BT Interface for TSDZ2 Open Source firmware - Work in progress

[gfmoore]

It always happens doesn't it! You say you will get round to doing something and then you are impelled to do it immediately.

apk.

So I re-downloaded the zip for the android app, opened it in Android Studio, made sure it built and ran.

Then Build>Build Bundle(s)/APKs>Build APK
After a few moments there is a little popup at bottom right that says ... locate and there is the apk at TSDZ2-Android-master\app\build\outputs\apk\debug

I side loaded it into my phone's downloads directory, used a file manager to locate it (X-plore), clicked on it and allowed it to be installed and bingo, sideloaded and working.

That has to be the easiest, least frustrating experience of the last few weeks in working with this stuff!!!

Gordon

[mspider65]

Cadence mode for my is like cruise mode without having it enabled. Motor stops to spin only with a lot of pedal pressure backwards or i change assistance mode to 0.

Anybody else with this problem?
I played around with pedal without rotation setting.
Recommended is 10 to 15. I get a nice start with a setting of 100. Seems not right but works for me.

Cadence mode works like this. Just move the pedals and the motor starts delivering the power you have programmed for the selected level.
I don't use the pedal without rotation because pedal rotation detection is very sensitive and the cadence mode for my use is just an emergency mode in case of problems with the torque sensor.

[huan]

Alright now i understand. Im had before mbrusa firmware. there is a Cadence assistant mode subordinate to the movement of the pedals.

[mspider65]

Alright now i understand. Im had before mbrusa firmware. there is a Cadence assistant mode subordinate to the movement of the pedals.

Cadence mode in my firmware and mbrusa's firmware are the same since mbrusa firmware uses my pedal movement detection alghoritm.

[Wimpy747]

New version released.
Everything should be updated, Android App, ESP32 and Controller.

The files are on Github: https://github.com/TSDZ2-ESP32/TSDZ2-ES ... master/bin
- Android: TSDZ2_ESP32v2.1.10.apk
- ESP32: TSDZ2-ESP32-Mainv1.1.8.zip
- STM8: TSDZ2-v14.zip

This version improves the motor efficiency under high loads.

In particular, the code that calculates the "Advance Angle" (FOC angle) has changed.
The old algorithm gave an underestimated value. Now the algorithm has changed and the value is calculated once every electrical revolution within the fast PWM interrupt.
I did some tests on a reference climb with the motor constantly at 400/450Watt and with the new version the motor warms up much less.

Important note:
After the update it is necessary to change the motor configuration.
There is a new parameter "FOC angle multipl." which replaces the "motor inductance" parameter.
In the Android app select: "Bike Configuration" -> System and select 36V or 48V according to your motor.
The parameter can also be entered manually in the range 0-50. If you want to experiment you can increase/decrease by 3 or 4 each time to see if you get further improvements.

MotorSetup.png

As you can see from the screenshot I also added the possibility to disable the "Field Weakening"

Last note:
The update disables the "Torque Offset Fix", and whoever had it enabled will have to enable it again after the update.

Thanks very much for the update, It works very well and somehow I finally did not get any lcd connection errors more!

[mspider65]

Thanks very much for the update, It works very well and somehow I finally did not get any lcd connection errors more!

Thanks Wimpy747.
I too have been using it for two months now without experiencing any problems.
I have done several rides by now and compared to the same ride done last year with the v7, the travel time is the same, I am one year older, I weigh 2 kg more but the battery consumption is still about 15% lower

[emyr666]

Does anyone in the EU have any boards to sell?

[gfmoore]

I can sell you mine that I never got round to using. PM Me (I'm in Stoke-on-Trent UK) Oh I forgot we're not in the EU anymore

Gordon

[Wimpy747]

Thanks very much for the update, It works very well and somehow I finally did not get any lcd connection errors more!

Thanks Wimpy747.
I too have been using it for two months now without experiencing any problems.
I have done several rides by now and compared to the same ride done last year with the v7, the travel time is the same, I am one year older, I weigh 2 kg more but the battery consumption is still about 15% lower

Somehow with some of the old versions a small error was introduced, but after installing the latest one I have no problems whatsoever. I think I will keep it like it is now, unless you will find a very smart or nice extra feature. The only thing I would find a plus is to able to change the fields in the app like the one caisinho made from yours
Thanks again..

[casainho]

The only thing I would find a plus is to able to change the fields in the app like the one caisinho made from yours
Thanks again..

Yes, that is the only feature I did develop and I think is very nice! It follows the same idea as we developed for the 850C/860C firmware, where user can customize which variable to see on each field.
On mobile phone, would be great if user could choose how many fields to show, like a preselection of 1, 2, 4 or 8. Also option to show a small graph or the numeric value on each field -- all this is just following what Garmin does on their cycling GPS displays or watchs, users can customize the number of fields and graphs or numeric on each one.

[Wimpy747]

The only thing I would find a plus is to able to change the fields in the app like the one caisinho made from yours
Thanks again..

Yes, that is the only feature I did develop and I think is very nice! It follows the same idea as we developed for the 850C/860C firmware, where user can customize which variable to see on each field.
On mobile phone, would be great if user could choose how many fields to show, like a preselection of 1, 2, 4 or 8. Also option to show a small graph or the numeric value on each field -- all this is just following what Garmin does on their cycling GPS displays or watchs, users can customize the number of fields and graphs or numeric on each one.

Totally agree, sorry I did not spell your name correctly ... Casainho!

[casainho]

The only thing I would find a plus is to able to change the fields in the app like the one caisinho made from yours
Thanks again..

Yes, that is the only feature I did develop and I think is very nice! It follows the same idea as we developed for the 850C/860C firmware, where user can customize which variable to see on each field.
On mobile phone, would be great if user could choose how many fields to show, like a preselection of 1, 2, 4 or 8. Also option to show a small graph or the numeric value on each field -- all this is just following what Garmin does on their cycling GPS displays or watchs, users can customize the number of fields and graphs or numeric on each one.

Totally agree, sorry I did not spell your name correctly ... Casainho!

And on Garmin devices, you have a wireless remote where you click on a button and the page changes.
On this app, there are also pages. Would be nice to have on our TSDZ2 wireless remote to change the page on the mobile app. The remote would connect by Bluetooth to phone and send a command to change the page, like using the on/off button click to change the page (just long press turns on/off the motor).

Note that our wireless remote already communicates with the Garmin devices to change the page, but adding the feature to also change on the mobile phone app, would be great.

[mspider65]

I have released a New Version with some minor updates:

• Slightly increased FOC angle multiplicator default values

• New Controller OTA FW update process (no more Power OFF/ON but use of Watchdog reset: Thanks @Beli for the suggestion)

• Added battery overcurrent check also in main loop

• Solved a small bug regarding historical data retention in Android App

• Optimized FOC angle calculation code

N.B.!!
Due the new OTA process it is necessary to do the UPDATE IN THE FOLLOWING ORDER!:
1) STM8 Controller Firmware
2) ESP32 Firmware
3) Android App

The new files are in https://github.com/TSDZ2-ESP32/TSDZ2-ES ... master/bin:
- Android: TSDZ2_ESP32v2.1.11.apk
- ESP32: TSDZ2-ESP32-Mainv1.2.0.zip
- STM8: TSDZ2-v15.zip

[bingo5]

I think I may have made a big mess....
My ESP32 (thanks AZUR!) has been lying around for a few months now, eagerly waiting to be installed. Finally the weather is getting better and I have enough free time.

So let's get to it...
Read the Wiki... Read the Wiki... Read the wiki again... Read also the hint with the possibly different colours.... ... Check everything... Think for a moment whether it is really the right cable... But okay... there is only 1 6 PIN cable, the colours fit and this is also used to flash the controller (via STLink), so this will be the right one.

After I soldered everything, installed it and started it... Nothing... No Bluetooth found and VLCD5 display runs normally. Then I measured everything... I was a bit surprised about -4.95V between +Batt and GND... Then I removed everything again, connected the ESP32 to my flasher (without download mode) and Bluetooth was there.

Then I read the technical documentation and got confused about the step-down converter... if there is already only 5V on +Batt, why reduce the voltage to 5V? Over time I realised that +BAT really meant 48V from my battery. Then I noticed it on https://opensourceebikefirmware.bitbuck ... oller.html. It was my 8 PIN cable that was meant -> https://opensourceebike.github.io/TSDZ2 ... ematic.png

I have now repaired the 6 PIN (wheel speed sensor) cable and soldered the ESP32 to the 8 PIN cable according to the schematic:

RXL -> Brown Cable
RXC -> Yellow Controller
TXL -> Yellow Cable
TXC -> Brown Controller

GND -> Black
+Batt -> Blue
LCD -> Red

Yellow/brown and red/black are plugged into the controller together, so the colours should be correct. Measured from the cable, the PIN assignment also matched.

Now I have connected the battery and switched on the display. The display shows E03. Bluetooth can be connected to ESP32, but it shows "Controller Error".

I have tested the controller connection several times and the connection is OK.

Check the wiring between ESP32 and controller, also check the solder points on the ESP32 board in particular the 3 small integrated circuits close to the 4 pin serial connector.

What do you mean by "check the 3 small integrated circuits"? Visually, they are flawless on my board. But I don't know how to measure them, or we are talking about different circuits?

But I suspect that I grilled the ESP32 with the wrong connection (maybe with VCC, 5V?):

▪ (RXC) --> orange wire | GND | used for: STLinkV2; wheel speed sensor
▪ (TXC) --> brown wire | VCC | used for: STLinkV2 (optional); wheel speed sensor

or am I still doing something wrong?

[mspider65]

I think I may have made a big mess....
My ESP32 (thanks AZUR!) has been lying around for a few months now, eagerly waiting to be installed. Finally the weather is getting better and I have enough free time.

So let's get to it...
Read the Wiki... Read the Wiki... Read the wiki again... Read also the hint with the possibly different colours.... ... Check everything... Think for a moment whether it is really the right cable... But okay... there is only 1 6 PIN cable, the colours fit and this is also used to flash the controller (via STLink), so this will be the right one.

After I soldered everything, installed it and started it... Nothing... No Bluetooth found and VLCD5 display runs normally. Then I measured everything... I was a bit surprised about -4.95V between +Batt and GND... Then I removed everything again, connected the ESP32 to my flasher (without download mode) and Bluetooth was there.

Then I read the technical documentation and got confused about the step-down converter... if there is already only 5V on +Batt, why reduce the voltage to 5V? Over time I realised that +BAT really meant 48V from my battery. Then I noticed it on https://opensourceebikefirmware.bitbuck ... oller.html. It was my 8 PIN cable that was meant -> https://opensourceebike.github.io/TSDZ2 ... ematic.png

I have now repaired the 6 PIN (wheel speed sensor) cable and soldered the ESP32 to the 8 PIN cable according to the schematic:

RXL -> Brown Cable
RXC -> Yellow Controller
TXL -> Yellow Cable
TXC -> Brown Controller

GND -> Black
+Batt -> Blue
LCD -> Red

Yellow/brown and red/black are plugged into the controller together, so the colours should be correct. Measured from the cable, the PIN assignment also matched.

Now I have connected the battery and switched on the display. The display shows E03. Bluetooth can be connected to ESP32, but it shows "Controller Error".

I have tested the controller connection several times and the connection is OK.

Check the wiring between ESP32 and controller, also check the solder points on the ESP32 board in particular the 3 small integrated circuits close to the 4 pin serial connector.

What do you mean by "check the 3 small integrated circuits"? Visually, they are flawless on my board. But I don't know how to measure them, or we are talking about different circuits?

But I suspect that I grilled the ESP32 with the wrong connection (maybe with VCC, 5V?):

▪ (RXC) --> orange wire | GND | used for: STLinkV2; wheel speed sensor
▪ (TXC) --> brown wire | VCC | used for: STLinkV2 (optional); wheel speed sensor

or am I still doing something wrong?

If the Android App is able to connect, it means that the ESP32 is working fine.
If the Android App shows "Controller Communication error" and not "LCD communication error" it means that the ESP32 board receives data from the display but does not receive data from the controller.

Error E03 on the display is a consequence of the fact that the ESP32 board does not receive data from the controller.
Check the wiring between controller and ESP32.

[Beli]

• New Controller OTA FW update process (no more Power OFF/ON but use of Watchdog reset: Thanks @Beli for the suggestion)

Using (ui8_rx_buffer[6] & 0x80) like I do.

[bingo5]

...

If the Android App is able to connect, it means that the ESP32 is working fine.
If the Android App shows "Controller Communication error" and not "LCD communication error" it means that the ESP32 board receives data from the display but does not receive data from the controller.

Error E03 on the display is a consequence of the fact that the ESP32 board does not receive data from the controller.
Check the wiring between controller and ESP32.

The wiring between controller and ESP32 is fine. There is no short circuit and I also checked the connection with a multimeter.

I've attached a photo of the connector that I soldered RXC (yellow) and TXC (brown) to. Is that the right plug?

[Blacklite]

I have released a New Version with some minor updates:

• Slightly increased FOC angle multiplicator default values

• New Controller OTA FW update process (no more Power OFF/ON but use of Watchdog reset: Thanks @Beli for the suggestion)

• Added battery overcurrent check also in main loop

• Solved a small bug regarding historical data retention in Android App

• Optimized FOC angle calculation code

Mspider65,

Your article explaining the changes you made to the firmware for hall calibration and timing fixes was incredible and incredibly instructive and informative... wondering if you could do the same thing for your changes to the code that calculates the advance angle (FOC angle)... it would be so useful to understand the science behind your changes.

Many thanks.

[mspider65]

The wiring between controller and ESP32 is fine. There is no short circuit and I also checked the connection with a multimeter.

I've attached a photo of the connector that I soldered RXC (yellow) and TXC (brown) to. Is that the right plug?

Connettori.png (71.11 KiB) Viewed 808 times

If you have the 8 pin connector identify the cables connected to the pin 4 (TSDZ2_Rx) and 8 (TSDZ2_Tx) of the connector.
Then cut the cables and do the following connections:

TSDZ2_Rx wire connector side - ESP32 TXL
TSDZ2_Rx wire controller side - ESP32 RXC

TSDZ2_Tx wire connector side - ESP32 RXL
TSDZ2_Tx wire controller side - ESP32 TXC

If that doesn't work, maybe you damaged something when you connected the ESP32 board to the wheel speed connector instead of the display connector.

[mspider65]

I have released a New Version with some minor updates:

• Slightly increased FOC angle multiplicator default values

• New Controller OTA FW update process (no more Power OFF/ON but use of Watchdog reset: Thanks @Beli for the suggestion)

• Added battery overcurrent check also in main loop

• Solved a small bug regarding historical data retention in Android App

• Optimized FOC angle calculation code

Mspider65,

Your article explaining the changes you made to the firmware for hall calibration and timing fixes was incredible and incredibly instructive and informative... wondering if you could do the same thing for your changes to the code that calculates the advance angle (FOC angle)... it would be so useful to understand the science behind your changes.

Many thanks.

In this case there is not much to explain.

Simplifying things a bit, the advance angle correction is based on two components:

• time: essentially given by the delay of the combination of Hall Sensors and electronics (the advance angle increases with the motor speed)

• load: the advance angle correction grows approximately linearly with the motor current. The linear constant is related to the motor inductance and is bigger for the 48V motor

I was able to calculate precisely the first component (Hall sensors calibration etc..) but i don't have the right tools for the precise calculation of the second.
To make precise measurements of the second component I would need a Trainer like this and a stabilized power supply of at least 600W.

Trainer.png (86.13 KiB) Viewed 754 times

However, I was able to estimate the second component by measuring the energy consumed on a reference climb using different configurations, and i found that the original FOC angle correction algorithm gave an underestimated value.
In practice it turned out that the original OS firmware used an excessive starting angle at zero load and underestimated the correction for high loads; the combination was that for low to medium loads it was not very efficient while for medium to high loads it had a quite good setup.

The correction for the load component was added starting from the v14 version of my firmware and, according to my measurements, now the firmware has the best efficiency for all loads.

[Blacklite]

....

Thank you for the explanation.

[bingo5]

...
If that doesn't work, maybe you damaged something when you connected the ESP32 board to the wheel speed connector instead of the display connector.

Hi mspider65,

sorry for the late feedback. I had only this week again time to take care of my bike.

I found the problem - fortunately nothing is broken by the wrong wiring. Instead, something must have gone wrong when flashing the motor firmware via STLink. After flashing again everything works now.

Your firmware is amazing, thank you! And in offroad mode fascinatingly quiet. However, the Street Mode (250W/25km / h) is much louder.

[Beli]

However, the Street Mode (250W/25km / h) is much louder.

That does not really make sense. Only different Max Speed and Max Power values are send to the motor.

For verifying you could just set at Bike Configuration / System at Street Mode the same values - or at least not set Max Power Limit there.
In my opinion 350W there is okay anyway because it's the power limit the motor is consuming - the real power to the wheel is less anyway because of every motor only has a certain efficiency and 350W input might be close to 250W output. And EU law does NOT tell any max power limit. So for a short time power is allowed to be higher anyway (the average power to the wheel within 30 minutes must not be higher than 250W). The more critical point is that the motor is not allowed to heat up more than 20 degrees (just to tell that too).

[bingo5]

Yes, of course it's probably not the Street Mode itself, but the limitation to 250W. When limited to 750W and 15A max current (48V battery), the motor is much quieter.
Your opinion with the 250W at wheels sounds interesting. I honestly haven't looked into the law in more detail. And yes, legal and ready to buy e-bikes also feel like they have more power than the TSDZ2 at 250W.

If the law says that within 30 minutes the average can't be over 250W, it would be cool if the TSDZ2 firmware would implement that and slowly reduce power after, for example, 15 minutes at ~400W. This is probably more complicated and computationally intensive though.

What do you mean by the critical point that the motor should not heat up more than 20 degrees (Celsius)? At 20 degrees outside temperatures, would that be just 40 degrees? After a long mountain drive, the engine is hot up to 80 degrees for me.

[Elinx]

.........it would be cool if the TSDZ2 firmware would implement that and slowly reduce power....

That is already the case if you have a build in temperature sensor. The power will be reduced with temperature rise.

What do you mean by the critical point that the motor should not heat up more than 20 degrees (Celsius)? At 20 degrees outside temperatures, would that be just 40 degrees? After a long mountain drive, the engine is hot up to 80 degrees for me.

There is a difference of maximum continuous value of 250W and 250W as absolute maximum value.
The first is specified for ebikes the second isn't.
250W continuous means, no significant temperature rise when running. (significant is defined as >20 degrees within a half hour)

It means in your case, running the engine at 40 degrees for a long time could be done with 250W or lower.
The power may be 500W or even 1000W too, but not longer than a half hour without temperature rise (>20).
In your case the temperature will be 80 degrees, so with 60 degrees rise, for a short time, there is no problem with regulations.

FYI: Realize that adding passive cooling (conductive material inside motorcase) let rise the time you can run at higher power.
In theory you rises the continuous value (250W) with that too.
The same is for a higher Voltage from battery. With the same power there is a lower current through the engine coils and less temperature rise.

But this isn't easy to measure on the fly.
Only with special equipment running the motor under certain conditions for a half hour with the highest possible power without temperature rise. It cost more time than a half hour to find that "higstest possible" power.

Easier to measure is this with the speedlimit, with a speedometer or on rollers.
So maximum 25km/h speed is more important to prevent problems with insurance and police.