Tsdz2 firmware open source adapted to vlcd5, vlcd6 and xh18

zappan said:
Elinx said:
wpenner said:
..........
If you use VCLD5 or VCLD6 it will not display the current value of the temperature sensor..........
There is always hope :)
mbrusa is working on that (monitoring temperature, Voltage, Watt etc.) and has already a working trial for XH18 display, based on 0.19C-v3.7 of marcoq.

For the moment only XH18 and not the vlcd.... displays, because they responding different on input of these values.

It works perfectly for XH18 :D . Thanks again to Mbrusa for his work :thumb: , the user from here Ashambro has also tested it and displays:
- the engine temperature
- the remaining battery charge in percentage
- battery voltage
but not yet for VCLD6 and VCLD5 :( , who can help develop these displays?

Latest version released by Mbrusa:
http://www.jobike.it/forum/topic.asp?TOPIC_ID=76426&whichpage=52

Hi, great news the latest release of Mbrusa works perfectly with all the original Displays :bigthumb:

http://www.jobike.it/forum/topic.asp?TOPIC_ID=76426&whichpage=55

http://www.jobike.it/Public/data/mbrusa/20191126123735_modifica_mbrusa_XH18_VLCD5_6_TSDZ2_Controller_vM0.19.C_and_TSDZ2_Configurator_0.3.7.zip
 
zappan said:
..........
Hi, great news the latest release of Mbrusa works perfectly with all the original Displays :bigthumb:

http://www.jobike.it/forum/topic.asp?TOPIC_ID=76426&whichpage=55

http://www.jobike.it/Public/data/mbrusa/20191126123735_modifica_mbrusa_XH18_VLCD5_6_TSDZ2_Controller_vM0.19.C_and_TSDZ2_Configurator_0.3.7.zip
Yes I had see this already too. :bigthumb:
For the people that want to try this addition.
In the zip file are only the modified files.
You must replace the original files with these and compile and flash the contoller again.

Marcoq has already mentioned that he will add these additions from mbrusa to his configurator, so you can choose wich valueas you want to see on the display.

vlcd 5/6 display procedure:

With VLCD5 and VLCD6 the procedure with the light button is the same, the codes change.
At the first press of the light button, E08 is not displayed but immediately the code of the corresponding data, at the second press of the button the data.
E02 - temperature (if sensor is present)
E03 - remaining battery capacity
E04 - battery voltage

In this version I left eMTB at level 3 as in that of marcoq, for those like me who prefer to have it at level 4, in the ebike_app.h file there is a new parameter ASSIST_LEVEL_eMTB, just put TURBO instead of SPORT.
 
I made some changes here and it seems there's no reason the various modes (street, boost, eMTB) can't be set up more logically, at least for the VLCD5.

Mine now works like below. First LIGHTS button press displays the current mode's status (E01 = Off, E02 = On), press again to change it. It's the same for all modes.

I also disabled the error code E02 displayed when assist is off and the LIGHTS button is pressed.

ECO:
E01 - Street mode OFF
E02 - Street mode ON

TOUR:
E01 - Boost mode OFF
E02 - Boost mode ON

SPEED/STREET/SPORT:
E01 - eMTB mode OFF
E02 - eMTB mode ON
 
zappan said:
http://www.jobike.it/Public/data/mbrusa/20191126123735_modifica_mbrusa_XH18_VLCD5_6_TSDZ2_Controller_vM0.19.C_and_TSDZ2_Configurator_0.3.7.zip

Why the hell you don't use github for publishing stable versions?! All users have to search all over the internet to find .zip files. Nobody knows which version is stable and which has bugs and nobody knows the differnce between the versions (hopefully the author himself knows them :wink: )
- marcoq
- ackmaniac
- Mbrusa
- ???

With github you can see clearly what has changed with each commit and you can describe the differences of your fork in the readme.md
Of course this only works, if you don't just upload zip files to github, but use git to syncronize your working folder. That's not too difficult with the git plugin in eclipse...

https://github.com/qmarco/TSDZ2-Smart-EBike-compatible-with-original-VlCD6-display/network/members

forks of qmarco.PNG

regards
stancecoke
 
stancecoke said:
zappan said:
http://www.jobike.it/Public/data/mbrusa/20191126123735_modifica_mbrusa_XH18_VLCD5_6_TSDZ2_Controller_vM0.19.C_and_TSDZ2_Configurator_0.3.7.zip

Why the hell you don't use github for publishing stable versions?! All users have to search all over the internet to find .zip files. Nobody knows which version is stable and which has bugs and nobody knows the differnce between the versions (hopefully the author himself knows them :wink: )
- marcoq
- ackmaniac
- Mbrusa
- ???

With github you can see clearly what has changed with each commit and you can describe the differences of your fork in the readme.md

regards
stancecoke

:bigthumb:
 
stancecoke said:
zappan said:
http://www.jobike.it/Public/data/mbrusa/20191126123735_modifica_mbrusa_XH18_VLCD5_6_TSDZ2_Controller_vM0.19.C_and_TSDZ2_Configurator_0.3.7.zip

Why the hell you don't use github for publishing stable versions?! All users have to search all over the internet to find .zip files. Nobody knows which version is stable and which has bugs and nobody knows the differnce between the versions (hopefully the author himself knows them :wink: )
- marcoq
- ackmaniac
- Mbrusa
- ???
...

I'm sorry stancecoke, but I just broke the news.
 
zappan said:
I just broke the news.

I know, but you are the "voice" of Mbrusa in this forum. I'm not active in the italian forum, perhaps you can give him a hint :wink:

Regards
stancecoke
 
stancecoke said:
......
Why the hell you don't use github for publishing stable versions?! All users have to search all over the internet to find .zip files. Nobody knows which version is stable and which has bugs and nobody knows the differnce between the versions.....
stancecoke said:
..... I'm not active in the italian forum, perhaps you can give him a hint.....
Ofcourse you are right. I'am also not active on the Jobike forum, but translate and read there on regulair base, otherwise I cannot keep up with the changes.
marcoq is not very active there either, but he gives the impression that he reads the messages here and there.
I think he is a very busy man and must divide the available time.
So he made choices that are not ideal for others.
 
stancecoke said:
Why the hell you don't use github for publishing stable versions?! All users have to search all over the internet to find .zip files.

Thank you for expressing your frustration. It's very confusing for newcomers when it really shouldn't be, especially with the configurator etc that Marcoq has built making the process so simple.

Soon people will be asking for 0.20 and integrating the various enhancements into a single version will be impossible. And while the configurator provides an easy to use interface, unfortunately waiting for a single person to provide updates will hinder other development.

As I come across problems in the code I really don't know where I should be raising them other than posting about it here. It doesn't look like there is a single officially active repo to contribute to. Perhaps if an up-to-date repo can be agreed on (Stancecoke's fork?) then the first post here could be updated with a link to that, or new thread created specifically for that purpose.

But are there many active developers here for this VLCD5 version? Or is everyone concentrating on the main version now?
 
famichiki said:
I also disabled the error code E02 displayed when assist is off and the LIGHTS button is pressed.

Looking at this again, can anyone please tell me the intended function of pressing LIGHTS when assist is OFF?

It seems like it will reset your mode settings to the defaults which you last flashed with. Is that correct?

I see Ackmaniac fixed a bug with eMTB startup defaults too. :thumb:
 
After testing between Marcoq's and Ackmaniac's versions, Ackmaniac's feels much more natural to me. However the motor overrun happens with Marcoq's too.

I notice that even if you apply the brake for a second, after you release it the overrun will continue. So I played around with the code and eliminated it, as soon as you apply the brake all parameters are reset.

However I couldn't get the same idea to work with the assist, so does anyone have any suggestions of where in the code to look? I asked on the main firmware thread but didn't get any answers. I presume the problem also exists in Casainho's 0.19 but have no way to test unfortunately.
 
stancecoke said:
Can you explain the fault again, please. What happens when? Is the behaviour reproducible?

Sure, please let me know if you'd like anything further.

There are 3 behaviours I've noticed, (1) and (2) are easily reproducible.

1. Motor runs up to a couple of seconds after stopping pedalling.

The overrun time varies from very brief to quite long. I can't figure out what the duration is related to, but if I pedal briefly it seems to run shorter than if I do multiple rotations. Speed might also be a factor.

I usually don't have brake cutoffs but fitted a third lever to experiment with. If I grab the brake for a brief moment while the overrun is happening, after I release it the overrun will continue.

This is the standard code when the brake is set and it really only pauses things when it needs other parameters reset to be safe.

Code:
ebike_app_set_target_adc_battery_max_current(0);
ebike_app_set_target_adc_motor_max_current(0);

I added this which helped to resolve it when braking, but behaviour (2) below still happened and after trying many things I still could not get the non-braking overrun to go away.

Code:
ui8_duty_cycle = 0;
ui8_motor_enabled = 0;
disable_pwm();

2. A burst or kick of power about a second after stopping pedalling.

This sounds like a loud ZZzz and seems to happen both during or after the overrun. It can even happen after you've come to a complete stop, giving you a little shunt.

3. Motor continues to run until system forcefully shut down.

Only happens rarely but motor will continue to provide power after stopping pedalling until manual intervention. Unsure of the cause or what ways work to cancel it, as it usually involves a panic trying to cut the power off.
 
Wow, OK. I just looked at the code, I still don't understand, why casainho doesn't use a PI control for the currents.
And the whole code seems to be rewritten in the recent master repo of casainho...

It is obvious, that the battery current target is not reset in each loop run in the ebike_app.c. But this shouldn't matter, as the phase current is always higher than the battery current.

Code:
  // clear battery target current
  ui8_adc_battery_target_current = ui8_adc_battery_current_max;
  ui8_adc_motor_target_current = 0;

First pragmatic suggestion is to add the cadence to the PWM target processing (line 685):

Code:
 if((ui8_adc_motor_target_current)&&(!ui8_brake_is_set)&&(ui8_pas_cadence_rpm))

If this doesn't help, we have to decrement the PWM in the timer interrupt routine (line 722 of motor.c).

Code:
  else if((ui16_motor_speed_erps > ui16_max_motor_speed_erps)) // if motor speed over max motor ERPS, reduce duty_cycle
  {
    if (ui8_duty_cycle > 0)
    {
      // decrement duty cycle
      ui8_duty_cycle--;
    }
    
  else if(ui16_pas_pwm_cycles_ticks >= (uint16_t) PAS_ABSOLUTE_MIN_CADENCE_PWM_CYCLE_TICKS) //Rider is not pedaling
  {
    if (ui8_duty_cycle > 0)
    {
      // decrement duty cycle
      ui8_duty_cycle--;
    }

Of course, this "quick and dirty" solutions will kill any throttle override function (no motor power without pedals turning in any case)

regards
stancecoke
 
I currently startet with the Ackmaniac code.
I din not understand which branch is the code from casainho? Based on ...?
 
godofglow said:
... Ackmaniac code....
Based on ...?
Ackmaniac has based his code on Marcoq v0.19C what is based on the stable v0.19 from Casainho.
 
stancecoke said:
Wow, OK. I just looked at the code, I still don't understand, why casainho doesn't use a PI control for the currents.
And the whole code seems to be rewritten in the recent master repo of casainho...

It is obvious, that the battery current target is not reset in each loop run in the ebike_app.c. But this shouldn't matter, as the phase current is always higher than the battery current.

Thanks for the tips, I tried them out today with mixed results.

Unfortunately I don't really understand the motor control stuff but I might have narrowed down the overall problem to something to do with the cadence. I sent an error code to the display whenever ui8_pas_cadence_rpm was zero and it didn't display until the end of the motor overrun. It seems the higher the cadence, the longer it dwells for. So because of that then your first suggestion at line 685 didn't work. I'd also tried similar changes before and couldn't get any improvement. Do you think would reducing the PWM duty cycle ramp down value would help, is that what it's meant for? I have previously tried reducing that but it didn't appear to help.

Your second suggestion seemed to help but caused hard cut-offs and clicking from the motor. Is there any way to smooth that? I'll need to test it again to be sure 100% sure it was stopping the overrun, I've been experimenting so much this afternoon I've confused myself as well as worn circles into the lawn. :lol: I'd like to do the same error code display with ui16_pas_pwm_cycles_ticks to see how responsive it is.

Interestingly, when operating the brakes the cut-off doesn't seem so bad. I played around adding this to ebike_app.c (around line 334), after ENABLE_BRAKE_SENSOR.

Code:
  if (ui8_torque_sensor < TORQUE_SENSOR_THRESHOLD_LOW)
  { 
	ui8_brake_is_set = 1;
  else
  {
	ui8_brake_is_set = 0;
  }

I found it was too sensitive and cut in and out a lot, perhaps reducing the threshold could help but I imagine this varies for every motor. It was impossible to pedal lightly and receive minimal constant assist.

Finally, I see in torque_sensor_read() in ebike_app.c there is a check for moving without pedalling to filter the ui8_torque_sensor to zero, but since it also tests for (ui8_pas_cadence_rpm == 0) I suspect it's going to suffer from the overrun lag too.

Code:
  // next state machine is used to filter out the torque sensor signal
  // when user is resting on the pedals
  switch(ui8_tstr_state_machine)
  {
    // ebike is stopped
    case STATE_NO_PEDALLING:
			if((ui8_torque_sensor_raw > 0)&&
         (ui16_wheel_speed_x10))
			{
				ui8_tstr_state_machine = STATE_PEDALLING;
			}
			break;

    // wait on this state and reset when ebike stops
    case STATE_PEDALLING:
			if((ui16_wheel_speed_x10 == 0)&&
         (ui8_torque_sensor_raw == 0))
			{
				ui8_tstr_state_machine = STATE_NO_PEDALLING;
			}
			break;

    default:
			break;
  }			

  // bike is moving but user doesn't pedal, disable torque sensor signal because user can be resting the feet on the pedals
  if((ui8_tstr_state_machine == STATE_PEDALLING)&&(ui8_pas_cadence_rpm == 0))
  {
    ui8_torque_sensor = 0;
  }
  else
  {
    ui8_torque_sensor = ui8_torque_sensor_raw;
  }
}
 
el_proletario said:
Hi everyone,

Did any of you install the software on the coaster brake version?
I installed it a couple of months back to see and the motor was still on half a second after I stopped to pedal. It was quite annoying so I put the original software back...
Also I found the motor to be less powerful, it required more efforts to move forward.

Is there any option on the configurator to make it work better and get 0 cut off delay when I stop pedaling ?

Many thanks
Hey,
did You find solution? I have one bike with coaster brake and also would like to use this firmware...
 
famichiki said:
So because of that then your first suggestion at line 685 didn't work.

OK, it seems, that the processor runs out of time. We had similar problems in the kunteng project. We replaced floating point arithmetics with integer arithmetics and replaced divisions with right shifts, where ever possible, that solved the issues.

Casainho and I (in the Kunteng project) have taken different paths in the way of controlling the duty cycle more than one year ago.
So I'm not really familiar with his recent code and I'm not motivated to do more than giving a few "quick and dirty" hints like I did above.

regards
stancecoke
 
stancecoke said:
famichiki said:
So because of that then your first suggestion at line 685 didn't work.

OK, it seems, that the processor runs out of time. We had similar problems in the kunteng project. We replaced floating point arithmetics with integer arithmetics and replaced divisions with right shifts, where ever possible, that solved the issues.

Casainho and I (in the Kunteng project) have taken different paths in the way of controlling the duty cycle more than one year ago.
So I'm not really familiar with his recent code and I'm not motivated to do more than giving a few "quick and dirty" hints like I did above.

regards
stancecoke

No problem, if you have any more ideas please let me know. I'd be really interested to see how 0.20 performs, but the factory firmware also had an overrun problem so I hope it is able to be corrected.
 
famichiki said:
if you have any more ideas please let me know

In addition to the already mentioned suggestions to avoid floats and divisions, it would need major rewriting of the core duty cycle manipulation and calulation of the target current.
-> Speedsensor and PAS processing via interrupts
-> Duty Cycle setting via a PI-control

overall principle: do as less as possible in the interrupt routines, only really time-critical operations. For any not time-critical calculation, just set a flag in the interrupt routine and do the calculation in the main loop.

Could be done by copy-paste from the Kunteng project, but would take several hours of work to fix all differences in variable naming etc.

regards
stancecoke
 
Hello,
I'm planning to upload firmware on TSDZ2 350W coaster brake type motor with VLCD5 display. If I set PWM DUTY RAMP DW much lower(0.6 or someone has even 0.3) would it help to stop motor faster (when there will be no cadence)? What else should I check and set properly? Maybe someone has done it before? (I bet someone did:))
Thanks.
A.
 
adrian009 said:
Hello,
I'm planning to upload firmware on TSDZ2 350W coaster brake type motor with VLCD5 display. If I set PWM DUTY RAMP DW much lower(0.6 or someone has even 0.3) would it help to stop motor faster (when there will be no cadence)? What else should I check and set properly? Maybe someone has done it before? (I bet someone did:))
Thanks.
A.

I tried setting to 0.3 and couldn't notice a difference, but you need to be using Ackmaniac's fork to safely set that low. Please try out some settings and tell us what happens.
 
famichiki said:
adrian009 said:
Hello,
I'm planning to upload firmware on TSDZ2 350W coaster brake type motor with VLCD5 display. If I set PWM DUTY RAMP DW much lower(0.6 or someone has even 0.3) would it help to stop motor faster (when there will be no cadence)? What else should I check and set properly? Maybe someone has done it before? (I bet someone did:))
Thanks.
A.

I tried setting to 0.3 and couldn't notice a difference, but you need to be using Ackmaniac's fork to safely set that low. Please try out some settings and tell us what happens.

Thx. I just ordered STLink module, will see. One more question, where can I find oryginal firmware for coaster brake version in case this one wont work properly?
 
Back
Top