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

[void-spark]

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?

Cool!
Yes, that should be possible if the original system does that, for motors that support it. the command should be pretty easy to find in the logs.
Would probably need to make another version of the firmware for it though, yet more configuration options

 

[gpu7990]

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

Hi latest cu2 release has broken
it cycles assistance modes and does not detect battery voltage.
I used firmware with first added time support and it works fine.

 

[void-spark]

Hi latest cu2 release has broken
it cycles assistance modes and does not detect battery voltage.
I used firmware with first added time support and it works fine.

Oops, that could be possible!
I don't have a easy CU2 test setup anymore, but I should be able to hook up a CU2 to the test circuit on my desk with a 'virtual' motor.
Could you give as detailed as possible description of the issue you see, which parts do you use, link to the build, and what you do/click and how it reacts?
Or at least, the quickest way to reliably reproduce something that is clearly wrong?
It should help me look into it faster

 

[gpu7990]

Oops, that could be possible!
I don't have a easy CU2 test setup anymore, but I should be able to hook up a CU2 to the test circuit on my desk with a 'virtual' motor.
Could you give as detailed as possible description of the issue you see, which parts do you use, link to the build, and what you do/click and how it reacts?
Or at least, the quickest way to reliably reproduce something that is clearly wrong?
It should help me look into it faster

Oops, wrong pin, 35 is ADC, 34 is charge · void-spark/[email protected]
cu2 + toprun motor. Assist modes switches 1-2-3-1-2-3....(1sec all cycle) and blue led blinks continiously.

 

[Mike747]

It's battery-time

PMU4 vs PMU3

 

[Mike747]

Well, PMU3 was not much of a surprise: this is an 8S version:

I do find PMU4 quite impressive: it simply comes apart after removing a few screws ! It does look nicely built.

 

[gpu7990]

Void-spart, can you please add a function like bms cutt off? one pin with active low when voltage on battery pin reach 2700mv. And active high all time before 2700mv

 

[void-spark]

Void-spart, can you please add a function like bms cutt off? one pin with active low when voltage on battery pin reach 2700mv. And active high all time before 2700mv

It should be possible! But I have concerns about the stability of the voltage measurement, so far it's been no very reliable. Haven't figured out yet if it's esp32, hardware, or software

 

[void-spark]

Oops, wrong pin, 35 is ADC, 34 is charge · void-spark/[email protected]
cu2 + toprun motor. Assist modes switches 1-2-3-1-2-3....(1sec all cycle) and blue led blinks continiously.

Finaly wired up CU2 on my desk test setup, and I see exactly what you describe, thank you
At least its easy to reproduce! Easy to reproduce bugs are usually easier to fix

 

[void-spark]

Hi latest cu2 release has broken
it cycles assistance modes and does not detect battery voltage.
I used firmware with first added time support and it works fine.

Found it, should be fixed from this version and later: Oops, used wrong event group · void-spark/[email protected]

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

I have added a gpu7990 custom for now, find it here: Add gpu7990 custom · void-spark/[email protected]
Let me know if it needs any other changes

 

[gpu7990]

Thanks! now I can make complete bms-charge-emulation board for ni-mh batteries without any PIC for dV charge method

 

[void-spark]

Void-spart, can you please add a function like bms cutt off? one pin with active low when voltage on battery pin reach 2700mv. And active high all time before 2700mv

Just to be clear and make sure, this part is not implemented (yet?)
Actually, is this meant to be a high cut off? I thought you wanted a low cutoff
On the upside, with charging the voltage would at least be stable, but you would lack accuracy, and for charging I think you want it pretty accurate
What is the 2700mv based on?

Thanks! now I can make complete bms-charge-emulation board for ni-mh batteries without any PIC for dV charge method

 

[gpu7990]

Just to be clear and make sure, this part is not implemented (yet?)
Actually, is this meant to be a high cut off? I thought you wanted a low cutoff
On the upside, with charging the voltage would at least be stable, but you would lack accuracy, and for charging I think you want it pretty accurate
What is the 2700mv based on?

I have 115k/12k voltage divider , thats 2695-2700mv with 28.5 input
For accuracy - no, thats not needed for me, because for ni-mh overheating is not dangerous and charge to 95-97% also not big deal
So yes i need high cut off, before 2700mv- high level on pin, after 2700 - low.
Also if you have time, then please cu3 and cu2 version based on mike variant.

 

[VSijts]

Found it, should be fixed from this version and later: Oops, used wrong event group · void-spark/[email protected]


I have added a gpu7990 custom for now, find it here: Add gpu7990 custom · void-spark/[email protected]
Let me know if it needs any other changes

I see the builds and files, but how can i download them?

Ah, und ich bin neu hier. Ich bin sehr beeindruckt mit wie weit sie sind. Meiner deutsch is nicht so gut, so wenn es dir nichts ausmacht, rede ich lieber auf english.

 

[Mike747]

Welcome!

I see the builds and files, but how can i download them?

You need to login on github and then the "artifacts" can be downloaded.

 

[void-spark]

Welcome!

You need to login on github and then the "artifacts" can be downloaded.

It took me a while to realize that, I'm always logged into GitHub, didn't know that was a requirement to download
It would be easier if things were stored under 'releases', but there's no 'easy' way to do that automatically I could find, so it would take time to set up too

 

[VSijts]

i just got my esp32-c3 in. after flashing the device keeps reconnecting (have nothing connected or set up on the board yet). Is this normal behaviour? I used the esp32c33 cu2 build

 

[Mike747]

i just got my esp32-c3 in. after flashing the device keeps reconnecting (have nothing connected or set up on the board yet). Is this normal behaviour? I used the esp32c33 cu2 build

I think the build (-s) are for a regular ESP, but I am not sure!

 

[void-spark]

i just got my esp32-c3 in. after flashing the device keeps reconnecting (have nothing connected or set up on the board yet). Is this normal behaviour? I used the esp32c33 cu2 build

Well, kinda maybe? Reconnecting to the serial terminal?
That might indicate a boot loop, which wouldn't be quite what I'd expect. I'd have to see the logs of the serial out

But since the device is rather pin constrained (only 6 'usable' pins), The tx/rx pins get reassigned as soon as it boots. So I do expect serial output to stop suddenly when it boots 'normally' after flashing.

I think the build (-s) are for a regular ESP, but I am not sure!

Some builds are for c3, its in the file name. And the flasher wont flash a build for the wrong chip, so if it flashed it was the one meant for it

 

[VSijts]

Seems like a checksum failure?

00:30:07.669 -> ESP-ROM:esp32c3-api1-20210207
00:30:07.669 -> ESP-ROM:esp32c3-api1-20210207
00:30:07.669 -> Build:Feb 7 2021
00:30:07.669 -> rst:0x15 (USB_UART_CHIP_RESET),boot:0x8 (SPI_FAST_FLASH_BOOT)
00:30:07.669 -> Saved PC:0x40047ed2
00:30:07.669 -> SPIWP:0xee
00:30:07.669 -> modeIO, clock div:1
00:30:07.669 -> load:0x3fcd5810,len:0x438
00:30:07.669 -> load:0x403cc710,len:0x91c
00:30:07.670 -> load:0x403ce710,len:0x25b0
00:30:07.670 -> Checksum failure. Calculated 0x08 stored 0x49
00:30:07.670 -> ets_main.c 333
00:30:08.741 -> ESP-ROM:esp32c3-api1-20210207
00:30:08.741 -> Build:Feb 7 2021
00:30:08.741 -> rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
00:30:08.741 -> Saved PC:0x40047ed2
00:30:08.741 -> SPIWP:0xee