Tsdz2 firmware open source adapted to vlcd5, vlcd6 and xh18

[Elinx]

...... i will do the wiki thermal mod (i dont think i will open the electric motor to put thermal paste but will do the others even the cutting of the case) ........

Imho cutting the case isn't necessary and maybe the paste between the flanges isn't too (instead you can push some thermal silicon putty too) , but I think that thermopads placed as in the wiki are imho improving a lot, because the thermal conductivity is not only to the case cover.

FYI
There is a collection of thermo mods in a separate topic

 

[vass]

...... i will do the wiki thermal mod (i dont think i will open the electric motor to put thermal paste but will do the others even the cutting of the case) ........

Imho cutting the case isn't necessary and maybe the paste between the flanges isn't too (instead you can push some thermal silicon putty too) , but I think that thermopads placed as in the wiki are imho improving a lot, because the thermal conductivity is not only to the case cover.

FYI
There is a collection of thermo mods in a separate topic

Having some air passing throught so much metal after cutting the case should help a bit , but i think i will only do it after i have the 860C and the full osf installed so i can have temperature readings (so i can compare and at least give some info back here).
I think after installing a bashplate and if we can prevent water from entering from there its a safe and cheap way to help it stay cooler

 

[Elinx]

....after i have the 860C and the full osf installed so i can have temperature readings .....

OSF v0.20 is a full (but a bit older) version and temperature readings are also possible with the version for stock displays.
The difference is that the configuration must be done before, with the configurator and flashed to the controller.
With 860C you can use the display to configure the controller.

 

[psl2806]

Okay, I'm slightly starting to panic now.

A few days ago I flashed my motor with the OSF for the first time. Everything seemed to look good the only thing I noticed was that the speed was not correct. I have a recumbent with 20" wheels so I changed the cicumference to 1510mm.
After the update the bike responded very erratic. I noticed that the computer registered the speed wrong as if 10 times to fast. And then nothing Which probably caused the motor to stop after it started.
I flashed it again with the original setting but that would n't help. From there it went worse, speed is no longer registered. The battery which supposed to be full shows up empty on the display and the motor no longer works.

Thinking is would be the firmware I flashed it again with the original firmware. But that did n't change a thing.
Anyone got an idea what could have gone wrong? Maybe a cable issue? Hopefully some tips how to troubleshoot this.

U

Update: I started having doubts about having damaged the cable so I started thinking, if the flashing can go wrong with OSF it can also go wrong with the original firmware. So I gave it another try. And phew what relief. I could see the battery status coming back and lights working too. Everything worked. So I also gave it another try at the OSF. Motor working, lights working but still issues with speed. The placement of the sensor seems to be very very sensitive. It's working but still does not feel very reliable. I read that more people have issues with this, but I can't find the advice that specifies the exact spec of the distance between the magnet and the sensor. Anyone got more info about that?
Thanks everyone for helping me solve this issues!

 

[Elinx]

....I can't find the advice that specifies the exact spec of the distance between the magnet and the sensor. Anyone got more info about that?....

The magnet may not to close to the speedsensor. Dependent of the sensitivity of the reedcontact inside the speedsensor
If the magnet is too close it is possible to get strange effects.
Try first 3mm, otherwise go to 5mm, but won't be surprised if it will be more.

 

[Waynemarlow]

We are finding 8mm to 10mm clearance works best.

 

[kallt_kaffe]

An update on the matter of the internal battery pack resistance. Calculating the internal resistance and showing it is very possible, however the value varies as there seems to be a delay in the voltage fluctation when current changes. I actually did some filtering to try to minimize this in order to keep this fully automatic but in the end I realized that the same delays making it hard to get stable value is the same delays that will make sure the battery bars do some flickering even if you get the internal resistance value correct.

So I decided to take another approach to it and instead of trying to measure voltage flucation under load I instead save the voltage everytime the currrent has been zero (no load) for 2 seconds and use that value and that value only for the battery bars. I no longer use the internal battery resistance value.

I did 45km ride today watching the battery bars drop from 6 to 3 bars and did not see a single batterybarflicker during the entire ride. There is a catch though. If you ride a long time with constant load the battery bars will not update. The way I use my bike this is not an issue but I guess it might be for some people?

Not being sure if all my changes to the code are what everyone wants I cloned the repository and pushed my changes to my own version of the repository if anyone else would like to give it a try and/or if emmebrusa wants to cherrypick some of the changes for the main repository.
This is the changes I've made and the code I'm currently been using for some time now: https://github.com/kalltkaffe/TSDZ2-Smart-EBike-1/commit/8bbea1a8cab498fbb71dad019b786a54929b9447

 

[Elinx]

.......pushed my changes to my own version of the repository if anyone else would like to give it a try.....

:thumb: Your solution is a good one to see the voltage drop, but as you said before. It works the best if you have a short stop ( >2s ) on a regular base.

 

[kallt_kaffe]

:thumb: Your solution is a good one to see the voltage drop, but as you said before. It works the best if you have a short stop ( >2s ) on a regular base.

You don't need to stop but you need to stop pedaling for 2 seconds or more and I think most people do that frequently when biking.

 

[Elinx]

..... you need to stop pedaling for 2 seconds or more ......

In that case this is for most people useable
I will install your mod for sure

 

[Waynemarlow]

I have found I think a repeatable problem, I have had on occasion a motor not responding once programmed to the torque sensor. Program the motor and all other functions will work except reading the torque sensor. If you revert back to the factory memory and program files it still will not work.

One of the posters recently said he also reprogrammed the Options part of the files which I have never done and low and behold I downloaded the S19 options file from Eco Bikes and it enables the torque convertor to be read again.

With the motor I have here at the moment I have to first program the motor using the configurator and then reprogram the Options using the STC program with the S19 file from EcoBikes. Its repeatable.

Any clues ?

 

[kallt_kaffe]

I have found I think a repeatable problem, I have had on occasion a motor not responding once programmed to the torque sensor. Program the motor and all other functions will work except reading the torque sensor. If you revert back to the factory memory and program files it still will not work.

One of the posters recently said he also reprogrammed the Options part of the files which I have never done and low and behold I downloaded the S19 options file from Eco Bikes and it enables the torque convertor to be read again.

With the motor I have here at the moment I have to first program the motor using the configurator and then reprogram the Options using the STC program with the S19 file from EcoBikes. Its repeatable.

Any clues ?

What happens if you manually flash the option_no_prot.ihx file instead (you'll find it in C:\TSDZ2-Smart-EBike-1-master\src\controller). It's the options file the configurator uses.

If that produce the same result as flashing with the configurator you could compare the stock-options-file and option_no_prot.ihx and try to figure out which setting in option_no_prot.ihx that couse the problem.

 

[Elinx]

.... compare the stock-options-file and option_no_prot.ihx and try to figure out which setting in "option_no_prot.ihx" that couse the problem.

I don't have a problem, but have compared the stock option byte of my backups (different motors and sources) with "option_no_prot.ihx". Couldn't compare the S19 file, because this is a different file.
All different stock files are identical, but differ with "option_no_prot.ihx" the third row.
I don't know what the meaning is of this third row, but maybe someone does

 

[kallt_kaffe]

I don't have a problem, but have compared the stock option byte of my backups (different motors and sources) with "option_no_prot.ihx". Couldn't compare the S19 file, because this is a different file.
All different stock files are identical, but differ with "option_no_prot.ihx" the third row.
I don't know what the meaning is of this third row, but maybe someone does

If you install the ST Visual Programmer you can load the option files into it and see what the differences mean.
EDIT: Actually, if you've followed the instructions in the wiki you should have it installed already.

 

[Waynemarlow]

Sorry guys, my programming skills are not that good and really can't help you here.

Apologies.

Elinx do you want me to make the S19 file available here but if you look on there website you can download it direct. I think the S19 and the hex files re the same ?

https://drive.google.com/drive/folders/1eGcBtTj8GrGQ4tDJAECr6ejMrpW2ZqvH

 

[Elinx]

...I think the S19 and the hex files re the same ?

https://drive.google.com/drive/folders/1eGcBtTj8GrGQ4tDJAECr6ejMrpW2ZqvH

The S19 file is identical to my backups. With STVP I see some differences (AFR5 and AFR3) with "option_no_prot.ihx"
But the only thing I can do is comparing files, not interpretating.



View attachment TSDZ2_36v_Stock_Option_Byte.zip

 

[Waynemarlow]

The S19 file I used seems to cure the problem, if that matches your files that also work, could we change the configurator to this file if the one on the configurator is different ?

 

[Elinx]

... could we change the configurator to this file if the one on the configurator is different ?

MarcoQ used the option_no_prot.ihx already with his versions. This file could be replaced by the stock file, but the question is, what the differences mean and why there are no more (or not so many) complains.

 

[stancecoke]

but the question is, what the differences mean and why there are no more (or not so many) complains.

Port B0 to Port B2 have to be set to the alternate function timer1 channel 1-3 N output. This processor pins drive the low side Mosfets.

The "option_no_prot.ihx" sets the pins to analog input. This can't work.

Regards
stancecoke

 

[Elinx]

......
The "option_no_prot.ihx" sets the pins to analog input. This can't work......

In that case, what happens if the program- or flash- batfile runs, because with these bat files "option_no_prot.ihx" will be flashed. If this can't work, shouldn't there be more complains?
As said, I think this OptionByte file is there from the beginning with MarcoQ's builds too.

 

[Waynemarlow]

I have only seen a problem on 2 motors out of about 10 I have programmed, but that's a pretty big hit rate, maybe others are just reprogramming the option byte when a problem occurs, there's been more than a few registering that the torque sensor stops working, we had been replacing the torque sensor / controller thinking it was a hardware fault.

At worst we need to put up a method of getting around the problem, that of just reprogramming the option byte.

The other question has to be, was it there from the factory setup as a software bug ?

 

[Elinx]

.....
The other question has to be, was it there from the factory setup as a software bug ?

Imho it isn't
I found a earlier post with a sort of same problem
https://endless-sphere.com/forums/viewtopic.php?t=93818&start=1600#p1438745

And here the TSDZ2 fw files of HurzHurz XH18 FW research (option_byte.hex is identical as 36Vstock backup), which communication protocol Marcoq has used as a base for OSF for stock displays
So if the "option_no_prot.ihx" inside the OSF isn't working it is unknown what the source would be.
I am surprised that this is the first time that we see this.
The first Marcoq version 0.16 is from december 2018 that has this file already.

Edit:
I have added an issue about it on mbrusa's github, with a reference to your post.

 

[mbrusa]

...I think the S19 and the hex files re the same ?

https://drive.google.com/drive/folders/1eGcBtTj8GrGQ4tDJAECr6ejMrpW2ZqvH

The S19 file is identical to my backups. With STVP I see some differences (AFR5 and AFR3) with "option_no_prot.ihx"
But the only thing I can do is comparing files, not interpretating.

OptionByte.jpg

TSDZ2_36v_Stock_Option_Byte.zip

Hi Elix
I will try to replace the option_no_prot.ihx file with stock.hex
But there is something I don't understand, in all my backups of the stock versions, the options file are identical to each other even with binary comparison.
The OptionByte.S19 files, option_no_prot.ihx, stock_36V.hex, with binary comparison are all different, but open with STVP GUI they are the same, I don't see the difference you have reported.
Maybe it depends on the version of STVP GUI?
I have version 3.2.7, what version do you use?

 

[Elinx]

.....
..... in all my backups of the stock versions, the options file are identical to each other even with binary comparison.
The OptionByte.S19 files, option_no_prot.ihx, stock_36V.hex, with binary comparison are all different, but open with STVP GUI they are the same,.....
I have version 3.2.7, what version do you use?

All my backups, downloads and the S19 file are binary and with STVP the same (also with the first source (aug 2018) of HurzHurz), but different with "option_no_prot.ihx".
Other differences are the extentions of the files (hex, S19 and ihx)
I use STVP version 3.4.1

 

[Waynemarlow]

Guys, thanks for the quick look at this for me.

I still have one of the problematic motors here ( kept it back for a few days whilst you were looking at the problem ) and can reprogram the motor with any changes you make to verify the changes ?

Let me know as I should get the bike back to the owner.