Bafang M500/M600 thread

I also wanted to highlight the reason for this madness from Bafang removing self-modification features.

In the old version of EN15194 there was not requirement for locking anti-tampering measures, however:
The latest standard EN15194:2017, sadly enough includes a section pushed by Bosch and Shimano lobyists, this also makes the EN15194:2017 inherently incompatible with any DIY or repair community/mentality.

NEN-EN 15194:2017
4.2.17.1 General
Anti-tampering measures apply to tampering or modifications that general consumers carry out
concerning the control unit, drive unit or other parts of power assisting system by using commercially
available tools, equipment or parts.
4.2.17.2 Prevention of tampering of the motor
The following anti-tampering requirements shall be taken into account:
a) Anti-tampering relevant parameters indicated below shall only be accessible to the manufacturer
or authorized persons and changes of software configuration parameters require programming
tools that are not commercially available or security protected:
1) maximum speed with motor assistance (all systems),
2) parameters affecting the maximum vehicle speed limited by design,
3) maximum gear ratio (system with middle motors),
4) maximum motor power (all systems),
5) maximum speed of starting up assistance;
b) Assumable manipulations on the approval relevant configuration shall be prevented or
compensated by effective counter measures, i.e. plausibility logics to detect manipulations on
sensors;
c) Closed set of components (i.e. operation only with released battery);
d) Protection against opening of relevant components without traces (sealing).

Luckily, and in contrast to populair opinion, EN15194 is not a European requirement for ebikes!
It's a tool: if you comply with EN15194, you are guaranteed to comply to the relevant portions of the "Machine Directive".

It depends on the country in question if they actually require EN15194 compliance for ebikes to be used on the road. For example the BeNeLux does not.
However: I sincerely doubt if a judge is going to find your bike "non-compliant", just because you didn't add anti-competitive practices to your self-build bike.
 
ornias said:
Super awesome, could you give some reasons as to why they send you these firmwares?

They send me this firmwares because I ask them for a firmware that was not so powerful in the low assist modes. Unfortunately it is also not so powerful also in the high assist modes. When using 5 assist modes in the 18 Amp firmware, you get 380 W in 1st assist mode and 460W in 2nd assist mode. That is to much when you are trying to save some battery. I would like a firmware with 200 W in first assist mode, 350W in 2nd Assist mode, 550W in 3rd assist mode, 700w in 4th assist mode and 860 in 5th assist mode.
 
PadreParada said:
ornias said:
Super awesome, could you give some reasons as to why they send you these firmwares?

They send me this firmwares because I ask them for a firmware that was not so powerful in the low assist modes. Unfortunately it is also not so powerful also in the high assist modes. When using 5 assist modes in the 18 Amp firmware, you get 380 W in 1st assist mode and 460W in 2nd assist mode. That is to much when you are trying to save some battery. I would like a firmware with 200 W in first assist mode, 350W in 2nd Assist mode, 550W in 3rd assist mode, 700w in 4th assist mode and 860 in 5th assist mode.

Shoot, that is really a lot.... I agree your curve seems to be much more sane!
you could try the "luna_x1_firmware__74963" firmware shared in the repo above. Its a 46.5 firmware that is known for low assist on lower levels (afaik half of stock). This was done for their ludicrous edition, because they shuntmodded the board which means the actual amps are higher than the once the firmware detects.

So if you run that on a normal board, it should actually result in lower than assistance than stock, while keeping the highs :)
 
ornias said:
Shoot, that is really a lot.... I agree your curve seems to be much more sane!
you could try the "luna_x1_firmware__74963" firmware shared in the repo above. Its a 46.5 firmware that is known for low assist on lower levels (afaik half of stock). This was done for their ludicrous edition, because they shuntmodded the board which means the actual amps are higher than the once the firmware detects.

So if you run that on a normal board, it should actually result in lower than assistance than stock, while keeping the highs :)

Many thanks for the info. I have try Luna Firmware and unfortunately its not as progressive as I would like. The low (1 and 2 assist mode), are very, very low. 1st is below 100w and 2 below 200W. Then it steps up in 3,4 and 5. and they are ok. I don´t understand why is so difficult to compile a progressive firmware.
In 3 assist mode, is more linear and progressive, but I prefer to have 5 assist modes.
 
Good to know, it was worth the try though... But that seems reasonable as the firmware was designed for a 2-3x shunt mod (aka 200-300 and 400-600w respectively on levels 1 and 2) :)

You could try asking bafang to just "Half the assistence on every assist level" in a firmware.
 
One quick note about batteries that may help someone and that you may include in the repo . I have 2 batteries and one failed after some water got into it, and this are my learnings in the fixing process:
The Water damage the BMS Board and could not charge the battery above 44,5 V, The BMS is a 13 Channel (Serial) so I deduce that one or the 13 Channels was broken. (13x3,7V perCell= 48,1V vs 12x3,7V perCell=44,5V)
The BMS is a PWPB-509S Rev1.5 so I looked up in Aliexpress and found a similar one with the same channel connector. This is important because it makes the repair far easier, as you only have to solder the power cables, the Swith cables and the NTC1 port which is for the temperature probe. The temperature probe doesn´t come with the BMS, so I used the original.
This is the BMS board I used: https://www.aliexpress.com/item/32861318980.html?spm=a2g0s.9042311.0.0.274263c0mRljSi


The battery layout is 13 packs in serial that each one have 5 cells in parallel.. What is known as a 13S5P configuration.
They use different cells to build the batteries so you may have Samsung INR18650-32E(3100mAh) or Samsung INR18650-35E(3450 mAh). I have one of each. The 35E are the better because they weight the same and are able to store more mAh or Wh inside.
• INR18650-32E(3100mAh) 13x5x3.7Vx3100mAh=745 Wh
• INR18650-35E(3450mAh) 13x5x3,7Vx3450mAh=830 Wh
The battery case has a label that may give you a clue, on which version you have.
Battery label 35E.jpegBattery label 32E.jpeg
 
PadreParada said:
One quick note about batteries that may help someone and that you may include in the repo . I have 2 batteries and one failed after some water got into it, and this are my learnings in the fixing process:
The Water damage the BMS Board and could not charge the battery above 44,5 V, The BMS is a 13 Channel (Serial) so I deduce that one or the 13 Channels was broken. (13x3,7V perCell= 48,1V vs 12x3,7V perCell=44,5V)
The BMS is a PWPB-509S Rev1.5 so I looked up in Aliexpress and found a similar one with the same channel connector. This is important because it makes the repair far easier, as you only have to solder the power cables, the Swith cables and the NTC1 port which is for the temperature probe. The temperature probe doesn´t come with the BMS, so I used the original.
This is the BMS board I used: https://www.aliexpress.com/item/32861318980.html?spm=a2g0s.9042311.0.0.274263c0mRljSi


The battery layout is 13 packs in serial that each one have 5 cells in parallel.. What is known as a 13S5P configuration.
They use different cells to build the batteries so you may have Samsung INR18650-32E(3100mAh) or Samsung INR18650-35E(3450 mAh). I have one of each. The 35E are the better because they weight the same and are able to store more mAh or Wh inside.
• INR18650-32E(3100mAh) 13x5x3.7Vx3,45mAh=830 Wh
• INR18650-35E(3450mAh) 13x5x3,7Vx3,10mAh=745 Wh
The battery case has a label that may give you a clue, on which version you have.
Battery label 35E.jpegBattery label 32E.jpeg

Might be interesting, but I've no idea what battery you're talking about. Bafang sells multiple and there are also A LOT of aftermarket batteries out there ;)
 
ornias said:
Might be interesting, but I've no idea what battery you're talking about. Bafang sells multiple and there are also A LOT of aftermarket batteries out there ;)

Sorry, I am talking about Dheng-Fu batteries. Which I think are the same as Luna cycles batteries. You have a picture of it in the Repo

ATTACH]
 
PadreParada said:
ornias said:
Might be interesting, but I've no idea what battery you're talking about. Bafang sells multiple and there are also A LOT of aftermarket batteries out there ;)

Sorry, I am talking about Dheng-Fu batteries. Which I think are the same as Luna cycles batteries. You have a picture of it in the Repo


Ahh cool, you are the one I need for something it seems :p
would there be enough space to push this battery to 14s5p?
 
thank you PadreParada for these very useful informations. you have mixed the valus in your calculation

i suppose that the BMS replaced is for the 32C ? does it the same for the 35C ? does the 2 battery have the same size (thickness) ?
 
patdam said:
thank you PadreParada for these very useful informations. you have mixed the valus in your calculation

Thanks, I have allready corrected it.

patdam said:
i suppose that the BMS replaced is for the 32C ? does it the same for the 35C ? does the 2 battery have the same size (thickness) ?

The BMS is the same for both cells (32E or 35E), and yes since the Cells have the same layout, both packs are equal in size and weight. The only difference is that one is more powerfull than the other.

https://eu.nkon.nl/samsung-inr18650-32e-3100mah-6-4a.html
https://eu.nkon.nl/samsung-inr18650-35e.html
 
PadreParada said:
They use different cells to build the batteries so you may have Samsung INR18650-32E(3100mAh) or Samsung INR18650-35E(3450 mAh). I have one of each. The 35E are the better because they weight the same and are able to store more mAh or Wh inside.
• INR18650-32E(3100mAh) 13x5x3.7Vx3100mAh=745 Wh

file.php


so the label on the 32E battery pack says 840Wh which is incorrect?
 
ornias said:
Ahh cool, you are the one I need for something it seems :p
would there be enough space to push this battery to 14s5p?
There is space for some more cells inside that case. I think that 5 more may fit, but I will need to open it again and double check.
A 14S5P format with this same cells will give you a 48,1V+3,7V=52V Battery, aproximately 300g heavier than the original and with 65Wh more for the 35E and 55Wh more for the 32E.
 
NoFanBoiz said:
so the label on the 32E battery pack says 840Wh which is incorrect?

Yes its incorrect in both cases 32E or 35E, but in the 32E cells, the error is around 100Wh.
To get to hte 840Wh number, they have than the following calculation 13x5x3.7Vx3500mAh=841,75Wh. They have rounded voltage and mAh up, way to much.
 
ornias said:
would there be enough space to push this battery to 14s5p?
A friend of mine already did this. Check out this group post: https://www.facebook.com/groups/2323768714344360/posts/3939496859438196 A guy from Poland is about to import these cases to Europe, that are 14S5P by default, without modding. His company is called HDenergy. Contact: hdenergyy@gmail.com
But: I think this discussion is not M500/M600 related.


 
Tomblarom said:
ornias said:
would there be enough space to push this battery to 14s5p?
A friend of mine already did this. Check out this group post: https://www.facebook.com/groups/2323768714344360/posts/3939496859438196 A guy from Poland is about to import these cases to Europe, that are 14S5P by default, without modding. His company is called HDenergy. Contact: hdenergyy@gmail.com
But: I think this discussion is not M500/M600 related.



It is because those 52v batteries remove some issues people are having with the low power output of the m500/m600 ;)
 
ornias said:
All things considered, it would be nicer if Luna Cycles started to embrace opensource and DIY and share which knowhow they have about the motors and which procedures they follow to modify theirs. We donnot need any proprietary software at this stage, we mostly just need to start to learn how the product behaves.

I'm 100% convinced Luna is totally clueless about this motor and would have absolutely nothing to offer. All they accomplished was to put shitty firmware on their M600 motors at the insistence of Bafang who was worried about liability with the 2x ludi mod. Bafang was the one that actually did the programming from what I understand, to castrate ludi at lower PAS. Luna put this shitty firmware on all their motors (beyond a few early motors up thru the middle of this year), and not just the motors with the Ludi mod which made the non-ludi motors unusable at lower PAS. They finally offered the BESST tool after users complained about it so that we could rid ourselves of the luna claptrap. Prior to that Luna was arrogant enough to claim their programming was "superior".
 
Tom said:
ornias said:
All things considered, it would be nicer if Luna Cycles started to embrace opensource and DIY and share which knowhow they have about the motors and which procedures they follow to modify theirs. We donnot need any proprietary software at this stage, we mostly just need to start to learn how the product behaves.

I'm 100% convinced Luna is totally clueless about this motor and would have absolutely nothing to offer. All they accomplished was to put shitty firmware on their M600 motors at the insistence of Bafang who was worried about liability with the 2x ludi mod. Bafang was the one that actually did the programming from what I understand, to castrate ludi at lower PAS. Luna put this shitty firmware on all their motors (beyond a few early motors up thru the middle of this year), and not just the motors with the Ludi mod which made the non-ludi motors unusable at lower PAS. They finally offered the BESST tool after users complained about it so that we could rid ourselves of the luna claptrap. Prior to that Luna was arrogant enough to claim their programming was "superior".

Agreed. Probably the best thing Luna is doing is making the BESST tool available at cost to try and help reprogram the bikes which came with the sucky firmware. Though still sucks to pay $100 for a tool to fix a firmware issue which should not have left the shop in such condition.

Anyway, looks like this thread is taking an interesting turn with a few dedicated individuals, the opening of the github repo and steps toward open source. So I'm signing on to help any way I can there! I have an X1/M600 and some electronics/electrical experience, so happy to help there... test, measure, find component datasheets, design circuit boards, etc - though pretty light on the software side. I can make an arduino work, but beyond spelling 'canbus' and a few of the tweaks offered pretty weak there!

Anyway, will be following closely.
 
4pir, and so can you find information / datasheets of the motor controller??
 
If you have specific component numbers you're interested in, let me know and I'll see what I can find. If you need to know the components in the controller + data sheets, that will take a bit longer as I'd have to pull my controller apart and see what I can see. But let me know and I'll go from there.
 
4πr^2 said:
If you have specific component numbers you're interested in, let me know and I'll see what I can find. If you need to know the components in the controller + data sheets, that will take a bit longer as I'd have to pull my controller apart and see what I can see. But let me know and I'll go from there.
Yes, we really need the most detailed images possible from the motor controller as also the schematic and the components list, so, every information you can get will help a lot!!

Let's say they use a STM32xxx, then we can try find a STM32xxx development motor controller0 board and develop the firmware there, which will be probably faster and cheaper, then as last step, move the code from the development board to the final board. Usually the companies follow this development boards, using the same schematic, components and even the firmware.
 
4πr^2 said:
If you have specific component numbers you're interested in, let me know and I'll see what I can find. If you need to know the components in the controller + data sheets, that will take a bit longer as I'd have to pull my controller apart and see what I can see. But let me know and I'll go from there.
Yes, we really need the most detailed images possible from the motor controller as also the schematic and the components list, so, every information you can get will help a lot!!

Let's say they use a STM32xxx, then we can try find a STM32xxx development motor controller0 board and develop the firmware there, which will be probably faster and cheaper, then as last step, move the code from the development board to the final board. Usually the companies follow this development boards provides by the microcontroller manufacturer, and they use the same schematic, components and even the firmware provided.
 
I'll work on getting set up on github and some pics. Looks like my motor is using an S32K142H controller
https://www.nxp.com/docs/en/data-sheet/S32K-DS.pdf

80V / 60A mosfets if anyone is interested:
http://www.hunteck.com/Datasheets/HGN036N08S_V1.0-061417.pdf
 
Why reinvent the wheel guys, I know Caisanho loves to reprogram from scratch and probably in the long term creates a better motor. But that development is hugely long winded as in the case of the TSDZ2 which has been developed now for probably 3 years.

With the M600 we have a pretty good motor straight out of the box, certainly powerful enough for most ( if we exclude Americans who want 2K Watts ), it’s just a bit crude in its manners. The question in the short term is more how to tweak the existing motor firmware more than total redevelopment, which in my view is just finding out what and how parameters can be altered and then putting that into a friendly user App like Blevo.

Sure a total redevelopment OSF firmware will be needed eventually as Bafang will almost certainly follow every other manufacturer and lock out any user alterations to the firmware such as Specialized have recently done.
 
Waynemarlow said:
Why reinvent the wheel guys, I know Caisanho loves to reprogram from scratch and probably in the long term creates a better motor. But that development is hugely long winded as in the case of the TSDZ2 which has been developed now for probably 3 years.

With the M600 we have a pretty good motor straight out of the box, certainly powerful enough for most ( if we exclude Americans who want 2K Watts ), it’s just a bit crude in its manners. The question in the short term is more how to tweak the existing motor firmware more than total redevelopment, which in my view is just finding out what and how parameters can be altered and then putting that into a friendly user App like Blevo.

Sure a total redevelopment OSF firmware will be needed eventually as Bafang will almost certainly follow every other manufacturer and lock out any user alterations to the firmware such as Specialized have recently done.

If you followed the github repository, you would notice we are also doing that...
But we seem to be either hitting some snags decoding the CANBUS interface or BAFANG actually locked down the settings we can change.

We are exploring both avenues, in both cases we really need to get to both the CANBUS protocol AND the controller hardware
 
Back
Top