The window is now a little shorter and also realizable, should work of for you. Please give feedback.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.
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.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...
geofft said:geofft wrote: ↑01 Jan 2018, 16:48
Edit: As stancecoke says, can't scroll at all now with laptop....![]()
The direction detection is known to be a kind of tricky, so we have to improve the algorithm...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.
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.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.
What was your setting for max motor current? Perhaps the control loop swings up. Perhaps we should use an averaged value for the display.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.
The feedback is really important, I was waiting for it from your experiencegeofft 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.
Please see that you need to use P3 = 0 to have current AND speed control, with P3 = 1, you will have only current control.This is with my hardware as shown in my bottom signature line below, 'Throttle/pas' input and 'Current/Speed' control mode.
ui8_temp = ui8_max (ui8_throttle_value_filtered, ui8_temp); // use the max value from throotle or pas cadence
// 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);
}
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;
Do you have some literature on this topic? I want to understand that!casainho said:the original may have less 30% wasted energy on the PWM commutations and meaning maybe 30% warmer on our firmware
Seems we both wrote a message at the same timestancecoke said:Thank you for your feedback!
The direction detection is known to be a kind of tricky, so we have to improve the algorithm...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.
For start, I think will be easier for geoff to test also with throttle. The LCD assist value scale both throttle and PAS cadence.stancecoke said: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.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.
// *************************************************************************** //
// 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
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...stancecoke said: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.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.
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.
#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
So, first, I added that option to firmware: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.
// 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
#define DEFAULT_VALUE_POWER_ASSIST_CONTROL_MODE 1
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.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.
http://www.ccs.asia.edu.tw/ezfiles/2/1002/img/442/0703-21.pdfstancecoke said:Do you have some literature on this topic? I want to understand that!casainho said:the original may have less 30% wasted energy on the PWM commutations and meaning maybe 30% warmer on our firmware
Maybe you misunderstood the information (or it was me).stancecoke said:In the "Forumscontroller-" code it is solved by checking the ratio of the PAS_High_counter to the PAS_Low_counter: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.
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: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)
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.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.
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,
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:....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..?
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):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.
/********************************************************************************************/
// 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
{
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: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.
What is the value for your PAS_NUMBER_MAGNETS??geofft said:...so it seems the pas detection needs a little more work..?
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.