A UBX-TIM-TM2 message is output at the next epoch if
• the UBX-TIM-TM2 message is enabled
• a rising or falling edge was triggered since last epoch on one of the EXTINT channels
The UBX-TIM-TM2 messages include time of the last timemark, new rising/falling edge indicator, time source, validity, number of marks and a quantization error. The timemark is triggered continuously.
The UBX-TIM-TM2 message includes the channel on which the timemark was recorded.
So:
- you can record on both channels
- you can differentiate to which channel the timemark belongs (you might need a script to divide the result, take a look at the timemark time machine, it would be possible to add a function to split the RINEX file in two files for each channel)
- you only can record one event per epoche, so you need to make sure that you fire the events in an alternating pattern. I.e. release the second camera with a 500ms delay or better release the the second camera after you have recorded the event of the first camera - e.g. with an additional Arduino or ask Ardupilot to integrate such a function.
I’m interested in such setup, I think it would be quite easy to integrate with an additional microcontroller (Arduino) which handles the triggering. It would basically need to have an input to trigger the release sequence, then release the first camera, wait for the hot shoe signal, release the second camera after a certain delay and wait for the second hot shoe signal before allowing the first camera to be released again (also with an delay). I guess that is some lines of code, some optocoplers and there you go for less than 15€ even if you go for a Adafruit build microcontroller.
But as @Stu74 I have 3 of the original units without the second input, so I cannot test it. Anyhow, with the time offset you could also use the original Reach unit if you use a pattern like “first camera, 250 ms delay, second camera, 1.000 ms delay”. The timemark time machine could then sort out each timemark where the previous timemark was less than 300 ms to ago to another RINEX file.
I also don’t think a delay introduces an additional problem if you want to overlay different channels. The problem that you do not have exactly matching pixels for each channel is introduced by using different cameras anyhow and you need to fix that somehow else.