Synchronized audio bleeper between two devices

Projects General Guidance
1

I have a programming background and have tinkered with Arduinos in the past (and Raspberry Pi). I think the Arduino is better suited to a small project I have to make my vlogging activities easier (due to small form factor and low power consumption).

However, I have never built something along these lines using the Ardiuno family of accessories etc. and would welcome some input from the amazing community here.

The idea is simple enough, press a button on "a device" to make a series of beeps (different tones, but the same on each device) at timed intervals on all paired devices. This would enable me to sync up the audio/video on several cameras at once. The catch is that the other devices could be quite some distance apart. For the moment, let's ignore power supply sources (though USB is readily available) and weatherproofing. I have access to a 3D printer, so this may be used in the future once the hardware decisions and testing have settled on a final unit.

Ideally, it would work at the outer limits of whatever Bluetooth can offer (like a Bluetooth intercom system does). Instead of broadcasting the notes as audio, I'd prefer to send a command to generate these in sync with the originating device. I think the parts I am needing the initial help with are board choice and any known limitations which may affect my project requirements.

If anyone would like to team up with me to develop and test this, I'd be happy to talk this through. I hope to begin purchasing components this week and test next week.

2

I think it would be very difficult to sync audio and video with a wireless signal due to the latency and possible interference with a wireless signal.

More details of exactly what you hope to do would useful.

What is the biggest acceptable timing error - in millisecs or microsecs?

...R

3

I'm only looking to sync the creation of the beeps from the Arduino. No video or audio for the vlogging, sorry if I didn't make that clear. I'm basically trying to make a wireless clapper board which can be triggered from either ride once all the cameras are rolling. Triggering the digital clapper board would make a quick series of tones on each which the GoPros would pick up, used later for sync'ing the audio/video in the editing room. As we would be riding at the time, it isn't practical to stop to do the clapper board and using horns isn't always good due to the time of day etc.

4

vacantinside:
I'm only looking to sync the creation of the beeps from the Arduino.

It is still important to know what level of timing error is acceptable.

Another issue is whether the receiver should act on the pulse immediately or just note its time for later use.

Bluetooth is essentially a one-to-one system but you could use nRF24L01+ transceivers organised so that several can receive the same message from a master Arduino. However in that situation there is no means to verify that all the receivers get the message.

You have not mentioned the range over which the wireless must work and whether there may be obstructions between the Tx and Rx - such as walls or trees or crowds of people.

...R
Simple nRF24L01+ Tutorial

5

Robin2:
It is still important to know what level of timing error is acceptable.

Another issue is whether the receiver should act on the pulse immediately or just note its time for later use.

Bluetooth is essentially a one-to-one system but you could use nRF24L01+ transceivers organised so that several can receive the same message from a master Arduino. However in that situation there is no means to verify that all the receivers get the message.

You have not mentioned the range over which the wireless must work and whether there may be obstructions between the Tx and Rx - such as walls or trees or crowds of people.

...R
Simple nRF24L01+ Tutorial

Thank you so much for your reply - all very useful at steering me towards a possible solution.

The range would need to be around 500 meters maximum, though I could work with less (say around 100m). Ideally <0.5sec difference between each device emitting the tone(s). I will look into the transceivers and see if I could make this idea work.

The way I envision this working:

Two (or possibly more) "paired" units (one per motorcycle), each with a speaker or piezo buzzer for emitting a series of different tones (so that the rider GoPro cameras can hear at least one tone clearly over wind and other noises - we will usually be in motion when activating the tones). The purpose is to use these tones to sync up the video files from all GoPro cameras in the video editing software.

As for interference, I imagine lots of possible sources - the bikes themselves, other vehicles and building, bridges. But all of these would vary from minute to minute (even the action of accelerating could produce different interference from the bikes compared with just idling). I'm happy to explore and test different solutions to find one which is reliable.

Rider 1 presses a button on their device. This instigates a wake-up/sync call to the other paired (I use the term paired as I originally imagined using Bluetooth) device(s). Once this is done a second signal is sent for each device to begin emitting the preprogrammed tones at the same time. This ends the cycle.

The process needs to be simple as we must minimise distractions or complications, hence the one-button press approach.

We would want to use this multiple times throughout a journey as we would be turning the cameras on/off to save power (and editing time!). Having this tone timed to match will make it much easier to sync up the video files in editing.

6

Let me try to write down what you want, as I understand it, and do please correct me if I've got it wrong.

There will be a number of people riding motorcycles.
One rider will be the designated "master"
When the master presses a button on a Arduino attached to his bike
a wireless message (perhaps just the character 'T' for tone) will be sent to the Arduinos on the other bikes
when the message is received the Arduino will make a tone or beep that can be picked up by the GoPro microphone
the idea is that the recordings on all the GoPros should record the tone at the same time
so that someone editing the video can easily identify the same place on several videos

I also have the notion that the purpose of recording the tone on the videos is (using the concept of a book) to give the person doing the editing a pointer to the appropriate page, or perhaps the appropriate paragraph but not as detailed as a specific letter on the page.

If there is the possibility of interference then I think it would be wisest to send individual messages to the bikes so that the normal acknowledgement process can tell the master that the message has been received. A successful round-trip message with an nRF24 (i.e. message plus acknowledgement) takes about 3 millisecs and a failed ack might delay the master by about 7 millisecs (the time depends on the chosen number of automatic retries), so for maybe 10 bikes it should easily be possible to communicate with all of them within the same half-second.

I see no reason to add the complexity of putting the Arduino to sleep. If you use a 3.3v Arduino and power it and the nRF24 from a pair of AA alkaline cells you should get 20 hours or more of operation before the batteries need to be replaced. (I have built some radio-control transmitters that work like that). If you can power it from the bike then you have what amounts to unlimited power.

It would probably be a good idea to use a high-power nRF24 (with external antenna) for the master to obtain the range you need.

...R

7

Thank you, Robin. Yes, you have the broad strokes correct. 10 bikes would be a huge number, I'm aiming first for two then a third and perhaps more but probably no more than 5. I don't expect that makes a jot of difference to your thoughts above.

At first, I think I'll design the test rig to not both with the acknowledgement. Once it works (within a room) I'll then add this in and probably add LEDs to indicate that no acknowledgement received (either due to distance or interference - the distinction doesn't matter).

I'll source the parts and order them later today. Many thanks for your help, Robin.

8

vacantinside:
and probably add LEDs to indicate that no acknowledgement received (either due to distance or interference - the distinction doesn't matter).

The advantage of using the acknowledgement is that the nRF24 can be set to make several retries before admitting failure.

You could write your program so that it would have another attempt at sending a few seconds later if there was a failure - before bothering to notify the rider.

...R

9

Robin2:
The advantage of using the acknowledgement is that the nRF24 can be set to make several retries before admitting failure.

You could write your program so that it would have another attempt at sending a few seconds later if there was a failure - before bothering to notify the rider.

...R

Yes, I like this approach. I'm quite excited!