Software M600

[cpardo13]

hello i have more software files for m600 36V. One version with 25A and three with 15A.

[PrivatePuffin]

Cool feel free to submit a PR, or mail them to me directly if you donnot know how (email address is on my profile)

:-)

Sure it's for the m600 though? I think there is only a 36v m500?

[cpardo13]

Sure i have installed on my frame. It's 36v.

[cpardo13]

I send the mail with the firmwares

[cpardo13]

[PrivatePuffin]

Very interesting, I never knew! I'll adapt the documentation right away!

[cpardo13]

I think the firmwares with 15A are for legal prupose in EU. Same as the Norway Elife ebikes with this 3 firmwares call them " the kind ", " the wild " and "the wilderness ". 😂

[PrivatePuffin]

I've merged the requested information, thanks for the headsup!

[PrivatePuffin]

I think the firmwares with 15A are for legal prupose in EU. Same as the Norway Elife ebikes with this 3 firmwares call them " the kind ", " the wild " and "the wilderness ". 😂

Nope, 15194 and the EU regulation its harmonised for, talks about "nominal RATED power" which is measured using the a formula that calculates wattage for a certain temperature equilibrium. There is no peak-power limit in the EU. It's super uber legally complex, but I should look into uploading the related standards and regulations shortly.

That being said: You have access to Norway Elife firmwares? please please please send me some!

[casainho]

Hmmm, so I would say the motor can handle as max the 58V battery and a current of 25A = 58 * 25 = 1450 watts.

[PrivatePuffin]

Hmmm, so I would say the motor can handle as max the 58V battery and a current of 25A = 58 * 25 = 1450 watts.

I'm not sure the 36A/25A firmware has the same uper voltage limit. If it does that would be amazing, because that would indeed mean we finally have a 1450watt firmware... :D

That being said: The motor itself runs fine at 48v/40A (= about 2000w) according to Luna Cycles, because they basically do a shunt mod that allows double current to flow.

[casainho]

But on TSDZ2, the 36V motor and 48V motor, the coils are different but the controller is just the same, that can handles the 18 amps, independent of the battery voltage, that can be something from 24V (7S) up to 58V (14S).

[casainho]

Well, when we have our OpenSource firmware, we can explore the hardware max limits :-)

[PrivatePuffin]

But on TSDZ2, the 36V motor and 48V motor, the coils are different but the controller is just the same, that can handles the 18 amps, independent of the battery voltage, that can be something from 24V (7S) up to 58V (14S).

Thats different with bafang m500/m600: The motor is the same, even between m500 and m600.

The controller is the same for all m500 and m600 voltage versions, the voltage is firmware only (thats also why the voltage and amps are an added sticker besides the actual serial number). There are controller differences between the m500 and m600 controller however, the m500 is missing one shunt resistor and (at least?) one MOSFET. Ohh and they shuffled the phase wires.

The controllers are actually a variant of the controllers sold by bafang to OEM's that make custom ebikes/motors... So that explains why they are so similair

[casainho]

Hmmm, if the motor is the same between M500 and M600, why there is such big difference on the weight??

[PrivatePuffin]

Hmmm, if the motor is the same between M500 and M600, why there is such big difference on the weight??

The motor is the same, but the m600 uses slightly different gears and one plastic gear is replaced with Metal. See the documentation and pictures I added ;-)

[cpardo13]

The case of the m600 is more widther than the m500.

[PrivatePuffin]

The case of the m600 is more widther than the m500.

It's not. I just uploaded the official specs for that.

[PrivatePuffin]

hmmm... Weight difference is indeed 500g So there might actually also be a winding difference between the m500 and m600.... so you might be right there @casainho

That would explain the torque differences between m500 and m600 and why the m500 can be classified as 250w and the m600 cannot, because more windings would improve the torque response at the same voltage and would produce less heat, which would lead to a higher EU rating for continues power.

Not between different versions of the m600 though, i'm sure of that because they would've had to publish stuff about it.

[cpardo13]

I reed in a forum the case of the m600 is more widther in the left side for the different gears reduction inside... But i don't know

[PrivatePuffin]

I reed in a forum the case of the m600 is more widther in the left side for the different gears reduction inside... But i don't know

Not everything you read on the internet is True. Please actually read our documentation and images on it, it also includes drawings and such. But as also stated on the forums the gear reduction is almost the same ;-)

edit I since also actually added some of the images to the docs :)

[PrivatePuffin]

Update:

• I've had some contact with Luna Cycles, they donnot have more firmwares than they already shared publically.
• I've had contact with Elife (Norwegian company producing the Elife X with their m600s motor), they cannot share their firmwares or hardware changes because they do not want to allow competitors to copy it. They did however share that in their testing the m500 has, in practice, about the same torque as the m600 and their choice for the m600 was mostly due to the build quality (presumably the plastic gear in the m500)
• I've thrown Dengfu a email if they can deliver me a m600 with a EU legal firmware like Elife does for the m600s, because I know that both Dengfu and Elife both have close connection with Bafang and Dengfu actually makes the frame for the Elife X already. So that might work out to get a nice custom firmware out of it :)
• If anyone wants to: Feel free to try to get bafang to send us a 48v25A firmware or EU legal firmware for the m600 though, I would really like one of those.
• I've added the 864w (48v/18a) firmware for the m500 from emtbforums, this should be the most powerfull firmware for the m500

[CiDi-IT]

I'm starting to think that firmware can be installed either on m500 or m600 controllers, knowing that the m500 controller and motor handle less current. Has anyone verified this?

[cpardo13]

I think the same. The firmwares in 36v are very similar references also in m500 and m600.

[KyokushinPL]

320 in f/w name means M600 and M500 its 420.

Wysłane z iPhone'a

Wiadomość napisana przez cpardo13 @.***> w dniu 23.07.2021, o godz. 09:15:

 I think the same. The firmwares in 36v are very similar references also in m500 and m600.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[cpardo13]

No. I received diferent firmwares directly from bafang for my m600 36v with 320 and 420 serial numbers.

[CiDi-IT]

Interesting, so 420 firmware is for M500, 320 firmware for M600, but they can be installed in both motors. Therefore the division by motor is useless, it is better to divide them by voltage / current.

[CiDi-IT]

Has anyone tried to do a file comparison? For example I have compared the 36V/25A file with the 48V/18A file, and they differ in only one since I assume both the indication of the nominal voltage and the maximum current.

[KyokushinPL]

I just have got confirmation from Bafang rep.

Wysłane z iPhone'a

Wiadomość napisana przez cpardo13 @.***> w dniu 23.07.2021, o godz. 09:45:

 No. I received diferent firmwares directly from bafang for my m600 36v with 320 and 420 serial numbers.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[KyokushinPL]

What will happen after flashing m500 by m600 firmware? Anyone tried?

Wysłane z iPhone'a

Wiadomość napisana przez Andrzej Czarnowski @.***> w dniu 23.07.2021, o godz. 10:09:

I just have got confirmation from Bafang rep.

Wysłane z iPhone'a

Wiadomość napisana przez cpardo13 @.***> w dniu 23.07.2021, o godz. 09:45:

 No. I received diferent firmwares directly from bafang for my m600 36v with 320 and 420 serial numbers.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[PrivatePuffin]

Has anyone tried to do a file comparison?

i've done a comparison of the hex output for some binfiles, they did not show a "magical hex value" we could change, sadly enough.

[PrivatePuffin]

@KyokushinPL and @CiDi-IT This indeed starts to show that the firmwares might not actually be limited by motortype at all.

I've also done some more research on how the m500 got EU compliant with 250w continues load. It's actually pretty smart: IEC 60034-1 determines that the nominal continues wattages is determined at the moment of temperature equilibrium (aka: doesn't get hotter anymore) at a certain load.

I always assumed they gimped the actual motor (coil) somehow, but I was wrong. The things they gimped is actually the controller! They didn't measure the temperature of the coil till equilibrium, they measured the FET's on the board. Thats the reason the m500 has less FET's on the board, because more power flowing through less FET's, means that single FET is getting hotter faster, so it would reach safe temperature equilibrium at a lower wattage aka: 250w in this case.

[PrivatePuffin]

No. I received diferent firmwares directly from bafang for my m600 36v with 320 and 420 serial numbers.

Could you try a 420 firmware on your m600?

[cpardo13]

Im waiting the bafng besst tool. When arrive i try all the firmwares in 36v

[casainho]

That kind information, we could get much more insights but looking at the board, to know how the hardware works. Does anyone have more detailed pictures?

Can anyone please donate me motor controllers? can be not working units. I will need a few and I will need to destroy them.

[CiDi-IT]

Quel tipo di informazioni, potremmo ottenere molte più intuizioni, ma guardando la scheda, per sapere come funziona l'hardware. Qualcuno ha foto più dettagliate?

Qualcuno può donarmi i controller del motore? possono essere unità non funzionanti. Me ne serviranno alcuni e dovrò distruggerli.

I have a spare controller and I can send you as many photos as you want, but I would prefer not to destroy it

[PrivatePuffin]

@CiDi-IT I've got more info on the CANBUS addresses as used by the BESST tool, you might want to start working on those as well:

https://github.com/OpenSourceEBike/Bafang_M500_M600/blob/main/CANBUS/BESST-CANBUS.md

[PrivatePuffin]

Okey @CiDi-IT and @casainho I've managed to figure out most of the CANBUS frames and documented it all.

I also found out it should be possible to set individual parameters on the controller, possible even things like max-current, using the CANBUS. However, while I found out the addresses, I need someone to work out the code to translate the data from the CANBUS packages to something readable.

I added the codesnippets from BESST that processes both the Reads and Writes to the controller to above document (at the bottom), but I think you guys and other interested parties should now be figure out how to access all accessable data and settings ^-^

[KyokushinPL]

Fingers crossed - mac current is holy grail for most of us

Wysłane z iPhone'a

Wiadomość napisana przez Kjeld Schouten-Lebbing @.***> w dniu 23.07.2021, o godz. 14:01:

 Okey @CiDi-IT and @casainho I've managed to figure out most of the CANBUS frames and documented it all.

I also found out it should be possible to set individual parameters on the controller, possible even things like max-current, using the CANBUS. However, while I found out the addresses, I need someone to work out the code to translate the data from the CANBUS packages to something readable.

I added the codesnippets from BESST that processes both the Reads and Writes to the controller to above document (at the bottom), but I think you guys and other interested parties should now be figure out how to access all accessable data and settings ^-^

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[PrivatePuffin]

A TLDR about the hidden CANBUS SET/GET/UPDATE options:

• There are 3 frameID endings for this: 6011 6012 and 6013
• When requested for data, we get a multipackage datastream
• The datastream contains multiple settings, which seem to be defined by their "data" paramater
• they also have a "read_value" which is their current settings
• if you want to set the value, you need to use the "set_value" parameter

However: i'm not sure how this multi-package stream works out in a NON-BESST utility.

[casainho]

I also found out it should be possible to set individual parameters on the controller, possible even things like max-current, using the CANBUS. However, while I found out the addresses, I need someone to work out the code to translate the data from the CANBUS packages to something readable.

On the "Maximum current-4", do you know for instance what are possible values? do you have an example CAN package only for this?

Also, how do you guys plan to have CANBUS access? I do not have any motor but if I did, and considering the CANBUS electric connections permit to add more and more nodes to the bus in parallel, I would add a wireless CANBUS to read and write data.

This means we would be able to monitor / log any data on the bus as also be able to write to the BUS, like you can imagine if there was a second display on the BUS, that can read the same data as display 1 reads.

I think the quickest and easiest way to this hardware could be a Raspberry PI Zero, that should use low energy but runs Linux and can easily be remoted access to run any code in C / Java or Python. But this hardware would not be final one, because it really uses to much power and would drain the battery.

The other option is the NRF52840, that has ultra low power mode (1 coin cell works for 2 years) Bluetooth, ANT and NFC. But here Bluetooth could be used to communicate with a mobile app or PC, like having a terminal over Bluetooth where we could send commands and receive data. This hardware would be the final one, that is small, ultra low power, has a button and a RGB LED. But it needs a firmware in C/C++, that is now fully develop for the TSDZ2 motor. This firmware is flashed on the board using Bluetooth, so it is easy for development. Also this hardware would be the one for when having our OpenSource firmware for the motor. User could keep using the original display or just this board with a simple remote keypad to turn on/off the motor and change assist level. All other data and options could be seen and changed on the mobile app:

Here pictures of the board on TSDZ2:

[casainho]

• read_value"

[casainho]

A TLDR about the hidden CANBUS SET/GET/UPDATE options:

• There are 3 frameID endings for this: 6011 6012 and 6013
• When requested for data, we get a multipackage datastream
• The datastream contains multiple settings, which seem to be defined by their "data" paramater
• they also have a "read_value" which is their current settings
• if you want to set the value, you need to use the "set_value" parameter

However: i'm not sure how this multi-package stream works out in a NON-BESST utility.

This makes sense for the CANBUS packages, that is the way things usually works.

[CiDi-IT]

With this simple interface I can receive and send can messages

[PrivatePuffin]

@casainho maxcurrent_4 and such are for assist levels afaik.

[casainho]

Yes, that would be enough for a motor configuration. What do you guys want, a tool configure the motor while it is connected to a PC or a way to configure the motor with a mobile phone, anytime like when riding on the field?

[PrivatePuffin]

Lets first reverse engineer the protocol and bother with implementations after, okey?

[casainho]

Lets first reverse engineer the protocol and bother with implementations after, okey?

I would build something simple to customize the assist levels because that would bring big and immediate value to users. For that, I would focus only on the "Maximum current-[0-4]" and not use time to understand all about the protocol.

And while it can be done with that very cheap USB-CAN devices and a PC, assist levels are very personal and there is need to tweak them while riding on the field, so, I would go with a mobile app instead a PC app. Maybe there are cheap USB-CAN devices for phones... And would be important to test a device like this to be connected simultaneous while the display is connected.

[PrivatePuffin]

I would build something simple to customize the assist levels because that would bring big and immediate value to users. For that, I would focus only on the "Maximum current-[0-4]" and not use time to understand all about the protocol.

No don't, max_current is just one of the assist settings and one of the least important of those. I suggest not skimming through the document I made and actually at least trying to understand it a bit ;-)

Also: You cannot just send a package with one current setting, like I explained it requires a set command with multiple packages containing all settings for said frameid.

[casainho]

If you agree on the feature assist level, than it is already good to focus on only that.

And since the assist level is changed by the display, we could replicate byte by byte what the display sends, or at least just focus on that packages. Should probably be the most easy thing to figure out.

Hmmm, no, the display just change but the BESST is the one that changes assist level factors.

[PrivatePuffin]

If you agree on the feature assist level, than it is already good to focus on only that.

And since the assist level is changed by the display, we could replicate byte by byte what the display sends, or at least just focus on that packages. Should probably be the most easy thing to figure out.

It seems you didn't actually completely understand my work. No what you propose is not possible.

The way displays set settings use a different CANBUS system than the way controller settings are changed. Please actually read through it, it's actually quite a bit more complicated. You cannot use the same commands to set frameid 6011 6012 and 6013

CANBUS frameid 6011 6012 and 6013, require a special sequence of packages that is unique to them to change settings. That is different from the way displays change things. Displays donnot change 6011 6012 and 6013.

Even BESST cannot change 6011 6012 and 6013 (it's not in the UI), those set parameters are most likely developement options from BAFANG. So "snooping and duplicating" the SET for those is not possible, however, we should be able to reverse engineer the GET by snooping BESST CANBUS calls and once we can duplicate those we can reverse it and send a SET.