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

[casainho]

I was hoping to make the wireless remote and make an almost completely wireless bike (except for the brake cable). I am curious about why you and beemac are both recommending a wired remote setup. Is it just because of the difficulty to build the system? Or is it because it is not quite ready to be tested? If it is just about the difficulty to build it, I don't really mind - I have access to a 3D printer so I can print the remote case as well as the box for the wireless motor controller. Here is the list of the parts that I ordered:

NRF52840-DONGLE x 2
TEC 2-4811WI
BSP296N
ITS4140N

I have an issue that once I screw the enclosure, for some reason, my battery drains very fast!! I already bought very good quality CR2032 batteries on local shop but this only happens to me - the remote works very well until I screw the enclosure - maybe the board has some issue, I do not know. I am trying to figure out as I really need it working on my EBike.

 

[beemac]

I have an issue that once I screw the enclosure, for some reason, my battery drains very fast!! I already bought very good quality CR2032 batteries on local shop but this only happens to me - the remote works very well until I screw the enclosure - maybe the board has some issue, I do not know. I am trying to figure out as I really need it working on my EBike.

Is this something you want to get working before doing a release? Not that I'm in any hurry - just curious what you think still needs to be done?

I might have some more time coming up - so was thinking about what to look at including in the 'vNext' release as I'm happy with the wired remote functionality now - new bike is running all the latest code and runs fine... I've compiled a list based on what's been talked about on the thread - plus a few things that during use I've thought would be useful - like being able to give bikes different bluetooth names...

Some of these should be pretty straightforward - I can look at the ones that don't need config or app changes initially... if we can agree the list of features I don't mind looking at the new config packet format either - if you could make the changes to the app to support any new settings?

hw = hardware
mc = motor controller
wc = wireless controller
wr = wireless remote
cp = config packet
aa = android app

hw mc wc wr cp aa
      *  *          Streetmode
      *             Startup boost
      *             VThrottle
      *     *  *    Fine grained unit settings - allow all combos of kg/km/c/lb/miles/f
*     *             Light signal on NRF pin
*     *             Brake light signal on NRF pin
      *  *  *  *    App setting to force reboot into DFU for wireless controller/remote (or even better - app controlled fw updates)
   *  *     *  *    Motor firmware update OTA
      *  *  *  *    Customise Bluetooth names
   *                Motor efficiency improvements
      *  *          Wireless remote - send button presses only to controller - move all control logic to wireless controller.
*  *  *     *  *    External SOC sensor support
   *  *  *  *  *    Sensor enable/disable + missing/bad data warnings - torque/pas/brake etc.
      *  *          Additional Garmin fields

 

[casainho]

Some of these should be pretty straightforward - I can look at the ones that don't need config or app changes initially... if we can agree the list of features I don't mind looking at the new config packet format either - if you could make the changes to the app to support any new settings?

I agree with that full list.

If you are ok, you can change the Android app. Adding / removing configurations should not be hard, you need to understand the logic but It is possible since the variable names follow the same on the firmware. Will always be easier to make similar things that are already done.
I can "quick" add / remove configurations but will always be easier for the one that is also developing the firmware, to test / develop on the both sides.
I would prefer to answer your questions you may have about the mobile app than do by myself the changes.

 

[beemac]

Some of these should be pretty straightforward - I can look at the ones that don't need config or app changes initially... if we can agree the list of features I don't mind looking at the new config packet format either - if you could make the changes to the app to support any new settings?

I agree with that full list.

If you are ok, you can change the Android app. Adding / removing configurations should not be hard, you need to understand the logic but It is possible since the variable names follow the same on the firmware. Will always be easier to make similar things that are already done.
I can "quick" add / remove configurations but will always be easier for the one that is also developing the firmware, to test / develop on the both sides.
I would prefer to answer your questions you may have about the mobile app than do by myself the changes.

Ok cool - yea I don't mind doing that - I've looked at the app code and looks pretty straightforward to add controls to the pages so I should be ok. Where is the latest source - i can only find v0.30 - can you push v0.31 or point me to the correct repo?

Garmin fields aside - I assume you'll keep working on those - it's the motor control improvements that I mostly hoped you'd be able to help with. As even if I can make the changes - like moving aspects of the motor control to timers or similar - I don't have the ability to test the impact on the motor control at a low level to see if the changes are good or not.

 

[casainho]

Ok cool - yea I don't mind doing that - I've looked at the app code and looks pretty straightforward to add controls to the pages so I should be ok. Where is the latest source - i can only find v0.30 - can you push v0.31 or point me to the correct repo?

Garmin fields aside - I assume you'll keep working on those - it's the motor control improvements that I mostly hoped you'd be able to help with. As even if I can make the changes - like moving aspects of the motor control to timers or similar - I don't have the ability to test the impact on the motor control at a low level to see if the changes are good or not.

You were correct, I did not pushed the V0.3.1 code, but I just did now.

About the motor control, it will be hard as there are changes added by mspider that are in assembly language. Developing for the motor control is always hard as it needs a good / heavy setup of hardware!! -- I am not ready to do that and I will be dad soon so I will be very busy on next year at least. But anyway, the best thing is to go in very small parts as possible, maybe we will be able if we can divide on that very small parts.

And yes, I took a break on the Garmin data fields but I now have recommendations from Garmin on what to do to improve (I did fill a an issue on their site). I hope soon to go back again to this, but first I need to have my wireless remote working, so I can use my EBike, which is the most important thing

 

[beemac]

Ok cool - yea I don't mind doing that - I've looked at the app code and looks pretty straightforward to add controls to the pages so I should be ok. Where is the latest source - i can only find v0.30 - can you push v0.31 or point me to the correct repo?

Garmin fields aside - I assume you'll keep working on those - it's the motor control improvements that I mostly hoped you'd be able to help with. As even if I can make the changes - like moving aspects of the motor control to timers or similar - I don't have the ability to test the impact on the motor control at a low level to see if the changes are good or not.

You were correct, I did not pushed the V0.3.1 code, but I just did now.

About the motor control, it will be hard as there are changes added by mspider that are in assembly language. Developing for the motor control is always hard as it needs a good / heavy setup of hardware!! -- I am not ready to do that and I will be dad soon so I will be very busy on next year at least. But anyway, the best thing is to go in very small parts as possible, maybe we will be able if we can divide on that very small parts.

And yes, I took a break on the Garmin data fields but I now have recommendations from Garmin on what to do to improve (I did fill a an issue on their site). I hope soon to go back again to this, but first I need to have my wireless remote working, so I can use my EBike, which is the most important thing

Thanks I'll have a go at building the app make sure I can test things properly.

Yea i think a baby might take some of your time hopefully between us and anyone else who wants to play with some code we can get the trickier bits done. I'm comfortable I can implement most on that list in a reasonable timeframe unless circumstances change significantly.

I had a quick look at how I can read external SOC - that's something I want to try to get working sooner rather than later. I considered a voltage divider feeding one of the ADC pins on the nrf - but I think a better solution is something like this :

https://uk.banggood.com/CJMCU-294-LTC2944-Battery-Temperature-Measuring-Module-60V-Voltage-and-Current-Measurement-Meter-p-1461327.html

I considered the LTC2944 as a discrete component - but it's tiny with 8 legs so the module is a much better (if slightly more costly) solution...

That would give much better SOC info than a simple voltage reading and we have enough free pins for an i2c interface but happy to hear from anyone with better suggestions.

edit: for some unknown reason that module appears to be configured for 1A max load! Why it lists electric vehicles as a suitable application I have no idea... so need another solution

edit: replacing the r050 resistor on the module with this bizarre looking 1mOhm resistor might allow up to 50A measurement - but not really an off-the-shelf solution. https://uk.rs-online.com/web/p/surface-mount-fixed-resistors/1930012/

Maybe just reading voltage via a divider and adc pin is the best route...

 

[beemac]

Ok cool - yea I don't mind doing that - I've looked at the app code and looks pretty straightforward to add controls to the pages so I should be ok. Where is the latest source - i can only find v0.30 - can you push v0.31 or point me to the correct repo?

Garmin fields aside - I assume you'll keep working on those - it's the motor control improvements that I mostly hoped you'd be able to help with. As even if I can make the changes - like moving aspects of the motor control to timers or similar - I don't have the ability to test the impact on the motor control at a low level to see if the changes are good or not.

You were correct, I did not pushed the V0.3.1 code, but I just did now.

About the motor control, it will be hard as there are changes added by mspider that are in assembly language. Developing for the motor control is always hard as it needs a good / heavy setup of hardware!! -- I am not ready to do that and I will be dad soon so I will be very busy on next year at least. But anyway, the best thing is to go in very small parts as possible, maybe we will be able if we can divide on that very small parts.

And yes, I took a break on the Garmin data fields but I now have recommendations from Garmin on what to do to improve (I did fill a an issue on their site). I hope soon to go back again to this, but first I need to have my wireless remote working, so I can use my EBike, which is the most important thing

Oh I noticed that someone was asking on another thread about integrating a wireless IGH with the tsdz2... has what Garmin told you mean we could at some point in the future stop using the ant_lev gear fields?

 

[casainho]

I received the M2x12mm screws I bought from EBay and I found that probably I need to make the 3D model about 1mm deeper for the screws - I will test and updated the files:


And I am 3D printing again a remote enclosure as the other is to dirty with the clear silicone I use to make the remote water prof. But I also added +0.4mm of space between the battery and the board, as I am afraid the forces of the board against the battery may be the source of the issue I am having. I am also using a new board, just in case that other is kind of faulty:

Oh I noticed that someone was asking on another thread about integrating a wireless IGH with the tsdz2... has what Garmin told you mean we could at some point in the future stop using the ant_lev gear fields?

You can read here: https://forums.garmin.com/developer/connect-iq/i/bug-reports/connect-iq-ant-apps-are-very-weak-not-usable-compared-to-garmin-ant-native-apps

 

[sidmodi]

I was hoping to make the wireless remote and make an almost completely wireless bike (except for the brake cable). I am curious about why you and beemac are both recommending a wired remote setup. Is it just because of the difficulty to build the system? Or is it because it is not quite ready to be tested? If it is just about the difficulty to build it, I don't really mind - I have access to a 3D printer so I can print the remote case as well as the box for the wireless motor controller. Here is the list of the parts that I ordered:

NRF52840-DONGLE x 2
TEC 2-4811WI
BSP296N
ITS4140N

I have an issue that once I screw the enclosure, for some reason, my battery drains very fast!! I already bought very good quality CR2032 batteries on local shop but this only happens to me - the remote works very well until I screw the enclosure - maybe the board has some issue, I do not know. I am trying to figure out as I really need it working on my EBike.

Oh that sounds like a challenging issue to solve. I expect to receive my parts next week so I will start putting it together then. If you haven't resolved the issue by then, I'll be happy to set up on my end here and try and reproduce the issue.

What would I need to do to get in the same state as you? Set up the wireless motor controller and wireless remote with the brake and battery?

 

[casainho]

What would I need to do to get in the same state as you? Set up the wireless motor controller and wireless remote with the brake and battery?

Yes.

And do you have with you the six screws M2x12mm 0.79mm pitch? because I had to buy from EBay and took about 1 month to arrive.

 

[beemac]

What would I need to do to get in the same state as you? Set up the wireless motor controller and wireless remote with the brake and battery?

Yes.

And do you have with you the six screws M2x12mm 0.79mm pitch? because I had to buy from EBay and took about 1 month to arrive.

Could you add clips to the print design so the halves snap together? That with the silcone would probably provide a good seal without screws? That was what I was trying to design for my case - but haven't got very far due to problems with the printer.

 

[casainho]

Could you add clips to the print design so the halves snap together? That with the silcone would probably provide a good seal without screws? That was what I was trying to design for my case - but haven't got very far due to problems with the printer.

Clips? please share some image of other products.

The screws are needed to secure the original keypad. I would not avoid them.

 

[beemac]

Could you add clips to the print design so the halves snap together? That with the silcone would probably provide a good seal without screws? That was what I was trying to design for my case - but haven't got very far due to problems with the printer.

Clips? please share some image of other products.

The screws are needed to secure the original keypad. I would not avoid them.

Clips as part of the printed design - so the halves 'click' together... you almost certainly have lots of things like that lying around - that you need to prise apart and that can snap back together...

I googled - but hard to find good examples - this should give you more of an idea:

https://www.sculpteo.com/blog/2018/04/25/how-to-connect-two-parts-with-3d-printed-joints-and-snap-fits/

Oh - didn't see the bit about needing screws for the keypad... glue?

 

[beemac]

About the motor control, it will be hard as there are changes added by mspider that are in assembly language.

Luckily i like a bit of assembly language - especially 8 bit... Have been looking at the motor changes will see how i get on

 

[casainho]

After more 4 new batteries and 4 different prints to test what could be wrong, I finally found that the issue is the most obvious -- small space means the wires keep the board button pressed and that means the system will enter in bootloader mode - probably the battery drain happens after a few hours at bootloader or something.

There is also other issue that is easy to screw the 4 M2x12 screws and the some of the keypad buttons will be always pressed, meaning the remote will not work.

So, because it was either in bootloader mode or a keypad button always pressed, the remote was not working at all and after a few hours the battery was empty.

I will now update the 3D design, that I increased 1.5mm in height, to avoid the board button press.

 

[beemac]

After more 4 new batteries and 4 different prints to test what could be wrong, I finally found that the issue is the most obvious -- small space means the wires keep the board button pressed and that means the system will enter in bootloader mode - probably the battery drain happens after a few hours at bootloader or something.

There is also other issue that is easy to screw the 4 M2x12 screws and the some of the keypad buttons will be always pressed, meaning the remote will not work.

So, because it was either in bootloader mode or a keypad button always pressed, the remote was not working at all and after a few hours the battery was empty.

I will now update the 3D design, that I increased 1.5mm in height, to avoid the board button press.

That was going to be my guess - but on the wireless controller the button does nothing so assumed it was the same on the wireless remote.... Does raise the question - rather than making it 1.5mm bigger - just disable the button in code - is it needed?

 

[casainho]

That was going to be my guess - but on the wireless controller the button does nothing so assumed it was the same on the wireless remote.... Does raise the question - rather than making it 1.5mm bigger - just disable the button in code - is it needed?

Well, I think I was wrong, the issue still persist and it is not the button for sure.

Since I already changed the NEF52 board for a new one, I am now thinking that I need to put the board running and measuring the current as I need to figure out if there is or not an high current that drains the battery.......... I can not use more batteries. I am now thinking when I will quit......

 

[rananna]

That was going to be my guess - but on the wireless controller the button does nothing so assumed it was the same on the wireless remote.... Does raise the question - rather than making it 1.5mm bigger - just disable the button in code - is it needed?

Well, I think I was wrong, the issue still persist and it is not the button for sure.

Since I already changed the NEF52 board for a new one, I am now thinking that I need to put the board running and measuring the current as I need to figure out if there is or not an high current that drains the battery.......... I can not use more batteries. I am now thinking when I will quit......

I see no issue on the bench, it seems it has to be related to the enclosure.
Is is possible that the board is shorting out to the battery through the insulating tape used on top of the battery?

 

[casainho]

I see no issue on the bench, it seems it has to be related to the enclosure.
Is is possible that the board is shorting out to the battery through the insulating tape used on top of the battery?

No because I did a design that I let +1.5mm to avoid that. That did not work and then I out that +1.5mm to top, to avoid the cables to press the button, which did not work either.

I am near to quit because of this, I am riding without brake sensor and my blue gear is now failing, so, a lot of work and time because of this issue.

 

[rananna]

I see no issue on the bench, it seems it has to be related to the enclosure.
Is is possible that the board is shorting out to the battery through the insulating tape used on top of the battery?

No because I did a design that I let +1.5mm to avoid that. That did not work and then I out that +1.5mm to top, to avoid the cables to press the button, which did not work either.

I am near to quit because of this, I am riding without brake sensor and my blue gear is now failing, so, a lot of work and time because of this issue.

Yes, a problem like this is very frustrating.
However, the good news is that there are only a few suspects left.
One of these would be the cable connection.
Measure the impedance disconnected to see if there is leakage. They have been known to fail.

 

[casainho]

I see no issue on the bench, it seems it has to be related to the enclosure.
Is is possible that the board is shorting out to the battery through the insulating tape used on top of the battery?

No because I did a design that I let +1.5mm to avoid that. That did not work and then I out that +1.5mm to top, to avoid the cables to press the button, which did not work either.

I am near to quit because of this, I am riding without brake sensor and my blue gear is now failing, so, a lot of work and time because of this issue.

Yes, a problem like this is very frustrating.
However, the good news is that there are only a few suspects left.
One of these would be the cable connection.
Measure the impedance disconnected to see if there is leakage. They have been known to fail.

I really need to measure the current that the board uses. On last day the remote started to working (probably because the battery was to low and did a reset to the system) while I was riding and I could understand:
- if I pressed the brakes, the system stops to work and the motor assist stops
- if I disconnect the brake sensor, the remote keeps working well for changing the assist level, turn on/off the motor and change Garmin Edge page. As soon I connect the brakes and brake, the system stops to work.
- even after 24h, the remote keep working but without the brake sensors connected

I think that for some reason, breaking may be using to much power and then the board shuts down because the battery should have very low energy now. If I can measure the board current, then I can find when TO MUCH current is being used and quick draining the battery.

 

[casainho]

I see no issue on the bench, it seems it has to be related to the enclosure.
Is is possible that the board is shorting out to the battery through the insulating tape used on top of the battery?

No because I did a design that I let +1.5mm to avoid that. That did not work and then I out that +1.5mm to top, to avoid the cables to press the button, which did not work either.

I am near to quit because of this, I am riding without brake sensor and my blue gear is now failing, so, a lot of work and time because of this issue.

Yes, a problem like this is very frustrating.
However, the good news is that there are only a few suspects left.
One of these would be the cable connection.
Measure the impedance disconnected to see if there is leakage. They have been known to fail.

I really need to measure the current that the board uses. On last day the remote started to working (probably because the battery was to low and did a reset to the system) while I was riding and I could understand:
- if I pressed the brakes, the system stops to work and the motor assist stops
- if I disconnect the brake sensor, the remote keeps working well for changing the assist level, turn on/off the motor and change Garmin Edge page. As soon I connect the brakes and brake, the system stops to work.
- even after 24h, the remote keep working but without the brake sensors connected

I think that for some reason, breaking may be using to much power and then the board shuts down because the battery should have very low energy now. If I can measure the board current, then I can find when TO MUCH current is being used and quick draining the battery.

Sometimes I get sad to see that people that contributed at initially are no longer active, maybe they decided to not use TSDZ2 anymore or such.

In June 2020, @Headless did the schematic and warned to not use the two NFC pins but with the new board, we connected the brake to one of them:

https://endless-sphere.com/forums/viewtopic.php?f=28&t=106346&start=75#p1565005



https://endless-sphere.com/forums/viewtopic.php?f=28&t=106346&start=75

 

[rananna]

No because I did a design that I let +1.5mm to avoid that. That did not work and then I out that +1.5mm to top, to avoid the cables to press the button, which did not work either.

I am near to quit because of this, I am riding without brake sensor and my blue gear is now failing, so, a lot of work and time because of this issue.

Yes, a problem like this is very frustrating.
However, the good news is that there are only a few suspects left.
One of these would be the cable connection.
Measure the impedance disconnected to see if there is leakage. They have been known to fail.

I really need to measure the current that the board uses. On last day the remote started to working (probably because the battery was to low and did a reset to the system) while I was riding and I could understand:
- if I pressed the brakes, the system stops to work and the motor assist stops
- if I disconnect the brake sensor, the remote keeps working well for changing the assist level, turn on/off the motor and change Garmin Edge page. As soon I connect the brakes and brake, the system stops to work.
- even after 24h, the remote keep working but without the brake sensors connected

I think that for some reason, breaking may be using to much power and then the board shuts down because the battery should have very low energy now. If I can measure the board current, then I can find when TO MUCH current is being used and quick draining the battery.

Sometimes I get sad to see that people that contributed at initially are no longer active, maybe they decided to not use TSDZ2 anymore or such.

In June 2020, @Headless did the schematic and warned to not use the two NFC pins but with the new board, we connected the brake to one of them:

https://endless-sphere.com/forums/viewtopic.php?f=28&t=106346&start=75#p1565005



https://endless-sphere.com/forums/viewtopic.php?f=28&t=106346&start=75

Yes, but we configure the nrc as gpio so they work as button input.
I measure no increased power consumption on this pin compared to other gpios.
I also see nothing on the nordic forum suggesting the use of these pins are an issue with power consumption.

Have you found a power issue with this pin?

 

[casainho]

Yes, but we configure the nrc as gpio so they work as button input.
I measure no increased power consumption on this pin compared to other gpios.
I also see nothing on the nordic forum suggesting the use of these pins are an issue with power consumption.

Have you found a power issue with this pin?

Well, after 24h, seems the battery is dead again. So, I really need to monitor the current by myself. Why you are not using yet the wireless remote?

 

[casainho]

Power mosfet on the TSDZ2 wireless board

I usually forget the disable the motor on the TSDZ2 wireless, meaning the TSDZ2 motor controller stays on for some days and I had no issue at all, so, I wounder if the power are really needed on the TSDZ2 wireless board.

DC-DC board and NRF52 board burned twice

I am using the following cheap DC-DC:



This DC-DC seems be 60V max and it did burn twice to me, and when it burns, also the NRF52 board burns. How it did happen:
1. I wanted to test the brake sensor so I kept the back wheel on the air while I did pedal a bit to make TSDZ2 motor start
2. unfortunately, I was testing my wireless remote that I am having issues with and, another issue did happen (twice!) that TSDZ2 motor kept rotating even if I stop pedaling
3. with the motor rotating and wheel on the air, I did apply the brakes and the motor did stop BUT also this DC-DC and NRF52840 were burned

My guess is that there is a voltage spike on the battery terminals when the brakes disable the motor coils, then, this DC-DC burns...