TSDZ8 OSF (open source firmware)

[larsb]

About the FOC multiplier, you can look at the readme section (of OSF for 860C). as explained, I "misused" an existing field that was not used to allow to edit the parameter. In theory, the magnetic field must be advanced when current and/or RPM increases. Currently OSF increases the field advance only based on the current. I expect that RPM has much less impact than the current but this should be validated by some tests.
Ideally, to find the best value (for a given RPM), you should use a home trainer that can measure the power delivered by the motor. Then you could calculate the ratio between the power measured by the home trainer and the power (Volt * Amp) delivered by the battery. The goal is to get the best ratio.

One way of setting the phase switching angle relative to hall sensor activation is to feed two motor phases with a small current, this will hold the motor position in one of the commutation steps, then it could be possible to use the OSF parameter to match the hall signal commutation step. Another way is to spin the motor and read out the BEMF and hall signals on an oscilloscope and match hall commutation to the BEMF waveform. Is it possible to read out the hall signal state from the OSF?

I have a question, normally the physical hall position in a motor is stable in manufacturing, either on a hall board that is adjusted, a recess in the motor laminations or in the slots of the stator. Therefore i don't think the original phase/hall relationship should need to be corrected in the OSF, and i haven't seen that the OSF is adjusting the motor control except for current and power limits. Why is this parameter then needed in the OSF?
(And please avoid calling it a FOC parameter to avoid confusion, it is normally called "phase advance angle", "hall sensor advance" or "hall angle")

 

[stancecoke]

feed two motor phases with a small current, this will hold the motor position in one of the commutation steps, then it could be possible to use the OSF parameter to match the hall signal commutation step.

This doesn't work for FOC, as you don't have "commutation" steps there. All three phase wires are powered simultaneously. In "real" FOC you drive the motor with a constant id and iq=0 in open loop for some revolutions to find the hall sensor positions.

 

[larsb]

Commutation in the physical way that hall signals commutate from 101 --> 011 --> during rotation and the rotor poles reaches the stator poles/slots in the laminations.

But this controller isn't FOC, right? Isn't it just a simulated sine wave commutation based on the hall sensor input?
I have fiddled a lot with hall angle setting on various controllers and the angle is not a dealbreaker on efficiency and power unless you are really in the wrong position. Too late firing of the phase lowers efficiency and rpm, but advance from 0 up to 30 degrees can be a bit better, then efficiency and torque drops off and rpm starts to run away..

 

[stancecoke]

Isn't it just a simulated sine wave commutation based on hall sensor input?

Hall sensor input has nothing to do with FOC.
The hall sensors are just one way to estimate the actual rotor position. You can do it by an encoder or an sensorless observer also.
The motor position is extrapolated from the hall sensor state and the actual speed of the rotor in this firmware. The main idea is to keep id at zero in FOC (if you don't want to do things like MTPA or field weakening). And this exactly what @mstrens does in this firmware.

 

[larsb]

Sure, I know that. But is this controller using FOC? having phase advance angle isn't really FOC as far as i know? I understand it to be a simple transformation of the commutation timing in relation to the rotor position as given by the hall signals.

 

[stancecoke]

But is this controller using FOC?

Define FOC It just stands for Field Orientated Control. This firmware controls the field orientation to get id=0. So it is FOC.
As far as I remember @mstrens even uses the Clarke and Park transformation to get id, but doesn't use the classical inverse Park and SVM to calculate the duty cycles for each phase, but a look up table. The result is the same in the end

 

[larsb]

I know what FOC is, but i've seen so much confusion regarding this topic. Are you splitting hairs for the sake of it or am I misunderstanding? Motor control tries to align the magnetic fields to the most beneficial position, right? How is the control implemented here? Is it a transformation based on the hall signals at low speed and a sensorless control algorithm at higher rpm? The reason i ask is that the parameters i see mentioned here as "FOC parameters" to me seem too simple to be FOC control.

(edit: i read the last pages of the thread and it's more clear to me, so never mind.)

 

[stancecoke]

The reason i ask is that the parameters i see mentioned here as "FOC parameters"

There you have to look at the history of this project. The code bases on the old Kunteng Open Source Firmware. This hardware has only one phase current sensor. The old TSDZ2 controllers used the same processor, but had no phase current sensor at all. So no classical FOC can be done, besides the poor processor power of the STM8 can't do the needed calculations in real time. To align the field, @casainho calculated the theoretical advance angle from the current, the speed and the motor parameters inductivity and resistance, based on the paper of Shane Colton, this is what is called FOC parameters in this TSDZ community. With the new generation of controllers with more processing power and three phase current shunts you could do "real" FOC now, but @mstrens decided to do something in-between.

You can still find all this old documentation on Bitbucket:

OpenSource_EBike_firmware-development-CHERRYTREE.ctb

 

[mstrens]

FOC multiplier is a name used in OSF for TSDZ2, It is a wrong name as it is not a FOC concept but just a way to calculate a lead angle based on Idc current and phase current.
In main branch of OSF for TSDZ8, I just used the same concept but even did not used phase current to calculate lead angle.

In test6_with_pll of OSF for TSDZ8, I tried to improved efficiency. In this version, a "raw" value of lead angle is calculated based on rpm (using a table) and on current (using a ratio). Then Id is also calculated and a lead angle correction is applied in order to get Id = 0. This correction (regulation) based on Id runs at a lower frequency than PWM. So this is quite similar to a true FOC.

 

[01zorro1]

hello, just bought a new tongsheng TSDZ8 48v 750w with a DFL11 display (the one in this link https://es.aliexpress.com/item/1005...t_main.77.7d21194dQKufbz&gatewayAdapt=glo2esp)
wanted to know before buying the j link and symilar if its posible to do what i wanna do in the settings

i just wanted to make the force or torque needed in the pedals way lower, its a bike for my old mother and she doesnt have much strenght, so i wanted it to need way less power for it to get to the "max output"

 

[Linas]

Looks good the only thing is that it got my safety limit that actually doesn't make sense as we have the limit in another place in the code. But it's 1200W so not something that should be noticable (having 23A in another place it's basically the same). No need to recompile firmware. Let's see if we get positive feedbacks I have updated the pull request so there is almost nothing now, just removal of what I've just mentioned + some spaces removal in another line, sorry my IDE automatically does it. If you want you can try to accept it so we can see how it works

@whatever2 here is the build where you should be able to get assist from stand still. (OSF_TSDZ8_860C_SPIDER_3_V00_02.04.hex). For hybrid mode torque sensor sensitivity (when it starts assisting from stand still) can be regulated from the menu if you have 860C. If you need that - let me know, I'll check what is the parameter name.

https://github.com/mstrens/OSF_860C/raw/b644c4b47b0263dcf02ac3aea704d2860df82463/files_to_flash/OSF_TSDZ8_860C_SPIDER_3_V00_02.04.hex

Do I understand correctly - the 860c display firmware version where I could increase max current to 23A- publicly is not available?

 

[prinf]

I’m not sure if everyone is aware of this. For just under a year now, there has been a display firmware update offering higher motor power ratings (1500W, although the maximum battery current has only been increased from 22A to 24A

@Linas, this is what we had on the previous page. So I assume you can find public build with 24A as a limit, just look for the version 0.20.1C-5.1.1. Seems it's here Color_LCD_860C/releases/20.1C.5-1-1 at master · emmebrusa/Color_LCD_860C

 

[whatever2]

Looks good the only thing is that it got my safety limit that actually doesn't make sense as we have the limit in another place in the code. But it's 1200W so not something that should be noticable (having 23A in another place it's basically the same). No need to recompile firmware. Let's see if we get positive feedbacks I have updated the pull request so there is almost nothing now, just removal of what I've just mentioned + some spaces removal in another line, sorry my IDE automatically does it. If you want you can try to accept it so we can see how it works

@whatever2 here is the build where you should be able to get assist from stand still. (OSF_TSDZ8_860C_SPIDER_3_V00_02.04.hex). For hybrid mode torque sensor sensitivity (when it starts assisting from stand still) can be regulated from the menu if you have 860C. If you need that - let me know, I'll check what is the parameter name.

https://github.com/mstrens/OSF_860C/raw/b644c4b47b0263dcf02ac3aea704d2860df82463/files_to_flash/OSF_TSDZ8_860C_SPIDER_3_V00_02.04.hex

Tested 02.04 and that fixed the startup, thanks! Didn't have to change parameters from the old version. Actually, I tried "assist without pedaling on", but it's way too dangerous for the kind of things I do, like causing random forward jerks when I'm stopped in a rocky descent and facing a cliff. Can't install the cut-off brakes because drop bars.

I’m considering upgrading to the latest OSF_TSDZ8_860C_SPIDER_3_V00_02.04 (from the test6_with_pll branch), but I’d like to focus strictly on efficiency and reliability rather than top speed.
For those who have switched from v1.35 (.35 hex) to v02.04, I would appreciate your observations on the following:
Energy Efficiency: Have you noticed any improvement in Wh/km (or range) during normal commuting/touring? Does the new PLL logic and updated power management feel more efficient in how it draws current from the battery during steady cruising?
Motor Stability & Predictability: How is the power delivery in terms of "smoothness"? Is the motor more predictable when transitioning between different assist levels or when the torque sensor kicks in? I'm looking for a "natural" feel without sudden surges.
Thermal Behavior: Does the motor seem to manage heat better with this version? Efficient energy management usually results in less wasted heat – have you noticed any difference during long, steady climbs?
Hybrid Mode Refinement: In v02.04, is the transition from standstill to assist more seamless? I'm looking for a reliable, "no-fuss" start every time without having to fight the torque sensor.
My main goal is a dependable, energy-efficient setup for long-range riding. Is v02.04 a step forward in "smart" energy management compared to the older v1.35?

Probably not gonna be too helpful here, but:
- Energy efficiency: I don't think there's a change if you don't push the motor in strong descents (it would previously top out at ~400-500W for me, now can reach above 1000W with 50t chainring + 11t cog).
- Stability/predictability: can't speak on that since I use aggressive settings
- Thermal: it takes longer for the problem on my motor (see my previous post) to manifest itself in long steady climbs, which I think is caused by heat
- Hybrid refinement: definitely better, I can start just as fast as the previous version again.

@mstrens I thought I saw something before about the battery wattage counter bug being fixed in the new branch, maybe I was mistaken? Or if you don't know what I'm talking about: when I set the battery gauge % calculation to be based on purely voltage, the A/B trip used watts variables on the main screen always stay stuck on a low value like 0.6 or 2.1 (not consistent). Also, do you know how the trip time variable works? At the end of my trips, it always looks much lower than the time that really passed.

 

[Will2]

I haven't tested or ridden for a few months.
During the last test ride last year, I had a bad fall, flew over the handlebars and twisted my wrist.
The rear brake failed because the brake hose was pinched between the frame and the motor.
Today I fixed the brakes, installed firmware 5.1.1. in the 860C display, and installed firmware 02.04 in the motor.
I only did a short test ride with version 02.04.
The first impressions are excellent, wind in my ears, it seems that the previous feelings of less performance compared to the original test3 firmware are gone.
No negative observations so far.

 

[mstrens]

@mstrens I thought I saw something before about the battery wattage counter bug being fixed in the new branch, maybe I was mistaken? Or if you don't know what I'm talking about: when I set the battery gauge % calculation to be based on purely voltage, the A/B trip used watts variables on the main screen always stay stuck on a low value like 0.6 or 2.1 (not consistent). Also, do you know how the trip time variable works? At the end of my trips, it always looks much lower than the time that really passed.

I do not remember having fixed a bug about battery wattage in OSF for TSDZ8. I expect that the issues you mentioned are in the firmware running on the display and not on the TSDZ8 controller. Best would be to ask those questions directly to mbrusa that maintains the firmwares on the displays. He did them for OSF on TSDZ2 and I just reused them for TSDZ8.

 

[malikomi]

Hi, does this work on a Green Pedel TSDZ8 with a DFL11 display?

 

[Will2]

I've got and I'm using such software to tsdz8 and 860c (I increased max A on display because 24 wasnt enough for me) I've got such 860c v13 software and tsdz8 software but just for my private use, there is a little graphic bug over 1300W on 860c, and above 1300W f.e 1360 showing as 60 maybe @mbrusa can help with finding it.
...

Hi ProzyC.
It seems to me that you have fixed the error of indicating power above 1300W in the binary file 860C_V13-v0.5.2PL1700W30A.bin with Polish menu. Do you also have the English version fixed?
What is the difference compared to the version 860C_V13-v20.1C.5-1-1-bootloader.bin from @mbrusa?

edit:
tested 24A/1500W vs 30A/1700W

 

[prozyc]

Hi ProzyC.
It seems to me that you have fixed the error of indicating power above 1300W in the binary file 860C_V13-v0.5.2PL1700W30A.bin with Polish menu. Do you also have the English version fixed?

Yes, I fixed this error but now I've got just for version with polish menu but please send me pm which display version do you need an I can easily make english version.

 

[Will2]

... send me pm which display version do you need ...

Thanks for the information.
For now, wait a bit, the version with the Polish menu is enough for me to test.
So far, I can't even exceed the limits from 5.1.1.

 

[mstrens]

It seems that version V00.02.04 for 860C is OK. It includes some optimisations done by printf.
I just create version OSF_TSDZ8_VLCD_SPIDER_3_V00_02.04.hex that contains the same optimisation but for VLD5 (and similar) display. This VLCD5 version is on github in test6_will_pll branch at OSF/files_to_flash at test6_with_pll · mstrens/OSF.
Please note that I did not tested it. If you find some bugs, please report them in this forum.

 

[gustavotp]

Hi everyone, I bought a TSDZ8 and its firmware is very aggressive in the first assist levels 1 and 2. This is good, but it consumes a lot of battery. The topic here is very technical, but I tried updating to the Katana 1.35 firmware and editing the torque without weight to 185 and 470, which it showed on the display. However, the assist level became weak and unstable at all levels. I'm asking if it's possible to simply modify the original firmware to have less assist level 1 and 2.

 

[mstrens]

Hi everyone, I bought a TSDZ8 and its firmware is very aggressive in the first assist levels 1 and 2. This is good, but it consumes a lot of battery. The topic here is very technical, but I tried updating to the Katana 1.35 firmware and editing the torque without weight to 185 and 470, which it showed on the display. However, the assist level became weak and unstable at all levels. I'm asking if it's possible to simply modify the original firmware to have less assist level 1 and 2.

You can have a look at this tread : new tsdz8 pswpower

If you want to continue with OSF, you can also try the latest version 00.02.04 in test6_with_pll branch. Please note that it is important to setup correct values for your torque sensor.

 

[Will2]

...
The hex file version is now V0.2.4.
I hope I did not make mistakes.

@mstrens, @prinf:
where are the source files for version OSF_TSDZ8_860C_SPIDER_3_V00_02.04.hex located?

If I compile the current files from "OSF_860C-test6_with_pll_for_pull", the compiled file is not identical to any of the files in the "files_to_flash" folder on github.

Edited: Solved, see later posts.

 

[mstrens]

@mstrens, @prinf:
where are the source files for version OSF_TSDZ8_860C_SPIDER_3_V00_02.04.hex located?

If I compile the current files from "OSF_860C-test6_with_pll_for_pull", the compiled file is not identical to any of the files in the "files_to_flash" folder on github.

This is strange. Normally the hex file has been generated with the latest source files on my laptop and all files have been uploaded on github in the branch test6_with_pll. Could it be that you use a different setup for compilation (optimization?).

 

[Will2]

I compiled independently on two different computers, neither file matched.
I will compare if these 2 files are the same.

Edit:
It's even more interesting, my two created files from different computers are not the same either, and neither is identical to the hex file on github.
On one of the computers I was getting warnings, not errors.

It would be good to have a third person do the checking.