• About PSAS
• Get Involved!
• Schedule
• Projects
• Presentations
• Mailing lists
• Contact us

• Teams
  • Airframe
  • Avionics
  • Communications
  • Ground
  • Payload
  • Propulsion
  • Rocket Science
  • Safety
  • Software
  • Uncertainty
  • Regulation
  • PSU Student Club

Node Testing

• Objectives:
  • Test firmware. Software Needed:
  • serial port test
  • Blinky Demo
  • eCos Port Plan:
  • Once the generic node front end has been fabbed and the Glue and SPS logic tested, the next step is to bring up the firmware on the board. The process will be similar to bringing up the Olimex evaluation board: verify communication through the serial port, download a simple program to blink an LED, and then download the same program running under eCos.

Initial USB Testing

• Objectives:
  • Demonstrate simple USB communications Software Needed:
  • simple USB software Plan:
  • A good first test of the USB software would be to set up a control endpoint that would send an "I'm alive" packet every USB frame. The host side would look at the frame number and endpoint number included in the USB frame to make sure that no packet was dropped. This test could be done without an eCos USB driver. This simple test might be used in flight to indicate that a node is functional. Since isochronous and interrupt transfers can only take up 90% of the USB frame, the test would not take away bandwidth from sensor data and would provide valuable feedback.

USB Performance Testing

• Objectives:
  • Test USB performance Software Needed:
  • eCos USB driver eCos isochronous USB support Plan:
  • When the PSAS software team suggested switching from CAN to USB, avionics team members were initially concerned about USB packet loss and bus speeds. There are no published papers on USB bandwidth tests, just the specification's assurance that it should "just work". Another concern is that the USB peripheral on the ARM microcontroller might be inferior. The USB software test should push USB to its packet size and bandwidth limits. We are especially interested in tests on isochronous transfers. Isochronous transfers are not retransmitted, so we want to make sure that the packets get through uncorrupted. A good test would be to create a configuration where the sum of the isochronous endpoint max packet sizes will use up the entire USB frame. The USB specification states that each received packet will contain the frame number and endpoint number that transmitted the data. If each packet contains a unique incremental packet ID, the host side can check that the endpoints are sending correct data every frame, and look for dropped packets. The isochronous code will be fairly complicated. An eCos USB driver is not strictly necessary for this test, but would be helpful. An eCos USB driver would handle the USB initialization, and would allow the designer of the isochronous test code to focus on the test code. However, this requires adding isochronous transfer support to eCos, a task that may take several months.