Bit of a mystery here Allan. It has good positional data (EK3 IMU0&1 using GPS) and there are no messages to explain why it’s disarming like there was when you had Radio FS’s.
To see the the map from the Log browser simply click the “Map” checkbox.
Actually, what do you mean by this? What is the same? I see you flipping the Arm/Disarm switch repeatedly.
Good question Greg; it’s fibreglass as far as I can tell.
Dave, I meant it doesn’t arm, just like my previous attempts. It was not connected to my laptop this time so I was flipping the arm switch every 30 seconds to see if it would arm. Each time I did that I got the arming buzz immediately followed by the disarm beep, so I then flipped the switch back to disarm and waited another 30 seconds. I think the log shows I did this for 5 minutes, and all the time I had at least 11 sats and hdop less than 1.0.
Thanks for the info about the ‘map’ checkbox.
I’ll be at the flying field on Sunday, so I’m going to wait until after I’ve tested there before doing anything more. Next step will be to remove the heli from the fuselage (again!) and see if it works bare-frame.
Yes, OK. I can see that now graphing Chan7 and the Arm State. I can’t see why it’s disarming, perhaps Shawn can locate something.
A test at the flying field, in the middle of a football field, revealed nothing new. Just the same arm/disarm sequence. So the heli will be out of its fuselage later this week, and I’ll start again.
Today I got around to removing the heli from its scale fuselage, in case that was causing the issue, but still the same problem – as soon as I arm the heli I get the long buzz that indicates it’s arming followed immediately by a short ‘bip’ that indicates a disarm, as shown in this brief log.
2023-02-27 16-25-19.bin (700 KB)
When connected to MP, with the heli indoors, I’m now getting various Prearm messages. At the moment it’s ‘Fence requires position’ even though I’ve got 11 sats. But that doesn’t cause it to disarm as soon as I arm – it simple doesn’t allow me to arm in the first place. If I disable fence, that message goes away (and there’s no other prearm messages), and once again it’s disarming as soon as I arm.
Apart from disabling the fence, the param file is the same as it was at the beginning of this thread.
The only thing I can see that would prevent arming is
PreArm: GPS 1 failing configuration checks
But I cant see why that would be so, the GPS and SERIAL setting all look reasonable.
Is a TX or RX wire in the wrong place, soldered to the wrong pad?
You have both Serial3 and Serial 4 set for GPS (protocol 5) so maybe disable one of those by setting protocol 2 just to rule out which serial port and RX/TX pads you are using.
EDIT: I suspect if the TX and RX wires were not connected to the same serial port pads then the GPS probably wouldnt be detected at all. I guess it’s something to rule out though.
It’s puzzling why it Arms then Disarms. Which GPS Module is this Alan? Perhaps try disabling the Galileo constellation. Admittedly not much logic to that but it’s not one I use.
The message “u-blox solution rate configuration 0x208” at the same time as the Configuration fail checks msg Shawn mentions is odd but don’t know what to make of it.
Just a shot in the dark, but save your parameters, flash arduplane or rover and then arducopter again. I had times when a bit seemed to have flipped causing inexplainable behaviour.
This is driving me crazy! count74’s suggestion struck a chord, for after I’d test-flown the heli back in November without the scale fuselage, after installing it in the fuselage I connected to MP to recalibrate the compass and at the same time was prompted to update to v4.3.3, which I did. So that’s the only difference between when it was working okay and when it’s not. Anyway, flashing arduplane and then re-flashing arducopter today didn’t solve the problem 
From my experience with other FC software I’m sure you’re right that it won’t register GPS and/or compass at all if the physical connections are wrong Shawn. Anyway, I’ve disabled Galileo and I’m showing the same number of sats but still getting the arm/disarm problem. I then set Serial3 and Serial4 protocol to 2 in turn, with the other one at 5, and still the same problem.
The GPS module is Matek TAOGLAS CGGBP.25.4.A.02 and the FC is Matek H743MINI connected as shown in this diagram
Just in case I’ve inadvertently changed something I shouldn’t have while doing these checks, here is the param file as it is now
Hughes 500.param (20.6 KB)
Next I’ll check the hardware, first by plugging in a different GPS unit.
I suspect there is something set in the Module that is not getting reset at boot configuration. Try this (from the Matek product page):
I see this module is EOL now.
Thanks Dave. When I bought it I thought M9N would be ‘better’ than the usual (at the time) M8N, though I now remember noting that they’d quickly moved on to M10N. I’ll try their reset sequence tommorow, and I’ve just put a plug on an old M8N to try that in its place as well.
I think that’s generally true and there are some reports of issues with the M10 but nothing definitive that I have seen.
This afternoon I temporarily replaced the Matek GPS unit with a RadioLink GPS SE100. After I’d reconfigured for the new GPS and compass I got the same result – I arm and it immediately disarms, with no Prearm messages showing in MP. Here’s the log file of this latest test, in case it shows anything new:
2023-03-01 16-00-54.bin (642.1 KB)
I haven’t tried resetting the M9N yet (bridge RST and GND with it powered on?), but since I’ve got the same issue with another module that would seem to me to demonstrate that the M9N is not at fault.
I still don’t know what the problem was, but I’ve installad a Matek H743WING board instead of the H743MINI, and I’m now able to arm 
I started from scratch with the parameters, went through the mandatory hardware setups, and then manually copied specific parameters such as FENCE_ from my previous setup and left the others at default.
So all I can say for sure now is my Tx and Rx were not the cause of the issue, nor was my heli’s physical setup, for they haven’t changed.
