EXPERIMENTAL - AUDIO-PTT

In response to a request for the race control audio prompts emanating from DSRC (countdowns and additional prompts if enabled) to be transmitted by radio to the racing fleet, which may be spread out for some distance around the start area, particularly for ocean racers :o)

It should go without saying that is the users responsibility to use equipment, frequencies, and modes in a manner that complies with their local laws and regulations (but I've said it anyway :o).

This page goes into some of the details around the possible solutions to this, and the DSRC Experimental extensions to enable this to happen.

Overview of requirements

Control of a 'control' radios PTT (Push To Transmit)

Most radio systems have an external jack for a handset that allow control of the PTT, plus audio in (mic). 

The aim of Audio PTT is for DSRC to provide PTT commands to switch between transmit and receive ('P1' = ON i.e. transmit, 'P0' = OFF i.e. receive).

As any radio system take some time (and it will vary) to switch the 'control radio' to transmit and the 'fleet radios' to open the receive squelch.

It is therefore necessary to delay (as little as possible) the audio whilst the PTT actions completed. 

Please note that none of these delays impact any DSRC timings, just the audio e.g. a finish time is captured/stored before the audio side is commenced.

The 'pre-delay' is adjustable via the Settings screen, and should be 'tuned' to as short as possible, but with the full audio prompt being heard at the receiving radios.

Additional requirement -  The ability to 'suppress' the horn sounds being transmitted during start sequences (switchable of course) to avoid 'hearing the horn twice' if near race control.

DSRC audio prompts

Of course, just making a radio switch to transmit is only half the story...

What is also needed, is to supply the radio with the DSRC audio (i.e. countdowns and prompts), and at a level the radio can accommodate.

This is probably the hardest part to achieve, and may well vary depending on users individual requirements.  

Also, remember that Race Control will still want to hear the audio!

Here are a few thoughts:

• Use the headphone jack on the Android devices running DSRC, but this would mean a 'trailing' lead, which gives it own issues (trip hazard, fixed length)

• Use a Bluetooth (BT) speaker linked to the Android device running DSRC, and somehow take an output feed from that to the radio (probably via a matching circuit) 

• Use a Bluetooth 'module' (linked to the Android device running DSRC) that has two outputs, feeding one to a speaker (probably powered) for Race Control, and the other to the radio (again probably via a matching circuit)

I have opted to test with the BT module, and the following notes focus on that. But remember, it's not the only way...

Mechanics

PTT

There are no doubt a number of ways to 'trigger' a Radios PTT, but here I'm going to focus on two I have tested (see fig 1 for example of handset wiring i.e. the one I'm using):

Relay module

If you are already familiar with using a wifi multiple relay board, and have a spare relay on it, then this might be the easiest mechanism to start with (although it does have the draw back of being the slower of the two methods described here).

Basically you edit the existing DSRC firmware to spot the new Audio-PTT incoming commands (i.e. 'P1' and 'P0'), and switch the spare relay accordingly.

And connect the relay contacts between the appropriate pins of the handset connector for the radio type you are using (it will vary a lot, so you need to be sure)

I have successfully tested this method by reassigning the 'Class 2' relay in my race box for PTT control (and it wasn't as slow as I thought it would be)

See Fig 3 for extarct of possible code for PTT relay control.

GPIO and MOSFET

If you are already using a MCU to control horn, lights, etc. and have a spare GPIO pin, then you can use that to control a small MOSFET circuit which 'grounds' the appropriate PTT pin on the RADIO. This is my preferred method, as it's quicker to switch compare to a relay, and probably more reliable in the long run.

AUDIO

As I stated earlier, there are no doubt quite a few different ways to create an audio fed compatible with the mic input to a radio, but I'm going to start the discussion off with what I'm testing with at present i.e. a Bluetooth (BT) board that has two outputs.

Firstly let me address the easy part... I'm using one outputs (with I believe is for speaker/headphones) as an input to a powered (30W) speaker, which is for the Race Control to continue tho hear to audio once the BT board is linked.

Now the harder bit. The BT board's second output is of line input level (too high for a radios mic input), and it's also stereo (radio wants mono), so theres a bit of electronic 'magic' required here:

Mix the left and right channels into a single mono signal.

Reduce the signal level to something the radio can cope with (and best have this adjustable for varying radio needs)

So below is a sort of schematic for what I'm testing:

Firmware

Relay PTT

GPIO and MOSFET

Testing observations (so far)

• Was able to set a reasonable level for a good radio received audio using the interface variable resistor.

• DSRC functioned well in providing the correct PTT On and PTT off at the expected times for both countdowns (10, 5, 4, 3, 2, 1) and additional prompts (e.g. "30 seconds to start")

• Using GPIO & MOSFET mechanism, was able to reduce pre-audio delay to 250ms, so very little delay at critical events i.e. finishes. 

Issues

BT board seems to have a random (can't pin it down, and I've tried) timeout is no audio is received for a while....

So some time (and it varies) after race start. I hear a disconnected 'tune', and then a reconnected one shortly after. 

But this is not the real issue, as somehow (and I don't yet know how or why), this event also upsets the DSRC 'hub-timer' MCU, causing it to reboot I suspect and therefore loosing the link to DSRC. The links are reestablished, but the wifi icon sometime stays red?

I have coded in a BT 'keep awake' that sends a 'empty' audio at a regular period. 

This period is currently adjustable under the Audio-PTT controls, but it is unclear how short a period it requires.

Still testing this, but I suspect to be 100% sure, the period will need to be short, say every 4 to 6 seconds.

Will update this as I find out more.... be a shame if this route proves unusable, as when it works, it works well!