KT motor controllers -- Flexible OpenSource firmware for BMSBattery S/Kunteng KT motor controllers (0.25kW up to 5kW)

I'll try...

Should be attached.
 

Attachments

  • scrnsht.png
    scrnsht.png
    33.5 KB · Views: 1,916
geofft said:
Ok, thanks.

One thing I noticed in the config.h file - I had to change the pas direction (3rd line from the end) and noticed in the default option the word 'RIGHT' was misspelt. Probably of no consequence but thought I'd mention in case it was a significant tag.
The window is now a little shorter and also realizable, should work of for you. Please give feedback.

I was looking to the sources and it is written as "PAS_DIRECTION_RIGHT". All seems ok for me - can you please clarify?? as wrong name will probably make a wrong result...
 
Now, there is no scrollbar any more with windows, you can only scroll down with the mousewheel. With no external mouse, you can't scroll at all... As I mentioned before, I would prefer a GUI, where you don't have to scroll at all, thats much more overseeable.
And as before, the write configuration button is cut at the bottom a little, see screenshot.

regards
stancecoke

Configuration Tool.PNG
 
geofft wrote: ↑01 Jan 2018, 16:48
Ok, thanks.

One thing I noticed in the config.h file - I had to change the pas direction (3rd line from the end) and noticed in the default option the word 'RIGHT' was misspelt. Probably of no consequence but thought I'd mention in case it was a significant tag.
The window is now a little shorter and also realizable, should work of for you. Please give feedback.

I was looking to the sources and it is written as "PAS_DIRECTION_RIGHT". All seems ok for me - can you please clarify?? as wrong name will probably make a wrong result...
I now realise the error lies not in the new configuration_tool.jar but in the 'OSEC_Parameter_Configurator.jar' file in the 'firmware' folder. If you select Pas direction 'Right' it misspells it in the config.h file as 'PAS_DIRECTION_RIGTH'. Sorry about the misinformation.

Will try the updated configuration tool soon, but it seems that stancecoke still has some issues with that.....?

Edit: As stancecoke says, can't scroll at all now with laptop.... :(
 
I fixed the typo in the "old" C#ROME-B tool ('OSEC_Parameter_Configurator.jar').
It should still work and needs no scrolling...

regards
stancecoke
 
geofft said:
geofft wrote: ↑01 Jan 2018, 16:48
Edit: As stancecoke says, can't scroll at all now with laptop.... :(

I've since discovered that if you maximize the window the scroll bar is enabled, which means I can now scroll to the very bottom ok. It's not exactly right, but good enough for now.
 
My replacement controller arrived today, so after much wrestling with the software eventually managed to get the firmware downloaded and ventured out in the current stormy weather to give it a try.

Initial findings are very positive, the pas works progressively and smoothly, also the throttle blends in with pas quite nicely. This is one area where the stock firmware was less than perfect, the added throttle being rather 'all or nothing' with little progression. Out on the road the motor ran quietly with no noticeable jumps or hiccups.

As you'd expect with any project like this there are a few rough edges and minor issues that probably need some attention. I don't know if you guys are looking for more feedback but I'll list some of the more obvious issues. This is with my hardware as shown in my bottom signature line below, 'Throttle/pas' input and 'Current/Speed' control mode.

1) The bike does not like being pushed in reverse - it's ok for about a metre or so but then the motor resists and at times will actively drive the bike forwards quite forcibly. This could create some dangerous situations and needs some attention.

2) PAS doesn't seem to respond to changing power levels (0-5), and generally feels rather overdriven at the lower settings. Tried reducing level 1 to 10% which didn't help and even at level 0 (which presumably should be no assist) I was getting a strong amount of pas drive.

3) With PWM control selected throttle worked ok but there was no response to pas input.

4) The LCD3 wattmeter seemed to have a mind of it's own, drifting around a lot, showing a small draw at idle and often showing a draw under pas or throttle of up to 2000w. This would roughly equate to a current of 40amps which I'm pretty sure wasn't actually happening. The controller was significantly warm after my 3km test ride however, certainly more so that the stock firmware which ran barely lukewarm at all times.

.,...which all sounds rather critical but don't be discouraged, my overall impression was very favourable and with a little 'tweaking' this could make a viable alternative to the stock Kunteng firmware.

If you need any more info or want something trying out on the road let me know, should have some time towards the weekend - weather permitting.... :)
 
Thank you for your feedback!
geofft said:
1) The bike does not like being pushed in reverse - it's ok for about a metre or so but then the motor resists and at times will actively drive the bike forwards quite forcibly. This could create some dangerous situations and needs some attention.
The direction detection is known to be a kind of tricky, so we have to improve the algorithm...

geofft said:
2) PAS doesn't seem to respond to changing power levels (0-5), and generally feels rather overdriven at the lower settings. Tried reducing level 1 to 10% which didn't help and even at level 0 (which presumably should be no assist) I was getting a strong amount of pas drive.
Seems, that the communication from the display to the controller doesn't work properly. Perhaps the display uses a different checksum again. Two possibilies: Disable the check of the checksum in the controller code, or log the bytes, sent from the display and analyze the used byte pattern. You'll need a UART to USB converter for this.
We should improve the code: Sending Data from the controller to the display only if a valid message from the display was received. When we get no speed information on the display, we definitly know, that there's something wrong with the received messages.

geofft said:
4) The LCD3 wattmeter seemed to have a mind of it's own, drifting around a lot, showing a small draw at idle and often showing a draw under pas or throttle of up to 2000w. This would roughly equate to a current of 40amps which I'm pretty sure wasn't actually happening. The controller was significantly warm after my 3km test ride however, certainly more so that the stock firmware which ran barely lukewarm at all times.
What was your setting for max motor current? Perhaps the control loop swings up. Perhaps we should use an averaged value for the display.

regards
stancecoke
 
geofft said:
My replacement controller arrived today, so after much wrestling with the software eventually managed to get the firmware downloaded and ventured out in the current stormy weather to give it a try.

Initial findings are very positive, the pas works progressively and smoothly, also the throttle blends in with pas quite nicely. This is one area where the stock firmware was less than perfect, the added throttle being rather 'all or nothing' with little progression. Out on the road the motor ran quietly with no noticeable jumps or hiccups.
The feedback is really important, I was waiting for it from your experience :)

This is with my hardware as shown in my bottom signature line below, 'Throttle/pas' input and 'Current/Speed' control mode.
Please see that you need to use P3 = 0 to have current AND speed control, with P3 = 1, you will have only current control.

1. Ok, the PWM is always active even if throttle (type) value = 0 and the motor should block because of that. Maybe we can disable when wheel speed = 0 and throttle = 0.
Driving the motor forward may be an issue, because it will detect motor speed... well, looking for throttle = 0 condition may avoid this issue.

2. That is strange because looking at the code:
Code:
ui8_temp = ui8_max (ui8_throttle_value_filtered, ui8_temp); // use the max value from throotle or pas cadence
And just after ui8_temp is multiplied by ui8_assist_level...
Also I do remember to test this... can you please test, with your wheel on the hair and P3 = 0, so you should get speed control linear to PAS cadence:
Code:
  // if LCD P3 = 0, control also the speed
  if (lcd_configuration_variables.ui8_power_assist_control_mode)
  {
    // set target motor speed to the value defined on the LCD
    // (due to motor configurations on the motor controller, this will only put a limit to the max permited speed!)
    motor_controller_set_target_speed_erps (motor_controller_get_target_speed_erps_max ());
  }
  else
  {
    // PAS cadence will setup motor speed
    // map PAS candence value to motor speed value
    ui16_target_speed_erps = (uint16_t) (map ((uint32_t) f_temp,
		  (uint32_t) 0,
		  (uint32_t) 255,
		  (uint32_t) 0, // motor speed min value
		  (uint32_t) motor_controller_get_target_speed_erps_max ())); // motor speed from max value, defined on the LCD
    motor_controller_set_target_speed_erps (ui16_target_speed_erps);
  }

3. You are correct, the implementation is the following (you can see at void ebike_throotle_type_throotle_pas (void) in ebike_app.c file). The idea of direct PWM was only throttle, mainly for development... do you want to use it?? If yes, I can add also PAS control to that.
Code:
  f_temp = (float) (((float) ui8_throttle_value_filtered) * f_temp);
  ui8_temp = (uint8_t) (map ((uint32_t) f_temp,
  			 (uint32_t) 0,
  			 (uint32_t) 255,
  			 (uint32_t) 0,
  			 (uint32_t) PWM_DUTY_CYCLE_MAX));
  ui8_pwm_duty_cycle_duty_cycle_controller = ui8_temp;

4. Yes, now I remember that I have the same issue about bad current readings on the LCD. I have LCD3 installed on my direct drive motor ebike and I am not using it right now so I forgot that issue.

About controller to be significantly warm, I think this can happen because:
1. your FOC_READ_ID_CURRENT_ANGLE_ADJUST value is not good and the controller is "giving" more battery power to the motor than what original firmware... I guess the motor would also get warmer on this case
2. the PWM scheme used is different from the original firmware and for what I did read, the original may have less 30% wasted energy on the PWM commutations and meaning maybe 30% warmer on our firmware

I don't really know if 2. cause a big impact. With my tests, I never go the controller to hot (S06S or S12S) but yes, I think with original firmware is less hot. About efficiency, stancecoke did test before and it seems very good, at least as the original firmware if not better.
 
casainho said:
the original may have less 30% wasted energy on the PWM commutations and meaning maybe 30% warmer on our firmware
Do you have some literature on this topic? I want to understand that!

regards
stancecoke
 
stancecoke said:
Thank you for your feedback!
geofft said:
1) The bike does not like being pushed in reverse - it's ok for about a metre or so but then the motor resists and at times will actively drive the bike forwards quite forcibly. This could create some dangerous situations and needs some attention.
The direction detection is known to be a kind of tricky, so we have to improve the algorithm...
Seems we both wrote a message at the same time :)
I would like to understand what you mean, what you think may be happening so I can try to improve this. Please look at my answer.

stancecoke said:
geofft said:
2) PAS doesn't seem to respond to changing power levels (0-5), and generally feels rather overdriven at the lower settings. Tried reducing level 1 to 10% which didn't help and even at level 0 (which presumably should be no assist) I was getting a strong amount of pas drive.
Seems, that the communication from the display to the controller doesn't work properly. Perhaps the display uses a different checksum again. Two possibilies: Disable the check of the checksum in the controller code, or log the bytes, sent from the display and analyze the used byte pattern. You'll need a UART to USB converter for this.
For start, I think will be easier for geoff to test also with throttle. The LCD assist value scale both throttle and PAS cadence.
And you may be correct, if the checksum is incorrect, that issue will happen: no communication from the LCD to controller firmware. geoff can also try change the wheel max speed on the LCD and use P3 = 0 and throttle and see if the speed limit will apply... -- note that if LCD is not communicating, the default wheel max speed is 25km/h.
Geoff, the default values if LCD is not communicating:
Code:
// *************************************************************************** //
// EEPROM memory variables default values
#define DEFAULT_VALUE_ASSIST_LEVEL 		2
#define DEFAULT_VALUE_MOTOR_CHARACTARISTIC 	202 // for Q85 motor (12.6 * 16)
#define DEFAULT_VALUE_WHEEL_SIZE	 	20 // 26''
#define DEFAULT_VALUE_MAX_SPEED	 		25
#define DEFAULT_VALUE_POWER_ASSIST_CONTROL_MODE 1
#define DEFAULT_VALUE_CONTROLLER_MAX_CURRENT	10

stancecoke said:
geofft said:
4) The LCD3 wattmeter seemed to have a mind of it's own, drifting around a lot, showing a small draw at idle and often showing a draw under pas or throttle of up to 2000w. This would roughly equate to a current of 40amps which I'm pretty sure wasn't actually happening. The controller was significantly warm after my 3km test ride however, certainly more so that the stock firmware which ran barely lukewarm at all times.
What was your setting for max motor current? Perhaps the control loop swings up. Or like #2, there might be a problem with the serial communication.
Hmmm, I bet it is a bug on the firmware. Since the communication sued the CRC, I think would be difficult for error on the communication data. That is why we (developers) need to log in real time this values during a test ride...
 
casainho said:
I would like to understand what you mean, what you think may be happening so I can try to improve this. Please look at my answer.

In the "Forumscontroller-" code it is solved by checking the ratio of the PAS_High_counter to the PAS_Low_counter:

Code:
#ifdef SUPPORT_PAS
void pas_change()       //Are we pedaling? PAS Sensor Change------------------------------------------------------------------------------------------------------------------
{
    if (last_pas_event>(millis()-10)) return;
    boolean pas_stat=digitalRead(pas_in);
    if (pas_stat)
    {
        pas_off_time=millis()-last_pas_event;
#if defined(SUPPORT_XCELL_RT) || defined(SUPPORT_SEMPU_V1) || defined(SUPPORT_SEMPU)
        if (analogRead_in_use)
          torque_want_calculation = true;
        else
          read_current_torque();
#endif
    }
    else
    {pas_on_time=millis()-last_pas_event;}
    last_pas_event = millis();
    cad=pas_time/(pas_on_time+pas_off_time);
    
    #ifdef SUPPORT_SEMPU_V1
      pedaling=bitRead(PINE,6); //read direction pin of pas sensor and set pedaling to true
    #else
      pas_failtime=pas_failtime+1;
      double pas_factor=(double)pas_on_time/(double)pas_off_time;
      if ((pas_factor>pas_factor_min)&&(pas_factor<pas_factor_max))
      {
          pedaling=true;
          pas_failtime=0;
      }
    #endif
}
#else
#warning PAS sensor support is required for legal operation of a Pedelec  by EU-wide laws except Austria or Swiss.
#endif

The valid range of the ratio is defined in the configuration tool. The range can be found by a "testing-mode" where the ratio is shown in the "live data view" in realtime.
index.php


In the original firmware, the parameter C1 is used to set the PAS characteristic, see page 22.

Can you please recheck my first answer, I had some "new" ideas.

Thanks
stancecoke
 
Thanks guys, I need to do my best to understand your responses, do some more tests and get back to you. Please bear in mind that my previous coding experience ended with BASIC back in the late 70's,- early 80's and I will struggle to follow the code you are using for this project. Maybe time for me to go back to school...

Things I can answer quickly now:- Motor current limit was 20a (set to 40 in config.h). I've just checked, my P3 was set to 1 so I need to redo some tests. Whilst checking this at standstill in my garage the motor wattage apparently was 321W.... :?

I notice you say that the power levels (0-5) also scale throttle by the same ratio. I think you'll find that most people who ride pas/throttle in combination prefer to have 100% throttle available at all times and I think the stock firmware is set that way. Is that possible..or maybe offered as an option in the user config?

I'll get back with the other information as soon as I can, but this may take a couple of days.

Geoff.
 
geofft said:
Thanks guys, I need to do my best to understand your responses, do some more tests and get back to you. Please bear in mind that my previous coding experience ended with BASIC back in the late 70's,- early 80's and I will struggle to follow the code you are using for this project. Maybe time for me to go back to school...

Things I can answer quickly now:- Motor current limit was 20a (set to 40 in config.h). I've just checked, my P3 was set to 1 so I need to redo some tests. Whilst checking this at standstill in my garage the motor wattage apparently was 321W.... :?

I notice you say that the power levels (0-5) also scale throttle by the same ratio. I think you'll find that most people who ride pas/throttle in combination prefer to have 100% throttle available at all times and I think the stock firmware is set that way. Is that possible..or maybe offered as an option in the user config?

I'll get back with the other information as soon as I can, but this may take a couple of days.

Geoff.
So, first, I added that option to firmware:
Code:
// in the case of EBIKE_THROTTLE_TYPE = EBIKE_THROTTLE_TYPE_THROTTLE_PAS, LCD assist level will apply only to PAS
#define EBIKE_THROTTLE_TYPE_THROTTLE_PAS_ASSIST_LEVEL_PAS_ONLY
You can verify the small changes I did here -- I didn't test but the firmware did built.

Before being worried about that lack of efficiency with the motor, try first understand if the LCD is working (from LCD --> firmware). You will not be able to set P3 value if LCD is not working. Well, you can if you go to main.h and change the default value of:
Code:
#define DEFAULT_VALUE_POWER_ASSIST_CONTROL_MODE 1

If your motor runs well but it is asking to much current with wheel on the air, like 321W (I = 321/48 = 6.7A), try adjust FOC_READ_ID_CURRENT_ANGLE_ADJUST value but like at throttle half or quarter value, not at max value (but in the end, compare also current with max value of throttle).
NOTE: my Q85 328RPM motor, at 30V, uses about 1.8A at max speed of ERPM = 520 (that gives wheel speed of 30 km/h). The firmware limits the ERPM to 520, so you will compare the same max speed as me.
 
stancecoke said:
We should improve the code: Sending Data from the controller to the display only if a valid message from the display was received. When we get no speed information on the display, we definitly know, that there's something wrong with the received messages.
That sounds a good idea but at the same time, not good in a way that user will not understand if LCD is working or not at all and can be a wiring problem. This way, at least we can see wiring may be good.
If the motor runs, it is easy to test LCD by changing the assist level and see the result on the motor speed.
 
stancecoke said:
casainho said:
the original may have less 30% wasted energy on the PWM commutations and meaning maybe 30% warmer on our firmware
Do you have some literature on this topic? I want to understand that!
http://www.ccs.asia.edu.tw/ezfiles/2/1002/img/442/0703-21.pdf
We are using top but original firmwares uses bottom:


Oiriginal PWM scheme: https://opensourceebikefirmware.bitbucket.io/development/Motor_controllers--BMSBattery_S_series--BMSBattery_S06S--PWM_signals--low_speed_up_to_max_speed_-_sineware.html
Our PWM scheme: https://eggelectricunicycle.bitbucket.io/MicroWorks_30B4_board--firmware_motor_control.html
 
stancecoke said:
casainho said:
I would like to understand what you mean, what you think may be happening so I can try to improve this. Please look at my answer.
In the "Forumscontroller-" code it is solved by checking the ratio of the PAS_High_counter to the PAS_Low_counter:
Maybe you misunderstood the information (or it was me).

I think geofft want to say pushing by hand the bike -- (and on this situation, will regen and that is why it may for some reason drive motor forward at sometimes, because regen control will change PWM duty_cycle...)

The current PAS code seems to work well for me, it detects well when rotating pedals backwards and outputs ui8_pas_cadence_rpm = 0 on that case.
 
@casainho: There was a post with several questions in the german forum.

especially the things concerning the LCD3 I don't know exactly. Perhaps you can help.

Translation by deepl.com:
What settings and displays are not available on the LCD3?
Where is the speed limit set? Display?
Is the speed signal determined via the external speed sensor and thus also the speed limit is maintained? The S06SC (Central Motor) is currently available for mid-engine applications.
Cheat time? If I need this, can I leave it out? What do I have to set, according to the instructions it doesn't work yet)
Leave engine type? open for new engine selection?
Torque sensor mode? What do I have to select for the known current level control?
How and where is the original Yamaha torque sensor connected?
What about the standard functions:
Low-voltage protection 30/40V (switching off the controller when the battery voltage falls below this level)
Overcurrent protection
Overtemperature protection - Output short-circuit protection (motor phases)

regards
stancecoke
 
stancecoke said:
Translation by deepl.com:
What settings and displays are not available on the LCD3?
Where is the speed limit set? Display?
Is the speed signal determined via the external speed sensor and thus also the speed limit is maintained? The S06SC (Central Motor) is currently available for mid-engine applications.
Cheat time? If I need this, can I leave it out? What do I have to set, according to the instructions it doesn't work yet)
Leave engine type? open for new engine selection?
Torque sensor mode? What do I have to select for the known current level control?
How and where is the original Yamaha torque sensor connected?
What about the standard functions:
Low-voltage protection 30/40V (switching off the controller when the battery voltage falls below this level)
Overcurrent protection
Overtemperature protection - Output short-circuit protection (motor phases)
LCD can change:
- assist level
- max wheel speed
- P3: Power Assist Control Mode

Speed limit is for wheel speed. The external sensor is supported and when it is not connected, motor speed will be used instead.
There is no cheat time implementation, yet.
There is no engine type option.

Low voltage protection is implemented but currently, we can select only 24, 36 or 48V that are the most common battery voltages. Other values can be implemented quickly -- I can do that if the user explains why he needs that, I want to know the user case.

Overcurrent protection works, for the value the user selects when configuring the firmware.

Overtemperature of what? motor or controller?

Shortcircuit is implemented by the motor overcurrent.
 
Thanks!
The controller temperature was meant. Is there an internal temperature sensor on the PCB? I can't find one in the schematic.

regards
stancecoke
 
stancecoke said:
Thanks!
The controller temperature was meant. Is there an internal temperature sensor on the PCB? I can't find one in the schematic.
I think this controllers don't have temperature sensor. Maybe they are developed to withstand mempeax temperature, for the max current over a large period of time and at an higher ambient temperature.
 
Spent an hour in the garage earlier with the bike up on a test stand and can now give you some more information on the problems i had with my previous test ride.

1) The bike does not like being pushed in reverse - it's ok for about a metre or so but then the motor resists and at times will actively drive the bike forwards quite forcibly. This could create some dangerous situations and needs some attention.

....this is definitely being caused by reverse pas being mis-interpreted by the firmware. If I reverse pedal fairly quickly all is well, but if I reverse pedal very slowly (as would happen pushing the bike backwards) the motor gives strong drive pulses. A short video here:-https://www.youtube.com/watch?v=2ZvIl2bwB7Y
...so it seems the pas detection needs a little more work..?

2) PAS doesn't seem to respond to changing power levels (0-5), and generally feels rather overdriven at the lower settings. Tried reducing level 1 to 10% which didn't help and even at level 0 (which presumably should be no assist) I was getting a strong amount of pas drive.

...as suggested this looks to be a communication problem between the display and controller. I tested this by setting a reduced max speed in the display but the controller would not respond to this and would always throttle or pas to the motor maximum (33kph on my setup). Same goes for assist levels I guess, changing these seems to have no effect on motor output. Just to check, I did reconnect the stock controller afterwards, this responded correctly to these display settings, so my hardware looks ok.

3) With PWM control selected throttle worked ok but there was no response to pas input.

....I only mentioned this out of interest, I will have no use for this facility, so it's a non-issue really, forget it.

4) The LCD3 wattmeter seemed to have a mind of it's own, drifting around a lot,

...I guess this is related to the communication issue mentioned above..?

If you need any further info or something tested just let me know.
 
geofft said:
....this is definitely being caused by reverse pas being mis-interpreted by the firmware. If I reverse pedal fairly quickly all is well, but if I reverse pedal very slowly (as would happen pushing the bike backwards) the motor gives strong drive pulses. A short video here:-https://www.youtube.com/watch?v=2ZvIl2bwB7Y
...so it seems the pas detection needs a little more work..?
Ok, so I did misunderstood before. Thank you for the video and your testing, it helps me a lot to understand the issue and I hope to get it resolved in 2 days.

geofft said:
...as suggested this looks to be a communication problem between the display and controller. I tested this by setting a reduced max speed in the display but the controller would not respond to this and would always throttle or pas to the motor maximum (33kph on my setup). Same goes for assist levels I guess, changing these seems to have no effect on motor output. Just to check, I did reconnect the stock controller afterwards, this responded correctly to these display settings, so my hardware looks ok.
So, I found that even the same LCD have a different value "key" to verify the package data that is sent from the controller firmware to LCD and the code to verify is here (ebike_app.c):
Code:
  /********************************************************************************************/
  // Process received package from the LCD
  //

  // see if we have a received package to be processed
  if (ui8_received_package_flag)
  {
    // validation of the package data
    ui8_crc = 0;
    for (ui8_i = 0; ui8_i <= 12; ui8_i++)
    {
      if (ui8_i == 7) continue; // don't xor B5 (B7 in our case)
      ui8_crc ^= ui8_rx_buffer[ui8_i];
    }

    // see if CRC is ok
    if (((ui8_crc ^ 10) == ui8_rx_buffer [7]) 	|| // some versions of CRC LCD5 (??)
	((ui8_crc ^ 9) == ui8_rx_buffer [7]) 	|| // CRC LCD5
	((ui8_crc ^ 2) == ui8_rx_buffer [7])) 	   // CRC LCD3
    {
The key is the ui8_crc ^ x, where values of 10, 9 and 2 works. If you send me your LCD3, I can try different values up to get it working but maybe would be more efficient if you could try by yourself -- you would need to changes, let's say that ui8_crc ^ 10 starting like from 0 up to 8 (2 is already on the firmware, no need to test). Maybe you will find it is value 3 that works for your LCD and then I would add that value to the firmware.

geofft said:
4) The LCD3 wattmeter seemed to have a mind of it's own, drifting around a lot,

...I guess this is related to the communication issue mentioned above..?

If you need any further info or something tested just let me know.
Thanks but it is not needed as I can replicate that issue (it happens to me also), I should look at it in 1 week or more, as I need a good weather to test it. And I think it is not related to communications, because it goes with the same package as all the data that goes from controller firmware to LCD, and things like speed or throttle and brakes indications works well.
 
geofft said:
...so it seems the pas detection needs a little more work..?
What is the value for your PAS_NUMBER_MAGNETS??
 
The key is the ui8_crc ^ x, where values of 10, 9 and 2 works. If you send me your LCD3, I can try different values up to get it working but maybe would be more efficient if you could try by yourself -- you would need to changes, let's say that ui8_crc ^ 10 starting like from 0 up to 8 (2 is already on the firmware, no need to test). Maybe you will find it is value 3 that works for your LCD and then I would add that value to the firmware.

...Ok, I can see that line in the code, should be no problem for me to try the other 'keys'. Hope to do this later today or tomorrow.

My PAS sensor has 10 magnets.
 
Back
Top