1. Manufacturer’s name – ASCII text value
2. Manufacturer’s model – ASCII text value
3. Capability Flags – 32bit hexadecimal number – See appendix
4. Storage unit #1 Name (ASCII string)
5. Storage unit #1 Capacity (integer value)
6. Storage unit #1 Units 0 = Empty/Unknown,1 = MB, 2 = GB, 3=TB
7. Storage unit #2 Name
8. Storage unit #2 Capacity
9. Storage unit #2 Units
10. Storage unit #3 … etc.

GCXP?……. Get the attached device’s changing data
Returns a series of fields denoting the attached device’s current status The fields are comma-delimited.

1. Current transport status – See appendix
2. Current frame rate numerator
3. Current frame rate denominator
4. Rate Flags (8bit Hex) – Bit 0 = Drop Frame, others unused
5. Current battery level percentage
6. External power applied/battery charging flag
7. Current clip/filename
8. Storage unit currently selected or in use
9. Storage unit #1 media remaining time in minutes
10. Storage unit #1 media remaining size
11. Storage unit #2 media remaining time in minutes
12. Storage unit #2 media remaining size
13. Storage unit #3… etc.

GCXP=…… Used to set the attached device’s transport status or frame rate.
This command can only change the transport control state or the frame rate. The command need only supply the first field if just controlling the transport state or optionally two fields if also controlling the frame rate.

1. Current transport status – See appendix
2. Current frame/bit rate Numerator (optional)
3. Current frame/bit rate Denominator (optional)

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 synchronization.
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.
Generally, all commands/requests are replied to but it must be noted some replies may take over a second to be returned. If no reply is heard within, say 2 seconds, the original request should be re-sent.
The master device continually polls the BLink network both obtaining basic status information which is stored in a local table for fast responses to requests
The BLink master also looks for new devices being connected to the network. New devices are auto allocated a new BLink ID which corresponds to a table entry of status information. New clients will generally be allocated an empty table position but if these get used up then entries from clients ‘not heard from’ will be re-used. This table may change as BLink devices come and go from the network.

• New devices may re-use table entries of devices that have disappeared.
• Table entries may exist of devices that have not been heard from for a long time.
• Returning devices may be allocated a new BLink network ID and therefore a different position in the table, therefore reference to Unique ID must be maintained.

The BLink system can be configured for in excess of 1000 clients but is currently restricted to around 50 clients depending upon the TCS device used as BLink master. It must be considered that more BLink clients do reduce the speed of the network.
Command use with BLink network
Example addressing of individual unit within BLink network
“#@1; GLSD?\n”………. Requests Sync standard of Blink device 1
“#@42; GLSD=0\n”…… Sets Sync standard of Blink device 42 to off.
Note; “#@0; GLSD?\n”…… Requests the Sync standard of the Blink Master and will result in the same as “#GLSD?\n”
Broadcast commands to all units will be for a restricted set of commands/settings only (not requests) and will be addressed using the “#@;” prefix i.e. device number missing. Broadcast messages are NOT responded to by the clients and there is no way of knowing without checking that a command has been heard or actioned.
There are also Group addressing commands that can address groups of units that are assigned to a particular group. There are 6 groups named ‘A’ through to ‘F’ and should be addressed as #@A; for instance, to address group ‘A’ devices.
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 instant 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.
BLID?…… Retrieves the current BLink ID for the device. The BLink ID is determined by the BLink master and cannot be set otherwise.
BLGR?…… Returns the BLink group to the slave belongs. Slave devices can be addressed individually or within groups. There are six groups so the reply will be an ‘A’ through ‘F’ depending on the current group or will return ‘0’ (zero) if the slave does not belong to any group.
BLGR= Sets the slave unit to belong to a particular group of slaves. Values should be an ASCII ‘A’ through to ‘F’ or a ‘0’ if to remove the slave from all groups.
Sending user-defined data to BLink slave devices
DASP=
Send a user-defined to the serial port on the slave devices.
The command should be used along with the formatting required to address slave units individually or globally. i.e.
“#@7; DASP=Hello\n”….. Will send “DASP=Hello” to slave ID #7
“#@; DASP=” To All\n”…… Will send “DASP=To All” to every slave
This command will also work with binary data such as

@3;DASP>Length+Data\n Will send Length+Data to slave ID #3

The overall length of the command should be kept as short as reasonably possible and must not exceed 112 bytes.
Sending user-defined data from slave devices back to the master.
DAMP=
Send a user-defined to the serial port on the master device.
i.e. “DAMP=Hello\n”
Will arrive at the master as “#@n; DAMP=Hello” – where n = slave ID
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) is converted to a binary value i.e. 1011011 will give a bitmap representation of active devices where bit 0 represents device 1, bit 1 represents device 2, and so on. In this instance devices 1, 2, 4, 5, & 7 are all active. Each bitmap number represents 8 devices so a third number in the reply represents the bitmap of devices 9 through to 16 and so on. This request should then be followed with individual requests for a particular device’s current status.
BLST Command must be used directly on the connected master device.
Addressing a slave device such as #@3:BLST? will return nothing.
BLST=n….. Retrieve basic status information from a BLink network device. Where n is the index into the table of stored devices.
For instance; BLST=1 will reply with the details of the first device in the table, and BLST=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. ID (Table Index)
2. Unique ID (hex form of 32-bit number i.e. 8 characters)
3. Unit Type
4. Last Reply (how long since the last reply from client [x10mS])
5. Replied Timecode “HHMMSSFF”
6. Replied UserBits “UUUUUUUU”
7. Sync Mode (0=INT, 1=Ext RF.. see TCSC command)
8. FPS (0=25,1=23.98,2=24,,,etc)
9. Ext Sync Std (0=Off, 1=PAL… see GLSD command)
10. Locked to Timecode Source (0 or 1)
11. Battery (1-5)
12. On PSU (0 or 1)
13. UserBits Lock (1=User Settable 0=Locked to RF Master)
14. Attached Device Type – See GCMD command
15. Current Assigned Group Number – 0 if none
16. Attached are Device Flags. The value should be broken into binary bits

A typical return from this request will be:-
BLST=1,12ABCD78,6,121,00043410,00000000,1,1,0,1,3,0,0,2,0,3
We may wish to expand this list in the future so currently ignore any subsequent statuses.
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. I 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…0001011011 and shows there are 5 bits set, thus there are currently 5 devices online, also the bits that are set give a representation of active devices where bit 0 represents device 1, bit 1 represents device 2, and so on. In this instance devices 1, 2, 4, 5, & 7 are all active. Each bitmap number represents 32 devices so additional values in the reply represent the bitmap of devices 33 through to 64 and so on.
The BLSS Command must be used directly on the connected master device.
Addressing a slave device such as #@3:BLSS? will return nothing.
BLSS=n…… Returns the slave device’s static data, where n is the index into the table of stored devices.
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. Unique ID (32bit Hexadecimal)
3. Unit Type
4. Unit Device Type Name
5. Firmware Revision * 100
6. FPGA Revision * 100
7. Ext Revision * 100
8. S1C Revision
9. Device Capability Flags (See appendix)

The device capability flags will let the Hub know what functions can be used with the device, such as if a display is fitted, has Wifi capability, or external Sync port etc. It is
proposed to use a 32bit hexadecimal number.
A typical return from this request will be:-
BLSS=1,12ABCD78,11,UltraSyncBLU,201,106,0,5, E0F07040
There could be confusion when parsing the returned values from the above two requests as they both return “BLSS=”. To differentiate between the two the length of the first field will determine which request the reply was from. If the first field has a length of 8 characters is can be determined that the reply is for the “BLSS?” query, otherwise, it is a reply to the “BLSS=n” query.
Slave Poll
BLSP?……. Same as ‘BLSS?’ command – see above.
BLSP=n……. Retrieve status information from a BLink network device.
Where n denotes the index in 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. Current Assigned Group Number – ‘0’/’A’ – ‘F’
3. Last Reply (time since last reply x10mS). Zero if unheard.
4. Current UserBits “UUUUUUUU”
5. Data changed flags (8bit hex) – see below
6. Ext Sync Std (0=Off, 1=PAL… see GLSD command)
7. Battery Percentage
8. On PSU (0 or 1)
9. RF Signal Strength (0 to 99)
10. Friendly name

Field 5 – Data changed flags – Bit definitions;
0 Main Static data Changed – use BLSS? to get changes
1 Main Polling data Changed – use BLSP? to get changes
2 Attached device static data changed – use BLXS?
3 Attached device polling data changed – use BLXP?
4-7 Undefined
The changed flags are automatically reset after this query.
A typical return from this request will be:-
BLSP=1,B,65,CAFEF00D,05,40,0,65,UltraSync 1
Devices with changed information
BLCH? Similar to the ‘BLCG’ command but only flags changes once the master device has updated its records with the changes.
The map returned is the same as the ‘BLSS?’ command above i.e. hexadecimal not decimal.
BLCH=0……. Reset BLCH bits.
BLCG?…….. (Deprecated – use BLCH)
Returns the number of BLink network slave devices that have changed details plus a bitmap of the affected devices.
BLCG=0……. Reset BLCG bits.
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. Manufacturer’s name – ASCII text value
3. Manufacturer’s model – ASCII text value
4. Capability Flags – 32bit hexadecimal number – See appendix
5. Storage unit #1 Name (ASCII string)
6. Storage unit #1 Capacity (integer value 0 – 65535)
7. Storage unit #1 Units 0 = Empty/Unknown,1 = KB, 2 = MB, 3 =GB
8. Storage unit #2 Name
9. Storage unit #2 Capacity
10. Storage unit #2 Units
11. Storage unit #3 … etc.

BLXP=n…….. Get the slave device’s changing data where n = slave’s BLink ID.
Returns a series of CSV fields denoting the attached device’s current status The fields are comma-delimited.

1. Blink ID
2. Current transport status – See appendix
3. Current frame rate numerator
4. Current frame rate denominator
5. Rate Flags (8bit Hex) – Bit 0 = Drop Frame, others unused
6. Current battery level percentage
7. External power applied/battery charging flag
8. Current clip/filename
9. Storage unit currently selected or in use
10. Storage unit #1 media remaining time in minutes
11. Storage unit #1 media remaining size
12. Storage unit #2 media remaining time in minutes
13. Storage unit #2 media remaining size
14. Storage unit #3… etc.

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.
The response will be UFCK=type, version, flag
type – 0=unknown, 1=main FW, 2=FPGA, 3=Ext
version = update version * 100
flag – 0=Can’t use, 1=Ok to proceed, 2=same version, 3=older version than current
UFST=n
Initiate a firmware update where n = overall size of ‘update file’ to be transferred.
The response will give the maximum size of updated data that can be transferred in each ‘UFDA’ block. i.e. UFST=106. Currently, this is limited to a 106-byte maximum but, in the future and if transferred locally using say the serial interface, this may be increased.
This command may take up to 3 seconds to complete depending on the size of the update.
Please use this command sparingly as each call forces an erase of the internal Flash memory update buffer.
UFDA>length + address + data-block + checksum + ‘\n’
This is a binary command where blocks of data are sent sequentially starting at address zero and progressing through until all the file is transferred. The data is sent in binary format, where;

• length is a single byte length of the entire message to follow (not including the final ‘\n’). Therefore, it is the length of the data block plus five (address and checksum bytes). Currently, the length value should not exceed 111(0x6f). With the final ‘\n’ character this is the current maximum total of 112bytes of data following the length byte.
• the address is a three-byte, little-endian, relative address of the data block from the start of the file.
• data-block is the block of data from the file
• the checksum is a 2’s compliment 16bit modular checksum of each of the address and data-block bytes. This is computed by successive addition of each of the (8-bit) bytes starting with the address bytes and ending with the final data byte and discarding any overflow beyond 16 bits. The resultant 16bit word is then two’s complimented and appended, little-endian, to the end as the last two bytes of the message.

The responses are as follows
UFDA=0 All fine – ready for next block
UFDA=1 All fine – Transfer complete
UFDA=2 Checksum error – Please Repeat the message
UFDA=3 Address out of sequence
UFDA=4 Length error – or UFST has not been issued
UFGO=checksum
This command initiates the update process once all the data has been transferred where the checksum is a 2’s complement 16-bit checksum of the entire file and presented in decimal. See the UFDA command for a method of calculation.
Responses are as follows
UFGO=0…… Only for the main firmware update. Flag to specify that all was fine and now proceeding with the 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. There may be many seconds delay before this is issued.
UFGO=2…… Data is not yet complete
UFGO=3….. Checksum does match stored data
UFGO=4….. Old or same updated version
UFGO=-n …….Negative return values during updates represent update failure.
Each type of update should be done separately i.e. Main Code, FPGA, and BLE updates, we always need to update the main code first. We will be providing updates as three separate files where one or more may be needed to be updated at any one time. The AirGlu can determine what each update is for from the contents, you do not have to retain the filenames.

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 the 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….. Can do zero brightness display setting
25….. Can do zero brightness LED flash
26….. Can do BLink master
27-28…. Currently unallocated with 0 default
29-31….. Currently unallocated with 1 default
External Device Capability Flags as used in BLXS=n and GCXS? Requests
Bit….. Capability
0/1….. Number of fitted Media Storage units
2…….. Transport state can be controlled
3……. Can be controlled On or Off
4…….. Predominantly Video devices using FPS (=0) or Audio Bitrate device (=1)
5-9…… Currently unallocated default =0
10-15…. Unallocated default =1
16-23….. Unallocated default =0
24-31…… Unallocated default =1

Integration Instructions

2.2 List of applicable FCC / ISED rules

2.3 Specific operational use conditions
Not applicable
2.4 Limited module procedures
Not applicable
2.5 Trace antenna designs
Not applicable
2.6 RF exposure considerations
To comply with FCC RF exposure requirements, the OEM must ensure that only antennas are installed which are listed with this module antenna details. The AirGlu2 module should be used in such a manner that the potential for human contact during normal operation is minimized.
OEM integrators and end-users must be provided with transmitter operating conditions for satisfying RF exposure compliance.
Radiofrequency radiation exposure Information: This equipment complies with FCC radiation exposure limits prescribed for an uncontrolled environment for fixed use conditions. This transmitter must not be co-located or operating in conjunction with any other antenna or transmitter except in accordance with FCC procedures and as authorized in the module certification filing. Changes or modifications not expressly approved by the party responsible for compliance could void the user’s authority to operate the equipment.
2.7 Antennas
The external antenna approved for use is the Taoglas TG.09.0113 SMA (F) monopole. The maximum Gain (free space) allowed is 2.0 dBi (900MHz) and -6dBi (2.4GHz). No other antenna type or higher gain of antenna design should be used. The unique antenna connection used on the AirGlu2 module is the ECT (Electric Connector Technology Co Ltd) part no. 818000157.
2.8 Label and compliance information
The host product manufacturer is responsible to provide physical or re- labeling stating ‘Contains FCC ID: AYV-AGLU02 or Contains IC: 10427A-AGLU02’ with the finished product. See Guidelines for Labeling and User Information for RF Devices – KDB Publication 784748.
2.9 Information on test modes and additional testing requirements
The AirGlu2 module comes complete with a Test Mode API within the core operation firmware, to configure all required test modes as a standalone transmitter in a host
2.10 Additional testing, Part 15 Subpart B disclaimer
The AirGlu2 modular transmitter is only FCC authorized for the specific rule parts (i.e., FCC transmitter rules) listed on the grant, and the host product manufacturer is responsible for compliance with any other FCC rules that apply to the host not covered by the modular transmitter grant of certification. The final host product requires Part 15 Subpart B compliance testing once the modular transmitter is installed.

Certifications

CE
The AirGlu2™ 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 AirGlu2™ module will need to perform the radio EMC tests on the end product according to EN 301 489-17. The conducted test results can be inherited from the module’s test report to the test report of the end product using the AirGlu2™ module. EN 300 328 radiated spurious emission test must be repeated with the end-product assembly. Test documentation and software for the EN 300 328 radiated spurious emissions testing can be requested from the Timecode Systems support.
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.
FCC RF Radiation Exposure Statement:
This equipment complies with FCC radiation exposure limits set forth for an uncontrolled environment. End-users must follow the specific operating instructions for satisfying RF exposure compliance. This transmitter must not be co-located or operating in conjunction with any other antenna or transmitter except in accordance with FCC multi-transmitter product procedures. OEM Responsibilities to comply with FCC Regulations: The transmitter module must not be co-located or operating in conjunction with any other antenna or transmitter except in accordance with FCC multi-transmitter product procedures. Each new host will require a reassessment of radiated spurious emissions and
a permissive change to the certification. For the AirGlu2™ module, the minimum separation distance to the human body is 20cm. OEM integrator is responsible for testing their end-product for any additional compliance requirements required with this module installed  (for example, digital device emissions, PC peripheral requirements, etc.). Important Note: In the event that this condition cannot be met (for certain configurations or co-location with another transmitter), then the FCC authorization is no longer considered valid and the FCC ID cannot be used on the final product. In these circumstances, the OEM integrator will be responsible for re-evaluating the end product (including the transmitter) and obtaining a separate FCC authorization.
End Product Labeling
The AirGlu™ module is not labeled with its own FCC ID due to its physical size. If the FCC ID is not visible when the module is installed inside another device, then the outside of the device into which the module is installed must also display a label referring to the enclosed module. In that case, the final end product must be labeled in a visible area with the following:
“Contains Transmitter Module FCC ID: AYV-AGLU02”
Or
“Contains FCC ID: AYV-AGLU02”
The OEM integrator must not provide information to the end-user regarding how to install or remove this RF module or change RF-related parameters in the user manual of the end product.
ISED Canada
This radio transmitter has been approved by Industry Canada to operate with its embedded antenna. Other antenna types are strictly prohibited from 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.

RF Exposure Statement
AirGlu2™ module meets the given requirements when the minimum separation distance to the human body is more than 20cm. RF exposure or SAR evaluation is not required when the separation distance is 20cm or more. AirGlu2™ module has been tested for worst-case RF exposure.
OEM Responsibilities to comply with IC Regulations
The transmitter module must not be co-located or operating in conjunction with any other antenna or transmitter. Radiated emission must be tested with each new host product and ISEDC must be notified with a Class 4 Permissive Change. OEM integrator is responsible for testing their end-product for any additional compliance requirements required with this module installed (for example, digital device emissions, PC peripheral requirements, etc.).
Important note
In the event that these conditions cannot be met (for certain configurations or co-location with another transmitter), then the IC authorization is no longer considered valid and the IC ID cannot be used on the final product. In these circumstances, the OEM integrator will be responsible for re-evaluating the end product (including the transmitter) and obtaining a separate IC authorization.
End Product Labelling
The AirGlu™ module is not labeled with IC ID because of its small physical size. The final end product must be labeled in a visible area with the following:
“Contains Transmitter Module IC: 10427A-AGLU02”
Or
“Contains IC: 10427A-AGLU02”
The OEM integrator has to be aware not to provide information to the end-user regarding how to install or remove this RF module or change RF-related parameters in the user manual of the end product.
JAPAN
The AirGlu2™ module is certified in Japan with certification number 008-220415
Important
The module does is not labeled with a Japan certification mark and ID because of the small physical size. A 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.
Translation:
“This equipment contains specified radio equipment that has been certified to the Technical Regulation Conformity Certification under the Radio Law.”

UK Timecode Systems Ltd.
Unit 6, Elgar Business Centre,
Moseley Road,
Hallow, Worcester.
WR26NJ. UK
(dated 26/05/2022)

Documents / Resources

| Timecode Systems AirGlu2 Wireless Sync and Control Module [pdf] User Manual
AGLU02, AYV-AGLU02, AYVAGLU02, AirGlu2, Wireless Sync and Control Module, AirGlu2 Wireless Sync and Control Module
---|---

Read User Manual Online (PDF format)

Download This Manual (PDF format)

Download this manual  >>