Zweiter Frühling für ION-Antrieb --- Sparta, Batavus, Koga ...

Diskutiere Zweiter Frühling für ION-Antrieb --- Sparta, Batavus, Koga ... im Nabenmotoren Forum im Bereich Fertig-Pedelecs; I’m happy to do some logging. Is there an esp32 firmware to write the decoded messages to the console? Or maybe a debug level in the existing...
K

kodel

Dabei seit
28.07.2022
Beiträge
32
Punkte Reaktionen
22
I’m happy to do some logging. Is there an esp32 firmware to write the decoded messages to the console? Or maybe a debug level in the existing code? I can find one of my serial to usb convertors, but that means messing around with drivers again and then still having to do decoding in python afterwards :)

I didn’t see a display dimming problem. I’m using a 4K7 pullup resistor and 100 Ohm pulldown on the bus, with a voltage divider of 47K + 4K7 to the bus for readout. So maybe it helps to pull a bit less current from the bus?
 
K

kodel

Dabei seit
28.07.2022
Beiträge
32
Punkte Reaktionen
22
This is what the inside of my cu3 display holder looks like. I have no display dimming issues with the 36V battery.

Regarding the cells in the pmu3 battery: they are aluminum encased rectangular prismatic cells, not pouched LiPo cells. I still need to do some discharge tests to determine the cell chemistry. When i got them, they were at 3.6V/cell. Yesterday I took them up to 4.1V/cell in a couple of hours with the supplied charger directly connected to the pack, delivering 1.8A. So I don't think it's LiFePo4 chemistry. I'll have to confirm that by doing 2 discharge tests: one after charging to 4.1V and another after charging to 3.6V. If there is a huge difference in capacity, the cells are LiIon and have to be charged to 4.1V/cell. If the difference is small, they are LiFePo4 and have to be charged to 3.6V/cell.
20220731_073850.jpg
 
Mike747

Mike747

Dabei seit
11.03.2021
Beiträge
261
Punkte Reaktionen
44
It would be nice if the cells are fine and you can use a "universal" BMS (and even the original charger) for the battery(y). "easy fix" ;).

The display-mount is the "full-featured" one. This could be necessary for the throttle and/or for 36V operation. It is good to know you do not experience the "dimming-issue" on 36V. I think Void-Spark had this issue on lower voltages on a 24V system with these versions of the mount.

By the way; what version of the display do you have? (I hope this does not have something to do with dimming, but you never know):
1659251565701.png

CU3 (left) and CU3v2 (right)

The CU3v2 has more "pixels", it is also marketed as "HD-display". It does run fine on 24V system:).
 
K

kodel

Dabei seit
28.07.2022
Beiträge
32
Punkte Reaktionen
22
I have the display on the left. My battery turns out to be Li-Ion and still delivers 8Ah, so certainly useable. Now I just have to wait for the BMS to arrive.
 
herman74

herman74

Dabei seit
28.04.2022
Beiträge
49
Punkte Reaktionen
15
Ort
Utrecht
Kodel:
battery state of charge calculation and forwarding to display (note: a voltage divider might not be very useful for this, since the voltage depends on the load of the battery, so either a current sensor or an indication of the motor of the current consumption will be needed)


here we use different capacity of cells my battery delivers 17ah that of Kodel still 8ah Would it be useful to use a voltage divider?

with both batteries 29.4 volts is a full battery and at 21 volts it is empty. it is of course true if the motor has to supply power, the voltage drops slightly, but this can be solved moderately in software

It is also the case that many bicycles for the battery level look at the voltage, also the meters on a battery the 1 with led that also look at the voltage. even if you perform a load test on a bicycle battery the tester looks at the voltage. I would prefer to keep the print as simple as possible with as few components as possible what would be the correct resistances for a voltage divider?

battery voltage full 29.4 volts empty 21 volts the esp wants to have max 3 volts on adc now the resistors have to be chosen so that the battery loses the least curent think it is best to place the voltage divider after the motor relay so that the voltage divider does not draw curent from the battery unnecessarily

maybe it is even nicer to be able to switch the voltage divider on via 1 pin of the esp32 maybe with a transitor or something like that. but I tink that the esp32 c3 does not have an extra pin available
 
Zuletzt bearbeitet:
K

kodel

Dabei seit
28.07.2022
Beiträge
32
Punkte Reaktionen
22
The input impedance of the esp32 is rather high, so the resistor values of the voltage divider can be chosen quite high as well. In your example of a battery that never exceeds 30V you could use 1K from GND to the input pin and 10K from the input pin to the battery positive.
That will result in 1V on the input pin for every 11V of batterij voltage.
I would not recommend this approach. Your reading will jump up and down with motor load severley, e.g. from 20% during a hill climb to 100% at standstill.

I don't think commercialy built charge indicators on ebikes use just battery voltage. I guess they measure power consumption combined with battery health estimation based on voltage sag and idle voltage, probably with initial state of charge estimation based on resting voltage.

A solution could be to use the battery indicator as an indication of how far you are above the minimum safe discharge voltage of your battery. 0% indication= at the voltage the BMS cuts the power, 100% indication= at the voltage the charger stops charging. This would be a good indication for someone who can interpret the reading, but it would freak out someone like my wife, who would think of this indication as unreliable.
 
Mike747

Mike747

Dabei seit
11.03.2021
Beiträge
261
Punkte Reaktionen
44
I would say, lets give it (a simple voltage-divider) a try and see what happens. Maybe we can add a "delay" in the software to prevent the meter from bouncing up and down to much.
My experience with the simple 4-led battery meters is fine. Sometimes under full load one more led goes off and comes back on under normal load.
 
herman74

herman74

Dabei seit
28.04.2022
Beiträge
49
Punkte Reaktionen
15
Ort
Utrecht
okay so we could try a voltage divider of 1K and 10 k does anyone have an idea to turn it on and off via a pin of the esp32?

the charging plug at ion is xlr3 there are only 2 pins used maybe the pin that is unused connect in to the plug of the charger to GND and wire this pin to the esp32 so when battery is on the charger there is a pin on the esp32 connected to GND

so that the esp32 knows that the charger is connected


the only problem for the esp32 c3 is that it doesn't have enough free pins.

the board i use there's space for 3 free pins easily

1 pin for the voltage divider
1 pin for switching the voltage divider on and off
1 pin connected to GND when charger is connected
 
Zuletzt bearbeitet:
K

kodel

Dabei seit
28.07.2022
Beiträge
32
Punkte Reaktionen
22
There is no point in switching the voltage divider if you already have it behind the motor relais. It only consumes 3mA and if that bothers you, you probably can lower it further by a factor of 10. To give an example: suppose you manage to drive for 10 hours on a 10Ah battery (average consumption of only 36W), then your voltage divider only consumes 0.3% of your battery. If you only drive for 4 hours on that battery, it is only 0.1%. Increase the resistors by a factor of 10 and it is only 0.01%.

If you really want to switch a voltage divider, you have to do it on the low side, for example with an NPN transistor brought in saturation by 1k resistor on the base that is hooked to an output pin, emitter to GND and collector to the low side of voltage divider. Then in software compensate for the Vce in saturation. But it is really an exercise in futility.
 
herman74

herman74

Dabei seit
28.04.2022
Beiträge
49
Punkte Reaktionen
15
Ort
Utrecht
I want to switch the voltage divider on/off when the bike is on the charger so that the motor relay can be turned off during charging. And the bike now the voltage

but maybe first the voltage divider behind the motor relay to test if it works properly

and the xlr3 plug of the charger to GND is that a good idea? the bike must be aware that it is being charged
 
Zuletzt bearbeitet:
K

kodel

Dabei seit
28.07.2022
Beiträge
32
Punkte Reaktionen
22
Why would you want to turn the motor relay off when the bike is on the charger? Power saving is not an issue at that moment: the motor capacitor is charged, but it is not using power besides for the electronics. Be aware that the device you're trying to use to switch that voltage divider (the ESP32) is using at least 10 times as much power than the voltage divider itself.

With regard to charge detection: I would use the detected battery voltage to determine that the battery is being charged (raise in voltage= connected to charger). To have a simple and crude estimation of battery state of charge (SOC), you could use 3 lookup tables that translate the measured voltage to a SOC: resting, charging, discharging. Or even simpler you could use a lineair relation, for example:
Resting: 4.0V/cell= 90% charge, 3.5V/cell=10% charge
Charging: 4.1V/cell=90%charge, 3.6V/cell=10% charge
Discharging: 3.5V/cell=90% charge, 3.0V/cell=10% charge

This takes the assumption that the internal battery resistance is fixed at 0.1Ohm (it is not: it varies by more than 100% based on SOC, temperature, age of battery, etc) and the discharge current (whilst providing assistance during cycling) is fixed at 5A (it is also not: it can momentarily exceed 10A).

If we then have a way to determine if the bike is resting, charging or discharging you can use this to calculate a SOC which could be more or less usable. Determining the state of the bike can be done quite simply:
- we measure the battery voltage/cell every minute and compare this voltage to the previous measured value
- at startup, we are in resting state
- if the battery voltage drops by more than 0.1V (compared to our previous measurement), we switch to discharging state
- if we are in discharging state and the battery voltage raises by more than 0.1V, we switch to resting state
- if we are in resting state and the battery voltage raises by more than 0.1V, we switch to charging state

To calculate the displayed SOC, we should prioritise the most reliable value, which is the resting value. The algorithm could look like this:
- at configuration time, we store the maximum discharge rate/minute. This is 1 over battery capacity in A times voltage in V divided by 250W times 60 minutes. In my case, 10A 36V= 1,16% per minute. I'll use this number as an example in the algorithm below.
- at startup time, we set both estimated SOC and displayed SOC to 100%.
- when we measure the SOC in the resting state, we store this number together with the timestamp. We update the estimated SOC to this number. If the estimated SOC is lower than the displayed SOC, we also update the displayed SOC.
- when we measure the SOC in the discharging state, we calculate the lowest possible theoretical charge state by subtracting 1.16% times the number of minutes expired from the stored SOC in the resting state
- if this calculated number is higher than the SOC measured in the discharging state, we update the estimated SOC to this calculated number. Otherwise, we update the estimated SOC to the measured SOC. If the estimated SOC is lower than the displayed SOC, we update the displayed SOC.
- when we measure the SOC in the charging state, we update the estimated SOC and displayed SOC with the measured number.

This should give a display of battery SOC that will not confuse the user and be a best effort indication of far you still can drive. If we can get more info (like power consumed by the motor, assist level or distance driven) we can get a much better estimation, but the algorithm above could be a good point to start tweaking.
 
K

kodel

Dabei seit
28.07.2022
Beiträge
32
Punkte Reaktionen
22
I setup the build environment so I could generate my own binaries and do some logging.
First conclusion is that the calibration routing is nog working on my side. The motor never returns the data to be saved in the calibration file. I'll have to dive deeper in what is know already on the protocol to figure this out. Probably the response message just looks a bit different.
Log extract:
I (918) app: Wakeup!
D (26059) app: KOEN Responding to calibrate command request
D (26092) app: KOEN In step 0 of calibration
D (26125) app: KOEN In step 1 of calibration
D (26163) app: KOEN In step 2 of calibration
I (27929) bow: Incomplete message:
I (27929) bow: 10 01 01 04 c0
 
K

kodel

Dabei seit
28.07.2022
Beiträge
32
Punkte Reaktionen
22
I did some more logging of the failed calibration.
I tried all combinations of:
- support level 0/1 before starting calibration
- starting calibration with the button on the esp32, the light button on the controls and the menu in the cu3 display
- configuring no display, cu2 display or cu3 display in the code
- send the handoff message to the motor instead of the display after receiving the "OK" response from the motor on the calibration command
Every test was done after a full reset of the system/

I never got a put data command from the motor like @void-spark did in message 109 of this thread.
When I start the calibration with the esp32 button, I don't get an answer on the get data request in "step 1" in the code
When I start the calibration with the menu, the code doesn't send out the calibration command to the motor at all, but he display indicates "calibration OK!". Maybe because the display doesn't hand off to the battery after sending the calibration command, but continues the conversation with the motor?
When I start the calibration by holding down the light button, the procedure runs fine, but I don't receive the put data message from the motor with the calibration data.
Maybe the calibration data is sent to the display and not the battery in the case of the cu3?
Maybe the battery doesn't need to handle the calibration with the cu3 display?

I will have to do full logging of what's happening on the bus with another device than the esp32, since it seems that if I write everything to the log the device/uart is chocking. It's also difficult to test whilst driving, since I need to wrap all of the electronics in the battery and don't fancy taking my macbook on a testdrive. Maybe redirecting the log to a file would be workable, but I don't know esp32 well enough to know how to do that.

Here are some logged messages (cu3 configured, support level 1, calibration started with the light button - values in hex)

Code:
I (10620) app: Motor msg rcvd: Tgt:02, Src:0c, Type:01, Command:1b
I (10621) app: 01
I (10621) app: KOEN Received calibrate command request from display
I (10640) app: KOEN In step 0 of calibration
I (10640) app: KOEN Sending request to motor to do calibration
I (10640) bow: Cmnd sent KOEN: Target: 00, Type: 01, Cmd: 35
I (10646) bow: Response rcvd KOEN: Src: 00, Type: 02, Cmd: 35
I (10649) bow: 00
I (10664) app: KOEN In step 1 of calibration
I (10664) bow: Cmnd sent KOEN: Target: 00, Type: 01, Cmd: 08
I (10664) bow: 00 df
I (10672) bow: Response rcvd KOEN: Src: 00, Type: 02, Cmd: 08
I (10673) bow: 00 00 df 00
I (10684) app: KOEN In step 2 of calibration
I (10684) bow: Cmnd sent KOEN: Target: 0c, Type: 01, Cmd: 2a
I (10684) bow: 01 01
I (10692) bow: Response rcvd KOEN: Src: 0c, Type: 02, Cmd: 2a
I (10739) app: Motor msg rcvd: Tgt:02, Src:00, Type:01, Command:09
I (10739) app: 94 c0 00 00 08 c1 00 00 00 00
I (10744) bow: Cmnd sent KOEN: Target: 0c, Type: 01, Cmd: 28
I (10744) bow: 03 01 09 00 00 00 00 00 00 00 00 00 00
I (10761) bow: Response rcvd KOEN: Src: 0c, Type: 02, Cmd: 28
I (10761) bow: 01
I (10854) app: Motor msg rcvd: Tgt:02, Src:00, Type:04, Command:00
I (11112) app: Motor msg rcvd: Tgt:02, Src:00, Type:04, Command:00
I (11151) app: Motor msg rcvd: Tgt:02, Src:0c, Type:01, Command:08
I (11151) app: 28 94
 
Mike747

Mike747

Dabei seit
11.03.2021
Beiträge
261
Punkte Reaktionen
44
Interesting issue. Unfortunately, I cannot help with that.
I don't think I have made a calibration log (yet) with XHP and CU3; only with a CU2 display.
 
G

gpu7990

Dabei seit
11.08.2022
Beiträge
20
Punkte Reaktionen
2
Hello everyone, I got a koga with a cu2 display. What happened to him is unknown, the battery died and was completely ruined. The wires near the display holder had three broken wires with a complete short circuit. I soldered the controller on the esp 32, instead of a relay I made a circuit on the ir2117 high-side pwm controller with irfp4568 mos, connected everything. Then measured voltage on the holder the bow bus 24 volt , +5v, but the display does not show any signs of life. 5 volts are supplied to the board, the voltage on the stm display controller is also formed, there is also 2.9 volts on the button "mode", but there is no reaction, only a barely visible image of all elements in a row.
As far as I understand the display operation scheme, it needs +5 and +24 on the bus to turn it on. Is my display broken, or does it need to receive a command from the bow bus to turn on? Maybe i made mistake in circuit.
 
Mike747

Mike747

Dabei seit
11.03.2021
Beiträge
261
Punkte Reaktionen
44
Hello!
If the wires to the display where shorted, the display might be "fried" and no longer working. There might be no protection for shorting the display. You could try to open the display and see/measure if components on the pcb are damaged and could be replaced.

You could test the display itself:
Zweiter Frühling für ION-Antrieb --- Sparta, Batavus, Koga ...

Are you sure the battery gives no communication? Mostly the bow-bus still functions (to display error messages I guess :rolleyes:) and often charging is also possible.

General info is found in the readme: GitHub - void-spark/SpartaIonStuff: Random grab bag of Sparta Ion ebike related things
"If the bike is idle/in low power mode, there is no communication on the bus. To wake up the bus a single '0x00' byte is sent when a button is pressed on the display."
The display should initiate the command-sequence, but the ESP32 sends the data what to display.
 
Zuletzt bearbeitet:
G

gpu7990

Dabei seit
11.08.2022
Beiträge
20
Punkte Reaktionen
2
The battery ruined- pcb was taken out from some glue and destroyed.
As of components on display pcb- i checked out transistors, diodes, resistors, all fine.
In the diagram of display pcb, I determined that 5 volts comes to the mosfet, the gate of which is just turned on by supplying 12-28 volts to the bow bus. So it turns out my display is faulty because when wires was shorted the 24v bow bus goes to STM.
Trying to find display in Ukraine, but for now with no success.
 
K

kodel

Dabei seit
28.07.2022
Beiträge
32
Punkte Reaktionen
22
I found out why my motor isn't return calibration data to the battery. The hint I got is that, when I analysed a full log, the motor also never requests the data back.
So I tried to do a calibration whilst standing on one of the pedals. The result was that the bike was no longer assisting me whilst pedaling lightly. When I recalibrated without standing on one of the pedals, the bike delivered power again whilst pedaling lightly. So the calibration works, but the battery is merely forwarding the calibration request from the display to the motor. The battery is not involved in storing and retrieving the calibration data.

Maybe somebody can check their logs of their own PMU3 motor to confirm the motor never requests the calibration value? In any case, the software as is supports this behavior without modifications.
 
Mike747

Mike747

Dabei seit
11.03.2021
Beiträge
261
Punkte Reaktionen
44
The battery is not involved in storing and retrieving the calibration data.
I think that is right, calibration is between display (command) and motor (store and use).

From the early stages, calibration was one of the first functions (next to support itself) to be implemented:
Zweiter Frühling für ION-Antrieb --- Sparta, Batavus, Koga ...
Die Kalibrierung sieht folgendermaßen aus:

Code:
tgt:MT typ:1 src:BT [10-0120-35-47] [35] Special calibration command to motor
tgt:BT typ:2 src:MT [10-2201-3500-8a] [3500] Ok!
tgt:MT typ:0 [10-00-b1] - HANDOFF
tgt:BT typ:1 src:MT [10-210a-0994384b20283a3e8f5c29-2b] [0994384b20283a3e8f5c29] - PUT DATA 4b20 8f5c29 (94384b20283a3e8f5c29) -- Motor sends new calibration data
tgt:MT typ:2 src:BT [10-0221-0900-ab] [0900] - PUT DATA - OK 00
tgt:BT typ:0 [10-20-68] - HANDOFF
tgt:MT typ:1 src:BT [10-0122-0800df-58] [0800df] - GET DATA 00df -- No idea why this is, but seems to be part of it :)
tgt:BT typ:2 src:MT [10-2201-0801-ba] [0801] - GET DATA - OK 01
 
K

kodel

Dabei seit
28.07.2022
Beiträge
32
Punkte Reaktionen
22
I just wanted to point out that the XHP motor works differently from the log above. The other motors send back a calibration value for the battery to store. On power on, the motor retrieves this value from the battery. But the XHP motor doesn't do this: it never requests or sends the calibration data.
Not very important since the existing code handles this nicely, but worth noting in demistifying the rest of the protocol.

Next step is to create a full log whilst driving. I'm eager to find out how the throttle boost function works and if we can maybe override it's limited duration in software :)
 
Thema:

Zweiter Frühling für ION-Antrieb --- Sparta, Batavus, Koga ...

Zweiter Frühling für ION-Antrieb --- Sparta, Batavus, Koga ... - Ähnliche Themen

Sparta ION Akku defekt?: Hallo zusammen, ich bin neu hier, vielen Dank für die Aufnahme...und ich komme gleich mit einem Problem/Frage. Meine Frau fährt (wenig, da sie...
Sparta Ion, Hercules emove, Batavus, Koga auf Li-Ion Akku umbauen reparieren.: Ich bin Besitzer zweiter solcher Bikes und habe diese nach einem Akkudefekt erfolgreich umgebaut. Gleich vorweg, es ist zeitaufwendig, man sollte...
Sparta M7e ion Antrieb von 2016: Hallo Leute, kurz zu mir: Ich bin seinerzeit mit einem Bausatz aus China angefangen (mit dem ich mich entsetzlich auf die Nase gelegt habe), dann...
verkaufe Koga E-Runner, Rh 47cm, ION-Antrieb, wie neu, super ausgestattet: Schnäppchen: Koga E-Runner, nur EUR 2.050,-/Neupreis EUR 3.000,- muß wg OP leider verkaufen, Fahrrad kaum genutzt, Heck-Motor ION-Antrieb (33 Nm)...
erledigt E-Bike SPARTA Blackline ION mit Garantie: BeschreibungHalle verkaufe hier ein E-Bike von Sparta, Model Black Line kompl. mit Ladegerät. Das E-Bike war ein Ausstellungsstück und hat das...
Oben