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

[gpu7990]

Does not charging and no error codes, totally sleep, like it was on bananas error batteries after long time using.
I will try today the motor, I hope everything will work.

 

[gpu7990]

So fast... bike is little dangareous to drive.
Motor have 5 assist modes- no parking or reverse.
Also it is really 28Nm, it feels like toprun before 25km, big difference for 40Nm or 50Nm.
My motors:
28Nm e-speed up to 45 (10s 36v)
40Nm batavus royal up to 32 (ni mh 24v)
50Nm sparta r20i up to 24 (7s 25.2v)
So this definitely the 250whatt power limit by EU laws.
As we know - the more rpm on motor the more amps it takes.
Now my plans to experiments:
28Nm - change shunt on motor, should be 40-50Nm but still fast
40Nm - i will try to read controller
50Nm - have couple of ideas to add some speed , first is to change location of speed hall sensor(may be out of motor for test, and then place arduino nano that would devide pulses by two and send it to controller)
but for this mod i have doubts that phase switching work with internal timers in software wich depends of current. In this case there is also possibillity of changing quartz resonator. For example i try this trick already on UPS, that have autoff timer in 30min, if i replace 8mHz to 6mHz, it works 40mins and give 176volts(220 on 8mHz)

 

[Mike747]

28Nm - change shunt on motor, should be 40-50Nm but still fast

Does it have a shunt? Do you think Nm/power of the motor is determined by a shunt? I would not be surprised if the copper-wire windings are different. And probably the motor-software or even the motor pcb's themselves.
I hope you will find out more.

 

[gpu7990]

Here it is on toprun.
For now developers uses one method of dc current monitoring -
measurement of voltage drop and conversion of voltage and resistance into current.
Even if there is no shunt in xhp, this only means that the voltage drop is measured on the mosfets. For example a mosfet has Rds on 0.004 Ohm and measured voltage drop 34mV, 0.034/0.004= 8.5 amps, there is no more realible ways (except measurment of induction field with hall sensor) to know dc current.
So in this case i only need replace msfets with lower Rds.

 

[MetallicGreen]

For the next project (XHP-motor, 36V battery, kunteng display) I tried to build GitHub - void-spark/ion1: ESP32 firmware to drive a Sparta Ion motor but don't know where to start. Isnt the platformio.ini missing? How do I initialize the projekt after cloning the repository? Sorry if it is mentioned already in this thread.

 

[MetallicGreen]

Just answering myself: Got Platformio to work, but it does not support idf-5.0 yet, so no esp_adc. Will try the eclipse plugin for espressif next.

The post where the build environment ist described ist #322

 

[MetallicGreen]

In Eclipse, everything works out of the box (just remember to activate "clone all submodules") except one error:

C:/Users/h/git/ion1/main/main.cpp:77:79: error: 'portTICK_RATE_MS' was not declared in this scope; did you mean 'portTICK_PERIOD_MS'?
   77 |         const int rxBytes = uart_read_bytes(UART_NUM_2, data, rxReady, 1000 / portTICK_RATE_MS);
      |                                                                               ^~~~~~~~~~~~~~~~
      |                                                                               portTICK_PERIOD_MS

portTICK_RATE_MS is deprecated and should be replaced with portTICK_PERIOD_MS.

 

[Mike747]

I tried something different: "recell" a Sparta PMU3 Li-ion battery. I put the electronics from a 7S battery together with a 7S2P (240Wh) cell-pack in a X-series framebattery housing. What can possibly go wrong .

The good news is that it works: the battery charges fine and the support works as expected.
Unfortunately not everything works:
*from standby, it starts in supportmode 4 (not 1). I keep somehow running into this.
*the batterymeter (4 leds on ribboncable!) does not work in standby, the 4 leds do flash though. Yes, that means something is wrong .
*The only errorcode that the display gives though, is E0006 when I turn on the lights: "light defect" .

Observations:
PMU3 (that is the Li-ion batteries, PMU2 = NiMh) gives Vbatt to the display instead of 5V (PMU2) .
All components used (motor, battery-electronics, display and holder) come from the same bike.

 

[Mike747]

I am afraid I have to give the (this) PMU3 electronics up. The "light defect" might be the cause of the malfunction (or not ).
When I turn on the light, the lights actually turn on for about 2 seconds and then turn off, together with E0006 in the display.
If anyone has a suggestion of what part could malfunction and how to investigate, I am open for suggestions!

The li-ion versions (PMU3) however do have some differences compared to the Ni-Mh versions (PMU2). We may have to pay attention when using different parts together.
*When connecting a different motor to the battery, I got a different "total distance" (and E000023, unknown motor/battery). Is distance now stored in motor instead of battery? I think PMU3 also uses the round motor-connector instead of the "AMP superseal" flat connector.
*Displayholder gets battery voltage instead of 5V. Maybe that is what the extra electronics in the displayholder are for (I think there is more "passive voltage regulation parts" in the holders). The connector of the PMU3-displayholder is a black 4 pin connector (3 wires connected) or a white 3 pin connector.
There are also "PMU2-displayholders" (with black 3 pin connector) that have more electronics inside though!

 

[void-spark]

Well, no-one ever said it would be easy Great findings as always at least, maybe someday someone will write a Ion wiki
The only thing I can offer at the moment is decoding logs, but that won't make different parts magically work together
I guess it makes sense the newer the parts are, the more variations there are

 

[Mike747]

I made 3 logs from a PMU3 battery. The logs name start with "error" because the battery is not right.
1st: connect fuse, communication start when charger is plugged in. The battery is NOT connected to anything!
2nd: Battery is connected to "bike" (motor + display + light are connected through 6 pin battery connector).
From standby through the supportmodes and back and logo-mode (there is a service notification when support is selected).
3rd: from standby light was turned on, E0006 was displayed.

serial numbers: M511493479 XHP C212050697 GB1213000279

 

[Mike747]

Funny addition: when connecting a PMU3 battery to an XHP motor, you get the kms stored in the motor (It is a different number for each motor connected ).
This also works when connecting to an XHP motor that was always paired with a PMU2 battery! PMU2 batteries store kms in the battery itself and send it to the display (as far as we know).
@VoidSpark: maybe it is possible to obtain distance from the motor instead of generating it in software on the ESP?

 

[Mike747]

Looking into powering the displays and standbymodes I found the following:

PMU3, (4 pin connector/3 pin white connector) gives Vbatt to power display.
Logo-mode (logo on display): Vbatt and BOW = active
Standy (blank display): 0V and BOW = high = Vbatt

NiMh PMU2 battery

PMU2, the straight version frame-battery has both 3 pin (5V) and 4 pin (Vbatt) connector to connect display to (not sure you are supposed to use the 4 pin ).
3 pin connector = 5V to power display -> remains 5V in logo-mode and standby.
logo-mode: motor-power is cut off, BOW = active
Standby (blank display): BOW = high = Vbatt

4 pin connector: gives Vbatt to power display. Turns power on and off with motor-relais (about 0.1V remains).
Logo-mode: well, there is no logo-mode . When you turn of the support, the relais clicks and display goes off. 0.1V and BOW = high = Vbatt
If I only turn on the system, it remains active for a few minutes (I guess the realis stays open) and then goes off (no logo mode).
Standby (blank display): 0.1V and BOW = high = Vbatt

 

[gpu7990]

Looking into powering the displays and standbymodes I found the following:

PMU3, (4 pin connector/3 pin white connector) gives Vbatt to power display.
Logo-mode (logo on display): Vbatt and BOW = active
Standy (blank display): 0V and BOW = high = Vbatt

Anhang anzeigen 487328NiMh PMU2 battery

PMU2, the straight version frame-battery has both 3 pin (5V) and 4 pin (Vbatt) connector to connect display to (not sure you are supposed to use the 4 pin ).
3 pin connector = 5V to power display -> remains 5V in logo-mode and standby.
logo-mode: motor-power is cut off, BOW = active
Standby (blank display): BOW = high = Vbatt

4 pin connector: gives Vbatt to power display. Turns power on and off with motor-relais (about 0.1V remains).
Logo-mode: well, there is no logo-mode . When you turn of the support, the relais clicks and display goes off. 0.1V and BOW = high = Vbatt
If I only turn on the system, it remains active for a few minutes (I guess the realis stays open) and then goes off (no logo mode).
Standby (blank display): 0.1V and BOW = high = Vbatt

It is better to assemble a replacement for the standard control board from a normal bms with balancing and dc dc with cc cv for charging.
But if you still want to look for where the breakdown is, then you need to carry out reverse engineering with a tester on a completely cleaned board from sealant. From the positive contact of turning on the light, look for all connections with the microcontroller, most likely there is either a "power good" check - that is a separate pin of the microcontroller that waiting for a high level when the light is turned on. Or the second option there is a circuit for measuring the current of lighting (protection against short circuits) Also pay attention to the inter-board flex-cable, it had a crack on my board.

 

[gpu7990]

How i can compile cu2 version with active high for light? Or maybe you have alreadt precompilled such variant?

 

[Mike747]

But if you still want to look for where the breakdown is, then you need to carry out reverse engineering with a tester on a completely cleaned board from sealant. From the positive contact of turning on the light, look for all connections with the microcontroller, most likely there is either a "power good" check - that is a separate pin of the microcontroller that waiting for a high level when the light is turned on. Or the second option there is a circuit for measuring the current of lighting (protection against short circuits) Also pay attention to the inter-board flex-cable, it had a crack on my board.

Thanks for the reply. Good place to start for me! I may look into it (someday ).
For now I am using it to find differences and improvements that we can use in our (newer) setups. The way the display (holder) is powered and how 5 assist-levels are/should function, I hope te find out (a bit) more.

How i can compile cu2 version with active high for light? Or maybe you have alreadt precompilled such variant?

First pass at smoothing bat%, average over · void-spark/[email protected]
Is there a variant that suits you?
Zweiter Frühling für ION-Antrieb --- Sparta, Batavus, Koga ...

 

[gpu7990]

Thanks for the reply. Good place to start for me! I may look into it (someday ).
For now I am using it to find differences and improvements that we can use in our (newer) setups. The way the display (holder) is powered and how 5 assist-levels are/should function, I hope te find out (a bit) more.

First pass at smoothing bat%, average over · void-spark/[email protected]
Is there a variant that suits you?
Zweiter Frühling für ION-Antrieb --- Sparta, Batavus, Koga ...

I see only CU2 std
And Mike variant only cu3
As i see in description std have active low.

 

[void-spark]

How i can compile cu2 version with active high for light? Or maybe you have alreadt precompilled such variant?

Sorry, I've been distracted
The 'easiest' way to compile your own variant is to:
- Create a github account, and log in
- Go to GitHub - void-spark/ion1: ESP32 firmware to drive a Sparta Ion motor
- Click the 'fork' button in the upper right, to create your own fork of the source code.
- Use the built in text editor in github to edit the config files in your fork, I'm guessing you use esp32 (not esp32c3), so the files you can change are (lowest file overrides the ones above it):
-- sdkconfig.defaults
-- sdkconfig.defaults.esp32 << This is the one you want to change for your case I think
-- sdkconfig.cu2
- When you've done the change, it should already start building, you can find the result when it's done under actions

 

[void-spark]

It's a 'problem' I've been considering, as we get more different versions, the custom builds don't scale so well anymore. I can only build so many without going through my allowances on github It's pretty hard to allow custom builds in an easy way though. Creating a web site for it (besides being a lot of work) means hosting it somewhere, and that creates interesting problems with people asking 1000 builds from it and such So far the GitHub Actions approach is the best I've found. It's not super easy, but it's pretty doable.

 

[void-spark]

I made 3 logs from a PMU3 battery. The logs name start with "error" because the battery is not right.
1st: connect fuse, communication start when charger is plugged in. The battery is NOT connected to anything!
2nd: Battery is connected to "bike" (motor + display + light are connected through 6 pin battery connector).
From standby through the supportmodes and back and logo-mode (there is a service notification when support is selected).
3rd: from standby light was turned on, E0006 was displayed.

serial numbers: M511493479 XHP C212050697 GB1213000279

Sorry, here are the translations