Making Begode wheels safer: PWM tiltback with custom firmware

[Seba]

8 minutes ago, supercurio said:

Maybe 8 bit precision for PWM with max PWM supported by the controller being the value 255.
Can it reach above 100%? (you never know...)

We can also divide it by two (right shift by one bit), so we'll make use of 7 bits instead of 8 bits. So instead of having 0..255 we'll get 0..127).

11 minutes ago, supercurio said:

And 8 bit signed precision as well for battery current.

What about using upper 9 bits for battery current and lower 7 bits for PWM? For example:

• PWM as a 7-bit unsigned value, ranging from 0 to 127 or 0 to 100 %
• battery current as a 9-bit signed value, ranging from -128 A to 127.5 A, with 0.5 A resolution

In both cases we get reasonable precision and range, covering even most powerful wheels.

[RolluS]

Hello @Seba, @supercurio

 

Nice idea to have pwm as 7 bits and battery current (if really available?) on 9 bits.

But... Battery fuses on Begode T4 are already 120A, I don't know if there are accurately chosen Am or Gg fuses badly selected to take current peak into account.
Then, INT9 (🤪) might be better as UINT9 and the sign computed with phase current.

Actually we have a decimal resolution for pwm, so assuming it's not a float, that's 10 bits.

My computer science last class was 21 years ago, I hope my message makes little sense anyway.

Edited October 26, 2022 by RolluS

[dycus]

I don't think it makes sense to have decimal precision on PWM... from a human's point of view, is it actually useful to know the PWM is 65.7% rather than 66%? I really don't think so. Better to use the extra bit(s) for something more useful.

[RolluS]

1 minute ago, dycus said:

I don't think it makes sense to have decimal precision on PWM... from a human's point of view, is it actually useful to know the PWM is 65.7% rather than 66%? I really don't think so. Better to use the extra bit(s) for something more useful.

I agree. For this point, I was just making a statement. I would love to have battery current and pwm. That would enhance EUC World precision a lot (mAh counter, safety margin, etc...)

[Bizra6ot]

49 minutes ago, RolluS said:

But... Battery fuses on Begode T4 are already 120A, I don't know if there are accurately chosen Am or Gg fuses badly selected to take current peak into account.

@RagingGrandpa sent me this if it helps
"A melting fuse with a label rating of 120A should pass 200% of its rating for at least 1 second. There is lots of extra headroom for pulses"

[RagingGrandpa]

On 10/24/2022 at 8:52 AM, supercurio said:

A more robust alarm model will alert on at least these 3 thresholds:

1. % of PWM
2. % of phase current
3. % of battery current vs battery spec

That way we have a method to avoid slow speed overlean when running out of phase current for torque, PWM for obvious reasons and battery current to avoid damaging cells on strong accelerations or hard braking.

So this is going beyond "avoiding an overlean crash," and moving into a vague concept of 'being nice to your machine.'

I suppose it might be helpful in some cases to know when battery current is excessive, which could occur during special situations (e.g.: climbing a hill with a headwind and a mud-packed motor). 
But I recommend identifying such a situation first: you will likely hit the PWM alarm, before battery current becomes noteworthy. And so the PWM alarm was enough, and extra effort on battery current alarms was wasted.
 

1 hour ago, RolluS said:

Battery fuses on Begode T4 are already 120A

Those fuses are not very carefully chosen... better to ignore them. If battery current exceeds 100A for more than an instant, something in the EUC has failed. 

Also beware, actual battery current is quite noisy. Some simple LPF would be necessary, to use it for an alarm/tilt behavior.

On 7/30/2020 at 11:44 AM, RagingGrandpa said:

Below shows a baseline for 'normal use' - a firm forward lean like I regularly use to accelerate from a stop:

[supercurio]

29 minutes ago, RagingGrandpa said:

So this is going beyond "avoiding an overlean crash," and moving into a vague concept of 'being nice to your machine.'

Yes exactly 😊 Being able to log, and since we don't want to make the user crash unnecessarily: always alert in case this is at the expense of the hardware health so it doesn't become something continuous or happening too often, as the rider integrates the new wheel limits in its riding style.

 

29 minutes ago, RagingGrandpa said:

I suppose it might be helpful in some cases to know when battery current is excessive, which could occur during special situations (e.g.: climbing a hill with a headwind and a mud-packed motor). 

But I recommend identifying such a situation first: you will likely hit the PWM alarm, before battery current becomes noteworthy. And so the PWM alarm was enough, and extra effort on battery current alarms was wasted.

It's hard to tell for sure until we have sufficient data.
When I was riding the OG Sherman, I had an EUC World alarm on estimated 60A battery current in order to avoid damaging another board due to excessive battery current. 30A+30A fuse: 60A. With an aggressive riding style, I hit it a million times during accelerations.

Now it's possible that the EUC World battery current estimate on Sherman was not very accurate but has still been useful and effective for its intended purpose.

On a HS Begode 100.8V 4P wheels with high capacity cells, hitting a 40A battery current alarm is probably super easy in an acceleration. That's my guess at least! I look forward to see data logs.
For custom or damaged wheels which have only 1 pack instead of 2 or 3, setting the limit to the actual battery capability will be very useful then. Due to the amount of Begode packs going bad, there's a bunch of people limping on 2/3, 1/2 or even 1/3 of the expected battery current capability.

 

29 minutes ago, RagingGrandpa said:

Also beware, actual battery current is quite noisy. Some simple LPF would be necessary, to use it for an alarm/tilt behavior.

Good point, if the battery current sent is a low sample rate based on noisy data maybe it won't be that useful especially for alarms. If it's not already the case, maybe @Freestyler could implement some smoothing here? I have no idea if the enough resources in the main loop would be available to allow that 😆

I'm asking about this data being available in the protocol but once this is well tested with app alarms, I would highly recommend to integrate battery current thresholds into the wheel beeps & tiltback.
First, in @Freestyler custom firmware, then Begode. That would certainly reduce the fire risk - if cell stress is indeed a significant factor.

Having only PWM as threshold for rider feedback is not sufficient IMO.

Edited October 26, 2022 by supercurio

[RolluS]

3 minutes ago, supercurio said:

On a HS Begode 100.8V 4P wheels with high capacity cells, hitting a 40A battery current alarm is probably super easy in an acceleration. That's my guess at least! I look forward to see data logs.

Check Telegram  But for the recorded trip, I was cruising around 30km/h and barely hit 15A estimated battery current.

[supercurio]

3 hours ago, Seba said:

We can also divide it by two (right shift by one bit), so we'll make use of 7 bits instead of 8 bits. So instead of having 0..255 we'll get 0..127).

What about using upper 9 bits for battery current and lower 7 bits for PWM? For example:

• PWM as a 7-bit unsigned value, ranging from 0 to 127 or 0 to 100 %
• battery current as a 9-bit signed value, ranging from -128 A to 127.5 A, with 0.5 A resolution

In both cases we get reasonable precision and range, covering even most powerful wheels.

That sounds reasonable.

I would suggest to give a try in a beta version and observe the range for the data coming out before making the final decision.
Battery current & voltage, that would be used to calculate the energy drained from the pack, right? Therefore beneficial to have higher resolution here.

[Seba]

10 hours ago, supercurio said:

I would suggest to give a try in a beta version and observe the range for the data coming out before making the final decision.

I agree.

10 hours ago, supercurio said:

Battery current & voltage, that would be used to calculate the energy drained from the pack, right? Therefore beneficial to have higher resolution here.

Battery current would be used to calculate real power and energy consumption. For sure better resolution (desirably 0.1A) would be beneficial, but it's way better than current estimated power or energy figures.

12 hours ago, RolluS said:

Then, INT9 (🤪) might be better as UINT9 and the sign computed with phase current.

The problem is that negative phase current doesn't necessarily mean that battery current is also negative

[RolluS]

2 hours ago, Seba said:

I agree.

Battery current would be used to calculate real power and energy consumption. For sure better resolution (desirably 0.1A) would be beneficial, but it's way better than current estimated power or energy figures.

The problem is that negative phase current doesn't necessarily mean that battery current is also negative

I meant that with your formula allowing some estimation of the current. But...

13 hours ago, RagingGrandpa said:

Those fuses are not very carefully chosen... better to ignore them. If battery current exceeds 100A for more than an instant, something in the EUC has failed. 

So -128 to +127.5 seems enough.

----------

Thank you @Bizra6otand @RagingGrandpa for fuse/current figures

[Freestyler]

I've been very busy the previous week and didn't have much time to participate.

I appreciate everyone's input. I really do. Thanks! 

 

One concern of yours was the data size. I understand your points, but it's not as big of a problem imo to warrant bit packing everything and complicating the protocol.

And I'll explain. We still have space for 2 more 16bit values in the 2 frame packets. First one is poweroff timer and second one is remaining distance. (dumb calculation based on voltage)

Furthermore, newer wheels and firmwares have added a 3rd frame packet with only 3 out of the 8 16bit values occupied. So no need to worry about space.

We could fit the PWM in 8bits, but I would personally hate to lose the decimal precision of the PWM. (aren't we all nerding out about every little detail anyway? :P)

I remember having a ride and I was surprised that I didn't hit my PWM limit of 70%. I checked my max PWM on euc-dash and found out that I topped at 69.6%. 

 

I have found a clean way to distinguish a custom running firmware, by changing the firmware version preamble from GW -> CF (Custom Firmware).

Super easy to request firmware information from the wheel (which is returned in ASCII form) and then check the first 2 characters.

 

Command to request firmware version: https://github.com/freestyl3r/euc-dash/blob/f1eddfba3972c76e7a33ecf7a2d784395edb8e3a/js/begode.js#L49

Command to enable PWM tiltback (speed alert 3): https://github.com/freestyl3r/euc-dash/blob/f1eddfba3972c76e7a33ecf7a2d784395edb8e3a/js/begode.js#L57

PWM value in frame packets: https://github.com/freestyl3r/euc-dash/blob/bb65d895927d94602c5be0de6b6196a450a59da7/js/begode.js#L470-L474

 

This was tested on my mcm5 which has no separate dc board and on a wheel with a separate dc board.

No side affects have been observed. The dc board firmware doesn't seem to care about the first characters.

 

To clarify: we have not seen battery current on a wheel yet. My theory was incorrect and Seba is right for saying that he found no shunt resistors to measure such thing.

Adding additionally functionality such as alarms based on the phase current are definitely on my mind for future versions Supercurio!

On some late wheels such as the latest revisions of T4, Master, Master pro etc I found some mentions of a battery current in the extended packets, but we have not verified this yet.

 

I also made another (irrelevant) breakthrough and it seems that we can now change to any arbitrary PID value without the need to copy from another firmware.

I will soon test it out, but first I'm testing a front / back angle adjustment like the other wheel makers provide (for example +1 degree, -2 degrees etc).

Edited November 6, 2022 by Freestyler

[RolluS]

2 hours ago, Freestyler said:

I have found a clean way to distinguish a custom running firmware, by changing the firmware version preamble from GW -> CF (Custom Firmware).
Super easy to request firmware information from the wheel (which is returned in ASCII form) and then check the first 2 characters.

Command to request firmware version: https://github.com/freestyl3r/euc-dash/blob/f1eddfba3972c76e7a33ecf7a2d784395edb8e3a/js/begode.js#L49
Command to enable PWM tiltback (speed alert 3): https://github.com/freestyl3r/euc-dash/blob/f1eddfba3972c76e7a33ecf7a2d784395edb8e3a/js/begode.js#L57

Great and neat progress !

2 hours ago, Freestyler said:

This was tested on my mcm5 which has no separate dc board and on a wheel with a separate dc board.

No side affects have been observed. The dc board firmware doesn't seem to care about the first characters.

Is the original Begode app still able to flash? Else... oups

2 hours ago, Freestyler said:

On some late wheels such as the latest revisions of T4, Master, Master pro etc I found some mentions of a battery current in the extended packets, but we have not verified this yet.

I shall be able to test in a couple of day, when my T4 will be fully reassembled, please ask me

2 hours ago, Freestyler said:

I also made another (irrelevant) breakthrough and it seems that we can now change to any arbitrary PID value without the need to copy form another firmware.

I will soon test it out, but first I'm testing a front / back angle adjustment like the other wheel makers provide (for example +1 degree, -2 degrees etc).

Excellent !

[daniel1234]

Custom FW from Freestyler fixed my T4 v1 problem with not working PWM alarm. Thank you!

 

[daniel1234]

I think there is some miss behavior with T4 v1 -> Above 80 percent PWM pedals seem to float back and forward. For me, with street tire, it starts from 43 km/h at 80 percent of battery. Even though Freespin is high. A partial solution is having PWM alarm/tilt-back at 70 percent - but that sacrifice a lot of "fun factor. At 25 percent battery,  70 percent PWM tiltback limits speed to 38 km/h.

Anyway, I tried to report it to the begode through distributor and they don't believe me. Feel free to test it yourself if you have T4 and a working PWM alarm .

[EMA]

14 minutes ago, daniel1234 said:

I think there is some miss behavior with T4 v1 -> Above 80 percent PWM pedals seem to float back and forward. For me, with street tire, it starts from 43 km/h at 80 percent of battery. Even though Freespin is high. A partial solution is having PWM alarm/tilt-back at 70 percent - but that sacrifice a lot of "fun factor. At 25 percent battery,  70 percent PWM tiltback limits speed to 38 km/h.

Anyway, I tried to report it to the begode through distributor and they don't believe me. Feel free to test it yourself if you have T4 and a working PWM alarm .

the v1 had this issue , they tuned the firmware to solve this --> v2

[Freestyler]

The v2 firmware is not compatible though. Is it meant for the newer controller with 18 mosfets?

[daniel1234]

7 hours ago, EMA said:

the v1 had this issue , they tuned the firmware to solve this --> v2

Begode claims there is no issue - that I am bad rider (literally). Where you got that information ? Is it feeling or fact ?

[EMA]

Just now, daniel1234 said:

Begode claims there is no issue - that I am bad rider (literally). Where you got that information ? Is it feeling or fact ?

all the 1st batch wheel had this issue, i clearly remember evees video and also Denis Hagov mention this on their test units 

[Freestyler]

I've also read is several places that T4 gets sketchy in higher speeds.

As in the recent Master thread, this is maybe an effect of bad PID tuning. I can copy the v2 pedal modes to the V1 version if you want to try it out and see if it fixes it for you.

[RolluS]

2 hours ago, EMA said:

all the 1st batch wheel had this issue, i clearly remember evees video and also Denis Hagov mention this on their test units 

Asymmetrical riding stance solved this issue for me. But yes, first reviewer told *102 versions of the firmware had woobling issue (that I still had with *103 if "incorrect" stance)

[RolluS]

31 minutes ago, Freestyler said:

I've also read is several places that T4 gets sketchy in higher speeds.

As in the recent Master thread, this is maybe an effect of bad PID tuning. I can copy the v2 pedal modes to the V1 version if you want to try it out and see if it fixes it for you.

I'm willing to test if needed . I guess as soon as we have the good firmware repository hack everyone can test right?

Did you see anything regarding motor control? Like different timing, KV, etc? To know if there is a difference between ZX and QS motor firmware wise.

[daniel1234]

1 hour ago, Freestyler said:

I've also read is several places that T4 gets sketchy in higher speeds.

As in the recent Master thread, this is maybe an effect of bad PID tuning. I can copy the v2 pedal modes to the V1 version if you want to try it out and see if it fixes it for you.

Yes, please. It would be awesome. That is worth of shot.  QS motor have few percent lower KV rating.

If I can ask - Are 100v nikola PID values different from T4? If Yes, I would love to have instead of soft mode PID, 100v Nikola HS hard mode values. Normal soft mode have no use for me. The whole board looks like Nikola. The connection board have 120A fuse. But all cables look kinda tiny ... I liked feel of nikola. If it would ride at least as well as 100v Nikola I would be satisfied.
I am surprised that others don't report similar behavior. It is really noticeable downhill with medium mode. Hard more is a little bit more stable. With stable I mean pedal tilt - pedals tilt start to get wigle room few degrees up/down. It almost feels like you ride a wheel that is not circular and I am riding flat tire.

Thank you for support Begode does not offer! 

Respect - where we can donate some $$ for coffee?

[Ben Kim]

Late to the party but, would it be possible to detect ambient temps by smartly considering a lack of board temp increase under load, and reduce PWM accordingly? (Optionally of course) 

I only suggest this as premature cutouts are more common in very cold temperature conditions.  

[Seba]

12 hours ago, Ben Kim said:

Late to the party but, would it be possible to detect ambient temps by smartly considering a lack of board temp increase under load, and reduce PWM accordingly? (Optionally of course) 

I only suggest this as premature cutouts are more common in very cold temperature conditions.  

The problem is that temperature measurement on Begode motherboards is done via a temperature sensor located in the IMU chip. In practice, it is the temperature that corresponds to the temperature of the motherboard PCB, not the MOSFET transistors or the heat sink. Yes, the heating of the transistors also translates into an increase in the temperature of the motherboard, but due to the thermal inertia of the board and the high thermal resistance between the surface of the PCB and the transistors, the temperature measurement is unreliable and is basically useless. Definitely it can't be used to estimate ambient temperature.