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

[beemac]

@casainho - I don't see how we can have anything other than something like what I've written in the controller code. Either we need a separate state machine for each led event - to turn on/off or whatever - or we use something like i've put together that manages the state when clocked. We can't just turn on leds, wait, turn off etc. that's not going to work.

I agree to do the best possible for power saving and sharing the code. If rananna can not do it, then I hope you will be able to do it. Rananna is working on the wireless remote and you on the wired remote. The board, buttons and LEDs are just the same, so I think the code should be the same.

Agree 100% on using the same method to illuminate the led - and I can take the work rananna's doing and make my sequencer use the same method to light the LED. But unless rananna wants to use my sequence player (even though he doesn't need to because the way the remote code works is slightly different around scheduling) then we'll have to use different methods to play sequences from what I can see...

Updated branch link below - will wait for rananna's PR and discuss how best to proceed.

https://github.com/4var1/TSDZ2_wire...ke_wireless_TSDZ2/firmware/include/ledalert.h
https://github.com/4var1/TSDZ2_wireless/blob/led-alerts/EBike_wireless_TSDZ2/firmware/ledalert.c

 

[g4eml]

The instructions for programming the wireless bootloader using Windows are lacking quite a few important steps. Anyone not experienced with Windows would waste a lot of time trying to get it to work.

I have just gone through the process and made the following notes which should help. Maybe someone with write access can update the instructions.

1. Download openocd for windows (current link is OK)
2. Unzip the file on your PC desktop.
3. Copy the resulting folder to a convenient place on your PC. For ease of access use C:/
4. Rename the folder openocd
5. Copy the Wireless Bootloader .hex file you have previously downloaded into c:/openocd/bin
6. In the Windows search box enter cmd to open a command prompt.
7. Enter cd C:/openocd/bin
8. Enter the following. (All in one line)

openocd.exe -f ../share/openocd/scripts/interface/stlink.cfg -f ../share/openocd/scripts/target/nrf52.cfg -c "program TSDZ2_wireless-bootloader_with_sd-v0.9.0.hex verify" -c "exit"

9. This will flash and verify the write. If you see ** Verified OK **, the flashing has been successful.



As an aside it might be easier if the above command was made available as a .bat file which would avoid typing errors.
Then the .bat file could be copied to the bin directory and executed with a double click removing the need to use the cmd prompt.

Colin.

 

[beemac]

Low-power PWM library
The low-power pulse-width modulation (PWM) library provides functions to generate a pulse-width modulated output signal while using minimal power. The signal can be used, for example, to change the intensity or the color of LEDs.

This library uses an application timer and is therefore not very accurate. It can be used to control, for example, LEDs, but for peripherals that need a high accuracy, you should use the PWM library instead.

@rananna, maybe you could use one app timer with frequency of 10x, so to have 10% duty_cycle, the LED would be on only 1 cycle interrupt from the 10 cycles, and so on.

Yes, that is what I was recommending in my previous post regarding the alternative pwm technique.
I will try it and see how it works

Hey @rananna - how are you getting on with the the power saving on the LED? I went for a ride today headless and all seems good - so I'm keen to post a test release for wired buttons for others to test - but need to finalise the LED stuff... I've had a busy day at work but have some time later if I can be of any assistance testing or suchlike?

It's great having nothing on the handlebars and still being able to see what's going on. For popping to the shops it makes a massive difference not having to come out of a shop, attach a phone to the handlebars and/or press things on the screen. Just switch on battery, press on/off - wait 10 secs and ride!

 

[rananna]

Low-power PWM library
The low-power pulse-width modulation (PWM) library provides functions to generate a pulse-width modulated output signal while using minimal power. The signal can be used, for example, to change the intensity or the color of LEDs.

This library uses an application timer and is therefore not very accurate. It can be used to control, for example, LEDs, but for peripherals that need a high accuracy, you should use the PWM library instead.

@rananna, maybe you could use one app timer with frequency of 10x, so to have 10% duty_cycle, the LED would be on only 1 cycle interrupt from the 10 cycles, and so on.

Yes, that is what I was recommending in my previous post regarding the alternative pwm technique.
I will try it and see how it works

Hey @rananna - how are you getting on with the the power saving on the LED? I went for a ride today headless and all seems good - so I'm keen to post a test release for wired buttons for others to test - but need to finalise the LED stuff... I've had a busy day at work but have some time later if I can be of any assistance testing or suchlike?

It's great having nothing on the handlebars and still being able to see what's going on. For popping to the shops it makes a massive difference not having to come out of a shop, attach a phone to the handlebars and/or press things on the screen. Just switch on battery, press on/off - wait 10 secs and ride!

Glad to hear it is working well.
Still testing the new pwm implementation.
I still hope to complete later today.

 

[beemac]

Low-power PWM library
The low-power pulse-width modulation (PWM) library provides functions to generate a pulse-width modulated output signal while using minimal power. The signal can be used, for example, to change the intensity or the color of LEDs.

This library uses an application timer and is therefore not very accurate. It can be used to control, for example, LEDs, but for peripherals that need a high accuracy, you should use the PWM library instead.

@rananna, maybe you could use one app timer with frequency of 10x, so to have 10% duty_cycle, the LED would be on only 1 cycle interrupt from the 10 cycles, and so on.

Yes, that is what I was recommending in my previous post regarding the alternative pwm technique.
I will try it and see how it works

Hey @rananna - how are you getting on with the the power saving on the LED? I went for a ride today headless and all seems good - so I'm keen to post a test release for wired buttons for others to test - but need to finalise the LED stuff... I've had a busy day at work but have some time later if I can be of any assistance testing or suchlike?

It's great having nothing on the handlebars and still being able to see what's going on. For popping to the shops it makes a massive difference not having to come out of a shop, attach a phone to the handlebars and/or press things on the screen. Just switch on battery, press on/off - wait 10 secs and ride!

Glad to hear it is working well.
Still testing the new pwm implementation.
I still hope to complete later today.

Ok nice one, I'll stop badgering you!

 

[casainho]

The instructions for programming the wireless bootloader using Windows are lacking quite a few important steps. Anyone not experienced with Windows would waste a lot of time trying to get it to work.

Done, updated the notes.

@rananna and @beemac, I will accept the next PR from rananna and then I will stop accepting others until I can work with beemac to use only the same code for both remotes - I guess we will need to reimplement the rananna.

 

[beemac]

The instructions for programming the wireless bootloader using Windows are lacking quite a few important steps. Anyone not experienced with Windows would waste a lot of time trying to get it to work.

Done, updated the notes.

@rananna and @beemac, I will accept the next PR from rananna and then I will stop accepting others until I can work with beemac to use only the same code for both remotes - I guess we will need to reimplement the rananna.

Thanks for merging the PR - however I'm having bluetooth pairing issues - cannot get the board that's running the new led code to pair any more. Can't be 100% sure that it isn't my phone as it's quite temperamental. I can't get testing right now unfortunately - but should be back later to try and pin this down.

I hope it's just me and not related to the changes!!

 

[beemac]

The instructions for programming the wireless bootloader using Windows are lacking quite a few important steps. Anyone not experienced with Windows would waste a lot of time trying to get it to work.

Done, updated the notes.

@rananna and @beemac, I will accept the next PR from rananna and then I will stop accepting others until I can work with beemac to use only the same code for both remotes - I guess we will need to reimplement the rananna.

Thanks for merging the PR - however I'm having bluetooth pairing issues - cannot get the board that's running the new led code to pair any more. Can't be 100% sure that it isn't my phone as it's quite temperamental. I can't get testing right now unfortunately - but should be back later to try and pin this down.

I hope it's just me and not related to the changes!!

Quick update - it's just my phone... all pairing ok! phew

 

[beemac]

The instructions for programming the wireless bootloader using Windows are lacking quite a few important steps. Anyone not experienced with Windows would waste a lot of time trying to get it to work.

Done, updated the notes.

@rananna and @beemac, I will accept the next PR from rananna and then I will stop accepting others until I can work with beemac to use only the same code for both remotes - I guess we will need to reimplement the rananna.

Thanks for merging the PR - however I'm having bluetooth pairing issues - cannot get the board that's running the new led code to pair any more. Can't be 100% sure that it isn't my phone as it's quite temperamental. I can't get testing right now unfortunately - but should be back later to try and pin this down.

I hope it's just me and not related to the changes!!

Quick update - it's just my phone... all pairing ok! phew

Just submitted a PR for a tiny update - when I was tidying up the code to publish I removed a couple of instructions I shouldn't have. Result was green is too bright - and blue wasn't working at all!

 

[beemac]

Done, updated the notes.

@rananna and @beemac, I will accept the next PR from rananna and then I will stop accepting others until I can work with beemac to use only the same code for both remotes - I guess we will need to reimplement the rananna.

Thanks for merging the PR - however I'm having bluetooth pairing issues - cannot get the board that's running the new led code to pair any more. Can't be 100% sure that it isn't my phone as it's quite temperamental. I can't get testing right now unfortunately - but should be back later to try and pin this down.

I hope it's just me and not related to the changes!!

Quick update - it's just my phone... all pairing ok! phew

Just submitted a PR for a tiny update - when I was tidying up the code to publish I removed a couple of instructions I shouldn't have. Result was green is too bright - and blue wasn't working at all!

Would be interested to see whether you think it flickers - might have to up the pwm interrupt frequency a touch. Looked ok in daylight - now it's dark is borderline whether there is flicker...

 

[Tiger_one]

As a side note for anyone without a STLink-V2.
I was able to load the boot loader for Wireless and Adafruit-Circuitpython (one or the other) via raspberrypi using this excellent tutorial:

https://www.rototron.info/circuitpython-nrf52840-dongle-openocd-pi-tutorial/

If you load the Adafruit bootloader you can access this board via Arduino-IDE after installing Adafruit nRF52840 library using board definition "Itsy-Bitsy nRF52840 express". This will wipe out your CircuitPython name and directory, so make a copy to go back to CircuitPython if you wish to do so.

P.S. Don't expect to do I2C in these environments

 

[rananna]

Thanks for merging the PR - however I'm having bluetooth pairing issues - cannot get the board that's running the new led code to pair any more. Can't be 100% sure that it isn't my phone as it's quite temperamental. I can't get testing right now unfortunately - but should be back later to try and pin this down.

I hope it's just me and not related to the changes!!

Quick update - it's just my phone... all pairing ok! phew

Just submitted a PR for a tiny update - when I was tidying up the code to publish I removed a couple of instructions I shouldn't have. Result was green is too bright - and blue wasn't working at all!

Would be interested to see whether you think it flickers - might have to up the pwm interrupt frequency a touch. Looked ok in daylight - now it's dark is borderline whether there is flicker...

@beemac, Still making the mods to the wireless code to incorporate signalling.
I like the flexibility for various type of pwm led signals- well done!
However, and since I am still perusing the code I may be wrong about this, I don't think you have added the option to have a signalling event continue until cancelled.
All events seem to have a fixed duration.
For example, this event is needed to signal the start of ANT pairing by a slow flashing led, and is terminated on connection with a led connection signal. Tghis is also needed for walk mode in the wireless remote that is started by a button press and is terminated by releasing the button

Can you please implement this feature?
(or if it is already added, please direct me to the solution!)

 

[beemac]

Quick update - it's just my phone... all pairing ok! phew

Just submitted a PR for a tiny update - when I was tidying up the code to publish I removed a couple of instructions I shouldn't have. Result was green is too bright - and blue wasn't working at all!

Would be interested to see whether you think it flickers - might have to up the pwm interrupt frequency a touch. Looked ok in daylight - now it's dark is borderline whether there is flicker...

@beemac, Still making the mods to the wireless code to incorporate signalling.
I like the flexibility for various type of pwm led signals- well done!
However, and since I am still perusing the code I may be wrong about this, I don't think you have added the option to have a signalling event continue until cancelled.
All events seem to have a fixed duration.
For example, this event is needed to signal the start of ANT pairing by a slow flashing led, and is terminated on connection with a led connection signal. Tghis is also needed for walk mode in the wireless remote that is started by a button press and is terminated by releasing the button

Can you please implement this feature?
(or if it is already added, please direct me to the solution!)

Thanks very much glad you like it. Ah yes you're correct I didn't realise that was a requirement so I'll need to implement. I'll have a look in the morning but I am on a training course all day so might have to wait until the evening - should be straightforward though.

Walk assist sort of does what you say - it just keeps pumping single green flash events into the queue whilst the down button is pressed - so looks like it's permanently flashing. The downside is the queue takes a while to clear so it keeps flashing after you release the button for a second or so.

If we reduce the queue size that lag before the flashing stops would reduce - do you need to only have a start/end event - can you keep calling led_alert whilst the situation is occurring?

Anyway - I'll have a look tomorrow and report back, cheers have a good evening!

 

[rananna]

Walk assist sort of does what you say - it just keeps pumping single green flash events into the queue whilst the down button is pressed - so looks like it's permanently flashing. The downside is the queue takes a while to clear so it keeps flashing after you release the button for a second or so.

Yes, I see that that is the case in the motor code, walk_assist_state() is called periodically in the main loop.
In the case of the wireless remote, I take a simpler interrupt driven approach where I sent the command to start walk mode (and start flashing ) when the button is pressed and cancel walk mode( and the flashing) when the button is released.

can you keep calling led_alert whilst the situation is occurring?

Although I could modify walk mode to work that way, it isn't really feasible to do that for ant connection/disconnection events.
It is far easier to just start an indefinite led flash upon initiating search and cancel it upon connection.

Anyway - I'll have a look tomorrow and report back, cheers have a good evening!

Thanks! I will incorporate your mods and complete testing of the wireless remote this weekend.

 

[plpetrov]

Would be interested to see whether you think it flickers - might have to up the pwm interrupt frequency a touch. Looked ok in daylight - now it's dark is borderline whether there is flicker...

@Beemac In addition to the frequency have you considered also managing the pulse width in one way or another? In a similar way to the display brightness for any LCD display?
My concern is that having only one brightness level is a kind of compromise. This means a led badly visible or not visible at all in bright sunshine and too bright or even blinding during the night. I faced this problem in a project of mine.

Also do not forget that we have different, if not contradicting requirements in relation to the power for the battery power remote and the wireless board. While the predominant requirement for the remote is to save power for the wireless controller would be the better and proper visibility, as power savings there is not of that importance.

And thank you very much for implementing the wired remote. I had exactly the same intention to copy the code from the the Bafang display but you were faster in doing it!

 

[rananna]

Would be interested to see whether you think it flickers - might have to up the pwm interrupt frequency a touch. Looked ok in daylight - now it's dark is borderline whether there is flicker...

The leds definitely have a noticeable flicker. please increase pwm frequency in your next update.

 

[beemac]

Would be interested to see whether you think it flickers - might have to up the pwm interrupt frequency a touch. Looked ok in daylight - now it's dark is borderline whether there is flicker...

The leds definitely have a noticeable flicker. please increase pwm frequency in your next update.

No probs - still in training - so will be later or or maybe tomorrow before I post an update.

* increase pwm frequency
* add function to start/end long running event

I was also going to add a function to de-init the app timer - do you need that for going into low power mode or similar? I was also going to look at possibly only enabling the timer when the led is on - that removes the need to explicitly switch off the timer at other times.

A thought r.e. power:

Higher the interrupt frequency - the more I can make the LED off for a cycle - and the shorter the minimum pulse-width. So that means less power spend lighting the LED - but more power spent servicing interrupts that don't do anything most of the time. Any thoughts on where the balance is?

I'll try a few options - making the pulse wider at same/lower frequency - or narrower at higher frequency. Do you have the means to test the compare the power draw of each method?

@plpetrov - yes i manage frequency and pulse width.

 

[casainho]

Would be interested to see whether you think it flickers - might have to up the pwm interrupt frequency a touch. Looked ok in daylight - now it's dark is borderline whether there is flicker...

The leds definitely have a noticeable flicker. please increase pwm frequency in your next update.

No probs - still in training - so will be later or or maybe tomorrow before I post an update.

* increase pwm frequency
* add function to start/end long running event

I was also going to add a function to de-init the app timer - do you need that for going into low power mode or similar? I was also going to look at possibly only enabling the timer when the led is on - that requires the need to switch off the timer at other times.

A thought r.e. power:

Higher the interrupt frequency - the more I can make the LED off for a cycle - and the shorter the minimum pulse-width. So that means less power spend lighting the LED - but more power spent servicing interrupts that don't do anything most of the time. Any thoughts on where the balance is?

I'll try a few options - making the pulse wider at same/lower frequency - or narrower at higher frequency. Do you have the means to test the compare the power draw of each method?

@plpetrov - yes i manage frequency and pulse width.

I think the SDK PWM low power also uses the APP_TIMER, so, your implementation should be near their in quality of power usage -- maybe you can look at theirs implementation to verify.

I will have a good weather on the weekend to ride -- if you guys have a working version that I can test, would be great!!

 

[beemac]

Would be interested to see whether you think it flickers - might have to up the pwm interrupt frequency a touch. Looked ok in daylight - now it's dark is borderline whether there is flicker...

@Beemac In addition to the frequency have you considered also managing the pulse width in one way or another? In a similar way to the display brightness for any LCD display?
My concern is that having only one brightness level is a kind of compromise. This means a led badly visible or not visible at all in bright sunshine and too bright or even blinding during the night. I faced this problem in a project of mine.

Also do not forget that we have different, if not contradicting requirements in relation to the power for the battery power remote and the wireless board. While the predominant requirement for the remote is to save power for the wireless controller would be the better and proper visibility, as power savings there is not of that importance.

And thank you very much for implementing the wired remote. I had exactly the same intention to copy the code from the the Bafang display but you were faster in doing it!

Yes I agree with your comments on the LED brightness for the controller. I had the same thoughts about using the lights on/off status to alter the brightness like with the 860c. Currently the pwm function I have implemented supports 4 levels of brightness but we only use the lowest currently. For now I want to get the pwm working for the remote - with low power - then perhaps we can look at other things.

Are you wiring a 'wired button wireless controller'? Would be good to have someone else to help test. I will do a schematic this weekend - but the pins for the buttons are exactly the same as for the wireless remote - just don't connect the brake if you're keeping wired brakes - brake wire should still go to the motor controller.

 

[rananna]

I was also going to add a function to de-init the app timer - do you need that for going into low power mode or similar? I was also going to look at possibly only enabling the timer when the led is on - that removes the need to explicitly switch off the timer at other times.

not really needed, the standby and low power modes of the nrf52840 deal well with running timers

A thought r.e. power:
Higher the interrupt frequency - the more I can make the LED off for a cycle - and the shorter the minimum pulse-width. So that means less power spend lighting the LED - but more power spent servicing interrupts that don't do anything most of the time. Any thoughts on where the balance is?

Definitely on the LED side. The on chip LEDs are often orders of magnitude more power hungry than SOC operations.

I'll try a few options - making the pulse wider at same/lower frequency - or narrower at higher frequency. Do you have the means to test the compare the power draw of each method?

Sure do.
I have the Nordic Power Profiler II to measure performance,( see: https://www.nordicsemi.com/Software-and-tools/Development-Tools/Power-Profiler-Kit-2)

 

[beemac]

Walk assist sort of does what you say - it just keeps pumping single green flash events into the queue whilst the down button is pressed - so looks like it's permanently flashing. The downside is the queue takes a while to clear so it keeps flashing after you release the button for a second or so.

Yes, I see that that is the case in the motor code, walk_assist_state() is called periodically in the main loop.
In the case of the wireless remote, I take a simpler interrupt driven approach where I sent the command to start walk mode (and start flashing ) when the button is pressed and cancel walk mode( and the flashing) when the button is released.

can you keep calling led_alert whilst the situation is occurring?

Although I could modify walk mode to work that way, it isn't really feasible to do that for ant connection/disconnection events.
It is far easier to just start an indefinite led flash upon initiating search and cancel it upon connection.

Anyway - I'll have a look tomorrow and report back, cheers have a good evening!

Thanks! I will incorporate your mods and complete testing of the wireless remote this weekend.

Ok - PR just submitted for a few tweaks.

pwm frequency upped to 16khz - duty cycle of lowest intensity is 2 out of every 16 cycles (green) others are 3/16.
have added three new functions:

void led_clear_queue(void); //used if you want to play a sequence right now.
void led_hold_queue(void); // Used to keep the current sequence playing
void led_release_queue(void); // Go back to normal - play the queue as it happens

I've used them in the walk assist button code so you can see that as an example. Is better now because it doesn't keep flashing once the state is over as it did when I just stuffed the queue during the event.

Call clear/hold queue just before you want to play a sequence that repeats until..

then call release queue once the event is done - then things go back to normal.

 

[beemac]

I was also going to add a function to de-init the app timer - do you need that for going into low power mode or similar? I was also going to look at possibly only enabling the timer when the led is on - that removes the need to explicitly switch off the timer at other times.

not really needed, the standby and low power modes of the nrf52840 deal well with running timers

A thought r.e. power:
Higher the interrupt frequency - the more I can make the LED off for a cycle - and the shorter the minimum pulse-width. So that means less power spend lighting the LED - but more power spent servicing interrupts that don't do anything most of the time. Any thoughts on where the balance is?

Definitely on the LED side. The on chip LEDs are often orders of magnitude more power hungry than SOC operations.

I'll try a few options - making the pulse wider at same/lower frequency - or narrower at higher frequency. Do you have the means to test the compare the power draw of each method?

Sure do.
I have the Nordic Power Profiler II to measure performance,( see: https://www.nordicsemi.com/Software-and-tools/Development-Tools/Power-Profiler-Kit-2)

Great - PR submitted - hopefully less flicker now. That's good as I've gone for the 'interrupts cheap, led power expensive' option - i.e fast pwm frequency and very short pulses of the LEDs.

 

[beemac]

I was also going to add a function to de-init the app timer - do you need that for going into low power mode or similar? I was also going to look at possibly only enabling the timer when the led is on - that removes the need to explicitly switch off the timer at other times.

not really needed, the standby and low power modes of the nrf52840 deal well with running timers

A thought r.e. power:
Higher the interrupt frequency - the more I can make the LED off for a cycle - and the shorter the minimum pulse-width. So that means less power spend lighting the LED - but more power spent servicing interrupts that don't do anything most of the time. Any thoughts on where the balance is?

Definitely on the LED side. The on chip LEDs are often orders of magnitude more power hungry than SOC operations.

I'll try a few options - making the pulse wider at same/lower frequency - or narrower at higher frequency. Do you have the means to test the compare the power draw of each method?

Sure do.
I have the Nordic Power Profiler II to measure performance,( see: https://www.nordicsemi.com/Software-and-tools/Development-Tools/Power-Profiler-Kit-2)

Great - PR submitted - hopefully less flicker now. That's good as I've gone for the 'interrupts cheap, led power expensive' option - i.e fast pwm frequency and very short pulses of the LEDs.

be really interested to see what the power draw is compared to 'full-on'. That power profiler kit looks amazing - "200nA to 1A measurement range" 200nA! 8) If you're happy with the led flicker with the latest PR - I can do a patch with the LEDs full on if you want to compare?

 

[beemac]

Would be interested to see whether you think it flickers - might have to up the pwm interrupt frequency a touch. Looked ok in daylight - now it's dark is borderline whether there is flicker...

The leds definitely have a noticeable flicker. please increase pwm frequency in your next update.

No probs - still in training - so will be later or or maybe tomorrow before I post an update.

* increase pwm frequency
* add function to start/end long running event

I was also going to add a function to de-init the app timer - do you need that for going into low power mode or similar? I was also going to look at possibly only enabling the timer when the led is on - that requires the need to switch off the timer at other times.

A thought r.e. power:

Higher the interrupt frequency - the more I can make the LED off for a cycle - and the shorter the minimum pulse-width. So that means less power spend lighting the LED - but more power spent servicing interrupts that don't do anything most of the time. Any thoughts on where the balance is?

I'll try a few options - making the pulse wider at same/lower frequency - or narrower at higher frequency. Do you have the means to test the compare the power draw of each method?

@plpetrov - yes i manage frequency and pulse width.

I think the SDK PWM low power also uses the APP_TIMER, so, your implementation should be near their in quality of power usage -- maybe you can look at theirs implementation to verify.

I will have a good weather on the weekend to ride -- if you guys have a working version that I can test, would be great!!

@casainho - if you want to ride this weekend, can you accept the PR please so rananna can incorporate the changes!

 

[AZUR]

I updated the schematics:

TSDZ2 wireless board:

TSDZ2 wireless remote:

Hi casainho, I'm was far for a long time... I've no words, your work is awesome!

I've some questions, please take a look when you have some time:

I own a 15s battery a bit undercharge for my setup (I use BT BMS for set 4,09 maximum cell voltage, so a total 61,35v full battery) whit SW102 and works very for over 2000km no one problem till now.

Now I want to try the wireless board, but I'm bit confusing if the BTS4140N would be enough for my maximum voltage. The datasheet says 60v max so what can I use? Does the BTS6163D could work?

Also the battery pack have an USB port inside, so can I use the 5v USB output to powering the nRF52840 instead of DC-DC converter? Why the DC-DC OUT- is connect to VDD_out and not to GND?

And also, another question about the nRF52840 TSDZ2 wireless board: can I directly connect the brake sensors by wire to pin 1-2 and VLCD5 remote to pin 1-7-8-9-10 and use them without the wireless remote?

According to the documentation the ANT communication is only active on the wireless remote and not on the wireless TSDZ2 controller, right? But I still able to connect to the wireless TSDZ2 controller for use an Bluetooth phone as display, also without the wireless remote, is it correct?

I'm pretty worried about relying on the wireless connection to handle the controls above all because of the inevitable latency that creates an extra component in the middle. In my opinion, the immediacy of the controls is much more useful than the ability to remove the control cable from the engine to the handlebar! During use on my trips, I often change assistance even 2-3 levels in rapid sequence, but above all a delay of even half a second in the activation of the brakes would be very uncomfortable.

Thank you so much for your time and your work

Hi, fi7ippo,

I also use a 15s battery without any problems.


Why don't you try it and see if it works. IC, Integrated circuits, generally have a 5% tolerance which will allow them to operate up to 66V. As you have a voltage of 61.5 v it is still well below tolerance.

Good luck. Then he says if it works.