MGL Avionics User Forum

I'm working on the XFS driver for the A16 audio panel and just want to confirm a few things:

1) With the CVR function, it does not appear to be the case that you can repeat the last received transmission (e.g. from COM1 or COM2). Is that the correct understanding? If not, can you direct me to a way to do so?

2) The setup protocol does not appear to provide a way to set the volume, gains or vox to a specific number but rather require incrementing or decrementing the current value. Is that correct? If not, can you point me to how to set those values and if my understanding is correct, I'd like to request a way to set these values to specific numbers. The increment/decrement approach is not conducive to the type of highly redundant driver model we use within XFS.

Thank you!

Mark

The CVR records COM1 Rx and COM2 Rx as well as intercom (including radio TX).
It is a continuous recording that excludes gaps. So it records when the VOX opens or there is RX. It's function is not to repeat the last transmissions - that is a function built into the radio itself if you have a V16 or another make that does similar.
The CVR is intended for accident investigation and typically records the last 30 to 60 minutes of activity. You can request playback of the entire recording.

You find out the current volume level in the secondary status message which is broadcast at 5 Hz if anything changed between the current and last interval or at a minimum rate of 1 Hz if nothing changed.
You then use the inc and dec message. You can post multiple if you like - the A16 has a large RX buffer. So if you have a known level of 25 and want 35 in one go - send 10 INC messages.
The protocol does not make provision for a direct numeric setting as this is not needed for our systems.

Rainier,

Thank you for the explanation. I'd like to encourage you to reconsider this design limitation in a future version of the protocol -- perhaps by allowing a message to be sent in a similar format as those nice, concise and deterministic ones that are currently received *from* the unit. While we can probably produce an XFS driver using the inc/dec mechanism, it does not lend itself to providing high reliability through deterministic operation -- especially if more than one instance of the driver is expected to be running within a non-trivial system implementation which leverages redundancy.

Mark