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

bart594 said:
Hi casainho and buba

since some time i'm trying to make 850c compatible with latest alpha firmware. Sadly there is some problem with communication. There is shift from time to time in values like on the pic 1 - the starting byte is in place of message id and the other values are too on incorrect places in array. Pic 2 shows when everything is ok. Basically the values in the rx buffer for motor controller showing randomly? misplaced
I think i tried everything: revert to old communication protocol structure like in stable for lcd and motor controller (sending 6 bytes and message id =8), sending only hardcoded values without variables so no coping between layers is needed for lcd850 , shorting it to only few values. Nothing worked. The only thing that worked partially was increasing sending/receiving interval to 110 ms on lcd but it still not working completely the shift/misplacing is gone for rx array but it is still out of sync because there is no assistance from motor.

I looked at motor controller code for alpha and buba you have changed order when communication is executed:

communications_controller(); // get data to use for motor control and also send new data
ebike_control_motor(); // use received data and sensor input to control motor

on stable it is behind ebike_control_motor

ebike_control_motor();
communications_controller();

But this is still executed in loop every 100 ms so it shouldn't have effect on communication with lcd ?

No, there should be no difference and if it is something is terribly wrong. What is important is the 100 ms timing.


bart594 said:
Maybe you you guys have an idea where i should look/check ?
I thought it will be pretty straightforward to adapt the code - just adding few new variables for configuration and copy uart structure from lcd3 but now I'm out of ideas..
I'm using STM Studio to monitor variables live The values that I'm monitoring are on motor controller side
Here is my github with changes
https://github.com/bart594/Color_LCD/

regards

bart594

I am looking at the code now!

------------------------------------

I think something that should be done is to create the riding_mode_controller that is present in the 0.20.0. The riding mode should only change in that function. This is not why you have a problem but it will simplify the debugging.

Code:
void assist_level_state(void)
{
  static uint8_t ui8_assist_level_previous = 0xff;
  static uint8_t ui8_riding_mode_emtb_prev;
  //static uint8_t ui8_var_temp;
  
  static print_number_t assist_level_emtb =
  {
    .font = &FONT_45X72,
    .fore_color = C_ORANGE,
    .back_color = C_BCKGROUND_1,
    .ui8_previous_digits_array = {255, 255, 255, 255, 255},
    .ui8_field_number_of_digits = 1,
    .ui8_left_zero_paddig = 0,
  };

  static print_number_t assist_level =
  {
    .font = &FONT_45X72,
    .fore_color = C_MAIN_1,
    .back_color = C_BCKGROUND_1,
    .ui8_previous_digits_array = {255, 255, 255, 255, 255},
    .ui8_field_number_of_digits = 1,
    .ui8_left_zero_paddig = 0,
  };

  if (m_lcd_vars.ui32_main_screen_draw_static_info)
  {
    UG_SetBackcolor(C_BCKGROUND_1);
    UG_SetForecolor(C_TITLE_1);
    UG_FontSelect(&FONT_10X16);
    UG_PutString(12, 55, "ASSIST");
  }

  if (buttons_get_up_click_event() && m_lcd_vars.main_screen_state == MAIN_SCREEN_STATE_MAIN)
  {
    buttons_clear_all_events();
    
    if (++l3_vars.ui8_assist_level > l3_vars.ui8_number_of_assist_levels)
    {
      // if eMTB is enabled set to +1
      if (1)
      {
        l3_vars.ui8_assist_level = l3_vars.ui8_number_of_assist_levels + 1;
      }
      else
      {
        l3_vars.ui8_assist_level = l3_vars.ui8_number_of_assist_levels; 
      }
	  }
  }

  if (buttons_get_down_click_event() && m_lcd_vars.main_screen_state == MAIN_SCREEN_STATE_MAIN)
  {
    buttons_clear_all_events();
    
    if (l3_vars.ui8_assist_level > 0) { --l3_vars.ui8_assist_level--; }
  }
  
  if ((l3_vars.ui8_assist_level != ui8_assist_level_previous) || m_lcd_vars.ui32_main_screen_draw_static_info)
  {
    ui8_assist_level_previous = l3_vars.ui8_assist_level;

    assist_level.ui32_x_position = 20;
    assist_level.ui32_y_position = 81;
    assist_level.ui32_number = (uint32_t) l3_vars.ui8_assist_level;
    //assist_level.ui8_refresh_all_digits = m_lcd_vars.ui32_main_screen_draw_static_info;
    assist_level.ui8_refresh_all_digits = 1;
    assist_level_emtb.ui32_x_position = 20;
    assist_level_emtb.ui32_y_position = 81;
    assist_level_emtb.ui32_number = (uint32_t) l3_vars.ui8_number_of_assist_levels;
    //assist_level_emtb.ui8_refresh_all_digits = m_lcd_vars.ui32_main_screen_draw_static_info;
    assist_level_emtb.ui8_refresh_all_digits = 1;
    
    if (l3_vars.ui8_assist_level > l3_vars.ui8_number_of_assist_levels) { lcd_print_number(&assist_level_emtb); }
    else {lcd_print_number(&assist_level);}
  }
}


void riding_mode_controller(void)
{
  static uint8_t ui8_walk_assist_state = 0;
  static uint8_t ui8_walk_assist_previous;
  static uint8_t ui8_riding_mode_previous;
  uint32_t ui32_x1;
  uint32_t ui32_y1;
  uint32_t ui32_x2;
  uint32_t ui32_y2;
  
  // reset riding mode
  l3_vars.ui8_riding_mode = OFF_MODE;
  
  if ((l3_vars.ui8_assist_level > 0) && (l3_vars.ui8_assist_level < l3_vars.ui8_number_of_assist_levels + 1))
  {
    // power assist
    // torque assist
    // cadence assist
  }
  else if (l3_vars.ui8_assist_level == l3_vars.ui8_number_of_assist_levels + 1)
  {
    l3_vars.ui8_riding_mode = eMTB_ASSIST_MODE;
  }
/*
  if (m_lcd_vars.lcd_screen_state == LCD_SCREEN_MAIN && l3_vars.ui8_walk_assist_feature_enabled)
  {
    if (buttons_get_down_long_click_event())
    {
      // clear button long down click event
      buttons_clear_down_long_click_event();
      ui8_walk_assist_state = 1;
    }

    // if down button is still pressed
    if (ui8_walk_assist_state && buttons_get_down_state())
    {
      l3_vars.ui8_walk_assist = 1;
    }
    else if(buttons_get_down_state() == 0)
    {
      ui8_walk_assist_state = 0;
      l3_vars.ui8_walk_assist = 0;
    }
  }
  else
  {
    ui8_walk_assist_state = 0;
    l3_vars.ui8_walk_assist = 0;
  }
   
    if((l3_vars.ui8_riding_mode < 5) || (l3_vars.ui8_riding_mode > 6)){ui8_riding_mode_previous = l3_vars.ui8_riding_mode;} 
	
    if(l3_vars.ui8_walk_assist && (l3_vars.ui8_assist_level > 0) && (l3_vars.ui16_wheel_speed_x10 < WALK_ASSIST_THRESHOLD_SPEED_X10))
    {
	 l3_vars.ui8_riding_mode = WALK_ASSIST_MODE;
	 } 
	 else if(l3_vars.ui8_walk_assist && (l3_vars.ui16_wheel_speed_x10 > CRUISE_THRESHOLD_SPEED_X10))
	{
	 l3_vars.ui8_riding_mode = CRUISE_MODE;
	}
	else
	{
	l3_vars.ui8_riding_mode = ui8_riding_mode_previous;
	}
	 
  // if previous state was disable, draw
  if((l3_vars.ui8_walk_assist != ui8_walk_assist_previous) ||
       m_lcd_vars.ui32_main_screen_draw_static_info)
  {
    ui8_walk_assist_previous = l3_vars.ui8_walk_assist;

    if(l3_vars.ui8_walk_assist)
    {
      UG_SetBackcolor(C_BCKGROUND_2);
      UG_SetForecolor(C_MAIN_2);
      UG_FontSelect(&SMALL_TEXT_FONT);
      ui32_x1 = 190;
      ui32_y1 = 10;
      UG_PutString(ui32_x1, ui32_y1, "W");
    }
    else
    {
      // clear area
      // 1 leters
      ui32_x1 = 190;
      ui32_y1 = 10;
      ui32_x2 = ui32_x1 + ((1 * 10) + (1 * 1) + 1);
      ui32_y2 = ui32_y1 + 16;
      UG_FillFrame(ui32_x1, ui32_y1, ui32_x2, ui32_y2, C_BCKGROUND_2);
    }
  }
  */
}

This code enables you to remove the walk_assist_state and replace it with the riding_mode_controller. I think you will understand what I have done. The Walk Assist and Cruise are commented for now as it is safer. But by doing this simple change we can be sure that you are always enabling the eMTB mode. There should only be one function that changes the riding modes and this is done for safety and a clear code.

Please note that I do not have the 850C and you need to validate everything.

------------------------------------

EDIT:

Just checked the communication and realized it is going to take some time to look through everything. I believe you when you say that you have tried everything and therefore I do not want to give suboptimal suggestions.

A lot of work is being done on the 850C now together with the SW102. So this will most likely be solved soon. But still... I want to help. Maybe Casainho has an idea that will immediately point you in the right direction.
 
Update on the eMTB sensitivity poll:

12.5 % uses sensitivity 1
62.5 % uses sensitivity 4
25.0 % uses sensitivity 6

Everyone has so far picked values below 7. I am confirming that eMTB will be updated in one way or another. I have already ideas on how to improve it. Will try to increase the number of sensitivity values as well so everyone can pick a value that works for them.
 
Bafang 850C display new firmware version

Download here: https://github.com/OpenSource-EBike-firmware/Color_LCD/releases/tag/v0.3.0

Follow the wiki to know the buttons combinations.

Bafang_850C_color_LCD_TSDZ2-wheel_speed-66.jpg
Bafang_850C_color_LCD_TSDZ2-configurations-66.jpg


Changes:
- graphs data variable to be shown can now be quickly changed from the main screen
- option to invert up and down buttons so the keypad can be installed on the right side of the handle bar
- enable the USB charging
- implemented imperial units
- implemented the option to enable throttle or temperature sensor, or disable both
- various small corrections

NOTE: this version was developed for TSDZ2 motor controller firmware stable version v0.19.0.
 
buba said:
e3s said:
What about using a linear resistor instead of the throttle to select the level assist?

That would be very possible to implement. But the problem is we would loose either the throttle or the temperature control if we did that. So we would have to write different implementations depending on user setup.
You are right. Temperature warning is important. Unfortunately I would like to help to test emtb mode but I can't Because I'm waiting some pieces.
 
bart594 said:
Hi casainho and buba
,
since some time i'm trying to make 850c compatible with latest alpha firmware. Sadly there is some problem with communication.
Sorry, I have no clue.

I just did a release of a new version of firmware for 850C display.

Geeksville is joining the firmware of SW102 and 850C so there will be a common base for the both displays and probably the 850C firmware as it is will change a lot, so my suggestion is for you to stop for now and join development or wait for that new version.
 
buba said:
elem said:
And yes it s different in marcoq version, in fact for me it s better than standard 0.19 because i can change the duty cycle and other things like that, haven t found on standard 0.19 what i need to change, may be my mistake ? i was using v 0.16 and i thinck it was a really good release .

- Can you explain more about the ability to change the duty cycle?

- And what other things would you like to change, improve or add? If you would like to take a look at the 0.20.0 wiki and maybe give suggestions of improvements to make? Maybe something Marcoq has implemented that we have not yet added or some feature/function that works better.

0.20.0 wiki:
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/0.20.0-(DEVELOPMENT)-%7C-KT-LCD3-%7C-TSDZ2-%7C-Manual

For duty cycle i m not an expert, i thanck it was possible to improve the work of the motor .
marcoq implemented the ability to change ramp up ramp down, not sure it s changing something ( have to test more )

pwn duty cycle v05.jpg

i m actually using pwn duty cycle 1.1 instead of 1.3 for up and down


as i said before in V 0.19 the start assit seem too long, and stop assit also
changing them seem impossible on V 0.19 but marcoq implemented a fonction to modify it



as marcoq is using official release, here it was v0.19 based
as you can see " standard " value from v 0.19 is 20 for initial soft start, too long changed it to 3 and it s perfect for me
K soft factor seem to adjust the decrease time when you stop pedaling, changed it to 0.350 and it s better .

in fact the defaut set up is probably good for road bike or treking but for MTB it s not good

in v 0.16 as long as i remenber i haven t this problem

as i said before maroq choice : what mean : with stock LCD5 we have 4 lvl of assist, marcoq choice was to put eMTB on the 3 one wich it s a good idea, we have for example ( what i m using ) lvl 1 for ridding with ppl without electric bike ( about 150 w avaiable max ) , lvl2 for climbing light mountain ( 300 w max ), lvl3/eMTB ( from 80 to max power 550 w for me, adjusted with a 1.15 factor ) and lvl4 when you are tired and need to climb with less effort .

Soo what could be good in v 0.20 : the ability to choose the lvl for eMTb mode .

yesterday i changed the motor of my midrive from a 36v motor to a 48v motor, i bought only the motor because my midrive is adjusted to my bike, my first goal was to improve the q-factor tu use a 32T instead of the regular 42T ( stock ) and use a 11/40 K7 without loosing any gear, it s ok modifying the frame and adjusting the middrive hub .

next step will be testing the v 0.20 ( probably today after my morning ride )

here is my last test with V 0.19 using a 36V motor ( experimental mode activated ) and a 12S battery .
motor power limit : 550W, max curent 15A, curent ramp : 4.5
menu 9 ( advanced data )
2 ;ADC pedal torque sensor : 53 ( static ), 89 ( right pedal whit my weight=64 kg ), 86 ( left pedal with my weight )
3 ; pedal torque sensor : 0 to 170
6 ; PWN duty cycle : 0 to 270
7 ; motor speed in REPS : 0 to 670
8 ; FOC angle : 1/2/3 , depend spining

don t know if my comment will be usefull but i share it .

And thancks to everybody involved in the development of the open source firmware, it s amazing ;)
 
buba said:
Clarification: If anyone likes how the eMTB mode works it is very similar to Torque Assist so give Torque Assist a try! If we had a sensitivity of zero on eMTB it would be just like Torque Assist and just a linear function. So if Torque Assist is setup properly the transition to eMTB will be completely natural but with more power! Please take time to configure and try this out.

After light testing of Torque Assist this is my first impression :
low Torque multiplier -> too weak assist when heavy pedal torque is applied (in steep uphill climb)
higher Torque multiplier -> too much assist when light pedal torque is applied (in sharp turn )

I guess the eMTB (exponential curve) just naturally compensates the torque sensor limits. Perhaps after the full sensor calibration the Torque Assist will be perfect.
 
ok, 48V is clearly better for MTB, better respondive for slower human rpm .

soo before going to V 0.20 made somme test to compare with the 36V motor

For me it s not easy to change version, i have to open my lcd3 and put wires in holes for programming, never solder anything on it, nor openned a hoole/windows to acces programming port, it s why i was waiting for stable release, in fact was using only v 0.16 stable relase, never tested other versions .

Soo with my set up ( 550 w max, 15A max, 5 lvl assist : 0.2/0.4/0.8/1.2/2.1 )

standard motor ( 0 ) mode :
menu9 :
3 = more than 200
4 = stop at 90, average 86 rpm ( human cadence )
5 = nothing displayed nevermore
6 = 180 duty cycle max
7= 500 reps max

experimental mode ( 2 )
6 = 280 ( about the same of my "old " 36v motor with experimental mode )
7 = 680

soo experimental mode is working fine with 36 and 48 v motor .

Well i m reday to test V 0.20 this afternoon and seeing if torque mode is soo strong, it s what i m affraid off in fact, getting too much power could be dangerous in hard climbing rock .

have fun : https://vimeo.com/353996242 , https://vimeo.com/353968863
 
elem said:
buba said:
elem said:
And yes it s different in marcoq version, in fact for me it s better than standard 0.19 because i can change the duty cycle and other things like that, haven t found on standard 0.19 what i need to change, may be my mistake ? i was using v 0.16 and i thinck it was a really good release .

- Can you explain more about the ability to change the duty cycle?

- And what other things would you like to change, improve or add? If you would like to take a look at the 0.20.0 wiki and maybe give suggestions of improvements to make? Maybe something Marcoq has implemented that we have not yet added or some feature/function that works better.

0.20.0 wiki:
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/0.20.0-(DEVELOPMENT)-%7C-KT-LCD3-%7C-TSDZ2-%7C-Manual

For duty cycle i m not an expert, i thanck it was possible to improve the work of the motor .
marcoq implemented the ability to change ramp up ramp down, not sure it s changing something ( have to test more )

pwn duty cycle v05.jpg

i m actually using pwn duty cycle 1.1 instead of 1.3 for up and down


as i said before in V 0.19 the start assit seem too long, and stop assit also
changing them seem impossible on V 0.19 but marcoq implemented a fonction to modify it

Soft start defaut.jpg

as marcoq is using official release, here it was v0.19 based
as you can see " standard " value from v 0.19 is 20 for initial soft start, too long changed it to 3 and it s perfect for me
K soft factor seem to adjust the decrease time when you stop pedaling, changed it to 0.350 and it s better .

in fact the defaut set up is probably good for road bike or treking but for MTB it s not good

in v 0.16 as long as i remenber i haven t this problem


Now I completely understand! Wow, okay did not know he allowed to change the duty cycle ramp up/down! In 0.20.0, this is similar to the motor acceleration variable you will see in the 0.20.0 wiki under Advanced Setup:

https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/0.20.0-(DEVELOPMENT)-%7C-KT-LCD3-%7C-TSDZ2-%7C-Manual

And when you try out the 0.20.0 and it will be a big difference compared to the 0.16.0!



elem said:
as i said before maroq choice : what mean : with stock LCD5 we have 4 lvl of assist, marcoq choice was to put eMTB on the 3 one wich it s a good idea, we have for example ( what i m using ) lvl 1 for ridding with ppl without electric bike ( about 150 w avaiable max ) , lvl2 for climbing light mountain ( 300 w max ), lvl3/eMTB ( from 80 to max power 550 w for me, adjusted with a 1.15 factor ) and lvl4 when you are tired and need to climb with less effort .

Soo what could be good in v 0.20 : the ability to choose the lvl for eMTb mode .

Okay! Will consider everything you said and await more feedback when you try out the 0.20.0! :)



elem said:
yesterday i changed the motor of my midrive from a 36v motor to a 48v motor, i bought only the motor because my midrive is adjusted to my bike, my first goal was to improve the q-factor tu use a 32T instead of the regular 42T ( stock ) and use a 11/40 K7 without loosing any gear, it s ok modifying the frame and adjusting the middrive hub .

next step will be testing the v 0.20 ( probably today after my morning ride )

here is my last test with V 0.19 using a 36V motor ( experimental mode activated ) and a 12S battery .
motor power limit : 550W, max curent 15A, curent ramp : 4.5
menu 9 ( advanced data )
2 ;ADC pedal torque sensor : 53 ( static ), 89 ( right pedal whit my weight=64 kg ), 86 ( left pedal with my weight )
3 ; pedal torque sensor : 0 to 170
6 ; PWN duty cycle : 0 to 270
7 ; motor speed in REPS : 0 to 670
8 ; FOC angle : 1/2/3 , depend spining

don t know if my comment will be usefull but i share it .

And thancks to everybody involved in the development of the open source firmware, it s amazing ;)

Thank you for such a detailed post and for helping improve the 0.20.0! That is great! :)

I look forward to you testing the 0.20.0 so you can later give impressions of the experience! eMTB will be improved so you can disregard that for now.
 
elfnino said:
buba said:
Clarification: If anyone likes how the eMTB mode works it is very similar to Torque Assist so give Torque Assist a try! If we had a sensitivity of zero on eMTB it would be just like Torque Assist and just a linear function. So if Torque Assist is setup properly the transition to eMTB will be completely natural but with more power! Please take time to configure and try this out.

After light testing of Torque Assist this is my first impression :
low Torque multiplier -> too weak assist when heavy pedal torque is applied (in steep uphill climb)
higher Torque multiplier -> too much assist when light pedal torque is applied (in sharp turn )

I guess the eMTB (exponential curve) just naturally compensates the torque sensor limits. Perhaps after the full sensor calibration the Torque Assist will be perfect.

Good feedback! I think that is largely due to the torque sensor having a small operating range for some users while others have a larger range. Will remember and consider this but you made a good point as to why the eMTB might be better!

Thank you! More news coming in the future!
 
elem said:
ok, 48V is clearly better for MTB, better respondive for slower human rpm .

soo before going to V 0.20 made somme test to compare with the 36V motor

For me it s not easy to change version, i have to open my lcd3 and put wires in holes for programming, never solder anything on it, nor openned a hoole/windows to acces programming port, it s why i was waiting for stable release, in fact was using only v 0.16 stable relase, never tested other versions .

Soo with my set up ( 550 w max, 15A max, 5 lvl assist : 0.2/0.4/0.8/1.2/2.1 )

standard motor ( 0 ) mode :
menu9 :
3 = more than 200
4 = stop at 90, average 86 rpm ( human cadence )
5 = nothing displayed nevermore
6 = 180 duty cycle max
7= 500 reps max

experimental mode ( 2 )
6 = 280 ( about the same of my "old " 36v motor with experimental mode )
7 = 680

soo experimental mode is working fine with 36 and 48 v motor .

Well i m reday to test V 0.20 this afternoon and seeing if torque mode is soo strong, it s what i m affraid off in fact, getting too much power could be dangerous in hard climbing rock .

have fun : https://vimeo.com/353996242 , https://vimeo.com/353968863

Good feedback on motor type! That is very valuable for users trying to decide what motor to buy.

I hope your tests with the 0.20.0 go well! The eMTB will be improved in the next Alpha coming tomorrow.
 
hello, have an issue with V0.20, suspected ancient value not cleared even if i writed all 00 before programming .

ok, motor stop at about 250w, like if street mode was activate, was testing torque mode, changed to power mode, it s the same .

trying to activate street mode with different value ( 35 km/h and 450 w max ) it s the same
trying to reset to defaut value, was impossible, a value of 42 was there and impossible to change ...

well, with my short test it s seem the start delay noticied in V 0.19 as gone

also tested in my garage the torque on pedal, it s different, you probably modified something ;)

in menu 11 ( previously 9 in v 0.19 )
2 torque sensor ADC : static 217, left and right with my weight ( 64 kg ) 340, dynamic ( pedaling ) hiting 320 wich is less than static and very different than V 0.19
3 pedal cadence hitting 125 max
4 PWN duty cycle : from 80 to 120( about )
5 ERPS hitting 360 ( about )

okay, i ll try to clear controler memory and reprogramm it .

in case of problm, is it possible to use V0.20.7 for LCD3 and for example V0.20.6 for controler ?
 
elem said:
hello, have an issue with V0.20, suspected ancient value not cleared even if i writed all 00 before programming .

Okay, everything is working as expected I just need to explain a couple of things :)

When you install the 0.20.0 it will load the default values, it will not be all zeros. Instead, the default values will be loaded and you can change those to whatever you want.


elem said:
ok, motor stop at about 250w, like if street mode was activate, was testing torque mode, changed to power mode, it s the same .

You need to set the motor power limit. Disregard the Street Mode and disable it for now. Just set the power limit to what you want it to be. It is in the Basic Setup sub menu.



elem said:
trying to activate street mode with different value ( 35 km/h and 450 w max ) it s the same
trying to reset to defaut value, was impossible, a value of 42 was there and impossible to change ...

Disable the Street Mode for now so you get comfortable with configuring the normal system. And later on it is no problem at all to enable Street Mode.

Please follow the instructions on the wiki on how to reset to defualt values. The system will not power down as it did previously. It will just smoothly set all values to default.




elem said:
well, with my short test it s seem the start delay noticied in V 0.19 as gone

I am glad to hear that! :) For MTB riding, Startup assist without pedal rotation is very good if you properly configure that. But maybe wait until you get comfortable with the 0.20.0.



elem said:
also tested in my garage the torque on pedal, it s different, you probably modified something ;)

in menu 11 ( previously 9 in v 0.19 )
2 torque sensor ADC : static 217, left and right with my weight ( 64 kg ) 340, dynamic ( pedaling ) hiting 320 wich is less than static and very different than V 0.19
3 pedal cadence hitting 125 max
4 PWN duty cycle : from 80 to 120( about )
5 ERPS hitting 360 ( about )

okay, i ll try to clear controler memory and reprogramm it .

in case of problm, is it possible to use V0.20.7 for LCD3 and for example V0.20.6 for controler ?

You can clear it but it will load the default values again. I think you thought the old values were there. I am pretty sure there are no bugs so you can use the Alpha 7 on both the motor controller and display.

So take a look at the wiki and I assure you everything will work! :)

https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/0.20.0-(DEVELOPMENT)-%7C-KT-LCD3-%7C-TSDZ2-%7C-Manual
 
Update on the eMTB sensitivity poll:

10.0 % uses sensitivity 1
10.0 % uses sensitivity 3
50.0 % uses sensitivity 4
10.0 % uses sensitivity 5
20.0 % uses sensitivity 6

Nice round numbers! But that is due to the fact that there are 10 users in total that have voted. Still, everyone is below sensitivity 7 so far.

I look very much forward to pushing out the new and improved eMTB! Thank you for all users that have voted and are still considering to do so! By voting I will have a very high confidence when scaling the next eMTB. This will enable everyone to pick a value that fits their style, setup, etc.

Will be away for today but be sure that as soon as I am back Alpha 8 will be prepared!
 
buba said:
elem said:
hello, have an issue with V0.20, suspected ancient value not cleared even if i writed all 00 before programming .

Okay, everything is working as expected I just need to explain a couple of things :)

When you install the 0.20.0 it will load the default values, it will not be all zeros. Instead, the default values will be loaded and you can change those to whatever you want.


elem said:
ok, motor stop at about 250w, like if street mode was activate, was testing torque mode, changed to power mode, it s the same .

You need to set the motor power limit. Disregard the Street Mode and disable it for now. Just set the power limit to what you want it to be. It is in the Basic Setup sub menu.



elem said:
trying to activate street mode with different value ( 35 km/h and 450 w max ) it s the same
trying to reset to defaut value, was impossible, a value of 42 was there and impossible to change ...

Disable the Street Mode for now so you get comfortable with configuring the normal system. And later on it is no problem at all to enable Street Mode.

Please follow the instructions on the wiki on how to reset to defualt values. The system will not power down as it did previously. It will just smoothly set all values to default.




elem said:
well, with my short test it s seem the start delay noticied in V 0.19 as gone

I am glad to hear that! :) For MTB riding, Startup assist without pedal rotation is very good if you properly configure that. But maybe wait until you get comfortable with the 0.20.0.



elem said:
also tested in my garage the torque on pedal, it s different, you probably modified something ;)

in menu 11 ( previously 9 in v 0.19 )
2 torque sensor ADC : static 217, left and right with my weight ( 64 kg ) 340, dynamic ( pedaling ) hiting 320 wich is less than static and very different than V 0.19
3 pedal cadence hitting 125 max
4 PWN duty cycle : from 80 to 120( about )
5 ERPS hitting 360 ( about )

okay, i ll try to clear controler memory and reprogramm it .

in case of problm, is it possible to use V0.20.7 for LCD3 and for example V0.20.6 for controler ?

You can clear it but it will load the default values again. I think you thought the old values were there. I am pretty sure there are no bugs so you can use the Alpha 7 on both the motor controller and display.

So take a look at the wiki and I assure you everything will work! :)

https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/0.20.0-(DEVELOPMENT)-%7C-KT-LCD3-%7C-TSDZ2-%7C-Manual


Ok, i was using V0.20 alpha 7 , the one for LCD3 and the one for TSDZ2, i know the standard process .
fact, it's seem the default value you used are good ;)
had only to change max power to 550 w ( my standard set up ), nomber of cells ( 12 ), max curent ( 15 )
eMTB configured to 3 ( instead of 2 from default value )

If you said alpha 7 work it s okay i thinck it s true

why i thinck there is some value from previous install ( v 0.19 ) is because when i came to power mode menu i found the same value i used in v 0.19 and i m pretty sure it s not your default value ( 0.3/0.6/0.9/1.5/2.1 this was my set up for different lvl in v 0.19 )

i just tried to clear my controleur ( may be not necessary, as i remenber you said it was the last time needed ! ) and reprogram it
sadly i have the same problem, and the same value for " reset default value " = 42, is it a timer to the reset ? haven t see it decrementing !?

Edit : sorry found the reason : Reset to default values. Enter the sub menu so that the number 42 starts blinking. Hold the POWER button a short amount of time and the system will reset to default values.

soo many things to learn :oops:

and also my own value from my previous install .

soo i thinck that it s some stored value in my LCD3 and i need to reprogramming it twice !?

sorry to disturb buba, all seems good when i was programming, no errors, nothing special, and i m using often my st link because i m also using marcoq code witch need to reprogram each time you want to improve a set up .
 
Ok made some short other tests .
reset factory default : was not working as expected, power button do nothing, but stoping the systeme, unpluging LCD3 and battery made the desired effect ...

made some test with default configuration ( after changing my battery set up and power goal : 15A max draw, 12 cells in serie, low cut off 34.8V, 140 ohm resistance battery ( default ), 550W max power, 50V reset wattmeter )

tested firstly with defautl motor configuration ( 0= 48v standard mode ) : motor regulate at about 250w hiting peack 300w but don t stop only regulate and power is fluctuating around 250 W .

tested secondly with experimental mode ( 2= 48v experimental ) : motor stop at about 250 w and you need to wait that human power goes down for the motor goes up, it s badly using standard mode .

his anybody experimenting this kind of problem ?

With V 0.19 48V exp mode was working fine, and it was easy for me to use full power avaiable with 550w set up i had sometimes 600W peack, without cut off motor, it was regulating itself around 550W .

Edit :
tested alpha 5 with power mode and torque mode, less power avaiable in torque mode, power mode hitting about 450w and regulating power at about 250w after a few seconds, same issues than with alpha 7, experimentale mode ( 2= 48V ) isn t useable .
planning to go back V 0.19 today morning .
may be mecanical issues in my system, i don t know anymore .
 
I'm sad to I can't try out 0.20, because before I got it flashed I cracked my LCD3 display (so I'm awaiting a new display. Worse I ordered a SW102, which isn't yet ported so I'll either have to wait or try to port myself).

In the meantime, when I first heard of the eMTB exponential multiplier I thought it was applied on top of Torque or Power proportional. I think I was wrong about that though - it's it's own mode.

However, couldn't / shouldn't it be just an filter on the other modes? It could just be a factor applied to the result (or the torque input). Assuming the loop can afford another multiplication operation? That way I could adjust assist level for how much I feel like contributing, but still get the responsive adaptive nature of the exponential curve.

Thanks as always for all the work devs - I'm loving what you're doing.
 
Just got things running on my small cargo bike with 0.19.0 and the 850C version 0.2.0 (just missed the update). I'm running a 52V battery on a 48V motor, singlespeed drive (42/16T). With mostly stock settings and a few adjustments everything is running quite well! I'm very happy with the responsiveness and power. I'll be shooting out a few paypal donations for the team working on the firmware, it is an impressive effort!

A few questions:
  • I can't change graphs on the 850C, and the SOC setting for "increment/decrement" always resets to "increment" on reboot. Are these issues addressed in the 0.3.0 update?
  • What is the timeline for merging the 850C branch with buba's updates to 0.20.0? Not rushing anyone, of course, just wondering if I should crack open the 850C and update to 0.3.0 now, or just wait until the merge.
 
phidauex said:
Just got things running on my small cargo bike with 0.19.0 and the 850C version 0.2.0 (just missed the update). I'm running a 52V battery on a 48V motor, singlespeed drive (42/16T). With mostly stock settings and a few adjustments everything is running quite well! I'm very happy with the responsiveness and power. I'll be shooting out a few paypal donations for the team working on the firmware, it is an impressive effort!

A few questions:
  • I can't change graphs on the 850C, and the SOC setting for "increment/decrement" always resets to "increment" on reboot. Are these issues addressed in the 0.3.0 update?
  • What is the timeline for merging the 850C branch with buba's updates to 0.20.0? Not rushing anyone, of course, just wondering if I should crack open the 850C and update to 0.3.0 now, or just wait until the merge.
Yes, V0.3.0 solve that 2 things you mention.
 
phidauex said:
  • What is the timeline for merging the 850C branch with buba's updates to 0.20.0? Not rushing anyone, of course, just wondering if I should crack open the 850C and update to 0.3.0 now, or just wait until the merge.

Not speaking for casainho, but for my part I need at least one week (possibly two if I slack off) before the 850C and SW102 will be running on a common codebase. I'd be in favor of not adding support for post 0.19 flavored motor controllers until after that date.

(But the good news is, we'll get support for those new motors in both the sw102 and the 850c - rather than having to do the changes twice)
 
Guys, just my perspective, but it wouldn't be cracking any 850c open... I expect to post info tonight or tomorrow for plug and play update... And casainho stated he would make the firmware changes required for easy updating... Took forever to get that sorted for the 850c... Was a real PITA for a dummy like me, haha.

Also working on that for the SW102... Gonna make it happen. Let's try not to crack these things open... is how I feel... We have almost reached the point where this will be easy and versatile for everyone. Plug and play/Bluetooth updates, big (850c) and small (sw102) display option, and widely available... Gonna get all the little bits stocked in a Chinese warehouse for cheap fast international shipped ng as well... You know I've been all for this since the beginning, and helped where I could... I think this is really all coming together in an awesome way at this point... Going for the trifecta.... Easy, cheap, and available!

Will be posting more ASAP
 
eyebyesickle said:
< lots of great stuff >

Sounds great. Also, in my dream world you can do a deal with the OEM to have a TSZD2 with correct connectors to just plug into a SW102. Also, if we set the options bits differently in the TSZD2, we can use the SW102 (or 850C) to update the motor firmware.

(Though the flash on the SW102 is a bit tight, so the user would have to briefly install a special "motor updater" SW102 load via bluetooth, then go back to the regular SW102 load)

Also it would be pretty easy to do cool things like "your ebike is locked if the paired phone is not in bluetooth range (or you can enter a special code to unlock it"). Certainly to the level that a not super technically clueful (i.e. willing to flash with an ST-LINK) thief will never get it working. Instead they just see a screen that says "reward if found call ..."
 
I already have the SW102 plug and play with the TSDZ2, no worries... I was recommending the SW102 for this about a year ago before interest picked up... Spent considerable time and resources developing stock Tsdz2 compatible firmware for it and everything ... So I have the bases pretty covered as far as that goes.

As for the rest .. I like what you're thinking!
 
geeksville said:
eyebyesickle said:
< lots of great stuff >

Sounds great. Also, in my dream world you can do a deal with the OEM to have a TSZD2 with correct connectors to just plug into a SW102. Also, if we set the options bits differently in the TSZD2, we can use the SW102 (or 850C) to update the motor firmware.

(Though the flash on the SW102 is a bit tight, so the user would have to briefly install a special "motor updater" SW102 load via bluetooth, then go back to the regular SW102 load)

Also it would be pretty easy to do cool things like "your ebike is locked if the paired phone is not in bluetooth range (or you can enter a special code to unlock it"). Certainly to the level that a not super technically clueful (i.e. willing to flash with an ST-LINK) thief will never get it working. Instead they just see a screen that says "reward if found call ..."
You have good plans, nice to hear about them. Thanks for all the work you do.
 
geeksville said:
Not speaking for casainho, but for my part I need at least one week (possibly two if I slack off) before the 850C and SW102 will be running on a common codebase. I'd be in favor of not adding support for post 0.19 flavored motor controllers until after that date.

Good news! I agree that the effort to put the common codebase together is worth a little delay - the SW102 sounds like a nice display as well and I'm impressed at the rate the development has gone for it.

eyebyesickle said:
Guys, just my perspective, but it wouldn't be cracking any 850c open... I expect to post info tonight or tomorrow for plug and play update... And casainho stated he would make the firmware changes required for easy updating... Took forever to get that sorted for the 850c... Was a real PITA for a dummy like me, haha.

Also working on that for the SW102... Gonna make it happen. Let's try not to crack these things open... is how I feel... We have almost reached the point where this will be easy and versatile for everyone. Plug and play/Bluetooth updates, big (850c) and small (sw102) display option, and widely available... Gonna get all the little bits stocked in a Chinese warehouse for cheap fast international shipped ng as well... You know I've been all for this since the beginning, and helped where I could... I think this is really all coming together in an awesome way at this point... Going for the trifecta.... Easy, cheap, and available

Even better! If the bootloader/OTA flashing situation is close to being solved them I'm all for it. I'm not opposed to soldering pins on and hacking it oldschool, but a "click to upgrade" solution would be great, and would open the modifications up for a lot more people. I'll hang tight with 0.2.0 and 0.19.0 as some of these great improvements come together.
 
Back
Top