From: paul.willmott@omsl.bm
To: amsat-bb@amsat.org
Subject: AO-40 Telemetry Notes - For Users & Writers of Telem Decode/Capture Software
Date: Tue, 9 Jan 2001 13:28:41 -0400

Hi All,

GENERAL CAPTURE NOTES
---------------------

The Command Stations have started to use the Whole Orbit Data (WOD)
sub-system. This means that the message blocks (K, L etc), are being used to
transmit data. If you have your telemetry capture software configured to
only capture "A" blocks then you will not collect the WOD data.

Recently command stations have also been requesting "raw" data, instead of
just CRCC OK (tlm) data. This is because some bad data is better than no
data.

Putting all the above together, ... for those of you who are capturing
telemetry, the best settings for P3T logging are:

1). 514 byte modem (if you have one)
2). Ignore CRCC
3). All Blocks

If everyone can use the above settings with P3T then the Command Stations
will have the best chance at getting the data they require.

If you capture ANY telemetry from AO-40 with P3T or compatible software,
then please .zip the files and send to ao40-archive@amsat.org for sorting
and merging. Please send your .raw files (all block types) un-filtered and
un-sorted.

It would help me if you could rename your files prior to zipping to include
your callsign in the filename, e.g. T010101@VP9MU.RAW ... I get a lot of
files with the same filename!

ARCHIVE NOTES
-------------

If you want to see the data we have collected to date, please see the
archive at:

http://www.amsat.org/amsat/ftp/telemetry/ao40/

The archive files are stored as 1 .zip per orbit, the filename shows the
start date (UTC) of the telemetry and the orbit number.

The .zip files contain several files, 1 file per block type. The filename is
the block type and the orbit number. These files are fully compatible with
P3T replay, ... just unzip into the P3T Telemetry directory to view them. 

DEVELOPER NOTES
---------------

If you are writing telemetry capture and/or decoding software then please
ensure that any logging to file function is implemented as below. This is
the format that the Command Stations and the AMSAT Archive require. Log
files stored in any other format cannot be processed, and hence valuable
data cannot be accessed. Files saved in the format below can be viewed using
P3T's Replay.

1). Filenames: TYYMMDD.RAW or TYYMMDD.TLM

T <- Indicates Telemetry File of all block types

YYMMDD <- Date of start of telem capture (Local Time).

.RAW <- for files that include all blocks captured, CRCC OK, CRCC BAD, or
CRCC Unknown, or combination thereof. Don't split capture into separate CRCC
OK and CRCC bad files, ... .RAW files should contain everything captured
good, or bad, in the correct sequence. Only store complete blocks of 512
bytes, discard incomplete blocks.

.TLM <- for files that include only blocks that are CRCC OK

Note: Only 1 file should be created per local day, ... your software should
append data to the end of an existing log file for the same local date. This
allows the users to stop and start the software without having to rename
files to avoid overwrites.

2). Files should contain the blocks in the order of capture, no filtering or
sorting is recommended. Files should contain all block types, ... some
blocks do not contain any time stamp, ... therefore adjacent A blocks are
required to determine when a block was sent, ... and in the case of the
archive, where a block should be stored.

3). Each block is stored as 512 bytes, the checksum is not stored. No
End-Of-Record or CRLF characters are placed between the blocks. 512 512 512
...

4). The AO-40 CRCC Calculation can be found here:

http://www.amsat.org/amsat/ftp/satinfo/ao13/spec_crc.doc

5). If the block was captured on a 512 byte decoder then the CRCC cannot be
tested, in which case the block should be saved in the log file with bit 7
(MSB) of bytes 0 and 1 set to 1. Setting bit 7 of a byte is IPS for inverse
video. With P3T replay if you see the first 2 two bytes of a block in
inverse video then you don't know if the CRCC is good or bad, and hence the
data may be good or maybe bad.

6). If the block was captured on a 514 byte decoder and the CRCC tests OK,
then the block is saved in the log file unchanged. If the block fails the
CRCC test then it is saved in the log file with bit 7 (MSB) of byte 0 only
set to 1. With P3T replay if you see the first byte of a block in inverse
video then you know that the CRCC is bad.

If there are any questions about the above, then please drop me a note at:

ao40-archive@amsat.org

73
Paul Willmott, VP9MU
AMSAT AO-40 Telemetry Archive