search

EFeru / hoverboard-firmware-hack-FOC

With Field Oriented Control (FOC)
GNU General Public License v3.0
1.17k stars 965 forks source link

Battery Low LED blinking, although battery is charged and ADC calibrated #505

Open Spb2005 opened 3 months ago

Spb2005 commented 3 months ago

Variant

ADC

Control type

FOC

Control mode

Voltage

Description

The battery level LED blinks red slowly and the board emits a quiet chirping sound (not beeping). The sound resembles coil whine, but I am not sure if it comes from the motors, the mainboard, or the speaker. I have calibrated the battery ADC and receive correct voltage values during debugging (around 40.6V). Sometimes the red blinking LEDs stop, but as soon as I raise the throttle to around 20%, the red blinking returns. I have measured the battery under load, and it only drops slightly (to 39.7V). What could be the problem? Are the red LEDs related to the battery, or is it some other type of error? I used USART3 for debugging and did not disable debugging, only connecting the sideboard and LEDs. Could that be causing the issue?

Candas1 commented 3 months ago

Hi,

Which red led are you talking about? The onboard one? Only the sideboard leds are used for the battery level.

Spb2005 commented 3 months ago

I am talking about the 6 leds, that are connected to the right sideboard.

Candas1 commented 3 months ago

Those leds usually have different colors https://github.com/EFeru/hoverboard-firmware-hack-FOC/wiki/Battery#bell-battery-level-low-alerts

Spb2005 commented 3 months ago

What do you mean with they having different colors. After powering up 2 LEDs blink green. Then sometimes 2 Red LEDs blink (like the battery was low, but it isn´t and i dont have the beeps for a low battery). Could it be an other error message, that is shown with the 6 LEDs arranged in an circle?

Henrikmakes commented 3 months ago

I also tried getting the battery indication to work over the past week. During the actual powerup when the melody plays all 6 blink in some circular motion pattern briefly, so I know they work. After the powerup the two oppsing green leds blink one time then nothing.

I have not been debugging anything and I just plopped values into the config based on my batterys discharge graph. When i first looked at the values in the config it seemed like the default battery was some lipo pack (high voltage range) while I am using packs built out of 18650. Earlier 25R's and more recently Mj1's. Still 10s.

I think I have activated the needed lines in the config. Will continue to investigate the coming week. One thing i was suspecting is that I might have the ledboard from a different hoverboard compared to the sideboard if that could make a difference, but on the other hand the leds do show signs of life during powerup. Its likely a code/calibration issue from that point of view.

Candas1 commented 3 months ago

Are you sure you use the right variant ? https://github.com/EFeru/hoverboard-sideboard-hack-GD#example-variants

At startup it can blink red if the MPU is not supported, but it's not really used anyway: https://github.com/EFeru/hoverboard-firmware-hack-FOC/wiki/Sideboards

Then you need the right variant and the mainboard should be able to communicate with the sideboard.

Henrikmakes commented 3 months ago

According to this text I should use the STM-firmware because the sideboard in question has the STMF103C8T6 chip. I dug out the other sideboard from the same hoverboard and they look identical as far as I can tell. The stm firmware is what has been flashed.

_**The GD firmware can be used on boards with following chips:

GD32F130C6T6 GD32F130C8T6 The STM firmware can be used on boards with following chips:

STM32F103C8T6 GD32F103C8T6**_

WIN_20240805_13_29_04_Pro

I noticed when programming the mainboard from this particular hoverboard that the GND and SWDIO were switched. I know this has been mentioned in the documentation somewhere, even if I havent seen it before. (have reprogrammed 4 other mainboards prior to this one) With this in mind could it be possible the RX and TX to the sideboards is flipped? I can easily try it but unsure if it can cause damage in some way.

Edit: Isn't the fact that the leds blink in the circular motion pattern at startup proof that the wiring is correct?

Candas1 commented 3 months ago

I am not talking about the chip, both GD32 and STM32 firmwares have same functionnalities, but it's for different chip brands. There are different variants to select in the firmware for the sideboards, same as for the mainboard firmware. Hovercar variant should also be selected for the sideboard firmware.

Henrikmakes commented 3 months ago

I have selected the hovercar variant through platformio before codebuild and flash of the sideboard. Similar to how I did for the mainboard.

In the config I have not changed the settings under hovercar. The serial_aux_rx looked ok to me to receive the data from the mainboard.

I couldn't see any other settings that seemed like they needed tinkering with. That said there are plenty of stuff I dont know what they are in detail. :)

/ ==================================== VARIANT HOVERCAR ==================================== /

ifdef VARIANT_HOVERCAR

define SERIAL_CONTROL // [-] Define for Serial Control via the serial port

define SERIAL_FEEDBACK // [-] Define for Serial Feedback via the serial port

define SERIAL_AUX_RX // [-] Use AUX4, AUX5 as USART port

// #define SERIAL_AUX_TX // [-] Use AUX4, AUX5 as USART port

define CONTROL_IBUS

define IBUS_NUM_CHANNELS 14 // Total number of IBUS channels to receive, even if they are not used.

define IBUS_LENGTH 0x20

define IBUS_COMMAND 0x40

endif

Candas1 commented 3 months ago

if you selected VARIANT_HOVERCAR it should be fine. If it blink red because of the MPU, you can try disabling it by commenting our #define MPU_SENSOR_ENABLE as you don't need it anyway.

Spb2005 commented 3 months ago

So i hadn´t even flashed an firmware to the sideboard. Now i have tried out the hovercar and the hoverboard firmware for the sideboard and in both cases the orange/yellow LEDs started blinking, while the battery is still fully charged. Is that the MPU error? (I have the MPU6052C)

Candas1 commented 3 months ago

Those leds usually have different colors https://github.com/EFeru/hoverboard-firmware-hack-FOC/wiki/Battery#bell-battery-level-low-alerts

That's what you should get if it's working and if your battery is correctly calibrated

Henrikmakes commented 3 months ago

I made another go at flashing the mainboard and nothing changed. Did a fully fresh flash incase I had caused some unintended changes by fiddling with the code, but no change.

THen I tried to also activate the sideboard RX to receive commands from the lightswitches and then it started working. image

So now it seems its only a matter of calibration, but it doesnt seem too off but I now have an ftdi device so I can dig more into this. Now jusdt to get the brake functionality back despite using the stretched brake adc span.

Candas1 commented 3 months ago

THen I tried to also activate the sideboard RX to receive commands from the lightswitches and then it started working.

Isn't this the default value

Henrikmakes commented 3 months ago

THen I tried to also activate the sideboard RX to receive commands from the lightswitches and then it started working.

Isn't this the default value

You are correct, I did double check by downloading another untouched version of the code. Either I had by mistake altered this in my fresh untouched copy directory intended for reference or the code I had downloaded way back was different. It is likely the prior because I knew nothing when I first started and now I know a tiny bit. At the time I didnt plan to use the sideboards to keep it simple and maybe I changed this. Conclusion is that both the RX and TX lines seem to be needed for the battery lights. Thanks again for the replies.