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

[rananna]

Nice video and I didn't yet see the lights enable on the mobile app!!

Ok - latest in my series of riveting videos, bit shaky at the start but settles down.

Hopefully is a bit clearer to see - have also fixed an issue with walk assist - and added power on/off...

[youtube]4c6j11HJ6tE[/youtube]

looks great!
I will implement the walk assist and light support in the wireless remote today.

 

[beemac]

Nice video and I didn't yet see the lights enable on the mobile app!!

Ok - latest in my series of riveting videos, bit shaky at the start but settles down.

Hopefully is a bit clearer to see - have also fixed an issue with walk assist - and added power on/off...

[youtube]4c6j11HJ6tE[/youtube]

looks great!
I will implement the walk assist and light support in the wireless remote today.

Thanks!

Let me know if there's anything I should watch out for or change to make your life easier - i presume you just modify the ui params same as I do - then the usual cycle copies those to the realtime layer and sends them to the app...

I'll do a bit more testing - then I've got some editing to do as the code is pretty much as-is from the 860c and so mentions lots of things about screens, screen presses etc.

Separately I am having a weird issue with my phone - not sure if I'm the only person to have two tsdz2_wireless paired to my phone - that might be aggravating things.

Seems to be when I go out of range - I just went to the shop but left my bike on whilst I went in (taking phone with me) - and when I came out of the shop and back into range - the phone went into a loop trying to pair with the TSDZ2 - "Tap to pair with TSDZ2' - then if I tap Pair - i get an error 'Pairing rejected by TSDZ2'. Repeat...

Had to go back into bluetooth settings on phone - re-pair at phone level, then restart ebike app - setup bluetooth, choose the correct tsdz2 - then all was well again...

Got home, put the bike away but forgot to turn it off - and phone starting pinging again with pairing requests once I got back in the house...

 

[rananna]

Nice video and I didn't yet see the lights enable on the mobile app!!

Ok - latest in my series of riveting videos, bit shaky at the start but settles down.

Hopefully is a bit clearer to see - have also fixed an issue with walk assist - and added power on/off...

[youtube]4c6j11HJ6tE[/youtube]

looks great!
I will implement the walk assist and light support in the wireless remote today.

Thanks!

Let me know if there's anything I should watch out for or change to make your life easier - i presume you just modify the ui params same as I do - then the usual cycle copies those to the realtime layer and sends them to the app...

I'll do a bit more testing - then I've got some editing to do as the code is pretty much as-is from the 860c and so mentions lots of things about screens, screen presses etc.

Separately I am having a weird issue with my phone - not sure if I'm the only person to have two tsdz2_wireless paired to my phone - that might be aggravating things.

Seems to be when I go out of range - I just went to the shop but left my bike on whilst I went in (taking phone with me) - and when I came out of the shop and back into range - the phone went into a loop trying to pair with the TSDZ2 - "Tap to pair with TSZD2' - then if I tap Pair - i get an error 'Pairing rejected by TSDZ2'. Repeat...

Had to go back into bluetooth settings on phone - re-pair at phone level, then restart ebike app - setup bluetooth, choose the correct tszd2 - then all was well again...

Got home, put the bike away but forgot to turn it off - and phone starting pinging again with pairing requests once I got back in the house...

I also have seen some occasional weirdness with the app that required re-pairing.
Haven't been able to track any issue down though.
BTW, have you pushed your changes to the repo?

 

[beemac]

Ok - latest in my series of riveting videos, bit shaky at the start but settles down.

Hopefully is a bit clearer to see - have also fixed an issue with walk assist - and added power on/off...

[youtube]4c6j11HJ6tE[/youtube]

looks great!
I will implement the walk assist and light support in the wireless remote today.

Thanks!

Let me know if there's anything I should watch out for or change to make your life easier - i presume you just modify the ui params same as I do - then the usual cycle copies those to the realtime layer and sends them to the app...

I'll do a bit more testing - then I've got some editing to do as the code is pretty much as-is from the 860c and so mentions lots of things about screens, screen presses etc.

Separately I am having a weird issue with my phone - not sure if I'm the only person to have two tsdz2_wireless paired to my phone - that might be aggravating things.

Seems to be when I go out of range - I just went to the shop but left my bike on whilst I went in (taking phone with me) - and when I came out of the shop and back into range - the phone went into a loop trying to pair with the TSDZ2 - "Tap to pair with TSZD2' - then if I tap Pair - i get an error 'Pairing rejected by TSDZ2'. Repeat...

Had to go back into bluetooth settings on phone - re-pair at phone level, then restart ebike app - setup bluetooth, choose the correct tszd2 - then all was well again...

Got home, put the bike away but forgot to turn it off - and phone starting pinging again with pairing requests once I got back in the house...

I also have seen some occasional weirdness with the app that required re-pairing.
Haven't been able to track any issue down though.
BTW, have you pushed your changes to the repo?

Ok i'll keep an eye on it - I also wonder how easy if would be to re-pair if you were in a group of users and two or more people trying at once - could get very confusing (and possibly dangerous) if bikes and apps got mixed up...

I know you can rename the bluetooth device in your paired list on phone - but would be nice to be able to set your own bike name for pairing... anyway one for the future perhaps list!

Sorry - just pushed my changes https://github.com/4var1/TSDZ2_wireless/tree/adding-wired-buttons-and-brakes

 

[rananna]

Sorry - just pushed my changes https://github.com/4var1/TSDZ2_wireless/tree/adding-wired-buttons-and-brakes

Are you ready to do a PR to the main repo?
I would like to pull it from there...

 

[beemac]

Sorry - just pushed my changes https://github.com/4var1/TSDZ2_wireless/tree/adding-wired-buttons-and-brakes

Are you ready to do a PR to the main repo?
I would like to pull it from there...

Oh no not really - needs a bit of tidying up - I'll hopefully get that done after work and can do a PR later or tomorrow..

Question - i've got code copied in there for virtual throttle at the moment - is that needed? It's not something i've tested - not even sure what it does...

Virtual throttle: in "Motor max power" mode, while pressing UP, long press ON/OFF

 

[casainho]

Virtual throttle: in "Motor max power" mode, while pressing UP, long press ON/OFF

We need to improve the documentation.

Virtual throttle is like that, a throttle that you control only with up and down buttons -- this is very nice for the ones like me that does not have a throttle but may need it when something fail like main gear fail and you can not pedal but need to return back home

 

[beemac]

Virtual throttle: in "Motor max power" mode, while pressing UP, long press ON/OFF

We need to improve the documentation.

Virtual throttle is like that, a throttle that you control only with up and down buttons -- this is very nice for the ones like me that does not have a throttle but may need it when something fail like main gear fail and you can not pedal but need to return back home

Ok thanks - I'll give it a test then if it's something that's used.

 

[beemac]

Virtual throttle: in "Motor max power" mode, while pressing UP, long press ON/OFF

We need to improve the documentation.

Virtual throttle is like that, a throttle that you control only with up and down buttons -- this is very nice for the ones like me that does not have a throttle but may need it when something fail like main gear fail and you can not pedal but need to return back home

Ok thanks - I'll give it a test then if it's something that's used.

How does it work - when you're actually in VT mode what do the buttons do... up makes the motor spin? You need to be in assist level 7 before the key combo works to activate?

 

[casainho]

How does it work - when you're actually in VT mode what do the buttons do... up makes the motor spin? You need to be in assist level 7 before the key combo works to activate?

Long press up for it to increase like 5%, and each up or down click to increase / decrease. Keep pressing to maintain, if not pressing for over 1 second, throttle goes to 0.

This is important to have a display, to understand and see the throttle value.

 

[beemac]

How does it work - when you're actually in VT mode what do the buttons do... up makes the motor spin? You need to be in assist level 7 before the key combo works to activate?

Long press up for it to increase like 5%, and each up or down click to increase / decrease. Keep pressing to maintain, if not pressing for over 1 second, throttle goes to 0.

This is important to have a display, to understand and see the throttle value.

You mean a garmin display or similar? Not the app?

Looks like i've not copied something across - as there's no way to get into alternate_field_state == 7 which is needed to activate VT. Just working my way through the state machine to see what's missing...

 

[beemac]

How does it work - when you're actually in VT mode what do the buttons do... up makes the motor spin? You need to be in assist level 7 before the key combo works to activate?

Long press up for it to increase like 5%, and each up or down click to increase / decrease. Keep pressing to maintain, if not pressing for over 1 second, throttle goes to 0.

This is important to have a display, to understand and see the throttle value.

You mean a garmin display or similar? Not the app?

Looks like i've not copied something across - as there's no way to get into alternate_field_state == 7 which is needed to activate VT. Just working my way through the state machine to see what's missing...

Yea is a pain to debug without a display! I can get in and out of alternative field mode now - assist level stops being changeable when in - but then I can't get any life out of the motor... should the motor start spinning as soon as you go into VT mode?

Also - whilst I'm doing this do you want me to bring across any other functionality - these seem missing from the main loop on the wireless controller - are they done by the app? If so - makes sense for the controller to cook the data and the app act as pure UI?

TripMemoriesReset();
batteryTotalWh();
batteryCurrent();
batteryResistance();
motorCurrent();
batteryPower();
pedalPower();

Edit - ok they only cook the data for display.. will leave them be

 

[beemac]

Ok - have submitted a PR - haven't refactored or changed any code so it's all as is with the names left referring to screen presses and so on - but have cleaned up some #defines that weren't working and I think it's ok to submit.

Still can't test VT or alternate fields properly - i'm not convinced VT is working but getting into alternate fields should be ok.

If I have some more time later I'll have another go at VT testing.

 

[Peacepirate]

i flashed successfully the bootloader firmware 0.9.0 hex file on a windows machine to the wireless board and then i could flash once a „TSDZ2_DFU“ device with the TSDZ2_wireless_ota_update_0.6.0 through the NRF Connect App.
After disconnecting and repowering the nrf board (by usb directly or indirectly by using the STLink with 3,3v and GND) i can’t find any tsdz2 device by my iphone. Instead the nRF Connect App discovers now a „Charge 2“ device. No DFU mode available. Reflashing device using STLink is possible and ends with „verify ok“ but the device doesn't reappear as „TSDZ2_DFU„ object in nrf app but „Charge 2“. Restarting device with the button pressed couldn’t start dfu mode. is this meant to be so as long as the wireless board is not connected to the motor controller? maybe its broken...

 

[casainho]

i flashed successfully the bootloader firmware 0.9.0 hex file on a windows machine to the wireless board and then i could flash once a „TSDZ2_DFU“ device with the TSDZ2_wireless_ota_update_0.6.0 through the NRF Connect App.
After disconnecting and repowering the nrf board (by usb directly or indirectly by using the STLink with 3,3v and GND) i can’t find any tsdz2 device by my iphone. Instead the nRF Connect App discovers now a „Charge 2“ device. No DFU mode available. Reflashing device using STLink is possible and ends with „verify ok“ but the device doesn't reappear as „TSDZ2_DFU„ object in nrf app but „Charge 2“. Restarting device with the button pressed couldn’t start dfu mode. is this meant to be so as long as the wireless board is not connected to the motor controller? maybe its broken...

Restart the board but you need to keep the button pressed for at léast 10 seconds, so will the enter in DFU.

And if the wireless firmware is ready, the app on an Android phone should see the TSDZ2 device.

 

[casainho]

I did a good update to the wireless remote page: https://opensourceebike.github.io/remote/build_remote

If someone can verify, at least the english language

This is how I edit the documentation and have a live preview, using the Code Studio, both for this as for developing the code:

 

[beemac]

If I have some more time later I'll have another go at VT testing.

Ok -so regarding VT - if it's a feature we want - looks like we need to decide what to do with ui16_m_alternate_field_value - as currently that's only displayed in the LCD code when the alternative field is activated. It's not passed in any config packets at present - so the app can't display it.

For testing I've mapped it to ADC Throttle so I can see what's going on from the app.

Is there an appropriate ANT page/value i can map it to?

//set variables for ANT transmission

// battery voltage
p_profile->page_4.battery_voltage = ui_vars.ui16_battery_voltage_filtered_x10;

// assist level
p_profile->common.travel_mode_state |= (mp_ui_vars->ui8_assist_level << 3) & 0x38;

// lights
p_profile->common.system_state |= (mp_ui_vars->ui8_lights << 3) & 0x08;

// lev speed
p_profile->common.lev_speed = ui_vars.ui16_wheel_speed_x10 / 10;

//state of charge
p_profile->page_3.battery_soc = ui8_g_battery_soc;

 

[casainho]

If I have some more time later I'll have another go at VT testing.

Ok -so regarding VT - if it's a feature we want - looks like we need to decide what to do with ui16_m_alternate_field_value - as currently that's only displayed in the LCD code when the alternative field is activated. It's not passed in any config packets at present - so the app can't display it.

For testing I've mapped it to ADC Throttle so I can see what's going on from the app.

Is there an appropriate ANT page/value i can map it to?

//set variables for ANT transmission

// battery voltage
p_profile->page_4.battery_voltage = ui_vars.ui16_battery_voltage_filtered_x10;

// assist level
p_profile->common.travel_mode_state |= (mp_ui_vars->ui8_assist_level << 3) & 0x38;

// lights
p_profile->common.system_state |= (mp_ui_vars->ui8_lights << 3) & 0x08;

// lev speed
p_profile->common.lev_speed = ui_vars.ui16_wheel_speed_x10 / 10;

//state of charge
p_profile->page_3.battery_soc = ui8_g_battery_soc;

I as thinking again on VT and I did remember when I implemented it.

VT use the UP and DOWN buttons that are mainly for assist level, that is why VT depends on the display because user will need to understand what is going on, like how to enter VT mode and leave VT mode. I now think maybe VT does not make sense on this remote or at least it should be started from the mobile app so the user can well understand how to enter and leave this mode as also see the throotle value. So, please do not implement VT for now as this need more work and thinking on the mobile app and the remote, simultaneous.

And you pull request has conflicts, please solve them.

 

[beemac]

If I have some more time later I'll have another go at VT testing.

Ok -so regarding VT - if it's a feature we want - looks like we need to decide what to do with ui16_m_alternate_field_value - as currently that's only displayed in the LCD code when the alternative field is activated. It's not passed in any config packets at present - so the app can't display it.

For testing I've mapped it to ADC Throttle so I can see what's going on from the app.

Is there an appropriate ANT page/value i can map it to?

//set variables for ANT transmission

// battery voltage
p_profile->page_4.battery_voltage = ui_vars.ui16_battery_voltage_filtered_x10;

// assist level
p_profile->common.travel_mode_state |= (mp_ui_vars->ui8_assist_level << 3) & 0x38;

// lights
p_profile->common.system_state |= (mp_ui_vars->ui8_lights << 3) & 0x08;

// lev speed
p_profile->common.lev_speed = ui_vars.ui16_wheel_speed_x10 / 10;

//state of charge
p_profile->page_3.battery_soc = ui8_g_battery_soc;

I as thinking again on VT and I did remember when I implemented it.

VT use the UP and DOWN buttons that are mainly for assist level, that is why VT depends on the display because user will need to understand what is going on, like how to enter VT mode and leave VT mode. I now think maybe VT does not make sense on this remote or at least it should be started from the mobile app so the user can well understand how to enter and leave this mode as also see the throotle value. So, please do not implement VT for now as this need more work and thinking on the mobile app and the remote, simultaneous.

And you pull request has conflicts, please solve them.

Ok fair enough - shall I leave the state machine in there anyway - as it seems to work now? I can leave the code and just comment out the calls - then it's there if we need to revist.

I'll take a look at the PR... i'd misunderstood the error from gh - thought it was telling me I couldn't resolve!

 

[rananna]

I did a good update to the wireless remote page: https://opensourceebike.github.io/remote/build_remote

If someone can verify, at least the english language

This is how I edit the documentation and have a live preview, using the Code Studio, both for this as for developing the code:

Looks good. I will give you some minor edits later today.
Question: how do you cut the dongle to avoid damaging the circuit?
We should probably put this in the documentation.

 

[casainho]

Ok fair enough - shall I leave the state machine in there anyway - as it seems to work now? I can leave the code and just comment out the calls - then it's there if we need to revist.

Please comment the code.

Question: how do you cut the dongle to avoid damaging the circuit?
We should probably put this in the documentation.

I forgot that detail. I always did cut my boards (with a simple metal saw, by hand) and the other ones and I never had an issue. For that 3D design, the board can not have more than 36mm -- I did cut just after the pads of SDWIO and SDWCLOCK.

 

[casainho]

So I found a video showing a Bosch display for their ebikes that has map navigation, connection to hear rate sensors, etc.

I think we are on spot with our project, we simple do not develop the display, the navigation, etc, as there are others, like Garmin, doing that much better we could ever do -- we just make the integration of TSDZ2 with them!!

[youtube]h7T09VOujSU[/youtube]

 

[beemac]

And you pull request has conflicts, please solve them.

Ok fair enough - shall I leave the state machine in there anyway - as it seems to work now? I can leave the code and just comment out the calls - then it's there if we need to revist.

I'll take a look at the PR... i'd misunderstood the error from gh - thought it was telling me I couldn't resolve!

I think I'm losing my mind... I resolved one in pins.h that was fine - i could see the problem... I cannot however work out what's the problem with https://github.com/OpenSourceEBike/TSDZ2_wireless/pull/62/conflicts

Will take another look later - hopefully all will become clear!

 

[beemac]

@casainho, @rananna - having a nightmare with this PR for some reason. I could not resolve a conflict I had in pins.c - despite my change just being to add 4 lines that weren't there before. So I just made a fresh branch - and added my changes to it by copying the changed files in from my original branch. That's what the current PR contains - and finally with no merge conflicts.

*but* I was reviewing the PR and it looks like it will back out some changes about ANT page 16 in main.c that I didn't make - not sure how that occurred.

I assume another PR was accepted in the short time between me pulling a fresh branch - and overwriting the files I'd changed...?

https://github.com/OpenSourceEBike/TSDZ2_wireless/pull/63/files

 

[casainho]

@casainho, @rananna - having a nightmare with this PR for some reason. I could not resolve a conflict I had in pins.c - despite my change just being to add 4 lines that weren't there before. So I just made a fresh branch - and added my changes to it by copying the changed files in from my original branch. That's what the current PR contains - and finally with no merge conflicts.

*but* I was reviewing the PR and it looks like it will back out some changes about ANT page 16 in main.c that I didn't make - not sure how that occurred.

I assume another PR was accepted in the short time between me pulling a fresh branch - and overwriting the files I'd changed...?

https://github.com/OpenSourceEBike/TSDZ2_wireless/pull/63/files

You need to improve as you "deleted" code that was working, like the code for brakes I did recently and I tested as working as is part of the latest release. And there are changes like to the SDC config file!! You need to review your PR, I did some notes on the PR, you should get notifications.