Gen2.1.12 (ex2.14) - PPM and PWM RC remote?

[dexterbot80]

Hello, First of all I want to congratulate you on this project. Very useful for bringing broken hoverboards back to life.... I have two pieces of this model and would like to be able to actuate them simultaneously from an RC remote control to create a 4-motor RC platform. Have you seen this model before? Can someone guide me? Thank you

[RoboDurden]

And you did not answer why you changed to the new pin

define HALL_A PB11

But all three led did blink with the old triple of hall pins. Either my old triple or your new.triple.will make all three led blink according to rotation.

[dexterbot80]

And you did not answer why you changed to the new pin

define HALL_A PB1

First time I tried to change the hall pins between them, but only in this configuration does the motor spin

define HALL_A PA1 // 3.3K -> CONNECTOR ->YELLOW WIRE

define HALL_B PB11 // 3.3K -> CONNECTOR ->GREEN WIRE

define HALL_C PC14 // 3.3K -> CONNECTOR ->BLUE WIRE

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/assets/47325794/c15fc0dc-625e-41cf-ac78-43e48ac90618

[RoboDurden]

Is this phase to gnd or phase to phase ?

And again:

And you did not answer why you changed to the new pin

define HALL_A PB11

But all three led did blink with the old triple of hall pins. Either my old triple or your new.triple.will make all three led blink according to rotation.

[dexterbot80]

Is this phase to gnd or phase to phase ?

And again:

And you did not answer why you changed to the new pin #define HALL_A PB11 But all three led did blink with the old triple of hall pins. Either my old triple or your new.triple.will make all three led blink according to rotation.

The GND of the oscilloscope probes is connected to the GND of the board and each probe is attached to each phase. Hmmm.... You asked me to identify the pins that reach the HALL connector and checking with the multimeter I discovered that pin PB11 corresponds to the yellow wire in the HALL connector.

[RoboDurden]

So now three led blinking and before only two ?

[dexterbot80]

So now three led blinking and before only two ?

On the master board i have only 2 leds on that connector. And when the engine rotates, only a green LED lights up

[RoboDurden]

With all three. Phases towards gnd it is hard to see the currents flowing from phase to phase.. If you pit ground of oscilloscope to phase a and.probe to phase.b,.you should see only little spikes of voltage difference that corresponds to current flowing from a to b. This should look equally for all three combinations. But this is not that helpful anyway.

The amplitude drop in your video is from the current limiting I guess.

[RoboDurden]

With the master board you should have two Led blinking. As master behaves as bad as slave, you can go back to slave.

And make sure you have the correct three hall pins. And also have the correct.colors of the three led.

[dexterbot80]

With the master board you should have two Led blinking. As master behaves as bad as slave, you can go back to slave.

And make sure you have the correct three hall pins. And also have the correct.colors of the three led.

Got it, I'll go back to the Slave board and carefully check the LEDs and the hall connector again our job must be a teacher - you have nerves of steel with a student like me :)

[RoboDurden]

At least read my world peace plan in exchange: www.RoboDurden.de - the long version..

[dexterbot80]

This is my final config - all 3 LEDS working but the noise is the same.

https://drive.google.com/file/d/1hoy9iiEKe96EsbqkHIa6tjysain0TzGp/view?usp=drive_link https://drive.google.com/file/d/15N46KoZS51pwuFrbk3OiDhKaJ3xRAmIO/view?usp=drive_link https://drive.google.com/file/d/1VBkLdv3-A8oTEor9qYiubpZ-PQEH5-YR/view?usp=drive_link

[dexterbot80]

Of all the motors you tested, were there any that had this extra white wire?

[RoboDurden]

No, I never encountered such an additional white cable. First guess is that it is a temperature sensor. Test if the resistance to the black or red Hall cable is something like 10k or 100k. Or a speed sensor might be an idea. Then it could output a spike every turn, so same frequency as the three hall sensors.

The led rotation of last video looks good. I see a position where the red led is single and a rotation position where the green led is on alone. But I do not see that signle-on for the yellow led. Please check that all three led (=all three hall inputs) behave exactly the same.

It is hard for me to analyze your nice three channel oscilloscope readings because it is the difference between two channels that represent current flowing inside the motor coils. Maybe you have an option to show differential values on your oscilloscope.

But as this motor is indeed different maybe it is indeed an idea to experiment with the dead time. Try to double it. Increasing the dead time should do no harm. Decreaseing it would make the high side and low side shortcut the battery. And MOSFETs would get hot quickly..

If @pacraf is still here and has a test setup with constant current power supply, he might also test one motor with double dead time and report the change in smooth rotation.

@dexterbot80 , you still have not confirmed that you have tested all six hall permutations and have tested all six phase permutations.

And it might be good to get serial communication via pb6 and pb7 anyway. Then we can identify the correct analog inputs for battery voltage and overall current DC. If you select remoteUart, the hoverserial.ino should now also make the motor spin with that ugly noise.

Sorry that we are stuck with that poor motor behavior.

Can you confirm that the drop in amplitude is due to the current limiting ?

It is to dangerous to test without current limiting. But maybe you can test different voltages and different cut off currents and see if the noise changes..

You might also set all yet unconfirmed pins in your defines to TODO_PIN and see if one of these changes has an effect on the motor noise. I left many pin definitions from 2.0 layout in place with the chance that they might be right also for 2.14. Like onoff button, vbatt, currentDC, hold, etc. But as some are output pins, they might interfere with some unknown hardware in this layout.

And please stop quoting/copying all my text in the response :-)

[dexterbot80]

@dexterbot80 , you still have not confirmed that you have tested all six hall permutations and have tested all six phase permutations.

All 6 permutations of the HALL sensor seem to work, the LEDs light up in the following sequence: GREEN GREEN - YELLOW YELLOW YELLOW - RED RED RED - GREEN Teach me to test all 6 permutations of the phases ....

And it might be good to get serial communication via pb6 and pb7 anyway.

Then we can identify the correct analog inputs for battery voltage and overall current DC. If you select remoteUart, the hoverserial.ino should now also make the motor spin with that ugly noise. Are you referring to this TestSpeed.ino? I can't find hoverserial.ino :)

In these conditions, the motor does not rotate at all

[RoboDurden]

Nice log output. Does the battery voltage change when you change the power supply voltage ?

Can you increase current above 1.00 A by putting a hand on the rotating motor ?

Swapping phases by simply swapping two of the big green yellow blue motor phase cables. They usually have single connectors.

Do not permutate the three led pins, these must final so green pin makes green led light up.

Do the six hall pins permutations. Only one permutation leads to smooth rotation. All other 5 permutations will lead to heavy stuttering. It can not be that whatever hall pins permutation you define, the motor spins just the same.

[dexterbot80]

wapping phases by simply swapping two of the big green yellow blue motor phase cables. They usually have single connectors.

Pffff.... only now I understood which permutations to check. Seems that I have found a combination in which the engine does not sound bad and does not consume only 0.45A when rotating without load. The sound is much smoother with the #define DEAD_TIME 120 option activated

MOTOR- GREEN WIRE <> YELLOW WIRE CONTROLLER MOTOR YELLOW WIRE <> BLUE WIRE CONTROLLER MOTOR BLUE WIRE <> GREEN WIRE CONTROLLER

With #define REMOTE_UART and Lolin board connected the motor is not rotating at all If I change the supply voltage, I see the changed battery voltage on the serial I am very sure that I am doing something wrong here as well ​

[RoboDurden]

go to remoteDummy.c line 15 and set a constant speed between 300 and 500 (1000 is max):

speed = 300;

Then step by step (= comile by compile ) optimize the DEAD_TIME so the the current drawn from the power supply is lowest = no shortcut current when high-side and low-side mosfets are both conducting.

Good to hear hat swaping / permutating the phase cables did the job:

MOTOR- GREEN WIRE <> YELLOW WIRE CONTROLLER
MOTOR YELLOW WIRE <> BLUE WIRE CONTROLLER
MOTOR BLUE WIRE <> GREEN WIRE CONTROLLER

Still it would be better if you can achieve the same effect by swaping the hall sensors:

#define HALL_A  PA1     // dexterbot80: CHINESE LOGIC A !
#define HALL_B  PB11    // dexterbot80: CHINESE LOGIC A !
#define HALL_C  PC14    // dexterbot80: CHINESE LOGIC A !

try

#define HALL_A  PA1     // dexterbot80: CHINESE LOGIC A !
#define HALL_C  PB11    // dexterbot80: CHINESE LOGIC A !
#define HALL_B  PC14    // dexterbot80: CHINESE LOGIC A !

#define HALL_C  PA1     // dexterbot80: CHINESE LOGIC A !
#define HALL_B  PB11    // dexterbot80: CHINESE LOGIC A !
#define HALL_A  PC14    // dexterbot80: CHINESE LOGIC A !

#define HALL_B  PA1     // dexterbot80: CHINESE LOGIC A !
#define HALL_A  PB11    // dexterbot80: CHINESE LOGIC A !
#define HALL_C  PC14    // dexterbot80: CHINESE LOGIC A !

#define HALL_C  PA1     // dexterbot80: CHINESE LOGIC A !
#define HALL_A  PB11    // dexterbot80: CHINESE LOGIC A !
#define HALL_B  PC14    // dexterbot80: CHINESE LOGIC A !

and the fifth is ?

The arduino log shows that iSpeed is received by hoverboard. So i currently have no idea why motor not spinning. You could try my RemoteUartBus. It is especially designed for Single boards instead of master/slave. Maybe i have a bug when using RemoteUart with Single. You have to actived UartBus protocol in the arduino code as well as flashing a RemoteUartBus to the hoverboard..

If I change the supply voltage, I see the changed battery voltage on the serial

Then this define is correct: #define VBATT PA4 // todo

Try to check all other possible adc pins for this and put a hand on the motor (best with constant speed) to increase the load until you see amps above 1A in the arduino log:

#define CURRENT_DC PA6 // todo

    available for analog input:
    A0 A2 A3 A5 A6 A7 B0 B1     

A2, A3 is probably the master-slave serial communication.

Here you have PB6 and PB7 for remote serial communication on the master board:

This is porbably a dual op-amp, either for two phase currents (not need for this firmware but for advanced FOC firmware), or the overall currentDC: Would be nice if you can trace the mcu pins.

For the master board, you still need to trace the buzzer, onoff button and hold output...

[dexterbot80]

After I activate #define DEBUG_RX in the arduino code (TestSpeed), some additional messages appear on the serial - you can see it in the video. I connected the oscilloscope to the RX TX communication between the Lolin board and the Hoverboard, and when the LEDs light up on the hoverboard, the signals on the oscilloscope start jumping. The signals on the oscilloscope change their amplitude and move irregularly even if I don't activate #define DEBUG_RX. The motor does not spin, so something is wrong here

https://drive.google.com/file/d/1FzGNwilz4I1YDhg0I1dSfp4Rj4NfZHZ_/view?usp=sharing

Try to check all other possible adc pins for this and put a hand on the motor (best with constant speed) to increase the load until you see amps above 1A in the arduino log:

I think we should first make it spin when it receives commands from the Lolin board

Would be nice if you can trace the mcu pins. Here I have the operational TP2272 which seems to take care of those two photocells on the back of the board. TP2271.PDF

[dexterbot80]

Hello @RoboDurden & @pacraf, I found the problem guys ! I was fooled by a 0 ohm resistor mounted between the RX TX pins. I removed the "virus" and now it works controlled by the Lolin board :)

Do you recommend a resistance of another value between the RX and TX pins?

I reversed the hall sensor pins a little and now it works with the motor connected, respecting the colors of the wires.

define HALL_A PB11 // GREEN <> GREEN

define HALL_B PC14 // BLUE<> BLUE

define HALL_C PA1 // YELLOW <> YELLOW

Could the function for RC remote controls with PWM signal be implemented?

`#define RCPin 3 volatile long StartTime = 0; volatile long CurrentTime =0; volatile long Pulses =0; int PulseWidth = 0;

void setup() { Serial.begin(9600); pinMode (RCPin, INPUT_PULLUP); attachInterrupt(digitalPinToInterrupt(RCPin),PulseTimer,CHANGE); }

void loop() { if (Pulses < 2000){ PulseWidth = Pulses; } Serial.println(PulseWidth); }

void PulseTimer(){ CurrentTime = micros(); if (CurrentTime > StartTime){ Pulses = CurrentTime - StartTime; StartTime = CurrentTime; } }`

[RoboDurden]

You are getting better and better. Nice to witness your progress :-)

Some boards have a 4 pin header with the two middle pin short cut and labeled as DATA :-( This 0 ohm resistor did the same job. No we do not want any resistor between Rx and TX.

Please post your complete defines_2-14.h file here so I can upload it to the repo . Post as CODE.

The speed command ranges from -1000 to +1000. If your pwm code works nicely it is easy to map your pwm value to 0-1000 and send it to hoverboard. Please post final working Arduino code here - again as CODE :-)

[dexterbot80]

#ifdef MASTER_OR_SINGLE     // layout 2.2 and 2.7 have buzzer on the slave board.
    #define HAS_BUZZER
#endif

/* GD32F130 48pin possible IO pins: 
    C13 C14 C15 F0 F1 A0 A1 A2 
    A3 A4 A5 A6 A7 B0 B1 B2 B10 B11
    B12 B13 B14 B15 A8 A9 A10 A11 A12 A13 F6 F7
    A14 A15 B3 B4 B5 B6 B7 B8 B9 

    mostly used for 6 BLDC mosfet pins: B13 B14 B15 A8 A9 A10
    mostly used for USART0: B6 B7
    mostly used for USART1: A2 A3
    ST-Flash pins: A13 A14 (also used as green and red led on 2.2)

    so mostly available for other use:  
    C13 C14 C15 F0 F1 A0 A1 A4 A5 A6 A7 B0 B1 B2 B10 B11 B12 A11 F6 F7 A12 A15 B3 B4 B5 B8 B9 
    so available for analog input:
    A0 A1 A2 A3 A4 A5 A6 A7 B0 B1   
*/

#define TODO_PIN PF4    // PF4 is only accessible on the largest GD32F130Rx LQFP64 pinouts mcu

// LED defines

#define LED_ORANGE PA15 // ORANGE LED 
#define LED_GREEN PB3     // GREEN LED
#define LED_RED PB4         // RED LED

#define UPPER_LED   PB5         // LED 
#define LOWER_LED   PC13    // IN THE AIR

// Mosfet output, little onboard led
#define MOSFET_OUT  PF4 //<<<<<<<<<<<<-----------??????????????

// Brushless Control DC (BLDC) defines
#define BLDC_GH PA10        // green    , Tommyboi2001 all bldc pins same as 2.0
#define BLDC_GL PB15        
#define BLDC_BH PA9         // blue 
#define BLDC_BL PB14        
#define BLDC_YH PA8         // yellow
#define BLDC_YL PB13        
#define TIMER_BLDC_PULLUP   GPIO_PUPD_NONE  // robo: not sure if some boards indeed nned GPIO_PUPD_PULLUP like 2.2 or 2.3

// Timer BLDC short circuit emergency shutoff define
#define TIMER_BLDC_EMERGENCY_SHUTDOWN   PB12

// Hall sensor defines
#define HALL_A  PB11           //  CONFIRMED
#define HALL_B  PC14       //  CONFIRMED
#define HALL_C  PA1        //  CONFIRMED

// GD32F130 USART0 TX/RX:   (PA9/PA10)AF1   , (PB6/PB7)AF0 ,    (PA2/PA3)AF1 , (PA14/PA15)AF1 GD32F130x4 only!
#define HAS_USART0  // uncomment if this layout has a usart0
#ifdef HAS_USART0
    #define USART0_TX   PB6
    #define USART0_RX   PB7

    //#define USART0_MASTERSLAVE        // uncomment if this usart is used for master-slave communication
    #define USART0_REMOTE                       // uncomment if this usart is used for optional remote control
#endif

// GD32F130 USART1 GD32F130 TX/RX: (PA14/PA15)AF1 , (PA2,PA3)AF1    , (PA8/PB0)AlternateFunction4
#define HAS_USART1  // uncomment if this layout has a usart1
#ifdef HAS_USART1
    #define USART1_TX       PA2
    #define USART1_RX       PA3

    #define USART1_MASTERSLAVE      // uncomment if this usart is used for master-slave communication
    //#define USART1_REMOTE             // uncomment if this usart is used for optional remote control
#endif

// ADC defines
#define VBATT   PA4                 // CONFIRMED
#define CURRENT_DC  PA6  // CONFIRMED

// Self hold defines
#define SELF_HOLD   PB2  //todo

// Button defines
#define BUTTON   PC15 //todo

#ifdef HAS_BUZZER
    // Buzzer defins
    #define BUZZER  PB10        // todo
#endif

#ifdef MASTER
    // Charge state defines
    #define CHARGE_STATE    PF0 // todo
#endif

// Debug pin defines -  no longer has any function in code !
#define DEBUG_PIN TODO_PIN

I still haven't identified the pin for the buzzer on the master board, which is now a slave for me :)

This code only reads the PWM values received from the RC remote control, I think it would be very useful to be able to connect PWM remote controls to. I tested it on the Lolin board and it works....

#define RCPin 3
volatile long StartTime = 0;
volatile long CurrentTime =0;
volatile long Pulses =0;
int PulseWidth = 0;

void setup() {
Serial.begin(9600);
pinMode (RCPin, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(RCPin),PulseTimer,CHANGE);
}

void loop() {
if (Pulses < 2000){
PulseWidth = Pulses;
}
Serial.println(PulseWidth);
}

void PulseTimer(){
CurrentTime = micros();
if (CurrentTime > StartTime){
Pulses = CurrentTime - StartTime;
StartTime = CurrentTime;
}
}

[RoboDurden]

If you plan to power every single board directly you might not need to care about the onoff button and the hold output pin of the original master board. But I do not know how this layout usually gets connected to the battery.

[dexterbot80]

If you plan to power every single board directly you might not need to care about the onoff button and the hold output pin of the original master board.

You have to teach me what this hold output pin does. I have no idea how to find it on the board. I would like to make this version 2.14 compatible with all the functions in the code + PWM RC :)

[RoboDurden]

The onoff button controls a transistor that powers the 5V and 3.3V for the MCU. But with release of the onoff button the power stops. With the hold output, the MCU can control another Transistor that emulates the onoff button. Therefore the MCU can shutoff itself by setting the hold output to low. Search main.c for usage of BUTTON and HOLD.

[RoboDurden]

Would be nice if you can integrate your pwm code into the Esp_ppm example. Add a #define RC_PWM in the beginning and then #ifdef ... your pwm code instead of the ppm code.

[dexterbot80]

Would be nice if you can integrate your pwm code into the Esp_ppm example. Add a #define RC_PWM in the beginning and then #ifdef ... your pwm code instead of the ppm code.

Yes but my code just read the pwm data from RC - I think it's much more complicated than that :)

I now understand what the hold output pin does - maybe I can find it by groping and disconnecting the power button after uploading the code. I'm thinking now that only the master board could have the hold power function ...

[dexterbot80]

I think this #define SELF_HOLD PB2 pin is correct because I disconnected the button and it didn't stop :). I reconnected the button without retention and after a short press it starts. The problem is that if I press the button one more time, the hoverboard stays on.

If I disconnect the power it stops and if I connect it back the power only starts if I press the start button.

​

[RoboDurden]

Then the BUTTON pin definition is wrong and the code does not recognize a button press to shutoff and release the HOLD output.

[dexterbot80]

Then the BUTTON pin definition is wrong and the code does not recognize a button press to shutoff and release the HOLD output.

Ok, i identify the button pins right away

[dexterbot80]

I think that if you implement the RC PWM remote control it will be much easier to implement in the future and the possibility of connecting an accelerator pedal, a brake pedal and a direction change button ​And look, this is how we turn this project into a multifunctional one :)

[RoboDurden]

I do not really want that. Not so many Variant_xy as the EFeru firmware.

[dexterbot80]

Not so many Variant_xy as the EFeru firmware.

I respect your decision - you are the boss here :)

Does it have to work only with the retaining button? If the button is ON does it work and if it is OFF does it stop?

I discovered the pin for the button, this would be #define BUTTON PA0 and if I set #define SELF_HOLD PB1 for hold power, it works exactly as I described above. If the button is ON, it starts and if the button is OFF, it stops.

[RoboDurden]

I can add a #define option to config.h that will make the board shutoff when the onoff button is released. It would simply disable the SelfHold functionality.

If this is already the behavior of your setup then I fear, the HOLD pin definition is still wrong.

[RoboDurden]

I do not want to add pwm or ppm to the Keil firmware at the moment. But you could add your code to the esp_ppm example so others can use own on the Arduino side. But these ino files are just meant as examples and not the main firmware.

You could fork this repo and add a RemotePwm.c to the Keil firmware. Should be quite easy to port your little interrupt routine as you can see how it is done in it.c and setup.c

[dexterbot80]

Does the button have to activate/deactivate the hold function even if I set the board with the button as SLAVE?

Until I encountered two scenarios when setting the pins for the hold and button functions:

1. If I set any other pin apart from PB2 for SELF_HOLD the hover function just if i hold the POWER BUTTON ON.

2. If I set PB2 for SELF_HOLD and PA5 for BUTTON, the hover works in the following scenario. If I connect the power, it only starts if I press the POWER BUTTON once, but it doesn't stop if I press the POWER BUTTON once more.

I do not want to add pwm or ppm to the Keil firmware at the moment. But you could add your code to the esp_ppm example so others can use own on the Arduino side. But these ino files are just meant as examples and not the main firmware.

I wanted to say that codes should be created for Lolin's ESP32 to allow us to operate the hoverboard with the RC PWM remote control.

Likewise, a separate ESP32 code for operating the hoverboard using two pedals, brake and accelerator + a button to change the direction of travel.

[RoboDurden]

Search main.c for the usage of BUTTON and SELF_HOLD and understand how it works :-)

Ppm and pwm are both connected to RC, so it would be good to have them in one Esp_PpmPwm.ino I do not like to update the hoverserial.h in too many .ino projects ..

[dexterbot80]

Hello @RoboDurden & @pacraf Please confirm if this code works with a PWM signal :) Probably for your remote control you need to adjust the 'a' and 'b' values in the code as follows: Increasing the 'a' value will amplify the effect of the PWM signal on speed, and adjusting the 'b' value will set the baseline speed when the PWM signal is low.

////DX_PWM.ino\\\\

#define ESP32
#define _DEBUG      // debug output to first hardware serial port
//#define DEBUG_RX    // additional hoverboard-rx debug output

//#define REMOTE_UARTBUS  // uncomment to connect multiple SINGLE boards to the same UART_BUS

#include "util.h" // you need to add this file in your code folder
#include "hoverserial.h" // you need to add this file in your code folder

#include <PPMReader.h>
byte interruptPin = 3;
byte channelAmount = 4;
PPMReader ppm(interruptPin, channelAmount);
const float a = 1.35; // Increase this value to increase speed
const int b = -2000; // Adjust this value to set the baseline speed 
int result = 0;

#ifdef ESP32
  #define oSerialHover Serial1    // ESP32
#else
  #include <SoftwareSerial.h>    // not compatible with RCReceiver because of interrupt conflicts.
  SoftwareSerial oSerialHover(9,8); // RX, TX 
  #define oSerialHover Serial    // Arduino
#endif
SerialHover2Server oHoverFeedback;

void setup() {
  #ifdef _DEBUG
    Serial.begin(115200);
    delay(2000); // wait some time after reset - to see below message
    Serial.println("Hello Hoverbaord V2.x :-)");
  #endif

  #ifdef ESP32
    HoverSetupEsp32(oSerialHover,19200,39,37);      // baud, rx, tx
  #else
    HoverSetupArduino(oSerialHover,19200);    //  8 Mhz Arduino Mini too slow for 115200 !!!
  #endif

  pinMode(LED_BUILTIN, OUTPUT);
}

unsigned long iLast = 0;
unsigned long iNext = 0;
unsigned long iTimeNextState = 3000;
uint8_t  wState = 1;   // 1=ledGreen, 2=ledOrange, 4=ledRed, 8=ledUp, 16=ledDown   , 32=Battery3Led, 64=Disable, 128=ShutOff

void loop() {
  unsigned long iNow = millis();
  digitalWrite(LED_BUILTIN, (iNow % 2000) < 500);

  int iSteer = -100;
  int iSpeed = 0;

  if (iNow > iTimeNextState) {
    iTimeNextState = iNow + 3000;
    wState = wState << 1;
    if (wState == 128) wState = 1;  // remove this line to test Shutoff()
  }

  // Read PWM value from the remote control
  result = pulseIn(3, HIGH, 25000);  // Assuming the PWM signal is on pin 3 and timeout is set to 25ms

  if (result > 995) {
    iSpeed = (result * a) + b;
  } else {
    iSpeed = 0;
    Serial.println("dead RClink"); 
  }

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

  #ifdef REMOTE_UARTBUS
    if (iNow > iNext) {
      iNext = iNow + 100;
      int iSpeedL = CLAMP(iSpeed + iSteer, -1000, 1000);
      int iSpeedR = -CLAMP(iSpeed - iSteer, -1000, 1000);

      HoverSend(oSerialHover, 0, iSpeedL, wState);
      delay(10);
      HoverSend(oSerialHover, 1, iSpeedR, wState);
    }
  #else
    if (bReceived)  // Reply only when you receive data
      HoverSend(oSerialHover, iSteer, iSpeed, wState, wState);
  #endif
}

pwm_rc_v1.0.zip

[dexterbot80]

Hello @RoboDurden Can you tell me how ugly this board is? :) Please take a look and tell me what else I should add to make it as universal as possible - so that everyone here can use it.

Now it has TX-RX output for ten motors on pins 39/37 and input from an RC receiver on pin 3. Also, the RC receiver can be replaced with an accelerator pedal with analog output and the other pins can be used for left-right signaling, headlights (high beam-low beam), horn, direction change switch and other functions that can be added...

For example, would I need to put a power supply module based on this circuit for a wider range of supply voltage? https://www.ti.com/product/LM2576HV

[RoboDurden]

My uartBus is still very experimental.. But if you enjoy making PCB, please watch my YouTube videos on that nice 80V 20A step up down converter like https://youtu.be/KYcyNHunJU8

I still have not found the happiness to make circuit boards.

So you are very welcome to stay here.

You should use the hvs version of that lm2596 converter which can handle 36 volt battery. And why not add the 3A cc constant current limit ! Then every user could test the motor with new binaries .. Normally, the esp32 can be powered by the hoverboard 3.3V .. So maybe a jumper which either sets the lm2596hvs to 5V and power the esp s2 mini or not power it and then ouputs 26V with 2A limit.

12 hoverboards is overkill. A 6 axis robot arm might be all people ask for. And smd diodes on board ..

But I do not really think people want auch a board... And maybe move the gpio headers closer to the esp and out a prototyping area in the free space. Then you also do not need the many optional resistors at the gpio pins..

Maybe add a 4 pin i2c header that is compatible with this cheap OLED.

[dexterbot80]

@RoboDurden

But I do not really think people want auch a board... And maybe move the gpio headers closer to the esp and out a prototyping area in the free space. Then you also do not need the many optional resistors at the gpio pins..

Maybe add a 4 pin i2c header that is compatible with this cheap OLED.

Can you post the electronic schematic diagram for the board in the picture? Send me an email - I will give you a replay with a software that will help you draw the electronic diagram quickly. dexterbot80@gmail.com

We couldn't make better use of the ESP32S3-based WT32-SC01-PLUS screen - it could probably replace the LolinS2 board and that screen you're using now. WT32-SC01+PLUS+Datasheet-V1.5+EN.pdf

I think we could make a very nice interface using this screen and if it goes to replace the LolinS2 board it will be perfect. Let's study this a little :)

[RoboDurden]

The lolin s2 mini is outstanding cheap. But no FCC certificate because not shielded.. The esp32 s3 is a risc processor and not as powerful as the S2.

If you guide me to a nice schematics drawing program, I will happily work with you.

But either create a new issue here or send email to roland@robo4future.de Or you or I create a new GitHub repo with free PCB layout and source code. Here my mppt based in this 20€ dcdc converter: unlisted.

[dexterbot80]

@RoboDurden

But either create a new issue here or send email to roland@robo4future.de

I sent you an email - please confirm by email if you received it. The program is very easy to use and you can find all the information here. https://www.electronic-software-shop.com/lng/en/electronic-software/splan-80.html?language=en&xoid=illi7sa2dbf08egbake58cfrpc

[dexterbot80]

Hello @RoboDurden Do you recommend ESP32-S2-SOLO-N4R2 or ESP32-S2-SOLO-2-N4R2?

esp32-s2-solo_esp32-s2-solo-u_datasheet_en.pdf

esp32-s2-solo-2_esp32-s2-solo-2u_datasheet_en.pdf