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



I went to ride and I used my Garmin GPS display, and yes, changing the assist level works well. Maybe this week I will finally remove the 860C display from the handle bar and start using only the wireless board... that will for sure give me extra motivation to finish the project and solve the issues I will have to deal with :)

There are some variables that have hard coded values, like the wheel speed = 25 km/h - this need to be improved.

I found the issue, and @rananna was right to think on the motor errors...

I just sent motor error variable as hall sensor, for the mobile app, and I found at level 3, at startup, sometimes the I got the error rt_vars.ui8_error_states = ERROR_FATAL, that only happens here on the motor controller firmware:

Code: 
    // if CRC is correct read the package
    if (((((uint16_t) ui8_rx_buffer[ui8_len + 1]) << 8) +
          ((uint16_t) ui8_rx_buffer[ui8_len])) == ui16_crc_rx)
    {
      ...
    }
    else
    {
      ui8_received_package_flag = 0;
      ui8_comm_error_counter++;
    }

  // check for communications fail or display master fail
  // can't fail more then 1000ms
  if (ui8_comm_error_counter > 10) {
    motor_disable_pwm();
    ui8_m_motor_enabled = 0;
    ui8_m_system_state |= ERROR_FATAL;
  }

I found that just sometimes I got this issue, and I did a long ride without any error at all even when changing between all assist levels.

So, why this issue happens but did not with the displays??
 
casainho said:


I went to ride and I used my Garmin GPS display, and yes, changing the assist level works well. Maybe this week I will finally remove the 860C display from the handle bar and start using only the wireless board... that will for sure give me extra motivation to finish the project and solve the issues I will have to deal with :)

There are some variables that have hard coded values, like the wheel speed = 25 km/h - this need to be improved.

I found the issue, and @rananna was right to think on the motor errors...

I just sent motor error variable as hall sensor, for the mobile app, and I found at level 3, at startup, sometimes the I got the error rt_vars.ui8_error_states = ERROR_FATAL, that only happens here on the motor controller firmware:

Code: 
    // if CRC is correct read the package
    if (((((uint16_t) ui8_rx_buffer[ui8_len + 1]) << 8) +
          ((uint16_t) ui8_rx_buffer[ui8_len])) == ui16_crc_rx)
    {
      ...
    }
    else
    {
      ui8_received_package_flag = 0;
      ui8_comm_error_counter++;
    }

  // check for communications fail or display master fail
  // can't fail more then 1000ms
  if (ui8_comm_error_counter > 10) {
    motor_disable_pwm();
    ui8_m_motor_enabled = 0;
    ui8_m_system_state |= ERROR_FATAL;
  }

I found that just sometimes I got this issue, and I did a long ride without any error at all even when changing between all assist levels.

So, why this issue happens but did not with the displays??
Click to expand...

Ah nice - glad you had a chance to try out the results of all your hard work! :)

Great work pinning down the problem. Really strange it's not affected the displays. If I understand correctly - problem is caused by too many comms errors between the wireless controller and motor controller?

If the nrf pin logic levels are 3.3v - and the TSDZ2 is 5v - could that be causing comms errors? If the 860c is 5v perhaps that wouldn't show the problem. How long are your wires? Mine are about 50cm between wireless board and motor controller case.

Spec says at 5v nrf logic high on pins is max 3.9v unless i'm reading the spec wrong. I wonder if the problem is the other way - is the nrf logical level high enough for the tsdz2?

https://infocenter.nordicsemi.com/topic/ps_nrf52840/abs_max_ratings.html?cp=4_0_0_8
 
beemac said:
If I understand correctly - problem is caused by too many comms errors between the wireless controller and motor controller?

If the nrf pin logic levels are 3.3v - and the TSDZ2 is 5v - could that be causing comms errors? If the 860c is 5v perhaps that wouldn't show the problem. How long are your wires? Mine are about 50cm between wireless board and motor controller case.

Spec says at 5v nrf logic high on pins is max 3.9v unless i'm reading the spec wrong. I wonder if the problem is the other way - is the nrf logical level high enough for the tsdz2?

https://infocenter.nordicsemi.com/topic/ps_nrf52840/abs_max_ratings.html?cp=4_0_0_8
Click to expand...
Yes, to many errors. Still I never tested how many errors with the display.

The 850C, 860C and SW102 are 3.3V, only the KT-LCD3 is 5V. As we know, SW102 is sold with 850C display.

My wires could be short but they are not so long as the display cable.

Maybe I could relax a bit the error amount, to 20 / 1 second, since that 10 check value means now 500ms, as each cycle is now 50ms.
 
@rananna and orther developers,

I just joined the sources of the bootloader, wireless board and wireless remote, this way we have only one common sources. Now there is only one place where the folder of Nordic SDK and not replicated 3 times.

For instance, recently you created the led_pwm_on() on the remote only but now it can be moved outside to common_firmware folder and then reuse on all the projects, like I will need it for the wireless board.

Get it here and please stop use the other repos, that I can make in archive mode soon: https://github.com/OpenSourceEBike/TSDZ2_wireless
 
casainho said:
beemac said:
If I understand correctly - problem is caused by too many comms errors between the wireless controller and motor controller?
Click to expand...
Yes, to many errors. Still I never tested how many errors with the display.

Maybe I could relax a bit the error amount, to 20 / 1 second, since that 10 check value means now 500ms, as each cycle is now 50ms.
Click to expand...

That would help keep things working but just masks the underlying problem? It's really bugging me (no pun intended!) that this occurs more on 'assist level 3' than others.

I've been a bit busy with work over the last couple of days - but I'll work on tapping the serial comms to see what sort of errors are actually occurring on-the-wire if we think that's useful.

Serial is 9600 etc. info here is correct? https://github.com/hurzhurz/tsdz2/blob/master/serial-communication.md
 
beemac said:
That would help keep things working but just masks the underlying problem? It's really bugging me (no pun intended!) that this occurs more on 'assist level 3' than others.

I've been a bit busy with work over the last couple of days - but I'll work on tapping the serial comms to see what sort of errors are actually occurring on-the-wire if we think that's useful.

Serial is 9600 etc. info here is correct? https://github.com/hurzhurz/tsdz2/blob/master/serial-communication.md
Click to expand...
No, it is 19200.
 
casainho said:
beemac said:
That would help keep things working but just masks the underlying problem? It's really bugging me (no pun intended!) that this occurs more on 'assist level 3' than others.

I've been a bit busy with work over the last couple of days - but I'll work on tapping the serial comms to see what sort of errors are actually occurring on-the-wire if we think that's useful.

Serial is 9600 etc. info here is correct? https://github.com/hurzhurz/tsdz2/blob/master/serial-communication.md
Click to expand...
No, it is 19200.
Click to expand...
OK - got a tap going - but only using putty at the moment so can't see the data in any meaningful way. What's the basic frame format? Is the link I posted earlier about the tsdz2 native protocol - not yours?

Watching the gibberish pulse past on putty - you can definitely see that the traffic is stuttering much more on level 3. Riveting youtube video uploading now! :)

[youtube]g28K6xHJmjo[/youtube]
 
beemac said:
casainho said:
beemac said:
That would help keep things working but just masks the underlying problem? It's really bugging me (no pun intended!) that this occurs more on 'assist level 3' than others.

I've been a bit busy with work over the last couple of days - but I'll work on tapping the serial comms to see what sort of errors are actually occurring on-the-wire if we think that's useful.

Serial is 9600 etc. info here is correct? https://github.com/hurzhurz/tsdz2/blob/master/serial-communication.md
Click to expand...
No, it is 19200.
Click to expand...
OK - got a tap going - but only using putty at the moment so can't see the data in any meaningful way. What's the basic frame format? Is the link I posted earlier about the tsdz2 native protocol - not yours?

Watching the gibberish pulse past on putty - you can definitely see that the traffic is stuttering much more on level 3. Riveting youtube video uploading now! :)

[youtube]g28K6xHJmjo[/youtube]
Click to expand...
You need to see and understand the code, the wiki is probably outdated on this type of information.

Maybe the best you can do is the change that value for 20, build and test that firmware. Also make the cable short.
And I am using a cable that is an extension for the speed sensor, I am not sure this cable is so good as a display cable.
 
And even more advanced would be for you to create a 8 bit variable and store the number of times that variable off package errors gets, then send that variable for like on the hall sensors or other, so you will be able to see on the mobile app, how many errors typically happens.

Other metrics like the time it takes between each error to happen, like a 16 or 32 bits variable that is already sent to display.

The idea is to measure and see if a shorter cable helps, if reconnecting the display connector helps, etc.
 
casainho said:
Maybe the best you can do is the change that value for 20, build and test that firmware. Also make the cable short.
And I am using a cable that is an extension for the speed sensor, I am not sure this cable is so good as a display cable.
Click to expand...

Sure - I'll have a play and see what I can find. Out of interest - why the change to 19200 from the native 9600? Maybe faster isn't faster! :)
 
beemac said:
casainho said:
Maybe the best you can do is the change that value for 20, build and test that firmware. Also make the cable short.
And I am using a cable that is an extension for the speed sensor, I am not sure this cable is so good as a display cable.
Click to expand...

Sure - I'll have a play and see what I can find. Out of interest - why the change to 19200 from the native 9600? Maybe faster isn't faster! :)
Click to expand...
The original firmware does much less and also send much less data to the display. Increasing the frequency made more available time for processing.
 
Hello, i've just finished to build my TSDZ2 e-mtb and flashed v0.20 firmware compatible with VLCD5.
I'm really interested to this project and i've just bought all the components needed to upgrade my ebike, but after reading all 28 pages of this topic i still haven't figured out which firmware version it is based on.
v1, v0.19, v0.20 or another one?
Thank you!!! :D
 
Filippods said:
Hello, i've just finished to build my TSDZ2 e-mtb and flashed v0.20 firmware compatible with VLCD5.
I'm really interested to this project and i've just bought all the components needed to upgrade my ebike, but after reading all 28 pages of this topic i still haven't figured out which firmware version it is based on.
v1, v0.19, v0.20 or another one?
Thank you!!! :D
Click to expand...
I am impressed that you slogged through all that discussion!
The answer is actually buried on page 25.
see: https://endless-sphere.com/forums/viewtopic.php?f=28&t=106346&p=1611774#p1611781

It's working quite well at the moment, looking forward to your feedback!
 
Filippods said:
Hello, i've just finished to build my TSDZ2 e-mtb and flashed v0.20 firmware compatible with VLCD5.
I'm really interested to this project and i've just bought all the components needed to upgrade my ebike, but after reading all 28 pages of this topic i still haven't figured out which firmware version it is based on.
v1, v0.19, v0.20 or another one?
Thank you!!! :D
Click to expand...
As rananna told, the motor firmware is the V1.1.0.

Find the very short documentation here: https://opensourceebike.github.io/ then you will find more on each repository. I would say you will be the first no developer to build the wireless board and use it - put your question here and we will guide you!!
 
:D thank you!

My BOM is:
- DCDC converter (mine is 10-90v to 5v 2,1A)
- nordic nrf52840 (blue one)
- BSP296
- BTS4140N
- fuse rated 250mA
- no resistors

My configuration is:
-TSDZ2 48v version (with some mods)
-14s 20Ah battery
-Etrex e30 or Android Smartphone

I would like to implement your wireless system plus ANT+ remote (the one included with VLCD5).
To avoid cables going around the frame of my ebike, im going to position all the stuff in the aluminium heatsink of the battery.
 
Filippods said:
:D thank you!

My BOM is:
- DCDC converter (mine is 10-90v to 5v 2,1A)
- nordic nrf52840 (blue one)
- BSP296
- BTS4140N
- fuse rated 250mA
- no resistors

My configuration is:
-TSDZ2 48v version (with some mods)
-14s 20Ah battery
-Etrex e30 or Android Smartphone

I would like to implement your wireless system plus ANT+ remote (the one included with VLCD5).
To avoid cables going around the frame of my ebike, im going to position all the stuff in the aluminium heatsink of the battery.
Click to expand...
Great but would be good if we keep using the same hardware, so later we can compare. I think would be good if you could use the same DC-DC, in the case you will buy it yet.

Using the same hardware means we can have the same dimensions, can be important for 3D printed enclosures.
 
casainho said:
Great but would be good if we keep using the same hardware, so later we can compare. I think would be good if you could use the same DC-DC, in the case you will buy it yet.

Using the same hardware means we can have the same dimensions, can be important for 3D printed enclosures.
Click to expand...
Ok, i've just ordered also thr DCDC you posted, but it's rated 55v in continuous usage while my battery at full charge is 59v.
Could i use a 250mA-500mA resettable fuse?
To build the remote i need only the nrf52840 board?
If it'll help i have a 3d printer and i can project and print in PLA, ABS and PETG.
I've also a CNC mill to create PCBs.
 
casainho said:
I would say you will be the first no developer to build the wireless board and use it ...
Click to expand...

"be the first no developer" - Is this a compliment or an offence?
 
casainho said:
You need to see and understand the code, the wiki is probably outdated on this type of information.

Maybe the best you can do is the change that value for 20, build and test that firmware. Also make the cable short.
And I am using a cable that is an extension for the speed sensor, I am not sure this cable is so good as a display cable.
Click to expand...

I think i'll leave my cable as it is for now - since it's much shorter than the original cable from the 860c - and if I can make my setup reliable it's a good chance others will then be.

I've got a few ideas, tonight I've just been getting the toolchain working on windows. I can now compile and flash the motor controller fw over SWIM - and I've just compiled the wireless controller firmware - going to hopefully get that flashing over SWD then I think that's a good evening's work!

Main thing that stopped things building initially was that the makefile for the wireless controller seemed to have two spaces not tabs in front of a lot of critical folders - putting those back fixed all my missing header errors.

Another gotcha was that I initially downloaded the "GNU Arm embedded toolchain for Windows 0.1.6" from VS Code extensions. That seems to have an issue generating the hex file for 64bit code (https://bugs.launchpad.net/gcc-arm-embedded/+bug/1810274)- so I downloaded https://github.com/ilg-archived/arm-none-eabi-gcc/releases/tag/v8.2.1-1.2 which works fine.

Edit: The above linked ARM toolchain also has bugs on windows - collect2.exe can't handle spaces in paths apparently and stops the bootloader linking (fails to find lto_wrapper.exe) I finally installed the right package - should have read the instructions more carefully in the first place and used the version from here - https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads
 
Filippods said:
im going to position all the stuff in the aluminium heatsink of the battery
Click to expand...
I have a really solid aluminium heatsink at one bike too. Putting the nRF52840 Dongle inside won't work (you would need an external antenna).

The developers documentation link doesn't work/exist.
I also can say that the right TSDZ2 firmware is not easy to find. In the releases folder I can find latest version TSDZ2-v0.57.3.hex - is this the one?

One additional remark with the DC/DC converter: it has to be the LM2596HV version - and there are many fakes around which are not the high voltage versions. And this converter is not really the best one. There is a lot of ripple voltage at the output.
@Filippods: I would be interested which 10-90V one you meant.
 
Beli said:
The developers documentation link doesn't work/exist.
I also can say that the right TSDZ2 firmware is not easy to find. In the releases folder I can find latest version TSDZ2-v0.57.3.hex - is this the one?
Click to expand...

Pretty sure you need the latest 1.1.0 - that's what I've been testing with https://github.com/OpenSourceEBike/Color_LCD/releases
And this is the apk https://github.com/OpenSourceEBike/TSDZ2_wireless/releases/tag/V0.3.1
Here are the wireless controller bootloader instructions https://github.com/OpenSourceEBike/TSDZ2_wireless-bootloader
This is the latest wireless controller binary that you install over bluetooth using 'the DFU process' in the bootloader instructions after you've installed the bootloader https://github.com/OpenSourceEBike/TSDZ2_wireless/releases/tag/V0.3.0

Hope that's right :)
 
Beli said:
I would be interested which 10-90V one you meant.
Click to expand...
I got this one but never tested it.
https://www.amazon.de/gp/product/B07X233TP2/
Available also from many other Chinese sources. It's 5 to 80V input with adjustable output 5 to 20 but I think it worths trying. I could not test it, as I have still to return my makerdiary boards and order the original blue ones.
 
Beli said:
I have a really solid aluminium heatsink at one bike too. Putting the nRF52840 Dongle inside won't work (you would need an external antenna).

The developers documentation link doesn't work/exist.
I also can say that the right TSDZ2 firmware is not easy to find. In the releases folder I can find latest version TSDZ2-v0.57.3.hex - is this the one?

One additional remark with the DC/DC converter: it has to be the LM2596HV version - and there are many fakes around which are not the high voltage versions. And this converter is not really the best one. There is a lot of ripple voltage at the output.
@Filippods: I would be interested which 10-90V one you meant.
Click to expand...
big-hailong-battery-controller-36v-48v-500w.jpg

in my battery there isn't a control board, so i have free space and the cover of the heatsink is in plastic, it should work without external antenna... or not?
DCDC: dd7818ta (5v 2.1Ah)
s-l1600.jpg
 
beemac said:
Pretty sure you need the latest 1.1.0 - that's what I've been testing with https://github.com/OpenSourceEBike/Color_LCD/releases
Click to expand...
Okay - I looked at github.com/OpenSourceEBike/TSDZ2-Smart-EBike and at the folders there is the comment "Changed version to 1.1.0" - so that's quite confusing (so obviosuly the release is not there but the source which is missing at Color_LCD).
plpetrov said:
https://www.amazon.de/gp/product/B07X233TP2/
Available also from many other Chinese sources. It's 5 to 80V input with adjustable output 5 to 20 but I think it worths trying.
Click to expand...
It*s pretty similar to the usual ones with LM2596HV and 0.8A enough for the project here. With 14s battery I would definitely prefer this one.
 
You must log in or register to reply here.

Similar threads

A
TSDZ2 Garmin integration and/or smaller display
Replies
10
Views
2,003
astronaut
astronaut
B
    • Like
arduino nano ebike controller board (TSDZ2+VESC)
Replies
8
Views
2,736
djwlindenaar
D
casainho
Xiaomi M365: VESC + modular DIY OpenSource electronics and software
Replies
3
Views
5,096
Jido
J
casainho
EasyDIY OpenSource display for EVs: TSDZ2 and Bafang M500/M600 EBike motors
5 6 7 8 9
Replies
208
Views
40,237
p0te
P
casainho
Motor Controller with Customizable Electronics, easy DIY and repair OpenSource
4 5 6 7 8
Replies
199
Views
32,747
afzal
afzal
Back
Top