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

jbalat said:
Oh well my theory is down the tubes. I bumped the voltage up from 10s to 14s and cadence is still limited to 80 (which is really 104)
Bugger hopefully I can bump up the ERPS limit in the code ?
Click to expand...
Please see on LCD3 the motor speed ERPS and also the duty_cycle value and post them here.

Main.h file:

#define MOTOR_OVER_SPEED_ERPS 520 // motor max speed, protection max value | 30 points for the sinewave at max speed


About cadence,


void read_pas_cadence (void)
{
// cadence in RPM = 60 / (ui16_pas_timer2_ticks * PAS_NUMBER_MAGNETS * 0.000064)
if (ui16_pas_pwm_cycles_ticks >= ((uint16_t) PAS_ABSOLUTE_MIN_CADENCE_PWM_CYCLE_TICKS)) { ui8_pas_cadence_rpm = 0; }
else
{
ui8_pas_cadence_rpm = (uint8_t) (60 / (((float) ui16_pas_pwm_cycles_ticks) * ((float) PAS_NUMBER_MAGNETS) * 0.000064));

if (ui8_pas_cadence_rpm > ((uint8_t) PAS_MAX_CADENCE_RPM))
{
ui8_pas_cadence_rpm = ((uint8_t) PAS_MAX_CADENCE_RPM);
}
}
}

On motor.c, ui16_pas_pwm_cycles_ticks is incremented every PWM cycle of 64us and reset.
That variable keeps the ticks in 64us that takes counting each magnet timming.

You should change PAS_NUMBER_MAGNETS (main.h) but that number were givin by another user/developer of TSDZ2:

// PAS
#define PAS_NUMBER_MAGNETS 24
 
Thank you. I will try. Maybe you can check your cadence on your motor.

Can you look at the code for the start from rest.
It should not provide power if cadence is zero. Dont worry about wheel speed or timer. Ideally it should start after 2 magnet pulses. If this works you can change min adc from +4 back to +2 or even zero !
 
Hello! Long time lurker, first time poster. I have a bike(one of those mass produced Chinese 20" fat bikes) with KZQW22A controller, which seems to be heavily customized for the purpose.

Otherwise the controller looks like a regular stock model, but this one has an input to switch between 6->25km/h cruise mode, output for lights, speed sensor input from motor, cruise input from the usual 3-speed control panel and USB lead for charging phone or something.

I didn't like the assist level presets so first I tried to read the serial data between the controller and the input panel to see what's going on in there, but soon realized that even the serial data was crippled so the parameters couldn't be changed that way (there's also 25km/h speed limit probably somewhere in the firmware).
Fortunately as these controllers need to be quickly flashed for different customers there was already a programming connector soldered to the board so one thing lead to another and now I have the firmware disassembled :D

I'm currently trying to figure out if it's possible to use the flexible open source firmware for this particular controller. First thing I noticed was that all the inputs/outputs are different, but otherwise the board should have everything (still not sure where the motor phases should connect on the FAN7888 IC in the first place). I've been also trying to figure out the code, but following assembler code is my weak point :) It is looking very similar to the TSDZ2 though. Any pointers or ideas why this wouldn't work?

You have an awesome project by the way, I appreciate the enthusiasm.
 
eyebyesickle said:
Hi guys...

So, my knowledge is very hit or miss... sometimes just miss! :oops: but I was wondering if anyone here could help me with something... I love what you all have going on, big thanks to casianho and everyone involved, but for several reasons, I am not particularly fond of the KT-LCD3... and also personally, I only need a couple modifications that I think should be easy and fast to implement due to the nature of the desired changed on my end. I am happy with most of the motors functioning personally. (well, maybe not - but you all are already doing a rework, more simple is where the bar is set for myself haha)

I have been talking to the manufacturer of the mini OLED display (same type EGGRIDER v2 uses)
closeuponcatalog.png
and they have agreed to send me some units matched to the TSDZ2 if I can send them the TSDZ2 protocol.

I am not sure what to send them, and am trying to speed this up, as TS is not much help, and even if I get them to help, it won't be tomorrow... and I know we already have this info. So, if someone could show me what exactly I need to send (TSDZ2 Protocol), I would be forever grateful =).

I like the mini display because it is so low key, but also because it has bluetooth. This way, I can have the info I want on the little screen, then i can pull up the program on my phone (or even just the menu of the display, no phone) to switch voltage, and maybe another couple settings... All I really NEEED, is just to be able to switch/open voltage. I would like to see the human power output as well, and then have the bluetooth/app log all the ride data as well - but that is simple for my guy. A broke man like me though, needs to get the display in hand, programmed for the TSDZ2, prepped, so when I bring it to my guy there is less work and I can pay the minimal fee, instead of pointing him here, and giving him a 'blank slate' display to do all the work from scratch (well, not quite from scratch as the groundwork has been more than laid out).

Thanks for any help guys - and keep pushing on!!
Click to expand...

Have you made any headway with this display? I feel the same way as you, I already ordered the kt-lcd3 display but it is late to arrive and I may just resell it when it finally does arrive. I do not particularly care for the direction with which the new firmware has taken lately and I would prefer to just run the stock firmware. I am happy with the way the motor works, if anything I would have preferred less power at takeoff (not more power with less of safety threshold) and perhaps some more power at the higher rpms (75-max cadence). I think I will try to upgrade my 48v controller to 52v and see how high the actual permitted voltage will be for a 15s 56v battery. My 48v controller works with up to a 57v battery charge now (although sometimes I have to pedal it around for 3 minutes until it kicks on- lol) so perhaps a 52v firmware update will be ok up to about 61v. 61v (down from the 63v max of a 15s battery) would be fine and should extend the battery lifetime considerably. If not then perhaps there is another way to modify it to accept a slightly higher voltage battery, somewhere around 61-62v max would be perfect. :) Thanks for all the posts on flashing the motor firmware, I am checking them out now :)
 
Hi,

Yes, I am making headway. I have to admit - I was a little surprised if not butt hurt that I could not even get a response about this, when I was so quick to take apart a controller to provide information, and provide pinout information etc... but WHATEVER.

I am ALL for the new firmware, and do believe it will be loads better(just going through stages, as anything must to find the right ground to settle on), just not a fan of the KT-LCD3 - not even close, and see this as a poor choice to do work meant for the future... because this is a very limited display of the past which presents many problems for users. So I am taking preemptive steps to get something else in place... because I do not see such solutions as soldering a bluetooth into the body of the KT-LCD3 as a realistic/viable fix... I wanted to get another display in place with some simple additions, but ready to remotely upgrade to the more advanced firmware when available... but I see how it is around here!!! :shock: :cry: :lol: hahahaha I am serious, but not taking it too seriously.

Here, an official copy of the communication protocol - which may even demystify some elements for others working on the project as well...



also note temperature protection fault code...

OH, and GET IT WHILE ITS HOT - I will probably take it down soon... depending on a lil sumtin sumtin
 
jbalat said:
Ok I had a small runaway I accidentally pressed the pedals and bike started moving. I was able to arrest the bike with the brakes but it kept going even after I took my feet off. I had to peddle backwards to stop it moving.
Click to expand...
On this days I also found this kind of issue. And can always replicate it: press the pedals to get assistance but block the ebike wheel to the ground, you will see motor power constant until you brake or you let the motor run...
Looking at LCD3, on torque sensor ADC value, we can see the torque sensor value really keeps high while we block the wheel... so the code seems to be working as expected (also I see the ADC values changing a bit, seems they are correct), I just can't understand why torque sensor output behaves like that, I didn't expect and I need to better understand this. My 3 ebikes have brake sensors, that is why I never saw this issue.

jbalat said:
Sorry but this new feature does not work

I had to do 3 or more peddle turns before the motor would cut in.

You need to just stop the motor turning when the cadence is zero and torque is applied. I’m not sure what you did ?

#define MOTOR_ASSISTANCE_CAN_START_WITHOUT_PEDAL_ROTATION 0
Click to expand...
I didn't tested but the change I did was very small. I probably can't test on the next days/1 week.

The code is this one:

Code: 
  // human power: pedal torque * pedal cadence
  // do not apply human power with lower cadence
  if (ui8_pas_cadence_rpm > 25)
  {
    // calc human power
    ui8_pedal_human_power = ((((uint16_t) ui8_torque_sensor) * ui16_temp) >> 8);

    // now scale human power with assist level
    f_temp = ((float) ui8_pedal_human_power) * f_get_assist_level ();
    if (f_temp > 255)
      f_temp = 255;

    ui8_pedal_human_power = (uint8_t) f_temp;
  }
#if (MOTOR_ASSISTANCE_CAN_START_WITHOUT_PEDAL_ROTATION == 1)
  else
  {
    ui8_pedal_human_power = ui8_torque_sensor;
  }
#else
  else
  {
    ui8_pedal_human_power = 0;
  }
#endif

So, if PAS cadence is less than 25, or we get ui8_pedal_human_power = ui8_torque_sensor; or ui8_pedal_human_power = 0. ui8_pedal_human_power is the output of this section and is used on next sections to setup the motor current/torque.
When you #define MOTOR_ASSISTANCE_CAN_START_WITHOUT_PEDAL_ROTATION 0, the executed code should be what you want: ui8_pedal_human_power = 0; I don't know what can be failing.
 
eyebyesickle said:
Yes of course, I am doing it in the video - I have been doing it to all models (excluding coaster brake model! ha), including 6 pin models :D
Click to expand...

Thank you very much for posting all the info. I followed your instructions but I had issues, I think my $2 aliexpress st-link is garbage. It comes up with a read error most of the time, the only way I was able to get it to work was to flash with the battery installed on the motor. Even then I could not read or write everything at once and each one took 5-10 tries. I did check all my wire connections and they all tested perfect.

As others have mentioned editing the two columns does not work, however overwriting the program and data set did work and I was able to run my 52v battery with a full charge.

I do have some observations from my first ride. The bike seems faster now, places (after a downhill) where I would consistently run at 29mph today I was doing 31mph. The throttle seems ok at high rpms but feels like it is breaking up and losing power at low/mid rpms. I also have been noticing that I was getting a runaway effect from the torque sensor, I have not had that ever happen before now. It actually made me miss a turn because I stopped pedaling and the motor kept going, and I did not want to risk hosing the blue gear so I just went straight. That too has never happened. It is possible that it was not initialized properly so I will try again tonight when it cools down outside. Oh, the battery power displayed on the vlcd5 is actually working now. At 50.5 volts it was down to 2-3 bars, before when I hit 2 bars it was almost out of power.

We did go 4.5 miles and the battery still had 50.5v remaining so we are definitely getting more range from our puny 2ah battery! We will try it again this evening and see how it works. It is noce to leave the battery on the charger until it shuts off and not have to keep checking the voltage :)

I have the 15s battery but I do not have a way to charge it yet. Once the charger arrives I will try to test the high voltage amount for the 52v controller.

Thank you.
 
220 pwm duty cycle
520 erps which is max setting in code
Adjusted cadence 104rpm

This works out well..:)
At 602 erps gives 255 pwm duty and 120 adjusted cadence !!
 
jbalat said:
220 pwm duty cycle
520 erps which is max setting in code
Adjusted cadence 104rpm

This works out well..:)
At 602 erps gives 255 pwm duty and 120 adjusted cadence !!
Click to expand...
Good!

But be warned that after the 525 ERPS the motor starts to be clearly inefficient. I saw this with my tests on lab power supply but I don't have numbers. We can improve this by increasing the PWM frequency but this would be ober the value from original firmware.

And 255 for duty_cyle seems to much, I think we should limit to something like 245 or 250.

Also, how can we validate the number of PAS magnets? How can we validate that factor of 1.3 that you mention?
 
Can you just put the bike on a stand and in Debug mode get it to send something to the LCD every time it passes a magnet ?

To test the Cadence. On a stand start peddeling at 60 cadence then use your stop watch for 10 seconds and count how many times you do a full rotation. Then multiply by 6 easy

Do it a few times and at different cadence to confirm for yourself.
 
eyebyesickle said:
Yes, I am making headway. I have to admit - I was a little surprised if not butt hurt that I could not even get a response about this, when I was so quick to take apart a controller to provide information, and provide pinout information etc... but WHATEVER.
Click to expand...

Sorry dude, I don’t know anything about protocols. But I share your view of the ktlcd3 and I really like the other display you are proposing so good luck with that.
 
jbalat said:
Can you just put the bike on a stand and in Debug mode get it to send something to the LCD every time it passes a magnet ?
Click to expand...
Good idea and I counted 20 while we are using:
#define PAS_NUMBER_MAGNETS 24

I put my test code online, on branch pas_number_magnets_testing. You can see the number of magnets increasing of the "FOC angle" option. Can you please validate that I counted correctly 20? If so, I think cadence calculation will work as long as we define the correct number of magnets, maybe you can also validate the cadence value.
 
eyebyesickle said:
Hi,

Yes, I am making headway. I have to admit - I was a little surprised if not butt hurt that I could not even get a response about this, when I was so quick to take apart a controller to provide information, and provide pinout information etc... but WHATEVER.

I am ALL for the new firmware, and do believe it will be loads better(just going through stages, as anything must to find the right ground to settle on), just not a fan of the KT-LCD3 - not even close, and see this as a poor choice to do work meant for the future... because this is a very limited display of the past which presents many problems for users. So I am taking preemptive steps to get something else in place... because I do not see such solutions as soldering a bluetooth into the body of the KT-LCD3 as a realistic/viable fix... I wanted to get another display in place with some simple additions, but ready to remotely upgrade to the more advanced firmware when available... but I see how it is around here!!! :shock: :cry: :lol: hahahaha I am serious, but not taking it too seriously.

Here, an official copy of the communication protocol - which may even demystify some elements for others working on the project as well...

tongsheng protocol.pdf

also note temperature protection fault code...

OH, and GET IT WHILE ITS HOT - I will probably take it down soon... depending on a lil sumtin sumtin
Click to expand...

Well, with "tongsheng protocol.pdf" I could not create my android app. The description from hurzhurz is better imho.
Here it's: https://github.com/hurzhurz/tsdz2/blob/master/serial-communication.md#motor-control-flags
I've also made a bluetooth module, connected to display cable at motor.
 
Haha thanks guys, I got no problem with anyone I just talk too much. ;)

Jbalat, no worries, no one here owes anyone anything, hopefully we all work together, I was just busting everyone's balls like I do to my friends in person. You all probably noticed I'm trying to piggyback on others work! Haha.

feketehegyi , I agree completely! Thanks for that link just what I needed! Great job on the Bluetooth module, very impressive. If we have a plug and play Bluetooth module ready to go, that alone would provide easy upgrading to any firmware mods etc, much more accessible to the layman such as myself!!!

--- What you have would actually be PERFECT for what I do with the coaster brake models... I actually like to run those with no display, speed sensor, anything. I tuck all the cables into the body, and sometimes wire a power switch into the main connector. Super clean and simple install with only the battery wire - for coaster brake models anyway... This way I could do the same with the Bluetooth connector, and not be stuck with a mediocre power level that ensues from the on with no display that I do now....

Edit: Oh, I'll play nice, cough CASIANHO, I appreciate that link instead of a message to look for it hard, that was real nice, haha.

Sorry for the interruption gentlemen, we now resume your normal 'programming' (heh see what I did there, lol)
 
casainho said:
Good idea and I counted 20 while we are using:
#define PAS_NUMBER_MAGNETS 24

I put my test code online, on branch pas_number_magnets_testing. You can see the number of magnets increasing of the "FOC angle" option. Can you please validate that I counted correctly 20? If so, I think cadence calculation will work as long as we define the correct number of magnets, maybe you can also validate the cadence value.
Click to expand...

Casainho.. I just did the test as well and I also count 20. (I have it on video)

This means the Cadence will go up by 1.2 which is much better than before.

If you think it will affect the way the firmware works then just leave it alone and put a fudge factor of 1.2 on the LCD display instead. Up to you
 
jbalat said:
casainho said:
Good idea and I counted 20 while we are using:
#define PAS_NUMBER_MAGNETS 24

I put my test code online, on branch pas_number_magnets_testing. You can see the number of magnets increasing of the "FOC angle" option. Can you please validate that I counted correctly 20? If so, I think cadence calculation will work as long as we define the correct number of magnets, maybe you can also validate the cadence value.
Click to expand...

Casainho.. I just did the test as well and I also count 20. (I have it on video)

This means the Cadence will go up by 1.2 which is much better than before.

If you think it will affect the way the firmware works then just leave it alone and put a fudge factor of 1.2 on the LCD display instead. Up to you
Click to expand...
As you can see, the cadence calculation already use the number of magnets, we just need to use the correct number and then the calculation will be correct. I will make that small change today.
 
Corrected to #define PAS_NUMBER_MAGNETS 20, on master branch.
 
jbalat said:
Sorry but this new feature does not work

I had to do 3 or more peddle turns before the motor would cut in.
Click to expand...
So, the code was checking for pedal cadence > 25, that was maybe why you had to do 3 turns??
I now changed that to be for pedal cadence > 6 and this time I was able to test (but quick small tests) and seems ok to me. However, I would not wonder if there are some glitches... we need to use/test and discover.

Here is the logic and the code:
If MOTOR_ASSISTANCE_CAN_START_WITHOUT_PEDAL_ROTATION = 0:
I just changed the code to,
1. output = 0 if pedal cadence < 6 RPM
2. output = torque sensor signal output if pedal cadence > 6 RPM and < 26
3. output = human power on pedals if pedal cadence > 25 RPM

Code: 
  // human power: pedal torque * pedal cadence
  // do not apply human power with lower cadence
  if (ui8_pas_cadence_rpm > 25)
  {
    // calc human power
    ui8_pedal_human_power = ((((uint16_t) ui8_torque_sensor) * ui16_temp) >> 8);

    // now scale human power with assist level
    f_temp = ((float) ui8_pedal_human_power) * f_get_assist_level ();
    if (f_temp > 255)
      f_temp = 255;

    ui8_pedal_human_power = (uint8_t) f_temp;
  }
#if (MOTOR_ASSISTANCE_CAN_START_WITHOUT_PEDAL_ROTATION == 1)
  else
  {
    ui8_pedal_human_power = ui8_torque_sensor;
  }
#else
  else if (ui8_pas_cadence_rpm > 6)
  {
    ui8_pedal_human_power = ui8_torque_sensor;
  }
  else
  {
    ui8_pedal_human_power = 0;
  }
#endif
 
That looks good you can just use cadence >0 should be ok

but what does this do ? It’s not really waiting 5 seconds is it ?

Code: 
// now count 5 seconds
    case STATE_STARTUP_PEDALLING:
    if (ui8_rtst_counter++ > 50) // 5 seconds
    {
      ui8_rtst_counter = 0;
      ui8_tstr_state_machine = STATE_PEDALLING;
    }

    // ebike is not moving, let's return to begin
    if (ui16_wheel_speed_x10 == 0)
    {
      ui8_rtst_counter = 0;
      ui8_tstr_state_machine = 0;
    }
    break;
 
jbalat said:
That looks good you can just use cadence >0 should be ok

but what does this do ? It’s not really waiting 5 seconds is it ?

Code: 
// now count 5 seconds
    case STATE_STARTUP_PEDALLING:
    if (ui8_rtst_counter++ > 50) // 5 seconds
    {
      ui8_rtst_counter = 0;
      ui8_tstr_state_machine = STATE_PEDALLING;
    }

    // ebike is not moving, let's return to begin
    if (ui16_wheel_speed_x10 == 0)
    {
      ui8_rtst_counter = 0;
      ui8_tstr_state_machine = 0;
    }
    break;
Click to expand...
That filters (set to 0) the torque sensor signal after 5 seconds of start pedaling and while wheel speed > 0. That is only to filter out the torque sensor signal when we are resting on pedals and ebike is moving... I think that works very well.
 
Hi Casainho I like the torque offset of +2 from the minimum value

Is it defined in main.c as +6 ?

Code: 
define ADC_TORQUE_SENSOR_THRESHOLD     6 // value in ADC 8 bits step
 
Just wanted to say I just tried the latest version and it works really well !!
Just like the original firmware it will behave when you are standing on the pedals waiting for the lights but if you let it nudge forwards a bit the motor will cut in momentarily.

Good work Casainho ;)

I need to do another cadence calculation. I could only ride to about 81 cadence before the motor cutout. Remember from my estimate the maximum. should have Been around 100. I bumped up the EPRS from 520 to 580 and I got to 93 cadence. I'm charging my battery because it's almost flat and this may have contributed to the low cadence ?
 
jbalat said:
Just wanted to say I just tried the latest version and it works really well !!
Just like the original firmware it will behave when you are standing on the pedals waiting for the lights but if you let it nudge forwards a bit the motor will cut in momentarily.
Click to expand...
Or we can try a different approach that is use a minimum torque value at startup. Please if is ok like this or we can try min torque instead of min cadence.

jbalat said:
I'm charging my battery because it's almost flat and this may have contributed to the low cadence ?
Click to expand...
Look at LCD3 motor speed ERPS and see if you are hitting the limit and to the PWM duty_cycle value.
 
I like the way the motor starts now from rest. Just leave it this way for now. It works exactly the same as the original firmware


The issue I have now is...

By scaling the cadence down this has had an affect of reducing the max cadence and speed. I was able to travel at 42km/hr and now I can only do 38km/hr

This is after I changed the ERPS from 520 to 580

In fact if we do the calculation (24/20) * 520 then the new equivalent ERPS should be 624 to get the same motor speed as before.

At 580 ERPS my Duty cycle was around 220

Do you agree ?
 
jbalat said:
I like the way the motor starts now from rest. Just leave it this way for now. It works exactly the same as the original firmware


The issue I have now is...

By scaling the cadence down this has had an affect of reducing the max cadence and speed. I was able to travel at 42km/hr and now I can only do 38km/hr

This is after I changed the ERPS from 520 to 580

In fact if we do the calculation (24/20) * 520 then the new equivalent ERPS should be 624 to get the same motor speed as before.

At 580 ERPS my Duty cycle was around 220

Do you agree ?
Click to expand...
Sorry, I am confused.

Your motor may not achieve the RPM you want if:
1. motor speed ERPS limit is hit: you can look at that value on LCD3 to see
2. PWM duty-cycle is at max value, this means motor coils voltage are at max possible voltage: see on LCD3

For 2., maybe you can improve by using higher battery voltage.

Also, I used for the first time the firmware on my son 36V motor and I remembered that I had to change the value for motor 36V, on the FOC calculation were 36V motor has lower inductance value. This values were calculated and other was measured, I am not sure of all this. Please try to change ui32_l_x1048576 = 142 (see the comments to understand); on motor.c, calc_foc_angle(). What I expect is the best efficiency possible, more torque/less battery energy used. Maybe this will improve what you ate looking for.
 
You must log in or register to reply here.

Similar threads

Cybernetica
2 Power mode switching for semi-legal EU option. BBS02 / 850C
Replies
4
Views
932
Cybernetica
Cybernetica
R
Re: Disque intermédiaire TSDZ2 avec écrans 860C, 850C ou SW102 uniquement -- Firmware OpenSource flexible (code Casainho
Replies
1
Views
509
Elinx
E
casainho
EasyDIY OpenSource display for EVs: TSDZ2 and Bafang M500/M600 EBike motors
5 6 7 8 9
Replies
207
Views
26,968
prozyc
P
M
    • Like
TSDZ2 OSF for all displays, VLCD5-VLCD6-XH18, LCD3, 860C-850C-SW102.
94 95 96 97 98
Replies
2,432
Views
205,983
mbrusa
M
Z
TSDZ2 SW102 OpenSource firmware (fail before flashing)
Replies
0
Views
662
zip1989
Z
Back
Top