Freesteel Blog » Flightlogger

Friday, December 30th, 2016 at 9:44 pm - - Flightlogger 1 Comment »

Not been taking time to blog much. I have been lost in a vast pool of non-working projects, and trying to learn scipy and pandas and jupyter, which is an effective replacement for twistcodewiki, which itself was derived from Scraperwiki. The in-browser interactive programming environment Jupyter is everything that Scraperwiki was supposed to have become (eg see data journalism example). But that didn’t happen because every other software engineer I knew assured me in No Uncertain Terms that nobody was ever going suffer the sheer excruciating pain of coding in the browser — when real programmers all want to use vi and git.

But I digress to a world where practically all of my coding is in the browser and I’m using tools like matplotlib at a cycle time of around 10 seconds, which is about a quarter of the time it takes to lose any image file you have generated somewhere on your goddamn disk!

Today I put my new hang-glider data logger (which is held together with lots of glue) into the floor of the elevator and recorded the accelerometer in Z sampling at 100Hz.

azacconly

With my new powers of filtering

b, a = scipy.signal.butter(3, 0.005, 'low')
pZ["fz"] = scipy.signal.lfilter(b, a, pZ.az)

we can get this:

azacconlyf

The art of using sensors is to use a set of them in order to access the underlying reality.

Here is the raw barometer reading as the elevator goes up and down several floors.
baroonly

Once again it’s a good idea to filter it, only this time we set the frequency of that butterworth filter to 0.01 instead of 0.005 because the barometer readings are at 50Hz, and we need the time delay from the filters to be comparable.

baroonlyf

Because it’s nice and smooth after filtering, we can differentiate it by differencing it, using the pF[“df”] = pF.f.diff()*50/10. The times 50 is because it’s at 50Hz, and the divide by 10 is to convert from barometric readings to metres (approximately). The scale is metres per second, and metres per second squared. The elevator travels at about 1.5m/s. The section on the right with the green line lifted for 12 seconds was traveling down about 3 floors at once, so the air pressure was constantly rising.

dbaroacc

Acceleration is the differential of the velocity, so setting ddf = df.diff()*50 gets us the following plot:
ddbaroacc

What we now see are just horrendous oscillations in the barometer. Every time you differentiate you magnify the noise.

But we can reduce the lowpass frequency of this filter by a factor of 5, so it’s 0.001 for the accelerometer and 0.002 for the barometer, and get a curve that agrees (where all the scaling seems to work out without any fudging).

ddbaroaccf

The problem now is you can’t see the elevator moving between the different floors at all. What are those barometric oscillations from? Was I breathing too hard?

Let’s plot the barometer differences against the filtered barometer differences.
dbaronof

There’s a little too much noise, so filter the barometer difference by 0.1 instead and plot it against the 0.01 filter.

dbaronof1

No, I can’t see those oscillations in the underlying data either.

To my eyes they only start to spike up with a filter low pass frequency of 0.03.

dbaronof3

So I’m pretty stumped. But now I’ve got my eye on it, I can see a slight waviness at about this frequency in the original barometric reading in the third picture from the top, so it’s not an illusion or a creation of this filter.

If I hadn’t just glued my entire unit together I might have separated just this device out to see if it’s caused by yet another oscillation in the circuitry, like the kind I’d seen on a temperature sensor.

Maybe I’ll have to rerun this elevator experiment with all the other sensors turned off as much as possible to see if I can get the the bottom of this mysterious 4 second oscillation in the barometer.

Then there’s the temperature decay curves to sort out (from the use of a hairdryer this morning), which are not as good as I had hoped.

I am pleased to have finally implemented an AB Butterworth filter on my arduino.

It’s not a big deal. The code is roughly as follows, and you can get the a[] and b[] arrays from SciPy by executing the function scipy.signal.butter(3, freq, ‘low’):

class ABFilter
{
    float* a, *b, *xybuff; 
    int n, xybuffpos; 
}

ABFilter::ABFilter(const float* la, const float* lb) :
    a(la), b(lb), n(len(la)), xybuffpos(0) // len(a) == len(b)
{  xybuff = (float*)malloc(2*n*sizeof(float));  }

float ABFilter::filt(float x)
{
    xybuff[xybuffpos] = x; 
    int j = xybuffpos; 
    float y = 0; 
    for (int i = 0; i < n; i++) {
        y += xybuff[j]*b[i]; 
        if (i != 0)
            y -= xybuff[j+n]*a[i]; 
        if (j == 0)
            j = n; 
        j -= 1; 
    }
    if (a[0] != 1)
        y /= a[0]; 
    xybuff[xybuffpos+n] = y; 
    xybuffpos += 1;
    if (xybuffpos == n)
        xybuffpos = 0; 
    return y; 
}

Saturday, September 24th, 2016 at 1:51 pm - - Flightlogger

I’ve been flying around with my data logger for two years now and I have only this week developed a theory of how to process the temperature data. I might have got to it sooner had I known enough physics or bothered to test the actual response time of my Dallas temperature sensor, which was so abysmal I had to start doing something about it. To be fair, it did take me over a year to even shelter it from the sunlight.

Part 1: The responsiveness of the temperature sensor is 0.09

The apparatus involved running a vacuum cleaner against the sensor housing to create a fast airflow while drawing the air either from the room or down a tube containing a bag of ice.

vacuumapparatus

This was the graph it made, holding the intake near the ice and away from the ice for about 40seconds at a time
temptubeiceupdown1

The curves you see are exponential decay curves, as the temperature sensor cools to the air cold temperature, then warms to the room air temperature, quickly at first, and then slowly as it converges.

(more…)

Thursday, July 28th, 2016 at 11:25 am - - Flightlogger, Hang-glide 1 Comment »

I don’t know which direction to go now, so I did a quick bit of video editing of a flight in Italy. I got plans to write this story up in more detail if I can get over the writers block that’s making it difficult even to complete my logbook.

I am losing control over direction. I should be running the machine tool on something, to keep it oiled. But then there is the GroundWindow app that I’m converting to work in Yorkshire with the cave data we have there. And also analyzing my flight logger data, which I seem to put hundreds of lines of code into a week, but continues to get nowhere. It’s strange.

The WebGL situation with GroundWindow is diving into a real rabbit hole. I have long known I needed to learn how to code GPUs, but could never find a way in. GPU technology, as I have observed, makes much of the software engineering I have done over the years entirely redundant.

Last week I spotted that the genius who made the early webgl water demo I’ve been hawking around to prove my point finally written a blogpost about one small aspect of the demo.

In it he referred to another blog about the GPU graphics pipeline (written in 13 parts), that I am trying to work through. I’m getting about 50% of it at most.

The question then comes down to whether there are any meaningful new machining algorithms that can be built based on this technology, using OpenCL or whatever, because that’s one of the few things I am uniquely qualified to research better than most — even if I can’t persuade someone with a budget to pay for it.

That’s just normal stupidity and mis-allocation of capital by those in control of developmental budgets.

For example, let’s take the massive public engineering program called Trident just authorized by Parliament this month to build four nuclear powered submarines to provide that essential round-the-clock service of threatening indiscriminate annihilation to targets unknown at a few minutes notice.

Now some MPs believe that investing in high technology is good merely for the sake of it, like Toby Perkins, who said in the debate:

The most depressing exchange was with representatives of the GMB union in Barrow [where the submarines are built], when… [the MP] for Islington South and Finsbury suggested that they might like to make wind turbines instead. They politely but firmly informed her that they were involved in designing and producing one of the most complex pieces of technology on the face of the earth, and that wind turbines had already been invented.

Setting aside the fact that nuclear submarines have already been invented too, the difference is that wind turbines produce electricity, which has value. Military nuclear submarines, on the other hand, have no return on investment. They are not put for up sale as part of the international arms market to foreign dictators (and you won’t get away with selling used ones to Canada again). The subs are not applicable to a modern resource war, like the invasion of Iraq where the plan was to win the wealth back by stealing their oil, because the victims don’t have navies. And there is no program for technology transfer, given that the nuclear power industry has been entirely outsourced to France on a strategic level

In fact all the engineering being budgeted for this program is wasted and will be subtracted from the engineering brains available nationally, just when we need them most and the availability of immigrant engineers is going to be choked off.

Nuclear war, in terms of the way the politicians handle it, is worse than low-grade Science Fiction. So at this time I picked up the 1964 Heinlein post-apocalyptic novel Farnham’s Freehold, where an all-out nuclear war blasted the Goldwater republican right-wing Americans (with the same mind-set as the author) two thousand years into the future from their private fall-out shelter. Here’s one of the characters in the future civilization looking back at the recorded history trying to interpret the events:

The war itself he didn’t find hard to believe. He had experienced only a worm’s-eye view of the first hours, but what the scrolls related matched the possibilities: a missile-and-bomb holocaust that escalated in its first minutes into ‘brilliant first strike’ and ‘massive retaliation’ and smeared cities from Peking to Chicago, Toronto to Smolensk; fire storms that had done ten times the damage the bombs did; nerve gas and other poisons that had picked up where the fire left off; plagues that were incubating when the shocked survivors where picking themselves up and beginning to hope–plagues that were going strong when the fallout was no longer deadly.

Yes, he could believe that. The bright boys had made it possible, and the dull boys they worked for had not only never managed to make the possibility unlikely but had never really believed it when the bright boys delivered what the dull boys ordered.

Not, he reminded himself, that he had believed in ‘Better red than dead’–or believe in it now. The aggression had been one-sided as hell–and he did not regret a megaton of the ‘massive retaliation’. [Chapter 14 p190]

Two things: Being ‘red’ is actually a temporary phenomenon (unlike radioactive and dead). Just ask the East Germans.

Secondly, the Cold War was stoked and prolonged by the dull boys in America, from their endless lies about the missile gap, to their intrusive U2 surveillance flights across Soviet airspace that utterly wrecked the four powers peace summit that had been scheduled to de-escalate the Cold War in 1960.

Ironically, those U2 flights were collecting intelligence that proved there was no missile gap whatsoever, yet the President and Presidential candidates continued to lie about Soviet capabilities to paint their political opponents as “weak on defense” in the forthcoming election.

It’s the old game of elites clinging to power by scaring the bejeezus out of the public, and then offering dangerous answers that don’t work, and successfully displacing consideration of the real problems at hand that require solutions they don’t want anything to do with.

The problem with our thinking is that future exists only in the human mind, and we are not carefully discriminating between the challenges ahead that are entirely within the various states of mind, such as the threat of war and the causes and consequences of property distribution and financial debt– and challenges out there in the physical world that are not going respond to any of our puny beliefs, like climate change and the polluting energy systems in the modern world.

In a sane world the Committee on Climate Change would get the £200billion engineering budget to start building the stuff we need now, like tidal barrages and CCS, and the nuclear warriors would instead sit in smoky committee rooms writing strategic reports on paper and getting sent off to international conferences to sign treaties– in other words do the sorts of things that would solve those problems completely.

That’s the way round it should be. But it’s like we think we’re looking through a window on the future, and instead it’s just a mirror reflecting the past behind us. And this would be fine, if it weren’t for the point of reality that time does not in fact run backwards.

Friday, May 27th, 2016 at 12:07 pm - - Flightlogger

The datalogger is fitted to the right hand upright of the control frame. According to my shoddy measurements the upright is 176cm long and the basbar is 138cm long. There are two wires from the corners of the control frame to a point on the keel 151cm forward, each of length 206cm. And there are another two wires to a point on the keel 80cm backward, each of length 205cm.

This seems to add up to a vector of (69.0, 42.06344442205491, -156.2492943010685) from the top of the control frame to one corner of the base bar, which is the alignment of the datalogger and its BNO055 orientation sensor strapped to the upright.

I definitely don’t have time for a complete blog record of this, and a lot of it isn’t working, even though I’ve spent no end of time hacking on things, but if I plot the logger vectors that go backwards and perpendicular to the upright on the gps track, I get this picture:

keelorientation

For scale, the red lines are 11m long and the plot rate is 3x on the 100Hz samples, so there are 33 of those lines per 1second of motion.

It’s reasonably smooth and consistent, unlike the accelerometer values, which I think represent a lot of vibrations in the system, if the creaking wicker chair-like noise on the gopro soundtrack is anything to go by. It’s about right, if you think of the airspeed being in line with the keel of the glider (which it is probably not, because of the yawing and side-slipping in turns).

I nearly bought a sonic anemometer second hand off ebay last week, but missed it. I’ve got an alert watch on a new one and have designs on fitting one to the top of the kingpost where it is out of the way and least likely to get damaged by flying into a hedge or the ground.

Regarding the kinematics of the system, every part of the flight is the same as everything else, so I can strip out the simpler bits to see if there is a relationship. In particular, this is a plot that claims to be 10 second long sections of the flight where the bank angle is less than 3degrees.

nobanksections

This doesn’t fit too well, and I can explain it that the calibration value on the device was at 1 out of 3 for most of the flight, in spite of starting off on the ground at 3/3, so it’s telling me it got it wrong.

Anyway, it’s straight enough to move on to this complex plot of some of those flight sections:

pitchsections

Time goes from left to right of about 10 to 20 seconds. The following traces have been displaced close to the zero horizontal white line so you can see their correlations, if any. Green is pitch angle, Yellow is smoothed acceleration in forward direction (approx because it’s not aligned with gravity yet), Red is airspeed, and White is differentiation of windspeed.

What I would hope for is a delayed correlation between pitch (green) and airspeed (red). If you push the nose up and hold it there, the glider will slow down, and then fly at a slower speed. If you pull the bar in and hold it there, the glider will speed up and then fly at a constant higher speed. But of course you’re moving the bar all the time. But you can almost convince yourself of the response; the green line goes down, and the windspeed then starts to rise, and vice versa.

This should be built this into a kinematic model of control and response. It would actually also align with the barometric reading, where the sink rate goes up with a higher speed, so it’s quite 2 dimensional in the vertical plane, with energy equations.

The other correlation should be between the forward acceleration and the derivative of the airspeed. Both the airspeed signals and the acceleration signals are quite full of noise, so they needed to be smoothed (I think I’ve done this incompetently here, but that’s for another fortnight of coding).

Here you would expect a direct correlation in still air, because if the accelerometer says I am accelerating at 1metre per second per second, then over the course of 2 seconds my absolute velocity will increase by 2 metres per second. And, if the air is still, then my measured air speed should also increase by 2 metres per second.

So these two ought to be scaled the same. Except the smoothing flattens out all the humps and troughs, so you really can’t tell what the absolute value of anything is from this anymore.

Some of the bumps seem to line up, but this is not adequate for a kinematic model.

The numbers get hairier and hairier as I try to approach something useful. And that useful thing would be to separate the absolute motion into that which is due to my control and the flight characteristics of the glider, and that which is due to the underlying wind speed and direction.

Accordingly, I should be doing lots of boring flights in completely still air at the start of the day with a working logger where everything is calibrated, rather than having lots of fun in thermic air. This is a job to do in Austria where the hills are high and I should have hours and hours in the campsite not coding on other things.

This work just takes so much time and has hit so many technical failures already that I doubt it could be done by someone who is answerable to a boss.

Monday, May 9th, 2016 at 4:49 pm - - Flightlogger

I made an interesting mistake during my flight over Merthyr which began in very rough air. My radio was charged and working, which meant I had an external source of misinformation to confuse me, that I did not have on my excellent flight from Builth Wells three days before.

One of the things I thought I overheard was that the thermals were tracking southeast in spite of the wind on the hill coming from due west. This suspect information lodged into my brain, so that when I finally got a good thermal I began tracking to the SE instead of due East with the wind, and fell out of it, and landed an embarrassing 5km away to the SE on a smooth bit of grassland feeling rather unhappy with myself.

Still, nothing important broken, except my ego. The data came out good, with the following temperature track vs altitude, where horizontal lines are degC from 0, vertical lines are 100m (topping at 1200m on the right), and green data points are during the climb, with red for the descent.

merthyralttmp

Potentially this means in such a strong thermal the temperature was one degC higher than the surrounding air, with brief drops in the readings in the moments where I fell out of the thermal. The climb rate up to 1000m was between 2 and 4m/s, but above that it became less than 1m/s — coinciding with period the temperature differential had decreased.

The thermal temperature is going to be all mixed up with rising air and surrounding air as I go in and out of the core, but it seems to have a pretty constant trend. The non-thermal air (encountered when I utterly lost the thermal) seems to be completely constant between 1000m and 1100m, which would account for the decline in thermal strength (according to theory) and at 1050m only differed by 0.3degrees.

Unfortunately, with only one thermal in the flight to derive the data from, the pattern is not definite. I think I should do something more serious with the temperature sensor, like fit a cowl over it to protect it from sunlight while directing the full flow of the wind across the device. It cannot take more than seconds to equalize. I ought to revisit my vacuum cleaner and hairdrier experiments.
(more…)

Thursday, May 5th, 2016 at 4:29 pm - - Flightlogger

I must have changed cards for one in an old camera or something, because the data files went bad on the hang glider logger.

What started out as an effort to plot a timeline of the holes in my data has turned into a simple SD card write benchmarking experiment which allows me to see the slippage.

The code sort of goes like this:

int multiple = 200; 
long biggaptime = multiple*2; 
long sumnormaltimes = 0; 
long nnormaltimes = 0; 
long flushmultiple = 1000; 
void loop()
{
    // wait for the next 200microsecond moment
    long mstamp; 
    long mstampnext = ((int)(mstampprev/multiple + 1))*multiple; 
    do {
        mstamp = micros(); 
    } while (mstamp <= mstampnext); 
    
    // output the microsecond value in 8 hex characters
    for (int i = 32-4; i >= 0; i -= 4)
        sdfile.write(hexchar((mstamp>>i)&0x0f)); 

    // if that write took longer than expected, record how long
    long mwritetime = micros() - mstamp; 
    if (mwritetime > biggaptime) {
        if (ngapsline < ngapslineP) {
            PRINT(" ", mwritetime, ".", nbytessincegap); 
        }
        nbytessincegap = 0; 
        ngapsline++; 

    // otherwise keep track of the average time
    } else {
        sumnormaltimes += mwritetime; 
        nnormaltimes++; 
    }
    nbytessincegap += 8; 
    
    // flush at a defined multiple of looks
    n++; 
    if ((n % flushmultiple) == 0) {
        sumnormaltimes = 0; 
        nnormaltimes = 0; 
        long mstamppreflush = micros(); 
        sdfile.flush(); 
        long mstampflushtime = micros() - mstamppreflush; 
        P(" F", mstampflushtime); 
    }
    mstampprev = mstamp; 
}

This produces output like this:

1085.0 17500.320 2926.512 2906.512 2912.512 3574.512 2925.512 2914.512 2912.512… (33.89)
10000 215737 F7575 994.320 407194.192 4632.512 2915.512 2943.512 2920.512… (33.89)
15000 407211 F7601 1104.384 3279.128 4400.512 205153.512 2916.512 2920.512… (33.82)
20000 207194 F7576 1018.448 3255.64 4535.512 2915.512 2916.512 204380.512… (33.80)

One can interpret it as taking on average 34microseconds per 8 byte write block, with a pause of 3milliseconds after every 512 bytes, and then an enormous 205millisecond pause after every 8*512=4096 bytes. The call to flush() takes 7.6milliseconds.

We can plot the timeline of writes with this function:

ftext = open(“SPEED.TXT”).read()
ts = [ int(ftext[i:i+8], 16) for i in range(0, len(ftext), 8) ]
t0 = ts[-20000]
sendactivity(points=[((t-t0)*1e-6, y) for t in ts[-20000:]])

to get the green series of points labelled 1 in the diagram below (where the yellow vertical lines represent one second increments):
badsdcards
(more…)

Thursday, April 28th, 2016 at 12:04 am - - Flightlogger, Hang-glide

Well, the hang-gliding has been quite lovely. But the logger appears shot to pieces.
cloud
I still don’t know what I am doing when I get to cloud-base, which is probably why I plummeted out of the sky shortly after this picture was taken.

As soon as I took off, the barometer stopped communicating most of its data.
badbaro
This is the device I lavished so much time on isolating it from the rest of the electrical circuit and arranging for it to bitbash the information back through an interrupt pin.

It could be some timing issue, or whatnot. No way to debug it. Luckily I got myself a Bluefly vario which does the same thing of reading a MS5611 barometer on a tight 50Hz loop and transmitting it back to the main board. In the Bluefly’s case it’s for the purpose of running a Kobo/XCsoar system. I’ve just given up on the one I built as it’s too inferior to simply running XCSoar on the phone where I’ve got colour and more or less know how to use it.

Luckily the Bluefly also sports a GPS and works through a serial port, so I’ve yanked off the Adafruit GPS breakout board and bodged the wires to insert the Bluefly in its place.
bfbodge
Then there was a small matter coding it up using a complex state machine to program the GPS module through the Bluefly pic processor to get it to read at 10 times a second.

But then the BNO055 orientation sensor played up and decides to shutdown at unexplained moments for unexplained periods of time.
badorient
The white vertical lines are 10 minute intervals, and there is a green dot for every successful orientation reading, with y-value proportional to the time since the previous reading, so I’m getting gaps in the data of half an hour in flight.

I’ve produced a reset timer to try and start it off again if no data comes through for 20 seconds.

Anyways, here is one of those nerve-wracking close encounters with the ground during the flight.
(more…)

Tuesday, April 5th, 2016 at 1:04 pm - - Flightlogger

On this second day of heavy rain in the Pyrenees I think I might have the time to catch up some ancient history from all of last week. We waited five hours on El Bosque for the wind to come right, and were then rewarded with this flight with vultures.
bosquevultures
These birds came much closer than they ever showed up in the pictures. They fly with hunched shoulders.

Unfortunately the GPS for that flight is inexplicably jagged, so here’s a flight above Teba from a day later where the data is cleaner.

teba1

gpstrackteba

The yellow cube is 1000m on each side for scale from a flight that took off at the point on the frontmost vertical cube edge

gpstracktebazoomed
Here’s a zoomed in section of the left most section of the path, shown looking down, with 100m XY axes in yellow. The track comes in from the bottom right goes to the top left (against the wind direction), then turns left to make four anticlockwise loops that drift back with the wind
(more…)

Tuesday, March 29th, 2016 at 9:28 am - - Flightlogger, Hang-glide

It happened towards the end of the flight before last when my wings became my own, and I just wasn’t thinking about it any more. I stopped having those intervals where I lose concentration and fall out of the sky because there was no concentration to lose. It was all about the feeling.

teba1
Above the town of Teba watching the cars scooting along the grid of streets like busy beetles in a rotten log

teba2
Low on same rocky hill just after take-off where I struggled to survive for some minutes before I found a bubble of rising air

If you need to learn hang-glide, there’s a English school down here called Lejair where you could get it all done in two weeks (instead of the average two years of weekends back in England) because the weather is better and they use tow trucks with gliders tethered above a trailer so you can learn how to fly it without having to run up and down the hill and learn how to steer in short difficult bursts. (If you have to ask why you need to learn hang-gliding, then you don’t need to.)

birdscage
We were woken by all this nice birdsound. Then we spotted that it was from three tiny birdcages in the courtyard below and it seemed so cruel. Why can’t they use little speakers tuned to a radio channel that broadcasts live birdsound?

Got to go now. We’ve not had an off-day where I can devote 10 straight hours to coding the datalogger analysis or write any of it up. I have two interesting results to report. One being the delay on the GPS, and the second being the clean mathematical relationship between the turning circle and bank angle as measure.

Wednesday, March 23rd, 2016 at 6:16 pm - - Flightlogger

Final late blog of the day.

An end-to-end design in Kicad all by myself, which was then cut out beautifully on the triangle machine tool.

hgcircuitkicad

dcirc2

Soldering, laser cutting and 3D printing took up the following week, and it should now small enough to fit onto the glider without getting in the way.

(Tom’s trick of defining a virtual second side of the board which we don’t actually cut, but instead implement with jumper wires worked a treat.)

dcirc1

We’ve got the questionable barometer, GPS, humidity, 2 temperature sensors, wind meter and an absolute orientation sensor (at the top) all logging at high frequency to an SD card and with an OLED screen to show me what’s not working so I can fix it in time. The black slab at the bottom holds 4 AA cells.

First thing that got logged was my fridge over last night using a string of 5 temperature sensors left over from Housahedron days:

fridgelog5

It’s the most boring high efficiency fridge in the world with a cooling cycle of four hours and, not surprisingly, different temperatures on each of the glass shelves.

I’m wondering if the new microbit device, of which a million will be distributed to children, has enough tech in it to use as a fridge logger. Everyone has a fridge. This would make an easy project for kids to log and upload the data of their make and model to a common place in order to find where the crappy fridges are. In the future they need to all be found and replaced, because they cost significant energy and CO2, but nobody knows since the electricity bills are aggregated for all appliances in one house and are mostly unknown.

For contrast, here’s an overnight log (interrupted at 4am in the morning for my host to get up and drive to London) of a fridge in Leeds using a different datalogger where the cycle is four times an hour:
peacheytemps1
I can’t explain the long hiccup at 3am where it skipped 3 cycles. Maybe there is a lot of information in that particular curve, such that the real way to find out about the quality of the fridge is to turn it completely off and measure how warm it gets overnight. Great idea. I can see a lot of kids getting into trouble over that one when the food is all spoiled. To which they can respond: “Hey look, it’s only the fridge. It’s not like I’ve done it to the whole planet.”