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

[casainho]

i finally had 2 hours time to play with my dongle. sadly i did not get very far as i had problems flashing the firmware.

What I would do:
- make a copy of TSDZ2 firmware folder and change the Makefile or the needed files to build for the NRF52840
- make a very simple main loop code to control the RGB led on the board
- flash and debug using the STLinkV2, just like on the TSDZ2

Using STLinkV2 is very fast for development, for flashing the firmware! And debug!

I would not use the Arduino but the Nordic SDK example code that implements both Bluetooth and Heart Rate sensor on ANT+. We do not need much more than this: control the motor as if we are a display; implement ANT+ LEV display and send and receive Bluetooth UART data to mobile app. All of this is already done on SW102 except the ANT+ LEV.

For the wireless display, I would reuse the SW102 code, because it has the custom fields code.

 

[casainho]

High level languages for fast development of UI display

I was looking for high level languages available for NRF5840, because this is very popular and have 1Mbytes of flash memory, which is a lot hence the high level languages available.

The potential advantages I see comparing to use current SW102 display firmware:
- faster developing and more advanced graphics (I hope there is a graphical framework)
- faster developing

I am not an high level developer so this is new to me. Maybe there are more developers here more experienced that can help.

Python

Seems there is no support for ANT+. There are guides about creating C code module for Pyhton so I guess it could be a way to have ANT+ implemented using the example from Nordic.





Javascript

Seems there is no support for ANT+...



Go

Article for embedded Go using our microcontroller:

 

[raw]

While it sounds like fun to build our own display, i do not think it is worth the effort. i expect the "cheap" 10€ display to also be cheap quality which manifests in low resolution and readability in direct sunlight. also, while it is cheap on the hardware costs, it requires a lot of work to make the display (3d printing, soldering and so on).

i also remember your statement in the 860c thread that making the display a full bike computer solution would mean a lot of work for a single hardware solution and it would be better to use an existing bike computer.

in my opinion, it would be better to make an smartphone app that works over bluetooth as bike computer and configuration interface, because

• Smartphones are cheap and getting cheaper every year. Most people already own one so the cost would be just an phone holder and maybe a waterproof case. Most people use their bike as tracking/street bike and not for MTB. but even MTB user can use old low-value phones, ebay is full of old phones with some scratches on the display. there are also brand new phones for <50€ example1, example2, a lot more on ebay search. so if you damage one you can always and quickly get a cheap replacement. I have tested 3 phones in this price class last year and was impressed by what you get for the money.
• Developing for android or even better multi-plattform would be more future-proof as android hardware is manufactured independently. if we stick to one hardware it may be abadoned by the manufacturer sooner or later. i think it is safe to say that we will still have android phones in 10 years. also supporting multiple boards/screens means a lot of work which is already covered by android (adapting to different screen resulutions, cpu models and so on).
• I think many DIY ebike batteries already come with a usb charging port, so power should be no problem. getting an 60v-to-USB-Power adapter should be also pretty standard.
• there are already multiple bluetooth bike buttons in the <20€ price range. i expect their batteries to last for years, but if you are afraid you can get yourself a replacement battery or a full replacement button just in case. also with smartphone, you have a touchscreen as fallback. the button can directly connect to the dongle so if your phone breaks, you will still be able to control the motor.
• there are already open source bike computer solutions out there that we could adapt. BoD/bikey, inv2004/cycle-computer (supports ANT+ somehow) and more.
• even if we start with a new app (for cross-plattform and a clean codebase), development on smartphones is more easy, quicker and has more possibilities as smartphones come with a lot of sensors and connectivity. also a very important fact is that we can use many libraries that make progressing easier like the osm android SDK and gadgetbridge and also a full-featured emulator with debugging.
• the ANT stuff can be handled by our dongle and passed to the smartphone.

i understand that you are not familiar with high-level or app programming and this is ok. i have actually only some limited android/rpi embedded experience while being a high-level developer for 15 years. maybe we should focus an what we can do best, meaning you could do the dongle and i could take care of the mobile app. if i try to do the dongle, i will need a lot time to only get the basic stuff going. let me know if you think we can split the work up like this, otherwise i will continue to try to get the dongle working.

iam on the nRF52840 ANT boat because i think it will attract more users and more developers than going with the ESP32 even if i do not plan to use any ANT devices. i also do not think that forking brings us far. someone forks, puts a lot of work in it but abandons the project one year later, which means that all his work is "lost" if it did not get merged into the upstream project.
we all will have less work and more features if we are all working on the same codebase, even if that means we need to accept features that we are not planning to use personally.

if you have not yet, you should register an account on https://www.thisisant.com/. downloading the S340 softdevice requires an account that will be manually approved which may take one or two business days.

also inter-operating with other ANT+ devices requires an ant network key which is also only available through this account (you need to upgrade it to adopter status after registration, but that is free). BUT we are not allowed to redistribute this network key or the S340 Softdevice, which means that every developer would have to sign up there and accept their terms. Their terms also state that we are not allowed to "advertise" our solution as ANT+ compatible until it gets certified by Garmin - which means we may choose our words wisely when writing the features list.

for that reasons it makes sense to me to have two makefiles or some switches for the dongle, one that goes with the ANT+ compatible S340 and one with the redistributable S140.

 

[casainho]

While it sounds like fun to build our own display, i do not think it is worth the effort. i expect the "cheap" 10€ display to also be cheap quality which manifests in low resolution and readability in direct sunlight. also, while it is cheap on the hardware costs, it requires a lot of work to make the display (3d printing, soldering and so on).

i also remember your statement in the 860c thread that making the display a full bike computer solution would mean a lot of work for a single hardware solution and it would be better to use an existing bike computer.

I will see how that display works but it says it is IPS. And the Adafruit also sells the same display for $20 so I hope it has some good quality.
Yes, a lot of work and you are right. But when I look back about 860C, it has great display quality and solid construction but it is also big, fragile in the case of a fall, impossible to repair, expensive and already limited in the features - for me it is a dead end as a project.

I guess I am now looking more for a DIY and not thinking so much on the others.

in my opinion, it would be better to make an smartphone app that works over bluetooth as bike computer and configuration interface, because

I fully agree on Android smartphones but I don't have knowledge to develop that project. Also, I bought a 50€ Android for navigation and installed OSMAND - while it runs ok, this ultra cheap smartphone is a bit big, has quite bad screen quality to be readable on sunlight and also low battery - I am with it always connected to 860C USB charging port. The solution I have is the one you are suggesting and I am no so much happy with it although I think will be ok for others. And the mobile phone apps, I guess they do not support advanced fitness metrics like Garmin devices and others have - and I want to get this, that is one of my main motivations.

i understand that you are not familiar with high-level or app programming and this is ok. i have actually only some limited android/rpi embedded experience while being a high-level developer for 15 years. maybe we should focus an what we can do best, meaning you could do the dongle and i could take care of the mobile app. if i try to do the dongle, i will need a lot time to only get the basic stuff going. let me know if you think we can split the work up like this, otherwise i will continue to try to get the dongle working.

I will do the dongle, I have some professional experience with NRF52.

About the buttons, I dream for myself to be have customized buttons and while it may have high value for me, maybe not for others. I am ok for Bluetooth buttons. Even when DIY with this board, being Bluetooth or ANT+ is just firmware.

And so I would like to know what are the most advanced/distinct features do you expect to implement on the mobile app side? What are your expectations?

iam on the nRF52840 ANT boat because i think it will attract more users and more developers than going with the ESP32 even if i do not plan to use any ANT devices. i also do not think that forking brings us far. someone forks, puts a lot of work in it but abandons the project one year later, which means that all his work is "lost" if it did not get merged into the upstream project.
we all will have less work and more features if we are all working on the same codebase, even if that means we need to accept features that we are not planning to use personally.

Ok and note that ESP32 can not implement wireless ebike standard, only NRF52 - I think this is very important!

if you have not yet, you should register an account on https://www.thisisant.com/. downloading the S340 softdevice requires an account that will be manually approved which may take one or two business days.

also inter-operating with other ANT+ devices requires an ant network key which is also only available through this account (you need to upgrade it to adopter status after registration, but that is free). BUT we are not allowed to redistribute this network key or the S340 Softdevice, which means that every developer would have to sign up there and accept their terms. Their terms also state that we are not allowed to "advertise" our solution as ANT+ compatible until it gets certified by Garmin - which means we may choose our words wisely when writing the features list.

I am already an "adopter" and I am trying on an old board I have here with NRF52832.

Note that for Bluetooth we can not also refer or use the logo unless we spend the same a lot of money on certification and fees.
[/quote]

 

[raw]

in my opinion, it would be better to make an smartphone app that works over bluetooth as bike computer and configuration interface, because

I fully agree on Android smartphones but I don't have knowledge to develop that project. Also, I bought a 50€ Android for navigation and installed OSMAND - while it runs ok, this ultra cheap smartphone is a bit big, has quite bad screen quality to be readable on sunlight and also low battery - I am with it always connected to 860C USB charging port. The solution I have is the one you are suggesting and I am no so much happy with it although I think will be ok for others.

yes, cheap phones will not have the brightest screens. if there is nothing comparable in the 50€ class to the 860c brightess now it may come on some years. there are a lot phones to choose from, so i think everyone will find one that fits his requirements and price range.
and for battery - yes even top smartphones do not last long when the screen is turned on at max brightness, so a power supply is required for most cases.

And so I would like to know what are the most advanced/distinct features do you expect to implement on the mobile app side? What are your expectations?

• make my bike cooler. if something has bluetooth and an mobile app it is cooler by definition
• make the 860C display optional so i do not need to buy these ones for the other bikes i plan to build (while keeping the features)
• having a mobile app would speed up development of nice features like better statistics, longer history and sharing the stats with other applications and online services.
• make the world better... (yes, i have a vision) i think the open source ebike firmware can be the start of something big in the future... something like linux was for operating systems and mysql was for databases... having an open source ebike that will have more features and support than any commercial bike will have. if you build a bike now, you can use it for 10 or 20 years. while this is not a long time for a bicycle, it is a long time for a product and a company that can go bankrupt at any point and for multiple reasons. (me is looking at the pebble steel on my arm). yes the project is currently limited to the TSDZ2, but i think it is possible that the firmware and the dongle will be ported to bafang and other motors at one point. these ports will then be able to use the same dongle and mobile app (hopefully not as fork but as part of one codebase).

i have not finally decided, but this is what i have in mind for version 1 of the app:

• configuration of the motor settings
• a main screen with similar in informations and features as the current 850/860
• maximum portability (android/iphone at least)
• possibility to use the main screen as application overlay (similar to google maps or youtube in background mode)

especially with the overlay feature, you can use any navigation app you like and still have a display of speed, assist level and more on screen.

one thing i currently think about is the communication protocol; my idea is to not just send the uart package over bluetooth but to create a new easier to understand/debug and more portable and extensible protocol based on JSON. afaik currently the display and controller firmware needs to match very closely because they need to have the same definition of how the binary uart data is parsed into its struct, even on data type level. while this is fine for cable-connected hardware, for wireless stuff it would be good if everything works even if the versions do not match closely. i.e. if a want to ride a friends bike with older firmware using my phones app.

maintaining backward compatibility in a structured data format like JSON is easier because you can add new fields at any position without breaking old stuff.

i will take a look at the esp32 project how they have solved it.

im also currently not sure if we stick to BLE or if we should support bluetooth4 (for the old phone use-case). on bluetooth 4 we would exchange packets over a serial channel while in BLE we can exchange data by defining characteristics endpoints.

 

[john61ct]

please do not discourage the real Makers and tinkerers, for they are what move us forward!

 

[raw]

please do not discourage the real Makers and tinkerers, for they are what move us forward!

what you are referring to?

 

[casainho]

yes, cheap phones will not have the brightest screens. if there is nothing comparable in the 50€ class to the 860c brightess now it may come on some years. there are a lot phones to choose from, so i think everyone will find one that fits his requirements and price range.
and for battery - yes even top smartphones do not last long when the screen is turned on at max brightness, so a power supply is required for most cases.

And with Android, I guess is possible to build DIY, a specific display to run Android and the Ebike app.

For me is really important the fitness metrics of Firstbeat/Garmin, so, I have no choice to buy and use a Garmin device. And so, there is no point to have big expectations for the mobile app on phone or display.

But when I ride on the city, I would like to have discrete, easy removable, small and cheap display. That would be Garmin Edge 130 with a 1.8'' display:

But that model does not support ebikes nor custom apps.

So my plan is to make a display similar to Edge 130 in size but with my firmware based on 860C/SW102, with customized fields. And additionally to 860C/SW102, I want it to be ANT+ ebike display, automatically connect to heart rate sensors and show the value on a field. The heart rate will be from my Garmin watch and the display will be bale to work as ANT+ extended display of my watch, so my watch does the fitness metrics and I can see on the display in real time + TSDZ2 data + send TSDZ2 data as cycling sensor to the watch.

I do not expect to ever implement navigation and advanced fitness metrics.

And so I would like to know what are the most advanced/distinct features do you expect to implement on the mobile app side? What are your expectations?

• 1. make my bike cooler. if something has bluetooth and an mobile app it is cooler by definition
• 2. make the 860C display optional so i do not need to buy these ones for the other bikes i plan to build (while keeping the features)
• 3. having a mobile app would speed up development of nice features like better statistics, longer history and sharing the stats with other applications and online services.
• 4. make the world better... (yes, i have a vision) i think the open source ebike firmware can be the start of something big in the future... something like linux was for operating systems and mysql was for databases... having an open source ebike that will have more features and support than any commercial bike will have. if you build a bike now, you can use it for 10 or 20 years. while this is not a long time for a bicycle, it is a long time for a product and a company that can go bankrupt at any point and for multiple reasons. (me is looking at the pebble steel on my arm). yes the project is currently limited to the TSDZ2, but i think it is possible that the firmware and the dongle will be ported to bafang and other motors at one point. these ports will then be able to use the same dongle and mobile app (hopefully not as fork but as part of one codebase).

2. yes, that NRF52840 board will be able to implement everything that is on current displays, + giving BLE and ANT+.

4. Would be nice if there was a standard for ebike on Bluetooth, so any mobile app could connect to every ebike.
I also owned a Pebble, Basis Peak, etc. I think Garmin are the best near of Pebble. Although Fitbit bought Pebble, their new product Fitbit Versa that I also own, did follow Apple watch as almost everyone, with displays with a lot of colors but not always on. Garmin is the only one that kept the always on displays, long battery, less beauty but very strong on the advanced fitness metrics - the display is not everything.

i have not finally decided, but this is what i have in mind for version 1 of the app:

• configuration of the motor settings
• a main screen with similar in informations and features as the current 850/860
• maximum portability (android/iphone at least)
• possibility to use the main screen as application overlay (similar to google maps or youtube in background mode)

The last point is nice and could be optional for a first version, the other points are the minimum.

one thing i currently think about is the communication protocol; my idea is to not just send the uart package over bluetooth but to create a new easier to understand/debug and more portable and extensible protocol based on JSON. afaik currently the display and controller firmware needs to match very closely because they need to have the same definition of how the binary uart data is parsed into its struct, even on data type level. while this is fine for cable-connected hardware, for wireless stuff it would be good if everything works even if the versions do not match closely. i.e. if a want to ride a friends bike with older firmware using my phones app.

maintaining backward compatibility in a structured data format like JSON is easier because you can add new fields at any position without breaking old stuff.

Seems important. This microcontroller should have enough processing power to do that every 50 ms, that is the period of every communication package to/from the TSDZ2.

im also currently not sure if we stick to BLE or if we should support bluetooth4 (for the old phone use-case). on bluetooth 4 we would exchange packets over a serial channel while in BLE we can exchange data by defining characteristics endpoints.

I have no idea about this... and on NRF52840 board, I will try to use the sample code of Bluetooth firmware they provide. On SW102 is BLE because I could not use most of the terminal UART apps available until I found that the issue was that only new apps with support to BLE would work. So, if possible, we should go with BLE.

 

[raw]

4. Would be nice if there was a standard for ebike on Bluetooth, so any mobile app could connect to every ebike.

there are profiles we can use: https://www.bluetooth.com/specifications/gatt/
i did not read into them.
afaik a phone can use multiple profiles at the same time, so we could implement these and just add some profile specific to our firmware.
the good thing about BLE is that the profiles are completely software-defined.

I also owned a Pebble, Basis Peak, etc. I think Garmin are the best near of Pebble. Although Fitbit bought Pebble, their new product Fitbit Versa that I also own, did follow Apple watch as almost everyone, with displays with a lot of colors but not always on. Garmin is the only one that kept the always on displays, long battery, less beauty but very strong on the advanced fitness metrics - the display is not everything.

yes, long battery live (1 week+) and always on is something i am used to now. is there a garmin model you would call a real pebble alternative? my pebble works fine, i have repaired it a bit (screen connector loose problem) and made my own strap i am just missing a pulse sensor.

here is also another thing that came in my mind; the configuration should be stored on the dongle and not on the phone. this would be useful for the "borrow a friends bike" or "replacement screen" (where you have multiple phones to use) scenario. if we do not just send the configuration to the display but also information about accepted values (data types, value range, acceptable enum values) the app could just render it and give edit options to whatever the dongle sends as configuration options. That way, no app update would be needed when adding new configuration options - and also the use of older firmware versions with less options will work with no effort.

it may be possible to render the configuration informations almost directly from the config definition structs we have on the Color_LCD firmware into JSON. do you plan to add the dongle as "display" to the Color_LCD project?

we should also think about some catchy name for the app (or for the project), something one can search on the appstore. "Smart Open eBike" would be one option, but is not very creative there are already a lot projects out there that use combinations of open and bike.

 

[casainho]

4. Would be nice if there was a standard for ebike on Bluetooth, so any mobile app could connect to every ebike.

there are profiles we can use: https://www.bluetooth.com/specifications/gatt/
i did not read into them.

There are none for ebike. There are only for cycling sensors like cadence.

yes, long battery live (1 week+) and always on is something i am used to now. is there a garmin model you would call a real pebble alternative? my pebble works fine, i have repaired it a bit (screen connector loose problem) and made my own strap i am just missing a pulse sensor.

Garmin are way more advanced right now, mainly of the fitness algorithms. On Garmin line, you need to decide if you want a watch for some oriented sport or a more casual watch. I decided to buy one for running for 210€, the Forerunner 245. If I want even more advanced metrics for running, I need to buy the Forerunner 945 for 600€ (there is a middle one 645).
Yesterday I went with my TSDZ2 ebike to the beach and did a swim:

With a multisport watch I could probably have one activity with that ones, because they have triathlon activity type. Still, the two cycling activity were recorded with the Edge on the bicycle that was receiving my heart rate from the watch. The integration of different sensors and devices, is very good.

So, you pay for the features. And select a model that have CIQ apps, the custom apps we can develop. This ones can communicate with a Bluetooth and ANT+ devices, etc. There are no watches with ANT+ LEV ebike but we can make a app for it.

here is also another thing that came in my mind; the configuration should be stored on the dongle and not on the phone. this would be useful for the "borrow a friends bike" or "replacement screen" (where you have multiple phones to use) scenario.

Sure and the board has 1Mbyte of flash memory, is a lot.

In the limit, we can ride without display or buttons, just connect mobile phone to startup the system and select the assist level. And yes, there are a lot of possible combinations for different users types

if we do not just send the configuration to the display but also information about accepted values (data types, value range, acceptable enum values) the app could just render it and give edit options to whatever the dongle sends as configuration options. That way, no app update would be needed when adding new configuration options - and also the use of older firmware versions with less options will work with no effort.

it may be possible to render the configuration informations almost directly from the config definition structs we have on the Color_LCD firmware into JSON. do you plan to add the dongle as "display" to the Color_LCD project?

Good!
For start I will build something out of the Color_LCD but after, if makes sense, we can make it together.

we should also think about some catchy name for the app (or for the project), something one can search on the appstore. "Smart Open eBike" would be one option, but is not very creative there are already a lot projects out there that use combinations of open and bike.

I agree.
Smart I think should be for devices with machine learning, not our case.

 

[sbartle]

Have you considered using the Wahoo Element Bolt. It’s £180 in the UK and has a battery life that’s almost triple that of the comparative Garmin 520 device. It supports LEVs, can be setup wirelessly from a smartphone etc. I haven’t got any experience of programming etc, so I apologise in advance if there’s something glaringly obvious that would prohibit its use!

https://uk.wahoofitness.com/devices/bike-computers/gps-elemnt-bolt

 

[casainho]

Have you considered using the Wahoo Element Bolt. It’s £180 in the UK and has a battery life that’s almost triple that of the comparative Garmin 520 device. It supports LEVs, can be setup wirelessly from a smartphone etc. I haven’t got any experience of programming etc, so I apologise in advance if there’s something glaringly obvious that would prohibit its use!

https://uk.wahoofitness.com/devices/bike-computers/gps-elemnt-bolt

The great of this project is that we will be able to choose from a large number of displays, unlike now. But note that a display that supports custom apps like Garmin Edge, will be able to provide more specific features for TSDZ2 and that Wahoo does not support custom apps, I think only Garmin support custom apps.

I bought the last version, the Edge 530 and it says 20 yours of battery - it is good to see that characteristic increasing over time / models. This model also supports a connection of a battery pack. Unfortunately there is no information how that battery pack connection works, so a connection base to the handle bars could be 3D printed with power connection.

I am on Garmin ecosystem because of the watch, for assess my fitness / health progression and sports activity like running / walking.
Here is my use case for wireless TSDZ2 ebike.

My body battery, changes depending on my sleeping quality, stress (or being hill, detected on heart HRV) and sport activity:



Training load, tell me I should probably rest on next 2 days:





And my VO2 Max slowly increasing since I started to run and doing the rest of efforts like swimming, cycling, eat less:



Now I am merging all this with cycling, where I can see my heart rate while cycling and deciding to use lower motor assistance as I want to workout more / be on a specific heart rate range:



Yesterday I went again to the beach at the end of the day. I wanted to workout, to be at a specific heart rate value and that is why I need a display to show that to me - look at that graph, that is where I took the idea for wanting graphs on TSDZ2 display. Note that my watch was measuring my HR and broadcasting to the Edge.

I also wanted to do the 17 kms from home to beach relatively fast, specially on long, plane and large cycle paths. I also had to manage the TSDZ2 max temperature, to avoid the motor power reduction, as seen on the 860C graph. Note that 860C has a very bright and good quality display!!

With this project in future, I will remove the 860C and use only the Edge. Edge will be able to control the TSDZ2 as a wireless standard EBike (ANT+ LEV). And because Garmin Edge support custom apps, I will be able to create a custom widget that is a graph to specifically show the TSDZ2 motor temperature - so, using Edge will be like having 850C/860C customs fields and graphs + Garmin health / fitness metrics.

 

[mallesepp]

I bought the last version, the Edge 530 and it says 20 yours of battery - it is good to see that characteristic increasing over time / models. This model also supports a connection of a battery pack. Unfortunately there is no information how that battery pack connection works, so a connection base to the handle bars could be 3D printed with power connection.

Hello Casainho, I use for long trips any powerbank for my garmin Edge 1000. It works without problems! I think it's also for yout Edge 530

 

[AZUR]

I bought the last version, the Edge 530 and it says 20 yours of battery - it is good to see that characteristic increasing over time / models. This model also supports a connection of a battery pack. Unfortunately there is no information how that battery pack connection works, so a connection base to the handle bars could be 3D printed with power connection.

Hello Casainho, I use for long trips any powerbank for my garmin Edge 1000. It works without problems! I think it's also for yout Edge 530

10854.jpg

Hi,

Many people destroyed the Garmin because water entered the USB port when they were charging the battery while riding the bike.
The Garmin edge has a waterproof cover that seals the USB port when not in use.

 

[AZUR]

Have you considered using the Wahoo Element Bolt. It’s £180 in the UK and has a battery life that’s almost triple that of the comparative Garmin 520 device. It supports LEVs, can be setup wirelessly from a smartphone etc. I haven’t got any experience of programming etc, so I apologise in advance if there’s something glaringly obvious that would prohibit its use!

https://uk.wahoofitness.com/devices/bike-computers/gps-elemnt-bolt

The great of this project is that we will be able to choose from a large number of displays, unlike now. But note that a display that supports custom apps like Garmin Edge, will be able to provide more specific features for TSDZ2 and that Wahoo does not support custom apps, I think only Garmin support custom apps.

I bought the last version, the Edge 530 and it says 20 yours of battery - it is good to see that characteristic increasing over time / models. This model also supports a connection of a battery pack. Unfortunately there is no information how that battery pack connection works, so a connection base to the handle bars could be 3D printed with power connection.

I am on Garmin ecosystem because of the watch, for assess my fitness / health progression and sports activity like running / walking.
Here is my use case for wireless TSDZ2 ebike.

My body battery, changes depending on my sleeping quality, stress (or being hill, detected on heart HRV) and sport activity:



Training load, tell me I should probably rest on next 2 days:





And my VO2 Max slowly increasing since I started to run and doing the rest of efforts like swimming, cycling, eat less:



Now I am merging all this with cycling, where I can see my heart rate while cycling and deciding to use lower motor assistance as I want to workout more / be on a specific heart rate range:



Yesterday I went again to the beach at the end of the day. I wanted to workout, to be at a specific heart rate value and that is why I need a display to show that to me - look at that graph, that is where I took the idea for wanting graphs on TSDZ2 display. Note that my watch was measuring my HR and broadcasting to the Edge.

I also wanted to do the 17 kms from home to beach relatively fast, specially on long, plane and large cycle paths. I also had to manage the TSDZ2 max temperature, to avoid the motor power reduction, as seen on the 860C graph. Note that 860C has a very bright and good quality display!!

With this project in future, I will remove the 860C and use only the Edge. Edge will be able to control the TSDZ2 as a wireless standard EBike (ANT+ LEV). And because Garmin Edge support custom apps, I will be able to create a custom widget that is a graph to specifically show the TSDZ2 motor temperature - so, using Edge will be like having 850C/860C customs fields and graphs + Garmin health / fitness metrics.

Casainho,

Development promises!

Good job.

You are, like the other developers, on the right track.

As I do an aggressive MTB, and I always ride with Garmin Edge, I would like to not need the 860.

But, for me, to give up the 860, I think I need to have robust buttons like those on the 860.

But it's just a personal opinion!

If I have to keep riding with the 860, but I have some information about the TSDZ2, on Garmin Edge I am very satisfied.

And if in addition I can also make the configuration of the TSDZ2, in a simpler way, on the smartphone, even better.

And if I manage to get some additional statistics on the Smartphone, it will be excellent.

And if I still manage, in an emergency, to ride the bike without the display, it would be great.

I am very satisfied with what is being done and I am an unconditional supporter.

 

[raw]

@casainho

thank you for sharing info about your setup. i am now thinking about upgrading my watch

i have finished my concept of the configuration screen and JSON structure. i expect it to change a bit over time, but now we have at least something we can discuss about.

here is my draft of how the configuration that is sent from the dongle to the app looks like:

{
  "version": 0.1,
  "config": [
    {
      "type": "bool",
      "label": "boolean option",
      "key": "enable_walkmode",
      "value": false
    },
    {
      "type": "menu",
      "label": "Some submenu",
      "key": "some_submenu",
      "children": [
        {
          "type": "text",
          "label": "here you can type some informative text"
        },
        {
          "type": "bool",
          "label": "Enable Walkmode",
          "key": "enable_walkmode",
          "value": false
        },
        {
          "type": "title",
          "label": "powermode options"
        },
        {
          "type": "enum",
          "label": "Power Mode",
          "key": "power_mode",
          "value": "TORQUE",
          "choices": {
            "TORQUE": "by torque",
            "POWER": "by Power",
            "SLOPE": "by Slope"
          },
          "info": "Some description\nof the power modes\n\nRTFM!"
        }
      ]
    },
    {
      "type": "number",
      "label": "Maximum speed",
      "key": "max_speed",
      "value": 25,
      "min": 0,
      "max": 50,
      "step": 1
    },
    {
      "type": "number",
      "label": "something with two decimal places",
      "key": "some_decimal",
      "value": 2.4,
      "min": 0,
      "max": 5,
      "decimal": 2
    }
  ]
}

the configuration screen that gets generated from this json looks like this:

the "info" field can be added to any field type and is optional. i thought it would be nice if you could give some info for more complex options.

everything that has a value also has a key so we have something to reference when sending the configuration back to the dongle. i have not yet decided if the returning configuration values will be nested in the same tree or just one flat key:value object. for the key:value object, the keys need to be unique while for the nested stuff the submenus need a key too.

having a key on the submenu will also allow it to be translated later (a translation definition could override the labels based on the keys).

the enum type is currently only a string-enum. it would be possible to implement an int-enum but i was not sure if this makes something easier.

the number type can either be decimal or int (defined by the decimal field). currently, if it is decimal, the step field is not supported, it only works for int. min and max value is always required, step and decimal is optional.

while the configuration menu on the 860c is used for configuring the motor, the display and to show diagnostic values, the configuration menu expressed by this JSON is only used for dongle/motor configuration. if the app is started or the config screen is opened, the configuration will be fetched once. when the configuration is closed, the values will also be transfered to the motor once.

for diagnostic and frequently changing values (assist level) we will use different endpoints.
if you want to try youtself, here is the apk: https://easyupload.io/cgasmh the example config file is compiled in.

any comments or ideas on this?

my next step is to add bluetooth functionality and design the bluetooth api by adopting some Nordic NRF example with my dongle.

 

[e3s]

Nice. Simple and easy. If I can suggest you can put + and - near the variable to change it or a slider or choose it with the keyboard. There are many options to choose. Further in the development a vertical slider on the right (or on the left for left-handed) in the main screen to change the level assist on the fly.

 

[casainho]

i have finished my concept of the configuration screen and JSON structure. i expect it to change a bit over time, but now we have at least something we can discuss about.

Nice advances!!

On my side, testing the sample code for receiving HR from an ANT+ HR sensor and send it as a BLE HR sensor:

I have an old board with NRF52832 and I flash and debug with the cheap STLinkV2:

Flash and debug:

The important line added to Makefile, to make a hex file that include the Softdevice and the application:

	$(SREC_PATH)srec_cat $(SOFT_DEVICE) -Intel $(OUTPUT_DIRECTORY)/nrf52832_xxaa.hex -Intel -Output $(OUTPUT_DIRECTORY)/TSDZ2_wireless.hex

And the HR sensor on BLE, on mobile phone:

I could not yet understand how to connect an ANT+ sensor to the board... the instructions of the example code says about using another board running another example code, which I don't have. Anyway, I was exploring on my watch and at least it could see and connect to the BLE HR sensor:

This testing code is here: https://github.com/OpenSource-EBike-firmware/TSDZ2_wireless

 

[casainho]

On my side, testing the sample code for receiving HR from an ANT+ HR sensor and send it as a BLE HR sensor:

My board is missing the antenna, there is the connector to it but I lost the antenna.

I tested 3 different example codes of Nordic SDK ANT+ (with 2 different softdevice versions) and none of them worked, still, the code that implemented Bluetooth and ANT+ simultaneous, the Bluetooth works as expected. My plan now is to wait for the NRF52840 boards I bought for this project, that will take probably more 3 weeks to arrive. I will take this time to learn more about the ANT+ LEV profile, as there is no sample code on the Nordic SDK.

 

[raw]

On my side, testing the sample code for receiving HR from an ANT+ HR sensor and send it as a BLE HR sensor:

My board is missing the antenna, there is the connector to it but I lost the antenna.

I tested 3 different example codes of Nordic SDK ANT+ (with 2 different softdevice versions) and none of them worked, still, the code that implemented Bluetooth and ANT+ simultaneous, the Bluetooth works as expected. My plan now is to wait for the NRF52840 boards I bought for this project, that will take probably more 3 weeks to arrive. I will take this time to learn more about the ANT+ LEV profile, as there is no sample code on the Nordic SDK.

have you ordered them from china?

im currently adding bluetooth functionality to the app using the cycling speed and cadence example from the sdk. i have looked into building a custom service and characteristic but as it did not progess as fast as i wanted i switched over to do some bluetooth on the app first. at least the battery status profile can be used later

implementing these standard profiles (csc, battery, ..) will allow the use of bluetooth based hardware bike computers and other fitness apps on the phone. i do not plan to use any of them, but it would make the dongle even more flexible. what do you think?

thinking about my own use case, i think about keeping the 860c display because of the extra screen space and the control buttons. so my usecase could be: assist level control using the display buttons, some basic real time metrics (speed, cadence, human/motor power) on the display, configuration using smartphone, advanced graphs and tour history on the smartphone.

one idea that came into my mind was to render the displays image content on the smartphone and send it (jpeg/gif?)compressed to the dongle which transmits it to the display. that way, the display can be used as extended screen space for the smartphone. but i am not sure if this would work because of bandwidth. i think it will be easier to just add some custom values that can be sent from the dongle to the display that can be flexible set via bluetooth. that way, the app user could set custom1 = heart rate, custom2 = slope, custom3 = acceleration on the smartphone app and see them on the display.

did you plan have the display supported on the dongle? on your usecase you do have no 860c display.

 

[casainho]

have you ordered them from china?

Sure, I bought 2 units that on EU would costs 60€ but from China costs 30€.

im currently adding bluetooth functionality to the app using the cycling speed and cadence example from the sdk. i have looked into building a custom service and characteristic but as it did not progess as fast as i wanted i switched over to do some bluetooth on the app first. at least the battery status profile can be used later

implementing these standard profiles (csc, battery, ..) will allow the use of bluetooth based hardware bike computers and other fitness apps on the phone. i do not plan to use any of them, but it would make the dongle even more flexible. what do you think?

I think yes, we should use standard existing profiles as much possible. However we know that it will not be possible for every data we want to send to smartphone.

thinking about my own use case, i think about keeping the 860c display because of the extra screen space and the control buttons. so my usecase could be: assist level control using the display buttons, some basic real time metrics (speed, cadence, human/motor power) on the display, configuration using smartphone, advanced graphs and tour history on the smartphone.

one idea that came into my mind was to render the displays image content on the smartphone and send it (jpeg/gif?)compressed to the dongle which transmits it to the display. that way, the display can be used as extended screen space for the smartphone. but i am not sure if this would work because of bandwidth. i think it will be easier to just add some custom values that can be sent from the dongle to the display that can be flexible set via bluetooth. that way, the app user could set custom1 = heart rate, custom2 = slope, custom3 = acceleration on the smartphone app and see them on the display.

did you plan have the display supported on the dongle? on your usecase you do have no 860c display.

The idea is that we have a standard wireless ebike based on ANT+ LEV profile - so users can choose from the available displays on the market, from more simple and cheap ones to the more expensive and complex ones. And I think another option is do develop a DIY ANT+ LEV display.

Maybe 860C can be used to build a DIY display but then you will want more from it and you will be thinking on that work arrounds like that of sending to it the full display image.

If you really do tours, maybe you should go with a Garmin Edge because it supports ANT+ LEV profile and you can have your custom fields and apps to get the specific TSDZ2 data, show graphs on display and can record an cycling activity where you can inject some TSDZ2 variables that will be shown on the Garmin app graphs, like other regular variable as heart rate, temperature, elevation, etc. -- this is the FIT file, also part of ANT. FIT file is a record from an activity where you can also inject your variables other the ones that the Edge already records.

Other option, could be a DIY display. Maybe with a powerful processor to be able for fast development and nice graphics. Or just low processing power and just simple data as you say.

Even other option could be the Edge 130:
- 860C display on EU costs 100€
- Garmin Edge 130 on EU costs 122€

[youtube]j_Q8xvdUsIA[/youtube]

Advantages of Edge 130:
- shows EBike data
- almost for sure can show TSDZ2 specific data
- Ebike control would be with wireless button that connects directly to Ebike wireless board (so Edge 130 is optional, you don need to be using it always to use your ebike)
- Garmin common features like many customized fields and layouts (where we can develop our own TSDZ2 Ebike fields)
- record cycling activities with added TSDZ2 motor data that can later be seen on Garmin mobile app graphs

See this ANT+ ebike field developed by an user: https://apps.garmin.com/en-US/apps/1532f0d9-fd19-4b63-b038-435d8fd670a4

 

[AZUR]

You have 2 860 Display in Europe at 80€.

 

[Headless]

I really love this project! I can't believe the work you've done already, but now to add cheapness and reduce clutter - :thumb:

To make a couple of observations from my perspective as a commuter and occasional leisure user...... One of the things I like about the TSDZ2 is the single cable that goes from the motor to the handlebars, which I would like to keep; however the power for the front light has to come from the back wheel connection.

If the "dongle" could be a cable-connection box for the front brakes, motor-controller, menu-buttons and have a couple of extra inputs for a light button and a horn button I think it might widen the appeal. The horn button could be direct Vbattery (with a linear regulator to 12v etc.?) but the light button could toggle between following the rear-light's behaviour or fully on - i.e. logic level switch with mosfet relay driven by processor.

If the cable-connection-box/dongle has an LED bar-graph on it this could be used for battery voltage, temperature warning, assistance level etc. when used headless. I would expect to use the bike headlessly most of the time, change any config. settings with the phone and perhaps occaisonally use the phone for logging, as a "live" display and with a ANT+ or BT sensor.

Do you know what current rating the 6/8-way motor-controller cable has? If the headlight could run off the battery voltage in that cable it would be great, but at 48v you might need to draw up to 200mA? And if you want to charge a phone etc. then double that. The Chinese are very clever at reducing copper in a product until it only just doesn't fail! I guess the experimenter could parallel the "throttle" and 5v cables with the Vbattery and GND, but it would be nice if it was compatible with the 6-way cable - i.e. 5v supply not used.

BTW, it did occur to me that you can get ANT+ cranks for torque sensors - with a pair of these could you replace the internal torque sensor and make a stronger axle? :wink:

Thanks again for your work on this - I don't have many skills, but I hope I can contribute at some point!

 

[cavi]

I really love this project! I can't believe the work you've done already, but now to add cheapness and reduce clutter - :thumb:

To make a couple of observations from my perspective as a commuter and occasional leisure user...... One of the things I like about the TSDZ2 is the single cable that goes from the motor to the handlebars, which I would like to keep; however the power for the front light has to come from the back wheel connection.

If the "dongle" could be a cable-connection box for the front brakes, motor-controller, menu-buttons and have a couple of extra inputs for a light button and a horn button I think it might widen the appeal. The horn button could be direct Vbattery (with a linear regulator to 12v etc.?) but the light button could toggle between following the rear-light's behaviour or fully on - i.e. logic level switch with mosfet relay driven by processor.

If the cable-connection-box/dongle has an LED bar-graph on it this could be used for battery voltage, temperature warning, assistance level etc. when used headless. I would expect to use the bike headlessly most of the time, change any config. settings with the phone and perhaps occaisonally use the phone for logging, as a "live" display and with a ANT+ or BT sensor.

Do you know what current rating the 6/8-way motor-controller cable has? If the headlight could run off the battery voltage in that cable it would be great, but at 48v you might need to draw up to 200mA? And if you want to charge a phone etc. then double that. The Chinese are very clever at reducing copper in a product until it only just doesn't fail! I guess the experimenter could parallel the "throttle" and 5v cables with the Vbattery and GND, but it would be nice if it was compatible with the 6-way cable - i.e. 5v supply not used.

BTW, it did occur to me that you can get ANT+ cranks for torque sensors - with a pair of these could you replace the internal torque sensor and make a stronger axle? :wink:

Thanks again for your work on this - I don't have many skills, but I hope I can contribute at some point!

doesn't the 860 have a usb power output? Couldn't you power your lights from there?

 

[e3s]

For reference here there is the difference between various nrf52. i was looking for cheaper one but cheaper means less functions.

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fstruct_nrf52%2Fstruct%2Fnrf52.html