"FAKE TAXI Project" - the modified original firmware for Bafang M820 motor

[rekrezeb]

Hi all,

I'd like to present a first public version (11.01.2026) of FAKE TAXI firmware for Bafang M820 motor.

Link: Proton Drive
File: FT_2026_01_11_public.zip
SHA256: 60c785e7010da3314eff8d91130a45da5c33051d7e1ef8006375dfe4bfd2f856

Inside the archive, you'll find a readme file with all technical issues. I'll provide more detailed info later.

rekrezeb

 

[Radolf]

Hi everyone

Someone has to write the first comment – let it be me I’m one of the few testers of this and previous releases of the modified SW for the M820.

First off – yes, it works! And it works definitely better than the original. It offers so much more, simply because the SW fell into the hands of a guy with insane knowledge who makes the impossible possible – big thanks to him for that but I bet he’ll still surprise us with something

Now, the issue that might surprise or discourage you – why is this SW for 11S batteries? We simply built these batteries on purpose because, as is well known, Bafang controllers handle batteries with an extra series of cells without issues (simplifying: for better range).

But don't worry! You can flash this even if you have a standard 36V (10S) battery. The only side effect will be an incorrect reading of a fully charged battery – I estimate it will show about 75%. Apart from that tiny downside, it’s all pluses, i.e.:

• Utilizing battery capacity to the very end, unlike the Bafang philosophy which is boring and very conservative
• Motor assist power drop only starts at 10% battery.
• Slightly different assist characteristics (SW with the letter V is more aggressive, with the letter W is more natural) – it’s worth checking both!
• Something I love just as much as the other changes – Walk Assist! Until now, I was the one pushing the bike up the hill because not only did it lack power, but it was also too slow (you had to shift to a lower gear to make it slightly faster, which isn’t desirable in those situations).

To sum up – I’ve done solid hundreds of kilometers on these mods, strictly in the mountains! Trouble-free and failure-free! Test it out and let us know your thoughts because I’m damn curious

 

[DPC18RI]

Something I love just as much as the other changes – Walk Assist! Until now, I was the one pushing the bike up the hill because not only did it lack power, but it was also too slow (you had to shift to a lower gear to make it slightly faster, which isn’t desirable in those situations).

I think a lot of people will be interested in having a better walk assist! But because of different M series motors i assume it's not that easy to find a solution to alter those different firmware's. But still, you guys got a big achievement!

 

[rekrezeb]

As mentioned before, I'll describe the firmware and its modifications in a bit more detail.

Regarding the name. At the beginning, when the very first attempts to modify the original firmware started, the goal was simply to check whether anything could be modified at all. We decided to change the version string as well, just to make it obvious that the modified firmware was actually running and to avoid any confusion with the original one. I put in 'FAKE TAXI ' as a joke - and it just stuck.

When it comes to firmware versioning, as you can see inside the archive, the files are named as follows: 'FT' at the beginning, then the date followed by the firmware version and a daily build number. If a file ends with 'v' + number, it means it is based on the original v3.3 (36V/15A). If it ends with 'w' + number, it is based on the original v2.5 (36V/15A). Internally, we also use 't' and 'u' versions: 't' is a test firmware based on a clean v3.3, while 'u' is a test firmware based on a clean v2.5. These are non-public test builds and you will never see them released. You may notice that the firmware build dates inside the archive are slightly different from the overall release date. This is because we decided to publish them now, even though testing and development are still ongoing.

I personally don't own an e-bike, but according to the testers, the assist curves are different in each firmware: v3.3 is more responsive and works better for riding in the mountains, while v2.5 does not provide linear assistance. That's as much as I know from their feedback. That's why we decided to modify both v3.3 and v2.5. In the short-term, we plan to add assist curve modification for each level (a lot of analysis has already been done, but we are still not even in the testing phase). When that happens, we will most likely continue developing only a single firmware, since it will be fully parameterizable. For now, there are two versions available, depending on personal preference or current needs.

All modifications required reverse engineering of the firmware and direct changes in the code. Everything that was modified is hardcoded, meaning it cannot be changed using any external tools like BESST, K1 or CANable. We noticed some discussions where people claimed that modifying the Speed Table via the CAN bus in original firmwares has any effect. This is definitely not possible, because those values are hardcoded. We also analyzed other firmwares that we did not modify, which - according to some forum posts - were supposed to allow speed table modification. This is simply not true.

In the mid-term, we plan to add the ability to store and modify all currently changed parameters via the CAN bus, using dedicated version of CANable. At the moment, however, everything is hardcoded and there is no way to change these values to anything else. So please don't ask how to 'easily tweak' things right now - it's not possible. Part of the parameters in this firmware are expressed in human-readable units, while others are based directly on ADC readings. Because of that, we are not going to build separate firmware versions for every possible configuration. You'll need to wait until parameter modification over the CAN bus is ready.

As I mentioned in my previous post, when you download the firmware archive, you'll find a PDF file inside with a detailed README, which contains the technical essence of all changes. Here I'll just briefly go over them, so it's clear what was modified for people who don't want to dig through the document.

1. BATTERY LIMIT CURVE MODIFICATION

The first change is the modification of the power limit curve. The README contains two graphs. The first one was created based on calculations and shows a graphical representation of the original curve reconstructed from values reverse engineered from the firmware. The second graph shows how this curve looks after the modifications proposed by the testers.

2 .BATTERY DISCHARGE CURVE MODIFICATION

The next change is the modification of the battery discharge curve. The firmware is intended for use with 11S batteries. Again, the first graph in the README shows the curve reconstructed from reverse engineering the original firmware calculations. The next graph shows how it looks after the changes - it is now matched to the actual discharge curve of this type of battery. As a result, the battery charge indicator now reflects reality much more accurately, unlike the original firmware. Below these graphs, there is also a table with other modified battery parameters. The most important one is undervoltage, which was lowered from 32 V to 31 V. In the original firmware, when the battery percentage reached zero, undervoltage was effectively at the same level. Once the display showed 0%, the bike stopped assisting completely. The testers wanted the bike to continue assisting even after 0% is shown, down to 31 V. Battery protection is then handled by the BMS. If someone wants to keep riding, the BMS protects the battery from over-discharge. The firmware itself does not completely cut off assistance, so the battery can be drained further than just the theoretical zero shown on the display.

3. SPEED TABLE MODIFICATION

The third change is the Speed Table values modification. The table included in the README contains all the parameters that are hardcoded in the firmware with their original and modified values. The behavior is analogous to other firmware series where Speed Table can be modified, so the values were adjusted according to the testers' proposals.

4. WALK ASSIST IMPROVEMENT

The last change is the Walk Assist improvement, and here things need to be split into two firmware versions. While all previous modifications were identical in both firmwares, Walk Assist differs significantly between them. In firmware 'v', the throttle value was increased from the original 12% to 26%, as testers agreed this was a good value after testing. The speed limit for Walk Assist was also slightly increased from 6.2 km/h to 6.6 km/h. There is no soft start here - when Walk Assist is enabled, the bike immediately starts moving, throttle jumps to 26%, and you get a noticeable jerk. That's simply how this firmware is built. In firmware 'w', the Walk Assist function is much more complex. In the table included in the README, you'll find all parameters that were modified. When Walk Assist is enabled while it was previously inactive, the throttle is set to the initial value. During the ramp-up phase, it increases to the base value. After that, throttle changes between base and maximum according to the attached graph. Both the original and the modified curves are included. This allows dynamic throttle adjustment based on actual assist current. Thanks to this, the bike speed remains more or less constant even when the load changes. In contrast, with firmware 'v', when riding uphill the speed will unfortunately drop, as this firmware does not include such compensation logic. All the original and modified timings are also listed in the README.

That's all I wanted to cover for now. I don't own an e-bike myself, but I treated this as a fun puzzle. Without the help of the other guys, who consulted everything and handled testing, none of this would have been possible. If anyone feels like testing the firmware and sharing feedback, we'll be grateful. Thanks and enjoy the ride!

 

[stancecoke]

All modifications required reverse engineering of the firmware and direct changes in the code

Do you know which processor is working in the M820 controller exactly?

Interesting project, but I prefer writing my own firmware from scratch. Hacking the OEM firmware, violating the manufacturer's IP is not my way

The behavior is analogous to other firmware series where Speed Table can be modified, so the values were adjusted according to the testers' proposals.

For me, this Speed Table is still a mystery. Especially, as you are calling the Speed Ranges simply 0 , 1, 2, .... in your PDF
I only found one source that tries to explain the "speed ranges"

The real fun begins! With our Torque Tab Turning World turned completely upside down, being dependent on bike speed/wheel rpm, and not pedal cadence nor motor rpm...

I had a DM last month from someone tuning his uart Ultra motor, and seeing behaviors he attributed to the SPD torque tab being related to cadence instead of wheel rpm. Here's a test anyone can run to verify for themselves

 

[Deko]

As mentioned before, I'll describe the firmware and its modifications in a bit more detail.

Regarding the name. At the beginning, when the very first attempts to modify the original firmware started, the goal was simply to check whether anything could be modified at all. We decided to change the version string as well, just to make it obvious that the modified firmware was actually running and to avoid any confusion with the original one. I put in 'FAKE TAXI ' as a joke - and it just stuck.

When it comes to firmware versioning, as you can see inside the archive, the files are named as follows: 'FT' at the beginning, then the date followed by the firmware version and a daily build number. If a file ends with 'v' + number, it means it is based on the original v3.3 (36V/15A). If it ends with 'w' + number, it is based on the original v2.5 (36V/15A). Internally, we also use 't' and 'u' versions: 't' is a test firmware based on a clean v3.3, while 'u' is a test firmware based on a clean v2.5. These are non-public test builds and you will never see them released. You may notice that the firmware build dates inside the archive are slightly different from the overall release date. This is because we decided to publish them now, even though testing and development are still ongoing.

I personally don't own an e-bike, but according to the testers, the assist curves are different in each firmware: v3.3 is more responsive and works better for riding in the mountains, while v2.5 does not provide linear assistance. That's as much as I know from their feedback. That's why we decided to modify both v3.3 and v2.5. In the short-term, we plan to add assist curve modification for each level (a lot of analysis has already been done, but we are still not even in the testing phase). When that happens, we will most likely continue developing only a single firmware, since it will be fully parameterizable. For now, there are two versions available, depending on personal preference or current needs.

All modifications required reverse engineering of the firmware and direct changes in the code. Everything that was modified is hardcoded, meaning it cannot be changed using any external tools like BESST, K1 or CANable. We noticed some discussions where people claimed that modifying the Speed Table via the CAN bus in original firmwares has any effect. This is definitely not possible, because those values are hardcoded. We also analyzed other firmwares that we did not modify, which - according to some forum posts - were supposed to allow speed table modification. This is simply not true.

In the mid-term, we plan to add the ability to store and modify all currently changed parameters via the CAN bus, using dedicated version of CANable. At the moment, however, everything is hardcoded and there is no way to change these values to anything else. So please don't ask how to 'easily tweak' things right now - it's not possible. Part of the parameters in this firmware are expressed in human-readable units, while others are based directly on ADC readings. Because of that, we are not going to build separate firmware versions for every possible configuration. You'll need to wait until parameter modification over the CAN bus is ready.

As I mentioned in my previous post, when you download the firmware archive, you'll find a PDF file inside with a detailed README, which contains the technical essence of all changes. Here I'll just briefly go over them, so it's clear what was modified for people who don't want to dig through the document.

1. BATTERY LIMIT CURVE MODIFICATION

The first change is the modification of the power limit curve. The README contains two graphs. The first one was created based on calculations and shows a graphical representation of the original curve reconstructed from values reverse engineered from the firmware. The second graph shows how this curve looks after the modifications proposed by the testers.

2 .BATTERY DISCHARGE CURVE MODIFICATION

The next change is the modification of the battery discharge curve. The firmware is intended for use with 11S batteries. Again, the first graph in the README shows the curve reconstructed from reverse engineering the original firmware calculations. The next graph shows how it looks after the changes - it is now matched to the actual discharge curve of this type of battery. As a result, the battery charge indicator now reflects reality much more accurately, unlike the original firmware. Below these graphs, there is also a table with other modified battery parameters. The most important one is undervoltage, which was lowered from 32 V to 31 V. In the original firmware, when the battery percentage reached zero, undervoltage was effectively at the same level. Once the display showed 0%, the bike stopped assisting completely. The testers wanted the bike to continue assisting even after 0% is shown, down to 31 V. Battery protection is then handled by the BMS. If someone wants to keep riding, the BMS protects the battery from over-discharge. The firmware itself does not completely cut off assistance, so the battery can be drained further than just the theoretical zero shown on the display.

3. SPEED TABLE MODIFICATION

The third change is the Speed Table values modification. The table included in the README contains all the parameters that are hardcoded in the firmware with their original and modified values. The behavior is analogous to other firmware series where Speed Table can be modified, so the values were adjusted according to the testers' proposals.

4. WALK ASSIST IMPROVEMENT

The last change is the Walk Assist improvement, and here things need to be split into two firmware versions. While all previous modifications were identical in both firmwares, Walk Assist differs significantly between them. In firmware 'v', the throttle value was increased from the original 12% to 26%, as testers agreed this was a good value after testing. The speed limit for Walk Assist was also slightly increased from 6.2 km/h to 6.6 km/h. There is no soft start here - when Walk Assist is enabled, the bike immediately starts moving, throttle jumps to 26%, and you get a noticeable jerk. That's simply how this firmware is built. In firmware 'w', the Walk Assist function is much more complex. In the table included in the README, you'll find all parameters that were modified. When Walk Assist is enabled while it was previously inactive, the throttle is set to the initial value. During the ramp-up phase, it increases to the base value. After that, throttle changes between base and maximum according to the attached graph. Both the original and the modified curves are included. This allows dynamic throttle adjustment based on actual assist current. Thanks to this, the bike speed remains more or less constant even when the load changes. In contrast, with firmware 'v', when riding uphill the speed will unfortunately drop, as this firmware does not include such compensation logic. All the original and modified timings are also listed in the README.

That's all I wanted to cover for now. I don't own an e-bike myself, but I treated this as a fun puzzle. Without the help of the other guys, who consulted everything and handled testing, none of this would have been possible. If anyone feels like testing the firmware and sharing feedback, we'll be grateful. Thanks and enjoy the ride!

Great job, what everyone has been waiting for and wanted for a long time. To reach a larger audience, could you increase the maximum voltage range to 60v so that people can use their 12s,13s,14s(43,48,52v) batteries? Then this modified firmware will be universal for all batteries. For full compatibility with different batteries, only this one parameter is important Overvoltage, and the BMS board is responsible for the rest.

 

[rekrezeb]

@stancecoke:

The MCU in M820 is GD32F303RCT6.

I'm familiar with your thread about developing new software and I'm really keeping my fingers crossed for this project. If everything works out, there will be no need to modify the original firmware at all. I definitely think that writing something from scratch is the better approach - having access to the source code and being able to improve it properly, instead of rebuilding or hacking existing software. I really appreciate the work you're doing here, because I know how much knowledge it takes to create something like this from the ground up, and unfortunately that level is completely out of reach for me at the moment.

I don't really agree with the idea that only modifying the original firmware is a violation of the manufacturer's IP. Writing software from scratch also requires reverse engineering - even if it's 'just' sniffing communication protocols or reversing things at the hardware level. If you didn't know which MCU is used in the motor, where the sensors are connected, or how the communication with the display works, you wouldn't be able to write your own software either. The same applies to the flashing process itself - I've seen you struggling with bypassing the original bootloader. In my opinion, if Bafang actually wanted people to write custom firmware, they would provide full documentation, schematics, and protocol descriptions. If they don't, I assume they simply don't want anyone to mess with it. From that perspective, I see modifying the original firmware and writing a completely new one as being on the same level when it comes to IP concerns. Howerver, I don't think it really matters in practice. Nobody is being robbed here - the manufacturer still makes money selling motors, and any kind of modification or availability of custom firmware likely drives hardware sales rather than hurts them. From the end user's perspective, the most important thing is that things work as they should, not how exactly that result was achieved.

Regarding the Speed Table, I'll describe it in more detail later. At the moment, I've already analyzed some parts of the firmware responsible for processing torque value. The data inside the Speed Table is split into several ranges. Each range depends on speed, and even though you can set a custom maximum speed for the bike, those ranges are constant in the software. There is a plan to add the ability to modify them as well. For now, they are stretched from 0 up to 25 km/h. In terms of torque processing, switching between those values is not done in a step-like way - the software interpolates the current value based on the previous and the next threshold. The transition between ranges is smooth and depends on the current speed of the bike.

 

[stancecoke]

the software interpolates the current value based on the previous and the next threshold

That's exactly the same way I do it
https://github.com/stancecoke/BAFAN...5a16e6393b7fe2514b54ea00725b/src/main.c#L1389

 

[rekrezeb]

@Deko:

I’m afraid that unfortunately overvoltage isn’t the only parameter that would need to be changed. Simply increasing the maximum voltage in the current firmware version would cause a risk of overpowering the motor, because the max current would still stay at 15A. For example, when using a 52V battery, the motor would be heavily overpowered. On the other hand, we also can’t just lower the max current, because then a motor with a 36V battery would end up underpowered.

What would really be needed is to create several firmware versions with a higher voltage threshold, but also with properly adjusted max current. The problem here is that even though I theoretically know where the reference max current value is, I’m not 100% sure that this is the only place defining it, and that there isn’t some other hardcoded value elsewhere in the firmware that isn’t calculated from it. Because of that, longer testing would be required to make sure such a change doesn’t cause any issues. I also haven’t analyzed any potential motor protection mechanisms yet, for example temperature-based ones.

The most reasonable approach would be to modify existing software versions already adapted to other batteries, but that takes time and also means having to maintain multiple firmware versions. Of course, in theory you could proportionally limit the max power across all assist levels - but how many people would actually do that? There will definitely be users who flash the new firmware without thinking, enjoy the extra power, and eventually damage the motor. Depending on ambient temperature and riding style, it might not happen right away, but we can’t predict all the consequences at this point.

Not to mention the need to adjust the discharge curve for different battery types for each firmware version - which technically isn’t mandatory, but would require checking SOC values via the BMS, because the display readings would be basically useless.

So to sum it up: at the moment, releasing firmware for other voltages is not planned. As mentioned earlier, in the mid-term we want to introduce the ability to parameterize the firmware via CANable. That should allow setting parameters, battery discharge curves, and limiting max current (which, again, would need proper testing first).

 

[borusgo2]

Hello.
Great news, so happy to see that someone can reverse engineer bafang SW. I think one of the most desirable thing would be to modify the voltage map.
I can see that some modified sections look the same but have a different offset.
It would be very nice to get any additional info what is ''what'' in the mod files.

Regards
Big Thanks
Piotr

 

[maglo18]

What exactly do you expect to achieve by modifying the voltage map?

I think one of the most desirable thing would be to modify the voltage map.

 

[borusgo2]

What exactly do you expect to achieve by modifying the voltage map?

Hi
Maybe I didnt express it properly, but basically I would like to get more juice out of the battery. Look bellow at 5A discharge of a samsung cell. Bafang have very conservative policy with cell voltage discharge. I think We can easly go to 3.0V as a 0% left of the battery.
By modifying voltage table You can gain somewhere from 20% to 30% more range out of the same battery.
Regards

 

[maglo18]

I think you have not reviewed the document from the ZIP file. In this software, it has been modified and optimized for an 11S battery. The new SOC battery curve and the reduced power cut-off level allow the battery to discharge down to 3 V and do not cause excessive over-discharge.

 

[borusgo2]

I think you have not reviewed the document from the ZIP file. In this software, it has been modified and optimized for an 11S battery. The new SOC battery curve and the reduced power cut-off level allow the battery to discharge down to 3 V and do not cause excessive over-discharge.

I have reviewed the document, PDF does only show voltage curve not the hex data and location. Was wondering where in the SW voltage map is located so I can play with it myself in other SW wersions.

 

[borusgo2]

Fale Taxi went nice and smooth into my m820 motor. The battery voltage map is perfect. At about 3.1V/cell there is 10% ok juice left.

Would like to do the same to 48V SW.

Regards

 

[Waynemarlow]

52 volt version would be appreciated. The motor seems to handle 600W's OK and I've had no over heating problems yet ( largely less than 5 minutes of climbing in Boost ).

 

[Hillhater]

Resist the temptation to google “Fake Taxi” ..
just sayin’ !

 

[Coolspot]

I'm really interested in this firmware but my battery is a Bafang 43V. My understanding is that firmware is for 36V, can I run it with my 43V battery? I can imagine the SOC% will be off but is there any problemrunning a 43V battery on a 36V firmware? too much amp?

 

[maglo18]

I'm really interested in this firmware but my battery is a Bafang 43V. My understanding is that firmware is for 36V, can I run it with my 43V battery? I can imagine the SOC% will be off but is there any problemrunning a 43V battery on a 36V firmware? too much amp?

Before flashing this firmware, the battery charge must not exceed 47 V.

 

[rekrezeb]

@borusgo2:

Regarding hex offsets: there was no such info in the README, because it doesn't work the way you think it does. I already wrote that everything we managed to change so far is the result of reverse engineering, and every single change required modifying the code. Just because something is hardcoded doesn't mean it exists in the firmware as a table that you can easily tweak with a hex editor. I also mentioned that the charts int he README were created based on equations that exist in the original software. There are no 'points' or ready-made maps there - most of the time it's ranges and the corresponding calculations. Constants often don't appear in a human-readable format, and loading them into variables doesn't involve 'pulling' a table from flash - at least not in this software. Most of the time it works like this: a value is loaded into a register and then ends up in the appropriate memory location. For 16-bit values, the instruction operand won't be fully and clearly visible in a hex editor. Blindly copying changes into another firmware makes absolutely no sense. It also happens that the indices of elements in data tables are not consistent with their actual locations in memory. Within the same controller and across different firmware versions, you might be able to find some analogies, but there's no guarantee that the relevant code range was compiled in the same way.

When it comes to different controllers, even ones based on the same processor, looking for analogous fragments in a hex editor is completely pointless. Out of curiosity, I took a look at the M510 firmware last week, and it turned out it's a totally different story. The software was compiled using different tools, possibly also written by someone else - its structure is completely different from the M820, so the whole analysis has to start from scratch. Of course, the experience from the M820 will definitely be useful and speed things up, but it's still basically 'starting over'.

Sure, it would be possible to prepare some kind of tool for the existing firmware version that would recalculate everything, encode it at the bit level, and modify the correct offsets, but that takes time and I don't see the point of building it right now. As I wrote earlier, in the mid-term we're planning to add software parameterization, including the voltage maps you mentioned. That will require reworking some existing parts and adding support for a table uploaded over CAN. This approach will allow us to develop just a single version that everyone can parameterize to their own needs. Changing parameters at the flash level would require maintaining multiple variants for every new release and to be honest, no one would really be fully satisfied, especially when you consider things like the parameters in the Speed Table. I already wrote that for now we're not going to create versions for different configurations. The software was properly prepared and tested before release. It's provided 'as is,' with a note explaining what it's intended for.

For now, we’re about to test setting assist levels and acceleration for each level. The next step is making the firmware 'CAN-able' with CANable, so please be patient

 

[borusgo2]

@borusgo2:

Regarding hex offsets: there was no such info in the README, because it doesn't work the way you think it does. I already wrote that everything we managed to change so far is the result of reverse engineering, and every single change required modifying the code. Just because something is hardcoded doesn't mean it exists in the firmware as a table that you can easily tweak with a hex editor. I also mentioned that the charts int he README were created based on equations that exist in the original software. There are no 'points' or ready-made maps there - most of the time it's ranges and the corresponding calculations. Constants often don't appear in a human-readable format, and loading them into variables doesn't involve 'pulling' a table from flash - at least not in this software. Most of the time it works like this: a value is loaded into a register and then ends up in the appropriate memory location. For 16-bit values, the instruction operand won't be fully and clearly visible in a hex editor. Blindly copying changes into another firmware makes absolutely no sense. It also happens that the indices of elements in data tables are not consistent with their actual locations in memory. Within the same controller and across different firmware versions, you might be able to find some analogies, but there's no guarantee that the relevant code range was compiled in the same way.

When it comes to different controllers, even ones based on the same processor, looking for analogous fragments in a hex editor is completely pointless. Out of curiosity, I took a look at the M510 firmware last week, and it turned out it's a totally different story. The software was compiled using different tools, possibly also written by someone else - its structure is completely different from the M820, so the whole analysis has to start from scratch. Of course, the experience from the M820 will definitely be useful and speed things up, but it's still basically 'starting over'.

Sure, it would be possible to prepare some kind of tool for the existing firmware version that would recalculate everything, encode it at the bit level, and modify the correct offsets, but that takes time and I don't see the point of building it right now. As I wrote earlier, in the mid-term we're planning to add software parameterization, including the voltage maps you mentioned. That will require reworking some existing parts and adding support for a table uploaded over CAN. This approach will allow us to develop just a single version that everyone can parameterize to their own needs. Changing parameters at the flash level would require maintaining multiple variants for every new release and to be honest, no one would really be fully satisfied, especially when you consider things like the parameters in the Speed Table. I already wrote that for now we're not going to create versions for different configurations. The software was properly prepared and tested before release. It's provided 'as is,' with a note explaining what it's intended for.

For now, we’re about to test setting assist levels and acceleration for each level. The next step is making the firmware 'CAN-able' with CANable, so please be patient

Big thanks for explanation and hard work.
I will buy a lot of popcorn for now and wait
If there is a way I can help somehow please let me know.

Regards
Peter

 

[rekrezeb]

Hi all,

After some discussion, we decided to go ahead and adapt FAKE TAXI for the remaining battery configs: 10S, 12S, 13S, and 14S. Keep in mind that these are untested firmware versions. Everything was modified without verification, so please approach them with caution (at least until someone tests and confirms that everything works as expected). The archive includes a README with details about the naming scheme - for each battery, firmware was prepared based on the previous 'v' and 'w' versions (in short: 'a' and 'b' for 10S, 'c' and 'd' for 12S, 'e' and 'f' for 13S, and 'g' and 'h' for 14S). Discharge curves and battery parameters are also included. Voltage levels were recalculated proportionally based on the 11S battery.

That's all for now. Any feedback is welcome - both for DIY batteries and original ones with a CAN-based BMS.

rekrezeb

Link: Proton Drive
File: FT_2026_02_02_public.zip
SHA256: 3ce5dfe08058c82bd3da3e190b71eda4a55dddec1bb3280942da59b2be1d280a

 

[DPC18RI]

I found the below quote interesting at EMTB forums whit the following question regarding 43V battery and fake taxi firmware.

Is this firmware work with 43V motor and battery?

You can check, but first discharge the battery below 46.0V (probably around 55% charge) otherwise your SN number may be lost.

I have no account at EMTB so i ask it here.
Having overvoltage can cause the SN number to vanish? Any other causes known that can make the SN gone? Undervoltage?

To be clear, the following is not related to the project in this thread. I noticed at some point my SN was gone (on a totally different controller). i'm sure not because of overvoltage but perhaps during tests with undervoltage i did? Or maybe when i tried to modify some settings?
It was no big deal, when i noticed it was gone i wrote it back. But seeing that message on EMTB I'm curious in what the findings / causes are regarding losing the controller SN number.

 

[Radolf]

In my humble experience, the SN only disappears after exceeding the battery voltage upper limit for a given FW. It definitely accepts a fully charged battery with one extra series of cells (+1S), but it won't accept two extra series (+2S) and simply 'wipes' the serial number :-D

 

[DPC18RI]

Thanks, good to know about the upper limit. I'm sure i never exceeded an upper limit so there must be more causes to get it wiped because i lost the serial several times in the past by playing with the controller using can interfaces etc. Which i obviously mostly notices only after some time by once in a while checking the "info tab" in the canable program. If a lost number has any influence on the working of the controller on a bike i don't know because i only "play" with them on my workbench.