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

[buba]

Hi Bubba

I gave 18.0 beta a 60 mile run today.

The good news is walk assist works a treat. I use 9 levels of pedal assist and to walk alongside the bike up a 33% climb I ended up selecting level 9 and bottom gear and it was faultless, really smooth constant speed (better than my BBSHD even) Plus I had two large panniers and a rear rack bag as well. You have done an excellent job on that.


The bad news is Cruise control. It works perfectly with a target speed set in the configuration menu, I settled on 12mph in the end and it cycled well between 11mph ish and 12mph, the default 15mph was fine too. But when I got adventurous and tried to test 'maintaining current speed' then after I pressed the down button it went straight to the previous 12mph setting and maintained 12mph with no button pressed. Fortunately I have the rear brake wired to cut out the motor and once I had slowed the bike below what must be the minimum speed for cruise control it came out of cruise control But as soon as I increased speed again the cruise control cut in again to maintain 12mph.Very scary and would have been very dangerous if I did not have the brake cut out as there was no quick way to stop the motor. In the end I had to switch the system off and back on and go into configuration to go back to target speed mode instead and continued the journey with no further issues in that mode. I don't know if it is practical but would it be possible to have an option to use the thumb throttle instead of cruise control?

Slightly bad news and may only affect a system using imperial miles. Function 7 wheel speed, 7.0 current, 7.1 average and 7.2 max display the MPH in the main field and kmph in the sub field and what ever function is selected it is displayed in the main field current speed display in all 8 display modes.

So really a big thumbs up for walk assist but cruise control has a serious bug in maintain current speed mode.


Hope that helps.

That helps a lot!

Regarding Cruise: that is very unexpected and strange but very good of you to report the bug. Have never ever stumbled on that when testing for over a week. Will be testing and trying to reproduce the problem tomorrow.

Will actually try to fix all reported bugs. So I have closed the current pull request and will send new pull request with the bug fixes.

Can not thank all enough for the constant feedback!

I recommend everyone that has installed beta 0.18.0 to disable Cruise for now and I will give updates as soon as possible. And please remember to have E-brakes when testing betas like this.

EDIT: I think I have solved all the reported bugs (LCD brightness, cruise, imperial units in sub menu 7). Am now ready to test everything. Will leave update within 24 hours.

(...) and what ever function is selected it is displayed in the main field current speed display in all 8 display modes.

It is implemented to work like that. If someone wants to track their average speed for instance it would always be displayed. But I take it as it is better to revert to current speed as soon as user leaves menu 7? This can definitely be changed to work differently in future versions if you and others think it is better to do so!

 

[Kisazul]

Hi casainho and buba! One of the main problems in the TSDZ2 motor is cadence, which is greatly reduced with a drop in battery voltage. One solution is to use 11S or 12S batteries for 36V and 14S for 48 volts. I want to share my opinion and find out the possibility of implementing constant cadence, which the user will choose in the menu. After all, if there is an opportunity to use experimental high cadence, then theoretically it is possible for each voltage level to increase its speed parameter in accordance with the voltage correspondence table when it falls. I understand that then the current will be a variable value and will increase with a voltage drop so as not to lose motor power.

 

[buba]

Great, good to know it is a simple fix.. very minor bug but worth to fix it :thumb:

Today I had the pleasure to test the firmware v.0.18 beta along 60 km with about 500m climb, it was the first trip with the OpenSource Firmware other than some around-the-house test.
I admit I had a very good feeling, a bit hard to recall all the functions in KT-LCD3 but at the end it is just matter to getting used to.
Once again, thanks to casainho and all the active developers down here.

I tried the cruise control as it is a new funcion of this beta, and it works quite good given the fact that it may be a bit difficult to hold the DOWN button for a while. I consider it a sort of "emergency mode" (e.g. broken pedal) so it is good to have the chance to use it if needed! :thumb:

Exactly!

I did not properly try the WALK assist as the climb was on asphalt road, anyway I had the impression that the power to the chain was quite quick and strong at startup, is there a power ramp to optimize perhaps? If I remember correctly the walk assist from marcoq version was smoother.

It is possible to implement a ramp up, absolutely! Just wanted to keep the code simple for now.

Now I would like to give a suggestion for a possible nice improvement: since you Buba developed a great experience on time and distance stuff on this motor, is it possible to implement a sort of "estimate distance left" indication?
I guess that all the needed data are already in place to do that, for instance I would use a sort of power_left variable (capacity - actual Wh consumed) and given the actual power from motor (W) you obtain the hours left. Multiply this value to the actual speed you obtain the left km before battery drains.

The actual power from the motor can be taken as moving average on the last 10s (in order not to have the results changing every second), updated every 5 s, and also the actual speed should be obtained from moving average on the same interval.

A pseudo code of what I have in mind is:
power_left := battery_capacity - Wh_consumed_since_last_charge
avg_motor_power := moving_average(actual_motorW, 10s) // calculated on the last 10 seconds or whatever is best
time_left := power_left / avg_motor_power // time left at this motor rate
avg_speed := moving_average(actual_speed, 10s) // average speed on the last 10 seconds or whatever is best
distance_left := avg_speed * time_left

The number can be shown in the SOC menu (n.2 if i remember correctly) or in a dedicated menu.

What do you thing about it? I think it is a nice feature to plan the assistance rate in order not to run out of battery specially in long trips .

Uh... quite a long post... i hope you manage to get to the end of it.

I did manage to get to the end of your post and it is a great suggestion. Will definitely keep this in mind for future pull requests!

 

[casainho]

Bottom line is: if you have the brake sensors connected make sure the contacts are open, otherwise the display will not start correctly.

LCD3 already shows error codes (but right now just 1 error code). Maybe Buba can improve the code on LCD3 to show an error code when brakes are active at start. Also another code for when throttle is active at startup. Also other code for when torque sensor is active at startup.

 

[thineight]

I did manage to get to the end of your post and it is a great suggestion. Will definitely keep this in mind for future pull requests!

Thanks Buba, rearding the estimation of distance left, it can be useful to have a user parameter to be set in the proper configuration menu to scale the calculations. I mean: if the algorithm calculates X and the user realizes that it is always overestimated (or underestimated) a value of 0.9 (or 1.1) can be multiplied to the result. This gives the flexibility to display always the correct numbers and, pending feedback from users, to improve the algorithm.

 

[markjiizs]

For me 18 beta cruise was working flawlessly, I never did the speed preset though. Didn't use too much because it was too cold to go without pedalling And the implementation of walk assist is really good as well, I am just thinking of putting parallel switch to down button to enable holding and wire some motorcycle style kill switch for the battery

 

[buba]

The bad news is Cruise control. It works perfectly with a target speed set in the configuration menu, I settled on 12mph in the end and it cycled well between 11mph ish and 12mph, the default 15mph was fine too. But when I got adventurous and tried to test 'maintaining current speed' then after I pressed the down button it went straight to the previous 12mph setting and maintained 12mph with no button pressed. Fortunately I have the rear brake wired to cut out the motor and once I had slowed the bike below what must be the minimum speed for cruise control it came out of cruise control But as soon as I increased speed again the cruise control cut in again to maintain 12mph.Very scary and would have been very dangerous if I did not have the brake cut out as there was no quick way to stop the motor. In the end I had to switch the system off and back on and go into configuration to go back to target speed mode instead and continued the journey with no further issues in that mode.

All reported bugs to date should be fixed in a new beta I have been working on for 0.18.0. But I could not reproduce the bug above in any way.

I still believe I know what the problem was in this case though. Very rarely, on very special situations and perhaps with special button combinations, the button events do not clear/reset. This would result in the bug you reported. Cruise seemingly worked as if you were holding down the DOWN button. So in a coming update this should be fixed as I have added the necessary "clear/reset" instructions for the buttons

 

[buba]

As some may know I have been working on fixing some reported bugs on the 0.18.0 beta 1. Wanted to share 0.18.0 beta 2 but there is a problem...

Okay... So the program memory on the STM8S105 is 32 kbytes (flash). Seems large enough? Well, we have now seemingly exceeded it with the 0.18.0 beta 2. The 0.18.0 beta 1 was cutting it really close as well.

Solution? Well, we could disable some functions and slim the code that way. I could remove the motor power menu (accessed with UP and ON/OFF button click on main screen) and put the max power configuration in the configuration menu. Have some more ideas of optimizing the code but do not know how big of a difference this will make.

We might be forced to end (finalize and clean up) development on the KT-LCD3 as there is no more program memory.

 

[Rafe]

As some may know I have been working on fixing some reported bugs on the 0.18.0 beta 1. Wanted to share 0.18.0 beta 2 but there is a problem...

Okay... So the program memory on the STM8S105 is 32 kbytes (flash). Seems large enough? Well we now have seemingly exceeded it with the 0.18.0 beta 2. The 0.18.0 beta 1 was cutting it really close as well.

Solution? Well, we could disable some functions and slim the code that way. I could remove the motor power menu (accessed with UP and ON/OFF button click on main screen) and put the max power configuration in the configuration menu. Have some more ideas of optimizing the code but do not know how big of a difference this will make.

We might be forced to end (finalize and clean up) development on the KT-LCD3 as there is no more program memory.

I agree with removing the motor power menu, besides not seeing the point of it as maximum current can be set anyway, it is far too easy to select the motor power menu by accident when wearing gloves. As it usually goes to 25 then after a long press of the on/off button to get back to the main menu the motor cuts out as 25 watts is too low for the motor to function, so myself I find it a real pain that is not needed anyway.

Fantastic that you have identified and fixed the bugs so soon Buba.

 

[casainho]

As some may know I have been working on fixing some reported bugs on the 0.18.0 beta 1. Wanted to share 0.18.0 beta 2 but there is a problem...

Okay... So the program memory on the STM8S105 is 32 kbytes (flash). Seems large enough? Well we now have seemingly exceeded it with the 0.18.0 beta 2. The 0.18.0 beta 1 was cutting it really close as well.

Solution? Well, we could disable some functions and slim the code that way. I could remove the motor power menu (accessed with UP and ON/OFF button click on main screen) and put the max power configuration in the configuration menu. Have some more ideas of optimizing the code but do not know how big of a difference this will make.

We might be forced to end (finalize and clean up) development on the KT-LCD3 as there is no more program memory.

Power menu should not be removed and in fact need to be improved: the main screen should fully work while we change max power.

Quick max power configuration is for a specific ride mode on montain biking.

 

[casainho]

Buba, The power ramp setup on LCD3, I was expecting that user would configure number of amps per second, just like the max current value configuration. Would be much easier for user to setup amps per second.

 

[buba]

Buba, The power ramp setup on LCD3, I was expecting that user would configure number of amps per second, just like the max current value configuration. Would be much easier for user to setup amps per second.

Yes, that will be in amps per second in the next pull request. Trying to optimize program memory now and when all is done you will have a new pull request.

 

[casainho]

Buba, The power ramp setup on LCD3, I was expecting that user would configure number of amps per second, just like the max current value configuration. Would be much easier for user to setup amps per second.

Yes, that will be in amps per second in the next pull request. Trying to optimize program memory now and when all is done you will have a new pull request.

Please note that I did merge to master your previous pull request.

Other thing I was expecting to implement was password at startup and a bit more complex/key combination to enter configuration menu.

Also I think the possibility to quick change temperature field to disable/motor temperature/battery soc, should be removed and user can configure only on configurations menu.

 

[buba]

Please note that I did merge to master your previous pull request.

Other thing I was expecting to implement was password at startup and a bit more complex/key combination to enter configuration menu.

Also I think the possibility to quick change temperature field to disable/motor temperature/battery soc, should be removed and user can configure only on configurations menu.

Thank you, Casainho!

Will look into that. The removal of quick-change temperature field would optimize program memory even more.

I have now succeeded in optimizing the firmware enough so that it can be uploaded to the KT-LCD3. Will test, submit pull request and also give a quick change log as usual!

 

[perryscope]

As some may know I have been working on fixing some reported bugs on the 0.18.0 beta 1. Wanted to share 0.18.0 beta 2 but there is a problem...

Okay... So the program memory on the STM8S105 is 32 kbytes (flash). Seems large enough? Well we now have seemingly exceeded it with the 0.18.0 beta 2. The 0.18.0 beta 1 was cutting it really close as well.

Solution? Well, we could disable some functions and slim the code that way. I could remove the motor power menu (accessed with UP and ON/OFF button click on main screen) and put the max power configuration in the configuration menu. Have some more ideas of optimizing the code but do not know how big of a difference this will make.

We might be forced to end (finalize and clean up) development on the KT-LCD3 as there is no more program memory.

Apologies if I am oversimplifying things as I am not an experienced programmer i'm just thinking of other ways that you might be able to optimise the code size other than removing functions.

I assume you compiling the code using SDCC? as it looks like this is may not be the most efficient compiler when it comes to the size of the file it generates? (but very good at creating 'fast' code) You can use the '--opt-code-size' argument in the makefile to optimize the size slightly but maybe its worth experimenting with other C compilers for the STM8 platform that claim to be much more efficient when it comes to the size of the hex file generated. http://www.colecovision.eu/stm8/compilers.shtml does a good comparison and the differences appear to be significant?

Just a thought and there may be very good reasons why this isn't possible that I don't understand, so feel free to tell me I'm talking rubbish if that's the case.

 

[Nick]

Hey Gals,

I faced some hurdles programming the open source software to the motor. LCD was flawless following the instructions on the wiki. But flashing the motor shows several errors and only with every like 10th try I was able to read the option bytes. I use a ST-LINK clone and short wires.
The solution was to plug the brown (VDD) wire to the 3.3V power (not to the 5V). This is reproducible, plug into 5V - No-Go - plug into 3V3 - works like a charm!

Please see the attached picture also.

Greetings
Nick

 

[Rydon]

Hey Gals,

I faced some hurdles programming the open source software to the motor. LCD was flawless following the instructions on the wiki. But flashing the motor shows several errors and only with every like 10th try I was able to read the option bytes. I use a ST-LINK clone and short wires.
The solution was to plug the brown (VDD) wire to the 3.3V power (not to the 5V). This is reproducible, plug into 5V - No-Go - plug into 3V3 - works like a charm!

I have seen similar intermittent behavior on the data tab as well. I will experiment with it. Have you tried disconnecting the voltage on the STLink and plugging the battery into the motor? I believe some of the developers do it that way for perhaps similar reasons.

 

[buba]

Tomorrow I will hopefully have time to test the changes listed below. Pull request will be submitted within 48 hours. As soon as it is reviewed by Casainho I think he will release the official v.0.18.0 beta X.

-----------------------------------------------------------------------------------------------------------
Changelog:

- Fixed bug that did not set the screen brightness until user toggles lights

- Improved screen brightness setup, now the user immediately sees the screen brightness during setup

- Fixed bug that did not show imperial units in the new Wheel Speed sub menu in the odometer field

- Implemented a more failproof cruise/walk assist

- Developed a better Main Screen Setup with more custom settings

- Removed the quick-change-temperature-field

- Optimized UART communication since 0.18.0 beta 1 and made overall improvements: faster and takes up less space

- Changed the motor acceleration to amps per second, more intuitive

- Implemented an enable/disable throttle toggle

- Some other smaller fixes
-----------------------------------------------------------------------------------------------------------

Thanks for all the input and help everybody!

 

[thineight]

- Optimized UART communication since 0.18.0 beta 1 and made overall improvements: faster and takes up less space

Thanks for all the input and help everybody!

Thanks to you for the prompt resolution of the issues.
Since the memory has come very close to its limit, do you think the "remaining distance estimation" field can be implemented in the remaining memory or definitely not?

 

[buba]

As some may know I have been working on fixing some reported bugs on the 0.18.0 beta 1. Wanted to share 0.18.0 beta 2 but there is a problem...

Okay... So the program memory on the STM8S105 is 32 kbytes (flash). Seems large enough? Well we now have seemingly exceeded it with the 0.18.0 beta 2. The 0.18.0 beta 1 was cutting it really close as well.

Solution? Well, we could disable some functions and slim the code that way. I could remove the motor power menu (accessed with UP and ON/OFF button click on main screen) and put the max power configuration in the configuration menu. Have some more ideas of optimizing the code but do not know how big of a difference this will make.

We might be forced to end (finalize and clean up) development on the KT-LCD3 as there is no more program memory.

Apologies if I am oversimplifying things as I am not an experienced programmer i'm just thinking of other ways that you might be able to optimise the code size other than removing functions.

I assume you compiling the code using SDCC? as it looks like this is may not be the most efficient compiler when it comes to the size of the file it generates? (but very good at creating 'fast' code) You can use the '--opt-code-size' argument in the makefile to optimize the size slightly but maybe its worth experimenting with other C compilers for the STM8 platform that claim to be much more efficient when it comes to the size of the hex file generated. http://www.colecovision.eu/stm8/compilers.shtml does a good comparison and the differences appear to be significant?

Just a thought and there may be very good reasons why this isn't possible that I don't understand, so feel free to tell me I'm talking rubbish if that's the case.

Do appreciate the time you took to write and give your thoughts! A very interesting comparison as well!

As you noted SDCC is very good at creating fast code and is one of the best compilers in that comparison. There are alternatives that could maybe change the size somewhat but I do not like to compromise in any way and would like to keep optimizing the code as much as possible. Removing a function is actually the last thing I would like to do and that will most likely never happen. The goal is to optimize and remove as much code as possible but still maintain the same functionality and readability.

There is a limit to this but maybe, just maybe, it will be possible to manage with the space left and we can consider the KT-LCD3 finalized. Would be exciting to see what can be done to the motor and controller thereafter!

We will have to see how things pan out in the coming days! Will be interesting either way!

- Optimized UART communication since 0.18.0 beta 1 and made overall improvements: faster and takes up less space

Thanks for all the input and help everybody!

Thanks to you for the prompt resolution of the issues.
Since the memory has come very close to its limit, do you think the "remaining distance estimation" field can be implemented in the remaining memory or definitely not?

It will be equivalent to fitting eight adults in a medium sized sedan. Not impossible but nonetheless a challenge! Will definitely try, thineight!

 

[casainho]

I would be nice if you could:

1. Change enter configuration menu to quick UP and DOWN + long UP and DOWN buttons. This would make less probably to enter this menu by mistake. Also the previous key combination could be then used to enter on off road mode or the ON/OFF + DOWN button (as I suggested before to free).

2. Remove specific menu for setup max power and instead implement the following code that I am using on Bafang 850C LCD -- I need this specific feature and I am using it like that, I think it is very good to be like that. And maybe to enter on this mode, could be long press of the buttons instead of regular press, to avoid enter by mistake as an user reported recently.

void power(void)
{
  static uint16_t ui16_battery_power_filtered_previous;
  uint32_t ui32_x1;
  uint32_t ui32_y1;
  uint32_t ui32_x2;
  uint32_t ui32_y2;
  static uint8_t ui8_target_max_battery_power_state = 0;
  uint16_t _ui16_battery_power_filtered;
  uint16_t ui16_target_max_power;

  static print_number_t power_number =
  {
    .font = &FONT_24X40,
    .fore_color = C_WHITE,
    .back_color = C_BLACK,
    .ui32_x_position = 200,
    .ui32_y_position = 219,
    .ui8_previous_digits_array = {255, 255, 255, 255, 255},
    .ui8_field_number_of_digits = 4,
    .ui8_left_zero_paddig = 0,
    .ui32_number = 0
  };

  if(lcd_vars.ui32_main_screen_draw_static_info)
  {
    UG_SetBackcolor(C_BLACK);
    UG_SetForecolor(C_GRAY);
    UG_FontSelect(&FONT_10X16);
    UG_PutString(238, 188, "Power");
  }

  if(!lcd_vars.ui8_lcd_menu_max_power)
  {
    _ui16_battery_power_filtered = ui16_battery_power_filtered;

    if((_ui16_battery_power_filtered != ui16_battery_power_filtered_previous) ||
        lcd_vars.ui32_main_screen_draw_static_info ||
        ui8_target_max_battery_power_state == 0)
    {
      ui16_battery_power_filtered_previous = _ui16_battery_power_filtered;
      ui8_target_max_battery_power_state = 1;

      if (_ui16_battery_power_filtered > 9999) { _ui16_battery_power_filtered = 9999; }

      power_number.ui32_number = _ui16_battery_power_filtered;
      lcd_print_number(&power_number);
    }
    else
    {

    }
  }
  else
  {
    // because this click envent can happens and will block the detection of button_onoff_long_click_event
    buttons_clear_onoff_click_event();

    // leave this menu with a button_onoff_long_click
    if(buttons_get_onoff_long_click_event())
    {
      buttons_clear_all_events();
      lcd_vars.ui8_lcd_menu_max_power = 0;
      ui8_target_max_battery_power_state = 0;

      // save the updated variables on EEPROM
      eeprom_write_variables();

      buttons_clear_all_events();
      return;
    }

    if(buttons_get_up_click_event())
    {
      buttons_clear_all_events();

      if(configuration_variables.ui8_target_max_battery_power < 10)
      {
        configuration_variables.ui8_target_max_battery_power++;
      }
      else
      {
        configuration_variables.ui8_target_max_battery_power += 2;
      }

      // limit to 100 * 25 = 2500 Watts
      if(configuration_variables.ui8_target_max_battery_power > 100) { configuration_variables.ui8_target_max_battery_power = 100; }
    }

    if(buttons_get_down_click_event ())
    {
      buttons_clear_all_events();

      if(configuration_variables.ui8_target_max_battery_power == 0)
      {

      }
      else if(configuration_variables.ui8_target_max_battery_power <= 10)
      {
        configuration_variables.ui8_target_max_battery_power--;
      }
      else
      {
        configuration_variables.ui8_target_max_battery_power -= 2;
      }
    }

    if(ui8_lcd_menu_flash_state)
    {
      if(ui8_target_max_battery_power_state == 1)
      {
        ui8_target_max_battery_power_state = 0;

        // clear area
        ui32_x1 = 200;
        ui32_y1 = 219;
        ui32_x2 = ui32_x1 + (5 * 24) + (5 * 24) + 1;
        ui32_y2 = ui32_y1 + 41;
        UG_FillFrame(ui32_x1, ui32_y1, ui32_x2, ui32_y2, C_BLACK);
      }
    }
    else
    {
      if(ui8_target_max_battery_power_state == 0)
      {
        ui8_target_max_battery_power_state = 1;

        ui16_target_max_power = configuration_variables.ui8_target_max_battery_power * 25;

        // clear area
        ui32_x1 = 200;
        ui32_y1 = 219;
        ui32_x2 = ui32_x1 + (4 * 24) + (4 * 24) + 1;
        ui32_y2 = ui32_y1 + 41;
        UG_FillFrame(ui32_x1, ui32_y1, ui32_x2, ui32_y2, C_BLACK);

        // draw number
        ui32_x1 = 200;
        ui32_y1 = 219;
        if(ui16_target_max_power >= 1000) {  }
        else if(ui16_target_max_power >= 100) { ui32_x1 += 24; }
        else if(ui16_target_max_power >= 10) { ui32_x1 += 48; }
        else { ui32_x1 += 72; }

        UG_SetForecolor(C_WHITE);
        UG_FontSelect(&FONT_24X40);
        UG_PutString(ui32_x1, ui32_y1, itoa((uint32_t) ui16_target_max_power));

        configuration_variables.ui8_target_max_battery_power = ui16_target_max_power / 25;
      }
    }
  }
}

Tomorrow I will hopefully have time to test the changes listed below. Pull request will be submitted within 48 hours. As soon as it is reviewed by Casainho I think he will release the official v.0.18.0 beta X.

-----------------------------------------------------------------------------------------------------------
Changelog:

- Fixed bug that did not set the screen brightness until user toggles lights

- Improved screen brightness setup, now the user immediately sees the screen brightness during setup

- Fixed bug that did not show imperial units in the new Wheel Speed sub menu in the odometer field

- Implemented a more failproof cruise/walk assist

- Developed a better Main Screen Setup with more custom settings

- Removed the quick-change-temperature-field

- Optimized UART communication since 0.18.0 beta 1 and made overall improvements: faster and takes up less space

- Changed the motor acceleration to amps per second, more intuitive

- Implemented an enable/disable throttle toggle

- Some other smaller fixes
-----------------------------------------------------------------------------------------------------------

Thanks for all the input and help everybody!

 

[Rafe]

Buba,
There is one thing have noticed in all recent firmwares but before you started doing your excellent mods that I have deliberately not mentioned so as to not cause confusion.

I always run with startup power boost enabled set to kick in when cadence/torque is zero and pedalling restarts. Mostly this works fine but every now and then when I start pedaling again there isn't any pedal assist at all for about three seconds and the assist when it does restart is normal assist not power boost. I've spent countless hours over long journeys trying to find a logic or sequence to this and so far it has escaped me. It usually comes to my attention on climbs as the incline levels off briefly and I stop pedalling for a few seconds and when I start pedalling again there is no assist and I'm under my own steam until it suddenly kicks in again. Sometimes the power boost is working perfectly for ages then suddenly it is not for a few restarts and then it is all working perfectly again.

It is left over from what we called 'the lag' which was worked on and if I recall correctly lasted longer and restarted in power boost mode and not normal assist as it does now. Perhaps your fresh eyes can find a solution?

Cheers

 

[thineight]

Thanks to you for the prompt resolution of the issues.
Since the memory has come very close to its limit, do you think the "remaining distance estimation" field can be implemented in the remaining memory or definitely not?

It will be equivalent to fitting eight adults in a medium sized sedan. Not impossible but nonetheless a challenge! Will definitely try, thineight!

I see.. good example. I do not have the clue how many bytes takes a function.
Just a suggestion, in case the memory is not enough. Perhaps the cruise control, being just a contingency measure, can be implemented differently in order to gain some space in memory.
Let me explain: I tried marcoq version earlier and on his walk assist setup I assigned to the last assistance level (4 in my case) a high ratio of walk ratio (90% if I recall well). Holding the DOWN button you can keep a reasonable speed (20 km/h) which is the target that should be ok for most users.
In such way you may delete the actual code keeping in the same time a function that pushes you in case you need to. In my personal opinion the cruise control you actually implemented is a nice to have feature but it can be removed with the above workaround.

 

[Nick]

Hey Gals,

I faced some hurdles programming the open source software to the motor...

I have seen similar intermittent behavior on the data tab as well...

I hardly can read any tab while powered with 5V. I never tried programming while battery powered. Such a high amperage supply just doesn't feel good and 3V3 works great and it is within the specs of the micro controller in use.
Maybe this is worth a hint in the wiki? I tear my hair out for several days while the solution was just a "wire plug" away

Greetings
Nick

 

[perryscope]

Are many people running the LM35 Temperature sensors in their motors?

I have read the wiki section https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/How-to-install-motor-temperature-sensor on this and purchased a sensor ( the first 10 i bought cheap and turned out to be NPN transistors!.
So I purchased what I think is a legit Texas Instruments LM35 from a UK supplier and have done some testing on the bench and well the results are somewhat off?
I tested at 20-90 deg C using my 3D printer heater bed which can be set to a stable temperature, left at each temperature for 5 min to stabilise and cross-referenced with an IR thermometer. But at the higher temperatures, I am almost 20°C out assuming a 10mV per °C reading???


View attachment 1

Does this just sound like Chinese clone that's highly inaccurate at the higher temperatures or is this normal and accounted for in the code? I guess I could just set the temperature limits lower but seems way out to me.