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

[casainho]

One approach would be to still keep the 8 bit value but convert it to ui8_battery_current_x6 or ui8_adc_battery_current. Then the operations and variable sizes of 8 bit would remain. Only difference is that we convert the 10 bit ADC value to 160 mA current steps during the ADC conversion. Not saying that is the best approach but am trying to convey that there are several ways of doing it and still maintaining speed and even simplifying code.

This approach seems good because each ADC unit (10 bits) represents 0.156 amps, the best the system can measure. With the 8 bits variable we can store up to 40 amps. So, I would say we could read the 10 bits ADC value and just store on 8 bits variable:

ui8_adc_battery_current = (uint8_t) ui16_adc_read_battery_current_10b();

Then filtering is missing and this current measure on the shunt resistor should be VERY noisy, because the PWM motor phase currents goes over there. But the true is that I can't say how much filtering we need, I guess we would need to try and see.

2. Low pass filter of analog signals
This motor has wires with high peak currents and PWM high frequency, meaning the electric signals should be noisy.

On the analog signals measured by the ADC, the first 2 bits of the 10 bits are being discarded and this results in a fast way that filters the noisy analog signals.

To discard two bits and therefore reduce the resolution with a factor of 4 is one way of filtering the values. This will remove noise that is between the 625 mA steps. But on the other hand you loose the resolution. Could be possible to filter the value in the same way the other measurements are filtered. But without having seen the type of noise and the amplitude I can not say much. Just that I have never used a sensor without some form of filtering. And more often than not it has been software filters.

We are filtering in 3 different types on our firmware:
1. discarding the 2 first bits
2. average
3. slow time reading/ reduced frequency sampling

For the ui8_adc_battery_current we are using 1.
2 and 3 do not work because they are slow/make a delay and we need fast reaction (at least the way I see all this working).

2. and 3. are being used for reading torque sensor, throttle.

 

[casainho]

1. I would like off-road faster engine start (more than 10 amps per second. Maybe 15 or 20? I have iron gear and Japanese bearings everywhere (the Chinese all fail very quickly) and I need more power very quickly!)

2. Another problem, the motor stops for a long time and spins for another 1-2 seconds after I stopped pedaling. Once this led to a chain bite due to dirt on the front gear and the motor managed to wind the chain in 1-2 seconds and pull out the rear derailleur with destruction. It would be great off-road to quickly stop the motor together with the speed of the pedals.

1. you mean you want to configure the motor ramp current of amps per second? If so, go to LCD3 and change it!!

2. hmmm, I think more users did report this. I think only changes done that can justify that were or on the pedal cadence or torque sensor reading. I think the issue can be on the cadence... can you please look at the LCD3 and see the cadence value, to see if when the motor stops after that 1-2 seconds after stopping pedaling, the cadence also goes to 0??

 

[buba]

The cadence is also changing throughout the stroke.

This change is very very small, due to mass inertia, see the values on the y-axis in your plot.

Not even noticeable, correct. But I am trying to justify the fact that we need to lower the current coefficient and would like to have some logic behind it. Even though it is severely lacking. In the end we are just calibrating and adjusting one coefficient to hopefully get to a level where the human power measurement can not longer be improved or other problems can be distinguished.

We look at the maximum amplitude and multiply it with 0.637

With this you will get most scatter. Over what period of time is the maximum measured? Refers the period to one crank revolution?
10 samples per second is much less than 32 samples per revolution at a "normal" cadence and you'll get aliasing effects with this small input rate.

I was just basically suggesting to reduce the coefficient that is currently 0.637 multiplied with every value of the torque signal. Tried to use some sort of logic, albeit lacking, to not just aimlessly decrease the value because it feels too high. It could also give some sort of indication of the value range: 0.41 ≤ X < 0.637.


Currently:

Human Power = 0.637 * torque * cadence

Suggestion to further test and be able to distinguish and define other problems:

Human Power = 0.41 * torque * cadence


As for the sampling rate, it should be set to a value sufficient enough as not to cause major loss of accuracy and at the same time be matched to fit the resolution and accuracy of the torque sensor itself. You are probably right in that the sampling rate is on the low side using the current filter technique. If the approach is to filter the values then you need a lot of data. But if the approach is to have a low sampling rate but use sinusoidal formulas you do not need all the data points making up the wave, instead you need the characteristics of the wave and only the data points that define those. Such as the maximum amplitude. Rest can be calculated with the formula.

Probably always best to measure more and try to calibrate but I do not know of the possible problems or limitations there are. Have not developed nor studied this particular part of the code in any meaningful way to have any say.

 

[buba]

1. I would like off-road faster engine start (more than 10 amps per second. Maybe 15 or 20? I have iron gear and Japanese bearings everywhere (the Chinese all fail very quickly) and I need more power very quickly!)

The maximum limit is set to 10 amps per second for now and the plan is to increase it in future versions.

 

[buba]

One approach would be to still keep the 8 bit value but convert it to ui8_battery_current_x6 or ui8_adc_battery_current. Then the operations and variable sizes of 8 bit would remain. Only difference is that we convert the 10 bit ADC value to 160 mA current steps during the ADC conversion. Not saying that is the best approach but am trying to convey that there are several ways of doing it and still maintaining speed and even simplifying code.

This approach seems good because each ADC unit (10 bits) represents 0.156 amps, the best the system can measure. With the 8 bits variable we can store up to 40 amps. So, I would say we could read the 10 bits ADC value and just store on 8 bits variable:

ui8_adc_battery_current = (uint8_t) ui16_adc_read_battery_current_10b();

Then filtering is missing and this current measure on the shunt resistor should be VERY noisy, because the PWM motor phase currents goes over there. But the true is that I can't say how much filtering we need, I guess we would need to try and see.

Yes, I only said 160 mA to keep it simple. And likewise, I do not know how much filtering is needed but I can calculate the minimum filter size if I have the noise, real waveforms, execution time (this we do know) and/or some form of data on the current. Do you have any graphs from an oscilloscope or any measurements whatsoever?

2. Low pass filter of analog signals
This motor has wires with high peak currents and PWM high frequency, meaning the electric signals should be noisy.

On the analog signals measured by the ADC, the first 2 bits of the 10 bits are being discarded and this results in a fast way that filters the noisy analog signals.

To discard two bits and therefore reduce the resolution with a factor of 4 is one way of filtering the values. This will remove noise that is between the 625 mA steps. But on the other hand you loose the resolution. Could be possible to filter the value in the same way the other measurements are filtered. But without having seen the type of noise and the amplitude I can not say much. Just that I have never used a sensor without some form of filtering. And more often than not it has been software filters.

We are filtering in 3 different types on our firmware:
1. discarding the 2 first bits
2. average
3. slow time reading/ reduced frequency sampling

For the ui8_adc_battery_current we are using 1.
2 and 3 do not work because they are slow/make a delay and we need fast reaction (at least the way I see all this working).

2. and 3. are being used for reading torque sensor, throttle.

Thanks! As I said, it would be nice to have some sort of measurements so the noise and waveforms are clearly defined. But I understand that you want it fast.

 

[buba]

Is anyone using the throttle on the 0.19.0 beta 8? Can someone confirm it works?

 

[casainho]

Yes, I only said 160 mA to keep it simple. And likewise, I do not know how much filtering is needed but I can calculate the minimum filter size if I have the noise, real waveforms, execution time (this we do know) and/or some form of data on the current. Do you have any graphs from an oscilloscope or any measurements whatsoever?

I don't have but I have in memory that should be something like this yellow line:

That was measured with my very cheap oscilloscope that should be even not showing some very fast noise. The yellow line is a phase current value, on the current sensor, on KT motor controller. I expect the current we read on TSDZ2 to be at least equal in terms of noise.

https://opensourceebikefirmware.bitbucket.io/development/Datasheets_and_application_notes--Endless-sphere.com_forum_messages--2017.09.03_-_more_ideas_about_zero_crossing_for_FOC.html

 

[buba]

Yes, I only said 160 mA to keep it simple. And likewise, I do not know how much filtering is needed but I can calculate the minimum filter size if I have the noise, real waveforms, execution time (this we do know) and/or some form of data on the current. Do you have any graphs from an oscilloscope or any measurements whatsoever?

I don't have but I have in memory that should be something like this yellow line:

That was measured with my very cheap oscilloscope that should be even not showing some very fast noise. The yellow line is a phase current value, on the current sensor, on KT motor controller. I expect the current we read on TSDZ2 to be at least equal in terms of noise.

https://opensourceebikefirmware.bitbucket.io/development/Datasheets_and_application_notes--Endless-sphere.com_forum_messages--2017.09.03_-_more_ideas_about_zero_crossing_for_FOC.html

This is great! Will be able to approximate the noise and make some calculations. Hopefully will figure out what we are dealing with. Thanks!

 

[thineight]

Question: what is the logic on the stock firmware to manage the peak power (>>250w) versus the nominal power (say 250w)?

Is the peak power fading to the nominal power after a certain amount of s?

Now with the open source firmware we do not have anymore the peak and nominal power.. we just have a maximum power that may be reduced if one sets the street mode or have the temperature sensor installed.. am I wrong?
Thanks

 

[casainho]

Question: what is the logic on the stock firmware to manage the peak power (>>250w) versus the nominal power (say 250w)?

Is the peak power fading to the nominal power after a certain amount of s?

Now with the open source firmware we do not have anymore the peak and nominal power.. we just have a maximum power that may be reduced if one sets the street mode or have the temperature sensor installed.. am I wrong?
Thanks

We have also boost that is a "peak" of assist level value for a specific defined time at startup.

 

[thineight]

Question: what is the logic on the stock firmware to manage the peak power (>>250w) versus the nominal power (say 250w)?

Is the peak power fading to the nominal power after a certain amount of s?

Now with the open source firmware we do not have anymore the peak and nominal power.. we just have a maximum power that may be reduced if one sets the street mode or have the temperature sensor installed.. am I wrong?
Thanks

We have also boost that is a "peak" of assist level value for a specific defined time at startup.

Correct, I didn't mention it because I keep it normally off.
I was just curious about the "running" peak of the original software :wink:

 

[hefest]

Need help trying to flash the KT-LCD3 and TSDZ2 for the first time.

Wen't through Wiki pages and I think I wired everything as specified.
When I power up, LCD3 turns on and all possible symbols are displayed and it's stuck at that.

Any hint in which direction should I look for a solution?

From the flashing below it looks like everything went ok. The only thing that comes to my mind is that wiring is not ok.

Downloaded v0.18.2:
- KT-LCD3-v0.18.2.hex
- TSDZ2-v0.18.2.hex

Flashed KT-LCD3 with the following commands on Linux:

$ echo "00 00 ff 20 df 00 ff 00 ff 00 ff 00 ff 00 ff" | xxd -r -p > option_bytes_pwm_n_channels_enabled.bin

$ stm8flash -c stlinkv2 -p stm8s105?6 -s opt -w option_bytes_pwm_n_channels_enabled.bin

$ stm8flash -c stlinkv2 -p stm8s105?6 -w KT-LCD3-v0.18.2.hex
Determine FLASH area
Due to its file extension (or lack thereof), "KT-LCD3-v0.18.2.hex" is considered as INTEL HEX format!
32717 bytes at 0x8000... OK
Bytes written: 32717

Flashed TSDZ2 with LCD3 connected on Linux:

$ echo "00 00 ff 20 df 00 ff 00 ff 00 ff 00 ff 00 ff" | xxd -r -p > option_bytes_pwm_n_channels_enabled.bin

$ stm8flash -c stlinkv2 -p stm8s105?6 -s opt -w option_bytes_pwm_n_channels_enabled.bin
Determine OPT area
Due to its file extension (or lack thereof), "option_bytes_pwm_n_channels_enabled.bin" is considered as RAW BINARY format!
15 bytes at 0x4800... OK
Bytes written: 15

$ stm8flash -c stlinkv2 -p stm8s105?6 -w TSDZ2-v0.18.2.hex
Determine FLASH area
Due to its file extension (or lack thereof), "TSDZ2-v0.18.2.hex" is considered as INTEL HEX format!
21233 bytes at 0x8000... OK
Bytes written: 21233

 

[thineight]

Need help trying to flash the KT-LCD3 and TSDZ2 for the first time.

Wen't through Wiki pages and I think I wired everything as specified.
When I power up, LCD3 turns on and all possible symbols are displayed and it's stuck at that.

Any hint in which direction should I look for a solution?

From the flashing below it looks like everything went ok. The only thing that comes to my mind is that wiring is not ok.

Downloaded v0.18.2:
- KT-LCD3-v0.18.2.hex
- TSDZ2-v0.18.2.hex

Flashed KT-LCD3 with the following commands on Linux:

$ echo "00 00 ff 20 df 00 ff 00 ff 00 ff 00 ff 00 ff" | xxd -r -p > option_bytes_pwm_n_channels_enabled.bin

$ stm8flash -c stlinkv2 -p stm8s105?6 -s opt -w option_bytes_pwm_n_channels_enabled.bin

$ stm8flash -c stlinkv2 -p stm8s105?6 -w KT-LCD3-v0.18.2.hex
Determine FLASH area
Due to its file extension (or lack thereof), "KT-LCD3-v0.18.2.hex" is considered as INTEL HEX format!
32717 bytes at 0x8000... OK
Bytes written: 32717

Flashed TSDZ2 with LCD3 connected on Linux:

$ echo "00 00 ff 20 df 00 ff 00 ff 00 ff 00 ff 00 ff" | xxd -r -p > option_bytes_pwm_n_channels_enabled.bin

$ stm8flash -c stlinkv2 -p stm8s105?6 -s opt -w option_bytes_pwm_n_channels_enabled.bin
Determine OPT area
Due to its file extension (or lack thereof), "option_bytes_pwm_n_channels_enabled.bin" is considered as RAW BINARY format!
15 bytes at 0x4800... OK
Bytes written: 15

$ stm8flash -c stlinkv2 -p stm8s105?6 -w TSDZ2-v0.18.2.hex
Determine FLASH area
Due to its file extension (or lack thereof), "TSDZ2-v0.18.2.hex" is considered as INTEL HEX format!
21233 bytes at 0x8000... OK
Bytes written: 21233

Make sure, if you have the brake sensors installed, that the magnets are in place otherwise the display won't boot. Or just disconnect the brake sensors wires.
It should be in the wiki, at least I asked casainho to add it because that caused me headache when I installed them the first time.. I thought I inverted the TX and Rx wires as happened to jbalat.

 

[hefest]

Need help trying to flash the KT-LCD3 and TSDZ2 for the first time.

Wen't through Wiki pages and I think I wired everything as specified.
When I power up, LCD3 turns on and all possible symbols are displayed and it's stuck at that.

Any hint in which direction should I look for a solution?

From the flashing below it looks like everything went ok. The only thing that comes to my mind is that wiring is not ok.

Downloaded v0.18.2:
- KT-LCD3-v0.18.2.hex
- TSDZ2-v0.18.2.hex

Flashed KT-LCD3 with the following commands on Linux:

$ echo "00 00 ff 20 df 00 ff 00 ff 00 ff 00 ff 00 ff" | xxd -r -p > option_bytes_pwm_n_channels_enabled.bin

$ stm8flash -c stlinkv2 -p stm8s105?6 -s opt -w option_bytes_pwm_n_channels_enabled.bin

$ stm8flash -c stlinkv2 -p stm8s105?6 -w KT-LCD3-v0.18.2.hex
Determine FLASH area
Due to its file extension (or lack thereof), "KT-LCD3-v0.18.2.hex" is considered as INTEL HEX format!
32717 bytes at 0x8000... OK
Bytes written: 32717

Flashed TSDZ2 with LCD3 connected on Linux:

$ echo "00 00 ff 20 df 00 ff 00 ff 00 ff 00 ff 00 ff" | xxd -r -p > option_bytes_pwm_n_channels_enabled.bin

$ stm8flash -c stlinkv2 -p stm8s105?6 -s opt -w option_bytes_pwm_n_channels_enabled.bin
Determine OPT area
Due to its file extension (or lack thereof), "option_bytes_pwm_n_channels_enabled.bin" is considered as RAW BINARY format!
15 bytes at 0x4800... OK
Bytes written: 15

$ stm8flash -c stlinkv2 -p stm8s105?6 -w TSDZ2-v0.18.2.hex
Determine FLASH area
Due to its file extension (or lack thereof), "TSDZ2-v0.18.2.hex" is considered as INTEL HEX format!
21233 bytes at 0x8000... OK
Bytes written: 21233

Make sure, if you have the brake sensors installed, that the magnets are in place otherwise the display won't boot. Or just disconnect the brake sensors wires.
It should be in the wiki, at least I asked casainho to add it because that caused me headache when I installed them the first time.. I thought I inverted the TX and Rx wires as happened to jbalat.

Oh man, you are a lifesaver with this info. I've actually soldered magnetic brake sensors directly to cable that goes to Tsdz2 controller so I can't unplug it, but I can have magnets nearby. Thank's, will try that rightaway.

PS: It's alive! Can't believe all the flashing and wiring, soldering, crimping succeeded in the first try. Next stop, lm35 and heatsink foam installation.

 

[thineight]

What is the heatsink foam? Something to improve the thermal dissipation of the motor?
Please share some info...

 

[casainho]

Buba, one user told the throttle not working may be something about 0 cadence - this can make sense.

For debug, force motor PWM disable and override the throttle variable with a fixed value -- then do a debug to see where the code is forcing the motor output to zero when throttle > 0.

 

[hefest]

What is the heatsink foam? Something to improve the thermal dissipation of the motor?
Please share some info...

It's gel pad/foam as the one used to attach heatsink to CPU just thicker. Here https://endless-sphere.com/forums/viewtopic.php?f=28&t=79788&p=1472729&hilit=Heatsink#p1472729/url]

 

[Rydon]

Buba, one user told the throttle not working may be something about 0 cadence - this can make sense.

For debug, force motor PWM disable and override the throttle variable with a fixed value -- then do a debug to see where the code is forcing the motor output to zero when throttle > 0.

I wonder if this might also be affecting the coaster brake version in v19 where motor output is always 0. Even though it does not have a throttle the throttle level is floating high and is always > 0. This is why we had to put in a "no throttle" option in v18.2.

 

[casainho]

This had to happen, a sensor fail while we were outside riding -- luckily we were only 10 kms away from home.

The magnetic brake sensor magnet simple took off and it was loose somewhere on the ground. My girlfriend had to pedal with motor turned of, back to home. This is no fun, specially if we are on a long travel, some days out far from home!!

I really need to implement on the motor and LCD options to disable the various sensors because they can suddenly fail and firmware should not limit the motor working because of that. Sensors I think we should be able to enable/disable on LCD:
- bake sensors
- wheel speed sensor
- torque sensor
- PAS sensor
- throttle sensor

That would mean to rethink how system can work without any of that sensors. For instance, with torque sensor disabled, the system would need to work with PAS and throttle. Current code is not ready to work without torque sensor. Once I received a motor where torque sensor was not working at all, just like a few users reported the same.

 

[buba]

This had to happen, a sensor fail while we were outside riding -- luckily we were only 10 kms away from home.

The magnetic brake sensor magnet simple took off and it was loose somewhere on the ground. My girlfriend had to pedal with motor turned of, back to home. This is no fun, specially if we are on a long travel, some days out far from home!!

I really need to implement on the motor and LCD options to disable the various sensors because they can suddenly fail and firmware should not limit the motor working because of that.

Sorry to hear that! I agree that is is good to have options for disabling sensors.

Sensors I think we should be able to enable/disable on LCD:
- bake sensors

I started working on the throttle issue reported from one of the betas in 0.19.0. I have already added wider range for the current acceleration, amps per second, as it was requested to be settable for values over 10 amps per second. And just implemented so that you can disable the brake sensor in the system. Will be included in the next pull request.

- wheel speed sensor

I think this is fixed since I added the check_system implementation that caused the blinking 1 bug.

- torque sensor

This is planned as perryscope has stated it would be good to have a cadence only mode for users not benefiting from the torque sensor. It would then operate much like any other ebike without the torque sensor.

- PAS sensor

The cadence sensor is the only one I have not planned to make possible to disable by user. But should be possible just as everything else is.

- throttle sensor

The throttle sensor is already able to be disabled from LCD

That would mean to rethink how system can work without any of that sensors. For instance, with torque sensor disabled, the system would need to work with PAS and throttle. Current code is not ready to work without torque sensor. Once I received a motor where torque sensor was not working at all, just like a few users reported the same.

I actually asked on this thread if anyone has had a broken torque sensor. This would justify cadence only operation even more.

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

I was extremely limited in time yesterday and also very limited today. Will update as soon as possible.

 

[casainho]

I was extremely limited in time yesterday and also very limited today. Will update as soon as possible.

I wanted to implement that by myself, I mean, I was not asking for you to implement. But that is ok for sure, no problem. I just hope this goes to next version and not the stable version we are trying to release soon.

One important thing would be to make LCD3 startup even if there is no communications from the motor controller and show an error for that. That error would help the users that exchange by mistake the RX and TX wires as also the ones that keep brakes active without knowing it.
This is tricky in a way that the protection at startup for brake sensors active, for development protection, should be removed, I think. That is a risk we should take, I guess.

Also, do you think to add to LCD3, is there space for that??
I really like SW102 Bluetooth LCD, it seems to have enough memory to hold all this options on the LCD itself, not even counting with the mobile app.

 

[thineight]

The magnetic brake sensor magnet simple took off and it was loose somewhere on the ground. My girlfriend had to pedal with motor turned of, back to home. This is no fun, specially if we are on a long travel, some days out far from home!!

I really need to implement on the motor and LCD options to disable the various sensors because they can suddenly fail and firmware should not limit the motor working because of that.

Casainho, sorry to hear that. I discovered this when I was trying to wire myself the VLCD5 with home-made sensors. Luckily on VLCD5 the sensors are disconnectable. With that experience in mind, I adopted the following configuration on the LCD3 wiring:
https://endless-sphere.com/forums/viewtopic.php?f=30&t=93818&p=1469691&hilit=Splitter#p1469691

In such way you always can disconnect one or both failing sensor if needed.

I recommend this setup for any installation so you keep intact the sensors and connectors, just need to buy a cheap splitter.
Please consider to add the explaination and the scheme to the wiki for user benefit.

One important thing would be to make LCD3 startup even if there is no communications from the motor controller and show an error for that. That error would help the users that exchange by mistake the RX and TX wires as also the ones that keep brakes active without knowing it.
This is tricky in a way that the protection at startup for brake sensors active, for development protection, should be removed, I think. That is a risk we should take, I guess.

I think TX an RX swap is a mistake well documented in jbalat videos, and users put attention on that (maybe it worth to specifically mention it in the installation wiki).

The unintentional brake active is trickier.. and several users (included myself) fell into this one.
Again I think that a clear note (in bold) in the wiki should be sufficient to avoid any other mistakes.

If you agree in principle with the above, and considering the possibility to wire the brake sensors with the disconnectable system described above, maybe the startup protection code can be maintained as it is.

Thanks

 

[hefest]

Tried v0.18 today for the first time. I've noticed few things that are worse (out of the box) than on original firmware.
1. LCD3 button clicks are really slow, you need to wait between each click otherwise it just ignores it.
2. Default Boost settings are too high. The first thing that was annoying me with the original software is that violent "jerking" on start, with default settings and OpenSource firmware it's even worse. Luckily, you can tune it down.
3. When you stop pedaling motor continues to pull for a brief moment. This "delayed" time is present on both, OEM firmware and OSS, but it looks like it's a tiny bit longer on OSS.
4. I'm not sure if this is subjective or not, but I've noticed that with OSS, drop in power when cadence is rising comes sooner than with original firmware. Is this possible? In lower gear (3rd out of 8 on my Nexus) it's dropping fairly quickly to 300W on steep incline.
5. Tried cruise control a bit, and it looks like it's completely useless. It comes in, pulls you over the set speed than motor stops pulling. When it drops below the set speed it kicks in again with the boost and overshoots than stops. It's like a yoyo.

 

[thineight]

You should try the v.19beta8 instead, it has been improved a lot compared to v.18

 

[hefest]

You should try the v.19beta8 instead, it has been improved a lot compared to v.18

After Casaihnos shout out not to use beta unless you are a tester, I chose to use stable 0.18 first

If I'm understanding this correctly, 0.19 stable is almost here.