User Manual v1.0 AirGlu™ module Wireless Sync and Control Key Features The AirGlu™ module highlighted features are listed below: • Configurable Sync and Control module for sync and control of professional cameras, recorders and audio devices • Built in Timecode Generator, with 0.5ppm VC TCXO • Timecode Input and Timecode output modes • Master or Slave operation modes • Genlock and Word Clock sync outputs • Sync and Control wireless using sub‐GHz protocol, transmit and receive. Internal Antenna.
System Overview Introduction The AirGlu™ module is an energy friendly, compact solution for providing wireless sync and control capabilities to a professional camera, recorder or audio device. It combines integrated MCU, FPGA and Sub GHz and 2.4GHz radio transceivers. A highly accurate 0.5ppm TCXO provides stable timecode and sync outputs. It can communicate via Sub GHz radio to other AirGlu™ modules or to 3rd party applications using the 2.4GHz Bluetooth LE radio.
System Overview Module Connections AirGlu module PIN Interface I/O Function 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 EXT SCK GND EXT MOSI MCU RESET EXT GPIO NC EXT MISO NC GND GENLOCK OUT 2V0 IN GND 3V3 IN EXT V SYNC EXT H SYNC GND UK Timecode Systems Ltd. Unit 6, Elgar Business Centre, Moseley Road, Hallow, Worcester. WR26NJ.
System Overview Serial UART API – S1C Commands API V5.4 Getting/Changing Configuration Settings of S1C enable devices All commands are formed normally using text-based strings and communicated to the device by one of the following methods. A bi-directional serial link. The link will currently be based around a logic level serial port with or without CTS/RTS handshake with a default baud rate of 57600.
Binary Commands Commands or queries requiring binary data are identified with different assignment characters as follows. ‘>’ Binary set (same as text command’s ‘=’) ‘<’ Binary get (same as text command’s ‘?’) Following the assignment character is a single length byte which denotes the length of the following binary data. If there is no binary data to follow then this length byte should be zero. The length byte should then be followed by the first byte of the binary data.
Timecode Source TCSC? Returns the current timecode source as a string TCSC=n where n is an ASCII ‘0’ through ‘2’ where; 0 = Internal (free run) 1 = External RF 2 = External RF (Cont) Free run between sync packets. 3 = External LTC 4 = External LTC (Cont) Free run if signal removed TCSC=n Sets the timecode source to the value n as in the list below.
TCRN=n Sets the Timecode to run (n=1) or freeze (n=0). Frame Rate * TCFR? Returns the current frame rate (Frames per Second) and whether using Drop-Frame encoding of the timecode data. Returns TCFR=n,d where n is the FPS value*1001 and d is a flag of whether using drop-frame encoding or not; 24000,0 = 23.98 fps (Non Drop-Frame) 24024,0 = 24 fps 25025,0 = 25 fps 30000,0 = 29.97 fps 30000,1 = 29.
GLSD=n Sets the current TV Sync method to the value n as in the list above. If the sync standard is not supported for the current frame rate the reply may not be the same as the request. The reply must be decoded and displayed as certain TV sync methods cannot be used with certain frame rates. Genlock or Sync Level GLOP? Returns the current TV sync level GLOP=n where n is an ascii character ‘0’ or ‘1’ where; 0 = Normal (75 Ohm) 1 = High (2 x 75 Ohm = 37.
Note: The transmitter will be automatically turned off if the Timecode Source is switched to External RF mode. It will not be automatically re-enabled when switched back. Device Type Name STTN? Returns the current unit’s device type as a text string such as “SystemOne OEM”. Device Definable Name STNM? Returns the current unit’s text name string. This string is user definable and is used to represent a ‘friendly’ name for the unit i.e. “Camera 1”. STNM= Sets the text name of the unit.
Individual Device – Static Data STSS? (For use with individual device – Use BLSS=n if through BLink master) The current status will be returned as an ASCII string with each status comma delimited on each line. The status’ to be returned will be:1. Unit Type 2. Unit Device Type Name 3. Firmware Revision * 100 4. FPGA Revision * 100 5. Ext Revision * 100 6. S1C Revision 7.
Bluetooth Low Energy (BLE) Commands BTPR= Set BLE into pairing mode Return values; BTPR=0 Stop any pairing sequence BTPR=1 Initiate pairing sequence – look for devices wishing to pair with us BTPR=2 Connect to device BTPR? Obtain current pairing information Return Values BTPR=0 Pairing sequence is idle BTPR=1 Searching BTPR=2, is waiting to pair BTST? Obtain current status of BLE devices This request returns the number of available connection slots followed by a list of currently connected
Device Control and Status – Generic Commands GCMD? This command is a method of getting connected device. As well as returning the device ‘Family’ type it also returns the model number. As BLST only returns the ‘Family Type’ this function returns both this and the model connected as a string. The query returns a CSV string where the first value is the Family Type of the connected device followed by a string denoting the devices model number. If only one value is returned, i.e.
2 = Mbytes Attached Device Status and Control These new commands form a combination of the old individual commands but split into just two functions, one to get static data that rarely changes, and one to get data that can change or be set. GCXS? Get attached device’s static data. Returns a series of fields that define the attached device and its capabilities. The fields are returned comma delimited. 1. Manufacturer’s name - ASCII text value 2. Manufacturer’s model - ASCII text value 3.
BLink networks BLink is a method of connecting client/slave devices to a master controlling device via the TCS proprietary long-range RF link. The master device MUST be the device that the clients are connected to for RF Timecode synchronisation. All S1C commands are initially sent to the master device and then relayed to the BLink client via the RF link. Responses from the BLink client are then replied back through the RF link to the master and then back to the command originator.
S1C is designed to address either the ‘Master’ device or any of the devices listening to the ‘Master’ device. The master device will be the device that all S1C communications are directed for access to the BLink network. S1C may also be used directly with devices that are currently a client within another master device’s BLink network, in this instance access to the BLink network is not possible. This would be used locally to ask for current information of that particular device, such as Timecode etc.
All the following commands should be directed to the master device only BLST? (Deprecated – use BLSS/BLSP) Returns the number of known BLink devices on the network and a number or sequence of numbers that represent a bitmap of which slave devices are active. A reply of BLST=5, 91 means there are currently 5 devices online, and if the 91 (decimal) if converted to a binary value i.e.
The statuses are only updated around twice per second maximum. So this command should only be used infrequently. Initial Connect – Static Data BLSS? Returns a bitmap of known BLink devices on the network. The bitmap is broken down into 32-bit hexadecimal values that represent a bitmap of which slave devices are active. If say there is the reply BLST=0000005B if now the reply is broken into binary, each bit represents a device present or not (1 or 0). Thus, the hex value of 0000005B breaks down to binary 0..
Slave Poll BLSP? Same as ‘BLSS?’ command – see above. BLSP=n Retrieve status information from a BLink network device. Where n denotes the index into the table of stored devices. For instance; BLSP=1 will reply with the details of the first device in the table, and BLSP=2 will reply with the details of the second device in the table, and so on. The statuses will be returned as an ASCII string with each status comma delimited on each line. The status’ to be returned will be:1. Blink ID 2.
Slave’s Attached Device Status These commands should be used to get information regarding a device attached to a slave unit, directly from the master device. There is one query to get static data that rarely changes, and one to get data that can frequently change. BLXS=n Get the slave device’s static data where n = slave’s BLink ID. Returns a series of CSV fields that define the attached device and its capabilities. The fields are returned comma delimited. 1. Blink ID 2.
Updating Firmware UFCK>length(=0x0A)+First ten bytes of update file+‘\n’ Binary command with an ASCII response to check the version of an update file. The update type and version are held within the first ten bytes of the update file so these need to be included in the query.
UFGO=checksum This command initiates the update process once all the data has been transferred where checksum is a 2’s compliment 16 bit checksum of the entire file and presented in decimal. See UFDA command for method of calculation. Responses are as follows UFGO=0 Only for main firmware update. Flag to specify that all was fine and now proceeding with update. The communications will be lost for a short time and when complete a UFGO=1 will be sent; UFGO=1 Update has been completed.
Appendix TCS Device Capabilities Flags as used in BLSS=n and STSS? requests Bit Capability 0 Has LTC Output function 1 Has LTC Input function 2 Has Genlock Output function 3 Has Word-Clock Output function 4 Has Wi-Fi capability 5 Has BLE capability 6 Has Serial port 7-11 Currently unallocated with zero default 12 Has a built-in display and can control brightness 13 Has button control 14 Has internal rechargeable battery 15-19 Currently unallocated with 0 default 20-23 Currently unallocated with 1 default 24
Certifications CE The AirGlu™ module is in conformity with the essential requirements and other relevant requirements of the Radio Equipment Directive (RED) (2014/53/EU). Please note that every application using the AirGlu™ module will need to perform the radio EMC tests on the end product according to EN 301 489‐17. The conduced test results can be inherited from the modules test report to the test report of the end product using AirGlu™ module.
FCC This device complies with Part 15 of the FCC Rules. Operation is subject to the following two conditions: • This device may not cause harmful interference, and • This device must accept any interference received, including interference that may cause undesirable operation. Any changes or modifications not expressly approved by Timecode Systems could void the user’s authority to operate the equipment.
ISED Canada ISED Canada (English) This radio transmitter has been approved by Industry Canada to operate with its embedded antenna. Other antenna types are strictly prohibited for use with this device. This device complies with Industry Canada’s license‐exempt RSS standards. Operation is subject to the following two conditions: 1. This device may not cause interference; and 2. This device must accept any interference, including interference that may cause undesired operation of the device.
ISED Canada (Français) Cet émetteur radio (IC : 10427A‐AGLU01) a reçu l'approbation d'Industrie Canada pour une exploitation avec l'antenne puce incorporée. Il est strictement interdit d'utiliser d'autres types d'antenne avec cet appareil. Le présent appareil est conforme aux CNR d’Industrie Canada applicables aux appareils radio exempts de licence. L’exploitation est autorisée aux deux conditions suivantes: 1. L’appareil ne doit pas produire de brouillage; et 2.
JAPAN The AirGlu™ module is certified in Japan with certification number xxx‐yyyyyy Important The module does is not labeled with Japan certification mark and ID because of the small physical size. Manufacturer who integrates a radio module in their host equipment must place the certification mark and certification number on the outside of the host equipment. The certification mark and certification number must be placed close to the text in the Japanese language which is provided below.
