Gen2.1.4 (ex2.3)

[mateuszfcg]

Hello. Has anyone run the disc version 2.3? At first I had a problem with uploading any batch, but I managed to do it for a while. now I have trouble starting it. when I connect the power supply, the engine only starts slightly and holds it in one position. I cannot establish communication with Arduino. I tried on different GD pins. please help. Does anyone have the file already configured for this disc? Regards

[mateuszfcg]

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/assets/83178714/dd9dc10b-a573-4dd5-8a3f-bd0c1a6c5101

I added my own line as a quick check on the connection itself when turning the motor

#ifdef test_hall 
gpio_bit_write(LED_GREEN_PORT,LED_GREEN,hall_a);
gpio_bit_write(LED_ORANGE_PORT,LED_ORANGE,hall_b);
gpio_bit_write(LED_RED_PORT,LED_RED,hall_c);    

#endif

[mateuszfcg]

i also noticed that when the power supply is connected, the motor weighs down when pulled by hand. test mode is deactivated ?

Where can I find the code for driving the mosfet controller?

[RoboDurden]

setup.c:255 PWM_init(void) bldc.c:137 CalculateBLDC(void) and :75 blockPWM(int pwm, int pwmPos, int *y, int *b, int *g)

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/assets/12238841/7907387a-248d-43a5-9970-ae5cabb5c916 you need a video player with h265 codec.

[DerPinguin77]

@mateuszfcg How did you get the new code running on your board. Ive trieed several times flashing it and the firmware didnt work. There is no startup beep. The motor makes whiered noises and you can hear the mosfets "Hiss". If go back to the old firmware it does work again. I have made shure i selected the right taget and the 2.3 board. Alto ried to change your difference iun de defined.h ba it changed nothing Also the motor is completly blocked and cant be moved by hand.

[RoboDurden]

I am sorry for this confusion :-/ Unfortunately you both do not fork my repo but download zip files and make changes localy that i can not verify. Normaly, you fork my repo and use "Github Desktop" to clone your own fork to your local computer. Then you push your local changes to your fork and make a pull request like https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/pull/24/files Then i can see what changes you have made to the code.

My last bigger update was accepting that pull request and introducing these RemoteXY classes. I am not aware that i did change anything to the mosfet/bldc code.

You could try to copy the defines_2-3.h from your old (working) copy to my latest version. Then you could try to copy the old setup.c to the new version. then the old bldc.c to the new version.

Again, as i do not really know what code you are running, i can not really help.

[mateuszfcg]

I will upload my code in the evening.

[DerPinguin77]

Im sorry i am just dumb. I forgot to build the software after changing the version, so I always flashe the software for the wrong board. Now it is working. In my case the one of the leds is not lighting up and it younds like its skippikg steps so maybe its a problem with one the hall sensors either in software or on the hardware. I will try another motor and let you know.

[RoboDurden]

Check the hall sensors with a multimeter. You need to test the hall pins on the three little smd resistors you have trace. But the red probe of the multimeter should be thin enoug the go into the female header:

They need 5V to send their state.

I have never come across a motor being broken.

[DerPinguin77]

Yeah i tested it and the motor is fine. But I think may be something messed up in the code with the hall sensors.

[RoboDurden]

@DerPinguin77 you really should start using your brain.

In my case the one of the leds is not lighting

Which color ??

And by now you should be able to turn this led on in main() using DEBUG_LedSet(SET)

And when you are sure the led pin is correct, then there must be something wrong with the hall pin that should turn this led on.

[DerPinguin77]

@RoboDurden Im just trying my best. I have never worked with this Software nor programmed anything in C. I thy my best to help with stuff that I can do like for exampe measuring stuff, or suggestions that i can give (maybe theire dumb or wrong but i try my best). Red and Green LEDs are lighting up when i spin the motor yellow is not working. I am using the software right from your git without any changes.

[mateuszfcg]

#ifdef test_hall 
gpio_bit_write(LED_GREEN_PORT,LED_GREEN,hall_a);
gpio_bit_write(LED_ORANGE_PORT,LED_ORANGE,hall_b);
gpio_bit_write(LED_RED_PORT,LED_RED,hall_c);    

#endif

Check if you have it running. In my case the LED pointing was not working so I added simple code. In config.h you must have ``

define test_hall

`` And check the LED pins carefully to make sure they are ok.

Another issue maybe something is defective with the control of the orange LED. Try swapping pins, e.g. red and orange, to see if it lights up

[DerPinguin77]

Hi i think i found the problem. The hall or the motor pins seem to be swapped. In the Video you can see the "wrongly" connectad motor phases to make it work.

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/assets/145379857/47a2b830-41d1-4e33-ae2b-c9b8318062a1

[DerPinguin77]

Here is another photo of the combination that worked.

[DerPinguin77]

Hi, @RoboDurden Today i spent some time finding the right pins and changing them in the code. I no got the motor running smoothly. I downloaded the zip and exept for the version i only changed some wrong pins in defines_2.3.h. Stuff i changed:

• Changed the Hall Pin Order => Motor runs smoothy now
• Changed the Led Pins => Orange LED works now, Led colors are like they are named in the Code
• changed the Power latch pin=> Powerlatch works now and you dont need tho hold the button to keep it on.

For the last one I just copied the code from @mateuszfcg Would be cool if someone could get the Voltage and Current sense pins working as I am not skilled enough to do so.

I also got the UART control running with the ESP and I was able to control the motor with a poti.

This is my defines 2.3.h:

#ifdef MASTER   // this layout has buzzer on the master board !
    #define BUZZER
#endif

//#define TODO_PORT GPIOA               // this should be a pin that does no harm if input or output
//#define TODO_PIN  GPIO_PIN_15 // B15 is not accessibla on the smaller QFN32 32 pin MCU version
#define TODO_PORT   GPIOF       // this should be a pin that does no harm if input or output
#define TODO_PIN    GPIO_PIN_4  // PF4 is only accessible on the largest GD32F130Rx LQFP64 pinouts mcu

// LED defines, colors probably mismatch !
#define LED_GREEN           GPIO_PIN_3
#define LED_GREEN_PORT  GPIOB
#define LED_ORANGE          GPIO_PIN_4
#define LED_ORANGE_PORT GPIOB
#define LED_RED                 GPIO_PIN_15
#define LED_RED_PORT        GPIOA

#define UPPER_LED_PIN   GPIO_PIN_4
#define UPPER_LED_PORT  GPIOB
#define LOWER_LED_PIN   GPIO_PIN_5
#define LOWER_LED_PORT  GPIOB

#define DEBUG_LED_PIN   LED_RED
#define DEBUG_LED_PORT  LED_RED_PORT

// Mosfet output
// seems to be an ordinary LED output ?
// led.c:91 gpio_bit_write(MOSFET_OUT_PORT, MOSFET_OUT_PIN, counter_Blue >= setValue_Blue ? RESET : SET); 
#define MOSFET_OUT_PIN TODO_PIN     // TODO
#define MOSFET_OUT_PORT TODO_PORT   // TODO

// Brushless Control DC (BLDC) defines
#define TIMER_BLDC_PULLUP   GPIO_PUPD_PULLUP    // robo, based on Herleybob:defines.h
// Channel G
#define RCU_TIMER_BLDC RCU_TIMER0
#define TIMER_BLDC TIMER0
#define TIMER_BLDC_CHANNEL_G TIMER_CH_2
#define TIMER_BLDC_GH_PIN       GPIO_PIN_8      // channels G=green and Y=yellow swopped compared to 2.0
#define TIMER_BLDC_GH_PORT  GPIOA
#define TIMER_BLDC_GL_PIN       GPIO_PIN_13
#define TIMER_BLDC_GL_PORT  GPIOB
// Channel B
#define TIMER_BLDC_CHANNEL_B TIMER_CH_1
#define TIMER_BLDC_BH_PIN       GPIO_PIN_9
#define TIMER_BLDC_BH_PORT  GPIOA
#define TIMER_BLDC_BL_PIN       GPIO_PIN_14
#define TIMER_BLDC_BL_PORT  GPIOB
// Channel Y
#define TIMER_BLDC_CHANNEL_Y TIMER_CH_0
#define TIMER_BLDC_YH_PIN       GPIO_PIN_10
#define TIMER_BLDC_YH_PORT  GPIOA
#define TIMER_BLDC_YL_PIN       GPIO_PIN_15
#define TIMER_BLDC_YL_PORT  GPIOB

// Timer BLDC short circuit emergency shutoff define
// Is initialized here but never used somewhere else in code.
// setup.c:176  gpio_mode_set(TIMER_BLDC_EMERGENCY_SHUTDOWN_PORT , GPIO_MODE_AF, GPIO_PUPD_NONE, TIMER_BLDC_EMERGENCY_SHUTDOWN_PIN);  
#define TIMER_BLDC_EMERGENCY_SHUTDOWN_PIN       TODO_PIN    // TODO
#define TIMER_BLDC_EMERGENCY_SHUTDOWN_PORT  TODO_PORT       // TODO

// Hall sensor defines
// Der_Pinguin tested with PA0,PA1,PA2 and it works fine now 
#define HALL_A_PIN  GPIO_PIN_0
#define HALL_A_PORT GPIOA
#define HALL_B_PIN  GPIO_PIN_1
#define HALL_B_PORT GPIOA
#define HALL_C_PIN  GPIO_PIN_2
#define HALL_C_PORT GPIOA

// Usart master slave defines
//#define USART_MASTERSLAVE USART1  // robo no second uart port for this board
#ifdef USART_MASTERSLAVE
    #define USART_MASTERSLAVE_TX_PIN    TODO_PIN
    #define USART_MASTERSLAVE_TX_PORT   TODO_PORT
    #define USART_MASTERSLAVE_RX_PIN    TODO_PIN
    #define USART_MASTERSLAVE_RX_PORT   TODO_PORT
#endif

// Usart steer defines
#define USART_STEER_COM USART0                  
#ifdef USART_STEER_COM
    #define USART_STEER_RCU RCU_USART0          
    #define USART_STEER_AF  GPIO_AF_0               
    #define USART_STEER_COM_TX_PIN  GPIO_PIN_6
    #define USART_STEER_COM_TX_PORT GPIOB
    #define USART_STEER_COM_RX_PIN  GPIO_PIN_7
    #define USART_STEER_COM_RX_PORT GPIOB
#endif

// ADC defines
//#define VBATT_PIN GPIO_PIN_0      // uncomment this line when you have verified the pin/port
#define VBATT_PORT GPIOA            
#define VBATT_CHANNEL ADC_CHANNEL_17
//#define CURRENT_DC_PIN    GPIO_PIN_1  // uncomment this line when you have verified the pin/port
#define CURRENT_DC_PORT GPIOA
#define CURRENT_DC_CHANNEL ADC_CHANNEL_2

// Self hold defines
// important pin keeps the mosfet open after the on/off button got pushed !
// main.c:306: gpio_bit_write(SELF_HOLD_PORT, SELF_HOLD_PIN, SET); 
// and turns off power on Shutdown:
// main.c:513:   gpio_bit_write(SELF_HOLD_PORT, SELF_HOLD_PIN, RESET); 
#define SELF_HOLD_PIN       GPIO_PIN_3      // lerwinDE: master: A11 is used a hold bin, slave: A11 is buzzer pini
#define SELF_HOLD_PORT  GPIOA               // TODO

// Button defines
// on/off (POW) push-button. So also a connection (i guess with some smd resistor in between) to a MCU pin.
// main.c:457: if (gpio_input_bit_get(BUTTON_PORT, BUTTON_PIN)) 
#define BUTTON_PIN  GPIO_PIN_4          // robo, based on Herleybob:defines.h
#define BUTTON_PORT GPIOA                       // robo, based on Herleybob:defines.h

#ifdef BUZZER
    // Buzzer defines
    #define BUZZER_PIN  GPIO_PIN_11     // robo, based on Herleybob:defines.h
    #define BUZZER_PORT GPIOA               // robo, based on Herleybob:defines.h
#endif

#ifdef MASTER

    // Charge state defines
    // This seems to be a digital input that hast to be high in order to enable the motors. 
    // main.c:381: chargeStateLowActive = gpio_input_bit_get(CHARGE_STATE_PORT, CHARGE_STATE_PIN);
    // If not found it should be okay to simply comment this line because chargeStateLowActive in initialised as set = true
    #define CHARGE_STATE_PIN GPIO_PIN_0     // TODO
    #define CHARGE_STATE_PORT GPIOF             // TODO
#endif

// photo diodes / light barriers on the backside
#define PHOTO_L_PIN     GPIO_PIN_15
#define PHOTO_L_PORT    GPIOC
#define PHOTO_R_PIN     GPIO_PIN_14
#define PHOTO_R_PORT    GPIOC

// Debug pin defines - seems to be never used in code.
#define DEBUG_PIN TODO_PIN  // TODO
#define DEBUG_PORT TODO_PORT            // TODO`

[RoboDurden]

Great you succeeded with the motor pins, led pins, esp32 communication and also adding a potentiometer to the ESP32 :-) Possible adc pins are

PA0 6    ADC_IN0
PA1 11   ADC_IN1
PA2 12   ADC_IN2
PA3 13   ADC_IN3
PA4 14   ADC_IN4
PA5 15   ADC_IN5
PA6 16   ADC_IN6
PA7 17   ADC_IN7
PB0 18   ADC_IN8
PB1 19   ADC_IN9

of which you have traced 7:

PA3 13   ADC_IN3
PA4 14   ADC_IN4
PA5 15   ADC_IN5
PA6 16   ADC_IN6
PA7 17   ADC_IN7
PB0 18   ADC_IN8
PB1 19   ADC_IN9

PA3 and PA4 are already taken for BUTTON_PIN and HOLD_PIN

That leaves 5 pins to test wise assign to

#define VBATT_PIN   GPIO_PIN_X
#define VBATT_PORT GPIOY
#define VBATT_CHANNEL ADC_INZ

and read the log data from the ESP32 while changing the voltage of the power supply.

I guess that PB0 and PB1 will be the mosfet lowside gate currents. PA7 and PA6 also come from a dual opamp chip so maybe the third lowside gate current (which is not really needed) and the overal currentDC.

So i would start with PA5 to be the battery voltage:

#define VBATT_PIN   GPIO_PIN_5
#define VBATT_PORT GPIOA
#define VBATT_CHANNEL ADC_IN5

[DerPinguin77]

I have already tried those pins but i only changed the VBATT_CHANNEL ADC_CHANNEL. I was afraid to break somethin because of the uncommented comment. So is it safe to uncomment this line and try all the pins out? With only the Vbat_Channel nothing happened with any ot the pins.

//#define VBATT_PIN GPIO_PIN_0 // uncomment this line when you have verified the pin/port

define VBATT_PORT GPIOA

define VBATT_CHANNEL ADC_CHANNEL_17

[RoboDurden]

i have updated my pervious comment !

if you do not uncomment the VBATT_PIN definition, no battery voltage will be calculated in bldc.c :

    #ifdef VBATT_PIN
        if (buzzerTimer % 100 == 0)
            batteryVoltage = batteryVoltage * 0.999 + ((float)adc_buffer.v_batt * ADC_BATTERY_VOLT) * 0.001;
    #else
        batteryVoltage = BAT_CELLS * 3.6;       // testing with no VBATT_PIN yet
    #endif

[DerPinguin77]

So i tested all of the 7 traced pins. The voltage pin is definetly right. I tested it with different voltages and it was only about 1V off. Maybe it need a little calibration. With the current sense pin i am not quite shure. The numbers seem right but one decimal to the left. They fluctuate quite a bit but it seems right. All of the other pins just gave random values of about -200 so i dont think it has anything to do with the current. These are the final pins i came up with:

// ADC defines

define VBATT_PIN GPIO_PIN_5 // uncomment this line when you have verified the pin/port

define VBATT_PORT GPIOA

define VBATT_CHANNEL ADC_CHANNEL_5

define CURRENT_DC_PIN GPIO_PIN_6 // uncomment this line when you have verified the pin/port

define CURRENT_DC_PORT GPIOA

define CURRENT_DC_CHANNEL ADC_CHANNEL_6

I also have another question. What is the max value you can send over uart for the maximum speed? 1024 or something different. Also how fast is the motor supposed to be at max speed?

I also made a Video of the Serial Monitor

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/assets/145379857/73503571-d8ee-4caf-9d96-2a5ab75f3b8f

[RoboDurden]

log data looks good to me. The lowside mosfet currents will be AC sine curves. Not needed for this firmware.

speed can go from -1000 to +1000 accelleration should be nearly instantly. Those motors are quite powerful.

[RoboDurden]

If you do not measure 5V on the DATA pin or the two PHOTO pins, you could try to replace

    #define USART_STEER_COM_RX_PIN  GPIO_PIN_7
    #define USART_STEER_COM_RX_PORT GPIOB

with one of these three. And see if the ESP32 is still able to control the speed. But the ESP32 should not really be connected to a pin that is pulled to +5V by the hoverboard controller !

When you succeed with hte RX pin you could try the remaining two pins for

    #define USART_STEER_COM_TX_PIN  GPIO_PIN_6
    #define USART_STEER_COM_TX_PORT GPIOB

and see if the ESP32 is still receiving log data.

The uart header you currently use is normally meant for the master-slave communication between the two split boards.

I just noticed, that the ESP32 S2 only seems to have two hardware serial, the first normally used for log output. With the original ESP32 you have three hardware serials and could control each split board via hardware uart. Of course there is still SoftwareSerial for the ESP32 S2..

The PHOTO pins might need an unsoldering of the photo light barriers. But maybe the pins will already work for rx or tx without unsoldering them.

[RoboDurden]

Yes i have a 2.3 layout and if you two continue here, i will join you with another test setup of mine:

[DerPinguin77]

Sorry for my late reply. I didn't have much time last week and I dont know how it will be next week. If I find some time i will test the PHOTO pins and let you know. I will try to help as much as I can.

[mateuszfcg]

I was away from home for a while so I couldn't test anything, but today I sat down anyway: -USART on slotted sensor pins is impossible(unless you use a solution like in Arduino "software serial). -PA15 and PA14 are USART1 pins 14A is the CLK pin which acts as tx and 15A RX. The problem is that 15 is the control of the red LED and even after soldering the transistor and resistor there is no communication on this pin.Maybe the problem would be solved by software serial then you could use the tx pin with CLK at the stlink connector and the "data" pin which is free altogether or the DIO pin. -referring to the voltage I recalculated the variable ADC_BATTERY_VOLT in the defines.h file. In my case it is 0.025827164959 As for the current on the connectors from the adc from the mosfets, I didn't measure it, but if you need it, with incorrect values, recalculate the variable MOTOR_AMP_CONV_DC_AMPin the defines.h file -I also tried to combine master/slave boards when controlling dummybut then only the master board works. I don't know what this is caused by. -Currently, I have connected both boards to Arduino mega and I use serial1 and serial2 in Arduino for communication and each separately set speeds. -one more thing puzzles me, well I would like to work on 12-14v power supply(motors with controllers will be used for a lawn mower, in the future autonomous) and I do not want to add any more inverters but the problem is that without external power supply uc does not want to wake up after pressing the button(when I power from 36v) everything is ok

[RoboDurden]

On the Gen1 boards there is a 30k:2k voltage divider for the on-off button:

You need to add a second resistor in parallel to the 30k to make the button work at 12V. Try another 30k resistor. But be careful to no longer attach a 36V battery to such a modification as it very well could kill your board with overvoltage on the onoff input.

[mateuszfcg]

@RoboDurden I would also like to send the command to switch off the board via uart. do you have any ideas?

[RoboDurden]

At the moment you do not use the steer command. So you could add to main.c

if (steer == 42) ShutOff();

[mateuszfcg]

Ok I didn't think about that. And actually what is the steer variable used for ?

[RoboDurden]

      // Each speedvalue or steervalue between 50 and -50 means absolutely no pwm
        // -> to get the device calm 'around zero speed'
        scaledSpeed = speed < 50 && speed > -50 ? 0 : CLAMP(speed, -speedLimit, speedLimit) * SPEED_COEFFICIENT;
        scaledSteer = steer < 50 && steer > -50 ? 0 : CLAMP(steer, -speedLimit, speedLimit) * STEER_COEFFICIENT * expo;

        // Map to an angle of 180 degress to 0 degrees for array access (means angle -90 to 90 degrees)
        steerAngle = MAP((float)scaledSteer, -1000, 1000, 180, 0);
        xScale = lookUpTableAngle[(uint16_t)steerAngle];

        // Mix steering and speed value for right and left speed
        if(steerAngle >= 90)
        {
            pwmSlave = CLAMP(scaledSpeed, -1000, 1000);
            pwmMaster = CLAMP(pwmSlave / xScale, -1000, 1000);
        }
        else
        {
            pwmMaster = CLAMP(scaledSpeed, -1000, 1000);
            pwmSlave = CLAMP(xScale * pwmMaster, -1000, 1000);
        }

[RoboDurden]

There are different sets of pins available for USART0 and USART1 i think. But yes, no free re-asignment like with the ESP32 i fear.

The 2.0 layout uses

#define USART_MASTERSLAVE USART1
#define USART_MASTERSLAVE_TX_PIN GPIO_PIN_2
#define USART_MASTERSLAVE_TX_PORT GPIOA
#define USART_MASTERSLAVE_RX_PIN GPIO_PIN_3
#define USART_MASTERSLAVE_RX_PORT GPIOA

Possible RX pins for USART_1 would be PA3, PB0 and PA15 but they are all used already for the 2.3 layout.

USART0 is the 2.3 mater/slave header which we currently use for steering:

    #define USART_STEER_COM_TX_PIN  GPIO_PIN_6
    #define USART_STEER_COM_TX_PORT GPIOB
    #define USART_STEER_COM_RX_PIN  GPIO_PIN_7
    #define USART_STEER_COM_RX_PORT GPIOB

Luckily these two pins are also used for I2C. So my SimpleFOC firmware should already work for this 2.3 layout. It should already work for you: https://github.com/RoboDurden/Split_Hoverboard_SimpleFOC You would only need to add a defines_2-3.h file.

I am not fully happy with that i2c firmware as you need to restart the hoverboard once the i2c connection fails.

It might be possible to use multiple slaves with the USART0 protocol ???

The ESP32 (master) would not only send speed and steer but also a slave ID. Then all attached hoverboards would receive the message and would discard it if their ID does not match. And then only the matching id would send the Feedback-data back to the master. As only the ESP32 has its RX pin connected to the TX pins of all the slaves, only the ESP32 would receive the Feedback message.

[RoboDurden]

Okay the master-remoteDummy is working on both boards. But the master-slave UART communication is not working. I will focus on that and later test the remoteUart with an esp s2 mini.

[RoboDurden]

Okay, serial communication from ESP32 S2 Mini works and master-slave also works. I have not updated my repo yet as i have reworked the usart0/usart1 code :-/ Need to tidy up the code and also make sure that the 2.0 layout with its two available usart ports still work. Unfortunately i have not a 2.0 setup here at my train station..

In config.h you will have to choose between three possible modes:

//#define MASTER        // uncomment if firmware is for master board
#define SLAVE           // uncomment if firmware is for slave board
//#define SINGLE            // uncomment if firmware is for single board and no master-slave dual board setup

Now i could try to connect both boards via the only one available usart to the ESP32 as i have suggested above. like i2c. Or you find some free pins that we somehow could use to at least send a speed value from ESP32 to each board. Like PWM or PPM..

[mateuszfcg]

In the Arduino IDE there is a library "software serial" maybe something like that could be used here, then we could use the stlink programming pins

[RoboDurden]

Yes :-) I have introduced a `

define REMOTE_UARTBUS // ESP32 as master and multiple boards as multiple slaves ESP.tx-Hovers.rx and ESP.rx-Hovers.tx`

and it works nicely:

millis: 5   iSlave: 2   iOdom: -1112        iSpeed: 0.00        iAmp: 0.60      iVolt: 23.25
millis: 101 iSlave: 2   iOdom: -1109        iSpeed: 0.00        iAmp: 0.80      iVolt: 23.25
millis: 96  iSlave: 1   iOdom: 7374     iSpeed: 0.49        iAmp: 1.20      iVolt: 22.85
millis: 5   iSlave: 2   iOdom: -1106        iSpeed: 0.00        iAmp: 0.40      iVolt: 23.25
millis: 96  iSlave: 1   iOdom: 7367     iSpeed: 0.49        iAmp: 0.60      iVolt: 22.85
millis: 101 iSlave: 1   iOdom: 7361     iSpeed: 0.49        iAmp: 0.60      iVolt: 22.86
millis: 5   iSlave: 2   iOdom: -1102        iSpeed: 0.00        iAmp: 0.40      iVolt: 23.26
millis: 96  iSlave: 1   iOdom: 7356     iSpeed: 0.49        iAmp: 0.20      iVolt: 22.86
millis: 5   iSlave: 2   iOdom: -1102        iSpeed: 0.00        iAmp: 1.20      iVolt: 23.26
millis: 96  iSlave: 1   iOdom: 7352     iSpeed: 0.49        iAmp: 0.40      iVolt: 22.86
millis: 5   iSlave: 2   iOdom: -1102        iSpeed: 0.00        iAmp: 0.80      iVolt: 23.19
millis: 96  iSlave: 1   iOdom: 7349     iSpeed: 0.00        iAmp: 0.20      iVolt: 22.77

I will only upload to my github repo when i have tested the code with a test setup that has two usart buses.

But you can download my work here: HoverBoardGigaDevice.zip and TestSpeed.zip

arduino code:

  boolean bReceived = Receive(oSerialHover,oHoverFeedback);   
  if (bReceived)
  {
    DEBUGT("millis",iNow-iLast);
    HoverLog(oHoverFeedback);
    iLast = iNow;
   }

  #ifdef REMOTE_UARTBUS
    if (iNow > iNext)
    {
      iNext = iNow + 100;
      //DEBUGLN("time",iNow)
      HoverSend(oSerialHover,2,-iSpeed/2);
      delay(10);
      HoverSend(oSerialHover,1,iSpeed);   // hoverboard will answer immediatly on having received this message
    }
  #else
    if (bReceived)  // Reply only when you receive data
      HoverSend(oSerialHover,iSteer,iSpeed);
  #endif

config.h :

//#define MASTER        // uncomment if firmware is for master board
//#define SLAVE         // uncomment if firmware is for slave board
#define SINGLE          // uncomment if firmware is for single board and no master-slave dual board setup

//#define TEST_HALL2LED // led the 3-led panel blink according to the hall sensors

#if defined(MASTER) || defined(SINGLE)
    #define MASTER_OR_SINGLE

    //#define REMOTE_DUMMY
    //#define REMOTE_UART
    #define REMOTE_UARTBUS  // ESP32 as master and multiple boards as multiple slaves ESP.tx-Hovers.rx and ESP.rx-Hovers.tx
    //#define REMOTE_CRSF

    #ifdef REMOTE_UARTBUS
        #define SLAVE_ID    2       // must be unique for all hoverboards connected to the bus
    #endif

by software, up to 255 split hoverboards can be connected to the bus.

enjoy :-)