Improving original firmware - TongSheng TSDZ2 mid drive motor

I think $1c is the smoothed throttle value, with the smoothing happening between $b82c and $b875.

$a6 could be something like a maximum current factor.
So when the throttle is above a certain level, it would make sense to set the current limit factor to the maximum.

Maybe the correlation between torque, assist level and the resulting power is somehow calculated (or prepared) at $9b2c.
Depended on the assist level, $dd and $ec are filled with different values.
And there is also the difference between the 36V and 48V firmware: 0x9bb3


casainho said:
Tested and it works -- please see my message on TSDZ2 main thread.
Click to expand...
Cool :)
 
I got FOC working so I don't have any big motivation to keep looking at original firmware. The only part that I miss now is protecting the motor controller against high currents. Can you please give a look to ADC current reading value and try to understand how the current is limited, I mean, what is the max value that is being compared and/or the mosfets are disabled? -- I can try to use my own guess values but using original ones may save some burned controllers ;)

This is how I implemented for KT motor controllers and works very well:

Code: 
  /****************************************************************************/
  // PWM duty_cycle controller:
  // - limit battery undervoltage
  // - limit battery max current
  // - limit motor max ERPS
  // - ramp up/down PWM duty_cycle value

  if ((UI8_ADC_BATTERY_CURRENT > ui8_adc_target_battery_current_max) || // battery max current, reduce duty_cycle
      (ui16_motor_speed_erps > MOTOR_OVER_SPEED_ERPS) || // motor speed over max ERPS, reduce duty_cycle
      (UI8_ADC_BATTERY_VOLTAGE < ((uint8_t) ADC_BATTERY_VOLTAGE_MIN))) // battery voltage under min voltage, reduce duty_cycle
  {
    if (ui8_duty_cycle > 0)
    {
      ui8_duty_cycle--;
    }
  }
  else // nothing to limit, so, adjust duty_cycle to duty_cycle_target, including ramping
  {
    if (ui8_duty_cycle_target > ui8_duty_cycle)
    {
      if (ui16_counter_duty_cycle_ramp_up++ >= ui16_duty_cycle_ramp_up_inverse_step)
      {
        ui16_counter_duty_cycle_ramp_up = 0;
        ui8_duty_cycle++;
      }
    }
    else if (ui8_duty_cycle_target < ui8_duty_cycle)
    {
      if (ui16_counter_duty_cycle_ramp_down++ >= ui16_duty_cycle_ramp_down_inverse_step)
      {
        ui16_counter_duty_cycle_ramp_down = 0;
        ui8_duty_cycle--;
      }
    }
  }
  /****************************************************************************/

And my tests of first time FOC implementation:

casainho said:
I put the TSDZ2 motor on an testing ebike and then on a training roller that makes a constant mechanical load on the wheel. I put the load to max possible value and went to measure the efficiency of our flexible OpenSource firmware VS the original firmware:

Code: 
Our flexible OpenSource firmware || original firmware
wheel speed  | battery amps    || wheel speed   | battery amps
8 km/h       | 1 amp           || 8.4 km/h      | 1 amp
13.3 km/h    | 2 amp           || 13.3 km/h     | 2 amp
17.2 km/h    | 3 amp           || 16.9 km/h     | 3 amp
20.5 km/h    | 4 amp           || 20.2 km/h     | 4 amp

NOTE: my lab power supply current limit is near the 4 amps. Later I should get a battery and test to at least 15 amps.

As we can see, the efficiency is the same. Also the running noise is the same for both firmwares, almost none.

The firmware source files are on github.

Here the graph of real time data, showing a session similar to that tests I did. You can see phase voltage, phase current, motor speed in ERPs and FOC calculated angle:
Original size



Video:
[youtube]N0D_q2zbrh4[/youtube]
Click to expand...
 
I am sooo glad for chosing the TSDZ2. I'm a big fan of open Software, so keep up the good work!!
Where can i get a spare connector for flashing the MCU? The "Lights output"-cable which came
with my set ist not fully wired.

Any chance to get some custom firmware for the XH18-LCD? I need to open it up and take some pictures..

greets from Munich!
Karl
 
shaddi said:
I am sooo glad for chosing the TSDZ2. I'm a big fan of open Software, so keep up to good work!!
Where can i get a spare connector for flashing the MCU? The "Lights output"-cable which came
with my set ist not fully wired.

Any chance to get some custom firmware for the XH18-LCD? I need to open it up and take some pictures..

greets from Munich!
Karl
Click to expand...
Thank for the feedback!!

See how to flash here: https://opensourceebikefirmware.bitbucket.io/kunteng_lcd3/

I hope to focus my energy on KT-LCD3 only. Maybe someone can start that project.
 
casainho said:
Can you please give a look to ADC current reading value and try to understand how the current is limited, I mean, what is the max value that is being compared and/or the mosfets are disabled?
Click to expand...
I can try to, but I have not much time at the moment.
I also want to understand where and how the current limit is set... if it is really in the eeprom etc.

shaddi said:
I am sooo glad for chosing the TSDZ2. I'm a big fan of open Software, so keep up the good work!!
Where can i get a spare connector for flashing the MCU? The "Lights output"-cable which came
with my set ist not fully wired.

Any chance to get some custom firmware for the XH18-LCD? I need to open it up and take some pictures..

greets from Munich!
Karl
Click to expand...
I did buy an extension cable here:
https://www.elektrofahrrad-einfach.de/products/Einzelkomponenten/Zubehoer/SFM-Zubehoer/SFM-Displayverlaengerung-40cm-fuer-DU250.html

And for the XH18-LCD, I opened it a while ago.
Unfortunately, the PCB is covered in resin or so. So, not easy...


At the moment, I have the idea to use a raspberry pi zero and a small/cheap lcd.
First just to show the additional information, maybe later also as a replacement...
 
hurzhurz said:
casainho said:
Can you please give a look to ADC current reading value and try to understand how the current is limited, I mean, what is the max value that is being compared and/or the mosfets are disabled?
Click to expand...
I can try to, but I have not much time at the moment.
I also want to understand where and how the current limit is set... if it is really in the eeprom etc.
Click to expand...
Ok. I implemented this protections:
Code: 
  /****************************************************************************/
  // PWM duty_cycle controller:
  // - limit battery undervoltage
  // - limit battery max current
  // - limit motor max phase current
  // - limit motor max ERPS
  // - ramp up/down PWM duty_cycle value

  if ((ui8_adc_battery_current > ui8_adc_target_battery_current_max) || // battery max current, reduce duty_cycle
      (ui8_adc_motor_phase_current > ui8_adc_target_motor_phase_current_max) || // motor max phase current, reduce duty_cycle
      (UI8_ADC_BATTERY_VOLTAGE < ((uint8_t) ADC_BATTERY_VOLTAGE_MIN))) // battery voltage under min voltage, reduce duty_cycle
  {
    if (ui8_duty_cycle > 0)
    {
      ui8_duty_cycle--;
    }
  }
  else if ((ui16_motor_speed_erps > MOTOR_OVER_SPEED_ERPS) && // motor speed over max ERPS, reduce duty_cycle
      (ui8_motor_over_speed_erps_flag == 0))
  {
    ui8_motor_over_speed_erps_flag = 1;

    if (ui8_duty_cycle > 0)
    {
      ui8_duty_cycle--;
    }
  }
  else // nothing to limit, so, adjust duty_cycle to duty_cycle_target, including ramping
  {
    if (ui8_duty_cycle_target > ui8_duty_cycle)
    {
      if (ui16_counter_duty_cycle_ramp_up++ >= ui16_duty_cycle_ramp_up_inverse_step)
      {
        ui16_counter_duty_cycle_ramp_up = 0;

        // don't increase duty_cycle if motor_over_speed_erps
        if (ui8_motor_over_speed_erps_flag == 0)
        {
          ui8_duty_cycle++;
        }
      }
    }
    else if (ui8_duty_cycle_target < ui8_duty_cycle)
    {
      if (ui16_counter_duty_cycle_ramp_down++ >= ui16_duty_cycle_ramp_down_inverse_step)
      {
        ui16_counter_duty_cycle_ramp_down = 0;
        ui8_duty_cycle--;
      }
    }
  }
  /****************************************************************************/

hurzhurz said:
shaddi said:
I am sooo glad for chosing the TSDZ2. I'm a big fan of open Software, so keep up the good work!!
Where can i get a spare connector for flashing the MCU? The "Lights output"-cable which came
with my set ist not fully wired.

Any chance to get some custom firmware for the XH18-LCD? I need to open it up and take some pictures..

greets from Munich!
Karl
Click to expand...
I did buy an extension cable here:
https://www.elektrofahrrad-einfach.de/products/Einzelkomponenten/Zubehoer/SFM-Zubehoer/SFM-Displayverlaengerung-40cm-fuer-DU250.html

And for the XH18-LCD, I opened it a while ago.
Unfortunately, the PCB is covered in resin or so. So, not easy...


At the moment, I have the idea to use a raspberry pi zero and a small/cheap lcd.
First just to show the additional information, maybe later also as a replacement...
Click to expand...
Well, at least it uses the same STM8 and that means is programmable, unlike the V-LCD5.

I think there are 2 vital things that need to be done:
- fully remove the resin to get and analyse the schematic, as also get the reference for the ICs like the LCD controller IC
- get to know where is the STM8 programming headed and see if an user would be able to easy remove the resin and solder the programming header

Clearly, KT-LCD3/5 are much easier for development and for final user to program. I will continue my focus on KT-LCD3 and maybe in future try the be KT-LCD5.
 
casainho said:
I think there are 2 vital things that need to be done:
- fully remove the resin to get and analyse the schematic, as also get the reference for the ICs like the LCD controller IC
- get to know where is the STM8 programming headed and see if an user would be able to easy remove the resin and solder the programming header
Click to expand...
and thats why i ordered my second xh18 LCD. Just waiting for the shipment from china... Maybe next year? :lol:
If somebody (near germany) has a second LCD (can also be a broken one) for fiddling with it, please contact me :)

casainho said:
Clearly, KT-LCD3/5 are much easier for development and for final user to program. I will continue my focus on KT-LCD3 and maybe in future try the be KT-LCD5.
Click to expand...
Yes, its more easy, but i really like the color graphic LCD on the XH18. Soo many possibilities...
 
shaddi said:
Yes, its more easy, but i really like the color graphic LCD on the XH18. Soo many possibilities...
Click to expand...
Yes but also that many possibilities also mean much more work to do. I really hope more people can start to develop.
 
LCD-Controller on the XH18 is a ST7735 and its connected via 8-Bit interface (not so common). Its a 16 Bit TFT Display.
Jog-Dial is conncted via an Hall-Sensor to one GPIO-Pin of the STM.

ISP-Port is clearly visible and have the same pinout like the LCD3. Firmware is Read-Protected, so no backup :(
 
feketehegyi said:
Do you think it is possible to calculate pedal cadence with original firmware data from the motor controller?
Click to expand...
Our improved original firmware sends the pedal cadence.
 
I'm not willing to tear open and unpot my xh18 for this research.

On the other hand, if you want to know where all the traces go,
I am willing to XRay it. Machine made for PCB inspections, not
some medical thing. Maybe tomorrow, if I remember to bring.
 
The good news, I remembered to bring my XH18
to throw under bus, or the the ray, or whatever.
Actually X-Rays shoot upward to the scintillator
located at the top of the box. Underneath is not
even in the picture.

But right now, I have a pile of real work that has
to be done first. Spare minutes at the end might
not happen till another day.

If you frequent DIYAudio, you've probably already
seen my small collection of vacuum tubes in xray.
 
Nevermind till Monday I guess.

I was working late in my own lab when those guys shut the machine down
and went home for the weekend. Usually that department stays busy till
2AM. But being Friday, seems they bailed at a more sensible hour...

Uncertain of all proper steps to safely turn it back on (warmup with a lead
target is involved). I think it better to wait than have to explain why half
the building is glowing, and I've grown an extra toe....

---- Edit Monday night, actually Tuesday early AM ----

Ditched me again! Its a Nordson XD something or other.
Dunno how to work it. Not quite the simple old YesTech
that used to occupy the corner. Just set Volts and Amps
limit, give 20 min of lead target to warm up, then glide
around with an old logitech gamepad. Save screenshots
to USB or network was fairly straightforward.

Nope, this one has 3D and bunch of confusing options.
Merely opening the door is a menu driven challenge.
Not even apparent where you'd plug in a USB stick to
save the screenshot. Probably has to happen over the
network, no clue where that option is hidden either.
And the guy said he'd be here late, but again bailed...

--- Edit Tuesday Night, not waiting for Wed AM ---

I stopped by the XRay station again a little earlier this
time, but others were still trying to get real work done.
Girl at the machine showed me she scanned her board
(checking for solder bridges to ground pad under QFN)
but offered to me no clue how to save the screenshot.
The floppy disk icon perhaps? Would be too easy.

Anyways, she said check back later. Prolly just ditch
me again and shut it all down, I'm beginning to see a
pattern...

Got my Sunlite deluxe double springer fork today,
and a wireless turn signal, and a Cree headlight.
Amazon this time, so it all came without hassle.
Two to five days, and nothing broke or missing.

Still no Stumey hubs from Outside Outfitters though.
More than a month gone by with no return of email
or phone call, they too seem to have ditched me.
Wasted a little over $200 bucks on things I'll have
to order again somewhere else...

Seven of eight things I ordered from AliExpress got
here. Last taking seven months, one fell off the
Shenzhen donkey cart, perhaps eaten by a Grue.
Maybe China Post will find it tomorrow? Not likely.
Another $130 lost, but my wasted time worth far
more. Lesson: Demand HKDHL shipping.

Eyebicycle sent my Tongsheng in 2 days for free.
That went very smooth. Why certain others can't
reliably ship things they claim to have in stock?

Enough rant, I wonder if that XRay station might
be unoccupied now??? Wed AM - You guessed it:
Ditched again. No 5min warning, no goodbyes...
 
Sadly, despite amazing xray photography of oddly shaped
vacuum tubes that were possible with the old machine,
this one hates anything that doesn't lay flat like a board.
Propped it up with foam level as I could in limited time.

The operator most familiar with it had no interested in
tweaking for a better picture of something that wasn't
work, and only wanted to shut it all down and go home.

This is what we get for free. Probably not too useful.
 
I have just opened my XH18-LCD to see if I can repair it:
I guess there is a defect transistor or mosfet that broke at the same time the other one at the motor controller broke.
Effect is the same like shown in this video: https://www.youtube.com/watch?v=P6CuWJCOV9k

Anyway, I have scrubbed off most of the potting compound and found the programming interface:
https://github.com/hurzhurz/xh18lcd/blob/master/images/swim.jpg
It was no problem to read it out:
https://github.com/hurzhurz/xh18lcd/tree/master/firmware

Edit/Update:
Faulty transistor identified: https://postimg.cc/image/c8zbaq6w1/
It is a BSR33 "PNP medium power transistor" in SOT89 package.
 
I have now started a collection for information that are needed to develop custom firmware for the XH18LCD:
https://github.com/hurzhurz/xh18lcd

And I have also created a example firmware that supports most features of the original firmware.
https://github.com/hurzhurz/xh18lcd/tree/master/development
custom-firmware.jpg

Though, it is made with an Arduino port for STM8. Probably not very efficient and not the best code style.
Probably better to make a one version from scratch than to enhance this one.
 
hurzhurz said:
I have now started a collection for information that are needed to develop custom firmware for the XH18LCD:
https://github.com/hurzhurz/xh18lcd

And I have also created a example firmware that supports most features of the original firmware.
https://github.com/hurzhurz/xh18lcd/tree/master/development
custom-firmware.jpg

Though, it is made with an Arduino port for STM8. Probably not very efficient and not the best code style.
Probably better to make a one version from scratch than to enhance this one.
Click to expand...
Congratulations!! I am very happy to see this development and I hope you can consider supporting the flexible OpenSource firmware that has strong advantages over original firmware.
 
casainho said:
Congratulations!! I am very happy to see this development and I hope you can consider supporting the flexible OpenSource firmware that has strong advantages over original firmware.
Click to expand...

Sure, the main motivation to look into this was to later have the possibility to support it.
Besides not riding my bike very often, the main reason I don't use the flexible OpenSource firmware yet is because I don't want to buy and mount the KT-LCD3 while I like the form factor of the XH18LCD.

I think the next I will try to do is to check if and how I can get the (already adapted to STM8 / C) UTFT library running without Arduino/Sduino.

What are your thoughts about using your KT-LCD3 firmware as a base for a new XH18LCD firmware?
Is it feasible to "replace" the display part?
To be honest, I havn't looked into it much yet.
 
hurzhurz said:
casainho said:
Congratulations!! I am very happy to see this development and I hope you can consider supporting the flexible OpenSource firmware that has strong advantages over original firmware.
Click to expand...

Sure, the main motivation to look into this was to later have the possibility to support it.
Besides not riding my bike very often, the main reason I don't use the flexible OpenSource firmware yet is because I don't want to buy and mount the KT-LCD3 while I like the form factor of the XH18LCD.

I think the next I will try to do is to check if and how I can get the (already adapted to STM8 / C) UTFT library running without Arduino/Sduino.

What are your thoughts about using your KT-LCD3 firmware as a base for a new XH18LCD firmware?
Is it feasible to "replace" the display part?
To be honest, I havn't looked into it much yet.
Click to expand...
You did a good choice as the TSDZ2 firmware is always changing as the LCD3 because we are developing it (but is more and more near a finish version).

The display part can be 80% of the project so I think you just need to support the communication. Also see that the motor firmware has a lot more options than original firmware and that ones are configured on LCD, so the LCD project is much bigger than original firmware.

LCD3 project uses about 22kbytea of flash memory from the 32kbytes available. What about your project? I am curious...
 
casainho said:
LCD3 project uses about 22kbytea of flash memory from the 32kbytes available. What about your project? I am curious...
Click to expand...
Well... crap. With fonts that are needed for a TFT, that will be tight ;)
My firmware barely fits in the 32k flash, I already had problems after I added the odometer as last.
Though, I don't know how much overhead comes from Arduino/Sduino. Strange thing is, it shows a smaller size after compiling than it does flash.
 
hurzhurz said:
casainho said:
LCD3 project uses about 22kbytea of flash memory from the 32kbytes available. What about your project? I am curious...
Click to expand...
Well... crap. With fonts that are needed for a TFT, that will be tight ;)
My firmware barely fits in the 32k flash, I already had problems after I added the odometer as last.
Though, I don't know how much overhead comes from Arduino/Sduino. Strange thing is, it shows a smaller size after compiling than it does flash.
Click to expand...
I was afraid of that, because I think that type of LCD gives a big freedom but must also need more program memory. What do you think was the strategy of original firmware?? Few features to fit on the 32kbytes??

KT also has some new color LCDs. Also one like LCD3 but with Bluetooth module included.

I think would be great to find a color LCD, that has at least 64kbytes flash, maybe STM32 and easy to source onmany online shops.
 
casainho said:
I was afraid of that, because I think that type of LCD gives a big freedom but must also need more program memory. What do you think was the strategy of original firmware?? Few features to fit on the 32kbytes??

KT also has some new color LCDs. Also one like LCD3 but with Bluetooth module included.

I think would be great to find a color LCD, that has at least 64kbytes flash, maybe STM32 and easy to source onmany online shops.
Click to expand...

Well, I'm not sure if they thought about that beforehand.
I think they designed the final PCB first and than cared about the software.

Look at how the LCD data pins are connected:
https://github.com/hurzhurz/xh18lcd/blo ... ardware.md
They spread the 8 lines across two different ports and even reversed them. So you can't simply and efficient put out a byte on the port.
That's how I have implemented it:
https://github.com/hurzhurz/UTFT-STM8S/ ... _XH18LCD.h (function UTFT__set_bits)
It is a nice looking PCB design, but not very practical...
And I also wonder why they haven't chosen the SPI version of the display/controller...

I also thought about using something completely different as LCD.
Maybe a Raspberry Zero with a cheap LCD or just a bluetooth transmitter and a phone.

Or to fit a different LCD in the same case... a transflective LCD would be nice. Together with an ESP32 or so.
 
hurzhurz said:
casainho said:
I was afraid of that, because I think that type of LCD gives a big freedom but must also need more program memory. What do you think was the strategy of original firmware?? Few features to fit on the 32kbytes??

KT also has some new color LCDs. Also one like LCD3 but with Bluetooth module included.

I think would be great to find a color LCD, that has at least 64kbytes flash, maybe STM32 and easy to source onmany online shops.
Click to expand...

Well, I'm not sure if they thought about that beforehand.
I think they designed the final PCB first and than cared about the software.

Look at how the LCD data pins are connected:
https://github.com/hurzhurz/xh18lcd/blo ... ardware.md
They spread the 8 lines across two different ports and even reversed them. So you can't simply and efficient put out a byte on the port.
That's how I have implemented it:
https://github.com/hurzhurz/UTFT-STM8S/ ... _XH18LCD.h (function UTFT__set_bits)
It is a nice looking PCB design, but not very practical...
And I also wonder why they haven't chosen the SPI version of the display/controller...

I also thought about using something completely different as LCD.
Maybe a Raspberry Zero with a cheap LCD or just a bluetooth transmitter and a phone.

Or to fit a different LCD in the same case... a transflective LCD would be nice. Together with an ESP32 or so.
Click to expand...
So this LCD seems a dead end, right? Or you still hope to optimize code size and use it?
 
You must log in or register to reply here.
Back
Top