[Isocops] APL tlm frame description

[Geoffrey B. Crew]

Hi Tim,

Sorry about the bad phone connection yesterday.

My reconstruction of the APL header accounted for the 64 bytes as
follows (apl_desc.h in the ISOC ibex s/w tree):

/*
 * Code 2 time format, I think...
 */
typedef struct apl_header {
    unsigned int    magic;          /* 0x499602D2 = 1234567890 */
    unsigned int    count;          /* frame bytes */
    unsigned int    zero;
    unsigned int    secs;           /* Cortex Code 3 format: time in year */
    union {
        unsigned int    usec;       /* Cortex Code 3 format: time in year */
        float           frac;
    } u;
    unsigned int    seqn;
    unsigned int    frame_check;    /* note 2 */
    unsigned int    frame_sync;     /* 0: off, 1: on/Lock, 2: on,flywheel */
    unsigned int    bit_slip;       /* 0: no, 1: yes */
    unsigned int    tm_delay;       /* number of frames between RTT & TLM */
    unsigned int    frame_length;   /* in bytes, pad bytes not included */
    unsigned int    sync_length;    /* 8 to 32 */
    unsigned int    frame_cnrs;     /* b0: rs on, b1 crc verify,
                                       b2: sum ver, b3: turbo */
    unsigned int    tx_data;        /* b0: sw+data+rs, b1: data only */
    unsigned int    null;
    unsigned int    nada;
} APL_Header;

/* for APL cortex programming */
#define APL_HDR_SIZE            64      /* exactly 64 bytes */
#define APL_FRAME_SYNC_RS       (4+1115+160+5)  /* no idea */

where an unsigned int (or a float) is 4 bytes.

Thus the APL data comes in blocks of 1348 bytes.

  $ tlm=/usr/local/IBEX/raw/o0079/ibex_2010154_2_cortex 1_tlm.raw.0
  $ for s in {50..55}
    do dd if=$tlm bs=1348 count=1 skip=$s 2>/dev/null |\
       od -tx4 |\
       head -1
    done

finds the magic number 50..55 1384-blocks in:

	0000000 d2029649 44050000 00000000 6bd5ca00
	0000000 d2029649 44050000 00000000 6bd5ca00
	0000000 d2029649 44050000 00000000 6bd5ca00
	0000000 d2029649 44050000 00000000 6bd5ca00
	0000000 d2029649 44050000 00000000 6bd5ca00
	0000000 d2029649 44050000 00000000 6cd5ca00

( od just does a hex dump and doesn't reorder the bytes, so
  d2029649 is 499602d2 hex which is  1234567890  decimal )

My guess is that the 160 bytes is the RS-code block, and the 5
bytes on the end is perhaps rounding out the block somehow
(1348 / 4 = 337 fwiw).  So:

    64 byte header
     4 byte CADU Sync byte (1a cf fc 1d)
  1115 byte CADU frame (6 + 3 + 1106)
   160 byte RS block
     5 byte trailer

Hope that helps....

-- 

		Geoff (gbc at space.mit.edu)