MARINA run progress

Posted on April 26, 2015 by Charles Lacy

With the initial telemetry analysis and checkout phase done, GRIFEX operations has shifted primarily to data generation and mass downlink. GRIFEX’s performance on-orbit has thus far been mostly nominal, allowing us to complete 11 runs of the MARINA payload and downlink the data from 8 runs. The runs are summarized below:

Completion Number	Date/Time	Coordinates (Approx)	Location (Approx)	Downlinked?
1	2/11/2015 22:54:26 UTC	28°54'N 76°45'W	Off the coast of Florida	Yes
2	2015/02/18 22:45:00 UTC	80°09'N 135°16'W	North Pole	Yes
3	2015/02/19 21:51:00 UTC	69°39'S 100°20'E	South Pole	Yes
4	2/25/2015 11:22:41 UTC	48°25'N 65°36'W	New Brunswick	Yes
5	2015/02/25 14:17:00 UTC	69°54'N, 34°18'E	North of Finland	Yes
6	2015/03/11 23:03:00 UTC	79°35'N 128°35'W	North Pole	Yes
7	2015/03/30 23:03:44 UTC		[Ann Arbor run]	No
8	2015/04/01 00:32:01 UTC	10°02'N, 88°24'W	Off the coast of Nicaragua	Yes
9	2015/04/20 00:58:00 UTC	59°14'N, 104°36'W	North Saskatchewan, Canada	No
10	2015/04/21 13:57:00 UTC	40°30'N, 96°9'W	Nebraska City, Nebraska	No
11	2015/04/25 13:40:00 UTC	31°39'N, 93°18'W	Robeline, Louisiana	No

In addition to these 11 completions, we occasionally see aborts of payload runs. The “MARINA Exit Status” telemetry point indicates to us the reason for the abort. The most common values of the “MARINA Exit Status” telemetry point are 0 (Success), 255 (Run in progress), and 1, which is one of 17 error codes. Aborts have been happening more often than expected, an issue we think is due to a timing issue in the code that monitors MARINA while it runs. We recently uplinked a patch such that the code will log more data during each run, which will let us better debug these aborts. Other than delaying runs, these aborts have not had any noticeable effect on spacecraft performance.

For our first imaging campaign (runs 1-5, occurring primarily in February), we were targeting primarily the North pole area, with some runs in view of Ann Arbor to let us monitor the payload as it ran, along with one run at the South Pole to give us baseline pixel brightness levels (since the permanent magnet is aligned such that the imager is facing away from the earth at that location, giving us a dark starfield).

Our next imaging campaign (runs 6-8, occurring in March and April) occurred in parallel with catching up on telemetry downlinks, and thus the runs were less frequent. For this set we had another North Pole run, an Ann Arbor run to check performance after 2 aborts, then a run near the equator to try to get a shot of the earth’s limb.

With baseline payload performance established, we are currently ramping up another imaging campaign, aiming for the best image quality possible. We are currently running approximately daily as we iterate to get a location that’s not too bright.

Once again, we’d like to thank Hams tracking GRIFEX – your continued monitoring has helped us respond quickly to software glitches and keep data flowing. We hope to post more updates as we get closer to an optimal MARINA image.

73,

The Operations Team

Telemetry Downloads Completed

Posted on February 13, 2015 by Charles Lacy

Thanks to Ham operators worldwide, we have completed downlink of the three 1-Hz telemetry runs conducted during early GRIFEX operations (1 Feb 2015 23:29 – 2 Feb 2015 01:56, 3 Feb 2015 00:22 – 05:16, and 9 Feb 2015 02:00 – 04:32). We’ve taken a look at these and some interesting trends emerge.

In all three runs, we see that the battery is near full State Of Charge (SOC) for the entire orbit! Being in full sun all the time has its benefits:

But what about the temperature? Battery temperature is one of the data points we watch most closely on-orbit, as our Lithium-Ion batteries have the narrowest thermal constraints of any of the hardware on the spacecraft (charge temperature 0 to 45 degrees Celsius). We were all relieved to see the battery temperature staying close to 30 degrees Celsius.

Many Hams have noticed the radio temperature going up as we downlink over them, and our adjustments to transmit power level to try to mitigate this. As it happens, we caught a downlink during one of our 1-Hz telemetry runs. At the time of this downlink, the radio transmit power was at ~0.5W:

Looks like FCPU TEMP 1 (directly under the radio’s power amplifier) gets pretty hot! The good news is, the processor inside the radio, along with the Flight Computer itself (FCPU TEMP 0) don’t get the full heat.

Temperatures elsewhere in the spacecraft are hot for humans, but relatively mild for avionics (usually rated to 85 or 125 degrees C). For reference, we’ve included an FCPU temperature from the same time period (no downlinks occurred during this time window) in the plots below. Note for those curious about the acronyms, EPS = Electrical Power System, TCB = Torquer Control Board, FCPU = Flight CPU [Flight Computer])

Looking closely at the EPS module temperatures, you can see a small, short-period sinusoidal trend overlaid on the larger overall sinusoidal trend, presumably due to each input regulation module receiving solar power in turn as the satellite rotates (one input regulation module corresponds to one panel).

Panel temperatures were a wildcard when making these plots. In the earliest 1-Hz run, panel temperatures varied a lot, but mostly tracked the trends of the other subsystems:

However, as the satellite continued to de-tumble, panel temperatures showed greater temperature extremes. Here’s the second run (run #1):

On the 3rd and final run (run #2), the panels got as hot as 60 degrees! This was during a downlink, so this may have been related to the rising radio temperature. However, the fact that other panels were approaching 0 degrees at that time suggests that the orientation of the satellite relative to the sun may have also been a factor. The good news is, temperatures are staying well within a safe range for our bus avionics.

A quick look at bus current draws shows nominal performance. The spikes in 3V3 bus current correspond to occasional spikes in flight computer current draw as it processes data.

Finally, for all you Linux Sysadmins out there, we’ve got a plot of our FCPU load averages. As you can see, collecting 1-Hz telemetry loads our processor relatively heavily as it tries to keep up will all the serial I/O from the sensors.

With this data downlinked, we’ll be switching to MARINA data as the primary downlink content (we started on this right after our first MARINA run on the 11th). We’ll also be downlinking archived beacon data, as we do by default when we don’t have other data products to downlink – GRIFEX saves every beacon it transmits, and we’re trying to get the data from as many beacons as possible to make plots like the above over longer time periods.

We’ll continue to post updates as we downlink data. To all the Hams tracking GRIFEX, Thank You – Your information on satellite status and reception quality has been invaluable, and we’ve been able to downlink significantly more with your support than we would be able to alone.

73,

The Operations Team

GRIFEX alive and well!

Posted on February 1, 2015 by jwc

We are excited to report that GRIFEX is doing well on orbit! Initial telemetry looks great. We are power positive. Temperatures are in good, safe ranges. GRIFEX has also responded well to commands. We are in the process of checking out the spacecraft and making sure everything is working well.

Thanks to NASA and the ELANA program for the great launch. Thanks to the global HAMs providing packets from all over the world!

Here is a spectral plot showing both GRIFEX and Firebird-2 transmissions (FU3).

Spectral plot of GRIFEX and Firebird transmissions.

Last-Minute Client Fix for Python 3 Users (Get it before the first pass!)

Posted on January 31, 2015 by Charles Lacy

With GRIFEX safely on its way to orbit (coverage on facebook), there is one quick fix we need Python 3 users to make to be able to decode GRIFEX beacons. Thanks to early installers, we have discovered that the TCP Serial Redirect script packaged with copies downloaded before today (1/31) may not function when run with Python 3. Our decoding client auto-updater does not update the TCP Serial Redirect script, so Python 3 users may have to re-download the client launcher to get it to work. Alternatively, those willing to dive into the code can change line 114 in tcp_serial_redirect.py from:

self.queue = Queue.Queue() # Works only in python 2

self.queue = queue.Queue() # Works only in python 3

(Yes, these lines are exactly the same except for capitalization).

Python 2 users, and those who downloaded the client this morning (1/31) should not be affected.

Beacon Decoding Client Ready for Download

Posted on January 29, 2015 by Charles Lacy

MXL’s beacon decoding client software is ready for download. This software will let you view the telemetry content of GRIFEX beacons while automatically sending it to MXL’s servers. We are distributing the client through our datasever at mxl-ops.engin.umich.edu. A visual walkthrough of the download/setup process (valid for Windows, Linux, and MacOS) is here: Downloading the MXL Client Application (PDF, 630kB).

If you encounter any bugs or difficulties, please email MXLab-HAMs@umich.edu and we’ll try to respond as quickly as possible. Updates to the client will be distributed automatically unless otherwise posted here.

Screenshot of Beacon Decoding Client v1.0.1 on Ubuntu 12.04