TSDZ2 mid drive with 860C, 850C or SW102 displays only -- Flexible OpenSource firmware (Casainho code only)

I'm working on a bug related to loading the configuration files .ini, may be loaded wrong parameters, so at the moment I recommend deleting the .ini files in the folder proven settings and experimental settings so in the configurator will be loaded only the default parameters. Modify the parameters of your interest.... then compile and program.
 
casainho said:
v0.17.0-beta5 is available here, please test and give feedback:

https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.17.0-beta5

Changes:

- implemented automatic fast increase/decrease of variables on configuration menus
- settable odometer
- trip distance function
- imperial units throughout the system
- saved menu state for all menus when power down
- flashing time on menu number and variables is now short -- it is easier to see the values
- TM and TTM time measurement

This beta release of firmware for KT-LCD3 works with the same previous TSDZ2 v0.16.0 firmware version:
- TSDZ2-throttle-v0.16.0.hex
- TSDZ2-v0.16.0.hex

No bugs to report over 40 miles of testing, all the new features work well. This is with a 52v battery, no temperature sensor, throttle, off road mode not enabled. Great stuff.

My only adverse comment is yet again about indicated human power in watts which seems high (possibly 2x) and also the pedal assist multiplication factor that set motor watts is derived from . I use 9 levels of pedal assist and the first four levels I have set at 0.2x, 0.4x, 0.6x and 0.8 x but the motor power results are not a simple product of human power x pedal assist multiplier. 0.2x produces motor watts half of indicated human power, 0.4x matches motor watts with human power and 0.8x produces motor watts of 2x human power watts. I say roughly as the values are always wildly fluctuating but the observed relationship is not far out, though I suspect 0.25x, 0.5x and 1x would give much the same result, it's just that I use those settings. Of course in reality once the desired setting are tuned in then they could just as easily be bananas rather than watts but as the facility is there it makes sense to make it accurate.

All in all this latest firmware is excellent and a pleasure to use. thanks.
 
Rafe said:
No bugs to report over 40 miles of testing, all the new features work well. This is with a 52v battery, no temperature sensor, throttle, off road mode not enabled. Great stuff.

My only adverse comment is yet again about indicated human power in watts which seems high (possibly 2x) and also the pedal assist multiplication factor that set motor watts is derived from . I use 9 levels of pedal assist and the first four levels I have set at 0.2x, 0.4x, 0.6x and 0.8 x but the motor power results are not a simple product of human power x pedal assist multiplier. 0.2x produces motor watts half of indicated human power, 0.4x matches motor watts with human power and 0.8x produces motor watts of 2x human power watts. I say roughly as the values are always wildly fluctuating but the observed relationship is not far out, though I suspect 0.25x, 0.5x and 1x would give much the same result, it's just that I use those settings. Of course in reality once the desired setting are tuned in then they could just as easily be bananas rather than watts but as the facility is there it makes sense to make it accurate.

All in all this latest firmware is excellent and a pleasure to use. thanks.

Thank you once again, Rafe, for your feedback and the testing you carry out!

I see no apparent problem or flaw with the math or physics regarding the calculation of human power. But that only holds true for ideal models. This seems to be a quite challenging thing to measure and compute. Have not really looked into this too much but if there are any problems with linearity, or lack thereof, in the sensors it becomes a much more involved bug to solve. Not listing other possible problems.

The assist multipliers are just values multiplied with some value we calculate from the torque sensor and measured RPM. It might not be representative of real human power, yet, but works well enough. In my latest contribution of code I divided the calculated human power value by two (2) and that gives a somewhat better representation of real values. This is NOT intended in any way to solve the problem, instead it is just a quick patch so a more realistic value of human power is displayed without the user having to change the assist multiplier values.

It is great seeing posts from users leaving feedback and thoughts to the problem!
 
Thanks for info Buba

It has occurred to me a few times that the cadence input into calculated human power is perhaps excessive or disproportionate, it does feel odd that motor assist Watts is at its lowest on the steepest part of the hill (when it is needed most) as cadence is also low but the force applied to the pedals at its greatest. Then motor assist picks up as the hill starts to level off (not needed as much) with cadence increasing and pedal force decreasing.
 
Would be nice if you could refer on the video description (this first one) that you are running TSDZ2 mid drive motor running tye flexible OpenSource firmware and link to project page.

done : there s a link in the first part of the video,
i m not a pro you tuber soo if someone have suggests !?

[youtube]2MJOG5QFkDw[/youtube]

And yes, open source firmware is a great improvment, i like it, will down assit levl 1 from 0.4 to 0.3 for saving battery use when i m riding with someone without motor .

I used 278 wh for this ride ( 36 km and 1450 D+ ) witch is fine, i was using a 13A curent Amp with stock firmware and had a good result to save battery use too, but seem open source firmware is superior in the use of the power and battery .

I see that when "human power " was for example "200w" motor gave about "80W", soo it s ok with lvl 1 parameter at 0.4 .
Don t know if it s possible to calculate the exact "human power " but parameters could be adjusted soo it s not very important .

i m using 0.016 TSDZ2 release, same for LCD3 ( not using 0.17 beta at the moment, will move to 0.17 when achived ) .
 
I have just flashed my TSDZ2 for the first time today with the Marcoq build (TSDZ2_Controller_vM0.16.B_VLCD6_and_TSDZ2_Configurator_v0.1.2) so I can test with the VLCD6 display for now. I do have a 850C display modified with an external connector but still trying to work out the toolchain for that path.

All has gone great flashing the firmware so I did a comparison against the stock Firmware on a small hilly loop around my house. Running on 36V 10S5P battery the stock firmware would pull about 15A max in highest assist level with hard pedaling however the opensource firmware tops out at 7A and is noticeably down on power. I am using a separate power analyzer on the bike to take live readings and peak readings.

To be fair it does not feel half the power I would say more like 70%.

I have been using the Java tool to edit a the motor wattage and set it to 500W (from 250W) but all other settings are using the default_configuration.ini settings. Battery voltage/and AMP settings seem fine and should deliver up to 17A without issue.

I'm sure I am missing something obvious, but I cannot think why the motor would use so much less power in full assist?
for flat general riding, it feels enough but I would like to have the option of the power that I was getting from the stock firmware, ideally a little more. I even switched back to the stock firmware to be sure, and sure enough, it was back to the full 15A I would expect.

well i m using marcoq archive in one of my bikes, it work fine but " offroad mode " disabled, soo no limitation of power .

haven t used "configurator " for the moment and only edited " data memory " tab for my use, it s documented in the thread, in page 61 if i remenber ( cherch my post ) ...

i use also a separated wattmeter to check current, i don t need more than 650W ( battery use soo it s about 500w eff ) .

editing " data memory " max current battery " is set to 16A, don t know with VLCD6 but for VLCD5 standard marcoq set up are too strong, lvl 1 gave about 450 w pedaling strong, soo i changed parameter not using configurator but editing "data memory " tab .
 
elem said:
editing " data memory " max current battery " is set to 16A, don t know with VLCD6 but for VLCD5 standard marcoq set up are too strong, lvl 1 gave about 450 w pedaling strong, soo i changed parameter not using configurator but editing "data memory " tab .

Thanks Elem, Would you mind sharing a screenshot of your data memory area so I can compare with mine.
 
pay attention, i m using VLCD5 instead of VLCD6, also 11S battery ( 39.6V nominal, 46.2V max )

11s 16A 550W.jpg

0x004000 : AA 03 00 10 1B 3F 01 23 08 2D 01 00 19 0A 0B C4
0x004010 : 00 3B 01 03 06 0C 18 00 00 04 0C 14 1C 14 23 01
0x004020 : 22 00 4B 55 0A 0C 12 1A 20 28 14 00 00 00 00 00


0x004001 : 03 ( default value assist level factor x10 )
0x004003 : 16 amp = 10 ( default value battery max current )
0x004004 : 270W = 27 = 1B ( default value motor max power x10 )
0x004005 : 31.9 V = 319-256 = 63 = 3F ( default value battery low voltage cut off x10 00 )
0x004006 : 256 = 01 ( default value battery low voltage cut off x10 01 )
0x00400E : 11= 0B ( battery nombre de cells )
0x004013 : 03 = 03 ( lvl 1 )
0x004014 : 06 = 06 ( lvl 2 ) 06 06
0x004015 : 12 = 0C ( lvl 3 ) 0C 12
0x004016 : 24 = 18 ( lvl 4 ) 18 24
0x004020 : 550w/25 = 22 ( max batt power div 25 )
 
Made some tests with VLCD5 using marcoq code,
as vlcd6 use 4 line bargraphe, in VLCD5 you lose first 1 bar, second 2 bars, third 2 bars, last begin to blinck at about 2 Volt before cut off and assit begin to grow down, about 50W max at 1.5 Volt before cut off .

Work better than stock firmware witch first bar was lost at about half battery .

if someone ( marcoq ? ) know where is the part of the code, may be it could be possible to modify code to adjust VLCD5 6 bar > bargraphe ? It s not very important in fact .

Ok found it ! lol, it s out of my brain ...

in : ebike_app.c
part of the code 512 to 527 ...

#if ENABLE_BATTERY_SOC_6_LEVELS
if(ui16_battery_voltage_soc_x10 > ((uint16_t) ((float) ui8_battery_cells_number_x10 * LI_ION_CELL_VOLTS_100))) {ui8_battery_state_of_charge = 6;} // 4 bars --> full + overvoltage
else if(ui16_battery_voltage_soc_x10 > ((uint16_t) ((float) ui8_battery_cells_number_x10 * LI_ION_CELL_VOLTS_83))) {ui8_battery_state_of_charge = 5;} // 4 bars --> full
else if(ui16_battery_voltage_soc_x10 > ((uint16_t) ((float) ui8_battery_cells_number_x10 * LI_ION_CELL_VOLTS_50))) {ui8_battery_state_of_charge = 4;} // 3 bars
else if(ui16_battery_voltage_soc_x10 > ((uint16_t) ((float) ui8_battery_cells_number_x10 * LI_ION_CELL_VOLTS_17))) {ui8_battery_state_of_charge = 3;} // 2 bars
else if(ui16_battery_voltage_soc_x10 > ((uint16_t) ((float) ui8_battery_cells_number_x10 * LI_ION_CELL_VOLTS_10))) {ui8_battery_state_of_charge = 2;} // 1 bar
else if(ui16_battery_voltage_soc_x10 > ((uint16_t) ((float) ui8_battery_cells_number_x10 * LI_ION_CELL_VOLTS_0))) {ui8_battery_state_of_charge = 1;} // blink --> empty
else{ui8_battery_state_of_charge = 0;} // undervoltage
#else
if(ui16_battery_voltage_soc_x10 > ((uint16_t) ((float) ui8_battery_cells_number_x10 * LI_ION_CELL_VOLTS_83))) {ui8_battery_state_of_charge = 5;} // 4 bars --> full
else if(ui16_battery_voltage_soc_x10 > ((uint16_t) ((float) ui8_battery_cells_number_x10 * LI_ION_CELL_VOLTS_50))) {ui8_battery_state_of_charge = 4;} // 3 bars
else if(ui16_battery_voltage_soc_x10 > ((uint16_t) ((float) ui8_battery_cells_number_x10 * LI_ION_CELL_VOLTS_17))) {ui8_battery_state_of_charge = 3;} // 2 bars
else if(ui16_battery_voltage_soc_x10 > ((uint16_t) ((float) ui8_battery_cells_number_x10 * LI_ION_CELL_VOLTS_0))) {ui8_battery_state_of_charge = 2;} // 1 bar
else{ui8_battery_state_of_charge = 1;} // blink --> empty
#endif
 
buba said:
Thank you once again, Rafe, for your feedback and the testing you carry out!

I see no apparent problem or flaw with the math or physics regarding the calculation of human power. But that only holds true for ideal models. This seems to be a quite challenging thing to measure and compute. Have not really looked into this too much but if there are any problems with linearity, or lack thereof, in the sensors it becomes a much more involved bug to solve. Not listing other possible problems.

The assist multipliers are just values multiplied with some value we calculate from the torque sensor and measured RPM. It might not be representative of real human power, yet, but works well enough. In my latest contribution of code I divided the calculated human power value by two (2) and that gives a somewhat better representation of real values. This is NOT intended in any way to solve the problem, instead it is just a quick patch so a more realistic value of human power is displayed without the user having to change the assist multiplier values.

It is great seeing posts from users leaving feedback and thoughts to the problem!

I looked at the power issue quite a bit as I have mentioned before.

The power calculation on the controller side is spot on and has not changed for 0.17.x for the controller. In fact nothing has changed for the controller for 0.17.x so multipliers will work the same. The power calculation at the controller is done at 10Hz and uses the torque sensor value at that point in time along with the rpm. This is exactly what you want on the controller side. Due to many issues (hw lowpass as mentioned by casainho, possible nonlinearities in torque sensor readings), this might not be perfect but is consistant and does measure power.

This power is sent to the display at 10Hz as well and the display applies a simple lowpass filter to it. I have played with various ways of averaging and it seems like the only way to get realistic power measurements for all cadence values is to do an average of all the power values for one complete revolution. Believe it or not, a simple divide by 2 is actually pretty close. Casaninhos suggestion of taking the min/max and dividing by 2 would also work.

That being said, once I figured this all out Im ok with it as is and why I have not talked about it more. Perhaps a simple explanation in the FAQ would be good enough?

As Rafe has mentioned, the power calculation favors more power at higher rpms because rpm is part of the power calculation (no way around that). Perhaps a multiplier could be applied based on RPM to boost lower RPMs but then it wouldnt be true power anymore. This might also overlap what 'boost' is trying to accomplish although boost is time based and using a multiplier would be all the time. I have no idea what using this multiplier would feel like in the real world. I definately notice this power based calcuation used for assist while riding and I just work with it as is as I use a high cadence 90% of the time. My brose equipped bike definately has more torque based based assist down low but Im not running boost at the moment on my TSDZ2.
 
We are looking for pedal human power in watts, and that is torque x rpm, analog to electric power in watts as amps x volts (if we want the motor with more torque we provide amps and we need to provide volts to increase motor speed rpm).

Analog torque sensor signal, like a sine wave (every lower peak represents torque on left cranck, for that specific torque sensor):
index.php


If we consider that is near a sinewave, to get average value, we can find max value and: multiplying the peak or maximum value by the constant 0.637 ONLY applies to sinusoidal waveforms. 0.637 is near the /2 value you guys feel as correct value.
 
Hi casainho,
regarding the wiki on the wiring:
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Flash-the-firmware-on-TSDZ2
I tried the "super dodgy way" to wire as mentioned few post above, and tonight I tried 3 wires only 5V, GND, SWIM without the RST as suggested in the guide.
I used the ST via command line exe (marcoq interface) under windows 10 64bit and it looked OK while flashing (no errors), unfortunately i realized during the test that something was wrong (no assistance on 2nd to 4th assist level, no walk assist), whereas the other day was working. After a while I tried to reconnect the fourth wire RST and flash again.. it worked.

Bottom line is that from my test all 4 wires need to be connected for a proper flash.
Since no clear errors arise when flashing with 3 wires, but the result is not correct, maybe the wiki should be updated... up to you.
Thanks
Ciao
 
casainho said:
We are looking for pedal human power in watts, and that is torque x rpm, analog to electric power in watts as amps x volts (if we want the motor with more torque we provide amps and we need to provide volts to increase motor speed rpm).

Analog torque sensor signal, like a sine wave (every lower peak represents torque on left cranck, for that specific torque sensor):
index.php


If we consider that is near a sinewave, to get average value, we can find max value and: multiplying the peak or maximum value by the constant 0.637 ONLY applies to sinusoidal waveforms. 0.637 is near the /2 value you guys feel as correct value.

Another simple thing to do is simply take the human power off the display :)

Im actually being serious. Perhaps focus more on users looking at motor power to figure out assist levels as thats what we really care about in the end.
 
elem said:
pay attention, i m using VLCD5 instead of VLCD6, also 11S battery ( 39.6V nominal, 46.2V max )

11s 16A 550W.jpg

0x004000 : AA 03 00 10 1B 3F 01 23 08 2D 01 00 19 0A 0B C4
0x004010 : 00 3B 01 03 06 0C 18 00 00 04 0C 14 1C 14 23 01
0x004020 : 22 00 4B 55 0A 0C 12 1A 20 28 14 00 00 00 00 00


0x004001 : 03 ( default value assist level factor x10 )
0x004003 : 16 amp = 10 ( default value battery max current )
0x004004 : 270W = 27 = 1B ( default value motor max power x10 )
0x004005 : 31.9 V = 319-256 = 63 = 3F ( default value battery low voltage cut off x10 00 )
0x004006 : 256 = 01 ( default value battery low voltage cut off x10 01 )
0x00400E : 11= 0B ( battery nombre de cells )
0x004013 : 03 = 03 ( lvl 1 )
0x004014 : 06 = 06 ( lvl 2 ) 06 06
0x004015 : 12 = 0C ( lvl 3 ) 0C 12
0x004016 : 24 = 18 ( lvl 4 ) 18 24
0x004020 : 550w/25 = 22 ( max batt power div 25 )

Thanks elem! , yes getting there up to 10.5A now under full assist and feels very close to stock. Some more tinkering but im starting to understand it a bit better now.

Current settings on 36V battery

0x004000 : AA 03 00 10 1B 2C 01 23 08 2D 01 00 19 0A 0A C4
0x004010 : 00 3B 01 03 06 0C 18 00 00 04 0C 14 1C 14 23 01
0x004020 : 22 01 4B 55 0A 0C 12 1A 20 28 14 00 00 00 00 00


0x004001 : 03 ( default value assist level factor x10 )
0x004003 : 16 amp = 10 ( default value battery max current )
0x004004 : 270W = 27 = 1B ( default value motor max power x10 )
0x004005 : 30.0 = 300-256 = 44 = 2C ( default value battery low voltage cut off x10 00 )
0x004006 : 256 = 01 ( default value battery low voltage cut off x10 01 )
0x00400E : 10 = 0A ( battery number of cells )
0x004013 : 03 = 03 ( lvl 1 )
0x004014 : 06 = 06 ( lvl 2 ) 06 06
0x004015 : 12 = 0C ( lvl 3 ) 0C 12
0x004016 : 24 = 18 ( lvl 4 ) 18 24
0x004020 : 550w/25 = 22 ( max batt power div 25 )

I can only see peak power and amps on my meter in current position by the motor, so cannot record lower assist figures unfortunately at the moment

3 > 10.53Ap 410Wp ( at final 38.00V )
 
Hi everyone,

i downloaded the package from marcoq with the java tool to try on a second ebike with VLCD5 and 48V motor and battery.

Just some questions :

- Why are there 2 Battery Current settings: Current and current Limit ? What is the difference ?
- I'm also a little confused by the motor max power option, i understand the difference between power draw on the battery and power delivered by the motor but what do i need to enter here for the 48V motor ?

Does these settings seems correct to you :

Max Battery Current Limit : 12
Max Battery Power : 576
Max battery Current 12
Number of Cells : 13
LVC : 39
Battery Voltage for FOC : 48.0

Motor :
48V
Max Motor Power : ?? for the 48V version
Motor Phase Max Current : ?? for the 48V version

Do i need to change something else for the 48V version ?

- Regarding compiling after settings are changed, after i click compile, the program is changing the files in the src/controller folder, and creates a main.ihx file, do i just need to load this file in ST Visual programmer like an .hex file, flash program tab, and done ? The data tab will be changed by the firmware the first time the motor turn on ?

sorry for these questions, and thank you for the wonderful work
 
New stable flexible OpenSource firmware v0.17.0, get it here: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.17.0

Thanks to all the developers, testers and other contributors!!

Changes from v0.16.x:
KT-LCD3:
- settable odometer
- trip distance function
- TM and TTM time measurement
- imperial units throughout the system
- saved menu state for all menus when power down
- implemented automatic fast increase/decrease of variables on configuration menus
- flashing time on menu number and variables is now short -- it is easier to see the values
 
nbdriver said:
Hi everyone,

i downloaded the package from marcoq with the java tool to try on a second ebike with VLCD5 and 48V motor and battery.

Just some questions :

- Why are there 2 Battery Current settings: Current and current Limit ? What is the difference ?
- I'm also a little confused by the motor max power option, i understand the difference between power draw on the battery and power delivered by the motor but what do i need to enter here for the 48V motor ?

Does these settings seems correct to you :

Max Battery Current Limit : 12
Max Battery Power : 576
Max battery Current 12
Number of Cells : 13
LVC : 39
Battery Voltage for FOC : 48.0

Motor :
48V
Max Motor Power : ?? for the 48V version
Motor Phase Max Current : ?? for the 48V version

Do i need to change something else for the 48V version ?

- Regarding compiling after settings are changed, after i click compile, the program is changing the files in the src/controller folder, and creates a main.ihx file, do i just need to load this file in ST Visual programmer like an .hex file, flash program tab, and done ? The data tab will be changed by the firmware the first time the motor turn on ?

sorry for these questions, and thank you for the wonderful work

- Max Battery Current Limit: battery safe limit.
- Max battery Current: current that motor draw from battery
- Max Motor Power: at the moment is not used.... maybe in the future
- Motor Phase Max Current: keep default parameter

Using the Java Configurator, you must click on "Compile" and after click on "Program" without use STVP program... but before you need connect the STLINK-V2 programmer to the USB port.
 
I'm interested in marcoq's firmware for VLCD6. I've installed both JRE and SDCC compiler, but am unable to flash the firmware within the configurator (I am in an OSX environment). I can install his firmware with stm8flash, however the stock eeprom settings are for the 36v, and I have a 48v 500watt motor that I'd like to make full use of. Would anyone know what else to check, or alternatively be able to supply a eeprom .hex with settings suitable for a 48v motor?
 
mossboss said:
I'm interested in marcoq's firmware for VLCD6. I've installed both JRE and SDCC compiler, but am unable to flash the firmware within the configurator (I am in an OSX environment). I can install his firmware with stm8flash, however the stock eeprom settings are for the 36v, and I have a 48v 500watt motor that I'd like to make full use of. Would anyone know what else to check, or alternatively be able to supply a eeprom .hex with settings suitable for a 48v motor?

"..... but am unable to flash the firmware within the configurator......"
Edit src/controller/configurator_program.bat and verify if STVP installation path is correct.... default is:
PATH = %PATH%;C:\STMicroelectronics\st_toolset\stvp
 
marcoq, can you please create a new thread for user support to your branch? Since it is harder to configure, the number of messages will be big (I saw this happening on KT motor controller firmware, where the process is similar and is a more extensive process to user).

I think we are all interested on development, but having lengthy user support together is not good. Even because I can't have daily digest messages on this forum like on others.


marcoq said:
mossboss said:
I'm interested in marcoq's firmware for VLCD6. I've installed both JRE and SDCC compiler, but am unable to flash the firmware within the configurator (I am in an OSX environment). I can install his firmware with stm8flash, however the stock eeprom settings are for the 36v, and I have a 48v 500watt motor that I'd like to make full use of. Would anyone know what else to check, or alternatively be able to supply a eeprom .hex with settings suitable for a 48v motor?

"..... but am unable to flash the firmware within the configurator......"
Edit src/controller/configurator_program.bat and verify if STVP installation path is correct.... default is:
PATH = %PATH%;C:\STMicroelectronics\st_toolset\stvp
 
casainho said:
marcoq, can you please create a new thread for user support to your branch? Since it is harder to configure, the number of messages will be big (I saw this happening on KT motor controller firmware, where the process is similar and is a more extensive process to user).

I think we are all interested on development, but having lengthy user support together is not good. Even because I can't have daily digest messages on this forum like on others.


marcoq said:
mossboss said:
I'm interested in marcoq's firmware for VLCD6. I've installed both JRE and SDCC compiler, but am unable to flash the firmware within the configurator (I am in an OSX environment). I can install his firmware with stm8flash, however the stock eeprom settings are for the 36v, and I have a 48v 500watt motor that I'd like to make full use of. Would anyone know what else to check, or alternatively be able to supply a eeprom .hex with settings suitable for a 48v motor?

"..... but am unable to flash the firmware within the configurator......"
Edit src/controller/configurator_program.bat and verify if STVP installation path is correct.... default is:
PATH = %PATH%;C:\STMicroelectronics\st_toolset\stvp

No problem casainho... I will create a new thread for OEM displays users. :thumb:
 
Hi, Im having a problem flashing the LCD3. Everything was fine following along with jbalat's video. Was able to erase old firmware, download 0.17 firmware but when i try to "program all tabs" it I get:
Error : Verify failed at address 0x4000
Error : < DATA MEMORY verifying failed.
Error : < Operation aborted.
any help would be appreciated . thank you
 
GTrider said:
Hi, Im having a problem flashing the LCD3. Everything was fine following along with jbalat's video. Was able to erase old firmware, download 0.17 firmware but when i try to "program all tabs" it I get:
Error : Verify failed at address 0x4000
Error : < DATA MEMORY verifying failed.
Error : < Operation aborted.
any help would be appreciated . thank you
Did you erase unlock first?
 
Hello good morning, the file LCD3 firmware 0.17 gives error, thank you very much for your work Casainho a greeting.
 
casainho said:
New stable flexible OpenSource firmware v0.17.0, get it here: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.17.0

Thanks, casainho, and all who contributed!

Will give 0.17 a try ASAP in my LCD3.

Do I have to update my motor controller firmware to 0.17? Or are there no changes from 0.16?

Thanks!

Neil
 
Back
Top