TSDZ2 EBike wireless standard (like Specialized Turbo Levo) - OpenSource

[cavi]

I own both a mtb with a TZ with the open source and a specialized Turbo Levo. I need to make a clarification on your comparison to the Levo. Specialized has a phone app, Mission control, on it you can raise and lower each indiviual power level, it would have allowed you to set the motor to your preferences. On another note I have ran my levo with the Specialized app, and with a Garmin, and also with a phone app called Blevo. The Blevo app is the winner hands down, it gives all the data you could ever want , hooks to HR monitors, has maps, and tons more. Running the Levo with a Garmin requires you to have your phone also with you most times and to have Garmin connect at the same time. Not terrible practical.
Beyond this, I have a question, will this new program you are designing will it replace the current OSF that we are running?

 

[stancecoke]

Black PLA would be better

Black is boring!

you seem to have cut the usb connector from the PCB. In your design, the slot for the PCB is 33x 18 mm. This doesn't fit between the original bolt holes. I think we should place the board diagonally in the case to use the original holes.


regards
stancecoke

 

[casainho]

you seem to have cut the usb connector from the PCB. In your design, the slot for the PCB is 33x 18 mm. This doesn't fit between the original bolt holes. I think we should place the board diagonally in the case to use the original holes.

See the best you can do and do not forget to put some space for the wires. No problem to have on this phase, a not optimized small design.

I have a firmware version that builds for the wireless board, but minimal, just for communicate with the TSDZ2 firmware, init, use the default settings and change assist level on the GPS display (ANT+ LEV). I want to test it up to next weekend.

But I think I want to try a direct connection of remote, using Bluetooth, to the wireless board - this way I could ride without any GPS display at all, I would need just the wireless remote to turn on/off the system and change assist level.

AND, please note, I would like to try connect the brake sensors to the remote and send the brake signal by Bluetooth to the wireless board - can you consider a possible hole to pass through the 2 wires for brakes: GND and BRK signal as on this schematic??

 

[stancecoke]

See the best you can do and do not forget to put some space for the wires

I have now extended the base conically and selected a height of 10mm.

https://github.com/stancecoke/ebike_wireless_remote/blob/master/3d_design/VLCD5_LowerPart.FCStd

If we need less space on the bottom we can reduce width and hight again. This is a very first draft, we can still round the edges, make pockets for the button cell and the nRF52840 board, etc.

The spacer for the handle bar will be an extra part, that's easier for printing.

regards
stancecoke

 

[casainho]

I printed the new part, see the battery and board on the picture.

Some notes:
- would be nice if the holes could be larger in a way we could use the original screws - seems possible to me
- the height can be lower 1.5mm
- the conic shape is important in one side to be able to put the board inside but
not needed on the other sides, so reduce the size of the remote
- the remote must be water prof. There will be a bootloader and then firmware can be updated by Bluetooth, so, user will only need to open like once a year or two years.
This part should have a fit with the top part, se we can put some silicone glue that will make water prof.



More ideas

Why not design everything in only one block, like this that I tried - I guess than the top thin shell would need to be design and printed so we would not be limited by the original screws position - this block only would mean for sure water prof:




See the example of the 860C remote, which I think is the best I used. As there are always the brake handler, gears handler, etc, this remote can be on top of various handles and the buttons then be near the place of our hand fist -- this is really important!!

With current design this is hard as we have a big Z axis...

photo url

And here the gears shifter, has some space between it and the handle bar... the new VLCD5 remote with the thin metal part should fit well, using the thin space available:



Another idea could be this, put the board and battery in one side... maybe we can explore this in future:

 

[stancecoke]

This part should have a fit with the top part, se we can put some silicone glue that will make water prof.

I've added a flange to the upper edge, so we have a sufficient surface for glueing. It is a bit difficult to print because it is undercut. Two holes for the brake wires are added also.
The spacer for the handlebar is also ready. To fix it you can use a cable tie or a screwed clamp.

https://github.com/stancecoke/ebike_wireless_remote/tree/master/3d_design

This must be good enough for the moment. You can modify the design easily, as you can move the edges in the sketches by drag and drop.

regards
stancecoke

p.s. I've mounted it on the wrong side of the handlebar, obviously

 

[casainho]

This part should have a fit with the top part, se we can put some silicone glue that will make water prof.

I've added a flange to the upper edge, so we have a sufficient surface for glueing. It is a bit difficult to print because it is undercut. Two holes for the brake wires are added also.
The spacer for the handlebar is also ready. To fix it you can use a cable tie or a screwed clamp.

https://github.com/stancecoke/ebike_wireless_remote/tree/master/3d_design

This must be good enough for the moment. You can modify the design easily, as you can move the edges in the sketches by drag and drop.

regards
stancecoke

p.s. I've mounted it on the wrong side of the handlebar, obviously

Thanks for the help and the pull request!! Would be nice if you could keep improving it but I understand you are not an user / do not take value of the work you did, so, you may have no reason to do it. But others or myself, we can look at the sources your shared and improve and learn how to design - thanks!

 

[casainho]

Finally I have the wireless firmware working!!

I did a very first version that only changes the assist level - I change the assist level on the GPS display, using the touch screen.

On the wireless firmware I setup the default settings for my ebike, like the wheel size, assist level factors, etc. Once I turn on the system, it is ready to work and I just need to change the assist level.

Next step is to start working on the Android app so it will be possible to change the settings and I will also start adding step by step the features like correct wheel speed, battery voltage, motor current, etc.
Any suggestions for the Android app? - maybe I should fork the TSDZ2-ESP32 Android app??: https://github.com/TSDZ2-ESP32/TSDZ2-ESP32-Main

And I also need to quick build the Nordic Bluetooth bootloader, as I will be testing the firmware on my ebike and I do not want to keep flashing the firmware with the STlinkV2.

And I think I will also add a switch to the wireless board, so it will work just like the Specialized ebikes, were we turn on/off the system on the battery pack (on our case, will be on the wireless board that will be installed near the battery case or in any other place we desire).

Here a picture of the wireless board connected to the TSDZ2 LCD connector:

 

[thineight]

Casainho, due to my limits in electronics I do not fully understand the technical details, but I do follow the logic in this interesting thread.

Do we have any chance to wire the brake sensors directly on the motor instead of relying on a wireless signal?
The bafang Y splitter we used to wire the sensors in previous installations (I think the schematic is still in the wiki) can be connected directly to the motor for a direct signal, correct?

If the above is not clear enough I can try to make a tough sketch.
Thanks

 

[casainho]

Do we have any chance to wire the brake sensors directly on the motor instead of relying on a wireless signal?

I would like to explore the possibility to go fully wireless, using standards:
- wireless display (ANT+ LEV standard)
- wireless remote (ANT+ buttons and Bluetooth buttons)
- wireless brake (Bluetooth fast buttons - there should be fast reaction as this is used for game pads that have no noticeable delay)

Going fully wireless means clean and more robust system because there are no wires to brake or connectors to fail.

Wireless has the issue of battery, that, if it fails it could render useless the EBike. But that will not happen because it can work without display, brake sensors and the remote - user will be able to use his phone or watch to change the assist level, and only if needed because if user keep using the same assist level, then, it will not need anything at all.

But yes, brake sensors can be connected as regular. The wireless signal for the brake sensors will end as a regular brake sensor signal that will connect as regular to the TSDZ2 LCD connector.

 

[rananna]

Do we have any chance to wire the brake sensors directly on the motor instead of relying on a wireless signal?

I would like to explore the possibility to go fully wireless, using standards:
- wireless display (ANT+ LEV standard)
- wireless remote (ANT+ buttons and Bluetooth buttons)
- wireless brake (Bluetooth fast buttons - there should be fast reaction as this is used for game pads that have no noticeable delay)

Going fully wireless means clean and more robust system because there are no wires to brake or connectors to fail.

Wireless has the issue of battery, that, if it fails it could render useless the EBike. But that will not happen because it can work without display, brake sensors and the remote - user will be able to use his phone or watch to change the assist level, and only if needed because if user keep using the same assist level, then, it will not need anything at all.

But yes, brake sensors can be connected as regular. The wireless signal for the brake sensors will end as a regular brake sensor signal that will connect as regular to the TSDZ2 LCD connector.

I have been trying to develop an alternative wireless remote using only ANT+ (no bluetooth) with ANT+ LEV and CONTROL slave profiles that builds upon your work with the CONTROLS remote.

The following features have been implemented:
1. Dual CONTROLS and LEV ANT slave support
2. "Long Press" support
3. LEV slave- allows for assist level (and other page 16 info) to be sent to the LEV master (the ebike motor). Long press of ENTER could be used to turn motor on/off and long press of STANDBY could be used for lights on/off short press of PLUS increases assist, short press of MINUS decreases assist.
4. CONTROL slave. Works as you designed to implement page control. Long press of PLUS for pageup, long press of minus for PAGEDOWN.


Notes:
1. I am not a professional programmer, so apologies for any sloppy coding.
2. I used SimulANT for testing with simultaneous LEV DEVICE and GENERIC CONTROLLABLE DEVICE profiles and the remote seems to work as I describe above.
2. Ant+ has the advantage that both the display and the LEV enabled remote can operate at the same time.
3. I also found that the button timers m_antplus_controls_send and m_lev_send work best with no delay.

here is the repository, let me know what you think:
https://github.com/rananna/ebike-LEV-and-CTRL-remote

 

[casainho]

I have been trying to develop an alternative wireless remote using only ANT+ (no bluetooth) with ANT+ LEV and CONTROL slave profiles that builds upon your work with the CONTROLS remote.

The following features have been implemented:
1. Dual CONTROLS and LEV ANT slave support
2. "Long Press" support
3. LEV slave- allows for assist level (and other page 16 info) to be sent to the LEV master (the ebike motor). Long press of ENTER could be used to turn motor on/off and long press of STANDBY could be used for lights on/off short press of PLUS increases assist, short press of MINUS decreases assist.
4. CONTROL slave. Works as you designed to implement page control. Long press of PLUS for pageup, long press of minus for PAGEDOWN.


Notes:
1. I am not a professional programmer, so apologies for any sloppy coding.
2. I used SimulANT for testing with simultaneous LEV DEVICE and GENERIC CONTROLLABLE DEVICE profiles and the remote seems to work as I describe above.
2. Ant+ has the advantage that both the display and the LEV enabled remote can operate at the same time.
3. I also found that the button timers m_antplus_controls_send and m_lev_send work best with no delay.

here is the repository, let me know what you think:
https://github.com/rananna/ebike-LEV-and-CTRL-remote

Good work!! If you look on web, there is almost no OpenSource projects for ANT+ / cycling devices.

But, I did not understand how the final result works - can you please say how do you intend to use it? as an user, how will you use all this?

 

[rananna]

I was hoping you would find it useful for your tsdz2 wireless project.
This remote with ANT+ LEV AND CONTROLS is able to:
1. Change assist levels
2.change page view on the display
3. Control the lights
4. Turn power on/off
5. Send brake signal to motor (ANT appears to be fast enough to control the brakes, but this remains to be tested. ( Bluetooth may still be required for speed or reliability.)

 

[casainho]

I was hoping you would find it useful for your tsdz2 wireless project.
This remote with ANT+ LEV AND CONTROLS is able to:
1. Change assist levels
2. change page view on the display
3. Control the lights
4. Turn power on/off
5. Send brake signal to motor (ANT appears to be fast enough to control the brakes, but this remains to be tested. ( Bluetooth may still be required for speed or reliability.)

Well, that seems everything I need!!

But, I tested with my Garmin Edge 830 and the remote control that implements the ANT+ CONTROLS and it only change page view on the display. Do you think your implementation will work on the Garmin Edge, for the rest?

I am confuse, the 1., 3. and 4. must be a connection to the LEV display or to the TSDZ2 wireless board?

 

[rananna]

The ANT+ LEV slave connection in my remote control is to the ANT+ LEV master device you implemented for the nrf52840 board connected to the motor, not the EDGE display. This allows my remote to implement 1,3,4,and 5 by sending page 16 to the motor.

The GARMIN edge 830 display implements another ANT+ LEV slave connection to the same nrf52840 board in the motor. The ANT protocol allows multiple slave connections, which is an advantage over bluetooth.
You can display motor information on the EDGE, a garmin watch, (with the ebike app) or any other ant+ LEV enabled display devices at the same time.
THE EDGE 830 is sending page 16 info back to your motor using touch control on the display. I am doing the same thing with my remote using the plus and minus buttons. The remote is acting like a edge 830 ANT+ LEV device with no display capabilities


All garmin bike computers support the Ant+ control profile for page turns, but not all support ANT+ LEV . To my knowledge, no other bike computer supports ANT+ CONTROL profile, so page turns are not possible for non garmin devices.
I personally have both garmin 530 and wahoo bolt devices. Both support ANT+ LEV for display, not only the 530 supports ANT+ CONTROLS.



So, in summary, my remote is talking to both the motor and the garmin edge bike computers at the same time, allowing for page control on the edge and motor control on the ebike

 

[casainho]

The ANT+ LEV slave connection in my remote control is to the ANT+ LEV master device you implemented for the nrf52840 board connected to the motor, not the EDGE display. This allows my remote to implement 1,3,4,and 5 by sending page 16 to the motor.

The GARMIN edge 830 display implements another ANT+ LEV slave connection to the same nrf52840 board in the motor. The ANT protocol allows multiple slave connections, which is an advantage over bluetooth.
You can display motor information on the EDGE, a garmin watch, (with the ebike app) or any other ant+ LEV enabled display devices at the same time.
THE EDGE 830 is sending page 16 info back to your motor using touch control on the display. I am doing the same thing with my remote using the plus and minus buttons. The remote is acting like a edge 830 ANT+ LEV device with no display capabilities


All garmin bike computers support the Ant+ control profile for page turns, but not all support ANT+ LEV . To my knowledge, no other bike computer supports ANT+ CONTROL profile, so page turns are not possible for non garmin devices.
I personally have both garmin 530 and wahoo bolt devices. Both support ANT+ LEV for display, not only the 530 supports ANT+ CONTROLS.



So, in summary, my remote is talking to both the motor and the garmin edge bike computers at the same time, allowing for page control on the edge and motor control on the ebike

Clever and again great job!!

I still have one question: how to pair ANT+ LEV remote? Did you already though on this? What do you suggest?

 

[rananna]

I still have one question: how to pair ANT+ LEV remote? Did you already though on this? What do you suggest?

My remote is set up with wild card pairing, that is it will pair with any ant+ LEV MASTER that is in range. A single button press will wake up the remote and initiate pairing.
Once paired, it will not pair with a second ebike, as you might expect.
I tested pairing operation and it seems to work well.

Please try it with your motor and edge 830 and let me know how it works out

 

[rananna]

Another thought on pairing:
If we set up a fixed device number on the LEV MASTER on the motor, we could set the LEV SLAVE remote to look for only this unique device number. This would speed up connection time, and only allow the remote to pair with your TSDZ2 motor, not other ANT+ LEV enabled e bikes.
This would not affect pairing on the edge 830 as it would simply store this device number once it is paired.

 

[casainho]

Another thought on pairing:
If we set up a fixed device number on the LEV MASTER on the motor, we could set the LEV SLAVE remote to look for only this unique device number. This would speed up connection time, and only allow the remote to pair with your TSDZ2 motor, not other ANT+ LEV enabled e bikes.
This would not affect pairing on the edge 830 as it would simply store this device number once it is paired.

I have 4 bicycles so I should avoid the situation of wrong pairing.

The ANT device ID, there must be a way for the user to change it. Would be nice if could be like a change on some file... ok on a HEX file but in the end we will have the ZIP file for OTA update that user will not be able to change due to checks on the inside file .DAT that his the hash of all package. The idea of need to build the firmware is out of question for the user.

Maybe the TSDZ2 wireless board could be configured by Bluetooth, and user could defined the ANT device ID on the mobile app. Anyway, this board will anyway be configured by Bluetooth.

Another question: what about the power usage? because my current code seems to be very good on this.

 

[rananna]

Another thought on pairing:
If we set up a fixed device number on the LEV MASTER on the motor, we could set the LEV SLAVE remote to look for only this unique device number. This would speed up connection time, and only allow the remote to pair with your TSDZ2 motor, not other ANT+ LEV enabled e bikes.
This would not affect pairing on the edge 830 as it would simply store this device number once it is paired.

I have 4 bicycles so I should avoid the situation of wrong pairing.

The ANT device ID, there must be a way for the user to change it. Would be nice if could be like a change on some file... ok on a HEX file but in the end we will have the ZIP file for OTA update that user will not be able to change due to checks on the inside file .DAT that his the hash of all package. The idea of need to build the firmware is out of question for the user.

Maybe the TSDZ2 wireless board could be configured by Bluetooth, and user could defined the ANT device ID on the mobile app. Anyway, this board will anyway be configured by Bluetooth.

Another question: what about the power usage? because my current code seems to be very good on this.

Well, the way I see it there are 3 possible options:
1. Leave the coding with wild card pairing, and let the remote find the nearest LEV device. For people with one Ebike this would work fine unless they startup near someone else who has an ANT LEV enabled ebike. Not an ideal situation, so I would not recommend this option.
2. Implement bluetooth ant device configuration for the remote. This seems to be overkill to me as there is only one thing to configure.
3. Prepare seversl remote firmware files in the repository for people to use. Ie: remote52.hex,remote53.hex,remote54.hex, ...etc.(51-54 is the ANT Device numbers)
We could easily create as many device numbers we think we need. You have 4 ebikes, so how about supporting 10 matching firmware files? We would be unlikely to update the remote very often once it is working.
Of course, you would set the matching ANT Device number to be user configurable with the android bluetooth app for the motor to match the remote firmware.

I would recommend option 3.

As far as power mgt is concerned, I copied the code you had in your remote to implement the 1 hour timer that calls the shutdown routine to put the nrf52840 in low power mode if a button has not been pressed. So it should work the same.

 

[casainho]

Well, the way I see it there are 3 possible options:
1. Leave the coding with wild card pairing, and let the remote find the nearest LEV device. For people with one Ebike this would work fine unless they startup near someone else who has an ANT LEV enabled ebike. Not an ideal situation, so I would not recommend this option.
2. Implement bluetooth ant device configuration for the remote. This seems to be overkill to me as there is only one thing to configure.
3. Prepare seversl remote firmware files in the repository for people to use. Ie: remote52.hex,remote53.hex,remote54.hex, ...etc.(51-54 is the ANT Device numbers)
We could easily create as many device numbers we think we need. You have 4 ebikes, so how about supporting 10 matching firmware files? We would be unlikely to update the remote very often once it is working.
Of course, you would set the matching ANT Device number to be user configurable with the android bluetooth app for the motor to match the remote firmware.

I would recommend option 3.

Not considering pairing, user need to configure each device ID, right? because I can´t have 4 remotes with the same ID nor 4 motors with the same ID -- right? if so, we need a way to easily configure for every device.

Then, in the case of the remotes, user need the extra configuration ID for pairing.

So, that would be to complex for user to understand on name of the files, to much files!!

So, I think we should implement Bluetooth specifically for configuration of this IDs and we will not need to develop an app, user can just use the NRFConnect app from Nordic to read or change the IDs, like this:

On the case of the remote, it MUST use very low power as possible. Bluetooth should not be enabled by default but maybe all buttons pressed at startup should enable Bluetooth for like 2 minutes window time.

Do you think this are good ideas?

If we agree, I would like to ask you for a pull request of your implementation - and for now keep the wild card. Next we could add the Bluetooth.

 

[rananna]

Well, the way I see it there are 3 possible options:
1. Leave the coding with wild card pairing, and let the remote find the nearest LEV device. For people with one Ebike this would work fine unless they startup near someone else who has an ANT LEV enabled ebike. Not an ideal situation, so I would not recommend this option.
2. Implement bluetooth ant device configuration for the remote. This seems to be overkill to me as there is only one thing to configure.
3. Prepare seversl remote firmware files in the repository for people to use. Ie: remote52.hex,remote53.hex,remote54.hex, ...etc.(51-54 is the ANT Device numbers)
We could easily create as many device numbers we think we need. You have 4 ebikes, so how about supporting 10 matching firmware files? We would be unlikely to update the remote very often once it is working.
Of course, you would set the matching ANT Device number to be user configurable with the android bluetooth app for the motor to match the remote firmware.

I would recommend option 3.

Not considering pairing, user need to configure each device ID, right? because I can´t have 4 remotes with the same ID nor 4 motors with the same ID -- right? if so, we need a way to easily configure for every device.

Then, in the case of the remotes, user need the extra configuration ID for pairing.

So, that would be to complex for user to understand on name of the files, to much files!!

So, I think we should implement Bluetooth specifically for configuration of this IDs and we will not need to develop an app, user can just use the NRFConnect app from Nordic to read or change the IDs, like this:

On the case of the remote, it MUST use very low power as possible. Bluetooth should not be enabled by default but maybe all buttons pressed at startup should enable Bluetooth for like 2 minutes window time.

Do you think this are good ideas?

If we agree, I would like to ask you for a pull request of your implementation - and for now keep the wild card. Next we could add the Bluetooth.

Yes, we need to set up every motor with a user configurable unique device number using the bluetooth android app.
in your example each of the 4 motors would be set up with different device numbers. The required 4 remotes would have to be set up with the exact SAME device numbers as the motor device numbers to ensure unique pairing to the right motor. (They cannot have DIFFERENT device numbers or they will never find the motor)
See fig 1 of the attached pdf to see how a unique device number will identify a specific master device to a remote device.

So, if we limited the motor configuration to a small number of allowable device numbers, (maybe the user chooses from a drop down list) there would only be a relatively small number of remote firmware files that would be identified by these allowable device numbers to choose from. (Like 10 hex files in my previous example) This would not be unmanageable in my opinion.

We could use the nrfconnect app as you suggest to program the device number in the remote firmware, but this is a lot more user work than simply choosing one of the10 prepared firmware files to flash to the remote.

Anyway, we can figure these details out later.

I will setup the github pull request for you this weekend.

 

[rananna]

I just added the pull request for the CONTROLS+LEV remote.
let me know how you make out.

 

[casainho]

I just added the pull request for the CONTROLS+LEV remote.
let me know how you make out.

Thanks. I accepted the pull request. I hope to test tomorrow night or on next day.

I am start to look at the examples of ANT+ and BLE, it seems very modular, easy to add to our current project.

I will start to add that option / characteristic for change the ANT device ID, as I will have to learn anyway.
I also need to understand how the Android app is structured in terms of this same characteristics as I need to have the configurations on the mobile app working.

 

[rananna]

I just added the pull request for the CONTROLS+LEV remote.
let me know how you make out.

Thanks. I accepted the pull request. I hope to test tomorrow night or on next day.

I am start to look at the examples of ANT+ and BLE, it seems very modular, easy to add to our current project.

I will start to add that option / characteristic for change the ANT device ID, as I will have to learn anyway.
I also need to understand how the Android app is structured in terms of this same characteristics as I need to have the configurations on the mobile app working.

Makes sense.
I am really looking forward to implementing a clean wireless ebike using your firmware. Great project!