Freesteel Blog » Machining

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

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.


With my new powers of filtering

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

we can get this:


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.

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.


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.


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

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).


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.

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


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.


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.


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

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.


Saturday, August 13th, 2016 at 12:23 pm - - Machining

I’ve been getting some machining done, found out what worn out tools are like when you try to use them, and bought a whole load more.

We’ve also been doing some important work controlling servos directly from the Beagleboard through an H-bridge which will allow us to bypass the conventional servo motor drive setup that prevents all positional feedback information.

You can see the varying width modulations on the scope here:


The code, compiled from C and deployed on the programmable realtime unit, varies the pulse width every cycle thus modulates the amplitude like a class D amplifier.

The music, in the second half of the above video, isn’t well picked up by the phone microphone, although it sounded surprisingly good in reality.

This is almost all the PRU code responsible for reading the channels (pairs of numbers that are wavelength and amplitude) and setting the PWM width per cycle.

struct Commondata {  unsigned int notes[NOTECHANNELS*2];  };
volatile near struct Commondata commondata __attribute__((cregister("PRU_DMEM_0_1", near), peripheral));

int main() 
  CT_ECAP.ECCTL2 = 0x02C0;
  CT_ECAP.CAP1 = 4096;    // PWM clock period
  CT_ECAP.ECCTL2 |= 0x0010;

  long channelcounts[NOTECHANNELS];
  for (int i = 0; i < NOTECHANNELS; i++) 
    	channelcounts[i] = 0;

  int mid50 = CT_ECAP.CAP1/2;
  int guardlo = mid50/8;   // clock range safe to change
  int maxamplitude = mid50 - guardlo;


    int waveamp = 0;
    for (i = 0; i < NOTECHANNELS; i++) {
      if ((pid.notes[i*2] == 0) || (pid.notes[i*2+1] == 0))
      channelcounts[i] -= 16;  // granularity of steps per PWM cycle
      if (channelcounts[i] < 0)  // countdown crosses zero, set wave back up
        channelcounts[i] += pid.notes[i*2];

      // calculate sawtooth wave amplitude within period
      int amp = (pid.notes[i*2+1] * channelcounts[i]) / pid.notes[i*2] - pid.notes[i*2+1] / 2;
      waveamp += amp;   // sum up the amplitudes

    // attenuate rather than truncate
    waveamp = waveamp*maxamplitude/(abs(waveamp) + maxamplitude);

    // wait till we are outside of the lower values of the clock
    while (CT_ECAP.TSCTR < guardlo)
    // wait till the clock has ticked over (but hasn't counted above 100)
    while (!(CT_ECAP.TSCTR < guardlo))

    // set the next duty cycle length (safe as value greater than guardlo)
    CT_ECAP.CAP2 = waveamp + mid50;

It's about 50 times less code and effort than I thought it was going to be, mainly due to the use of the PWM subsystems, rather than attempting to generate timed PWM in realtime from the PRU code. This could only have been possible were I authoring the assembly code directly instead of using a compiler, because only that way can you count the cycles. This is a good move because, while it would have been fun to write carefully hand-coded division routines that used a fixed amount of processor cycles, it would have been a waste of my time. This way we're simply using the PRUs as co-processors that we assume are running fast enough to service those other subsystems in the chip.

The other subsystem we need to read are the quadrature encoders in order to drive the motors to a given position -- and read what position they have been dragged to by other forces (like human hands).

This is the current state of the project plan to get to a milling machine that responds to cutting forces with changes in toolpath trajectory (which requires the abolition of G-code).

It's all about us keeping an eye on where we are trying to get to, picking the route to it that takes us across the known unknowns in a way that exposes us to maximum learning, and then cutting corners (eg by further bodging the circuits we already have).

I couldn't do this if I had to explain, repeat and clear every change of plan with a boss who was remote to the project.

On the other hand, if we did have a boss maybe we'd get there at the same rate on account of a lot fewer holidays per year.

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, June 17th, 2016 at 1:48 pm - - Machining 1 Comment »

What was that horrible noise coming out of the closet at DoESLiverpool for about three days?

I was attempting to machine down one of these hold-down clamps so it could fit the 70mm wide type 2 vice I’d bought recently.

My earlier attempts to clamp the vice down on two points failed when the bolts rattled loose and the whole thing started being dragged back and forth across the table by the milling cutter. I decided was going to require at least four points of attachment to work, and these neat little clamps looked just the right shape — except for the problem of being slightly too tall.

(That current configuration in the picture was an idea Andy came up with at the last minute when trying to solve this problem.)

Andy had tried to skim them down on his lathe and told me that the metal was too hard. But I was determined to prove that anything could be done if you took little enough cuts. In this case it was steps of 0.1mm per layer and 0.5mm across

At 8000rpm there were sparks. These didn’t happen at 6000rpm. I was running with a 5mm 2fluke flat bottomed tiain-coated carbide tool. Furthermore, the conventional milling sounded marginally less nasty than the climb milling passes. I’m surprised nothing broke, though I don’t have the experience to tell whether a tool has worn out or not.

The result was pretty crap. Instead of performing some clean cutting, it seems like some of the metal was simply bashed flat and pushed out to form a lip around the face.
I didn’t know that metal would have the propensity to produce this result when undergoing milling.

It’s not a factor accounted for any software I’ve heard of.

I’ve written many algorithms that detect the horizontal flat faces of a part and create toolpaths to skim them out, but no one has ever requested a subsequent pass just below each open edge to clean off the burr left over.

Sadly, there won’t be any more machining for at least six weeks as I’ll be in a rainy campsite in Austria waiting for the chance to fly. At least this will give me lots of time to try and write some useful code when I’m not washing pans or carrying rope and other provisions for the cavers.

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:


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.


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:


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.

Wednesday, May 25th, 2016 at 1:05 pm - - Machining 1 Comment »

You know those clamps for the vice I was so pleased about fitting?

Well, they slipped out while milling metal due to all the vibrations during helixing.

This just after I’d spent all afternoon compensating for the rotational position of the vice to withing 0.04mm across 50mm of its width by probing a piece of metal in the jaws wrapped in a piece of wax paper to electrically isolate it from the vice.

Bog! That’s ruined my day.

And the weekend is going to be rubbish, waiting in a tiny cold tent in Yorkshire for the fog to clear.

Thursday, May 12th, 2016 at 5:04 pm - - Machining

I have actually been doing some machining at long last, having purchased a 130-040-01900 Precision Tool Vice Type 2 – 70mm wide vice, which feels reassuringly solid, square and metal for the entirely reasonable price of £56 — given that this is about what I’ll need to pay for a single tapered cutter when I get onto that project.

First problem was that the hold down clamps were a bit too wide to fit into the groove comfortably, so I milled them down by about 1.5mm. There had been a worry that these would be hardened steel, so I tested one by cutting a groove into it with a hacksaw. Of course the clamps are going to be soft steel. If it was hard metal it would be liable to make horrible marks in your work-piece.

Then I tried squaring off a bit of model board. This is what happens when you forget to tighten up the vice and the cutter lifts and ploughs through it before tossing it off the table.

A bit more practice, some work on toolpaths, more tools, the procurement of some pieces of metal, and I’ll be ready for business. Just in time for the holidays.

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.


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.

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)

    // 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; 

    // otherwise keep track of the average time
    } else {
        sumnormaltimes += mwritetime; 
    nbytessincegap += 8; 
    // flush at a defined multiple of looks
    if ((n % flushmultiple) == 0) {
        sumnormaltimes = 0; 
        nnormaltimes = 0; 
        long mstamppreflush = micros(); 
        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):