Tsdz2 firmware open source adapted to vlcd5, vlcd6 and xh18

stancecoke said:
kallt_kaffe said:
I notice that casainho's firmware doesn't flash data and option at all so couldn't we just skip flashing option bytes?

Hm, in the Kunteng-Project we had to write the option byte once to disable the readout protection bit. If Tonsheng has not set this bit in the factory settings, there is no need to write the option bytes. As people can read out the factory firmware, the bit seems not to be set.
I think qmarco didn't knew this, when he took the Java-configurator from the Kunteng-Project as base for the TSDZ2 Project. The data (=EEPROM) memory should be written each time to prevent inconsistent settings.

So we just have to delete the entries in the src/controller/compile_and_flash.bat

[strike]STVP_CmdLine -BoardName=ST-LINK -ProgMode=SWIM -Port=USB -Device=STM8S105x6 -FileOption=option_no_prot.ihx -verbose -verif -no_loop
if errorlevel == 1 goto FAIL[/strike]

STVP_CmdLine -BoardName=ST-LINK -ProgMode=SWIM -Port=USB -Device=STM8S105x6 -FileProg=main.ihx -FileData=data.ihx[strike] -FileOption=option_no_prot.ihx[/strike] -verbose -no_loop -verif -no_warn_protect
if errorlevel == 1 goto FAIL

regards
stancecoke

I can report that adapting the compile_and_flash.bat file as proposed by stancecoke worked for me.
I used it right from the 1st flash of my 2 TDSZ2's, so it seems indeed that no readout protection bit needs to be set and the option byte can be left untouched.
-> Would it make sense to adapt github accordingly?
 
HughF said:
If you want the best response from a standstill with the TSDZ2 and the OSF, you need to be using a mode that is purely torque sensor based. So this could be Torque mode or eMTB mode.

Using pedal power (torque * cadence) to calculate motor current results in the current being zero amps until the cadence sensor is spinning fast enough to give an output. It makes the system very sluggish off the line.

A hybrid mode based on speed would be best so that torque only is used at the start and cadence only at then end ?
 
jbalat said:
HughF said:
If you want the best response from a standstill with the TSDZ2 and the OSF, you need to be using a mode that is purely torque sensor based. So this could be Torque mode or eMTB mode.

Using pedal power (torque * cadence) to calculate motor current results in the current being zero amps until the cadence sensor is spinning fast enough to give an output. It makes the system very sluggish off the line.

A hybrid mode based on speed would be best so that torque only is used at the start and cadence only at then end ?
Probably, yes. Personally I'm 100% happy with a pure torque mode calculation. Works fine for me off road and on road.
 
Hi all. Option Byte issues have been discussed previously on other posts so here is my experience. I flashed our two identical bikes with the latest Mbrusa version but discovered some strange behaviours with option byte set to 20. First, on my bike the motor would periodically run uncontrolled at a speed around 12kph and even after braking to a halt the motor would start up again as soon as the brakes were released. The behaviour ceased after setting the motor power up to turbo and back to eco (where I normally ride), but this happened usually on every ride. The other bike the motor would just cease to work and had to be switched off and then on to recover operation. However, once the Option byte was set to 28 (as in the FS) there were no more incidents and the bikes performed normally.
 
Sorry if this seems a stupid question but I'm not sure what processor my motor is using, it's a 48V 750W version.

Looking on youtube there appears to be contradictions, either stm8s105x6 or stm8s105x4 processor.

Which one is it?
 
Guys, so I have tried to do something unusual today. I attempted to install a throttle onto the motor that came without it. I read that the controllers are all the same, just the wires for throttle are missing. Using guide for installing temp sensor, I simply soldered the wires to the motor controller and then hooked it to the throttle thing itself. I reflashed the firmware once with a throttle option enabled, nothing happened. It didn't work. Then I figured there is a brake sensor option that would be required, so I turned it on and flashed it again. Suddenly it worked the way it should. Sure the guide says "only with sensor brakes installed and enabled", I kind of thought it's a safety thing and even without brake sensor it would still work, just I would have had to be very careful when to use it. Anyways I put the bike onto its wheels and let it be, as the display was still turned on, I was putting some tape around the wires... Then suddenly the motor goes full power as if throttle is pressed all the way and drives itself into a wall causing quite a nasty accident in my balcony :x I can't understand what the hell happened. After that, every time I would connect throttle wires without touching the throttle, it would just instantly react and go into full power. I reflashed it again and recreated the effect. Turns out if I keep the bike turned on for a while with throttle connected, it stays in idle for around 3 minutes and then suddenly tries to go full power again... Is this a bug or is it supposed to act like that without the brake sensors?
 
Didcot said:
... contradictions, either stm8s105x6 or stm8s105x4 processor.

Which one is it?
For flashing firmware. Settings STVP:
Stock FW - stm8s105x4
OSF - stm8s105x6
 
Hi,

Just flashed Embrusa's latest OS Firmware to bike.
Improvement is way better than expected - Big Thank you to the guys giving up there free time to produce this stuff.

I have an issue with the Speedometer no longer working immediately after I installed OSF.
(I have checked wheel diameter & leave bike to settle for 30 secs after turn on - nothing works)

How do I reintall stock firmware to check if the speed sensor has gone faulty ?
If it works on Stock then the OSF must be causing an issue :-(

Any links would be really appreciated

Thanks Paul
 
anonpleb said:
.....

Just flashed Embrusa's latest OS Firmware to bike......

I have an issue with the Speedometer no longer working immediately after I installed OSF.
(I have checked wheel diameter & leave bike to settle for 30 secs after turn on - nothing works).....
imho you must biking for about 30 secondes. In that time the counter doesn't work till it is compensated for the time measured the values.
So only leave the bike for 30 sec isn't enough.
 
You can also disable the Odometer compensation box. then it will just add that km that it counts on startup.
 
Elinx said:
anonpleb said:
.....

Just flashed Embrusa's latest OS Firmware to bike......

I have an issue with the Speedometer no longer working immediately after I installed OSF.
(I have checked wheel diameter & leave bike to settle for 30 secs after turn on - nothing works).....
imho you must biking for about 30 secondes. In that time the counter doesn't work till it is compensated for the time measured the values.
So only leave the bike for 30 sec isn't enough.
Thanks - will try that when the the Biblical Storm we are having breaks !
 
matschi140 said:
You can also disable the Odometer compensation box. then it will just add that km that it counts on startup.

Was thinking of doing that myself as a test - thanks
 
So, today something strange happened to one of my TSDZ2's. I was out on a trail with a friend that was on an analog bike, so I turned off the assistance (power still on, assistance to zero). After a while I wanted some assistance in a steep climb, so I switched it up to 2, while I was pedaling hard. Nothing happened, and I looked down on the display, that was showing E04. I was about to stop and restart the display, but before I could turn it off, it switched off itself. I turned it back on, and I think it was on for a brief second, before I discovered the smoke, pouring out from the motor. Obviously, I unplugged the battery and has not tried it since. Pedaled it home with that familiar burned electronic stink surrounding me 😂

The reason Im posting this is if it could be a bug that caused this, or just a coincidence? I dont think it has anything to do with the osf, just wanted to ask in case there is something that should be looked at in the code. Im very happy with the osf, but the mechanical part of the system isnt just what I am needi g atm, so Im moving on to something else for this bike anyway. Will open it up and see what blew. Im guessing the controller is a dark, stinking brick 😂
 
I am also still waiting for somebody to clarify about the bug on the no throttle motors. Using Mbrusa firmware https://github.com/emmebrusa/TSDZ2-Smart-EBike-1 Why is it when I solder throttle wires to the controller and try to connect my own throttle, then it works how it should for a few minutes but then the motor goes full power by itself with no way to stop it ? I have tested the throttle with multimeter and it's not faulty. IS there a way to report the bug to somebody? Or is this really happening due to absence of brake sensors?
 
Is there a setting in the java app making the motor respond to pedal pressure right away? I saw there was a discussion of this in the other thread about it being unsafe, but I don't leave my bike lying around turned on. It would be really useful to have starting on climbs on the trail. The present delay (in torque assist setting) of half a turn or more is too long.
 
Kati-moa said:
Badmotor, what value have you set for the Option byte? Make sure it is 0028 not 0020.

I havent set any values about the optionbyte, because there was no such option in the Java configurator. Now Ive read about the optionbyte thing , is there an easy way to reset it to 0028 ?
 
Yes, it is easy but you need to use ST Visual Programmer. Connect up the ST-Link as normal and open the programmer (The JavaConfigurator is not needed or used). Select the Option Byte tab and what I do is 'Read' that tab to determine what is actually in the controller, change the byte from 0020 to 0028 and then 'program'.

It will write the change and verify. All done - good to go. However, until the Java Configurator is updated you will need to do this following each upload of SW, but is easy since everything is already connected.

Hope this fixes your problem
 
Kati-moa said:
Yes, it is easy but you need to use ST Visual Programmer. Connect up the ST-Link as normal and open the programmer (The JavaConfigurator is not needed or used). Select the Option Byte tab and what I do is 'Read' that tab to determine what is actually in the controller, change the byte from 0020 to 0028 and then 'program'.

It will write the change and verify. All done - good to go. However, until the Java Configurator is updated you will need to do this following each upload of SW, but is easy since everything is already connected.

Hope this fixes your problem
Hi,

Just when I thought I understood all this ......
Can you clarify the following :-

1. Option Byte = 20 Signifies OSF sotware is being used
2. Option Byte = 28 Signifies Stock is being used

If I have a new "Out of the box" motor and I program it with latest OSF software using Java Configurator, are you suggesting that I then have to use ST Visual Programmer to update Option Byte From 0020 to 0028. (If so could I use "STOCKOPTIONBYTE.S19" from
https://drive.google.com/drive/folders/1eGcBtTj8GrGQ4tDJAECr6ejMrpW2ZqvH).

If at some later time I use the Java Configurator to change some options I would have to change option byte manually again ?

Thanks Paul
 
Hi,
I have a problem with the setting of the battery indicator in the firmware. I don't understand the limits there.

I interpret the following from the instructions:
Display xh18
2.9v or less = No notch
3.25 - 2.91 = 1 notch
3.55 - 3.26 = 2 notches
3.85 - 3.56 = 3 notches
3.95 = Minimum voltage to Display 4 notches.

What happens between 3.85 and 3.95 ?
 
Paul, to make it clear why I suggested to Badmotor that he use 28 rather than 20 was in response to the issue he was having with 'no throttle motors'. In my experience with these controllers I found anomalous or unusual behaviour in the way the motor ran. In particular, the motor/controller would randomly kick into a form of cruise mode, the odometer would freeze and it was not easy to regain control of the ebike even after turning off and then on would not fix it sometimes. However, problems went away once I changed the option byte.

Now it may not be a problem in your case and the controller will behave as expected, but this is a strategy if strange things occur. Both of my ebikes with OSF installed have responded positively to the change. And yes, if the change solves the problem it goes without saying the byte will have to be changed after every upload until those doing the development determine the right approach for the SW.

Ian
 
Back
Top