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

[rananna]

@rananna and other developers,

I burned 2 times a wireless board, while it was connected to my PC using the STLinkV2 clone and the also connected to the 58V of battery, provided by the the motor controller LCD connection. The board did work for some time and I think the issue may happen when connecting / disconnecting the battery power to the motor controller.

We need to better understand this issue, as at least the final user will need to connect the wireless board to PC using STLinkV2 when flashing the bootloader.....

I do not understand.
What exactly is the issue you are seeing when burning the board?

 

[rananna]

I got the firmware ready for turn on / off the TSDZ2 motor controller, a simple command from Bluetooth or ANT will do it. Next I will implement this on the mobile app and when it is working, then we can implement on the wireless remote.

If you share with me what you did, I could implement it in the remote control for you.

 

[casainho]

I do not understand.
What exactly is the issue you are seeing when burning the board?

When the issue did happen, I could not program anymore the board. I also verified there was no more 3.3V on the board. After removing the components of the DC-DC converter and put 3.1 volts on the 3.3V line, I could not program again, so, I think the board is dead.

For the turn on / off, I have this code on the Bluetooth handler. The value must be different of 255, otherwise is ignored, like you should send only one time the assist level and other times as value 255. The same for turn on / off the motor.

static void tsdz2_write_handler_periodic(uint8_t *p_data, uint16_t len)
{
  if (p_data[0] != 255)
    ui_vars.ui8_assist_level = p_data[0];

  if (p_data[1] != 255) 
  {
    switch (p_data[1]) {
      case 1:
        // turn on TSDZ2 motor controller
        if (m_TSDZ2_power_state == TSDZ2_POWER_STATE_OFF)
          m_TSDZ2_power_state = TSDZ2_POWER_STATE_ON_START;
        break;

      case 2:
        // turn off TSDZ2 motor controller
        if (m_TSDZ2_power_state == TSDZ2_POWER_STATE_ON)
          m_TSDZ2_power_state = TSDZ2_POWER_STATE_OFF_START;
        break;
    }
  } 
}

The status of TSDZ2 motor init state are a few states and so is a complete byte, because some states can give feedback if the process blocked like wrong firmware version:

This is sent periodically every 50ms by Bluetooth: tx_data[32] = (uint8_t) g_motor_init_state; It will be MOTOR_INIT_READY when motor is ready and MOTOR_INIT_GET_MOTOR_ALIVE, when motor is disabled.

Note that to get up to MOTOR_INIT_READY, will take at least 6 seconds!!

Fatal errors:
- MOTOR_INIT_ERROR_GET_FIRMWARE_VERSION
- MOTOR_INIT_ERROR_FIRMWARE_VERSION
- MOTOR_INIT_ERROR_SET_CONFIGURATIONS

volatile motor_init_state_t g_motor_init_state = MOTOR_INIT_GET_MOTOR_ALIVE;

typedef enum {
  MOTOR_INIT_GET_MOTOR_ALIVE = 0,
  MOTOR_INIT_READY = 1,
  MOTOR_INIT_WAIT_MOTOR_ALIVE = 2,
  MOTOR_INIT_GET_MOTOR_FIRMWARE_VERSION = 3,
  MOTOR_INIT_WAIT_MOTOR_FIRMWARE_VERSION = 4,
  MOTOR_INIT_GOT_MOTOR_FIRMWARE_VERSION = 5,
  MOTOR_INIT_ERROR_GET_FIRMWARE_VERSION = 6,
  MOTOR_INIT_RECEIVED_MOTOR_FIRMWARE_VERSION = 7,
  MOTOR_INIT_ERROR_FIRMWARE_VERSION = 8,
  MOTOR_INIT_SET_CONFIGURATIONS = 9,
  MOTOR_INIT_WAIT_CONFIGURATIONS_OK = 10,
  MOTOR_INIT_WAIT_GOT_CONFIGURATIONS_OK = 11,
  MOTOR_INIT_ERROR_SET_CONFIGURATIONS = 12,
} motor_init_state_t;

 

[rananna]

@rananna and other developers,

I burned 2 times a wireless board, while it was connected to my PC using the STLinkV2 clone and the also connected to the 58V of battery, provided by the the motor controller LCD connection. The board did work for some time and I think the issue may happen when connecting / disconnecting the battery power to the motor controller.

We need to better understand this issue, as at least the final user will need to connect the wireless board to PC using STLinkV2 when flashing the bootloader....

A known issue with dc-dc converters is that cheaper designs do not incorporate adequate overvoltage protection on the output. ( When switching power supplies start up, the output voltage can take some time to settle)
The transient voltage could easily burn the board.

Check the circuit design of the converter you are using to see if it has a circuit like this on the output:
https://www.electricaltechnology.org/2019/11/simple-overvoltage-protection-circuit-using-zener-diode.html

 

[casainho]

A known issue with dc-dc converters is that cheaper designs do not incorporate adequate overvoltage protection on the output. ( When switching power supplies start up, the output voltage can take some time to settle)
The transient voltage could easily burn the board.

I understand but I think it was not that. I use the computer connected to mains, a USB charger connected to mains and then connected to STLink and then another STLink connected to computer. And the motor controller and the wireless board connected to the battery.
The motor controller, I can not program it anymore. The wireless board was also burned. I can not continue developing until I get a new motor controller, which may take like 3 weeks.

The turn on/off was almost ready, I put the Bluetooth connection on an Android snack bar as seem on the image and then the on / off button on top bar:

But I need to work more on it.

You keep doing a good job!! Thanks!!
We are going very deep on the power optimization:

 

[casainho]

I had to buy more mosfets for other future builds of the TSDZ2 wireless board and I decided to buy from Ebay the BSP296 in SOT223 - the idea is to try exchange the tiny mosfet for this new one, so the both mosfets will be SOT223 package and easier to solder - I will test on my next build and if it works, then I will updated the schematic:

 

[casainho]

@rananna and other developers,

I did a release build for the Android app: https://github.com/OpenSourceEBike/TSDZ2_wireless/releases/tag/V0.2.0

It works for current master TSDZ2_wireless firmware - must be built.

The TSDZ2 firmware is the stable V1.1.0.

This apps connects to TSDZ2 wireless board and is able to turn the motor on / off, changes configurations, assist level and see the real time data as battery voltage, motor current, wheel speed, etc.

 

[rananna]

@rananna and other developers,

I did a release build for the Android app: https://github.com/OpenSourceEBike/TSDZ2_wireless/releases/tag/V0.2.0

It works for current master TSDZ2_wireless firmware - must be built.

The TSDZ2 firmware is the stable V1.1.0.

This apps connects to TSDZ2 wireless board and is able to turn the motor on / off, changes configurations, assist level and see the real time data as battery voltage, motor current, wheel speed, etc.

Can I test the on/off sequence without connecting to a motor? It would be useful for troubleshooting the remote if there were dummy values in the tsdz2 firmware that simulate the operation of the motor.

If not, I will have to solder a board with the switching components and connect it to my ebike.

 

[casainho]

@rananna and other developers,

I did a release build for the Android app: https://github.com/OpenSourceEBike/TSDZ2_wireless/releases/tag/V0.2.0

It works for current master TSDZ2_wireless firmware - must be built.

The TSDZ2 firmware is the stable V1.1.0.

This apps connects to TSDZ2 wireless board and is able to turn the motor on / off, changes configurations, assist level and see the real time data as battery voltage, motor current, wheel speed, etc.

Can I test the on/off sequence without connecting to a motor? It would be useful for troubleshooting the remote if there were dummy values in the tsdz2 firmware that simulate the operation of the motor.

If not, I will have to solder a board with the switching components and connect it to my ebike.

Firmware must send value 1 for motor ready, 0 for motor off. Please see the changes I did to the firmware.
There other values other 0 or 1 means the motor is initializing, so, user should not press the pedals.

I still have a good work to do on the app, like a pop up warning for when motor is initializing.
Also the icons for the motor status, must be improved.

When I have this app mostly ready, then I can help you on the remote.

 

[casainho]

Wireless remote battery will work for 2 years

@rananna is doing a great job on the wireless remote and was able to optimize the power, and considering a regular usage (even with LEDs blinking), the battery will probably work for more than 2 years:

 

[rananna]

Here is a link to the pull request for those that want to read it:
https://github.com/OpenSourceEBike/ebike_wireless_remote/pull/46

 

[beemac]

The motor controller, I can not program it anymore. The wireless board was also burned. I can not continue developing until I get a new motor controller, which may take like 3 weeks.

I've had my controller seemingly die twice on me after lots of battery connection/disconnection whilst rewiring, both times it took repeated attempts flashing the firmware with stvp to recover. I almost gave up the 2nd time as it really looked like it was dead as I could neither read write or verify any tabs. After trying for about 30-45 mins I got the program mem flashing but would error when it tried the data memory. At that point I found i could program the option bytes - and once the option bytes were reset it flashed all tabs with no problems. It wasn't a cable or dongle issue the 2nd time as I also tested flashing with the new controller I ordered the 1st time it seemed to die (but as yet haven't needed to fit) - and that flashed with no problems.

* Keep flashing the full firmware many times - for me that took up to 30 mins of trying to get any response.
* If you get any response - try to program the option bytes
* Hopefully it's back to life and you can flash all tabs!

Because this has happened to me twice I've started working on a script using openocd to do the above steps (save me clicking repeatedly in stvp) - next time (if there is a next time) I'll test my 'recovery process'!

Because this has only happened twice - i can't be sure this is a process that works for anyone else - but it might be helpful...

 

[casainho]

The motor controller, I can not program it anymore. The wireless board was also burned. I can not continue developing until I get a new motor controller, which may take like 3 weeks.

I've had my controller seemingly die twice on me after lots of battery connection/disconnection whilst rewiring, both times it took repeated attempts flashing the firmware with stvp to recover. I almost gave up the 2nd time as it really looked like it was dead as I could neither read write or verify any tabs. After trying for about 30-45 mins I got the program mem flashing but would error when it tried the data memory. At that point I found i could program the option bytes - and once the option bytes were reset it flashed all tabs with no problems. It wasn't a cable or dongle issue the 2nd time as I also tested flashing with the new controller I ordered the 1st time it seemed to die (but as yet haven't needed to fit) - and that flashed with no problems.

* Keep flashing the full firmware many times - for me that took up to 30 mins of trying to get any response.
* If you get any response - try to program the option bytes
* Hopefully it's back to life and you can flash all tabs!

Because this has happened to me twice I've started working on a script using openocd to do the above steps (save me clicking repeatedly in stvp) - next time (if there is a next time) I'll test my 'recovery process'!

Because this has only happened twice - i can't be sure this is a process that works for anyone else - but it might be helpful...

Hmmm, I need to try this. Thanks!!

I am having the same issue on the TSDZ2 motor controller as also on a STM8S105 development board.

 

[rananna]

@casainho,
I have been looking to wire up a board and have a basic question.
If you have a TSDZ2 with throttle, (as I do) and therefore have a 9 pin hugo connector, why do we need an extra dc-dc converter as 5 V is available from the controller board on the white wire? It seems to me that this 5v supply could be used to power the dongle. I am probably missing something basic here, please explain.

 

[casainho]

@casainho,
I have been looking to wire up a board and have a basic question.
If you have a TSDZ2 with throttle, (as I do) and therefore have a 9 pin hugo connector, why do we need an extra dc-dc converter as 5 V is available from the controller board on the white wire? It seems to me that this 5v supply could be used to power the dongle. I am probably missing something basic here, please explain.

Well, I never thought on that and probably because I always select my motors to be 6 pins no throttle.

I would expect to pull only low current from the 5V but maybe that will be enough for the wireless board. I think it is low risk for you to try and something burn, so, would try.

 

[rananna]

@casainho,
I have been looking to wire up a board and have a basic question.
If you have a TSDZ2 with throttle, (as I do) and therefore have a 9 pin hugo connector, why do we need an extra dc-dc converter as 5 V is available from the controller board on the white wire? It seems to me that this 5v supply could be used to power the dongle. I am probably missing something basic here, please explain.

Well, I never thought on that and probably because I always select my motors to be 6 pins no throttle.

I would expect to pull only low current from the 5V but maybe that will be enough for the wireless board. I think it is low risk for you to try and something burn, so, would try.

I should have tested before asking the question. The 5v line is inactive when the motor is off. So, not an option.

 

[beemac]

I am having the same issue on the TSDZ2 motor controller as also on a STM8S105 development board.

Yes I can't be sure what you have is the same issue as me and as yet I've not tried to program any of my nrf52840's. Because it's only happened twice to me when I've been doing lots of different wiring changes it's hard to correlate cause and effect. I can't even be sure that what I've done is what recovers the device - it could be a fuse healing. But I do know the 2nd time it happened I left it for at least a day to see if it was something like that before I tried the repeated flashing to try and get it back to life.

Oh and I don't connect a battery during programming if it makes any odds - just use the 5v from the stlink adapter.

One feature that I thought of as a side-effect of the issues I had. Because both times the controller failed - the starting symptom is 'Error Brakes' - so my first troubleshooting step is to unplug the brake sensors. The 2nd time I forgot to reconnect - then went through my flash recovery process. When i got it back to life (as i was late for a ride) - I just went out. Was only the next day I realised I'd forgotten to reconnect the brake sensors. Luckily I didn't do any damage afaik (I did have a few beers so only time will tell...)

Would be good to have a warning (e.g. red background on power-on) if no brake sensors detected. Obviously a setting would be needed to disable the warning for those that don't use sensors. But might save some people from lunching their nylon gear.

I know - I should do what I suggest and if it works - do a pull request!

edit: Same goes for temp sensor too I reckon.

 

[beemac]

I had to buy more mosfets for other future builds of the TSDZ2 wireless board and I decided to buy from Ebay the BSP296 in SOT223 - the idea is to try exchange the tiny mosfet for this new one, so the both mosfets will be SOT223 package and easier to solder - I will test on my next build and if it works, then I will updated the schematic:

Ok I'll amend the PCB once we've tested the new mosfet.

* Do we want to accommodate > 60v - e.g. 72v like a poster earlier in the thread?
>> I wondered if anyone knows if the vbatt (in the 6/8 pin cable) going to the motor needs to be full voltage or just above a threshold to switch it on? If the latter then anyone using higher voltages can just lower the voltage on vbatt before the board. Tbh I can't find a suitable mosfet that does >60v anyway so maybe a moot point.

* I thought to include a full 10 pin st-link header on the PCB. So there is the option to easily include a cheap $5 stlink adapter in the enclosure with the pcb connected by a short IDC ribbon. With the SWCLK/SWDIO pins going to the nrf52840 and the SWIM pins being provided as connections to relevant speed sensor wires for motor fw updates. If put the box close enough to the motor you could have in/out connectors for the speed sensor and tap off to SWIM on the PCB.

Then we can have a single USB connection for ebike fw updates - and a single openocd script that programs both the motor and nrf52840 firmware. Getting close to plug-n-play i thought... 8)

* Are we having connections for physical up/down/menu/on/off buttons? Do I need to include wiring points for those?

edit: Other question was - should I include the 5v DC-DC converter from the ESP32 project (or other suggestion) - or keep the PCB simple and assume external 5v DC conversion?

 

[Beli]

I bring up my current project again.

I made some progress in developing my own display:



I decided to use a TTGO T4 (ESP32 with 2.2 inch LCD) being rather cheap (below 20€):



Actually it works better than expected. The LCD is not as good as the 2 inch Waveshare (especially regarding LED backlight). But buttons (I use a cut out keypad from a Set-Top-Box remote; it can be get for less than 1€) work reasonable well, better than the ones from VLCD6 or SW102. Using gloves during winter it's even easier than at the VLCD5 remote to hit the right button.
I still have to cut out a piece of glas from an (anti-reflex) picture frame glas cover and would finally fix the buttons and glas with silicone so that the cover should be quite water resistant.

Now the hardware side gets clearer the question is: how to connect to the motor?

The TTGO brings a lot of features on one small board (unfortunately no RTC, I consider adding a small board). There even would be the option to build a completely wireless display (battery connector and charger/soc are as well on board).
I won't go this way and at least connect power supply from the main battery because it's easier to handle but there could be a branch for that..

Up to now I used the emmebrusa version and ESP32 (with complete board from Asia) by mspider65. One way could be using the mspider65 software and adding LCD drivers. Supporting the current project here would be another.

So one question @casainho: would it be possible to not only connect the smartphone by bluetooth but also at the same time establishing a second bluetooth connection (to the display)?

Asking that I have to say till now I only have little experience in programming simple PIC microcontrollers. For first trials I used here Arduino.

 

[casainho]

I had to buy more mosfets for other future builds of the TSDZ2 wireless board and I decided to buy from Ebay the BSP296 in SOT223 - the idea is to try exchange the tiny mosfet for this new one, so the both mosfets will be SOT223 package and easier to solder - I will test on my next build and if it works, then I will updated the schematic:

Ok I'll amend the PCB once we've tested the new mosfet.

* Do we want to accommodate > 60v - e.g. 72v like a poster earlier in the thread?
>> I wondered if anyone knows if the vbatt (in the 6/8 pin cable) going to the motor needs to be full voltage or just above a threshold to switch it on? If the latter then anyone using higher voltages can just lower the voltage on vbatt before the board. Tbh I can't find a suitable mosfet that does >60v anyway so maybe a moot point.

* I thought to include a full 10 pin st-link header on the PCB. So there is the option to easily include a cheap $5 stlink adapter in the enclosure with the pcb connected by a short IDC ribbon. With the SWCLK/SWDIO pins going to the nrf52840 and the SWIM pins being provided as connections to relevant speed sensor wires for motor fw updates. If put the box close enough to the motor you could have in/out connectors for the speed sensor and tap off to SWIM on the PCB.

Then we can have a single USB connection for ebike fw updates - and a single openocd script that programs both the motor and nrf52840 firmware. Getting close to plug-n-play i thought... 8)

* Are we having connections for physical up/down/menu/on/off buttons? Do I need to include wiring points for those?

edit: Other question was - should I include the 5v DC-DC converter from the ESP32 project (or other suggestion) - or keep the PCB simple and assume external 5v DC conversion?

Maybe you should build the DIY wireless board and help us test it, then we all will learn a lot with with, on the hardware side and usage, that would provide the answers you are asking.

 

[casainho]

So one question @casainho: would it be possible to not only connect the smartphone by bluetooth but also at the same time establishing a second bluetooth connection (to the display)?

I am a bit confused, but assuming you want to connect by Bluetooth, your display can behave like the Android app, should implement the same things: configurations and should display data to user.

You can either look an the Android app sources or to the TSDZ2 wireless board firmware sources, to see how the communications are implemented.

One question: if I want to build a new EBike with TSDZ2, why would I choose to use build and use your display over the 860C display?

The TSDZ2 wireless board has an RTC but no battery, anyway it will always be connected to the EBike battery, so maybe you can grab the time for the it.

Maybe the display could be a fully water proof block, if it would implement the EBike wireless standard, it could work like the Garmin GPS display, the remote would change the pages of data and remote already turn on/off and change the assist level, so no buttons on the display, maybe a sensor to detect vibrations to start the display.
The display configurations itself could be changed on a specific mobile app, just like for the wireless board configurations.

 

[Beli]

One question: if I want to build a new EBike with TSDZ2, why would I choose to use build and use your display over the 860C display

First it's my personal preference and aim: I want to connect to smart bms and display the remaining capacity directly. 850C can't do that. And I prefer a smaller display for everyday use. A SW102 is also not an alternative for me (not sure if there is enough code space left, don't like the buttons, screen size is also quite limited - and so on).

if it would implement the EBike wireless standard, it could work like the Garmin GPS display, the remote would change the pages of data and remote already turn on/off and change the assist level, so no buttons on the display

I don't want an additional device with buttons. Simply one small device for everyday use with features that aren't available yet (first of all: connecting to the smart bms).

The display configurations itself could be changed on a specific mobile app, just like for the wireless board configurations.

That's one reason why I also want to use the smartphone connection preferable at the same time.
So still the questions: are two connections possible at the same time?

 

[casainho]

One question: if I want to build a new EBike with TSDZ2, why would I choose to use build and use your display over the 860C display

First it's my personal preference and aim: I want to connect to smart bms and display the remaining capacity directly. 850C can't do that. And I prefer a smaller display for everyday use. A SW102 is also not an alternative for me (not sure if there is enough code space left, don't like the buttons, screen size is also quite limited - and so on).

if it would implement the EBike wireless standard, it could work like the Garmin GPS display, the remote would change the pages of data and remote already turn on/off and change the assist level, so no buttons on the display

I don't want an additional device with buttons. Simply one small device for everyday use with features that aren't available yet (first of all: connecting to the smart bms).

The display configurations itself could be changed on a specific mobile app, just like for the wireless board configurations.

That's one reason why I also want to use the smartphone connection preferable at the same time.
So still the questions: are two connections possible at the same time?

Now I remember, the BMS.

I don´t think is possible to connect 2 Bluetooth central devices to the wireless board: mobile phone and the display.

On the NRF SDK there are examples for both central and peripheral at the same time, so, I think the TSDZ2 wireless board could be a central and connect to the BMS peripheral to get the BMS data. In parallel the TSDZ2 wireless board is already a peripheral to where the central smart phone already connects - to resume, I think the TSDZ2 wireless board should connect to BMS and then the BMS data would be available to the mobile app or the display, but the user would use or the mobile app or the display (the display would need a button to change between Bluetooth modes, for be a peripheral to connect to the mobile app for configurations or as central to connect to the TSDZ2 wireless board.

 

[Beli]

On the NRF SDK there are examples for both central and peripheral at the same time, so, I think the TSDZ2 wireless board could be a central and connect to the BMS peripheral to get the BMS data.

That probably would be the best solution.
If one has the smart BMS there should be a way to configure which BMS to use (to which MAC address to connect).

TSDZ2 wireless board should connect to BMS and then the BMS data would be available to the mobile app or the display, but the user would use or the mobile app or the display (the display would need a button to change between Bluetooth modes

Well - as I already asked before personally I would prefer RX and TX pins for the display.

(the display would need a button to change between Bluetooth modes, for be a peripheral to connect to the mobile app for configurations

I read that it should be possible for the ESP32 to be both, Bluetooth client and master, at the same time. So connecting the display to the NRF and passing data through the display and making it available for smartphone could be a solution.

 

[casainho]

On the NRF SDK there are examples for both central and peripheral at the same time, so, I think the TSDZ2 wireless board could be a central and connect to the BMS peripheral to get the BMS data.

That probably would be the best solution.
If one has the smart BMS there should be a way to configure which BMS to use (to which MAC address to connect).

And would be important because it would work for every user on this project and not only for the users of your display.

TSDZ2 wireless board should connect to BMS and then the BMS data would be available to the mobile app or the display, but the user would use or the mobile app or the display (the display would need a button to change between Bluetooth modes

Well - as I already asked before personally I would prefer RX and TX pins for the display.

I hope you understand this is a project for wireless. I hope that is the reason why you are here and why you choose to use a board for your display with wireless - I do not see any disadvantage in using the Bluetooth on your board.

(the display would need a button to change between Bluetooth modes, for be a peripheral to connect to the mobile app for configurations

I read that it should be possible for the ESP32 to be both, Bluetooth client and master, at the same time. So connecting the display to the NRF and passing data through the display and making it available for smartphone could be a solution.

That would be a second system between the motor controller and the mobile app. Current there is already a lag on the data sent from the motor to the mobile app because the wireless board is in the middle, adding another board on the middle (of your display) should be avoided.