rocketview is PSAS' telemetry viewer for LV1b and later launch vehicles. LV1b's
rocketview was a C/GTK+ application (see the below) and the current LV2
rocketview is a Java SDK 1.2 application.
- RocketViewRecoveryNode - Spec on how to display recovery node information in rocketview
- RocketViewGpsNode - Spec on how to display the GPS node info
- RocketViewApsNode - Spec on how to display the Avionics Power System node info
- RocketViewImuNode - Spec on how to display the IMU node info
- RocketViewLaunchPanel - Spec on the integrated LaunchControl panel.
Yes, most of this should be moved to an old-rockview page. The archictecture and layout ofchanges frequently, so it shouldn't be documented here.
The Java implementation of our telemetry display software, RocketView, has several components. These are:
- an interface to CanMuxer
- a set of CAN message renderers
- a message dispatcher from CAN to the renderers
- a specialized stripchart GUI component
- a driver which integrates the other parts of the system together
CanSocket are defined as follows.
public class CanMessage
protected short id;
protected Date timestamp;
protected byte body;
public CanMessage(short id, Date timestamp, byte body)
this.id = id;
this.timestamp = timestamp;
this.body = body;
public short getId()
public Date getTimestamp()
public byte getBody()
public CanMessage read() throws IOException;
public void write(CanMessage msg) throws IOException;
public void close() throws IOException;
TCPCanSocket class implements
CanSocket to provide a connection to a running CanMuxer instance.
LogCanSocket class acts as a filter, passing calls to its methods through to an underlying
CanSocket instance, but also logging all
CanMessages it sees to a file.
CanRenderer interface is implemented by classes that wish to recieve
CanMessages from the dispatcher, presumably in order to display the contents of those messages through a GUI or other user interface. This interface is defined as follows.
public void render(CanMessage msg);
Dispatcher class tracks CAN renderers which have been registered with it and provides an event loop for processing messages from the rocket.
JStripChart class accepts timestamped numbers and renders them on a scrolling timestamp-scaled scatterplot.
RocketView class initializes the renderers, lays out a GUI, and passes control to the dispatcher.
- Write dispatcher class
- Write stripchart class
- Read up on java.net.Socket, java.io.InputStream/OutputStream, java.awt.GridBagLayout, and Swing in general
- Write CAN network class
- Write main (layout) class
This page is an attempt to document Rocketview, our current telemetry display software. Comments and questions are requested to help me make this documentation more complete.
--- 09 Jan 2002
The source code for LV1b's version of Rocketview may be browsed online at http://bart.cs.pdx.edu/cvsweb/cgi-bin/cvsweb.cgi/rocketview/ . The new version for LV2 is under development at http://bart.cs.pdx.edu/cvsweb/cgi-bin/cvsweb.cgi/fc/rocketview/ . (As of this writing, the new version is nearly identical to the old one.)
The transport is intended to be the same as that used by CanMuxer, so that no special-purpose software is needed to deliver telemetry data to the ground. Transport details are mostly abstracted by libcan, part of CanMuxer.
The transport handles splitting the telemetry stream into packets, but Rocketview is still responsible for interpreting the data in those packets. This layer selects a RocketView to handle each packet based on the CanBusIDs.
LV1b specifics: serial.c and the packet/ directory
The transport was over radio modems, so Rocketview communicated with a serial port. The protocol used is documented at GroundSupport.
serial.c handled opening and reading the serial port, buffering input until a complete packet arrived, calling the right packet decoder when a complete packet had been read, and passing the decoded packet to a RocketView.
A domain-specific language was created to describe packet formats, including the order, types, and names of the fields in each type of packet. These descriptions were used to generate the packet decoders in the packet/ subdirectory.
Some calculations are done on the ground before presenting the telemetry data to the user.
- Samples from the pressure sensor are converted into altitude.
The remaining processing involves reporting the data to the right RocketView widgets.
- Altitude from pressure and/or GPS
- GPS latitude and longitude, status, and number of visible satellites
- Flight computer's current time
- StateMachineApr2003 state transition messages
- IMU acceleration and rotation measurements
BartMassey wrote a custom stripchart widget for this project.
BartMassey wrote the original GUI code. wrote the original packet parsing and processing code. Both collaborated to complete the result.