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

[casainho]

for the flutter bluetooth topic: the flutter_blue library

So, I think that you are interested on using the NRF52840

Hm, my main interest is to avoid the development of the next "homebrewed" communication protocol but to use a "standard"
The only "standard" I know so far is ANT+ LEV. It does not offer all function to configure your system, but it's a starting point.

I played around with the popular and cheap HM10 BLE module and made fast progress with communication between the cell phone and the PC following this tutorial.
The module offers the service 0000FFE0-0000-1000-8000-00805F9B34FB. This has read and write properties to receive and send the UART messages. So my first thougt was to send Bytes according to the ANT+ LEV syntax directly from the Lishui-Controller to the cell phone and back. With this solution you won't need an own firmware on the wireless board, just the generic HM10 module. But it offers no ANT+ of course.

I'm a complete newbie in BLE/ANT, so I don't know anything about defining and offering own UUIDs / services

If instead of HM10 module you use the NRF52840 module, running our OpenSource firmware, you will get the standards of wireless ANT+ and Bluetooth EBike, cycling and fitness sensors, unlike that generic Bluetooth UART module. We can work together for a common mobile app. Once you do this investment, you (and anyone since this project is OpenSource) can quick reuse this EBike wireless technology with any other future EBike motor controller firmware you will develop other than the KT and the Lishui!!

 

[stancecoke]

you will get the standards of wireless ANT+ and Bluetooth EBike, cycling and fitness sensors

yes, that would unify the wireless communication, but not the interface to the controller itself. And this part is the one I'm interested in mainly.
I got some experience with the BionX protocol in my last project. It has parameters defined for very much e-bike specific needs.
As BionX doesn't exist any more there should be no copyright issues.
https://github.com/stancecoke/BionX_Minimal_Translator/blob/master/Inc/CAN-Registers.h

regards
stancecoke

 

[casainho]

you will get the standards of wireless ANT+ and Bluetooth EBike, cycling and fitness sensors

yes, that would unify the wireless communication, but not the interface to the controller itself. And this part is the one I'm interested in mainly.
I got some experience with the BionX protocol in my last project. It has parameters defined for very much e-bike specific needs.
As BionX doesn't exist any more there should be no copyright issues.
https://github.com/stancecoke/BionX_Minimal_Translator/blob/master/Inc/CAN-Registers.h

I see.

Well, for TSDZ2, we have specifics like torque sensor calibration table.

For the motor controller, I have mainly 3 packages:
- motor controller init (that includes sending the firmware versions for checking) and only after init:
-- configurations package that flows only after init or when user changes the configurations
-- periodic package that flows every 50ms (works also as an alive signal)

 

[stancecoke]

For the motor controller, I have mainly 3 packages:

But I doubt that this is suitable for a future standard. I like the BionX idea of just two different message-types. One request and one command.

void Send_CAN_Request(uint8_t address){
	TxHeader.StdId=ID_MOTOR;
	TxHeader.DLC=2;
	TxData[0] = 0;
	TxData[1] = address;

	//HAL_GPIO_TogglePin(Onboard_LED_GPIO_Port, Onboard_LED_Pin);
	if (HAL_CAN_AddTxMessage(&hcan, &TxHeader, TxData, &TxMailbox) != HAL_OK)
	   	{
    	  Error_Handler();
    	}
}

void Send_CAN_Command(uint8_t address, uint16_t value){
	TxHeader.StdId=ID_MOTOR;
	TxHeader.DLC=4;
	TxData[0] = 0;
	TxData[1] = address;
	TxData[2] = (value>>8) & 0xff;
	TxData[3] = value & 0xff;

	// Start the Transmission process, zwei mal senden wie im Beispiel https://github.com/jliegner/bionxdrive
	if (HAL_CAN_AddTxMessage(&hcan, &TxHeader, TxData, &TxMailbox) != HAL_OK)
	  {
	   // Transmission request Error
	   Error_Handler();
	  }

}

I think, I will read the basics about the ANT protocol first and then decide, how to proceed.

regards
stancecoke

 

[Slipy]

Welcome to the new topic TSDZ2 to S06S firmware
https://endless-sphere.com/forums/viewtopic.php?f=30&t=108904

 

[stancecoke]

the only critical thing is to agree on the UUIDs of the services used,

Is there a public overview over already existing "interesting" BLE and ANT+ services? We do not want to reinvent the wheel... I only found a link in @mspider65's repo:
https://www.bluetooth.com/blog/part-2-the-wheels-on-the-bike-are-bluetooth-smart-bluetooth-smart-bluetooth-smart/

regards
stancecoke

 

[casainho]

the only critical thing is to agree on the UUIDs of the services used,

Is there a public overview over already existing "interesting" BLE and ANT+ services? We do not want to reinvent the wheel... I only found a link in @mspider65's repo:
https://www.bluetooth.com/blog/part-2-the-wheels-on-the-bike-are-bluetooth-smart-bluetooth-smart-bluetooth-smart/

For ANT+ I am using their site, I had to register for free to get the access.

 

[raw]

the only critical thing is to agree on the UUIDs of the services used,

Is there a public overview over already existing "interesting" BLE and ANT+ services? We do not want to reinvent the wheel... I only found a link in @mspider65's repo:
https://www.bluetooth.com/blog/part-2-the-wheels-on-the-bike-are-bluetooth-smart-bluetooth-smart-bluetooth-smart/

regards
stancecoke

and here is what we have for bluetooth: https://www.bluetooth.com/specifications/gatt/

CPP Cycling Power Profile 1.1 Active 03 May 2016 N/A
CPS Cycling Power Service 1.1 Active 03 May 2016 N/A
CSCP Cycling Speed and Cadence Profile 1.0 Active 21 Aug 2012 N/A
CSCS Cycling Speed and Cadence Service 1.0 Active 21 Aug 2012 N/A
BAS Battery Service 1.0 Active 27 Dec 2011 N/A

 

[stancecoke]

Thank you for your answers. So ANT+ with the LEV standard has a certain lead...

regards
stancecoke

 

[casainho]

Thank you for your answers. So ANT+ with the LEV standard has a certain lead...

I think ANT is way more for cycling, including EBike. There are even ANT tyre pressure sensors!!

 

[stancecoke]

I am using their site, I had to register for free to get the access.

they want to know a lot of personal data when registering, this is not my thing.

regards
stancecoke

 

[casainho]

I am using their site, I had to register for free to get the access.

they want to know a lot of personal data when registering, this is not my thing.

That is what happens to me when I have to do the same for professional work, they always want to have many information. I think they expect developers that work for companies and not OpenSource individual developers.

While you are there, try to see the information about license and costs to use this ANT technology - compare the same for using Bluetooth, all of them need to be licensed.

 

[rananna]

I just added a pull request for the wireless remote.

Bluetooth capability has been added. Ant Device number can be changed for ANT+ LEV control.
I have tested with ANT+LEV devices with different device numbers and it works fine. Please note that variables are cleared with a reset, so, I added the function :
write_to persistent_memory_and_reset() to deal with this issue.
This needs to be added to the motor code also.
It is really interesting that bluetooth and ANT can function well at the same time.
The time division multiplexing that Nordic is doing with the radio for both protocols works well!

Operation:

1. short press on MINUS__PIN will decrease assist level
2. short press on PLUS__PIN will increase assist level
3. short press on ENTER__PIN will pageup on Garmin bike computer
4 short press on STANDBY__PIN will pagedown on garmin bike computet
5 long press on PLUS__PIN will start bluetooth advertising
6. long press on MINUS__PIN will stop bluetooth advertising
the remote will also stop bluetooth after 10 minutes of bluetooth advertising in case the user forgets to turn it off for lower power consumption.

Next up I will start to look at the bootloader.

 

[casainho]

I just added a pull request for the wireless remote.

Thanks!! and as I wrote on the pull request, there seems to be some issues you need to look.

 

[rananna]

I just added a pull request for the wireless remote.

Thanks!! and as I wrote on the pull request, there seems to be some issues you need to look.

Yes, I clearly need to brush up on git!
Thanks for the references; I will have a look and try again.

 

[rananna]

Added a replacement pull request.

 

[casainho]

Added a replacement pull request.

Thanks!! and I see you decided, to store the ANT ID, to not use the flash memory as I do to store the virtual display configurations, and instead use the sd_power_gpregret. The registers used by sd_power_gpregret keep only the value on RAM, even after reset, and only while the system has power only - this means user will have to make the configuration every time it changes the battery, which should not be often but using the flash memory as I did would avoid this. I think that for now we can keep like this and next time we can improve by changing the sd_power_gpregret to flash memory.

I would like you could make some clean before commit, see the following points:

Seems there are files added that are not needed, like UART drivers that are for sure not needed on this project. Please try find not needed, by removing then and build, so this way we will have a project more clean:
Makefile exmaple:
$(SDK_ROOT)/integration/nrfx/legacy/nrf_drv_uart.c \

After do the same on sdk_config.h, like on definitions like this:
#define NRFX_UARTE_ENABLED 1

Please remove this, as they are not used, right?
TSDZ2_REMOTE_FIRMWARE_MAJOR

On main.c, you removed the Copyright, please keep the original and add another line with your nickname or name like
Copyright (C) Casainho, 2020
Copyright (C) rananna, 2020

And why references to a bootloader that does not exist??
timer_button_long_press_bootloader_timeout_handler
m_timer_button_long_press_bootloader_timeout

 

[rananna]

@casainho, Today for some reason I cannot flash using openocd!
Something must have changed on my ubuntu installation, but I cannot figure it out.
I tried unstalling/uninstalling openocd, but no luck.

Below is what appears in the terminal.
it is complaining about -chain-position option, do you any ideas on how to fix this?

Terminal output:

Executing task: openocd -f /github/ebike_wireless_remote/firmware/tools/openocd-v0.10.0-scripts/stlink-v2.cfg -f /github/ebike_wireless_remote/firmware/tools/openocd-v0.10.0-scripts/nrf52.cfg <

Open On-Chip Debugger 0.10.0+dev-01447-g91c4c83f4-dirty (2020-11-01-11:31)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'adapter driver' not 'interface'
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
/home/randall/github/ebike_wireless_remote/firmware/tools/openocd-v0.10.0-scripts/nrf52.cfg:28: Error: target requires -dap parameter instead of -chain-position!
in procedure 'script'
at file "embedded:startup.tcl", line 26
at file "/home/randall/github/ebike_wireless_remote/firmware/tools/openocd-v0.10.0-scripts/nrf52.cfg", line 28
The terminal process "/bin/bash '-c', 'openocd -f /home/randall/github/ebike_wireless_remote/firmware/tools/openocd-v0.10.0-scripts/stlink-v2.cfg -f /home/randall/github/ebike_wireless_remote/firmware/tools/openocd-v0.10.0-scripts/nrf52.cfg'" failed to launch (exit code: 1).

Terminal will be reused by tasks, press any key to close it.

 

[rananna]

Never mind, I deleted openocd manually from usr/bin and reinstalled with sudo apt-get openocd and it works!
Don't know what happened to mess it up.

 

[casainho]

@casainho, Today for some reason I cannot flash using openocd!
Something must have changed on my ubuntu installation, but I cannot figure it out.
I tried unstalling/uninstalling openocd, but no luck.

Below is what appears in the terminal.
it is complaining about -chain-position option, do you any ideas on how to fix this?

This is what I see, 0.10.0 while you are using 0.10.0+dev-01447-g91c4c83f4-dirty (2020-11-01-11:31).

> Executing task: openocd -f /home/cas/software/nordic/nRF5SDK160098a08e2/tools/openocd-v0.10.0-scripts/stlink-v2.cfg -f /home/cas/software/nordic/nRF5SDK160098a08e2/tools/openocd-v0.10.0-scripts/nrf52.cfg <

Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 10000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : STLINK v2 JTAG v29 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.174803
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints

---

I had that kind of issues when I used older versions of OpenOCD, like 0.8 and 0.9 where I found the script were different for each version.

So, do not forget to run on a terminal: openocd -f /github/ebike_wireless_remote/firmware/tools/openocd-v0.10.0-scripts/stlink-v2.cfg -f /github/ebike_wireless_remote/firmware/tools/openocd-v0.10.0-scripts/nrf52.cfg

Seems the issue is on the nrf52.cfg that may need to be different for a different version of OpenOCD. Usually you can find the scripts for different microcontrollers on the OpenOCD installation folder - go and grab there file contents for NRF52.

 

[rananna]

[
Seems the issue is on the nrf52.cfg that may need to be different for a different version of OpenOCD. Usually you can find the scripts for different microcontrollers on the OpenOCD installation folder - go and grab there file contents for NRF52.

Thanks for the info. All is working well now.

 

[casainho]

Finally I have the Android app working!!

Starting with TSDZ2-ESP32 Android app and current firmware, there was no communication. Then I decided to try Nordic firmware example code for UART over Bluetooth and the Android app was not working but the Nordic Android app was working, so, there was some difference between both apps... since Nordic is sharing the source of his Nordic Android app on github, I could find the differences that was a thing about the way of setting characteristics notifications.

To resume: our Android app works with the Nordic firmware example code for UART over Bluetooth. It does now work yet with our firmware, seems the firmware has some issues on BLE services (??).

Screenshot showing Android code being debug and show receive of variable that is incrementing on the firmware side:

 

[casainho]

I got a big pull request from rananna, that also updated the project description: https://github.com/OpenSource-EBike-firmware/ebike_wireless_remote

This videos he posted should make more clear current state:

See controlling a Garmin 1030 bike computer for assist levels and page control using a simulated ANT+ LEV Ebike in this video:
[youtube]s7URIMVzcwc[/youtube]


See changing the ANT+ LEV Device Number (to connect to only one specific eBike) using the Nordic nRF Connect app in this video:
[youtube]pvqh7uVm5ww[/youtube]

 

[casainho]

I got a big pull request from rananna, that also updated the project description: https://github.com/OpenSource-EBike-firmware/ebike_wireless_remote

I updated the TODO list to:
- Bluetooth enabled bootloader to allow for wireless firmware updates
- Evaluate sending the brake sensors signal wireless
- Planned feature: Long press the [POWER] button to turn off the TSDZ2 motor
- Other ANT+ LEV button assignments (ie: Lights on/off Turn signals, etc)
- no battery voltage measurement on the hardware, firmware and so it is not reported to master / Edge
- Design a suitable spacer for 3D printing that can reuse the VLCD5 keypad and handlebar connector (basically, the top and bottom portions of the keypad) Inital design attempts are located in the 3d_design folder. Please contribute if you can!

I think the bootloader is the more urgent task so anyone can already build his remote and easily update future firmware improvements. Right now this remote is already great for Garmin Edge users!!

The evaluate the brake sensors signal going wireless would be my next priority, as I can not use my ebike without the brake sensors.

Having the all other features like the buttons lights, on/off, would be great.

About the 3D print, while I think is a good idea, alternatively anyone can keep using VLCD5 keypad and put the wireless board outside and protect it with some black tape and so give water resistance.

And about the TSDZ2 wireless board firmware, I now have the full Bluetooth working: 1 service for changing the ANT+ ID and 1 service for TSDZ2: 1 characteristic for configurations and 1 characteristic for periodic data. I hope this weekend to start and hopefully finish the implementation of the configurations, that is the top priority!!

 

[rananna]

-
I think the bootloader is the more urgent task so anyone can already build his remote and easily update future firmware improvements. Right now this remote is already great for Garmin Edge users!

Thanks for the merge!
I will start working on the Bluetooth bootloader now.