Freesteel Blog » Julian

Thursday, May 18th, 2017 at 4:25 pm - - Flightlogger

We’ve had fun in the past updating the software on the Sonoff S20 mains adapter plug which has a relay switch and an ESP8266 with enough power to run MicroPython and connect to your WiFi, but I realized that we had to go further.

Not only is the software on these mains plugs inevitably out of date for your latest networked IOT needs, requiring you to immediately replace itin order to make it do clever things, but the microcontroller itself won’t be any good. What if you want to use a Raspberrypi, an Arduino or an ESP32?


So I got Tom to design a cheap componentwise mains switch with four wires: Ground, 5V power (good for most microcontrollers), Switch-Pin (to throw the relay, which works with 3V), and Current Flow (an analog pin).

Don’t worry about the voltage, I said. We know what the voltage is, on a cycle between 0 and 240V which we can sample and add up.

Turns out it’s not quite so simple.


The ACS712 current sensor reads 2.5V with zero current and goes towards 0V and 5V depending on the direction and magnitude of flow.

I tried it with the fan and the desk lamp.


Fortunately we have an oscilloscope in the hackspace.

At first I didn’t think it was working, but then it turned out that these devices don’t draw much current. You can see the shallow A/C signal.

You get a proper big sine wave when you plug in the kettle.

And then you get lots of spare hot water and brew yourself a cup of tea.

I found an electric drill on the proxxon mini mill


And its trace involved these little humps in either direction.


It’s almost as if it’s only bothering to draw current when the mains power goes above 150V.

Here is the trace from the computer power supply and the LCD monitor.


This seems to pick up current only when it goes below 20V on the return to zero part of the cycle, like it trims off just the tail of the A/C cycle and blocks the rest of the flow. I guess if it was in a 110V power supply it would take a bigger chunk of it.

So that shows I was completely wrong. We need to know the voltage, or at least have an interrupt pin the fires when it crosses the zero threshold, wherein we can recreate the cycle using a sine wave.

Annoyingly an ESP8266 has only one analog input pin, so we’d need an additional analog to digital converter, but the interrupt pin idea, or one that is up or down above a certain voltage would do the job at the minimum.

It does mean we can form an interesting signature of each of your devices.

Most electronic devices with switch mode transformers are going to have a fairly consistent pattern of chopping out the waveforms (I wonder what the consequences of this are on the grid), but something more complex like the washing machine will have heating, pumps and spin cycles which ought to be distinguishable.

We can put the whole thing into a single package with a modern ESP8266 microcontroller with its 4Mbs of flash memory to keep records in order to find out what’s going on. Smart meters should mean you don’t need to write anything down.

Just plug it in, say what it is, and it will build up a table of what it is. Even saying what things are is a pain, so put a disposable RFID onto your appliances and wave the smart socket at it before you plug it in. This product does all the thinking for you and builds up a dashboard of your energy consumption portfolio rather like your pension investment plan — except in this case the numbers are real and you can do something about them. It’s not some fictional investments that are going to be stripped from you at the next engineered crisis in order to cover up for the fact that the whole system is bankrupt.

I mean, goddamnit, why is it easier to find out the stock trading price of General Motors Series Z shares in Chicago than the total electricity use of my washing machine on a full cycle? What kind of a misplaced set of priorities do we have here. Let’s get this thing working.

Wednesday, May 10th, 2017 at 2:40 pm - - Flightlogger

My theory is that airspeed is related to kinetic energy. Like a person walking up and down a train, the airmass provides the reservoir of momentum and energy so that it all adds up.

The balance of kinetic energy when walking in a train has always bothered me. If the train is moving at a velocity v then your body’s kinetic energy is m*v^2/2 while seated in the train. If you walk in the towards the front of the train at walking speed w your kinetic energy will be m*(v+w)^2/2 and if you walk towards the back of the train your energy will be m*(v-w)^2/2. That means the difference in kinetic energy going forwards is m*v*w + m*w^2/2 and going back is -m*v*w + m*w^2/2.

The m*w^2/2 is your kinetic energy from walking on a stationary ground. But how do we account for the +-m*v*w?

Well, it turns out that if the train has mass M then, by the conservation of momentum, when you start walking up the train at velocity w the train must slow down by a factor of w*m/M where M is the mass of the train. This tiny tiny decrease in the train’s velocity releases kinetic energy of about w*m/M*M*v, which accounts for that factor. (I’m ignoring lower order terms that take account of the fact that your forward velocity is not actually v+w because you need to subtract off for the slightly slower train.)

Air is not the same as a train — an enormous solid object to which one can directly transmit kinetic energy and momentum — but we’ll treat it as such until I can think of it in a better way to handle it.

To illustrate the difference, here’s my top landing at Camlo Hill which transmitted a good deal of momentum via a dent in the ground.



Monday, May 8th, 2017 at 6:49 pm - - Flightlogger, Hang-glide

I’m getting tired of having “learning experiences” when I really want more “fun experiences”. But in the meantime, here goes.

On 2017-04-29 I was at the hang-gliding competition on Camlo hill in Wales, where I didn’t take any thermals over the back — like the folks who knew what they were doing — and I landed back on the top with nil points and little satisfaction.

For this learning experience, I downloaded the tracklog of one of the guys who did make it and snipped out the first 12kms of flight, like so:


Direction of flight north is to the right (start of flight bottom left near (0,0)), the coordinates are in metres.

Having convinced myself I can extract the SRTM3 terrain, this is the graph of the flight altitude from the hill for those 12km against the terrain altitude:


Or you can plot the actual height above ground by subtracting the two:


This looks like he was circling with a pretty consistent height of 350m as the air mass was carried up and down over the terrain, in a “bubble” of rising air.

Except there is no way this could be a bubble, because even if the bubble extended all the way to the ground 350m below, it would have certainly been been expended in less than 6 minutes at a rate of 1 metre per second to support an efficiently flying glider.

After 25 minutes of existence, we can rule out that it has anything to do with any packets of warmed air which may have risen from the ground 12kms to the south.

“Ah,” the usual response goes, “the glider was flying in a chain of thermic bubbles along the track of the flight, each one rising up just in time to pick up from where the last left off.”

This explanation is bogus. I don’t seem to pick up thermic bubbles that easily along my track, while the pilot that stayed with the thermal reported a continuously existing atmospheric formation which strengthened and subsided, but was always there.

I also don’t buy the idea that this structure is somehow kicking off thermic bubbles on the ground 350m below at least five minutes downwind of its track in time to reach his altitude.

No, this must be a self-contained, self-sustaining convection structure that may have been initiated by a thermic bubble, but which has clearly morphed into something altogether different.


Monday, April 24th, 2017 at 8:15 pm - - Flightlogger

I had a very agreeable flight on Saturday in Wales, marred by a crappy going down performance on Bradwell on Sunday, just to put me in my place as not having any talent.

Here’s the good place to be, about a mile up from the ground:

It was a confused forecast, which meant a lot of people stayed away. Turns out it was because there was wave everywhere. I flew Tim’s U2 (mid-performance glider), but was put off by the fact of everyone pointing out that I was too high on the bar, and so wouldn’t be able to steer it so well. Hang-loops, unlike climbing harness loops, do not come with a buckle, so you can’t do anything about it.

There was a lot of lift straight off the hill, and then Carl said over the radio, “I think I’ve contacted wave, just to the right of the mound in front of the hill.”

There were lenticular (French for “slow”) wave clouds everywhere and no cumulus. I was wearing a skinny pair of gloves and had no base bar mitts (which I do have on my own glider).

Wednesday, April 19th, 2017 at 11:41 pm - - Flightlogger

I’m not going to learn too much from myself, so I’ve got the raw data from Tim’s flight as measured by his Kobo/bluefly IGC logger.


As you can see, he ranged a good deal further than I did from Mam Tor, reaching an altitude of 1500m, and he reported scoring glide angles of 10 to 1 on his glider much-fancier-than-mine-of-which-I-am-now-jealous.

Let’s see if we can corroborate this from his data with the power of pandas and matplotlib.

pIGCtim = fd.LoadIGC("Tim-1492470000.igc")
pQ = pIGCtim.resample("1S").interpolate(method="time")  # fill uneven records

dstep = 30 # rolling windowed measurements in seconds
vario = (pQ.alt.diff(dstep)/dstep)  # m/s averaged over 30seconds
groundvelocity = numpy.sqrt(pQ.x.diff(dstep)**2 + pQ.y.diff(dstep)**2)/dstep

Here is vario:

Here is ground velocity:

The glide slope (normally called the glide-angle, even though we don’t quote it as an angle) is the groundvelocity divided by the descent rate. When the descent rate is close to zero, you get stupid numbers, so we need to throw those out and only quote for the parts where there is reasonably direct gliding flight.


Friday, April 14th, 2017 at 4:32 pm - - Machining

Building on the weighted servo motor (having spent the first 20 minutes of the day trying to find where I left my code) I’ve tried to code it to run on a sine wave as an oscillation.

It’s not easy, of course.

How did I get this?

From the fixed voltage experiments I computed the function from the voltage and velocity to the acceleration for motor1 as follows:

cv0, cm0, cv1, cm1, cvm, cvc = 53.202, -1036.634, 56.027, -974.375, -7.497, -1521.571
acceleration1 = (velocity1 - (min(volts1-cv0, 0)*cm0 + max(volts1-cv1, 0)*cm1))*cvm + cvc

Therefore, given the velocity, if you want a particular acceleration, you need the following voltage:

tq = velocity1 - (acceleration1 - cvc)/cvm
if tq < 0:
    volts1 = tq/cm1 + cv1
    volts1 = +tq/cm0 + cv0

The above was the result of trying to make the motor oscillate like a pendulum by setting the acceleration to a negative number times the displacement:

acceleration1 = -acc1fac*(position1 - position1c)

Of course, one source of the problem is knowing the velocity. I’ve bodged this by recording a couple of positions up to 0.2seconds in the past and measuring to them.

if currenttime - prevtime > 0.1:
    position1prev2 = position1prev
    position1prev = position1
    prev2time = prevtime
    prevtime = currenttime
velocity1 = (position1 - position1prev2)/(currenttime - prev2time)

Unfortunately, this produces lots of bumps, so I think I’ll have to do this properly by applying, say, an exponential filter to the position value which delays the position, and use the difference between that and the current position as a measure of velocity.

Like all such runtime velocity measurements (unlike the ones done in pandas that have been calculated by picking a position on either side of the current time, like so:

(df.shift(-10).position1 - df.shift(10).position1)/(df.time.shift(-10) - df.time.shift(10))

…it’s also going to be delayed by a certain amount and be invalid under accelerations.


Thursday, April 6th, 2017 at 11:22 am - - Flightlogger

On my last sorry flight I was carrying a total of four GPS units. One of them is a pile of poo. It’s the bluefly one I programmed to read at the frequency of 10 times a second, so greedy was I for precision and data.


Why do they have that option if it’s a complete waste of my time? All that work learning how to remotely step up its baudrate so that it could transmit data at this higher rate.

Here’s how the error comparisons line up, including the minus 3second correction on the 6030 vario’s timestamps. The “u” value is the number of milliseconds from midnight according to the GPS satellite timestamp.

gnames = [ "gps6030", "gpsxcsoar", "gpsTopShelf", "gpsBlueFly" ]
print("samples, gpsA, gpsB, stddev")
for i in range(len(g)):
    for j in range(i+1, len(g)):
        qA, qB = g[i], g[j]
        dt = 3000 if i == 0 else 0 # observed timeslip on 6030 unit
        dx = qA.x - numpy.interp(qA.u-dt, qB.u, qB.x)
        dy = qA.y - numpy.interp(qA.u-dt, qB.u, qB.y)
        k = (dx**2 + dy**2)[tf0:tf1]
        print(len(k), gnames[i], gnames[j], math.sqrt(k.mean()))
samples gpsA gpsB stddev
400 gps6030 gpsxcsoar 6.086
400 gps6030 gpsTopShelf 7.914
400 gps6030 gpsBlueFly 17.040
550 gpsxcsoar gpsTopShelf 7.845
550 gpsxcsoar gpsBlueFly 19.095
4120 gpsTopShelf gpsBlueFly 17.451

Now I have to program the BlueFly to sample at 200ms like the spare top-shelf GPS does, and see if that fixes it.

Meantime, has is that the accelerometer doing with this not-crap GPS?

Tuesday, April 4th, 2017 at 1:29 pm - - Machining

Suppose we apply a random series of fixed duty cycles to a servo motor, like so:


A 50% duty cycle means that the volts are applied half one way and half the other at about a frequency of 100kHz, so it’s equivalent to zero volts.

I can plot the position from the encoder at the same time, like so:


There’s about 1000 ticks per revolution of the wheel and it’s wired backwards so a positive voltage makes it spin backwards.

Amazingly, with the control loop written in Python on a beaglebone controlling the H-bridges, it makes 4500 samples per second, which is perfectly adequate and I have not had to resort to any fancy tricks with C++ or the PRUs.

With a pandas timeseries Series object pos, we can calculate the velocity over a window of +-100 samples (about 1/20th of a second) like so:

# I'd like a better way to shift and difference a timeseries index.
vel = (pos.shift(-100) - pos.shift(100)) / \
      (pos.index.to_series().shift(-100) - pos.index.to_series().shift(100))

And then there is the acceleration:

acc = (vel.shift(-100) - vel.shift(100)) / \
      (vel.index.to_series().shift(-100) - vel.index.to_series().shift(100))

We can plot them all up like so:


Here’s what the first two seconds look like.

Friday, March 31st, 2017 at 10:10 am - - Machining

No time for blogging, but here is a video of the servo motor doing some random lifts with the string.

And this is the graph of the data acquired (red is the step-changing voltage applied) including position, velocity and acceleration:
Back later when I have time to write this up and do some further analysis.

Friday, March 24th, 2017 at 12:19 pm - - Flightlogger

We move on to the temperature sensor work, and the controversial concept that the temperature of the rising air in a thermal is hotter than the non-upwardly-mobile surrounding environmental atmosphere.

I say it’s controversial because the meaning of “the temperature” in relation to a mobile and turbulent airmass whose structure spans hundreds of metres in the vertical dimension and thousands of Pascals in relative pressure is undefined. Remember that the adiabatic temperature differential is about 0.7degrees per 100m change in altitude.

We do, however, have a single point temperature sensor on a mobile glider which is also progressing up and down the air column (depending on the wind currents and skill of the pilot). The location of the glider with the single temperature sensor is imperfectly known (due to bad GPS (see previous post) and inexplicable barometric behavior (see next post)), and the sensor itself has a thermal mass which means its readings have a delay half-life of about 9 seconds in flowing air (see this other post).

I have taken the precaution of jettisoning my slow, accurate and low resolution dallas temperature sensor for two humidity/temperature sensor combos and an infrared thermometer that has quite a good ambient temperature sensor within its metal can.

These sensors tracked one another pretty well, except for one small problem when I spotted a series of spikes in one and then the other humidity/temperature sensor.


What is going on?