MGL Avionics User Forum

I have posted a major update on the V16 - A16 (and A14) as well as Razor V16.

This introduces a fully digital audio link between intercom and transceivers (up to two for COM1, COM2) which also takes case of PTT. This is a huge improvement simplifying installation and wiring needs while at the same time easing setup and improving audio quality.

On the Razor V16 - it now includes full A16 control head functionality as well (By popular demand).

I'm hoping someone can help, just tried to update my A16 using the bin file, it now isn't recognised and showed not data received as soon as I restarted it for the update process to begin.

Tried the serial version with no luck as well. My 2 V16's updated fine on the serial link.

Hoping it isn't bricked.

Mike

Can anyone confirm that the RS232-USB harness for the V16 will work on the A16, or do I need to use a different 232 ground other than pin 9?

Update

Problem solved.

It would not show as online using the Windows updater, but by applying power after starting the update process, instructions say it has to be online but I ignored this.

It did recognise the A16 and after a couple of failed attempts it accepted the firmware update.

Mike

Tasmag wrote: ↑Fri Mar 04, 2022 7:19 am Can anyone confirm that the RS232-USB harness for the V16 will work on the A16, or do I need to use a different 232 ground other than pin 9?

It is the same.

If you are using a 64 bit Windows platform you have a good chance of the USB/Serial port dongle not working.
There is a lot of info on the web about this and many solutions.
Basically 32 bit drivers do not work in a 64 bit environment so your USB device needs to have 64 bit drivers. If you upgraded from a 32 bit windows to 64 bit (with a 64 bit platform) you will likely not have the 64 bit drivers. Windows installs them automatically for some dongles but it appears not all of these actually work. In some cases you need to use older drivers with a manual install. It seems pretty messy.

Our update programs are 32 bit applications but work fine in a 64 bit environment. The updater does not address the USB drivers directly - rather it goes through the normal Windows API related to COM ports. If your USB COM port shows up in your device manager without the yellow triangle it should normally work.

A further simple test is to use a simple terminal emulator (many free ones on the net) and open your COM port - then simply short pins 2 and 3 on your serial port with a small screwdriver or whatever and type on your keyboard - whatever you type should appear on the terminal. If that happens it must work with the updater as well.

lastly - it is important that once your updater app is running that power to the V16/A16 is applied cleanly. If it is not clean you get the situation that the device sends out the "OK" which causes the update up to start the next phase of the sequence - but power fails again and it does not complete. The device now sends the "OK" again - but the updater is no longer looking for this and it now hangs.
The only solution is to start the process again from scratch.
This can easily happen if your power switch is just two pieces of wire you are holding together !

Thanks rainier

I'm not sure what happened with the initial bin file update. It started as per normal but then showed no data received from the A16 as soon as I turned it on to commence the update.

Mike

I'm hoping I can find out the data format of this new digital audio interface.

I have already written my own python script to control V16 via RS232 (CAN bus in progress) and am converting the analog audio to/from the V16 with a product called "digirig" (basically a standard USB sound card, RS232, and PTT switch in one small unit), but my setup is still somewhat susceptible to a low level of audio noise which I am "gating" out using a linux pulse audio software module.

Being able to grab the digital audio i/o directly would be a super cool way to interface to my beloved V16 radio.

CD

I have not written a protocol document but it is very simple (but can be tricky - luckily the tricky part is in the V16 for you).

The RS232 port runs at a baudrate of 500.000 bits per second. 8 bits, 1 start, one stop bit.
A16/A14 (or your intercom is the master).
It sends out packets of data at 8Khz (half the actual audio sample rate used in A14/A16 and V16). Each packet contains 5 bytes. This is made up of two 16 bit values - each contains a audio sample using 16 bits in signed complementary format (just straight linear audio, nothing fancy, no compression) and a header byte.
The header byte contains the value 0x05 in the lower 5 bits - this is used to synchronize the packet on the receive side. Bit 6 is PTT COM1 and Bit 7 is PTT COM2 (a set bit means PTT active). Bit 5 has a special meaning and the A14/A16 sends it always with a value of zero.
Header byte is first followed by audio COM1 and then COM2.

This always goes to COM1 RX - COM1 then takes the audio intended for it and replaces it with its own audio. The audio for COM2 is left unchanged. Bit 5 of the header is set to 1 if it was received as 0 (which it is if the packet came form the intercom). So the complete 5 byte packet is then resent - it now is received either by COM2 or the intercom (in case no COM2 is used).

If COM2 receives the packet it knows it is COM2 because bit 5 of the header is set and takes it's audio from the packet and replaces it with its own. Bit 5 is now reset by COM2 and the whole packet is sent out - back to the intercom.

The intercom checks bit 5 of the header - if it is set - then only COM1 exists - if it is zero then COM1 and COM2 must exist (or you just wired TX to RX on the intercom in which case it simply gets it's own audio back). So the intercom now takes the audio from the packet for COM1 (and possibly COM2) and streams it into its codecs.

The intercom has the easy part - but to make life possible for the V16 the packet transmit rate must be 8Khz. The V16's inevitably will have a slightly different sample rate and this is a huge problem that will cause nasty artifacts. The V16's are not able to synchronize the internal sample rates to that received from the intercom so they perform filtering techniques to merge their own audio into the intercom sample rate - this does not completely eliminate the issue but is good enough. The intercom itself receives one packet for every packet sent so it does not have this issue.

On RX at your side - before you start accepting audio - you need to synchronize to the packet using the 5 LSB's of the header byte - as the value 0x05 can occur in the audio packets you need to track this for a number of packet counts before you can be sure you are in the correct position and keep tracking so you can detect loss of sync and restart the process. Check that your RS232 driver chip is up to the task of transmitting and receiving at this rate without too much edge slew. of course your firmware needs to be able to transmit and receive without jitter so forget about interrupts - you need to use DMA and accurate timing to get this running well.

So that's it...

I have a V16 controlled by an MX1 but no A16. Is there any gain/advantage for me in this update?