The Rocketometer flew into space on 21 October 2013, on board NASA sounding rocket 36.290. The following are notes on its performance, including any glitches or other things to be corrected on the next flight

General

The Rocketometer performed as designed during the flight. It was able to record inertial readings once every 3ms throughout the flight. I have to look pretty hard to find anything which didn't go according to plan.

The device was installed with -Z in the direction of powered flight. This was unexpected, but caused no problems. It's a good thing I wrote the vertical test to check for both directions, no Genesis sensor problem for me.

Card reading

I tried reading the card in my laptop Natsumi, in Linux mode. In order to insert it there, I put it in a microSD to normal SD adapter, with the write-protect switch on the adapter set to lock. The card failed to read in this mode. I then put the switch in unlock, and initially it didn't read that way either. It seemed like it either just took a long time to mount, or that the video-copying I was doing simultaneously was interfering with it. Anyway, I eventually saw it as /dev/sdc1, started doing a dd dump, and about half way through that, the device automounted and I could copy files normally.

Magnetometer

The magnetometer was able to see the Earth's magnetic field through the skin of the rocket and the various cases and boxes between it and the external field.

I had assumed without looking closely that the sensor registers in the HMC5883 were in order, and wrote the code accordingly. Upon getting the data, the "x" and "z" axes were showing spin, when I expected the x and y axes to show the spin around the Z axis. Closer examination of the HMC5883 data sheet shows that the registers are in XZY order, not the expected XYZ. In order to maintain compatibility, the magnetometer packet is now documented to be in XZY order and will not be changed. Code is changed such that it catches the Y and Z axes in the Y and Z variables, in case any on-board systems wish to analyze the data. Any change in the packet to write XYZ ordered data will be done with a new APID.

The device is capable of readout at 100Hz or more. Design performance was one compass read every 20 inertial reads. Actual performance achieved that, with a read every 60ms, except one sample in every 7 was delayed, only reading after 111ms. This has to do with the fact that the compass and pressure sensor were not in phase with each other. The code as originally designed had a phase variable incremented once every inertial read. It was checked (phase%20==0) for the appropriate phase to fire the compass reading, then checked and reset whenever the pressure sensor was read. This happened at such a rate that effectively every 7th reading was delayed, since the phase got reset at the wrong time.

Future code will have an independent phase for the compass and pressure sensors, and will read the sensor closer to its capability.

The hard iron effect was of such a magnitude that the sensor readout ellipsoid did not even contain the zero vector. The hard iron offset appeared to change in a step on at least one axis during reentry, near 575 seconds after launch. There is significant soft-iron distortion of the ellipse as well.

Analyzing hard and soft iron is roughly equivalent to finding the center and size of an ellipsoid that fits the measured points. We use the ellipsoid_fit routine which finds the principal axis unit vectors, radii, and center of the best-fit ellipsoid. The center is directly the hard iron distortion in DN. The principal axis unit vectors and radii are used as eigenvalues and eigenvectors, and the matrix which has those eigenproperties is found as follows:

[A]x⃗ =λx⃗ [A]x→=λx→

[A][x⃗ 0x⃗ 1x⃗ 2]=[λ0x⃗ 0λ1x⃗ 1λ2x⃗ 2][A][x→0x→1x→2]=[λ0x→0λ1x→1λ2x→2]

[B]=[λ0x⃗ 0λ1x⃗ 1λ2x⃗ 2][B]=[λ0x→0λ1x→1λ2x→2]

[X]=[x⃗ 0x⃗ 1x⃗ 2][X]=[x→0x→1x→2]

[A][X]=[B][A][X]=[B]

[A]=[B][X]−1[A]=[B][X]−1

This matrix [A][A] directly converts a unit vector magnetic field into a point on the ellipsoid, and it does so in a manner without rotating the ellipsoid, because of the eigenvectors. The eigenvectors are scaled straight out to the ellipsoid, with no rotation.

Since the field strength changed during the flight as a result of altitude change, all the measurements don't really fall on the same ellipsoid, but one which varies with field strength. We will ignore this. The Kalman filter will carefully run the WMM2010 code to get the field BIBI in nanoTeslas, then convert to DN by multiplying by the A matrix above:

B⃗ body=q′rbB⃗ IqrbB→body=qrb′B→Iqrb

B⃗ DN=[A]B⃗ body+B⃗ hard,DNB→DN=[A]B→body+B→hard,DN

The measured hard and soft iron during the flight between t=0t=0 and t=575t=575 is then:

B⃗ hard,DN=⎡⎣⎢⎢843.15455−1139.8037603.84026⎤⎦⎥⎥B→hard,DN=[843.15455−1139.8037603.84026]

[A]=⎡⎣⎢⎢12567.9128058990−1062.4357595761139.1144904110−1062.435759576110553.3281864438420.3887030047139.1144904110420.38870300477970.6607032257⎤⎦⎥⎥10−6[A]=[12567.9128058990−1062.4357595761139.1144904110−1062.435759576110553.3281864438420.3887030047139.1144904110420.38870300477970.6607032257]10−6

RGB Light and blinklock

This is one that I was worried about before the flight. The RGB light is blinked in order to show that it is working - one of the colors is turned on when a sector is written to the card, then back off when the next sector is written, then the next light is on with the next sector, etc. At high rate recording, the light blinked faster than a human could count, while at low rate, it blinked at about half-second on, half second off.

If there was an error, the device went into blinklock. This blinked out an error code, with a red light representing a zero bit of the error code, and a green light a one bit. A blue light indicated the end of the number. This is a problem because error code 2 looks like a slow blink rate for the low rate recording. The blink lock is slower, but hard to recognize if you aren't used to seeing both. Further, it was a blink lock, which meant that the device would do that forever without attempting to reset itself.

Next mission, the light will blink red for errors, with a zero bit indicated by a 1-second light and a one bit by a 2-second light. Blue light again for end of code. The normal write pattern will not blink the red light. This way, if you see green, things are good. If you see red, things are bad. The device will blink the error code out twice then reset itself.

Timing

The 60MHz clock is used as the nominal time reference. This is converted and wrapped using the fix_tc function to provide a time for each packet relative to the restart of the device. According to that time scale, the last undisturbed accelerometer sample before the flight was the last sample before 2019.0 seconds exactly, and the next sample was after that time, so launch time on the device clock is considered to be 2019.0s exactly.

Several sharp events were seen in the inertial data, such as detach of stages and other parts. Also, the time of external power disconnect was recorded by the device. Correlation of these visible sharp events with the actual mission timeline will provide correlation of the device clock with UTC. In particular, it looks like the board was powered up 2019 seconds before flight (thus t0 is this value), then had power cut at 1139.629s before flight. The device ran on internal power until 852.622s before t0 and was cut off again in flight (as expected) at 585.445676 seconds after t0.

Touchdown occurred at 933.943 seconds after first motion, as reported by the low-scale accelerometer. Touchdown was rather gentle, never saturating the low-scale measurement. The payload had fallen over completely by 935.314s, and came to complete rest at about 941.4s

Inertial sensor calibration

The inertial sensors experienced a substantial time in weightlessness, from about 130 to 470 seconds after launch. During this time, the mean rotation speed of the payload was one revolution per year since it was pointed at the sun. This was around ecliptic north, but the payload Z axis was perpendicular to this and the mean rotation speed around that axis was precisely zero.

The temperature of the sensor went from ~700DN to ~1300DN during the weightless portion, in a linear fashion. It is basically impossible to distinguish linear trends vs time from linear trends vs temperature under these conditions. However, the part includes a temperature sensor for a reason, so we will presume that the weightless value is a function of temperature.

Consider that the slopes have to be multiplied by the ~1000DN temperature range that the part saw. MAZ varies by 4DN over that much range, MGX by 1DN, and all the rest are less than 1DN over that range.

In a very real sense, the majority of the calibration of the Rollercoasterometer by the Rocketometer is accomplished with this table. This is over 50% of why I put a Rollercoasterometer into space.

Initial conditions

The launcher is at 106.320160°W, 32.417995°N, 1209m above the WGS-84 ellipsoid. The initial velocity is moving with the surface of the Earth. The initial orientation is determined with the accelerometer and compass, except for the problem of significant distortion of the compass reading by the steel in the launcher. The accleration used to determine local vertical must be taken when the vehicle is not moving. Examination of the compass data shows that the external distortion is gone by 1.0 seconds after launch, while the vehicle has rotated very little (less than 2°) by this point. Therefore we can use point-toward, pointing the sensed acceleration at the local gravity vector before launch, and the sensed magnetic field toward the modeled field from WMM2010 1 second after launch, presuming that the vehicle orientation is the same in both instances.

The sensed magnetic field 0.974456s after launch is

B⃗ b=⎡⎣⎢⎢28564.7076367.164740336.593⎤⎦⎥⎥B→b=[28564.7076367.164740336.593]

There is an approximately 10° mismatch between the field reported by the compass and the launch elevation and azimuth reported in the radar data. So, what we are going to do is run the filter with only the radar data to determine position and velocity, and using the compass and gyro sensors from the flight only -- no acceleration in this pass.