From time to time at the flying field I’m frustrated by my heli not arming, even after waiting long enough for a good satellite fix. I know I ccould set LOG_DISARMED to 1 or 2 to create logs prior to arming, the penalty being a much bigger log file. Is there any chance there could be an extra configuration that would record pre-arming data, but then delete it immediately arming is achieved and continue logging the flight as normal?
What problem are we trying to solve?
It seems like your complaint is a lack of real-time information in the field regarding pre-arm status, but your proposed fix is one that would optionally allow post-event forensics after a failure to arm (which is incongruous).
What are you using in the field to monitor pre-arm status? Do you use any GCS or RC handset with telemetry available?
You’re right; it’s the lack of pre-arm information. But I disagree about the incongruity, for knowing what’s going on might allow me to make some adjustments after the event – i.e. back in my workshop. The scenario is that sometimes I power up and the copter doesn’t arm even though the GPS LED tells me it’s got a fix (but, admittedly, maybe not good enough fix for Arducopter) and several minutes have elapsed. So I disconnect the battery, sit down and have a cup of tea and a natter, then power up again and the copter arms within about a minute, as expected, and flies in stabilised, alt-hold, pos-hold, and RTL modes without any glitch.
I use FrSky Taranis Tx and FrSky receivers. Some time back I was told about some telemetry that can link Arducopter to my Tx, but I can’t remember what it was and I couldn’t figure out how to install/configure it. Also I feel more comfortable making adjustments in the workshop, rather than in the field.
I think the fixes are these:
Most easily:
Enable LOG_DISARMED for a few sessions out in the field. When you have one of those prearm issues, download the most recent log and share it. I suspect you simply need to relax the HDOP requirement, and all will be well forever.
Slightly more complex but arguably most correct:
Bring a laptop to the field and monitor the prearm checks over radio telemetry to see which one is failing most frequently.
Most complex (to configure), but most easily employed on a routine basis:
Use the Yaapu telemetry script, which sounds like it is very likely compatible with your RC hardware.
I’m not sure we want to enable a feature where we auto-delete logs of any sort.
Thanks for your reply Yuri_Rage. I’ll follow your ‘Most easily’ suggestion and see where it takes me 
I’m not keen on taking a laptop to the field because it’s another thing to carry and we have to park over 100yds away from the pits.
Yaapu was what people had suggested to me a while back (can’t remember why), and is compatible with my Taranis, but I couldn’t get my head around how to set it up.
It would be worth working thru Allan. Rare that I need a Ground Station on-site and it gives’s you most of what you need.
1 Like
I seem to have solved the problem by increasing GPS_HDOP_GOOD from the default of 140 to 300. But I don’t understand why, for both my other helis with same FC and same GPS are still at 140 and don’t have the same long delay in arming.
Perhaps that specific receiver, antenna, cable, or combination thereof is a bit worse than the others, causing reception issues that aren’t catastrophic, but do affect precision.
If you put two of them side by side in an open field with LOG_DISARMED,1 and power them on at the same time for about 10 minutes, maybe we could do a little analysis on the resulting logs.
Thanks Yuri, I’ll do that and report back next time I have the chance. In the meantime another issue has cropped up which might possibly be related. I’ll start a new thread for it.
Since both helis use the same Tx I powered them up one after the other: The JetRanger first because I know it will be quick (it was ready in about 1 minute) and then the problematic TRex500 which then took over 5 minutes to give the ‘ready to arm’ tune.
Here’s the param files and links to the .bin files:-
Trex500 GPS_HDOP_GOOD changed from 140 to 300.param (18.2 KB)
Jet Ranger after MagFit (COMPASS_OFS_Y still out of less than -400).param (21.3 KB)
Edit: This issue may be related to one I brought up in [another thread](Repeated 4 beeps during flight - #4 by abenn1).
The Trex500 log clearly shows far worse GPS performance (an order of magnitude worse) than the JetRanger. It’s receiving 5 fewer satellites with much worse reported accuracy.
They are on slightly different firmware, and the GCS message set differs, but it looks like identical autopilot and GPS hardware.
In the other thread there was some talk of wiring, but I don’t think that’s the problem. If you had a wiring issue, we’d see more problems with serial message receipt. We are getting the messages, it’s just that the content shows bad performance.
I think this issue is the same as in your other thread - that GPS module is not performing up to snuff.
Do you have a spare GPS module you can swap into the Trex500? I’m wondering if you just got a bad one (with poor internal grounding or something like that).
1 Like
Thank you Yuri. I’ve got so used to it being builder or pilot error that I didn’t think of a bad GPS unit, but that appears to be the case.
As luck would have it I have another identical GPS unit waiting to go into another model, and swapping it into my TRex500 resulted in ready to arm in less than a minute (after I’d calibrated the new unit). That was with GPS_HDOP_GOOD at default 140.
1 Like
Unfortunately, the complexity of ArduPilot often means that user error is to blame for issues. I know you’re pretty experienced with these frames, and simple, single GPS configuration is usually straightforward enough, even for the new guys. Your issue had none of the hallmarks of typical user error, which made it a lot easier to point to a hardware problem. Glad you had a spare on hand, and hopefully you can get a refund for the bad one.
1 Like