# ZL2AFP FSQCall

## An Introduction to Telemetry

V0.41, 21.10.2016

### What is Telemetry?

> 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:
> - Weather stations
> - Remote FSQ Relay stations
> - Solar, water or wind generator sites
> - Monitoring equipment at a holiday cottage
> 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.

### FSQ Telemetry

> 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 by design 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.

> 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 (typically 0 to 4095), 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.4

> the 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.4

> would 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.
> Block diagram of FSQCall Telemetry management

> The diagram above illustrates how data is handled by FSQCall when a local third-party program is used to generate the messages as a file which is picked up by FSQCall. The 'helper' collates and processes the raw data, and periodically assembles a file 'data.txt', which contains a properly formatted FSQ file send sentence.

### Sending Telemetry

> There are three main methods available, all with scope for ingenuity: (1) PC hosted, (2) local audio or QRP source, and (3) Stand alone. We will also discuss Intellegent Sounding here (4), as the technique is similar.
> 1. PC Hosted
>    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.

>    This option is already in operation, and is illustrated in the diagram above.

> 2. QRP Remote Audio or Radio
>    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.

> 3. Remote Stand-Alone Device
>    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 on different channels.

>    Block diagram of FSQCall Telemetry using remote stand-alone device

> 4. Intelligent Sounding
>    While not a Telemetry application per se, FSQCall with a 'Helper' program can perform a range of useful Intelligent Sounding applications, such as distributing weather information or results from a sports event. In this scenario (see illustration below) a 'Helper' application collates the data (which might be from an external source or provided in a file), and then periodically saves the file as 'data.txt' in the /Shared folder, for FSQCall to transmit. The simplest application of this type would be to hand-type the FSQ sentence into Notepad, and periodically save it into the Shared folder when a new update is required.

>    If the FSQCall station is network connected, and the /Shared folder has been 'shared' with other network users, operators on other computers can generate files to be saved across the network and transmitted in this way. This is highly convenient in a multi-operator base station for an event.

>    An advantage of Intelligent Sounding is that it can be Directed to a station, or to allcall, and so will appear on their main screen. The message can also be sent as a file to one or more stations if required. For example, for a sports event, the base operator can send updates to all stations that will be stored sequentially to file.

> Illustration of Intelligent Sounding

> Because FSQCall has a CSMA protocol which controls access to the radio channel, the telemetry sentence (Option 1 above) 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.

> 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.

> > Hint:
> > You can suppress the usual 'ack' from the target station to every Telemetry frame by including ' - ' (minus) somewhere in the target file name. For example zl1xyz#[-hilltop.tlm]1234,002,12.5,21.4 will cause the Telemetry to be saved into filename '-hilltop.tlm' at ZL1XYZ, but ZL1XYZ will not acknowledge each frame. You could also use the file name 'hill-top.tlm', and the result would be the same. This only applies if the target station is running FSQCall V0.36 or later.

### Helper Programs

> 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 applications 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. This feature is illustrated in the first illustration on this page.

> So far, two different 'Helper' programs have been tested. 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'. The other collects telemetry data as described above, and generates a telemetry sentence. This application (called FST or Fast Simple Telemetry) works with a USB-connected Arduino device, as described in Option (1) above. It is very versatile, since the time between transmissions, the target callsign, the target file and even the data formatting options can all be pre-defined.

### Time Stamps

> In most applications, any necessary time stamp will be added by the originating souce, or at the transmitting 'Helper' application, as suggested in the next section. However, FSQCall can optionally store a locally generated time stamp to the beginning of any incoming telemetry message. This function is available from the Options menu.

> When this option is turned on, each file store message received with a ' - ' character in the file name (e.g. zl1eyz#[-hilltop.tlm]data,data,data) will have a time stamp and SNR applied to the front of each line stored to the file. The time stamp format is 'HH:MM SS' where SS is the Signal to Noise Ratio of the remote station when the message was received. Time is local computer time at the FSQCall computer. Unless monitoring for telemetry, leave this option off, although it has no effect unless there is a ' - ' in the received file name.

### Data Format

> 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 offered by 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:

> > Arduino Sentence
> > sssddd000111222333 (Where each channel is in 3-digit hexadecimal lower case, e.g. 0b3)

> > Transmitted Payload
> > TTTT|sssddd000111222333tttttt| (Where data is prefaced with a time stamp and marker, and followed by a marker)

> > Fast Payload
> > TTTT.sssdddpppqqqrrrsssuuuyyy. (Where numbers have been shifted +64 ASCII)

> > Legend:
> >   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)

Copyright © Murray Greenman and Con Wassilieff 2013-2016. All rights reserved.