Optimized TSDZ2 Firmware

Hi @casainho,
i've found that the OEM firmware uses a "Dead Time" value of 0x31 (about 3,1us) but you used a value of 1us.
Did you take a test to choose this value ?
In my latest version just released I increased the value to 1.5us. For now I have only taken a test ride and it is too early to draw conclusions but my impression is that consumption has decreased.
 
mspider65 said:
Hi @casainho,
i've found that the OEM firmware uses a "Dead Time" value of 0x31 (about 3,1us) but you used a value of 1us.
Did you take a test to choose this value ?
In my latest version just released I increased the value to 1.5us. For now I have only taken a test ride and it is too early to draw conclusions but my impression is that consumption has decreased.

You should be able to feel a change in temperature if the change made a difference, even at standstill.

1us is perhaps rather short for the design. They seem to use a small 3phase gate driver (fan7888? Looks like the right pinout) Which doesn't have strong drive capability.

In my investigations I've found anything below about 400ns Dead time results in heating on my boards, which I guarantee switch a LOT faster than this. Diagnosing this definitively is a simple oscilloscope job, but pragmatically can be done by just checking to see what Dead time results in less temperature rise.
 
mspider65 said:
Hi @casainho,
i've found that the OEM firmware uses a "Dead Time" value of 0x31 (about 3,1us) but you used a value of 1us.
Did you take a test to choose this value ?
In my latest version just released I increased the value to 1.5us. For now I have only taken a test ride and it is too early to draw conclusions but my impression is that consumption has decreased.
I did measure the dead time of original firmware, using the oscilloscope and if I remember correctly, it was like 0.9 us and then I decided to use the 1us. How did you measure the 3.1us?

And is that possible the dead time is instead forced by the mosfet driver IC?
 
casainho said:
I did measure the dead time of original firmware, using the oscilloscope and if I remember correctly, it was like 0.9 us and then I decided to use the 1us. How did you measure the 3.1us?

And is that possible the dead time is instead forced by the mosfet driver IC?

I've found in the OEM hex binary the instruction where the PWM1 DTR register is updated.
Was simple because the DTR address is only in one place of the hex file
 
mspider65 said:
casainho said:
I did measure the dead time of original firmware, using the oscilloscope and if I remember correctly, it was like 0.9 us and then I decided to use the 1us. How did you measure the 3.1us?

And is that possible the dead time is instead forced by the mosfet driver IC?

I've found in the OEM hex binary the instruction where the PWM1 DTR register is updated.
Was simple because the DTR address is only in one place of the hex file
Good!
 
mxlemming said:
You should be able to feel a change in temperature if the change made a difference, even at standstill.

1us is perhaps rather short for the design. They seem to use a small 3phase gate driver (fan7888? Looks like the right pinout) Which doesn't have strong drive capability.

In my investigations I've found anything below about 400ns Dead time results in heating on my boards, which I guarantee switch a LOT faster than this. Diagnosing this definitively is a simple oscilloscope job, but pragmatically can be done by just checking to see what Dead time results in less temperature rise.

You are right, normally, starting from a from a fixed steady state, you could gradually decrease the dead time until you measure a temperature or a current consumption rise.
Unfortunately i don't have a spare controller and motor to do any test.
As soon i have spare time, without disassembling anything, maybe i could connect my multimeter to my bike and then, after applying a fixed duty cycle, measure the current for different values of the dead time.
 
Just don't go too low, the current rise is entirely losses in the FETs due to shoot through and is dumped resistively in the semiconductor junction... The power dissipated in them will be battery voltage x the current, and can quickly get very toasty. It ramps up suddenly as you approach the area where the miller plateau of the FET is being charged, a matter of a few hundred ns
 
mxlemming said:
Just don't go too low, the current rise is entirely losses in the FETs due to shoot through and is dumped resistively in the semiconductor junction... The power dissipated in them will be battery voltage x the current, and can quickly get very toasty. It ramps up suddenly as you approach the area where the miller plateau of the FET is being charged, a matter of a few hundred ns

Yes, my idea is to start with 1us and then increase the value step by step to verify if the current decrease. Maybe i would just try to decrease 1 step to verify if 1us is just at the borderline. I don't want to burn my controller :)
 
mspider65 said:
beemac said:
Hi @mspider65 - the timer triggers in main that call motor and ebike every 4/50mS i think have an issue. I found the problem since because of the timer arrangement changes I copied your method across - but when I put my serial trace on I saw packets were being sent before the last packet was finished causing serial errors which weren't there before - so had a bit of a dig to see what was causing and noticed that your timer loops may fire early when the counters get close to wrapping causing a little jitter in how regularly the calls are made - and causing (in the osf firmware anyway) serial errors as packets don't get a chance to send before the next one starts every now and again... so causing a bad crc every few seconds or so...

it's these constructs that are problematic i think. Say if the test fires at tim4 counter = 254. Next firing the counter will be 3 but the two cycles before that when the test is say 0,1, or 2 minus 254 will be greater than 4 - so it fires a bit early.

Code:
    ui16_1mS_counter = ui8_tim4_counter;
    if((ui16_1mS_counter - ui16_motor_controller_counter) > 4) // every 4ms

I'm testing a change - to just detect change in the 1ms timer counter (this is ok as long as the loop runs faster than 1mS - and it does) - to give a 1mS pulse - and use that to increment separate trigger timers for the 4mS and 50mS calls... That seems to work and gets rid of the serial errors I was seeing.

I'm still testing - but this is the idea:

Code:
    ui8_1mS_counter = ui8_tim4_counter;
    if (ui8_1mS_counter != ui8_last_1mS_counter) // 1mS pulse
    {
      ui8_last_1mS_counter = ui8_1mS_counter;
      
      if (++ui8_motor_controller_counter == 4) ui8_motor_controller_counter = 0; // every 4mS
      if (++ui8_ebike_app_controller_counter == 50) ui8_ebike_app_controller_counter = 0; //every 50mS

      ui8_motor_controller_trigger = ((ui8_motor_controller_counter | ui8_motor_controller_trigger) == 0);
      ui8_ebike_app_controller_trigger = ((ui8_ebike_app_controller_counter | ui8_ebike_app_controller_trigger) == 0);
    }
   
    if(ui8_motor_controller_trigger) // every 4ms
    {
      ui8_motor_controller_trigger = 0;
       motor_controller();
      continue;
    }

    if(ui8_ebike_app_controller_trigger) // every 50ms
    {
      ui8_ebike_app_controller_trigger = 0;
      ebike_app_controller();
      continue;
    }
  }

Hi beemac,
the loop calculation are correct, only just change the > with >= to run every loop with the correct frequency.

Cheers - I realised my subtraction was off but forgot to correct my post - not had much time to code recently unfortunately!
 
Just started reading this thread. Newbie question, but what are ERPS when applied to motor speed? I did look on duckduckgo, but couldn't find anything relevant :confused: I bet I'm going to be embarrassed now :oops:
:wink:
Gordon
 
mspider65 said:
:eek:
gfmoore said:
Just started reading this thread. Newbie question, but what are ERPS when applied to motor speed? I did look on duckduckgo, but couldn't find anything relevant :confused: I bet I'm going to be embarrassed now :oops:
:wink:
Gordon

No problem :)
Electrical Revolutions Per Second. For TSDZ2 1 ERPS = 8xRPS. (Revolution Per Second).

Thank you very much.

One last newbie question, so I can go and do some study, exactly what type of motor is the TSDZ2? I'll shut up now.

edit: Does anyone know of a cheap hobbyist motor that works on the same principles?
😀
 
Back
Top