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

[rananna]

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?

Unfortunately I have had some health issues that prevent me from riding.
All I can do is bench testing for now.
Is the battery draining when the nrf52840 is out of the enclosure?
I would request that you please test on the bench so we can at least eliminate any enclosure related issues.

[casainho]

Unfortunately I have had some health issues that prevent me from riding.
All I can do is bench testing for now.
Is the battery draining when the nrf52840 is out of the enclosure?
I would request that you please test on the bench so we can at least eliminate any enclosure related issues.

I wish you a quick recovery.

About the issue, I used a 15 ohms resistor in series with 2 AAA NiMh batteries (2.3 volts), to power the wireless remote. I did measure with oscilloscope the voltage across the resistor and here is the result:

1. Wireless remote without any power supply - 9.85mV for 0 amps current:




2. Wireless remote working, no LED on, TSDZ2 wireless board off:



3. Wireless remote working, no LED on, TSDZ2 wireless board on with TSDZ2 motor off:


On 3. there are peaks of 166 - 10mv = 156mv, which means peaks of 10mA.

[casainho]

And this is with brake pin active (connected as original schematic):



So, PWM every 1ms and very small duty-cycle to turn on the red LED of brake signal. The large impulse at middle of the image, happens every 250ms and is the ANT+ LEV reception and processing.

In my calculations, if TSDZ2 wireless board ANT+ LEV is not transmitting, the wireless remote battery will work at best for about 2.5 years but if ANT+ LEV is always transmitting, the remote battery at best will only work for 8 months.

I did put the NRF52 board inside the wireless remote and measured again and I did not see nothing about the possible issue. The current values all seems the same and ok.

Maybe the next step should be to build a wireless remote but with 1 hole to put outside the resistor to measure the current and also wires to measure the battery voltage, so I can monitor it.

[casainho]

Finally I was able to find the issue!!

Easy to replicate: with the TSDZ2 wireless board is off, click on any button of the wireless remote to make it work. Then, click 1 or more times on the down button and then long press on the down button (sometimes you need more than 1 long press) -- then the wireless remote will pull continuous 6.5mA and stop responding to the buttons press, so keeping draining the battery!! The CR2032 battery has about 180mAh, meaning it will drain in about 27 hours!! -- this is for sure what was happening to me all the time.

The same happens if TSDZ2 wireless board is on and then I see the same 6.5mA + the impulse of current used by receiving the ANT from the wireless remote (1 pulse every 250ms).

Now, how to solve this?? what is the source of this issue?? Note that seems to happen only with DOWN or ON/OFF buttons, not with the other buttons. If I click the reset button, the system resets and go back to normal as usual.

[casainho]

Meanwhile I found:
- the used current is the same as if the microprocessor is running at 100%
- if a debug and stop the system, I can not see the place in code it is running and if I click continue, it will continue and using the same amount of current (it is like if is running on an infinite loop and without the softdevice running, otherwise there would be an exception after I click continue)
- if I disable the power on/off pin on the initialization, then the long press on this will not trigger the issue
- if this issue is triggered while the red LED is on, then it will keep always on at max brightness (like if the PWM stops at a fixed position)

[beemac]

Meanwhile I found:
- the used current is the same as if the microprocessor is running at 100%
- if a debug and stop the system, I can not see the place in code it is running and if I click continue, it will continue and using the same amount of current (it is like if is running on an infinite loop and without the softdevice running, otherwise there would be an exception after I click continue)
- if I disable the power on/off pin on the initialization, then the long press on this will not trigger the issue
- if this issue is triggered while the red LED is on, then it will keep always on at max brightness (like if the PWM stops at a fixed position)

my guess is nrf_delay_ms being called somewhere in the remote code - but haven't looked at the code. I think as well as effectively causing 100% cpu - they also block interrupts which would explain the pwm hang... but just a guess!

edit: I should check before pointing fingers - I can't find any nrf_delay being used in the remote code - so can't be that - sorry rananna

[rananna]

Meanwhile I found:
- the used current is the same as if the microprocessor is running at 100%
- if a debug and stop the system, I can not see the place in code it is running and if I click continue, it will continue and using the same amount of current (it is like if is running on an infinite loop and without the softdevice running, otherwise there would be an exception after I click continue)
- if I disable the power on/off pin on the initialization, then the long press on this will not trigger the issue
- if this issue is triggered while the red LED is on, then it will keep always on at max brightness (like if the PWM stops at a fixed position)

my guess is nrf_delay_ms being called somewhere in the remote code - but haven't looked at the code. I think as well as effectively causing 100% cpu - they also block interrupts which would explain the pwm hang... but just a guess!

edit: I should check before pointing fingers - I can't find any nrf_delay being used in the remote code - so can't be that - sorry rananna

No problem!
All ideas all welcome.

[casainho]

Seems the problem is here: void send_page16(ant_lev_profile_t *p_profile)

do
{
err_code = sd_ant_acknowledge_message_tx(p_profile->channel_number, sizeof(p_message_payload), p_message_payload);
// } while (err_code == NRF_ANT_ERROR_TRANSFER_IN_PROGRESS);
} while (err_code);

If I comment the send_page16(), there is no more issue. I had luck because the debugger once did stop on the send_page16().

[rananna]

Seems the problem is here: void send_page16(ant_lev_profile_t *p_profile)

do
{
err_code = sd_ant_acknowledge_message_tx(p_profile->channel_number, sizeof(p_message_payload), p_message_payload);
// } while (err_code == NRF_ANT_ERROR_TRANSFER_IN_PROGRESS);
} while (err_code);

If I comment the send_page16(), there is no more issue. I had luck because the debugger once did stop on the send_page16().

Interesting..... I added this code to ensure that the send page 16 command gets an acknowledgement form the motor for the page16 command before proceeding. obviously when the acknowledgement fails it goes into a continuous loop and burns up power!!
Good catch and sloppy coding on my part.
It would be better to simply press the button again if the message does not get received.
I will eliminate the do loop and give you a PR

[casainho]

Some news:

1. I did a nice update on the project page, like main page focus on TSDZ2 EBike wireless controller, mobile app and fully wireless remote and wired remote. On this main page there are pictures of this 3 parts. I also added screenshots on the mobile app page and wrote some notes.

2. @rananna documented a different build and 3D design for the wireless remote: https://opensourceebike.github.io/remot ... emote.html