-
Notifications
You must be signed in to change notification settings - Fork 8
Home
Looks like there's a problem with the LEDS on pins A1 and A2 conflicting with the ADC gimbal inputs if the sensors produce outputs below about 0.6V (the forward voltage of the LED). The solution is likely to be to remove the LEDs, but they are on the hidden side of the devboard once it's soldered to the PCB, so I haven't been able to test yet.
Based on the schematic (https://github.com/Xinyuan-LilyGO/LilyGO-T-DisplayGD32/blob/master/Schematic/T_Display_GD32_Schematic.pdf) the blue and green leds should be the ones to remove, but it maybe safer to remove all three in case they aren't always populated accurately. (I just confirmed that blue and green are the right LEDs on the TTGO boards that I have to hand)
Update: I still haven't had time to test removing the LEDs. As a short term fix I've worked around the problem by swapping the signal pins in the plug for the affected gimbal and re-mapping the gimbal channels in user_config.h. Fortunately the LEDs only affect two of the four channels, one on each plug. Since gimbals that output less that 0.6V are relatively unusual there's a good chance that swapping the pins will give you a workable outcome, and is much easier than trying to get the mcu devboard off the PCB of an existing build.
If you're updating the firmware on an existing handset checkout the What's New page for info.
NB New firmware development is on the master branch, not the default main branch. Make sure you flash from master!
The handset only supports a subset of features of ExpressLRS, so to connect successfully the receiver will need to be compiled with:
- 500Hz support
- hybrid switches
- a fixed UID
The more experimental features are only enabled in native mode. Unfortunately this needs modified firmware on both the receiver and betaflight. Since my fork of the elrs rx code is based on quite an old version, and my BF code contains some fairly experimental stuff, it doesn't seem likely that anyone else would want to use them, but I can make them available if anyone really wants to try. It's likely that these features will become available with mainstream ELRS and BF over time, particularly with the adoption of CRSF V3 for the RX uart. For now, compatibility mode supports up to 500Hz at 10 bits to match ELRS V1.0.
There's a gotcha on the order of assembly; if you put the MCU on too early you can't get at one of the headers for the radio carrier. But soldering all the MCU pins is also tricky so you don't want too much stuff in the way when you do it. I messed this up in the latest build and melted one of the radio carrier pin strips while soldering the MCU. So my recommendation:
- Solder the passives first
- Add the pinstrip for the radio carrier that is between the rows of the mcu pins. Don't add the second radio pinstrip yet - that will give you more space to work with when soldering the MCU
- Remove the blue and green LEDs from the MCU devboard - they can interfere with the ADC measurements
- Solder the MCU (don't forget the 2x4 pins). Depending on the case you are using you might want to use sockets for the MCU instead of soldering it directly. The plus is being able to remove it easily if you need to, the downside is the extra depth needed at the front of the case.
- Add the second pinstrip for the radio
- Add the sockets for the active filter (use turned pin if building with the FNW case as the lower profile gives more vertical space)
- Add the remaining sockets for switches etc
There are two options for power, either supply regulated 5V to the 5V-IN connector or use a 2S lipo on the 2SBAT connector and add a buck converter with 5V output using the 5VBUCK pin header (untested). The + connector on the 2SBAT input is used for battery voltage monitoring, so if using regulated 5V input, connect the unregulated battery voltage to the 2SBAT + pin (no buck needed).
EasyEda project page with a table of values for the active filter
https://easyeda.com/jbk1/expresscontroller
I'm currently leaning to filter cutoffs in the 500 to 1000 Hz region. With the FrSky Hall sensors it doesn't look like we need a lot of filtering to get pretty smooth output.
There's a "cheat sheet" to help when assembling the filter board
https://github.com/ExpressLRS/Handset/blob/main/Wiki/images/filter_cheat_sheet.png
Flashing the dev board is annoyingly finicky, and some boards seem to be worse than others. There's a relatively short window after powering up with the boot button held when DFU is active, so you need to find a sequence that works for you. You can either hold the boot button down and apply power, or you can power up first, then hold boot while pressing reset to enter DFU. Because the boot and reset buttons are small and close together the first way is physically easier, but the second seems to have more predictable timing. The 'upload' button in vscode also has an annoyingly variable amount of delay which makes this harder. If you can't get it working from vscode, use the platformio/advanced/verbose upload option (from within vscode) to see the full command that vscode is using, copy that to a terminal and run it by hand so that you have more control over the timing.