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

[casainho]

for reference only this devices has also lev
wahoo elemnt roam

According to the docs also the wahoo elemnt bolt is supporting LEV (with firmware upgrade)

Please put that list on the documentation page, so it is easy for new users to find compatible displays.

 

[casainho]

@raw,

Do you have any news for the mobile app?

I started to put the firmware on the same project of SW102 and 860C displays - I call to the wireless firmware as "wireless_virtual_display_NRF52840" - and virtual because I hope to develop a real wireless display with the same board NRF52840.
Next step I hope to get the motor working with the wireless board but the configurations will be the default (no mobile app). But the next step and probably the last one, will be the communication with the mobile app - I will need it this week or on the next one, can you do it?

And you can simulate on your side the wireless board, because it will implement only for now, UART over Bluetooth. Maybe you can find any creative way to simulate or simple make the app to load local JSON files - this files could work as testing and documentation / definition on the interface to the mobile app.
There are only 2 packages that you need to define on the JSON:
- PERIODIC: data that is sent every 50ms, like current assist level, wheel speed, etc.
- CONFIGURATIONS: sent every time a user change leave the configurations / change configurations

You can find those on the firmware, at rt_send_tx_package(), as FRAME_TYPE_PERIODIC and FRAME_TYPE_CONFIGURATIONS.

 

[mallesepp]

Hello everyone, I can buy both versions of the nRF52840 on the same terms. Is one of the two preferred? The black or the blue version?

 

[casainho]

Hello everyone, I can buy both versions of the nRF52840 on the same terms. Is one of the two preferred? The black or the blue version?

I am developing with the Makerdiary version and I bough a few of them, so, I think is safe to you to buy the same. This board has only the disadvantage that may have slow shipping like 1 month, but, it is cheaper.

And whichever version you decide to buy, buy like 3 units, because you may damage 1 unit and I also want to implement the wireless buttons to connect both to our wireless board and simultaneous to the Garmin Edge, otherwise, you will need to buy the Garmin wireless remote control at least.

 

[raw]

@raw,

Do you have any news for the mobile app?

I started to put the firmware on the same project of SW102 and 860C displays - I call to the wireless firmware as "wireless_virtual_display_NRF52840" - and virtual because I hope to develop a real wireless display with the same board NRF52840.
Next step I hope to get the motor working with the wireless board but the configurations will be the default (no mobile app). But the next step and probably the last one, will be the communication with the mobile app - I will need it this week or on the next one, can you do it?

i think so, had some problem with the dongle disconnecting after 2 seconds but now i think that my dongles firmware is bugged because this also happens on the nrf connect app

And you can simulate on your side the wireless board, because it will implement only for now, UART over Bluetooth. Maybe you can find any creative way to simulate or simple make the app to load local JSON files - this files could work as testing and documentation / definition on the interface to the mobile app.
There are only 2 packages that you need to define on the JSON:
- PERIODIC: data that is sent every 50ms, like current assist level, wheel speed, etc.
- CONFIGURATIONS: sent every time a user change leave the configurations / change configurations

You can find those on the firmware, at rt_send_tx_package(), as FRAME_TYPE_PERIODIC and FRAME_TYPE_CONFIGURATIONS.

I don't really understand what you have in mind. do you plan to pass the uart packages to the app and have it act like a real display? that may be the easiest way to get some configuration to the dongle but i think it will cause a lot of work on the app side that gets thrown away later.

there are two (or one?) bluetooth characteristics that need to be defined;

* the read-only configuration structure as json string that i have described earlier that also contains the current config value. that one gets pulled when the user opens the config screen on the app. i could (and did) mock it on the app but only as example version.
* the write-only endpoint that accepts a json string just like the configuration structure with everything optional/stripped but the values and structure. this will be sent once the user closes the config screen or once for every setting changed.

i think both can also be one configuration characteristic that is read/writeable with different value written as it reads, right? then that would be the way to go.

assist level and other stuff should be a separate characteristics if no standard bluetooth service profile is available that can fill its purpose (like battery service). looking at the cycling speed and cadence profile, iirc it only returned rotations but not a ready to use speed value.

if you create a characteristic that can write and read a string of any length i can try to implement the json encoding/decoding and config writing. i was playing around with the nrf sdk for two evenings and finally gave up on defining my own characteristic

 

[casainho]

i think so, had some problem with the dongle disconnecting after 2 seconds but now i think that my dongles firmware is bugged because this also happens on the nrf connect app

You should use the STLinkV2 and Code Studio, for flash and debug. If you are not on Linux, I guess you will need a bit of work to make it working but then you can document it for the next developers.

I don't really understand what you have in mind. do you plan to pass the uart packages to the app and have it act like a real display?

My idea is to send commands forward and backwards, using only UART over Bluetooth - and these commands are JSON strings / files.

Only UART over Bluetooth because it is simple, equal to the communications done already between the TSDZ2, it is already implemented on SW102 firmware, I understand it and there are many examples. I think that must be even easier to find on Flutter. And will also be easier for simulation.

So, wireless board will keep sending the PERIODIC command at every 50ms and the mobile app will keep answering to that command. This command only sends data, no structure at all.

When the mobile app starts up or enters the configuration menu, will send the ASK CONFIGURATIONS structure command. Wireless board will answer with the CONFIGURATIONS structure.
After leaving the configurations menu, the mobile app will send the CONFIGURATIONS data command.

I think we should try to replicate what is already done on the display <-> TSDZ2 controller, but sending commands with JSON. Also the new thing here is the wireless board sending the configurations structure.

Do you agree?

 

[raw]

i think so, had some problem with the dongle disconnecting after 2 seconds but now i think that my dongles firmware is bugged because this also happens on the nrf connect app

You should use the STLinkV2 and Code Studio, for flash and debug. If you are not on Linux, I guess you will need a bit of work to make it working but then you can document it for the next developers.

I don't really understand what you have in mind. do you plan to pass the uart packages to the app and have it act like a real display?

My idea is to send commands forward and backwards, using only UART over Bluetooth - and these commands are JSON strings / files.

Only UART over Bluetooth because it is simple, equal to the communications done already between the TSDZ2, it is already implemented on SW102 firmware, I understand it and there are many examples. I think that must be even easier to find on Flutter. And will also be easier for simulation.

So, wireless board will keep sending the PERIODIC command at every 50ms and the mobile app will keep answering to that command. This command only sends data, no structure at all.

When the mobile app starts up or enters the configuration menu, will send the ASK CONFIGURATIONS structure command. Wireless board will answer with the CONFIGURATIONS structure.
After leaving the configurations menu, the mobile app will send the CONFIGURATIONS data command.

I think we should try to replicate what is already done on the display <-> TSDZ2 controller, but sending commands with JSON. Also the new thing here is the wireless board sending the configurations structure.

Do you agree?

i do not think this is a good idea because it will limit the functionality and flexibility that BLE offers to us.
With BLE there is no need for periodic packages; if the app wants to display the cadence, it subscribes to the characteristic and gets notified when it changes. if the user does not want to display the cadence, the app can ignore it and nothing gets submitted, meaning more power effectiveness and responsiveness of the communication.

BLE offers service discovery, so if a bike has a temperature sensor, we can discover and subscribe to it. same for the assist level which can be read and written from and to the same characteristic.
if you decide to build a DIY hardware button for assist level switching, you would have to just read/write that one characteristic (and ignore the rest), which will be easier and more power efficient than implementing the uart protocol on the button.

using raw uart over wireless would be a good idea if we would want to connect an 860c over bluetooth without changing anything else. but as we have to rethink and recreate a lot of stuff, we can do it the BLE way.

 

[raw]

for an example of an simple BLE service you can look at examples/ble_peripheral/ble_app_blinky and on ./components/ble/ble_services/ble_lbs/ble_lbs.c / .h
that is the most basic example i were able to find

 

[casainho]

for an example of an simple BLE service you can look at examples/ble_peripheral/ble_app_blinky and on ./components/ble/ble_services/ble_lbs/ble_lbs.c / .h
that is the most basic example i were able to find

Ok I will look at it. I don't expect it to be complex anyway and with a an example from Nordic, there will be no problem.

Do you think should be a characteristic for each single command?

 

[bobreece20]

I've also been looking into BLE services, I found the ble_app_blinky example difficult as I couldn't convert it easily to use softdevice s340 (and at that point didn't have STLink to debug why the dongle was crashing). The ble_app_hrs example was simple to convert to use s340 though, just requiring makefile changes.
Also I found https://github.com/NordicPlayground/nRF5x-custom-ble-service-tutorial which I think will help a lot but have not had chance to go through myself yet.

On a side note, I intend to start having a look at client code for the ANT+ LEV profile but with my focus being on cheap NRF52832 smartwatches as my display rather then the NRF52840 which might require some tweaking for the different softdevice but hopefully not too much. I've got a X9 Pro NRF52832 smartwatch arriving tomorrow (at an amazing total cost of £9) and will hopefully have a pinetime arriving in the next month or so. Found a cool resource for some of these smartwatches here: https://github.com/curtpw/nRF5x-device-reverse-engineering

 

[raw]

for an example of an simple BLE service you can look at examples/ble_peripheral/ble_app_blinky and on ./components/ble/ble_services/ble_lbs/ble_lbs.c / .h
that is the most basic example i were able to find

Ok I will look at it. I don't expect it to be complex anyway and with a an example from Nordic, there will be no problem.

Do you think should be a characteristic for each single command?

i have never designed a bluetooth profile but from what i read this is how its done. one characteristic for every variable that we want to read or change wireless. so one for the battery level, one for assist level, motor temperature, cadence, watts, human power and so on.

i found a guide about understanding and designing GATT profiles here. most important is to choose the right UUIDs, structure our data into a number of useful services and re-use existing standardized profiles whenever possible.

candidates for re-use are the battery service, cycling power and cycling speed and cadence profiles, but i think its only useful now if it does not add much overhead. the battery service should be easy and has the benefit that the battery value gets displayed on the bluetooth connection on some mobile phones
cycling power and stuff would make the dongle even more accessible to 3rd party bike computers, but maybe it takes some work to implement everything needed for a full profile. it may be easier to implement some custom services specific for our use-case.

here is my idea on the services:

• 
  Battery Service (SIG Profile)
  Cycling Info Service (motor/human power, cadence, distance, ...)
  Battery Info Service (Voltage, Resistance est)
  Assist Service (Assist level)
  Walk Assist Service (Enable trigger)
  Virtual Trottle Service (Enable trigger)
  Motor Temperatur Service (Motor Temperature if available)
  Street Mode Service (Enable trigger)
  Torque Sensor Service (torque value for calibration)

also - i now worked around my bluetooth connectivity problems. i was using the ble_app_hrs or ble_app_cscs (cycling speed and cadence) examples for testing my app. while im sure that it worked once, i was not able to get a stable connection to the dongle. i debugged my app like a monkey, but no way... if i connect, i get a bluetooth connection dialog and 1 or 3 seconds later a disconnect if i do not query some characteristic quick enough. i have tested it with the nrf connect app for android and it is the same! also, it asks for pairing on EVERY connect.... i have no idea. can you reproduce that problem with the ble_app_hrs example (which has a pca10059 makefile out of the box)?

i have now disabled the peer_manager_init function from the example... the android bluetooth connect dialog disappeared but i do not get disconnected anymore! now i can finally continue building the app.

 

[bobreece20]

can you reproduce that problem with the ble_app_hrs example (which has a pca10059 makefile out of the box)?

I wasn't noticing any issues with this example was nice and stable when I tried it but I was using softdevice s340 rather then the defaul that example comes with. And I'm also using pca10059 not the MDK dongle but I wouldn't of thought that would make a difference, although the button can be used for triggering bluetooth things which may be mapped to a different pin on MDK which may be why you were having issues, it may of been a floating pin triggering things.

See https://github.com/OpenSource-EBike-firmware/TSDZ2_wireless/tree/master/firmware/config for correct pin map for MDK dongle

 

[raw]

can you reproduce that problem with the ble_app_hrs example (which has a pca10059 makefile out of the box)?

I wasn't noticing any issues with this example was nice and stable when I tried it but I was using softdevice s340 rather then the defaul that example comes with. And I'm also using pca10059 not the MDK dongle but I wouldn't of thought that would make a difference, although the button can be used for triggering bluetooth things which may be mapped to a different pin on MDK which may be why you were having issues, it may of been a floating pin triggering things.

See https://github.com/OpenSource-EBike-firmware/TSDZ2_wireless/tree/master/firmware/config for correct pin map for MDK dongle

i have the blue nrf52840 dongle (pca10059)
maybe my dongle has something in memory that messes things up, but i have no idea how to reset it. i do not have a stlinkv2 connected yet.

 

[raw]

little update on the app: bluetooth discovery and connection view is working, the chosen device is saved, the connection state is displayed on the title bar of the homescreen and on startup the app searches and automatically connects to the dongle.

next step is to implement the battery display

 

[casainho]

but with my focus being on cheap NRF52832 smartwatches as my display

That seems to be a good idea! I think a watch can have a display of minimum size to work as a very small ebike display.

BUT I think there is a big risk on this project, that is Chinese are always changing the product hardware, I mean that you can invest to make documentation and develop the firmware and on next 6 months that watch model is no more on selling and a new other is... we have luck with TSDZ2 motor and the displays, I guess because they are not so cheap and because the bicycle OEM may demand stability on the products.
Maybe the Pinetime is a best bet on this issue of stability / availability to buy.

here is my idea on the services:

• 
  Battery Service (SIG Profile)
  Cycling Info Service (motor/human power, cadence, distance, ...)
  Battery Info Service (Voltage, Resistance est)
  Assist Service (Assist level)
  Walk Assist Service (Enable trigger)
  Virtual Trottle Service (Enable trigger)
  Motor Temperatur Service (Motor Temperature if available)
  Street Mode Service (Enable trigger)
  Torque Sensor Service (torque value for calibration)

Seems good.

 

[bobreece20]

That seems to be a good idea! I think a watch can have a display of minimum size to work as a very small ebike display.

BUT I think there is a big risk on this project, that is Chinese are always changing the product hardware, I mean that you can invest to make documentation and develop the firmware and on next 6 months that watch model is no more on selling and a new other is... we have luck with TSDZ2 motor and the displays, I guess because they are not so cheap and because the bicycle OEM may demand stability on the products.
Maybe the Pinetime is a best bet on this issue of stability / availability to buy.

Yeah I agree, I'm hoping to try build on something like lvgl graphics library so if the watches disappear another nrf52832 based smartwatch can be used and all that would be required is a new lcd driver. I think I can prove the concept if it works on both the pinetime and x9 pro

Update: Got the x9 pro watch open, debugged and got the graphics driver working, next step is getting lvgl working, although the x9 has a tiny 96x64px display and only one button so not the best platform for this, the pinetime will be a much better platform, hopefully I'll arrive soon

 

[bobreece20]

casainho, have you figured out a way to use NRF_LOG_INFO and receive the data via the SWD interface? It's not strictly needed as debug will do but it'd be nice to be able to log things out for more complicated applications

 

[casainho]

casainho, have you figured out a way to use NRF_LOG_INFO and receive the data via the SWD interface? It's not strictly needed as debug will do but it'd be nice to be able to log things out for more complicated applications

Once I tried on a STM32F103 and it was to slow / not usable, for some reason. On current hardware, maybe is faster to use the second UART or simple implement the UART over Bluetooth.
And I don't know / I usually do not use NRF_LOG_INFO.

About the watch, yes, I would say 1.2 is the minimum size and the size of a regular small watch. Nice progress you got!!

Pine seems nice with the touch screen. But it could work just like the Garmin Edge, where you can use the wireless remote to change the pages / information while you are riding. (I wish to make with 3D print a wireless remote with 6 buttons, 3 for motor control and other 3 for display control, having a small size for an ebike and not like that big ones we can buy for motorcycles).
For the watch to work as a display, I would make it with similar TSDZ2 information as 860C display + working with wireless remote buttons + show user heart rate when it is broadcast by wireless from a smart watch. Heart rate with zones information is really good for workout!! I do not expect other advanced features like navigation or any other fitness metrics. Well, maybe working as a secondary display on ANT+ profile, meaning mirror data that is on the user watch and that can be advanced fitness metrics.

 

[casainho]

@bobreece20, I received my BSS123 mosfets and I tested with both the resistor and without and it works on both cases, so, no resistor needed as expected. So, the schematic this schematic is correct - can you please update the mosfet referent to BSS123?

And I think is very important to share knowledge and technology for ebikes as OpenSource, so, I am very happy to see detailed notes on the schematic!! BUT, I also think all that details makes feel difficult / hard to DIY the board... for a final user version, I think the schematic should be simple as possible and without technical information, my reference are the Arduino https://fritzing.org schematics with colors on the wires:



@bobreece20, could you please make a very simplified schematic version (can be on Kicad) for the users that just want to follow a simple steps? if they want more information, we should link to the full notes schematic version. Also note that letters should be big to be easy to read and with good space between wires, again, to be easy to read.

 

[casainho]

I am a bit tired of trying to get UART working on the firmware, using the latest SDK of Nordik...

Meanwhile I tested using ANTSimulator (Windows only) to simulate a remote. I tested to send the command 0 and it simple switch the Edge pages.

My plan to chill out a bit, is to quick develop the firmware for having an Edge Remote, that let me change the Edge pages while I am riding. This firmware can after evolve to the ebike remote remote button:

ANTSimulator working as a Generic Remote:

And the configurations on my Edge for the Remote sensor:

The last option is "Show map":

 

[casainho]

Thanks @bobreece20 for updating the schematic and documentation (using a pull request).

As I want to make my own remote buttons, I started to design an enclosed on FreeCAD for reusing the VLCD5 remote buttons board and pad:

And the schematic draw by @bobreece20:

 

[bobreece20]

And the schematic draw by @bobreece20:

Although I have been updating the schema I cannot take claim for the original creation and that one in particular is not one I've touched, I believe it's from @Headless. It would be good if we can get it in github though so it can be updated if needed

 

[casainho]

I am being procrastinating on the firmware side. This week I decided to learn more about FreeCAD to design and 3D print my own remote buttons - but the VLCD5 remote buttons touch pad (the only missing part now) has some very specific curves in 3D that I am not being able to replicate on the design... current status:

And I also received the IPS 2 inches LCD I bought. Here is the LCD, battery, battery charger board and the wireless board with the microcontroller. The idea, that I don´t know if I will find time to do it, was to design and 3D print the enclosure for all that to make a cheap wireless display to show the same information as 860C display + user heart rate. The possibilities are customizing for a bigger or smaller battery as also wireless charging instead of using micro-usb:

 

[Waynemarlow]

Casainho, would it not be easier and lower work hours for you developers to simply extend the wiring of the keypad back along the frame to the small box that will have to house the other components. An all singing and dancing bluetooth keypad solution is the ideal, the not so ideal is having one very small electrical cable linking the box and keypad, but you will have time to go riding and we will all have the keypad ready and waiting to connect from our original kit.

 

[stek692003]

Rather than 3d printing a whole new remote enclosure you could just design a spacer for the current one. You could even possibly do this without a 3d printer.