Casainho: I seem to have got the problem back with flashing empty battery signal and no motor functions (LVC triggered..?)
You fixed this a couple of days ago, could it have sneaked back into the github download?

I am not really happy with riding experience with my direct drive motor.
The torque sensor outputs a value that is a peak signal every pedals rotation and I feel that peak on the motor, if I control directly the motor duty_cycle. Ideally, the torque signal would be stable continuous over a pedals rotaion and I think that would be veey good for the motor....

I got no idea about the regen current. I can measure how much the stock firmware gives if you want but its strong only at high speed. Under 20km/h unusable.

The electric unicycles I did ride, had motors similar to Q11 and the same PWM control scheme our firmware uses, and they do break almost at to spto point -- it must, other Segways, hoverboards and electric unicycles could not exist.

I got no idea about the regen current. I can measure how much the stock firmware gives if you want but its strong only at high speed. Under 20km/h unusable.

The electric unicycles I did ride, had motors similar to Q11 and the same PWM control scheme our firmware uses, and they do break almost at to spto point -- it must, other Segways, hoverboards and electric unicycles could not exist.

--complex and more common way is the controller repeatedly "shorts" the motor windings to create pulses of much higher voltage to be able to cause current flow even at motor speeds which would not otherwise be able to do it, so it can brake down to much lower speeds. Some are better at this than others, and some are more efficient at it (the less efficient ones make the motor and controller hotter from the waste heat than the more efficient ones).

On my KT S12SN controller, there is an option, C13, that is described in the manual as:

Until I read AmberWolf's para above the weaker braking == better energy recovery & Stronger breaking == least energy recovery didn't make sense to me; now it seems clear that this controller can be configured to either feed whatever is generated by the motor on overrun back to the battery (C13=1) or actively feed reverse polarity power to the windings to slow the motor down (C13=5); or (somehow) a mixture of the two (C13=2..4).

Note:I have no real knowledge of this, I'm just passing along some info that seems it might be relevant to what you are doing, that you might otherwise miss.

I'm going to buy a wattmeter(or perhaps 2), and if I can work out how to put one in circuit with one of the phase windings, I will try to work out what the standard firmware does with that settings value.

Now I remember to see many times on oscilloscope the motor PWM signals for the 3 phases and I just saw always the same, no short of windings.
The unicycle must brake as also quick change motor rotation direction and that is very smooth, the transition as also all the brake and also motor accelerating. Here an example of changing direction and that I never saw short of phases in oscilloscope:

And a question, 6fet has 1 shunt and 12fet has 2 of them, I wonder, isnt there a need to change something in firmware so they both measure correctly? (I want to use 4 of them in 18fet)

There isn't yet. On my S06S, I did measured each 8 bits ADC step (20mV) to be equal to 0.5A: 5V / 256 = 0.02V.
My S12S had 2 shunts but I cut one, so I can't now measure the real value for S12S.

Please measure for your controller and say the value, then I can put on the firmware as an option.

I do not understand this, I think you just need to know that there will be 4 of them. Or a mOhm value setting will be good also or just any value i can change by trial and error to get the amps I have set?

To the regen types. From my basic understanding I think there are 3 types. The real regen(charging battery), shorting phases, and powering them to slow down.

Best controllers can do all 3 types. Here we should be okay just with charging and shorting. (We get enough braking but no need to waste power)

Casainho, I wonder as you wrote its for moderate accelerations (not for my big bike) then how it can be used on unicycles which needs faster accelerations than I do (I mean in theory, to react that fast.)

On the testbike I am still having problems with the zero current. Once the motor starts it runs forever. I think some offset of the zero value will help here also but now for me its easier to do hardware repair of shunt and see if it helps. I will add brake lever and try a little ride tomorow

The torque sensor outputs a value that is a peak signal every pedals rotation and I feel that peak on the motor,

Therefore the torque is avaraged over one crank revolution in the torque simulation fork...
To have assistance by just putting force on the pedal at zero speed, in the "forumscontroller" code is checked, if the value of human power, or the direct torque value is higher. The bigger value is used for the motor control.

regards
stancecoke

Last edited by stancecoke on Jan 13, 2018 2:42 am, edited 1 time in total.

I do not understand this, I think you just need to know that there will be 4 of them. Or a mOhm value setting will be good also or just any value i can change by trial and error to get the amps I have set?

Ok, how can you do it? Try to run the motor at a fixed battery current, like on a bike training roller, like 3 amps (measure with an amperimeter). At the same time, measure the voltage on the STM8 pin 23: PE7 (ADC_AIN8) | motor_total_current_filtered. Repeat for other current values, more samples of the measures, the better.
Also measure the STM8 pin 23 with motor stopped, that will be the voltage respective to zero battery("motor") current voltage.

On the testbike I am still having problems with the zero current. Once the motor starts it runs forever. I think some offset of the zero value will help here also but now for me its easier to do hardware repair of shunt and see if it helps. I will add brake lever and try a little ride tomorow

It runs forever when duty_cycle increases but never decreases again. I got that when this condition on motor.c code runs:

// verify if there is regen current > 0 (if there is happening regen) and
// if battery voltage is over or equal to absolute battery max voltage, and if so
// reduce regen current
else if ((ui8_adc_motor_total_current < ui8_motor_total_current_offset) &&
(UI8_ADC_BATTERY_VOLTAGE >= ((uint8_t) ADC_BATTERY_VOLTAGE_MAX)))
{
if (ui8_duty_cycle < 255)
{
ui8_duty_cycle++;
}
}

The thing was for me:
1. my mistake of cells voltage number and so was like if battery was charge to max value, so regen never happens and the only way is to keep the same duty_cycle or increase it
2. I was running the motor with a lab power supply, it does not receive back current and quickly increases the voltage at his terminals, will happen then the case 1.

but now for me its easier to do hardware repair of shunt and see if it helps.

What do you mean with "repair"?

regards
stancecoke

Thank you, will try. With repair I mean get exactly to the original resistance, maybe just desolder and put new one. It was covered with solder to get from 20 to 25A on original firmware and then recovered back to like 20.5 maybe but as I see now here its a problem. But the offset will come in handy for more people I believe original shunt resistance can be slightly different on each controller. (Its not precisely set from factory)

But the offset will come in handy for more people I believe original shunt resistance can be slightly different on each controller. (Its not precisely set from factory)

So If I understand, it will not be only an offset, maube an offset + diferent ADC step... -- and If so, I think will be hard for people, for instance, let's see how can you deal with that.
But, I would be happy if people can use the firmware on modded more powerful hardware!!
Would be great if you can resume how to do it, what changes are needed in firmware and let's write an howto.

original shunt resistance can be slightly different on each controller. (Its not precisely set from factory)

Thats no problem, as the firmware reads in the zero current value at every start up of the system. The problem is, that the delta between setpoint and actual value of battery current has to be quite big to make the i16_output value bigger than 1 respectivly smaller than -1.

As there is no "classical" integral part with floating point arithmetic in the control loop, the delta can't be controlled completely by summig up the error by the time.
Setting the zero current value to a slightly negative value is just a trick to make the delta bigger.
I don't know, if we can do a "real" PI-Control like in the torque-simulation fork in the fast loop, or if the floating point operation is to slow...

regards
stancecoke

Last edited by stancecoke on Jan 13, 2018 7:27 am, edited 1 time in total.

original shunt resistance can be slightly different on each controller. (Its not precisely set from factory)

Thats no problem, as the firmware reads in the zero current value at every start up of the system. The problem is, that the delta between setpoint and actual value of battery current has to be quite big to make the i16_output value bigger than 1 respectivly smaller than -1.

As there is no "classical" integral part with floating point arithmetic in the control loop, the delta can't be controlled completely by summig up the error by the time.
Setting the zero current value to a slightly negative value is just a trick to make the delta bigger.
I don't know, if we can do a "real" PI-Control like in the torque-simulation fork in the fast loop, or if the floating point operation is to slow...

stancecoke, I remember when I did that, I tried hard to do a code not using floats as it is very slow... but, maybe we need that code.

I remember to play with the integral but for some reason I didn't like the results. Anyway, we can try again, with floats and integral part. I wasn't motivated to do something complex, because if that will be a PI controller and will need user to tune the coefficients... more complexity while the original don't have that need for user tune!! I think we should simplify in a way to have no more options for user to tune, like the original firmware.

I wasn't motivated to do something complex, because if that will be a PI controller and will need user to tune the coefficients... more complexity while the original don't have that need for user tune!! I think we should simplify in a way to have no more options for user to tune, like the original firmware.

The user won't have to tune the PI coefficients. I think we will find a setting that works for most Motor/Battery/Controller combinations.
And we still don't need to do the mathematics in a fast loop, as I have already mentioned several times

Found some time for a test ride and some playtime in the garage today, a couple of things you may like to know.

The motor wattmeter is improved but still reads about 30% high (was 100%+ high previously). Damping is also improved, now takes maybe 5secs to reach zero after a motor cut, maybe should be slightly less, not a big deal.

The battery indicator is not quite right, with 'sensible' voltages entered in the main.h voltage lookup table (similar to default values) it was generally reading 1-2 bars too high. My battery was almost fully discharged, so whilst charging was able to enter lookup table values that gave a correct indication. The results were surprising, generally needing values around 0.25v higher than you might expect:-

...it seems the code that runs the battery indicator may not be operating exactly as you intended, or maybe I have a fault with my controller?

Another 'oddity', when reflashing these numbers and powering back up was that I was occasionally greeted with LVC indicated on the lcd3 (flashing battery icon, motor disabled). Couldn't really work out what was causing this, but the real problem was that I couldn't escape from it, whatever I changed in main.h or anywhere else in the firmware (and re-flashing) I still got LVC.
Eventually found that deleting the entire firmware folder on the laptop (BMSBattery_S.....) then re-installing a new copy restored normal operation. This worked every time, so it seems that when LVC was triggered something was being flagged in the firmware folder to lock it. Any ideas?

All just details really, have to say the bike rode really well....

Last edited by geofft on Jan 13, 2018 3:03 pm, edited 2 times in total.

Guys I think my testbike motor fails to switch to FOC, when motor start interpolatiom 60 degrees set to 200 it runs up to high speed and then starts coughing when set 40 it starts sooner. Is it related with only FOC ID angle or also rotor offset? This motor needed the C2 parameter set at 5 with stock fw.

Guys I think my testbike motor fails to switch to FOC, when motor start interpolatiom 60 degrees set to 200 it runs up to high speed and then starts coughing when set 40 it starts sooner. Is it related with only FOC ID angle or also rotor offset? This motor needed the C2 parameter set at 5 with stock fw.

Edit: Thanks stancecoke, motor stopping is improved.

I think you need mainly to play with MOTOR_ROTOR_OFFSET_ANGLE.
I would put fixed FOC_READ_ID_CURRENT_ANGLE_ADJUST = 127 and start play with MOTOR_ROTOR_OFFSET_ANGLE.

Out of curiosity, how did you find that C2 must be 5 for your motor, on stock firmware?

The thing is, FOC needs to keep motor current at a specific position, and that specific position is relative to hall sensor signal. A value o 127, means it will be at the same position at hall sensor. Please read that document.

The motor wattmeter is improved but still reads about 30% high (was 100%+ high previously). Damping is also improved, now takes maybe 5secs to reach zero after a motor cut, maybe should be slightly less, not a big deal.

How did you measured to verify it is about 30% high? -- if we agree, I can just reduce that 25% or 30%, etc.

That 2 lines with >> 2, before was value 3. You can try reduce to 1 or 0, with 0, there will be no damping.
>> 2 is divide by 4; >> 1 is divide by 2. Maybe no damping will be ok, who knows if the LCD already damps that value??

...it seems the code that runs the battery indicator may not be operating exactly as you intended, or maybe I have a fault with my controller?

I just looked at the code and I found I could do some variable type optimizations -- can you please test?
I must say I tested by looking at my display and changing the lab power supply, and seems ti works well but I never verified in details.

Can you please write the SOC table, for what would be the correct values? And provide a link your references??

Eventually found that deleting the entire firmware folder on the laptop (BMSBattery_S.....) then re-installing a new copy restored normal operation. This worked every time, so it seems that when LVC was triggered something was being flagged in the firmware folder to lock it. Any ideas?

The motor wattmeter is improved but still reads about 30% high (was 100%+ high previously). Damping is also improved, now takes maybe 5secs to reach zero after a motor cut, maybe should be slightly less, not a big deal.

How did you measured to verify it is about 30% high? -- if we agree, I can just reduce that 25% or 30%, etc.

My estimate here is not scientific, the power maximum the motor draws (indicated on display) with the stock firmware is 800w, but the new firmware is showing 1150w. I can do some better tests with an ammeter in the battery supply if you prefer..?

...it seems the code that runs the battery indicator may not be operating exactly as you intended, or maybe I have a fault with my controller?

I just looked at the code and I found I could do some variable type optimizations -- can you please test?
I must say I tested by looking at my display and changing the lab power supply, and seems ti works well but I never verified in details.

I'm beginning to think that the battery state-of-charge voltage figure (as reported from controller to display) is an imprecise number which varies with different controllers. This is maybe why the LCD3 provides for a large range of adjustment via the P5 parameter? So maybe we already have the solution by adjusting the voltage figures in the main.h lookup table. This works well enough for me, but will checkout your changes and let you know.

Can you please write the SOC table, for what would be the correct values? And provide a link your references??

I always use this table, seems to give a very accurate state-of-charge indication.

Lipoly Voltage vs_ State of Charge.jpg (32.17 KiB) Viewed 834 times

Last edited by geofft on Jan 14, 2018 6:21 am, edited 1 time in total.

My estimate here is not scientific, the power maximum the motor draws (indicated on display) with the stock firmware is 800w, but the new firmware is showing 1150w. I can do some better tests with an ammeter in the battery supply if you prefer..?

I always use this table, seems to give a very accurate state-of-charge indication.
Lipoly Voltage vs_ State of Charge.jpg

I just updated the table on main.h but I also had to update the code that calc the number of bars:

The BATTERY_PACK_VOLTS_100 is 4.20, that is the voltage when it leaves the charger and will be at that value almost no time when running the motor, so, we can't consider the 4 bars | full charge for that voltage. So, I consider the battery is full between 100% and 80%, this seems logic to me.