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

[beemac]

I connect VBUS, GND on the nrf to the 5V, GND pins on the stlink adapter. No other power is applied to the circuit.

But you flashed the bootloader before wiring the board or when it was wired?

Is it possible to flash the main firmware over the SWD link? It's not that straightforward to use the nordic tools - i can work on an openocd script if it's not a non starter...

 

[casainho]

I connect VBUS, GND on the nrf to the 5V, GND pins on the stlink adapter. No other power is applied to the circuit.

But you flashed the bootloader before wiring the board or when it was wired?

Is it possible to flash the main firmware over the SWD link? It's not that straightforward to use the nordic tools - i can work on an openocd script if it's not a non starter...

The plan is to flash only one time the bootloader and then always update the firmware wireless.

I agree the Nordic mobile app is a bit technical and I think it was developed for technical users like us. We have all the source code from Nordic in the case we want to develop our own mobile app to update the firmware, which I think we should not because there are more important things to do.

 

[beemac]

Here is the updated schematic based on our prototypes (please test that schematic as possible, like removing any resistors).



I did a commit with this schematic update but later I need to start thinking on the final documentation.

I wanted to know if that DC-DC would for some reason pull down / make not working the VBUS voltage from the STLinkV2. Now it is clear to me so we can write that later on the final documentation.

Ok yes it works fine with my DC converter - can't speak for any other.

Schematic isn't quite right i think - pins for the BSP296. The big tab (Drain) is pin 4 and is also connected to pin 2 (middle of the three). Gate is pin 1 the leftmost bottom pin (if the tab is at the top) - that should be connected to pin 4 on the nrf. Pin 3 - the rightmost bottom pin is connected to ground.

edit: maybe i'm going mad - it has been a long day over the soldering iron. But I think the 4140 isn't right either. Pin 1 (left bottom pin if big tab is up) on my 4140 connects to pin 4 on the BSP296 (the big tab)...

Brake line is new on pin 3 of the nrf- what's that used for? Is it just for 'brakes' display message? I thought the brake function was direct to the motor?

 

[beemac]

I connect VBUS, GND on the nrf to the 5V, GND pins on the stlink adapter. No other power is applied to the circuit.

But you flashed the bootloader before wiring the board or when it was wired?

Is it possible to flash the main firmware over the SWD link? It's not that straightforward to use the nordic tools - i can work on an openocd script if it's not a non starter...

The plan is to flash only one time the bootloader and then always update the firmware wireless.

I agree the Nordic mobile app is a bit technical and I think it was developed for technical users like us. We have all the source code from Nordic in the case we want to develop our own mobile app to update the firmware, which I think we should not because there are more important things to do.

Well that was why I wondered if using SWD was easier all round. I still plan to leave my cheap £5 stlink adapter in the case with the wireless board ultimately. I'll tap the speed sensor and connect the motor controller fw update wires to SWIM - and the wireless board to SWDIO/SWCLK - then i can use a single openocd script to update both over a USB cable. That lowers the bar of adoption massively imho.

 

[casainho]

And I did a small update to the project page: https://opensourceebike.github.io/

Here is the updated schematic based on our prototypes (please test that schematic as possible, like removing any resistors).



I did a commit with this schematic update but later I need to start thinking on the final documentation.

I wanted to know if that DC-DC would for some reason pull down / make not working the VBUS voltage from the STLinkV2. Now it is clear to me so we can write that later on the final documentation.

Ok yes it works fine with my DC converter - can't speak for any other.

Schematic isn't quite right i think - pins for the BSP296. The big tab (Drain) is pin 4 and is also connected to pin 2 (middle of the three). Gate is pin 1 the leftmost bottom pin (if the tab is at the top) - that should be connected to pin 4 on the nrf. Pin 3 - the rightmost bottom pin is connected to ground.

edit: maybe i'm going mad - it has been a long day over the soldering iron. But I think the 4140 isn't right either. Pin 1 (left bottom pin if big tab is up) on my 4140 connects to pin 4 on the BSP296 (the big tab)...

Brake line is new on pin 3 of the nrf- what's that used for? Is it just for 'brakes' display message? I thought the brake function was direct to the motor?

Thanks, I just corrected the schematic. Are you sure your board is wired correctly??

The brake line will be controlled by the NRF52840, so when it receives brake command (from the wireless remote), it will enable the TSDZ2 brake signal. If you want to use this signal, to wire a regular brake sensor to the wireless board, I think a resistor in series with the line of NRF52840, should be added. Anyway, the idea is not create many options / branches of the system, otherwise we would never finish the project and would be to complex, we would take our time discussing all the possibilities and give support to users.

 

[beemac]

And I did a small update to the project page: https://opensourceebike.github.io/

Thanks, I just corrected the schematic. Are you sure your board is wired correctly??

The brake line will be controlled by the NRF52840, so when it receives brake command (from the wireless remote), it will enable the TSDZ2 brake signal. If you want to use this signal, to wire a regular brake sensor to the wireless board, I think a resistor in series with the line of NRF52840, should be added. Anyway, the idea is not create many options / branches of the system, otherwise we would never finish the project and would be to complex, we would take our time discussing all the possibilities and give support to users.

Schematic looks better - I'll have a proper check in the morning.

I can't be 100% sure that my board works correctly - we'll see tomorrow if the weather is ok but the video shows the voltage control working ok as far as I can see.

Ok so pin 3 is brake output to the motor - so my arrangement where i have physical brakes will work. Thanks just wanted to make sure I wasn't doing something stupid that meant my brake sensors wouldn't work.

 

[beemac]

Ok so pin 3 is brake output to the motor - so my arrangement where i have physical brakes will work. Thanks just wanted to make sure I wasn't doing something stupid that meant my brake sensors wouldn't work.

Does the android app show 'Brakes' when the motor controller receives a brake signal? Only asking as need to confirm they are working before I test. don't want to damage the nylon gear...

 

[casainho]

Ok so pin 3 is brake output to the motor - so my arrangement where i have physical brakes will work. Thanks just wanted to make sure I wasn't doing something stupid that meant my brake sensors wouldn't work.

Does the android app show 'Brakes' when the motor controller receives a brake signal? Only asking as need to confirm they are working before I test. don't want to damage the nylon gear...

I just corrected the schematic, again. It seems to be equal to your board picture:


No, the mobile app currently does not show brake state.
The mobile app is ready to show brake and lights state but the firmware is not sending the TSDZ2 brake state to the mobile app. There is yet a lot of small things to do

 

[beemac]

I just corrected the schematic, again. It seems to be equal to your board picture:


No, the mobile app currently does not show brake state.
The mobile app is ready to show brake and lights state but the firmware is not sending the TSDZ2 brake state to the mobile app. There is yet a lot of small things to do

Schematic looks good!

Ok thanks, yea appreciate there's a lot to do - I'll just be careful, not going to ride far with the wireless setup - just round the block I think for now.

Circuit looks to be all working though - did a quick test before I put my life on the line!

[youtube]atKwk1H9Lm8[/youtube]

 

[beemac]

OK, am back and still alive. Works great!

Observations:

* 7 assist settings, not 20 - more fyi for anyone else testing - i thought my phone had locked up when it wouldn't go above 7...
* variables update more slowly than on the 860c and seem to be more erratic. Might be the speed of my not-very-new phone..
* Human power reading seemed quite high (250w+ at times) - but I've not really watched that on the 860c so not sure how different that is.
* my brake setup doesn't seem to work. I think this is because I disconnected my 860c from the wiring loom. The brake signal goes into the display and out to the motor - so I'll need to make a loopback plug to replace the 860c with in the interim.

It's amazing how quickly you forget about the brake sensors (or lack of) - so I stopped testing and came back in as I don't like that clicking noise when I forget and brake under power!

 

[beemac]

The brake line will be controlled by the NRF52840, so when it receives brake command (from the wireless remote), it will enable the TSDZ2 brake signal. If you want to use this signal, to wire a regular brake sensor to the wireless board, I think a resistor in series with the line of NRF52840, should be added. Anyway, the idea is not create many options / branches of the system, otherwise we would never finish the project and would be to complex, we would take our time discussing all the possibilities and give support to users.

I had a lightbulb moment - and finally understand the goal of this project properly. I assumed you were 'adding' wireless to the tsdz2. I now understand that your aim is for all comms to/from the motor to be wireless. So 'wireless only' effectively...

I'll try to stop making suggestions involving wires!

 

[casainho]

OK, am back and still alive. Works great!

Observations:

* 7 assist settings, not 20 - more fyi for anyone else testing - i thought my phone had locked up when it wouldn't go above 7...
* variables update more slowly than on the 860c and seem to be more erratic. Might be the speed of my not-very-new phone..
* Human power reading seemed quite high (250w+ at times) - but I've not really watched that on the 860c so not sure how different that is.
* my brake setup doesn't seem to work. I think this is because I disconnected my 860c from the wiring loom. The brake signal goes into the display and out to the motor - so I'll need to make a loopback plug to replace the 860c with in the interim.

It's amazing how quickly you forget about the brake sensors (or lack of) - so I stopped testing and came back in as I don't like that clicking noise when I forget and brake under power!

Thanks for the video and the report. You now have the hardware working. We will need to keep developing and updating the TSDZ2 wireless board firmware and mobile app, but this updates are very easy as they are wireless - so you do not need to mess up with a programmer or such.
You are missing the wireless remote, and I understand you do not want one. Anyway, we do not have it working yet.

- 7 assist levels because the Wireless EBike standard limits to that max 7 number. This are ok, but user will probably feel the need to customize this values.

- yes, it is supposed the variables to be slower updating, as the wireless board are now another system between the motor and your display (mobile phone)

 

[casainho]

I had a lightbulb moment - and finally understand the goal of this project properly. I assumed you were 'adding' wireless to the tsdz2. I now understand that your aim is for all comms to/from the motor to be wireless. So 'wireless only' effectively...

I'll try to stop making suggestions involving wires!

Yes, it is very import to test in reality to better understand.

Now is important for you to understand as an user, where do you prefer to place the wireless board... Do you prefer a very short cable? very small case?

Would you prefer to not using your mobile phone (using it only sporadically for configurations) and use only a remote to turn on/off the motor, change assist levels and see the battery SOC?

 

[rananna]

You are missing the wireless remote, and I understand you do not want one. Anyway, we do not have it working yet.

I am implementing power control now. I expect it will be ready in a few days.

 

[casainho]

You are missing the wireless remote, and I understand you do not want one. Anyway, we do not have it working yet.

I am implementing power control now. I expect it will be ready in a few days.

Then I will build my remote and be ready to test!! And on next days I hope to have the full control on the wireless board also (power on/off, assist level and battery state).

@ranana, we really need to put all the files on the same repository, as I think the battery SOC will be the same on remote as on the wireless board, like at startup, the LEDs could blink from 1 to 10, long blink on last value, like if 50%, only blink 5 times and the color would be orange... would this work for a user to understand? -- after having this defined, we could trigger at anytime, maybe a button combination or only at startup.

 

[beemac]

Now is important for you to understand as an user, where do you prefer to place the wireless board... Do you prefer a very short cable?

Would you prefer to not using your mobile phone (using it only sporadically for configurations) and use only a remote to turn on/off the motor, change assist levels and see the battery SOC?

I'm planning to mount mine as close to the motor as possible - in a case with a few other components.

* 5A 12v DC converter and 6v relay for lights
* STLINK connected to speed sensor for motor flashing
* wireless board

My personal goal is to make a reasonably cheap, easy to assembly single box that fixes all the reasons why my friends wouldn't/couldn't buy a tsdz2 and install the OS fw.

Since i've got spare buttons and nrf52840 I might make a remote - but (other than contributing to this project) - it does feel like adding more complexity to my bike for not much benefit. Even then I might still keep physical wires for brake sensors since to me they are a critical part of the bike's reliability and so I think wires are better.

I'm not sure i'd want anything else on the handlebars permanently except the remote/buttons. I rarely change assist level - mostly I use the buttons to turn street legal mode on/off. Since i set the bike to switch on in legal mode.

If I'm just biking around locally most of the time I don't need SOC or any info really. If I'm out on a longer ride I'd want the phone on the bars for maps and so on anyway.

Does mean for the first time I can see the point of a phone that can run two apps split screen...

 

[casainho]

* STLINK connected to speed sensor for motor flashing

Motor firmware can be flashed by the wireless board itself, like TSDZ2-ESP32 project does.

Since i've got spare buttons and nrf52840 I might make a remote - but (other than contributing to this project) - it does feel like adding more complexity to my bike for not much benefit. Even then I might still keep physical wires for brake sensors since to me they are a critical part of the bike's reliability and so I think wires are better.

Yes, I also think brakes are very important. Maybe the remote may keep a LED blinking if it is not connected, to alert the system is not ready to use. Once the remote keeps the continuous communication with the wireless board, then the brake signal will not fail.

Thanks for the feedback.

 

[beemac]

* STLINK connected to speed sensor for motor flashing

Motor firmware can be flashed by the wireless board itself, like TSDZ2-ESP32 project does.

Yes, I also think brakes are very important. Maybe the remote may keep a LED blinking if it is not connected, to alert the system is not ready to use. Once the remote keeps the continuous communication with the wireless board, then the brake signal will not fail.

Thanks for the feedback.

My worry about relying on the wireless board to flash is if my problem where the motor controller dies happens again - would i be able to run my 'recovery process'? I just know that will happen once I've routed all my cables neatly and hidden them with tape. Although it's rare - i think it's worth covering that eventuality. It's also one of those things that I think if it happened to someone less technical - they may well stop using the bike - so worth putting in a simple method of recovery.

Great idea for the remote - flashing LED if not connected would make me feel better!

 

[beemac]

* my brake setup doesn't seem to work. I think this is because I disconnected my 860c from the wiring loom. The brake signal goes into the display and out to the motor - so I'll need to make a loopback plug to replace the 860c with in the interim.

I think i've worked out why my brake sensors don't work - i know it's not core to the project but might help people with testing without the remote. I have the bafang wiring harness and sensors - and I didn't pass through GND...

Just making that change to the wiring - also bypassing my extra resistors so I'm testing the current board spec.

Only difference between my board and the schematic now will be a 200mA SMD fuse on vbus.

 

[beemac]

I have the bafang wiring harness and sensors - and I didn't pass through GND...

Just making that change to the wiring - also bypassing my extra resistors so I'm testing the current board spec.

Hmmm... ok - so now my brake sensors work - and there is a notification on the Android app - a 'B' appears between the battery indicator and the time when the sensors are activated!

But... i get no assist any more - I did briefly but then not again... i've rebooted a few times - still nothing. Yellow button is still going green - so comms is working...

I disconnected the brake sensors just in case they were the cause - but no.

I'll double check everything and maybe put the resistors back if still not working...

Edit - ok, putting the resistors back didn't make any difference.

It looks like the cause might be a bug in the android app or fw - if you change assist level twice - assist no longer works until you power cycle... Will have more of a play later.

Edit: Ok looks like if you select assist level 3 - that kills assist until you turn the motor on/off... i'll post a video

Also the speed goes awry above (i assume) 25.5 and removes the decimal point - so reports speeds as 256+

Video showing the above - can also just about see the 'B' for brake indicator at the top of the screen.

Vid could be clearer - if I didn't get my hand in the way all the time - hopefully you can see enough!

One other observation - can the app detect the state of the motor whenever the app gets focus or periodically? I found it's easy for the app to get out of sync with the motor. e.g. if you switch on the motor with the app - then power the bike on/off. The app still thinks the motor is on - so you have to restart the app to get control back.

[youtube]_BIltzlHkxk[/youtube]

 

[casainho]

It looks like the cause might be a bug in the android app or fw - if you change assist level twice - assist no longer works until you power cycle... Will have more of a play later.

Edit: Ok looks like if you select assist level 3 - that kills assist until you turn the motor on/off... i'll post a video

Hmmm, I can´t see why on the code... are you sure it happens only when decreasing like from 4 to level 3? if you find other combinations will trigger this issue, please report so I can find it.

Also the speed goes awry above (i assume) 25.5 and removes the decimal point - so reports speeds as 256+

Good catch!

V0.3.1 should solve that:
https://github.com/OpenSourceEBike/TSDZ2_wireless/releases/tag/V0.3.1

One other observation - can the app detect the state of the motor whenever the app gets focus or periodically? I found it's easy for the app to get out of sync with the motor. e.g. if you switch on the motor with the app - then power the bike on/off. The app still thinks the motor is on - so you have to restart the app to get control back.

Yes, that´s it, periodically every 50ms the motor state and other variables are sent - I need to check this, as it should not be hard to do.

 

[beemac]

It looks like the cause might be a bug in the android app or fw - if you change assist level twice - assist no longer works until you power cycle... Will have more of a play later.

Edit: Ok looks like if you select assist level 3 - that kills assist until you turn the motor on/off... i'll post a video

Hmmm, I can´t see why on the code... are you sure it happens only when decreasing like from 4 to level 3? if you find other combinations will trigger this issue, please report so I can find it.

Just went and had another go. Does seem to be the case...

I tried 0,1,2,1,0,1,2 - all works - until you go to 3 -then the assist stops shortly after letting it settle on 3.

Same happens if you motor on/off and start above 4. Can go to 4,5,6,7,6,5,4 - all works - again until you go to 3 and the assist stops.

I'll see if I can take a better video...

Vid uploading - but definitely is the case - if you motor on/off with assist already at 3 on the app - you don't get any assist.

Never posted so many youtube videos in my entire life!

Edit: just checked my config to make sure that assist level 3 wasn't 0.00 in the config. But that wouldn't stop it working until a power cycle anyway...

[youtube]pHxDbmoqyUw[/youtube]

 

[casainho]

Thanks for the video and all the tests.

As we see the assist level on the mobile app changing, that is the value inside the TSDZ2 wireless board firmware, so, it is changing as expected.

I think the issue may be on this piece of code, sending assist level to the TSDZ2 motor controller:

case FRAME_TYPE_PERIODIC:
if (rt_vars.ui8_walk_assist) {
ui8_usart1_tx_buffer[3] = (uint8_t) rt_vars.ui8_walk_assist_level_factor[((rt_vars.ui8_assist_level) - 1)];
ui8_usart1_tx_buffer[4] = 0;
} else if (rt_vars.ui8_assist_level) {
uint16_t ui16_temp = rt_vars.ui16_assist_level_factor[((rt_vars.ui8_assist_level) - 1)];
ui8_usart1_tx_buffer[3] = (uint8_t) (ui16_temp & 0xff);
ui8_usart1_tx_buffer[4] = (uint8_t) (ui16_temp >> 8);
} else {
// if rt_vars.ui8_assist_level = 0, send 0!! always disable motor when assist level is 0
ui8_usart1_tx_buffer[3] = 0;
ui8_usart1_tx_buffer[4] = 0;
}

 

[beemac]

Thanks for the video and all the tests.

As we see the assist level on the mobile app changing, that is the value inside the TSDZ2 wireless board firmware, so, it is changing as expected.

I think the issue may be on this piece of code, sending assist level to the TSDZ2 motor controller:

case FRAME_TYPE_PERIODIC:
if (rt_vars.ui8_walk_assist) {
ui8_usart1_tx_buffer[3] = (uint8_t) rt_vars.ui8_walk_assist_level_factor[((rt_vars.ui8_assist_level) - 1)];
ui8_usart1_tx_buffer[4] = 0;
} else if (rt_vars.ui8_assist_level) {
uint16_t ui16_temp = rt_vars.ui16_assist_level_factor[((rt_vars.ui8_assist_level) - 1)];
ui8_usart1_tx_buffer[3] = (uint8_t) (ui16_temp & 0xff);
ui8_usart1_tx_buffer[4] = (uint8_t) (ui16_temp >> 8);
} else {
// if rt_vars.ui8_assist_level = 0, send 0!! always disable motor when assist level is 0
ui8_usart1_tx_buffer[3] = 0;
ui8_usart1_tx_buffer[4] = 0;
}

Only thing I can see here that i'm not sure about - if the assist_level_factor is a ui16 - shouldn't you be x2 the ui8 assist_level to read the correct value from the array? Ignore me - it's an array of ui16...

I have installed the toolchain - not compiled the fw yet - so am hoping that I can contribute something. C++ isn't my forte. C# i find much more straightforward...

edit: ok - have some actual useful info. If you change the assist level 3 in config from 0.28 to something else - i've tried a couple of values - all works ok. If you set it back to 0.28 - it stops working....

 

[rananna]

Great idea for the remote - flashing LED if not connected would make me feel better!

Actually that is already implemented.
Leds flash if not connected by ANT and reconnection attempts are made for 5 minutes automatically. Any button press will start another 5 minute reconnection attempt.
The connection is darn good though; I have never seen a failed connection when both the remote and no boards are powered.