To flash the ELRS firmware I pressed only the ELRS boot button. To flash the FC firmware, I pressed only the FC boot button. This part of the logic worked on my FC.
I’m on ELRS 2.2. WiFi still does not work; apparently it is hardware-broken in my FC. Shit happens.
I have just done tuning the battery sensors, and, surprisingly, the layout is much different from the proposed values.
The file libraries/AP_HAL_ChibiOS/hwdef/JHEMCU-GSF405A/readme.md reads:
BATT_MONITOR 4BATT_VOLT_PIN 11BATT_VOLT_SCALE 11BATT_CURR_PIN 13BATT_CURR_SCALE 17and this is how ArduPilot initializes these values (apart from the first one, which is quite strange).
However, what I’ve found out to be working is actually:
BATT_MONITOR 4BATT_VOLT_PIN 13BATT_VOLT_MULT 11BATT_CURR_PIN 12BATT_AMP_PERVLT 40.8BATT_AMP_OFFSET 0.001One may ignore the parameter naming. However, the pins are definitely different, and current scaling is definitely much different (the two latter values may vary since these result from empirical calibration, but definitely not 17).
IMO this may deserve some investigation.
These could easily be wrong in the hwdef. It’s always the last thing I check and usually only if I am flying a board.
Thank you for figuring this out.
@andyp1per What is the relationship between the ADC pin assignments and the HAL pins?
# analog pins
PC3 BATT_VOLTAGE_SENS ADC1 SCALE(1)
PC2 BATT_CURRENT_SENS ADC1 SCALE(1)
# RSSI analog input
PC0 RSSI_ADC_PIN ADC1 SCALE(1)
define BOARD_RSSI_ANA_PIN 1
and
# define default battery setup
define HAL_BATT_VOLT_PIN 11
define HAL_BATT_CURR_PIN 13
define HAL_BATT_VOLT_SCALE 11
define HAL_BATT_CURR_SCALE 17
Look in hwdef.h for HAL_ANALOG_PINS that should tell you the pin numbers
Well, that’s not a 1st April joke, that’s something even worse.
A JHEMCU GSF405A-based HD ArduWhoop that actually flies!
Here are the test indoor videos from the actual HD camera. Apologies for the mess at home 
The weight is 56g with a 850 mAh 1S battery, of which the camera is a large percentage. The hover current is 5-6 amps with 0802 19000kV motors and 51mm props.
The current awkward build is a pusher because the FC has a USB port pointing downwards, where a battery would be an ideal option. Due to this I had to add an idiotic support, so that it does not spin on the ground while arming. However, a Throw initial mode will probably work better
Good job!
In order to use all the advanced functions of arducopter, will you also mount gps and compass? I think you will have to modify the frame and more …
That would be too heavy for this small guy The compass would also probably be jammed by the motors, as they are very close to everything onboard.
Maybe I will eventually do that if I find a more lightweight option for a camera. For that, I would probably drop an idea of having a 4K recording camera.
Also it may be a good idea to add a short-range lidar and optical flow instead. This would work better indoors, where GPS would be a non-option anyway.
I preferred to use a 3 "frame just to have more space for gps and compass (otherwise I would have used betaflight).
I also used optical flow. That’s actually light enough even for a whoop. Here you will find the type of optical flow and some test videos (at 25m).
I already have a sturdy full-blown 3" based on Matek H743-mini, which I really love.
I treat this small thing as a proof-of-concept whoop build, where I investigate how Ardu copes with such small sizes. As of now, I am in the process of tuning (and also frame redesign), and I can say that - probably due to high rotation frequencies - it is very easy to get a significant horizon drift if the D-terms are just a little too high.
Unfortunately, it seems that I have two out of four ESCs seriously damaged.
What is more, it seems to be like that from the beginning - in a hover, the outgoing RPMs were noticeably higher for them - but got worse recently, with one of them just stopping on any attempt to lift off. I will probably check whether the problem is indeed ESCs and not the motors, but overall that’s somewhat sad.
any help on binding this board to the jumper t lite happymodel lite module?
The thing is, this board seems to come with some 1.x ELRS firmware version. So if you have a 2.x ELRS on your transmitter, you would like, most probably, to upgrade firmware on the board.
If you are lucky and your board has a working ELRS WiFi, then you just go and follow the usual route of uploading the fresh firmware through that WiFi. That firmware would have the binding phrase, which shall be the same as the binding phrase on your transmitter, and then it works. (The latter sentence also works for each and every subsequent case).
However, both of my GSF405A boards have broken WiFi, so much broken that it is not ever seen by a laptop or a smartphone at a distance of 1cm. Then, the next simple way is to use Betaflight passthrough. Since the board comes with Betaflight preinstalled, it is a good habit to update ELRS before uploading Ardupilot. My second board was dealt with using this route.
Theoretically, UART passthrough may also work, and Ardupilot supports some kind of that. However, I did not manage to make it work, no matter how I tried. The ELRS configurator just cannot talk to the module through Ardu. Of course it may be me who missed the right recipe, but my experience with this route is negative.
The final and the ultimate way is to solder the Rx/Tx wires to the pads which this board made accessible, and to use an FTDI or a similar device to flash the ELRS chip directly. This seems risky, but it is actually possible; for the sake of safety, set SERIAL1_PROTOCOL to -1 beforehand. This is how I flashed my first board.
To keep you updated. The new carbon frame, as well as soft-mounting (frame+motors versus FC+camera+battery), did the trick, and now the vibrations are at the sane level.
However, the craft still did “the leans” a lot, quickly getting impossible to keep level even with pitch and roll at maximum. The log analysis showed that accelerometers are fine and quiet, but gyros drift a lot. What is more, gyros drift a lot even when disarmed, so this is definitely not due to vibrations.
This matched some recent messages that some batches of MPU6000 suffer from gyros drifting a lot, much unlike before. Maybe I have both my GSF405A boards with such problematic chip.
Fortunately, Ardupilot can cope with gyro drift thanks to EKF, but the default configuration seems too conservative for this particular chip. So I went on and set the following:
EK3_GBIAS_P_NSE = 0.003
which is greater than the maximum recommended value of 0.001. This was just a random guess for a value. However, it did the trick, and just few minutes ago I have performed the full-duration hover flight in Stabilize from 4.2 to 3.3 volts uninterrupted. So at least this craft is now manageable.
The only thing is that the log of that flight stopped after 6 minutes of flying due to the 8 megabytes being just too small. I guess I have to stop IMU batch logging from now on
Since here is the only place I can find for discussion about GSF405A Flight Controller, for a record and try to help others with difficult to update ELRS. I have a successful update ELRS 2.5.0 by Betaflight passthrough from ERLS configurator. But I cannot get a stable way to do it, sometime It will have error of cannot connect to the RX. The time I success is I select all the target and settings first, then I plug the flight controller a few seconds before I click “Build & Flash”. And this time ELRS can connect and write the firmware.
Finally I can let my ELRS TX to communicate to the FC.
Just to keep you updated.
Build #4, with a small FPV-only camera.
24g dry, 40g wet with a 850mAh 1S battery.
It hovers on 3.3 amps on a fresh battery, with vibration levels at 3 for VibeX, 5 for VibeY, 2 for VibeZ. What is more, it does not seem to suffer from Z position innovations that prevented altitude holding in the previous build, which is probably due to better vibration isolation and the barometer properly coated.
The copter is still a little bit undertuned (overcontrolled), but otherwise is capable of doing nice simple flights.
Flight times up to 12 minutes seem to be possible with the batteries I have, based on both the capacity numbers + current statistics and the actual autotune flights.
Hi,
I tried ELRS firmware update via Betaflight passthrough but it is not successful. Do you have any advice for me? My ELRS configurator settings are:
Device category: JHEMCU 2.4 GHz
Target: JHEMCU RX24T 2400 RX, JHEMCU EP24S 2400 RX, JHEMCU SP24S 2400 RX
*I tried all 3 “Target” above. then I saw the error as follows:
======== PASSTHROUGH INIT ========
Trying to initialize COM13 @ 420000
[ERROR] Invalid serial RX configuration detected:
!!! serialrx_provider != CRSF !!!
Traceback (most recent call last):
File "C:\Users\apoch\AppData\Roaming\ExpressLRS Configurator\firmwares\github\ExpressLRS\src/python/BFinitPassthrough.py", line 170, in <module>
Please change the configuration and try again!
bf_passthrough_init(args.port, args.baud)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\apoch\AppData\Roaming\ExpressLRS Configurator\firmwares\github\ExpressLRS\src/python/BFinitPassthrough.py", line 77, in bf_passthrough_init
raise PassthroughFailed(error)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PassthroughFailed:
[ERROR] Invalid serial RX configuration detected:
!!! serialrx_provider != CRSF !!!
Please change the configuration and try again!
*** [upload] Error 1
========================= [FAILED] Took 44.91 seconds =========================
Environment Status Duration
---------------------------------------------------- -------- ------------
DIY_2400_RX_ESP8285_SX1280_via_BetaflightPassthrough FAILED 00:00:44.912
==================== 1 failed, 0 succeeded in 00:00:44.912 ====================
According to information on JHEMCU GitHub, in ELRS.7z file shows the target should be “DIY 2400 RX” and device is “DIY 2400 RX ESP8285 SX1280”.
And your result is normal fail case in my previous try and error. Even I success one time, I cannot understand how that time is working. I can only tell you that the time I successfully is plug the FC and wait for 2 to 3 sec, then I click “Build and Flash” in betaflight passthrough mode
Are you following these steps for flashing with betaflight passthrough Betaflight Passthrough - ExpressLRS ? it seems that the RX will need to be powered off which suggests that a built-in elrs cannot be flashed using this method. So it might be the cause for some of your successful tries?
