$50SAT – Eagle2 - Communications

Release Version 1.2 – April 2014

Table of Contents

$50SAT - Eagle2 - Communications....................................................................................................2Introduction.................................................................................................................................2

Frequencies used................................................................................................................3Best chance of hearing $50SAT - Eagle2..........................................................................3

Basic $50SAT operation..............................................................................................................3Sequence of tasks in the program loop..............................................................................3Sleep period.......................................................................................................................4

Data telemetry transmissions......................................................................................................5Packet transmissions from $50SAT - Eagle2.....................................................................5Packet structure..................................................................................................................5Packet type number............................................................................................................6Status flags.........................................................................................................................6Info packet contents...........................................................................................................6FEC packet contents..........................................................................................................8Ready packet contents.......................................................................................................9Acknowledge packet contents...........................................................................................9

Command uplink.......................................................................................................................10Open command uplink packets........................................................................................10Closed command uplink packets.....................................................................................10

Slow Morse beacon...................................................................................................................12Morse WPM rate..............................................................................................................12Morse tone frequency......................................................................................................12

Fast Morse data.........................................................................................................................13FLDIGI setup for fast Morse...........................................................................................14

FSK RTTY................................................................................................................................16FLDIGI setup for FSK RTTY..........................................................................................16FSK RTTY data...............................................................................................................17Format..............................................................................................................................17

RFM22B\Si4432 register configuration....................................................................................19Appendix 1 – Byte order of packets..........................................................................................20

Data packet......................................................................................................................20FEC packet.......................................................................................................................21FEC Telemetry portion of FEC packet (prior to encoding).............................................22Ready packet....................................................................................................................23Acknowledge packet........................................................................................................24

$50SAT - Eagle2 - Communications

Introduction

The principal objective of the $50SAT (Eagle2) project was to see if a viable satellite could be built to the Pocketqube standard, which is a 50mm cube form factor, using standard off the shelf commercial components. To date the smallest satellites in orbit have been Cubesats which are 100mm cubes.

The initial communications requirements were;

1. Transmit a slow Morse call sign identity.

2. Provide remote command uplink to turn radio transmissions off.

3. Operate at a programmable frequency in the 70cm amateur radio band.

4. A method of getting data back on solar panel and battery performance.

The small size of the satellite makes it difficult to find a ready built radio transceiver for communications. There are radio modems available for use in cubesats but they are either not small enough for use in a 50mm cube or not low cost.

The smaller surface area of a Pocketqube versus a Cubesat reduces the available power for radio transmissions, since there is only ¼ of the area for solar panels assuming that for simplicity of construction fold out panels are not used.

For command uplink the requirements for the receiver on this Pocketqube satellite are relatively modest, the satellite will operate in the 70cm amateur band so there is a ready supply of RF power amplifier’s and high gain antennas for use on the ground, thus the satellite's receiver need not be particularly sensitive.

Some tests were carried out using a Hope RFM22B FSK data transceiver which is based on the Silicon Labs Si4432 device. It was shown that with simple ¼ wave antennas and 100mW of transmit power the devices could transmit and receive 1kbps data packets reliably over a line of sight distance of 40km. To get a range of 1000km for the uplink to low earth orbit, approximately 26dB of gain would then be required, assuming a dipole is used on the satellite.

A modest 10dB gain yagi\uda antenna and a 10W output power amplifier, should have 30dB gain versus the 40km LOS tests and should allow for successful command uplink.

$50SAT is the name given to the satellite by the development team, the official designation is Eagle2.

The $50SAT Team;

Howie DeFelice - AB2S

Michael Kirkhart - KD8QBA

Stuart Robinson - GW7HPW

Frequencies used

All transmissions from and to $50SAT are at the same frequency, 437.505Mhz with up to plus or minus 10kHz of Doppler shift.

Best chance of hearing $50SAT - Eagle2

Tests carried out listening to other amateur satellites suggest that the FSK RTTY sent by $50SAT should easily be heard using standard amateur radio receivers and an omni directional antenna such as a quadrifilar helix and with no low noise amplifier required. The equipment used by the author for these tests was a home brew quadrifilar helix mounted on a 12 metre mast and connected to a Yaesu FT817.

The distinctive 1 second FSK pips sent before the actual FSK RTTY data should be readily heard. These pips should also be seen in the spectrum display of one of the software defined radios such asthe Funcube Dongle.

Basic $50SAT operation

The $50SAT communications and measurements are sequenced in a program loop that constantly repeats. This loop starts as soon as the initial set-up of $50SAT has completed following a hardwareor software instigated reset. Reset can occur for several reasons, a program crash following a RAM corruption for instance or measured over current or very low battery. To sequence the transmissions of the five different slow Morse beacons, fast Morse and the FSK RTTY, there is a sequence counter for the program loop (BeaconLoopSeq) that runs from 0-4 and back round to 0 again. Its the BeaconLoopSeq that controls which slow Morse beacon (0-4) is sent out on a particular program loop. The fast Morse and FSK RTTY are not sent at every program loop, but alternate according the values of BeaconLoopSeq. After the initial set up the $50SAT program executes its tasks in a specific order. Its difficult to give precise timings for where in the program loops these tasks occur as the Morse messages vary in length as does the word per minute (WPM) rate. The fast Morse data takes less time to transmit thanthe FSK RTTY and the sleep time varies too. Its best to use the slow Morse beacon as a marker. Of particular note is that the listen period for command uplink is the 10 seconds immediately after the end of the slow Morse beacon and the transmission of a single 'ready' packet.

Sequence of tasks in the program loop

Start of program loop.

Measurements of voltages, currents, temperatures, SEU check.

Transmit slow Morse beacon, one of 5 in rotation, starts approximately 12 seconds after the start of the program loop.

Transmit a single 'ready' packet.

Listen for incoming command packets for 10 seconds, listen period starts immediately after end of slow Morse beacon and the transmission of the 'ready' packet.

Transmit fast Morse data on BeaconLoopSeq 1 and 3, starts approximately 11 seconds after end of slow Morse beacon.

Transmit FSK RTTY on BeaconLoopSeq 0, 2 and 4, starts approximately 11 seconds after end of slow Morse beacon. Transmit data packet, transmitted immediately after end of Fast Morse or RTTY.

Transmit FEC encoded data packet, transmitted approximately 6 seconds after the normal data packet.

Sleep period (see below).

Repeat program loop.

Sleep period

Each iteration of the program loop takes about one minute at full battery charge. As the battery voltage falls, the sleep periods extends to balance available power with consumed power. The extension of the sleep period means that at low battery charge the various transmissions occur less often. Its the radio transmissions that consume most of the power so with longer periods between transmissions much less power is consumed. Also note that if the battery voltage drops below 3.3V transmissions are stopped.

With a full battery, the program loop takes approximately 1 minute to execute, including a short sleep (idle) period. Thus the slow Morse beacon is sent out once per minute under these conditions.The sleep period in seconds is (approximately) for battery voltages below these levels in mV; Default 12 seconds3800mV 25 seconds3700mV 50 seconds3600mV 126 seconds3500mV 176 seconds3400mV 226 seconds3300mV 277 seconds, but transmission disabled due to low voltage3200mV 327 seconds, but transmission disabled due to low voltage3100mV 378 seconds, but transmission disabled due to low voltage

Data telemetry transmissions

The Hope RFM22B uses the Silicon Labs Si4432 RF transceiver which is designed to send and receive digital packets of data using frequency shift keying (FSK). The receive sensitivity of the RFM22B is quoted as -121dBm, so receiving the data telemetry from low earth orbit at a distance of1000km or so, and with only 100mW of transmit power is certainly challenging. Tests at ground level suggest that a good quality low noise mast head amplifier such as the Super-Amp SP7000 adds about 12dB of useful signal gain when used in front of the RFM22B receiver. With a high gain yagi or dish in use, reception of data telemetry on the ground should be possible when the satellite is directly overhead.

The $50SAT team did investigate the use of the Hope RFM23BP, which uses the same RF IC as the RFM22B, but with an added 1W amplifier. However this would have required a re-design of the solar panels, the maximum power point tracker and battery choice to provide the 5V and 550mA of current the RFM23BP needs for full power. So it was decided to proceed with the RFM22B design.

Packet transmissions from $50SAT - Eagle2

During the $50SAT program loop 4 different types of packets are sent by the RFM22B. They are a ready packet, an acknowledge packet, a data packet and a FEC encoded data packet. To improve reliability of communications both data packets are sent 3 times. Although the packets are sent in FSK mode, they will be heard as noise on a FM receiver. The ready packet is sent once and the acknowledge packet is sent twice. The acknowledge packet is sent on receipt of a valid command packet (see later).

All packets have the same basic format, with only the amount of data payload varying. The transmission format is;

Frequency, 437.505MhzFSK deviation 5kHz Data rate 1kbpsGFSK ModulationData sent MSB first

Packet structure

Preamble = 64 bits Sync Word byte 1 = 0x2D Sync Word byte 2 = 0xD4Header Byte 3 = Text character '$'Header Byte 2 = Text character '5'Header Byte 1 = Packet type numberHeader Byte 0 = Status flags. Packet Length = {varies}Data Payload = {varies}CRC = 2 bytes of CCIT CRC on header, packet length and data fields

Packet type number

The packet type number in the header identifies what the packet is or contains;

1 = Ready packet, sent at beginning of the $50SAT command uplink receive period5 = Acknowledge packet, sent after a valid packet received34 = Info packet, contains status information and measurements made by $50SAT 73 = FEC encoded version of Info packet

Status flags

Header byte 0 is a byte of $50SAT status flags;

SEUflag, bit0, set if there is a detected single event upset on scratch pad RAM.

Freqchange, bit2 , set if there is a change in transmit frequency after tone or packet send.

RFMconfigerror, bit3 , set if a byte error is seen reading the RFM22B configuration from table.

CommandOK, bit4 , set if a valid command key has been received.

EEPROMflag, bit6 , set if a EEPROM error is seen.

Nocharge, bit7 , set if charge is disabled.

Info packet contents

Header Byte 3 = “$” (0x24)

Header Byte 2 = “5” (0x35)

Header Byte 1 = 34 (0x22)Header Byte 0 = Status flags.

Then 24 bytes in total, a mixture of bytes and words;

Flags, byte, various flag bits, same as the flags in header byte 0.SEUCount, word, for current SEU error count.NumResets, word, number of Resets.EEPROMfails, byte, number of EEPROM locations that fail check.Fchanges, word, number of frequency changes detected.RFMTemperature, byte, measured RFM22B internal temperature.Idlecurrent, byte, measured current in mA during program idle.RSSIlast, byte, RSSI value of last packet received.RXcurrent, byte, measured current in mA during receive.PCBTemperature, byte, results from DS18B20 digital temperature sensor.TXcurrent, byte, measured current in mA during transmit.SolarCurrent, byte, measured solar charge current in mA.SolarVolts, word, Solar mV.NumberLUPs, word, number of over currents detected.

Batvolts, word, battery mV.PacketSequenceNumber, word, increments by 1 for every packet sent.TXpower, byte, power level of transmitter, should always be 7.

This is a more detailed explanation of each of these parameters;

Flags Same as described for the header byte 0 above.

SEUCount Every program loop, a 512 byte area of RAM is checked for any SEU events causing bit changes. A running total of detected changes is kept and stored in EEPROM.

NumResets Each time $50SAT is reset the reset counter is incremented and stored in EEPROM.

EEPROMfails During RFM22B configuration a comparison is made between the parameters stored in EEPROM and those stored directly in program memory. This is a count of the locations that differ.

Fchanges After every RFM22B transmission a check is made to see if the RFM22B has reset. This is a running count of the number of such changes, the running total is also stored in EEPROM.

RFMTemperature The reading from the internal RFM22B temperature sensor, not very accurate. Avalue of 0 is -64C, a value of 64 is 0C, a value of 128 is +64C.

Idlecurrent The measured current in mA during program idle, normally about 3-5mA.

RSSIlast RSSI value of last packet received, a larger number is a stronger signal, the lower limit forreception is a value of 40-45.

RXcurrent The measured current in mA during RFM22B receive, normally about 22mA.

PCBTemperature Results from DS18B20 digital temperature sensor, 0-127 = 0 to +127C, values above 127 are the temperature below 0C, such that 132 = -4C. TXcurrent The measured current in mA during RFM22B transmit, normally about 100mA.

SolarCurrent The measured Solar charge current in mA.

SolarVolts The measured solar voltage in mV.

NumberLUPs When the idle, RX and TX currents are measured a check is done for excess current in order to detect over current latch up situations. If detected a power down is initiated and the NumberLUP parameter is incremented and stored in EEPROM.

Batvolts The measured battery voltage in mV.

PacketSequenceNumber Increments by 1 for every packet sent.

TXpower Power level of transmitter, should be 7 (100mW).

FEC packet contents

Header Byte 3 = “$” (0x24)

Header Byte 2 = “5” (0x35)

Header Byte 1 = 73 (0x49)Header Byte 0 = Status flags.

Then 51 data bytes, consisting of:FEC telemetry, 48 bytesPacketSequenceNumber, word, increments by 1 for every packet sentTxpower, byte, power level of transmitter, should always be 7

The FEC telemetry, prior to forward error correction, consists of 24 bytes. The first 21 bytes are a duplicate of the info packet packet data from flags up to and including Batvolts. This is followed by a 16 bit CRC (CRC-16) and a terminator byte (11, or 0x0b). This is then forward error correctedusing a r=1/2, L=4, non-recursive convolutional encoder. The output of the encoder, which consistsof 2 bits for each bit of data input, is then run through a 4 by 4 matrix interleaver. Since the FEC packet is almost twice as large as the info packet, it takes nearly twice as long to transmit.

While it is still possible to successfully receive info packets on the ground, the FEC packets were added to improve the probability of successful reception telemetry data. In theory, the coding gain for this forward error correction scheme approaches 4.8 dB; in practice, it will likely be about 3 dB.

This forward error correction scheme is the same as the one developed by Keith Packard for use in the AltOS operating system. This, in turn, is based on the forward error correction scheme used on the TI CC1111 ISM band transceiver. TI Design Note DN504 provides an excellent explanation of this forward error correction scheme, with an emphasis on the encoder, while TI Design Note DN507 describes the implementation of the decoder, which is based on the Viterbi algorithm.

Ready packet contents

Header Byte 3 = “$” (0x24)

Header Byte 2 = “5” (0x35)

Header Byte 1 = 1 (0x01)Header Byte 0 = Status flags.

Then 4 data bytes;

SolarCurrent, byte, measured Solar charge current in mA.PacketSequenceNumber, word, increments by 1 for every packet sent.

TXpower, byte, power level of transmitter, should always be 7.

Acknowledge packet contents

Header Byte 3 = “$” (0x24)

Header Byte 2 = “5” (0x35)

Header Byte 1 = 5 (0x05)Header Byte 0 = Status flags.

Then 4 data bytes;

RSSIlast, byte, RSSI value of last packet received.PacketSequenceNumber, word, increments by 1 for every packet sent.Txpower, byte, power level of transmitter, should always be 7.

When a test packet is received by $50SAT it responds by transmitting an acknowledge packet and then the measured RSSI of the received packet in slow FM Morse.

Command uplink

It is a requirement to be able to turn off the satellite transmissions if requested. For a 10 second period in every program loop (approx once a minute at full battery charge) and just after the slow Morse call sign transmission, the transceiver is in listen mode for 10 seconds, waiting for an incoming data packet. At the start of the listen period a ready packet is also sent.

The separate ground station transceiver PCB and software is used to transmit the various command uplink packets that $50SAT will accept. The 100mW output of the RFM22B will need to be suitablyamplified up to 10W or more to allow $50SAT to receive the packets in low earth orbit.

Open command uplink packets.

The following command uplink packets are open, in that they can be transmitted by anyone with a suitable ground station transmitter set-up. The $50SAT receiver uses the packet packet number to decide what action to take, that number is in the transmitted packets header byte 1, as per the explanation of packet types above.

There is a four data byte payload sent with the open command uplink packets, but it is ignored by the $50SAT receiver. For reference the data payload is;

0x00PacketSequenceNumber, word, increments by 1 for every packet sentTxpower, byte, power level of transmitter, should be 7

The open packet numbers are;

Packet number 35 Test packet, when received $50SAT transmits the received signal level (RSSI) as slow FM Morse numbers.

Packet Number 50 $50SAT transmits the data telemetry info packet.

Packet Number 52 $50SAT transmits the FSK RTTY data.

Closed command uplink packets

For these packets both $50SAT and the ground station need the same 64 bit key, which is not intended for public release.

The data payload part of the packet is then 11 bytes;

64 bit key, 8 bytesPacketSequenceNumber, word, increments by 1 for every packet sentTxpower, byte, power level of transmitter, should be 7

The closed packet numbers are;

Packet 36 Turns the $50SAT Transmitter off

Packet 37 Turns the $50SAT Transmitter on

Packet 54 Force processor reset

Packet 57 Change fifth slow Morse beacon message

The fifth beacon message of up to 15 numbers or characters can be changed remotely, and remains stored in EEPROM and in use until changed again.

Note that the $50SAT transmitter on\off status is permanently stored in EEPROM, to prevent inappropriate transmissions after any possible resets.

Slow Morse beacon

Once every program loop (approximately 1 minute at full battery charge) one of five call signs or messages is sent out as slow FM Morse, deviation of 5Khz. The sequence is;

GW7HPWAB2SKD8QBAS50SATEAGLE2

The 'EAGLE2” message can be changed to a different message of up to 15 characters by command uplink from the ground.

The words per minute (WPM) speed of the Morse will increase as the solar voltage falls, and the tone of the Morse will be higher for a higher battery voltage as described below.

Morse WPM rate

The WPM rate of the Morse is varied as the solar panel voltage varies. At high solar voltage the Morse WPM is reduced, and at low solar voltage it is speeded up. So by listening to the FM Morse you can tell if the solar voltage is high or low. In addition at low solar volts where the battery chargeis expected to be low also, the faster Morse uses less power.

At 2500mV from the solar panels the delay value used for the Morse dit period is 50mS, this gives aWPM rate of approx 24WPM. At 4500mV from the solar panels the delay value used for the Morse dit period is 100mS, this gives a WPM rate of 12WPM.

Morse tone frequency

The tones used for the Slow Morse beacon will vary as the battery voltage changes.

At 3300mV all transmissions are turned off, so there is little point in setting the Morse tone frequency for this low level. The limits used are 3400mV to 4300mV, although in normal operation the battery voltage should not exceed 3900mV.

To make the voltage easy to read, at 3400mV the tone frequency is 500Hz, thus it will readily show up on the frequency display of FLDIGI, 500Hz = 3400mV, 700Hz = 3600mV, 4300mV = 1400Hz etc.

Note that at 3900mV, normal for a fully charged battery, the Morse tone frequency is 1000Hz, which is the same frequency used for the fast Morse. So for a fully charged battery, the slow Morse and fast Morse tones should be the same.

If FLDIGI is used to display the received FM audio, you can readily read off the frequency and determine the battery volts. See the screen shot below, the frequency of the Morse is around 1020Hz, representing a battery voltage of around 3920mV.

Fast Morse data

Every other run of the main program loop (so approximately every two minutes at full battery) key data is sent out as fast 120WPM FM Morse. This is too fast to decode by ear, but there are several PC based programs that will decode fast Morse, you just need to install the software and feed the audio from a UHF receiver, a simple HT will do, into a PC. Then tune into the slow Morse beacon, remembering that the Doppler shift may be as much as plus 10kHz as the satellite is coming towards you and as much as minus 10kHz as its going away from you. This gives a possible tuning range of between 437.515MHz and 437.495Mhz. The data sent in fast Morse is; battery volts, solarvolts and solar current. The software used was FLDIGI, and the version available at the time of writing, Fldigi 3.21.76, does decode the fast Morse, some previous versions would not adequately decode the faster Morse.

FLDIGI setup for fast Morse

The parameters to use to configure FLDIGI for fast Morse are shown below;

The tone frequency used for the fast Morse is 1kHz, so place the tuning cursor (the two red lines) at 1kHz in the displayed audio window at the bottom of the screen, see picture;

When the fast Morse is received it should be decoded and will appear on the terminal screen;

The decoded Morse is shown as;0<AR>2<AR>2<AR>2<AR>BV 3915SV 4103SI 016The <AR>2<AR>2<AR>2<AR> sequence are sync characters sent by $50SAT to help FLDIGI to lock onto the Morse.

The values are then;BV3915 = Battery volts = 3915mVSV4103 = Solar volts = 4103mVSI016 = Solar current = 16mA

FSK RTTY

The RFM22B\Si4432 is a FSK transmitter and can be switched rapidly between two carrier frequencies. Thus two FSK tones can be generated by radio receivers capable of receiving in low side band mode. Most base station UHF transceivers can receive in LSB mode as can the Funcube dongle. The $50SAT software sends the same bytes in the info packet as 8 bit ASCII FSK RTTY. The audio from the receiver is fed into a PC and software such as FLDIGI is used to decode it.

FLDIGI setup for FSK RTTY

FLDIGI needs to be set-up correctly, the settings are; 100baud, set for custom carrier shift, 630Hz shift, 8 (ascii) bits per character, none parity, 1 stop bit, fast AFC.

The RTTY decoder in FLDIGI then needs to be positioned correctly to allow the ASCII to be decoded, the FSK uses two tones about 630Hz apart. It was designed to use FLDIGI with the tuningpoint of the radio set to produce the two shifted tones centred on a 1kHz shift. To this end, if the radio receiver is tuned such that the reception frequency is in the centre of the FM Morse (clearest signal) and you then shift the receiver to LSB mode the two FSK tones should appear at the right width apart and at approximately 685Hz and 1315Hz.

To aid radio tuning and to assist in the positioning of the FLDIGI decode cursor (the red lines) the FSK RTTY transmission is prefaced with a sequence of 11 short FSK pips transmitted with an offset approximately 1kHz from the RFM22 centre frequency, so they should be heard as 1khz tones. The pips should look like this in the FLDIGI audio display;

You can see that the yellow aiming cursor lines have been placed over the centre of the pips. The drift is normal as the RFM22B cools and heats. Just before the last pip, freeze the red decode lines by pressing the mouse button.

When the RTTY data starts, and assuming you have AFC enabled, the red decode lines should track the two tones and decode the RTTY, see below;

FSK RTTY data

Format

The bytes and words from the info packet are formatted in the style of a GPS NMEA string before being sent out. The individual bytes and words are separated by commas, which allows the receivedcharacters to be copied from the FLDIGI terminal screen and loaded into a spreadsheet in CSV format. Zero entries are not sent so a zero field will be represented by two adjacent commas. The sequence of data is the same as for the info data packet, see above. However for the RTTY data the PacketSequenceNumber (word) and TXpower (byte) are not sent so the last data field in of the RTTY is the battery voltage. There is also a NMEA style checksum appended to the end as below;

$$$$50SAT,128,,162,,,54,3,,21,140,87,,102,,3723,*70

Note that the data fields start after the comma after 50SAT such that the first data field (128 in the above case) is the flags byte. Also note that the comma after the last data field (3723 in the above example) is also ignored.

As an example, the above RTTY data, the first data received from $50SAT after it was launched, decodes as follows;

Flags 128 = charge disabled (due to cold)SEUCount 0NumResets 162EEPROMfails 0Frequency changes 0RFMTemperature 54 = -9C (not accurate)Idlecurrent 3mARSSIlast 0 = means no packets receivedRXcurrent 21mAPCBTemperature 140 = -13C (accurate)TXcurrent 87mASolarCurrent 0SolarVolts 102mV.

NumberLUPs 0 (includes planned power downs every 500mins)Batvolts 3723mV

The characters between the last $ and the * can be copied from the FLDIGI terminal screen and intoone of the on-line NMEA Checksum generators. Thus if you copy;50SAT,,,1,,,90,2,,23,20,95,,756,,3834,

Into this checker here;

http://www.hhhh.org/wiml/proj/nmeaxor.html

It should confirm the checksum is 70

RFM22B\Si4432 register configuration

The RFM22B for both $50SAT and the ground station receiver has the same basic configuration. After reset of the RFM22B the initialisation requires that some registers are set to values other than the reset values. The settings needed are, hexadecimal number of register first, then the hexadecimalcontents of the register;

$07,$40 'TX and RX off, LBT on$09,capvaluedefault 'Oscillator load capacitance, fine tune frequency for each RFM22 module$0D,$10 'Configure GPIO2 pin for Direct mod (Morse)$12, $60 'set-up temperature sensor$1C,$29 'IF Filter Bandwidth $1D,$40 'AFC Loop Gear shift Override $20,$E8 'Clock recovery oversampling ratio $21,$60 'Clock recovery oversampling ratio $22,$20 'Clock recovery offset 1 $23,$C5 'Clock recovery offset 0 $24,$10 'Clock recovery timing loop gain 1$25,$0F 'Clock recovery timing loop gain 0 $2A,$1D 'AFC Limiter $30,$8C 'Data access control $32,$8C 'Header control 1 $33,$42 'Header control 2 $34,$10 'Preamble length $35,$22 'Preamble detection control $3A,"$" 'Transmit header 3$3B,"5" 'Transmit header 2 $3F,"$" 'Check header 3 $40,"5" 'Check header 2 $69,$60 'AGC on$6E,$08 'Data rate $6F,$31 'Data rate $70,$2C 'Modulation mode control 1$75, $53 'Frequency band select $76, $BB 'Nominal carrier frequency 1 $77, $A0 'Nominal carrier frequency 2

$50SAT Team – April 2014

Appendix 1 – Byte order of packets

This appendix details the outgoing byte sequence of the packet types used. The structure is handled automatically by the RFM22B packet handler, but knowing the structure may be useful if a differentdevice is used to receive or transmit the packets. Note that the two byte words are sent out as they appear in PICAXE memory, low byte first (little endian format).

Data packet

FEC packet

FEC Telemetry portion of FEC packet (prior to encoding)

Ready packet

Acknowledge packet