Re-reading the wiki, the instructions for copter 4.2 are contained in a NOTE box and a WARNING box.
All the old text for pre copter 4.2 still exists.
It’s unclear if any of the pre copter 4.2 wiki is significant - or if it should be ignored in it’s entirety.
I expect it makes perfect sense to those on the DEV team who developed this change - but its been pretty confusing to me.
As a suggestion, if the part below the NOTE and WARNING boxes only pertain to copter pre 4.2, that text should be identified as such - so that people upgrading to the new firmware can ignore it.
There are other instances of documentation of new functionality being added without revision to the text of the older functionality being modified to take this into account. It’s a source of confusion. The documentation for FFT that’s added to the static filter documentation is another example.
I find that SERVO14_FUNCTION=-1 makes the pre-arm warning go away - but has to be accompanied with SERVO13_FUNCTION=-1 to make the pre-arm warning for pin 54 go away as well. (my camera shutter is using the pin 55 relay)
Using the parameter SERVO_GPIO_BITMASK and checking the servo 13 and servo 14 tickmarks will also cause the pre-arm warnings go away.
I’ve discovered that the relay doesn’t behave properly with the release candidate. Perhaps there’s another parameter I’ve neglected to set.
I’m going to write it up under a separate post - but in a nutshell, the release candidate causes the relay to go high un-commanded.
Using the SERVOn_FUNCTION=-1 method, the relay goes high about every 10 or 15 seconds - causing the camera to start and stop recording on it’s own.
Using the SERVO_GPIO_MASK to enable servo 13 and 14, the camera starts when the firmware boots up - as it did before. (bootloader issue - the relays go high momentarily on boot up) The camera stays on, as the relay doesn’t seem to go high on it’s own. But when I command the shutter causing the relay to go high again, after the camera stops recording, it will start up again - apparently through the relay going high again un-commanded.
None of the un-commanded relay high actuations have associated MavLink messages.
So either I still haven’t set the right parameters, or there’s a bug in the release candidate.
Other than the unrelated boot loader behavior, I have not experienced spurious GPIO behavior (multiple Cubes and H7-based Matek boards).
For the one vehicle where it’s critical, I avoid the boot loader GPIO trigger by using a PWM (RC) controlled relay as a (logic level) power supply switch to my main relay board. It failsafes to off if valid PWM is not observed. I have it set to switch on in conjunction with my ignition circuit command, which coincides with the first time I want to use any other relay.
These parameters are with the servo_gpio_mask settings.
This works better than the servo(n)_function settings.
Using the servo_gpio_mask settings, the relay will go high - causing the camera shutter to release and the video to start recording - until I actuate the camera shutter from my transmitter - which triggers the shutter again and ends the recording. Unfortunately, the relay goes high again un-commanded, in about 10 to 15 seconds after the recording ends.
Using the servo(n)_function method, the relay goes high un-commanded every 10 to 15 seconds no matter what the camera was doing on startup.
Thanks for reminding me about the RELAY_PIN(n) parameters - I remember setting them up when I first configured the relay for the camera shutter - but I’d forgotten where to find them.
NOTE: There is no “RELAY_PIN1” parameter. The fist pin is addressed as “RELAY_PIN”
I set the parameters as you suggested - and still experienced some issues.
It occurred to me that the camera may be playing a role - the camera is heat sensitive - the docs for the camera direct that it must be in motion with the drone within about a minute to avoid over heating.
So I set up a test rig with a box fan to keep the camera cool.
With the extra cooling, the camera behaved much better. I operated the camera in video capture mode for over 5 minutes with no problems.
However - when triggering the shutter to stop recording, the camera would spontaneously start recording again - anywhere from a minute and a half after stopping the recording - to about 3 and a half minutes.
It’s not possible to know if the spontaneous shutter release is caused by the firmware - or the camera. But as no MavLink message is issued, I’m thinking it’s more likely that it’s the camera itself.
Since the recording time doesn’t seem to be affected - at least for up to 5 minutes - it’s less of an issue.
I’ll do some test flying tomorrow and report back.
Definitely sounds like a camera issue. I should think spurious relay output would’ve been seen before by any number of other users. You could try connecting an LED and current limiting resistor to the relay output to help determine root cause.