The name literally means to measure at a distance. It is used to describe any system where data is measured at a remote location, and transported by some means to where it is analysed. In the context of Amateur Radio, and FSQ in particular, Telemetry is used to measure the status of important parameters at the remote radio site, such as battery voltage, charger current, shack temperature etc. There are as many potential applications as there are hams to dream them up! Here are some examples:
Unlike other telemetry systems, typically relying on VHF or UHF equipment, FSQ can also be used via HF, so will work well from heavily wooded sites, over hilly terrain, and over long distances. Also, and this is a very important factor, FSQCall requires no infrastructure (mains power, phone, internet, cellular or repeaters) for operation.
- Weather stations
- Remote FSQ Relay stations
- Solar or wind generator sites
- Monitoring equipment at a holiday cottage
The FSQCall program on its own does not generate or process the Telemetry. That is left to add-on programs, with FSQCall acting as an intelligent transport medium. The interaction is at a file level, and is very easy to use.
Unique among mainstream Amateur Radio modes, FSQCall has been set up to transfer telemetry data just as easily as it does chat text, files and images. No other mode has this native capability. FSQCall can work with third-party programs which collect and collate data for transmission. FSQCall operating on a remote computer can make these transmissions automatically, or some stand-alone smart transmitter can collect the data and make the transmissions.
At the receiving end, the incoming telemetry data will be stored automatically in a file chosen by the source device or computer, with subsequent telemetry sentences appended to the same file in chronological order. A third-party application can take this information and process it as required.
In a different scenario, the remote site can store the data for each day, to be downloaded and analysed as convenient.
With FSQCall, any remote station can send data to one or all stations; and can have data stored in a common or a unique file at the station(s). Since each remote device can have a unique ID, which can be sent with the data, even when stored in a common file, the data can still be analysed for an individual source.
The FSQCall Telemetry capability makes use of the standard FSQCall File Put(#) command. For example, if a remote device were to send:allcall#[zl1xyz_2.tlm]1234,002,12.5,21.4the data would be saved by all stations within range, into, or appended to a file named 'zl1xyz_2.tlm". The data in this example is decimal, and might be "frame number, device number, battery voltage, ambient temperature".zl1xyz#[zl1xyz_2.tlm]1234,002,12.5,21.4would result in the data only being stored at ZL1XYZ's home station.
Any station within range could subsequently read the telemetry file from ZL1XYZ, using:zl1xyz+[zl1xyz-2.tlm]but be prepared for the file to be large. Check the file size using the directory list.
There are three main methods available, all with scope for ingenuity: (1) PC hosted, (2) local audio or QRP source, and (3) Stand alone. You can also use these features for 'Smart Sounding', using a third-party program to generate messages.
Because FSQCall has a CSMA protocol which controls access to the radio channel, the telemetry sentence will not be transmitted until the channel is free, and might time out if the channel is busy. Telemetry is best sent on a dedicated radio channel, especially if the working channel is frequently used.
- An intelligent device such as an Arduino board equipped with various sensors and conditioning circuits, measures the real world parameters at the remote site. It pre-processes the data, and generates a telemetry frame which it sends to the PC. In the case of the Arduino, this is via USB, and is received on the PC by a 'helper' program, which checks the data, further processes it, assembles an FSQ sentence in a standard format, and then writes it to a file and saves it. This will be the file 'data.txt' in the Shared folder.
FSQCall, from V0.34 onward, checks for the existence of a file 'data.txt' in the Shared folder. If this exists, FSQCall will immediately transmit the contents, then delete the file. The file will of course be made again periodically by the 'helper' program, with newly received data.
A variation on this is where the remote site PC regularly stores the telemetry frames in a single file, which can be accessed at will by any station. Both of these options are already in operation.
- This is perhaps the most unusual method. A stand-alone intelligent device such as an Arduino or Raspberry Pi would be equipped with various sensors and conditioning circuits, measuring the real world parameters at the remote site. It would periodically process the collected data, generate a telemetry sentence with a pre-defined preamble and the data as payload.
This device would be equipped with a sound card or other audio synthesizer, or an inexpensive function generator such as the AD9833 module, and would generate FSQ audio at 1500 Hz, which is fed into the FSQ receiver path of the PC. It could alternatively operate the synthesizer on the working FSQ radio channel and talk to the software that way. In either case, the device would send the telemetry using a relay command, so the FSQ station makes the transmissions for it.
- A stand-alone intelligent device such as an Arduino or Raspberry Pi would be equipped with various sensors and conditioning circuits, measuring the real world parameters at the remote site. It would periodically process the collected data, generate a telemetry sentence with a pre-defined preamble and the data as payload.
This device would be equipped with a DDS synthesizer, such as an inexpensive AD9850 or AD9833 module, and periodically would tell this synthesizer to go to the working frequency, then modulate it with the sentence in FSQ. A low-powered amplifier would be attached, along with an antenna.
This equipment is currently being planned by several developers. If the antenna used was dual-band or wide-band, the transmitter could switch to day and night frequencies based on measurements from a solar panel, or could repeat the same sentence on two or more bands throughout the day, or could send the sentence to several pre-defined stations.
With Option (3), there would be no receive capability, so these devices would need to operate on a dedicated radio channel with low transmission rates to limit collisions. A TDMA protocol based on device ID and system time could easily be implemented.
FSQCall has been set up in a way that allows third party programs to interact with it, without any particular restrictions or proprietary demands being made on FSQCall. The first of these was FSQPlot, developed by Murray ZL1BPU. This simply reads the Heard Log file, and generates a graph of received station signal quality over time.
In the same way, third party programs can interact with files in the FSQ/Shared folder. Thus a developer can write an application to read, process and display data from a remote telemetry device, or several devices. One could also, for example, develop a simple messaging system based on stored files.
FSQCall (from V0.34) has a special feature, where the program scans the FSQ/Shared folder looking for a specific file, "data.txt". Nothing further is done if the file isn't there. When the file is found, the content is read into the FSQCall transmit buffer and transmitted; the "data.txt" file is then deleted, so the 'helper' program can know that it has been sent.
Several different 'Helper' programs are now in use. One simply generates a Sounding message, giving FSQCall the ability to send more intelligent soundings, perhaps containing weather information and a 'message of the day'. Others collect data, generate telemetry transmissions or analyse telemetry data as described above. These applications (called collectively FST or Fast Simple Telemetry) work with a USB-connected Arduino device, as described in Option (1) above. FST is very versatile, since the time between transmissions, or use of stored files, the target callsign, the target file and even the data formatting options can all be pre-defined and suited to the application.
See the main FSQ page to download the FST software package.
FSQCall can handle anything that contains only text, because it has a limited character set. So you can't send .XLS, .PDF or .DOC documents. Nor would you want to, because of their size. It will happily handle comma separated (.CSV), hypertext markup (.HTM), plain text (.TXT) and even program source code in most cases.
Telemetry data can be sent in decimal, comma separated, as in the above example, which makes it easy to analyse the data with a spreadsheet. However it is a fairly verbose method, making the transmissions fairly long (typically 35 seconds for an eight channel message).
A much more compact method, suited to automated analysis, is to define all the data channels in 8-bit or 12-bit hexadecimal, and transmit them with no separators (packed), for example "023102e0303400403c41231d7". The receiving 'helper' program would easily be able to recover the data.
Because FSQCall has an alphabet which favours lower case letters (these are transmitted twice as fast as numbers, upper case and everything else), it makes sense to send the telemetry this way. A really cunning technique is in use in FST V0.02, where all characters less than ASCII 64 (numbers 0-9) are translated up by 64 (to become letters p-y)!
Essentially the telemetry payload is completely free-form, provided it (a) contains no real callsigns, (b) contains only characters in the FSQCall alphabet, and (c) conforms to what the receiving 'helper' analysis program is expecting. Thus the payload definition can be set locally.
A suggested payload, based on the Arduino device used by ZL1BPU would be:
sssddd000111222333   (Where each channel is in 3-digit hexadecimal lower case, e.g. 0b3)
TTTT|sssddd000111222333tttttt| (Where data is prefaced with a time stamp and marker, and followed by a marker)
TTTT.sssdddpppqqqrrrsssuuuyyy. (Where numbers have been shifted +64 ASCII)
- TTTT Time stamp, PC time from Helper program.
- sss Remote device frame sequence number.
- ddd Remote device unique ID number.
- 000 A-D channel 0 (battery voltage 0 - 16V)
- 111 A-D channel 1 (charger voltage 0 - 16V)
- 222 A-D channel 2 (solar panel voltage 0 - 16V)
- 333 A-D channel 3 (charge current 0 - 5A)
- ttt A-D Temperature channel 4 (Ambient, 0 - 50°C)
- ttt A-D Temperature channel 5 (Equipment, 0 - 50°C)