$50SAT Eagle2 - Communications

Release Version 1.2 April 2014

Table of Contents
$50SAT - Eagle2 - Communications....................................................................................................2
Introduction.................................................................................................................................2
Frequencies used................................................................................................................3
Best chance of hearing $50SAT - Eagle2..........................................................................3
Basic $50SAT operation..............................................................................................................3
Sequence of tasks in the program loop..............................................................................3
Sleep period.......................................................................................................................4
Data telemetry transmissions......................................................................................................5
Packet transmissions from $50SAT - Eagle2.....................................................................5
Packet structure..................................................................................................................5
Packet type number............................................................................................................6
Status flags.........................................................................................................................6
Info packet contents...........................................................................................................6
FEC packet contents..........................................................................................................8
Ready packet contents.......................................................................................................9
Acknowledge packet contents...........................................................................................9
Command uplink.......................................................................................................................10
Open command uplink packets........................................................................................10
Closed command uplink packets.....................................................................................10
Slow Morse beacon...................................................................................................................12
Morse WPM rate..............................................................................................................12
Morse tone frequency......................................................................................................12
Fast Morse data.........................................................................................................................13
FLDIGI setup for fast Morse...........................................................................................14
FSK RTTY................................................................................................................................16
FLDIGI setup for FSK RTTY..........................................................................................16
FSK RTTY data...............................................................................................................17
Format..............................................................................................................................17
RFM22B\Si4432 register configuration....................................................................................19
Appendix 1 Byte order of packets..........................................................................................20
Data packet......................................................................................................................20
FEC packet.......................................................................................................................21
FEC Telemetry portion of FEC packet (prior to encoding).............................................22
Ready packet....................................................................................................................23
Acknowledge 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
amplifiers 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 as
the 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 hardware
or 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 than
the 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 seconds
3800mV 25 seconds
3700mV 50 seconds
3600mV 126 seconds
3500mV 176 seconds
3400mV 226 seconds
3300mV 277 seconds, but transmission disabled due to low voltage
3200mV 327 seconds, but transmission disabled due to low voltage
3100mV 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 of
1000km 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.505Mhz
FSK deviation 5kHz
Data rate 1kbps
GFSK Modulation
Data sent MSB first
Packet structure
Preamble = 64 bits
Sync Word byte 1 = 0x2D
Sync Word byte 2 = 0xD4
Header Byte 3 = Text character '$'
Header Byte 2 = Text character '5'
Header Byte 1 = Packet type number
Header 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 period
5 = Acknowledge packet, sent after a valid packet received
34 = 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. A
value 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 for
reception 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 bytes
PacketSequenceNumber, word, increments by 1 for every packet sent
Txpower, 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 corrected
using a r=1/2, L=4, non-recursive convolutional encoder. The output of the encoder, which consists
of 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 suitably
amplified 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;
0x00
PacketSequenceNumber, word, increments by 1 for every packet sent
Txpower, 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 bytes
PacketSequenceNumber, word, increments by 1 for every packet sent
Txpower, 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;
GW7HPW
AB2S
KD8QBA
S50SAT
EAGLE2
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 charge
is 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 a
WPM 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, solar
volts 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 016
The <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 = 3915mV
SV4103 = Solar volts = 4103mV
SI016 = 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 tuning
point 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 received
characters 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 0
NumResets 162
EEPROMfails 0
Frequency changes 0
RFMTemperature 54 = -9C (not accurate)
Idlecurrent 3mA
RSSIlast 0 = means no packets received
RXcurrent 21mA
PCBTemperature 140 = -13C (accurate)
TXcurrent 87mA
SolarCurrent 0
SolarVolts 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 into
one 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 hexadecimal
contents 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 different
device 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