Open hoverboardhavoc opened 2 weeks ago
Please post the full autodetect log. And from your video i see that you do not use an arduino with my autodetect.ino as the serial log data proxy. Only my autodetect.ino can save the tested HOLD pin so on repowering the board, the autodetect firmware can retrieve the last tested button from autodetect.ino and reconize this as the HOLD button..
You should also to run the normal autodetect procedure with "0". Then i think the first pin to detect is the voltage adc VBATT.
And anyway, if the HOLD detection does not work, then simply keep the onOff button bridged and skip this detection stage. So we see if the different led and the buzzer can be detected.
The hall dectection normaly needs the VBATT, because the pwm ratio must be adjusted for 26V or 36V...
I can not read the log ouput on your hall video. Does the autodetect indeed finds all three hall pins ? I only see two pins detected in the beginning, then you mention a phase being detected. But the scan continous until all possible pins have been tested but no third hall found ?
hall detect work normally 3 pin found but no order is valid self hold and button is not required for the firmware to function so you dont need to test those
Thanks for the help with this!
I'm running autodetect.ino
on a Blue Pill. I can send pull request with the changes I made to make it work.
Yes, all three hall pins are detected. I failed to paste the logs properly because the buffer is weird in the Aurdino IDE. Creating an entire log has proved problematic, If I run the whole detect routine using, 0 the board just dies when I unbridge the power button. If I detect VBATT (PA4) prior to detecting the hall sensors, hall order detection still fails. The three HALL pins are detected, PC13, PC14, PA1
.
Every combination of HALL_A, HALL_B and HALL_C have been tested with every combination of the detected hall pins, PA1, PC13 and PC14. None of them make the motor turn forwards and backwards using REMOTE_DUMMY.
Yes, he could already proceed with a RemoteDummy firmware and simply test the 6 hall permutation with six different firmwares. But i would autodetect the rgb leds first so that they will blink according to the hall sensors:
#ifdef REMOTE_DUMMY
#define TEST_HALL2LED // led the 3-led panel blink according to the hall sensors
I only have two color leds to play with unfortunately. There is only green and red (no orange). But they do light up when I manual rotate the wheel when using REMOTE_DUMMY
. Maybe I could try with the up or down led as the third led
you should use putty as the default serial terminal if you are using windows
If i remember correctly, my HOLD detection has two stages. First it tries to detect the power fail quickly enough to keep code running. If this fails it will use the autodetect.ino to save the last pin tested and recover that information after repowering.
As your board seem to turn off immediately, setting all possible pins to INPUT_PULLUP does not seem to activate the HOLD button. maybe OUTPUT and digitalWrite(1) is needed. or even digitalWrite(0).
I think you should try to detect as many other pins as possible, so when everything else runs, you have less to try-and-error with the HOLD/BUTTON pins.
Yes, if you have detected UP or DOWN, you can manualy define the orange pins as such a one.
If the led blinking does confirm that you have found the correct three hall pins, than i think that one of the six possible permutations must do.
Because my hall pin detection stage does make the motor spin. So the the activations of the six mosfet seem to work as they are supposed to.
My autodetect log output does support the Arduino serial terminal.
I only have two color leds to play with unfortunately. There is only green and red (no orange). But they do light up when I manual rotate the wheel when using
REMOTE_DUMMY
. Maybe I could try with the up or down led as the third led
yes this is what i do when i develop on the spin06 board where there is only 2 led driver on master your board seems to contain 7 led driver transistor though which is quite allot
I tried using red, green and up and I think this indicates that I have correctly detected the hall pins. I have tried all the possible different orders and nothing worked but I can try again.
https://github.com/user-attachments/assets/4519ee5b-bdbb-4e15-9145-48e43429ce4d
in fact i probably know why it doesnt work
Am I OK to flash the board using the power from the ST-LINK? I can't seem to flash the board when it's powered from the PSU.
@I-hate-2FA The serial is running on a mac currently. I can try putty on Windows. Thanks
this is gen2, you should always use the stlink to power the board when flashing, gen1 dev dont know what they are doing
I do not think that he needs to change "invert lowside"
// Set up the output channel parameter struct
timerBldc_oc_parameter_struct.ocpolarity = TIMER_OC_POLARITY_HIGH; //HIGH: CHx_O is the same as OxCPRE , LOW: CHx_O is contrary to OxCPRE
timerBldc_oc_parameter_struct.ocnpolarity = TIMER_OCN_POLARITY_LOW; //HIGH: CHx_ON is contrary to OxCPRE, LOW: CHx_O is the same as OxCPRE
As my hall detection stage is already able to make the motors spin.
No need for putty. He obviously can send comands to autodetect.bin and receive the log output :-)
Success!! It seems really smooth :)
@ I-hate-2FA hinted at how voltage problems and BAT_CELLS
was set incorrectly. It's defined both on line 14 and 36 in config.h
https://github.com/user-attachments/assets/1842cbcf-16f3-4d18-8af1-3d909ffa41b9
Thanks so much for the help.
So the remaining issues I have are:
~If I send a PR for this board, what should I call it?~ Ahh I see you gave it a name Gen2.1.20
The slave usualy gets 5V or 12V via the Master-Slave cable which makes it wake up. So simply measure what positive voltage you have on the master slave cable, and feed this to the correct pin of the slave board.
Your defines you be named defines_2-1-20.h
Is there any lower bound to the voltage I can use. Can I try 12V? I guess it will be slow if it works?
Concerning the HOLD button.. I guess i would add to main.c
typedef struct {
uint32_t i;
char* s;
uint8_t wState; // 1=adc
int16_t iAdc;
} PinAD;
#define COUNT_PinDigital 31
PinAD aoPin[COUNT_PinDigital] = {
{PC13,"C13",0} ,{PC14,"C14",0} ,{PC15,"C15",0} ,{PF0,"F0",0} ,{PF1,"F1",0} ,
{PA0,"A0",1} ,{PB11,"B11",0} ,{PA4,"A4",1} ,{PA5,"A5",1} ,{PA6,"A6",1} ,
{PA7,"A7",1} ,{PB0,"B0",1} ,{PB1,"B1",1} ,{PB2,"B2",0} ,{PB10,"B10",0} ,
{PA1,"A1",1} ,{PB12,"B12",0} ,{PA11,"A11",0} ,{PF6,"F6",0} ,{PF7,"F7",0} ,
{PA12,"A12",0} ,{PA15,"A15",0} ,{PB3,"B3",0} ,{PB4,"B4",0} ,{PB5,"B5",0} ,
{PB6,"B6",0} ,{PB7,"B7",0} ,{PB8,"B8",0} ,{PB9,"B9",0} ,{PA2,"A2",1} ,
{PA3,"A3",1}
};
with all the pins removed that you already know to have a different function. I you had an autodetect.bin with PA2 and PA3 as rx tx pins.
Then before the while(1) loop add something like
for (i=0;i<COUNT_PinDigital; i++)
{
//pinModePull(aoPin[i].i,GPIO_MODE_INPUT,GPIO_PUPD_PULLUP);
pinMode(aoPin[i].i,GPIO_MODE_OUTPUT);
digitalWrite(aoPin[iTest].i,1); // every remaining io pin might be the SELF_HOLD pin
}
And then release the onoff button when the dummy starts spinning. That way you might be able to find out, what make the HOLD transistor being active.
The button input pin might no longer work if the battery voltage is too low. And the gate drivers need at least 12V to work nicely. You have a step down regulator that generates this gate driver voltage. So 12V battery might only lead to 10V for the gate drivers. But you have a nice digital power supply. you can test it :-)
Is there any lower bound to the voltage I can use. Can I try 12V? I guess it will be slow if it works?
15v
Concerning the HOLD button.. I guess i would add to main.c
typedef struct { uint32_t i; char* s; uint8_t wState; // 1=adc int16_t iAdc; } PinAD; #define COUNT_PinDigital 31 PinAD aoPin[COUNT_PinDigital] = { {PC13,"C13",0} ,{PC14,"C14",0} ,{PC15,"C15",0} ,{PF0,"F0",0} ,{PF1,"F1",0} , {PA0,"A0",1} ,{PB11,"B11",0} ,{PA4,"A4",1} ,{PA5,"A5",1} ,{PA6,"A6",1} , {PA7,"A7",1} ,{PB0,"B0",1} ,{PB1,"B1",1} ,{PB2,"B2",0} ,{PB10,"B10",0} , {PA1,"A1",1} ,{PB12,"B12",0} ,{PA11,"A11",0} ,{PF6,"F6",0} ,{PF7,"F7",0} , {PA12,"A12",0} ,{PA15,"A15",0} ,{PB3,"B3",0} ,{PB4,"B4",0} ,{PB5,"B5",0} , {PB6,"B6",0} ,{PB7,"B7",0} ,{PB8,"B8",0} ,{PB9,"B9",0} ,{PA2,"A2",1} , {PA3,"A3",1} };
with all the pins removed that you already know to have a different function. I you had an autodetect.bin with PA2 and PA3 as rx tx pins.
Then before the while(1) loop add something like
for (i=0;i<COUNT_PinDigital; i++) { //pinModePull(aoPin[i].i,GPIO_MODE_INPUT,GPIO_PUPD_PULLUP); pinMode(aoPin[i].i,GPIO_MODE_OUTPUT); digitalWrite(aoPin[iTest].i,1); // every remaining io pin might be the SELF_HOLD pin }
And then release the onoff button when the dummy starts spinning. That way you might be able to find out, what make the HOLD transistor being active.
Thanks, using this method I discovered that hold is PB12
So it does need output and digitalWrite(PB12,1) to activate the HOLD transistor ?
Now in RemoteAutodetect.c on line 365 you could change
pinModePull(aiPinScan[SCAN_SELF_HOLD],GPIO_MODE_INPUT,GPIO_PUPD_PULLUP);
//pinMode(aiPinScan[SCAN_SELF_HOLD],GPIO_MODE_OUTPUT);
//digitalWrite(aiPinScan[SCAN_SELF_HOLD],1); // SELF_HOLD pin to high
to
aiPinScan[SCAN_SELF_HOLD] = PB12;
HidePinDigital(PB12);
//pinModePull(aiPinScan[SCAN_SELF_HOLD],GPIO_MODE_INPUT,GPIO_PUPD_PULLUP);
pinMode(aiPinScan[SCAN_SELF_HOLD],GPIO_MODE_OUTPUT);
digitalWrite(aiPinScan[SCAN_SELF_HOLD],1); // SELF_HOLD pin to high
Then you might be able to release the onOff button after you have choosen the BUTTON detect stage and that way discover the button input
Maybe better add this code also(!) to line 631, then you can already release the onOff button when the menu appears.
it is better to connect the button pin directly to your external micro controller and disable self hold, so you can control power to the board on demand(assume the mcu is powered externally)
You could also set the RemoteDummy speed to 0 and try three possible pins as the hall inputs. Then one of the three led will blink according to button pushes.. Will need a free bianries to test all possible pins.
@I-hate-2FA , what transistor/optocoupler do you suggest to emulate the onOff button ?
@hoverboardhavoc , it would be nice if you are able to find all pins and then made a pull request with your defines....h
@I-hate-2FA , what transistor/optocoupler do you suggest to emulate the onOff button ?
you do not need one, just connect the button connector directly to esp gpio, the transistor is built in the hoverboard, if they have common gnd itll work
?? the 2pin button (onOff) socket has 36V on one pin ?
connect gpio to the one that dont have 36v, 36v one is not needed
yes that might work. But if the other pin is connected to ESP32, it will kill the ESP. But yes, if people will use a ESP32 for uart control, they might be better of turn the hoverboard on off from there. On the other hand, the hoverboard could be used to power the esp32.
i already tried it irl it worked on my board
Now in RemoteAutodetect.c on line 365 you could change
pinModePull(aiPinScan[SCAN_SELF_HOLD],GPIO_MODE_INPUT,GPIO_PUPD_PULLUP); //pinMode(aiPinScan[SCAN_SELF_HOLD],GPIO_MODE_OUTPUT); //digitalWrite(aiPinScan[SCAN_SELF_HOLD],1); // SELF_HOLD pin to high
to
aiPinScan[SCAN_SELF_HOLD] = PB12; HidePinDigital(PB12); //pinModePull(aiPinScan[SCAN_SELF_HOLD],GPIO_MODE_INPUT,GPIO_PUPD_PULLUP); pinMode(aiPinScan[SCAN_SELF_HOLD],GPIO_MODE_OUTPUT); digitalWrite(aiPinScan[SCAN_SELF_HOLD],1); // SELF_HOLD pin to high
Then you might be able to release the onOff button after you have choosen the BUTTON detect stage and that way discover the button input
Having made this change, the autoconfig just seems to go into a loop when doing 2: Hold
. 3 is not available in the menu, but I can type it anyway but it also goes into an infinite loop:
release OnOff button
ENTER to begin, 's' for next stage, 'q' for menu
C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15 F0 F1 A0 B11 A5 A6 A7 B1 B10 A11 F6 F7 A12 A15 B6 B7 B8 B9 C15autodetect menu:
0: do all
1: VBatt
2: Hold
4: Led
5: Hall
6: HallOrder
7: CurrentDc
8: Results
and itll only make sense if you power the esp externally yes
Also, just out of curiosity, why was the autodetect not able to do the digitalWrite(aiPinScan[SCAN_SELF_HOLD],1);
Was I just using it wrong somehow?
because pinmode output in autodetect is not allowed
As you can see this OUTPUT + digitalWrite was the way i did it - before @I-hate-2FA convinced me that this might create a short cut on some boards. So i switched to the INPUT_PULLUP method.
Yes, you can add wMenuStage |= AUTODETECT_Stage_Button;
to make this stage visible in the menu.
If i remember correctly this button detect stage also has two parts, one with onoff bridged and one with releasing it. So the code can detect the difference and find the pin.
I figured out the last piece of the puzzel for the master board, BUTTON
:
#ifndef DEFINES_2_x_H
#define DEFINES_2_x_H
#define HALL_A PC13
#define HALL_B PA1
#define HALL_C PC14
#define LED_RED PB4
#define LED_GREEN PB3
#define UPPER_LED PB2
#define LOWER_LED PB5
#define BUZZER PB9
#define VBATT PA4
#define CURRENT_DC PA0
#define SELF_HOLD PB12
#define BUTTON PA12
// 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
#define HAS_USART1 // tx=PA2,rx=PA3 uncomment to connect via 19200 baud serial
// GD32F130 USART1 GD32F130 TX/RX: (PA14/PA15)AF1 , (PA2,PA3)AF1 , (PA8/PB0)AlternateFunction4
#ifdef HAS_USART1
#define USART1_TX PA2
#define USART1_RX PA3
#define USART1_MASTERSLAVE // uncomment if this usart is used for master-slave communication
#endif
#endif
I'll send a PR in the coming days
~I attempted to make a PR but it says I have an "entirely different commit history"~
Ok, I've forked the wrong repo! This was a little mind bending. This issue is on one repo, but the code is elsewhere. Maybe it could all be put in the same place?
no because then you will not be able to download the code in browser
all big project issue tracker and wiki have seperate repo like esphome
Yes, This home repo had become to big in size. The GD32 code repo is easy to download.
Thanks for the pull request. I improved your missing orange led code in bldc.c :
#ifdef TEST_HALL2LED
#ifdef LED_ORANGE
digitalWrite(LED_ORANGE,hall_b);
#elif defined(UPPER_LED)
digitalWrite(UPPER_LED,hall_b);
#elif defined(LOWER_LED)
digitalWrite(LOWER_LED,hall_b);
#else
if (hall_b)
{
digitalWrite(LED_GREEN,(steerCounter%2) < 1);
digitalWrite(LED_RED,(steerCounter%2) < 1);
}
#endif
digitalWrite(LED_GREEN,hall_a);
digitalWrite(LED_RED,hall_c);
#endif
I think there are pads for another USART but no connector. Maybe I'll need to solder something on if I want to connect the board to a micro controller and a slave
Yes, the second uart port (usually PB6 and PB7 ) would be good to have master-slave communication. But i added the RemoteUartBus with which you can control two or more single boards directly from ESP32 (or likewise).
What empty uart header are you reffering to ? Please show it on a photo. I see some bluetooth modules on your photos. Sometimes they only offer a TX or RX line and not both..
The slave board has a red 4 pin header mounted. That might be three additional led outputs.
This board from Classy Walk hoverboard and has a GD32F130, FORTIOR FD6287T GA1015 and a NCE01P13K 1PKL2. It's marked with OLSZ 0L20190703-V4.1
Master
Slave
Config
The hall order was not detected by autoconfig (see below). Every combination of HALL_A, HALL_B and HALL_C have been tested with every combination of the detected hall pins, PA1, PC13 and PC14. None of them make the motor turn forwards and backwards using
REMOTE_DUMMY
.Hold detection
https://github.com/user-attachments/assets/07c28e3b-4ee3-4a48-b20d-48aaa9bedfdd
Hold detection freezes after the
release OnOff button
stage. When the power button is released, the board just turns off.Hall / Hall order detection
https://github.com/user-attachments/assets/b025cb2a-ecb6-43c4-bc1f-d2cba355bd90
The hall detection works but the hall order detection does not detect the order.
Slave board
The slave board flashes but does not appear to turn on. There is obviously no switch to bridge.
Questions
Flashing
The master board can't be flashed when being powered via the bench power supply but can be flashed when powered via the 3.3V line on the ST-LINK flasher. I read elsewhere that this is bad and the ST-LINK does sometimes behave strangely. (Maybe too much current is being drawn?) Any idea why it does not flash while being powered by the bench power supply and are there any workarounds? Maybe it would be better to have an external 3.3V power supply rather than using the 25.9V bench power supply?
Version number
Any idea how this board would fit into the existing version number scheme? It says 0L20190703-V4.1 on it.