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

[Tiger_one]

Has anyone built the controller using the Traco power TEC-2-4811WI voltage converter?

I have it, but have not built yet. Got off tract building the balancing robot.

 

[Tiger_one]

Some news:

2. @rananna documented a different build and 3D design for the wireless remote: https://opensourceebike.github.io/remote/alt/build_remote.html

Great work! I like the new remote 3D design. On the new documentation page the link "How to flash bootloader on dongle" is broken. Link is under "Step by Step Instructions".

 

[casainho]

I did an update to the TSDZ2 EBike wireless controller page, mainly I put new updated images from my last build: https://opensourceebike.github.io/ebike_wireless_controller.html

So the documentation is at a good state. Next I need to build again my wireless remote and finally ride

 

[casainho]

I updated the main page with information for the Garmin Edge / cycling GPS displays: https://opensourceebike.github.io/

The page has now the following topics:
- EBike wireless controller
- Mobile app
- Fully wireless and wired remotes
- Garmin Edge / cycling GPS displays

 

[casainho]

Just to let you guys know that I just started the very initially firmware development for TSDZ2 motor controller v2 - this version has a way a more capable hardware to implement FOC, which will mean more efficiency motor control and less noise - also the microcontroller IC provides a ready code for FOC, so should be very fast to get it working!!

Here the repository: https://github.com/OpenSourceEBike/TSDZ2_motor_controller_v2

And building the very initial code:

 

[casainho]

Finally I installed my wireless remote and it seems to work as expected, at least the battery already worked for more than 24 hours

Also I always get my motor keep running, with wheel on the air, if I pedal a bit with assist level high. Previously with that old DC-DC converter, when I did break I always got the DC-DC and the NRF52 board burned :-( -- now with the new DC-DC, the one it is recommended on the instructions, I tested a few times and everything is ok, so finally I will be able to ride again

But on all this time, seems I lost the last tweaks in measures for the wireless remote 3D design, like the screws fail to tighten the keypad part, so, I have more work to do...

I did an update to the TSDZ2 EBike wireless controller page, mainly I put new updated images from my last build: https://opensourceebike.github.io/ebike_wireless_controller.html

So the documentation is at a good state. Next I need to build again my wireless remote and finally ride

 

[casainho]

So many annoying issues with the remote...

First I solved the issue where the screws would not tight the key pad original part, but that was kind of easy - I added the screws to the assembly and then compared the width of original part to the printed one, then adjusted the different and now they work as expected.

And there is another issue, screwing in totally will make the keypad to keep all 4 buttons pressed, I need to figure out to to solve this.

Then I assembled again my wireless remote and it was not working, Bluetooth was working but not ANT as also no reaction to UP and DOWN buttons... I decided to do a nrf5 mass_erase on OpenOCD and flash again the bootloader and firmware, finally the board was working again.

After 3 hours I tested again and the remote was dead... I did open it again, measured the battery voltage and was now maybe half of the voltage, so it was discharged but not fully, still, no response at all from the buttons. Then I restarted using the reset button of the board and it was finally working again. So I think the firmware were blocked some where and running at full speed so did discharge a lot the battery in so few time. Maybe it is something with buttons being pressed by mistake... or something with the timeout of 1h after no button press - I think there must be a blocking condition (infinite loop?) on the code that may be triggered with some buttons combinations, since my remote keypad is easily keep the buttons pressed without me knowing.

 

[casainho]

After 3 hours I tested again and the remote was dead... I did open it again, measured the battery voltage and was now maybe half of the voltage, so it was discharged but not fully, still, no response at all from the buttons. Then I restarted using the reset button of the board and it was finally working again. So I think the firmware were blocked some where and running at full speed so did discharge a lot the battery in so few time. Maybe it is something with buttons being pressed by mistake... or something with the timeout of 1h after no button press - I think there must be a blocking condition (infinite loop?) on the code that may be triggered with some buttons combinations, since my remote keypad is easily keep the buttons pressed without me knowing.

@rannana or anyone that is experienced, I decreased the BUTTON_PRESS_TIMEOUT from 60 minutes to 3 minutes and I verified the code always blocks after 3 minutes but not like at 2 minutes or less than the BUTTON_PRESS_TIMEOUT.

If you can think of what can be blocking...?? this is the shutdown sequence after that BUTTON_PRESS_TIMEOUT:

void shutdown(void)
{
led_sequence_play_next(LED_SEQUENCE_SHORT_GREEN);
led_sequence_play(LED_SEQUENCE_SHORT_BLUE);
led_sequence_play(LED_SEQUENCE_SHORT_YELLOW);
nrf_lp_delay_ms(2000);
nrf_gpio_pin_clear(19); //reset
nrf_lp_delay_ms(10);
nrf_gpio_pin_clear(BUTTON_1); //button1
nrf_lp_delay_ms(10);
app_timer_stop(ANT_Search_timer);
nrf_lp_delay_ms(10);
app_timer_stop(m_timer_button_press_timeout);
nrf_lp_delay_ms(10);
app_timer_stop(m_timer_button_long_press_timeout);
nrf_lp_delay_ms(10);
app_timer_stop(bluetooth_timer);
nrf_lp_delay_ms(10);
sd_clock_hfclk_release();
nrf_lp_delay_ms(10);
// Disable TWI ready for sleep
NRF_TWI0->ENABLE = TWI_ENABLE_ENABLE_Disabled << TWI_ENABLE_ENABLE_Pos;
nrf_lp_delay_ms(10);
NRF_SPI0->ENABLE = 0;
nrf_lp_delay_ms(10);
NRF_UART0->ENABLE = 0;
nrf_lp_delay_ms(10);

// shut down the dcdc
sd_power_dcdc_mode_set(NRF_POWER_DCDC_DISABLE);
sd_power_pof_enable(0);
nrf_lp_delay_ms(100);

nrf_gpio_cfg_default(LED1_G);
nrf_gpio_cfg_default(LED2_R);
nrf_gpio_cfg_default(LED2_G);
nrf_gpio_cfg_default(LED2_B);

nrf_gpio_cfg_default(BUTTON_1);
nrf_gpio_cfg_default(19);
sd_clock_hfclk_release();
nrf_lp_delay_ms(10);

nrf_lp_delay_ms(WAIT_TIME);
nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_GOTO_SYSOFF);
}

 

[casainho]

After 3 hours I tested again and the remote was dead... I did open it again, measured the battery voltage and was now maybe half of the voltage, so it was discharged but not fully, still, no response at all from the buttons. Then I restarted using the reset button of the board and it was finally working again. So I think the firmware were blocked some where and running at full speed so did discharge a lot the battery in so few time. Maybe it is something with buttons being pressed by mistake... or something with the timeout of 1h after no button press - I think there must be a blocking condition (infinite loop?) on the code that may be triggered with some buttons combinations, since my remote keypad is easily keep the buttons pressed without me knowing.

@rannana or anyone that is experienced, I decreased the BUTTON_PRESS_TIMEOUT from 60 minutes to 3 minutes and I verified the code always blocks after 3 minutes but not like at 2 minutes or less than the BUTTON_PRESS_TIMEOUT.

If you can think of what can be blocking...?? this is the shutdown sequence after that BUTTON_PRESS_TIMEOUT:

void shutdown(void)
{
led_sequence_play_next(LED_SEQUENCE_SHORT_GREEN);
led_sequence_play(LED_SEQUENCE_SHORT_BLUE);
led_sequence_play(LED_SEQUENCE_SHORT_YELLOW);
nrf_lp_delay_ms(2000);

Hmmm, I found that nrf_lp_delay_ms() was the blocking reason... so I exchanged all calls inside shutdown() to the regular nrf_delay_ms() and no there is no blocking at all. Finally I saw that shutdown() were being called a few times from regular main loop and only one time from the BUTTON_PRESS_TIMEOUT interrupt. I decided to shutdown_flag = true; inside that interrupt instead call directly the shutdown().
And I added this note to the code: void nrf_lp_delay_ms(int ms_delay); // SHOULD not be called inside an interrupt or the system will block

I updated the firmware to be the TSDZ2_wireless_remote_ota_update-v0.7.2.zip: https://github.com/OpenSourceEBike/TSDZ2_wireless/releases/tag/v0.7.0

 

[rananna]

GOOD CATCH!!!
I guess we got overly ambitious ion trying to save power.

 

[casainho]

but if you want a more compact solution - I've also used two of these and they seem to work well and be reliable.

https://uk.rs-online.com/web/p/switching-regulators/1883365

I would like to try this DC-DC but on the datasheet it says it need external capacitors, probably the ones that are big. Did you installed the external capacitors and if so, do you have a picture of your board?

 

[beemac]

but if you want a more compact solution - I've also used two of these and they seem to work well and be reliable.

https://uk.rs-online.com/web/p/switching-regulators/1883365

I would like to try this DC-DC but on the datasheet it says it need external capacitors, probably the ones that are big. Did you installed the external capacitors and if so, do you have a picture of your board?

Yea I've posted a pic before - i've not used any external components - I have two boards using that dc-dc - one is my development board - and one on my fsr mtb - although I've yet to ride that much since I've only just fitted a battery... My main bike has the traco 4850wi and that's also been faultless so far...

https://endless-sphere.com/forums/viewtopic.php?f=28&t=106346&p=1626311#p1626311

 

[casainho]

but if you want a more compact solution - I've also used two of these and they seem to work well and be reliable.

https://uk.rs-online.com/web/p/switching-regulators/1883365

I would like to try this DC-DC but on the datasheet it says it need external capacitors, probably the ones that are big. Did you installed the external capacitors and if so, do you have a picture of your board?

Yea I've posted a pic before - i've not used any external components - I have two boards using that dc-dc - one is my development board - and one on my fsr mtb - although I've yet to ride that much since I've only just fitted a battery... My main bike has the traco 4850wi and that's also been faultless so far...

https://endless-sphere.com/forums/viewtopic.php?f=28&t=106346&p=1626311#p1626311

Thanks. Because I will buy 2 more NTG52 boards from RS components, I will buy that DC-DCs because they are small and I would like to have a smaller device, I will then design a specific case for 3D print using this small DC-DC.

 

[sidmodi]

but if you want a more compact solution - I've also used two of these and they seem to work well and be reliable.

https://uk.rs-online.com/web/p/switching-regulators/1883365

I would like to try this DC-DC but on the datasheet it says it need external capacitors, probably the ones that are big. Did you installed the external capacitors and if so, do you have a picture of your board?

Yea I've posted a pic before - i've not used any external components - I have two boards using that dc-dc - one is my development board - and one on my fsr mtb - although I've yet to ride that much since I've only just fitted a battery... My main bike has the traco 4850wi and that's also been faultless so far...

https://endless-sphere.com/forums/viewtopic.php?f=28&t=106346&p=1626311#p1626311

I noticed that the Traco 4850wi and the buck that casainho is using, both have a 5V 1A output. How important is the 1A? The Traco TEC-2-4811WI that is listed on the wiki has 5V 400mA. Do you guys think the output current is too low? If that is the case, can I (or someone with the permissions) update the wiki to update the part number there?

Thank you@

 

[casainho]

but if you want a more compact solution - I've also used two of these and they seem to work well and be reliable.

https://uk.rs-online.com/web/p/switching-regulators/1883365

I would like to try this DC-DC but on the datasheet it says it need external capacitors, probably the ones that are big. Did you installed the external capacitors and if so, do you have a picture of your board?

Yea I've posted a pic before - i've not used any external components - I have two boards using that dc-dc - one is my development board - and one on my fsr mtb - although I've yet to ride that much since I've only just fitted a battery... My main bike has the traco 4850wi and that's also been faultless so far...

https://endless-sphere.com/forums/viewtopic.php?f=28&t=106346&p=1626311#p1626311

I noticed that the Traco 4850wi and the buck that casainho is using, both have a 5V 1A output. How important is the 1A? The Traco TEC-2-4811WI that is listed on the wiki has 5V 400mA. Do you guys think the output current is too low? If that is the case, can I (or someone with the permissions) update the wiki to update the part number there?

I think that 100mA will be more than enough.
You need to fork the repository, do the changes and finally do a pull request - search on google.

 

[casainho]

Finally I put all the translucent silicone on my wireless remote, it is fully water prof - I tested the battery after 24 and 48h, there is no noticeable discharge and I used the remote 1h each day. I am now very happy

 

[gfmoore]

Well, what can I possibly say! Absolutely enthralling read. I've just spent the last 3 days (I am currently redundant) reading every post on this magnificent thread. You guys are totally amazing and selfless. The efforts, tears, insights and determined doggedness on this project have been inspirational. You should heartily congratulate yourselves for a tremendous job.

Now that you have your "remote" working I think you guys should just take a few days to meditate on what you have accomplished and also to think on the "lessons learnt" perhaps. What worked well, what didn't work well, how could the project have worked better as a process, how could communication and the style of communicating been improved, what would you have avoided doing or saying. There are certainly some approaches that might work better in the future. As an example how might you have approached the led signalling system as this took what seemed to be quite a long time in iteration. Perhaps a more collaborative document might have helped to keep everyone on the same track?

I must commend Rananna for his humility, patience and determination to keep going, even when at times, I suspect, he got a bit frustrated. Casainho has been a tremendous force in driving the development and has shown extraordinary leadership. Beemac has in my opinion kept the project alive with insights, ability and seemed to keep you all on the same wavelength. There are many others too that have made amazing contributions throughout this last year.

Just a totally different thought, but do you realise that you now have the basis for an SRAM etap style electronic gear changing system? As I see it, all that is needed is some way of pulling and releasing the gear derailleur by means of a stepper motor attached to the cable. I have seen such a system, but it wasn't as cheap as I would like. Anyway idle thought. Take some time to recharge and enjoy your families and cycling.

Gentlemen, I salute you all. :thumb:


Gordon

 

[casainho]

Just a totally different thought, but do you realise that you now have the basis for an SRAM etap style electronic gear changing system? As I see it, all that is needed is some way of pulling and releasing the gear derailleur by means of a stepper motor attached to the cable. I have seen such a system, but it wasn't as cheap as I would like. Anyway idle thought. Take some time to recharge and enjoy your families and cycling.

Thanks for all the feedback.

Yes, I hope others can reuse our code and shared knowledge to keep improving the EBikes technology and knowledge.

Yes, now are good times in Portugal due to the sun and more outdoor events happening I am also cleaning and doing maintenance to my EBike, like yesterday I changed (for the first time in my life) the head set. On next days I will exchange the TSDZ blue gear for a new one since I did damage the current one while riding without brake sensors connected, while I had no wireless remote working with the brake sensor, due to all the problems that are now solved.

I wish we could develop a new motor, or at least parts of TSDZ2 to try make it smaller, light and less noise as also another version for more powerful and heavier.

 

[gfmoore]

Hi, for my own interest I want to see how all this stuff works. I am going to use Windows 10 and the Linux Ubuntu 20.10 wsl2 subsystem. I do have a Linux machine, but the screen size is too small when I remote into it so I'd rather use windows. (I thought using the windows linux subsystem might work ok - well it accepted all the apt installs)

Anyway, hit my first stumbling block, but to solve it I need to ask the question as to what my directory structure would look like? I cloned the entire repo, but when trying to clean noted that there are two tasks.json Clean is using the top level one. I am thinking that I should be using just the firmware directory and not need anything else? Or I need to set VSCode to just use the firmware folder, but I don't know how to do that - is it something to do with ${workspaceFolder} ? Currently that is pointing to the top of the cloned repo.

Gordon

edit: having senior moment - of course I can just open the firmware folder! - doh

 

[gfmoore]

Well I think I answered my question (partly). I just put the contents of the firmware folder at the "root" level - i.e. my ebike directory and was able to clean and compile. I would prefer to be able to clone and point at the firmware folder though.

However I got one compile error:
> Executing task: make <

Makefile:317: Cannot find include folder: ./nRF5_SDK_16.0.0/components/ant/ant_key_manager/config
mkdir _build
cd _build && mkdir TSDZ2_wireless_remote
Assembling file: gcc_startup_nrf52840.S
Compiling file: nrf_drv_clock.c
Compiling file: nrfx_clock.c
Compiling file: nrf_log_backend_rtt.c
Compiling file: nrf_log_backend_serial.c
Compiling file: nrf_log_backend_uart.c

Looked in the folder and that file wasn't there, just

gordon@GM-One:~/ebike/ebike_wireless_remote/nRF5_SDK_16.0.0/components/ant/ant_key_manager$ ls
ant_key_manager.c ant_key_manager.h

As far as I can tell anyway. Am I missing something?

(I'm pretty pleased that it almost worked - I am making notes as to what I do! )

Gordon

 

[beemac]

Hi, for my own interest I want to see how all this stuff works. I am going to use Windows 10 and the Linux Ubuntu 20.10 wsl2 subsystem. I do have a Linux machine, but the screen size is too small when I remote into it so I'd rather use windows. (I thought using the windows linux subsystem might work ok - well it accepted all the apt installs)

Anyway, hit my first stumbling block, but to solve it I need to ask the question as to what my directory structure would look like? I cloned the entire repo, but when trying to clean noted that there are two tasks.json Clean is using the top level one. I am thinking that I should be using just the firmware directory and not need anything else? Or I need to set VSCode to just use the firmware folder, but I don't know how to do that - is it something to do with ${workspaceFolder} ? Currently that is pointing to the top of the cloned repo.

Gordon

I use Windows but not using wsl. Had to look for a few win32 ports of tools e.g. srec_cat - but if you have it all installed in wsl already then you should be good...

I have a root folder called tsdz2 - then I clone all the repos into that folder... e.g:
\tsdz2\TSDZ2_Wireless
\tsdz2\TSDZ2-Smart-EBike
\tsdz2\TSDZ2-Android
etc.

I don't use vscode to build just to edit so not much help there - but if you have all the tool folders set in the path - just run make clean & make from the command line in the firmware folder to build.

 

[casainho]

Well I think I answered my question (partly). I just put the contents of the firmware folder at the "root" level - i.e. my ebike directory and was able to clean and compile. I would prefer to be able to clone and point at the firmware folder though.

However I got one compile error:
> Executing task: make <

Makefile:317: Cannot find include folder: ./nRF5_SDK_16.0.0/components/ant/ant_key_manager/config
mkdir _build
cd _build && mkdir TSDZ2_wireless_remote
Assembling file: gcc_startup_nrf52840.S
Compiling file: nrf_drv_clock.c
Compiling file: nrfx_clock.c
Compiling file: nrf_log_backend_rtt.c
Compiling file: nrf_log_backend_serial.c
Compiling file: nrf_log_backend_uart.c

Looked in the folder and that file wasn't there, just

gordon@GM-One:~/ebike/ebike_wireless_remote/nRF5_SDK_16.0.0/components/ant/ant_key_manager$ ls
ant_key_manager.c ant_key_manager.h

As far as I can tell anyway. Am I missing something?

(I'm pretty pleased that it almost worked - I am making notes as to what I do! )

Go to the makefile and remove the entry for that folder, as I think it is not needed (if so, this need to be corrected): /nRF5_SDK_16.0.0/components/ant/ant_key_manager/config

 

[beemac]

@casainho - interesting glitch in the android app if you have two bikes. Connect the ebike app to the first - then without closing the app - go to setup bluetooth and pair with a 2nd bike. The app then keeps the connections to both - you see the numbers flicker and switch between values for bike1 and bike2!

 

[gfmoore]

Hi, so something isn't right in the code or my toolchain and I don't want to go down a rabbit hole.

I went into MAKEFILE and removed (eventually) three lines that referenced ant_key_manager

213 $(SDK_ROOT)/components/ant/ant_key_manager/config \ removed (why does # comment not work?)
then
211 $(SDK_ROOT)/components/ant/ant_key_manager \ removed
then
107 $(SDK_ROOT)/components/ant/ant_key_manager/ant_key_manager.c \

(I couldn't understand why the comment character # would comment the line and everything after it???)

Then I got an error in main.c so commented out //#include "ant_key_manager.h"

Then I got an error
...
Compiling file: main.c
./main.c: In function 'softdevice_setup':
./main.c:907:14: warning: implicit declaration of function 'ant_plus_key_set' [-Wimplicit-function-declaration]
907 | err_code = ant_plus_key_set(ANTPLUS_NETWORK_NUM);
| ^~~~~~~~~~~~~~~~
Compiling file: eeprom.c
...

I'm thinking before I start removing, commenting out any more code (that I don't know what it does) some thought may be in order

I'm assuming you guys have been able to compile and not get these errors so what might be different to what you have and what I have cloned? Am I doing something stupid - probably as this is a bit new to me. I have used VSCode for personal web development projects, JavaScript etc, but the last time I programmed in C was in 1984 (ish) on an IBM PC clone. (No hard disk just 5 1/4 inch floppy disk and wrote a quicksort program - yay me!)

Gordon

 

[beemac]

Hi, so something isn't right in the code or my toolchain and I don't want to go down a rabbit hole.

I went into MAKEFILE and removed (eventually) three lines that referenced ant_key_manager

213 $(SDK_ROOT)/components/ant/ant_key_manager/config \ removed (why does # comment not work?)
then
211 $(SDK_ROOT)/components/ant/ant_key_manager \ removed
then
107 $(SDK_ROOT)/components/ant/ant_key_manager/ant_key_manager.c \

(I couldn't understand why the comment character # would comment the line and everything after it???)

Then I got an error in main.c so commented out //#include "ant_key_manager.h"

Then I got an error
...
Compiling file: main.c
./main.c: In function 'softdevice_setup':
./main.c:907:14: warning: implicit declaration of function 'ant_plus_key_set' [-Wimplicit-function-declaration]
907 | err_code = ant_plus_key_set(ANTPLUS_NETWORK_NUM);
| ^~~~~~~~~~~~~~~~
Compiling file: eeprom.c
...

I'm thinking before I start removing, commenting out any more code (that I don't know what it does) some thought may be in order

I'm assuming you guys have been able to compile and not get these errors so what might be different to what you have and what I have cloned? Am I doing something stupid - probably as this is a bit new to me. I have used VSCode for personal web development projects, JavaScript etc, but the last time I programmed in C was in 1984 (ish) on an IBM PC clone. (No hard disk just 5 1/4 inch floppy disk and wrote a quicksort program - yay me!)

Gordon

Yea don't comment that out - is the nrf sdk in the firmware folder? I think in the repo the nrf sdk is (relative to the fw folder) ..\..\common_firmware so it can't be found.

Copy or junction nRF5_SDK_16.0.0 into the firmware folder if it's not there.