Eggrider support

[Bafanger]

Will there be eggrider support on the new 1.6 version ?

[danielnilsson9]

No, I don't really have any interest of doing that but if anyone wants to contribute it I'm open for it.

[Bafanger]

Ok sounds like a good plan. I need to speak with few people and see if we can get this going. Is there any chance you would be interested in adding field weakening to your firmware ?

[dav0000000]

Are you saying it is possible to implement field weakening on the factory controller and know what needs to be done?

[danielnilsson9]

BLDC control firmware is a completely different firmware for a different microcontroller on the board. But it can be written and flashed although that requires deppotting the controller which very few people would do.

I wrote a programmer for the other microcontroller here as there is no cheap official one:
https://github.com/danielnilsson9/78k0r-pgm

I was able to flash it and run custom code but never put in the effort to go further.
Anything is possible, if I remember correctly there was some code for FOC implementation on that MCU somewhere, no idea if included field weakening. Datasheet is available so it could be implemented anyway of course.

I'm basically not running bafang motors anymore but TSDZ2 and TSDZ8 instead...

[Bafanger]

Thanks for the answer

[Eelviny]

Hi all, I'm making an attempt to get the Eggrider functional. While I don't think it's possible to support Eggriders re-programming functionality, if we can get the road/offroad switch working, I think that'll be enough to make it worth using with bbs-fw.

See my work in progress PR here: #284. Any help is appreciated, the depth of my embedded programming knowledge at this point doesn't go past a few C functions for my esphome devices ;)

[ericboucher225-png]

Hi,
I have completed an experimental OEM / EggRider compatibility implementation
based on BBS-FW 1.5.0 for BBS02.

The implementation currently supports:
-EggRider Road mapped to BBS-FW Normal/Standard
-EggRider Off-road mapped to BBS-FW Sport
-PAS settings stored separately for Road and Off-road
-OEM Basic, Pedal and Throttle read/write commands
-OEM identification and authorization exchange
-Walk mode, throttle, brake sensors and shift sensor

The generic version has been compiled, flashed, bench-tested and road-tested
successfully on a BBS02 controller.

One known limitation remains: after changing Road/Off-road in EggRider, the
user must wait until the profile-change confirmation message disappears
before pressing Read. The OEM Read request does not contain a profile
identifier, so a Read during the transition can return the previously
confirmed profile.

On my controller, I also have a lighting issue: one of the light outputs, either front or rear, stopped working after flashing BBS-FW. I cannot identify which output is affected because I do not have the controller pinout, wire identification, or internal circuit routing.

@danielnilsson9, would you be interested in reviewing this work?

[ericboucher225-png]

Quick update regarding the lighting issue mentioned in my previous comment:

The lighting problem has now been corrected and validated on my BBS02. After correcting the P0.1 light-output control in BBS-FW, both the front and rear lights are now operating correctly.

At this point, the only remaining known limitation is the Read timing after switching between Road and Off-road profiles in EggRider.

[dav0000000]

Hi,With the read timing issue, you have to make sure the motor is not in the middle of getting a status, current or cadence update in process_com_state_machine_idle() in motor.c. Your attempt to change Max Current will fail if one of the operations above is in progress. It is also best to make sure the motor is idle before allowing the update to trigger. Setting Max Current will also fail if the current or cadence is being changed. I haven’t touched any code on this for about 2 years so it’s a bit vague in my memory but I had the same issues you describe and fixed it.So, set a bool somewhere when your update is triggered and only allow the trigger to be activated when the motor is idle, then wait for the status, current and cadence update requests to complete.You mention the read timing after switching and you may also have to make sure the same conditions above are met before you read.Happy to discuss further if needed.On 29 Jul 2026, at 15:40, ericboucher225-png ***@***.***> wrote:ericboucher225-png left a comment (danielnilsson9/bbs-fw#267) Quick update regarding the lighting issue mentioned in my previous comment: The lighting problem has now been corrected and validated on my BBS02. After correcting the P0.1 light-output control in BBS-FW, both the front and rear lights are now operating correctly. At this point, the only remaining known limitation is the Read timing after switching between Road and Off-road profiles in EggRider. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[ericboucher225-png]

Hi, thank you for the detailed explanation.

After reviewing the exact behavior, I believe the issue I described occurs at
a slightly different layer.

Normal Road/Off-road switching during regular EggRider use works correctly,
and I have not observed any problem when changing profiles while riding.

The issue only occurs in the EggRider Basic settings. If I select Road or
Off-road and press Read before the profile-change confirmation message
disappears, EggRider can send the OEM Read request before the new 0x1F profile
announcement has been received and confirmed.

Because the OEM Read request does not contain a Road/Off-road identifier, the
firmware can then return the previously confirmed profile. Waiting until the
confirmation message disappears avoids the issue consistently.

That said, I will also verify whether status, current or cadence communication
is still in progress when the Basic profile selection and Read occur. A
deferred trigger using a pending boolean may improve the synchronization of
the requested profile update and the Read response, even if it does not
completely remove the profile ambiguity.

Do you remember whether your fix was added only in motor.c, or whether you also
changed the display-side communication handling in extcom.c?

[dav0000000]

I don't think anything in extcom was relevant. You are reading from the controller though and I don't do that to get any values, you will probably have to wait for status updates and idle motor for that to proceed reliably.

[dav0000000]

Ok, I think what I just said is probably not valid for your problem. You are not reading the values from the controller really, you are just answering them in extcom, right?

When you select the new profile you probably set the max current for that profile and also the current and cadence for the selected pas level. This update happens on the controller. Max current is not asyncronous in daniels code from memory. How do you set those values when the new profile (road/off road) is selected. What happens in your code if this update fails. I kind of remember that everything gets a bit messed up for a while if you try to make multiple requests to the controller while it is already processing something. All a bit vague though.

[ericboucher225-png]

Yes, that is correct. The Basic Read values are generated in extcom.c from the profiles stored inside BBS-FW rather than being read back from the motor controller.

For the Road/Off-road switch, I do not send a series of Max Current, current or cadence configuration requests directly to the controller. When the 0x1F profile announcement is received, the implementation selects the corresponding BBS-FW operation mode through app_set_operation_mode(): Road selects Normal/Standard and Off-road selects Sport. The global Max Current remains unchanged at 25 A. The current, cadence and speed limits for each PAS level are already stored in the corresponding Normal or Sport assist table. BBS-FW then uses the selected table through its normal internal control logic. Because of that, the profile switch itself does not depend on several configuration requests being accepted by the motor communication state machine. For OEM Basic, Pedal and Throttle writes, the translation layer updates the BBS-FW configuration and reloads the relevant runtime settings.

Your question about what happens if a lower-level controller update is busy or fails is still valid, and I will review that path to confirm whether any of those updates need an explicit pending or retry mechanism. So far, I have not observed any failed or partially applied profile changes,
even after repeated Road/Off-road switching.

[dav0000000]

You are probably ok with the way you are doing it. Perhaps it was only the max amps update that could fail but if you are not updating that then all good.

[ericboucher225-png]

Thank you, that confirms my understanding. I will still keep an eye on the event log during repeated profile switching, but so far I have not observed any failed or partially applied changes.