Skip to content

Instantly share code, notes, and snippets.

@Micrified

Micrified/stefano_meeting_notes.md

Created January 27, 2020 15:05
Show Gist options
  • Save Micrified/e286e49c5baf580f222b460d70db8940 to your computer and use it in GitHub Desktop.
Save Micrified/e286e49c5baf580f222b460d70db8940 to your computer and use it in GitHub Desktop.
Download ZIP
Meeting Notes for Communications
Raw
stefano_meeting_notes.md

Communication Hardware/Software Facts

  1. The hardware takes a slice of bytes and sends it.
  2. A driver provides an interface to send information
  3. There isn't just one interface, but several that can be used (expanded upon later)
  4. Stefano has been told that all buses are point-to-point.
  5. Stefano has been told he will have his own UART
  6. The hardware internally uses a simple protocol with a header, size, body, etc.
  7. The hardware provides telemetry information that can be queried via the driver.
  8. The hardware can respond to different commands send in formatted messages over the UART. The commands include asking if the hardware is responding, asking if there is a ping (assuming that is a link to the ground station), and a command to power-cycle the board.
  9. All software that runs the board is available here: https://github.com/DelfiSpace/COMMS_FlightSoftware/tree/89421855b379bc1ad7054342ddb9c3b583d82942
  10. The UART can use different addressing methods. One way is just to wait for a pause, then assume the first byte or bytes of the next data send represents the address of the device being communicated to. The protocol assumed by Stefano and the communications module uses 9-bit addressing. There is an extra bit marking the beginning of a transmission.
  11. The legs use the UART. Can look into how they communicate.
  12. The internal protocol used is AX.25, which only supports error-detection. Packets are chunked into 64 bytes or so. The protocol doesn't account for dropped packets. It is constructed specifically for communication with distances as far as the moon.
  13. System has 4 serial ports, two on connectors. One for debug. One mode made for Zebro is to transmit on two carriers. One is for data. Easiest is for them to have one serial.

Communications Module

  1. Nobody is writing the communications module at this time.
  2. Stefano is only responsible for the driver, as far as he is concerned.
  3. The driver available is written in C++, which is good.

Communication Options

PPU can talk to comms via the following options:

  1. On a dedicated RS485 separate point-to-point bus.
  2. Everyone on the same bus, or communications module is in-between them.
  3. In general, Stefano/Sevket aren't clear on what is going to be used.

Testing Hardware

  1. A USRP (software radio) can be used to test the communication hardware.
  2. Can work when plugged into a software radio. Also implemented AX25 as a protocol (old one)
  3. A USRP behaves as a very fast ADC or DAC operating with RF. Identical hardware (almost) is available at EWI.
  4. 2s flight time for messages
  5. Bit-rate for 100bps for EWI (using the dish on top of the building). 10Kbps for Dwingeloo (25m dish)
  6. Availability would be whenever the moon is in view (9-12h a day)
  7. No specific ground station made yet.

Radiation Hardened Software

  1. For modules produced (by ISIS), two watchdogs keep track of the system. One internal watchdog runs on the processor watches communication between the board and OBC. The external watchdog ensures that programs are setting flags every so often. If they aren't, the system is power-cycled. The external watchdog is not part of the processor and is its own IC.
  2. Checkpoints are placed approximately every one second worth of execution time.
  3. Unsure if this external watchdog is included with the Zebro hardware.

LEAP

  1. Sujay may be using a newer version of communication/radio hardware for other project.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment