To set up your Timecode Systems devices, including your :pulse, you need to understand how a BLINK network works. In the following sections, we explain the key concepts of BLINK networks and answer some of the most common questions:
- What is a BLINK Network?
- Master and Slaves in the BLINK Network
- What if a Slave Can't Find a Master?
- What if there are Multiple Masters in the Same BLINK Network?.
If you are familiar with BLINK networks and just want to set up your :pulse, see Quick Set Up :pulse in a BLINK Network.
A BLINK network is a group of devices that are all set to use the same RF channel.
Timecode Systems devices synchronise with each other by using radio (RF) to send and receive timecode. Each device has to be set to use a specific RF channel and can only synchronise with other devices also using that RF channel. For example, if you set your :pulse to use RF channel 9, it can communicate and synchronise with other devices that also use RF channel 9. But it can't synchronise with devices that use different RF channels, such as RF channel 3 or RF channel 5.
Each BLINK network should have one device set to run as a master, with all of the other devices running as slaves. The master device will send its timecode to the slave devices, so that all of the devices in the network use the same timecode.
Let's say you are filming an action scene and you are using two video cameras, a sound mixer, and four SyncBac PROs with GoPro HERO4™s attached. You connect a :pulse to each camera and to the sound mixer.
To synchronise, the devices all need to use the same RF channel and one device has to be set to run as a master with the others set to run as slaves. The master sends its timecode to all of the slaves (see :pulse and the BLINK Network). In the image shown, all of the devices in the BLINK network are set to use RF channel 5.
To synchronise, the devices in a BLINK network use a master and slave relationship. This allows the master's timecode data to be applied to all of the devices.
The master-slaves relationship works like this:
- One device is set to run in master mode and all of the other devices are set to run as slaves.
- When a slave is switched on, it announces itself on the network, and the master will detect it (as long as the slave is in range of the master).
- The master device then sends its timecode data to the slave device, and the slave device applies the timecode automatically.
This process is repeated for each slave in the BLINK network, so that all of the slaves and the master are synchronised using the same timecode.
To make sure the timecode data continues to be synchronised, the master and slaves communicate regularly.
Note: You don't have to use your :pulse as part of a BLINK network. You can use it as a stand-alone device if required, by putting it into Free Run/Jam-EXT mode (see Free Running and Jamming).
When you switch a slave device on, it announces itself on the network so that it can be detected by a master device. But it will only be detected by a master device if:
- The slave device is within range of the master device.
- There is a master device in the BLINK network (there should be one master device per BLINK network, but it is possible that the master is off or has been set up incorrectly).
- There is no interference or blockage of the RF signal between the master and slave.
If a slave cannot connect to a master, or loses its connection with its master, it:
- Runs using its own internal clock. If it was previously synchronised with a master, the slave's internal clock will still be closely matched to the master's clock (as they were synchronised).
- Continues to search for a master. If it was previously synchronised with a master, it will only search for that specific master. The slave will not connect to any other masters that come into range.
When the slave detects a master, it connects and synchronises. If the slave was previously connected to the master but lost its connection, the resynchronisation will be smooth, with no sudden jumps in the timecode.
A camera crew are going to film an exciting river rafting scene in Europe. They fit GoPro HERO4™ Silver cameras to the boats, and the HERO4™s are connected to SyncBac PROs. The SyncBac PROs are set to run as slaves.
A technical centre is set up at the position where the climax to the scene will take place. A :pulse is set up in the technical station, with these settings in place:
- RF Country/Area: Europe/UK
- Timecode Mode: Int-Gen TX
- RF Channel: 4
- The timecode is set to the current time
- The FPS is set to 25:00, which is appropriate for the HERO4™ cameras being used on the shoot.
Before filming begins, the SyncBac PROs and :pulse are synchronised at the technical centre (where the SyncBac PROs are in range of the :pulse). The SyncBac PROs and HERO4™ Silvers are then fitted to the boats.
As soon as the SyncBac PROs are out of range, they start to use their own internal clocks and are no longer synchronised with the :pulse. However, as they have extremely accurate clocks and were synchronised with the :pulse at the start, they remain very accurate.
Filming begins and the GoPro HERO4™ Silver cameras record the action as the boats head down the river towards the technical centre.
As the boats come into range of the :pulse, the :pulse connects with the SyncBac PROs and they re-synchronise. Because the SyncBac PROs are so accurate, the resynchronisation is a 'soft sync' - the SyncBac PROs gradually synchronise with the master :pulse frame-by-frame. There is no sudden jump in the timecode.
You should set up your Timecode Systems devices so that there is one master device per BLINK network. This ensures that all of the slave devices synchronise with the same timecode source (the master device's timecode).
When you switch on a slave device, it announces itself on the network so that it can connect to a master. It will connect to the first master that responds. That's why it is important that there is only one master in the network - if there are multiple masters, there is no guarantee that all of the slaves in the network will connect to the same master, and so this can lead to differences in the timecode being used.
When a slave connects to a master, it stores the name of the master device. If it then loses its connection with the master, it will free run using its own internal clock and will keep searching for the master. If another master comes into range, the slave will ignore it - it will only connect to the master device that matches the name stored in the slave. However, if you turn the slave off and then back on again, the slave will connect to the first master that responds.
Let's say you have a BLINK network where all of the devices are set to use RF Channel 4. There is one master, which is a :pulse, which we will call :pulse A for this example. There are also three SyncBac PROs which are set to run as slaves.
The :pulse and SyncBac PROs are all turned off and you add a second :pulse (:pulse B) to the BLINK network. You set :pulse B to run in Int-Gen TX mode (a master mode), which means that when the devices are all turned back on, there are two masters in the BLINK network - :pulse A and :pulse B.
The SyncBac PRO slaves announce themselves on the network so that they can connect to a master. As they have been switched off, they will connect to any master - they are not expecting a master with a specific name. Two of the SyncBac PROs detect the :pulse A master first, and synchronise with it. But the other SyncBac PRO finds :pulse B first, and so synchronises with that instead. As a result, the devices in the BLINK network are not all using the same timecode.
To fix the problem, you turn all of the SyncBac PROs off and set :pulse A to run as a master and :pulse B to run as a slave. You then turn the SyncBac PROs back on and they all synchronise with :pulse A (as it is the only master). When they synchronise, the SyncBac PRO slaves store the name of the master :pulse (:pulse A). During the shoot, the SyncBac PROs are moved out of range of the :pulse A master, and so they lose their connection and switch to free running. The SyncBac PROs then come into range of another master device, but they ignore it - they will only connect to :pulse A. The slaves continue to free run, until they come back into range of :pulse A or are switched off and then back on again (at which point, they forget their connection to :pulse A and will connect to the first master device that responds).