Thanks I will try that.
TSDZ8 OSF (open source firmware)
- Thread starter mstrens
- Start date
I connected earlier battery 54.1V to motor and VLCD5 had one bar. Now I connected 48.5 V battery and one bar is blinking and soon after power on display goes off. Firmware is OSF_TSDZ8_V00_01_11.hex and default TSDZ8 48 V from java configurator except walk assist and brake sensors enabled. Earlier walk assist was working and now not anymore.
There is something problem in controller. Now one is coming maybe next week.
There is something problem in controller. Now one is coming maybe next week.
This is strange. Just for a test, I suggest that you upload an "official" firmware (e.g. from the ebikestuff web site) just to see if this firmware provides you the expected number of bars (for the voltage).
I have already controllers original and ebikestuffs version on my computer.
There is something strange in controller. Today VLCD5 showed full bars with same settings on controller yesterday. And brake sensors and walk assist are working again.
Yesterday two errors 02 and 03 alternated on the display. 02 refers to torque sensor. I don't know what is 03.
There is something strange in controller. Today VLCD5 showed full bars with same settings on controller yesterday. And brake sensors and walk assist are working again.
Yesterday two errors 02 and 03 alternated on the display. 02 refers to torque sensor. I don't know what is 03.
In vldc5 manual I see
ERR-02Motor hall fault or motor short circuit
ERR-03Controller failure
ERR-04Throttle failure
ERR-08Low battery alarm
ERR-06Turn on the motor with cyclist’s feet on the pedal for coaster brake version
In OSF codes have other meanings:
#define ERROR_OVERVOLTAGE 1 // E01 (E06 blinking for XH18)
#define ERROR_TORQUE_SENSOR 2 // E02
#define ERROR_CADENCE_SENSOR 3 // E03
#define ERROR_MOTOR_BLOCKED 4 // E04
#define ERROR_THROTTLE 5 // E05 (E03 blinking for XH18)
#define ERROR_OVERTEMPERATURE 6 // E06
#define ERROR_BATTERY_OVERCURRENT 7 // E07 (E04 blinking for XH18)
#define ERROR_SPEED_SENSOR 8 // E08
#define ERROR_WRITE_EEPROM 9 // E09 shared (E08 blinking for XH18)
#define ERROR_MOTOR_CHECK 9 // E09 shared (E08 blinking for XH18)
I do not know what are the code used by the TSDZ8 original firmware.
jped277
10 mW
Is it safe to run this firmware yet? Have you solved the issue of burning up controllers?
It is better to wait. The feeling is not perfect.
I still do not yet know why some controllers were damaged.
At this stage, I expect that it is not the firmware that damaged my controller ( because it is only the torque sensor driver that has an issue). For the other controllers, I have no news.
jped277
10 mW
I hope you guys can help me I was just riding my e-bike and out of the blue the throttle started acting weird and the odometer went to 9999. I don't have open source firmware on it right now but I did put it on and take it back off. Is this a firmware problem maybe some ghost code?
Attachments
jped277
10 mW
I discovered for some reason it thought the wheel size was 280 inches and the magnets number was maxed out at 140 or something so my odometer is now at 999 forever. Please tell me there's a way with the J-Link to reset my odometer
jped277
10 mW
Well I found out you hold plus minus and info for 10 seconds to reset the odometer. And I reflashed the original updated firmware from tongsheng to fix the issue with the wheel size being 280inches. I'm assuming I got a bug in the system but does anyone here have any info or idea what happened?
There are still issues with the torque.
I noticed that the current was fluctuating a lot (at midle frequency) and I seached a way to solved it.
I supposed it was a bug in my code.
I asked on the web but did not find a solution.
I tested a total different way of controlling the motor and I got similar or even bigger variations.
So I expect they are inherent to way the motor is build.
I will now try to increase the filtering of the current measurement in the firmware to avoid those fluctuation at middle frequency.
Wait and see.
I am still waiting new controller and torque sensor. They have arrived two weeks ago but there is some new EU regulations to be needed for customs and I can't declare them. I'm get tired for waiting and ordered whole motor which is imported from Germany so no customs needed. See what troubles for that is coming.
At this stage, I do not yet know the FOC parameter to use for TSDZ8. For first tests, I used a lower value for foc_multiplier because the motor has 4 poles instead of 8 poles (for TSDZ2) and so erps is lower. I set it on 24. but I expect it could even be lower.
I made a lot of search because I expected that the total current should be quite constant (for no load or a given load).
first I suspected the ADC measurements (because the values fluctuates a lot) but when I put a scope on a shunt between battery and motor, I saw also huge fluctuations at a frequency that is 6 X the frequency of the magnetic flux rotation. So the issue is not related to the ADC.
I tested also a true FOC algorithm (using Clarck and Park transform) and I also noticed big fluctuations at the same frequency.
So I expect that those fluctuations are to be considered as "normal" and probably due to the befm.
Due to the huge current fluctuations within one electric rotation, it seems me now better to calculate the average current per electric rotation and to use this average to manage the motor regulation.
I plan to deliver soon a version that would be regulated on the average current per rotation. To be tested on a bike to see if the user still feel jerking.
I'm just asking what is the status of the 860c firmware development.
Sorry off topic. I was riding today my bike with TSDZ2 motor and suddenly assist was gone. I rebooted 860C display few times but no assist. I drive always on torque mode because I like it most. Then I changed assist mode to cadence and assist was back. The advantage of 860C display is to change assist mode straight from display. if I have had a vlcd5 display, I would not have had the possibility to change the assist mode on the road. That is one reason why I like 860C display.
Sorry off topic. I was riding today my bike with TSDZ2 motor and suddenly assist was gone. I rebooted 860C display few times but no assist. I drive always on torque mode because I like it most. Then I changed assist mode to cadence and assist was back. The advantage of 860C display is to change assist mode straight from display. if I have had a vlcd5 display, I would not have had the possibility to change the assist mode on the road. That is one reason why I like 860C display.
With a VLCD5 you can also change the assist mode using the keyboard (no need to reflash). Still I agree that it is not so easy than with a 860c. With LCD5 still most parameters can only be changed by the javaconfigurator.
In the last 2-3 weeks, I did not work on the 860C version for TSDZ8 bacause I tried to solve the jerking issue.
I put on github a new version (for LCD5) and I asked ebikestuff to test it (as he did most of the tests with the previous version).
If jerking issue is solved, then I will work again on 860C version.
Ok, where can I find instructions for changing assist mode on VLCD5. I'm waiting new motor and controller to come. After that I can test your firmware again.
here : TSDZ2-Smart-EBike-1/manuals at master · emmebrusa/TSDZ2-Smart-EBike-1
Please note that there are different versions of OSF. This is for the mbrusa version on vlcd5 (and other displays that uses the original protocol)
Thank you very much.
Congratulations and thanks for the work Mstrens, I have tested version 13.hex and you have managed to solve the problem of engine fluctuation and now your osf works really well, I have tested on xh18 for now, power mode (acc 35 and dec 35) 22A 1200W max, I checked with an external ammeter and the engine reaches these 22A. I have also tested on ekd01, there are no errors, it just does not show the current engine power well. If you need anything else to test, let me know. Soon I will check it with vlcd5.
Thanks for the feedback.
Did you try to change the foc multiplier? If yes, what is the value that gives best efficiency?
Did you try only with a home trainer or also on a bike?
Did you try it also at slow speed (low RPM). After releasing version 13, I had some doubts that it would work well and I was thinking making other changes. Did you see the mail with the text below?
In addition to my previous mail (see below), I can say:
I further looked at your last video.
In this video, the actual duty cycle was always on 254 (the max value) when throttle is on . This is because the measured current remains lower than the target current. I noticed that the measured current was wrong because it was twice lower than it should be (there was a bug in the firmware). Still even if the measured current would have been correct, it would remain below the current target and so the actual duty cycle would always stay on the max value.
This means that there is no regulation done by the firmware that could explain the current fluctuations on the BMS.
I expect that the only parameters that could create the fluctuations would be:
- an non optimal foc angle
- some load variations in the home trainer.
I suggest you try to find the best foc angle for a given load/speed and see if there is no significant current fluctuation on the BMS.
I tested only on the bike, also at lower speeds and compared to previous hex versions (I did not test version 12 because I was away for a long time) it works much better, I will upload my settings, I did not change anything in config, i.e. foc was default, all the parameters that I changed were only in java config, it was not necessary to change acc or dec because there was no jerking/wavering of the engine, in reference to the email I hardly tested throttle because I rarely use it myself, I will pay attention to that, however when pedaling it was already more or less ok. I will test it again and let you know.
Attachments
I will try to resume what your tested. Please say me if I am wrong.
- your tested version 13 in 3 ways
- 1 : on the home trainer at full throttle and with different loads and foc multipliers.
- 2 : on a bike with a previous java configuration (and so acceleration/deceleration was not the default values)
- 3 : on a bike with default values in javaconfigurator.
- In test 1 I noticed that the actual current remains always lower than the target current. It means that the firmware does not regulate the power because actual duty cycle remains 254 (with full thottle). Changes I made in version 13 (averaging current over a whole electrical rotation) should not have any impact. So result should be similar as with some oldier versions (except version 11 that underestimated the current and so the FOC angle). This test seems to show that when load/current is high, increasing the FOC multiplier gives better efficiency. Still you could not test values above 30 for FOC multiplier because uc_probe did not allow it (furthermore, current firmware limits the FOC angle to 13). In a future version, I could remove those limit to see if a value above 30 would be better.- in test 2 and 3, I expect that the current target is much lower than in test1 (due to the assist level). So I expect that the actual current can reach the target current and therefore the duty cycle would be lower than 254. In those conditions, the firmware adapts the duty cycle in order to keep the actual current close to the target current. 2 factors can influence the way the regulation acts: the acceleration/deceleration rate on ne side and the way actual current is measured (using more or less averaging).
In test2 you still noticed more flinkering than in test 3: So I expect that acceleration/deceleration rates play an important role (because this is the only changed between the 2 tests, averaging current measurement being unchanged). Perhaps that averaging current method introduced in version 13 helps also but it was not enough).
Please note that in tests 2 and 3, the foc multiplier was 14 and so efficiency was not optimum (at least when current increases where FOC angle become important).
Please confirm if my statements are correct are correct or not.
I could then propose some more changes and test process.
@prozyc
I expect that my post here above seems you quite strange because I refer to testing in 3 ways.
This is my fault.
In fact outside of this forum I also had some mail exchanges with ebikestuff.
I thought that prozyc was the pseudo name of Ebikestuff on this forum and this created some confusions.
FYI ebikestuff makes also some tests on a home trainer with version 13. He provided a video that I callled test 1 in post above.
To clarify things I put here below a related mail from ebikestuff:
I did a few tests. The video can be seen here:
While doing the high amps test I've noticed that the battery connector gets hot. Probably a bad solder joint. This might have affected the efficiency a little so I soldered a new connector to make sure everything is working fine. The last test in the video above is with the new battery connector. I don't know if there's any difference.
Anyway. It seems like the efficiency is fine when using higher foc multiplier. As you can see on the video, the higher values like 28 or even 30 result in the highest rpm. The power output on the home trainer seems to be reflecting that. It's hard to tell the difference between those higher values. I would have to record a longer video and try to calculate the average power draw from BMS and compare it against the average power from home trainer. I believe that the differences would be small. But definitely the lower values like 14 are not optimal for the efficiency.
The fluctuations are still there but I've only noticed them after running the test with high load for a while.
I also did a few kms commute. The jerkiness is still there. The assistance doesn't seem to be smooth. It works but the motor gives that "jerky" feeling. I haven't tried different modes. I only used hybrid. It's possible that it's caused by the old config with the torque sensor calibration that I used. If I have some spare time I will try the default config and see if there's any difference.
Please note that getting a current of 22A is not necessary a good thing. In fact it could be that the motor has low efficiency (due to non optimal synchronization of the rotation of the magnetic flux). When synchronization is not good, the motor consumes more for the same effective power.
In version 13, I hardcoded a parameter called FOC multiplier on a value = 14. I expected this would be good but the tests made by ebikestuff on the video with a home trainer seems to indicate that the value should be much higher (he get highier rpm with lower Amp).
I expect that my post here above seems you quite strange because I refer to testing in 3 ways.
This is my fault.
In fact outside of this forum I also had some mail exchanges with ebikestuff.
I thought that prozyc was the pseudo name of Ebikestuff on this forum and this created some confusions.
FYI ebikestuff makes also some tests on a home trainer with version 13. He provided a video that I callled test 1 in post above.
To clarify things I put here below a related mail from ebikestuff:
I did a few tests. The video can be seen here:
While doing the high amps test I've noticed that the battery connector gets hot. Probably a bad solder joint. This might have affected the efficiency a little so I soldered a new connector to make sure everything is working fine. The last test in the video above is with the new battery connector. I don't know if there's any difference.
Anyway. It seems like the efficiency is fine when using higher foc multiplier. As you can see on the video, the higher values like 28 or even 30 result in the highest rpm. The power output on the home trainer seems to be reflecting that. It's hard to tell the difference between those higher values. I would have to record a longer video and try to calculate the average power draw from BMS and compare it against the average power from home trainer. I believe that the differences would be small. But definitely the lower values like 14 are not optimal for the efficiency.
The fluctuations are still there but I've only noticed them after running the test with high load for a while.
I also did a few kms commute. The jerkiness is still there. The assistance doesn't seem to be smooth. It works but the motor gives that "jerky" feeling. I haven't tried different modes. I only used hybrid. It's possible that it's caused by the old config with the torque sensor calibration that I used. If I have some spare time I will try the default config and see if there's any difference.
Please note that getting a current of 22A is not necessary a good thing. In fact it could be that the motor has low efficiency (due to non optimal synchronization of the rotation of the magnetic flux). When synchronization is not good, the motor consumes more for the same effective power.
In version 13, I hardcoded a parameter called FOC multiplier on a value = 14. I expected this would be good but the tests made by ebikestuff on the video with a home trainer seems to indicate that the value should be much higher (he get highier rpm with lower Amp).
