OBDH - COMS Interface


All aspects of the interface are detailed in the OBDH - COMS Interface Document.

The COMS subsystem will receive control signals we send to the satellite from the ground station, as well as transmit system status, payload, ADCS and camera data. The data will be temporarily stored in the SD card until it’s transmitted.

The satellite must be in a certain state before it attempts to power-up the payload. For this reason, the satellite will transmit its state to the ground station, and wait for the ground station to request that the payload be powered-up.

The COMS system will be powered on in Recovery mode and transmits a beacon to allow the ground station to track the satellite. The antenna will be deployed after 30 minutes. Intervals will be left in the beacon transmission to allow the reception of the first contact command from the ground station.

Should the satellite be unable to receive data from the ground station for whatever reason, to avoid the mission failing completely the satellite will enter Autonomous mode, where the important ADCS and payload data will be continuously transmitted.

Required Pins
Pin Name I/O Description
H1.10 P4.6 O Set low to enable +5V_SW power
H2.2 P6.6 O Set low to enable transceiver interface
H1.34 -RST_MHX I +5V reset input to transceiver. Active LOW.
H1.35 -CTS_MHX O +5V clear-to-send output from transceiver. Active LOW.
H1.36 -RTS_MHX I +5V request-to-send input to transceiver. Active LOW.
H1.37 -DSR_MHX O +5V data set ready output from transceiver. Active LOW.
H1.38 -DTR_MHX I +5V data transmit ready input to transceiver. Active LOW.
H1.39 TXD_MHX I +5V transmit data input to transceiver. Idles HIGH.
H1.40 RXD_MHX O +5V receive data output from transceiver. Idles HIGH.

Team allocation

The current jobs of the OBDH team members working on the COMS interface are as follows.

David Marshall -

  • Produce a buffering system for sending multiple characters to the modem.
  • Write a general test plan for testing the connection of the modems.

Tom Hands -

  • Analyse the COMS modem base code and modify it for ease of use.
  • Talk to COMS team to find out if they have any way of reading in received data from the modem.

Gareth Gould -

  • Look at error testing for received characters and problem solutions.

Andy West -

Dominic Hilliard -


The flight controller interfaces with the COMS transceiver and modem using two modem connections, RADTXD (Input) and RADRXD (Output), at 9600Bd.

Communications are half duplex and a handshake is returned after every command is received.

To connect the development board to the modem use the connectors shown below. These are from the perspective looking at the back of the modem.


The pins can be connected to using the dismantled serial connector with green wires soldered to the required serial pins.

Current Test Plan (Updated 04.02.2010)

This is covered in the OBDH - COMS Interface Test Plan.

This test was carried out successfully, requiring a new plan to be produced. A generic plan is also needed to quickly determine that the modems have been connected and configured correctly, perhaps using a test branch of the code repository.

Expectations of the board’s communication

The ground station should be able to tell the satellite to do these things:

a) Report status
b) Power-up payload
c) Power-down payload
d) Take photo
e) Transmit SD cluster # (0 – 4,194,303)

Modem commands

Full details on all commands can be found in the OBDH - COMS Interface Document.

Modem initialisation

The modem requires configuration commands in a specific order to set it up. Each command returns ACK.

The command sequence is listed in the OBDH - COMS Interface Document.


Development History (2 week intervals)

Wed 30/09/2009 -

  • Work begins on COMS interface.

Wed 14/10/2009 -

  • To do: Output any signal from the USART. DONE

Wed 28/10/2009 -

  • Code developed and run on board to transmit characters using the USART.
  • Problem fixed where board pins were at 3.3V for an unknown reason. Switched to 5V logic by enabling transceiver interface.
  • To do: Set the correct baud rate settings by determining the clock speed used. CARRIED
  • To do: Configure USART interrupts. CARRIED
  • To do: Determine correct register settings. DONE

11/11/2009 -

  • Register settings determined.
  • Modem communicates with the board, responding with WAKAK to a WAKE character, read with the logic analyser.
  • To do: CARRIED: Set the correct baud rate settings by determining the clock speed used. DONE
  • To do: CARRIED: Configure USART interrupts. CARRIED
  • To do: Code sending a character to the modem, receiving a response and storing it to the SD card. DONE
  • To do: Begin programming AX.25 code. CARRIED
  • To do: Write COMS interface test plan document. CARRIED
  • To do: Write OBDH-COMS interface document. CARRIED
  • To do: Program modem commands. CARRIED

25/11/2009 -

  • Baud rate problems fixed which were causing a problem communicating with the modem.
  • Code can send a character to the modem, receive a response and store it to the SD card.
  • Error reporting from the USART added to the code.
  • OBDH-COMS interface document first draft nearly complete.
  • To do: CARRIED: Configure USART interrupts. DONE
  • To do: CARRIED: Begin programming AX.25 code.
  • To do: CARRIED: Write COMS interface test plan document.
  • To do: CARRIED: Finish writing OBDH-COMS interface document. DONE
  • To do: CARRIED: Program modem commands.
  • To do: Code the modem initialisation procedure.
  • To do: Process a command sent from a PC via the modems which causes the flight controller to change the system state.

10/12/2009 -

  • USART interrupts implemented.
  • OBDH - COMS interface document draft finished.

Winter break

03/02/2010 -

  • 3 system test between OBDH, COMS and ADCS attempted. Currently can't read in data from the modem to the board.
  • COMS Interface Test Plan written.

17/02/2010 -

  • Testing with COMS successful. The modems were used to send a signal to the board, which changed the system state causing the main loop to produce an output. It was not possible to interface with any other subsystems as none were available for testing.
  • Attempted to test new main program loop. The test could not be completed as one of the modems could not be successfully configured.

03/03/2010 -

17/03/2010 -

  • Modem initialisation and enquire functions complete.
  • Transmission of data from board via modems successful, it cannot be received by the laptop as the python code does not currently work in this mode, the transmission was tested using the logic analyser.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.