March 2016

Solar cluster: Handling the solar input

Seems one of the past projects, the #ARDUINO MPPT SOLAR CHARGE CONTROLLER might be worth taking a close look at.

That could sit between my relay-based circuit and the solar panel to up the efficiency a little bit. Previously, I’ve used a LM2576 buck converter and that has done okay, but needs constant tweaking. This alternative should be a bit more automatic in its operation.

Improved Helmets: Looking for answers in textbooks

As mentioned earlier, I’ve been doing a little “light” reading. Light reading being in the form of a 1500-page physics textbook which was purchased in my first year of engineering.

I’ve just been reading through it revising the material. Not doing the actual problems but just refreshing my memory, I figure I’ll go back and do selected problems once I’ve gone over everything.

I figured I’d see something that would perhaps jog my memory, or inspire me in one form or another.

One area was Hooke’s law, which relates the force exerted on a spring to its amount of displacement. I figure as a model of the brain, this might be one way to model it, not as a single mass, but as a series of “marbles”, if you will, connected by springs, as an analogy to the concept of neurons and their interconnections. The thought that, perhaps brains are not solid, but are a very dense mesh.

I’ll have to ponder this a bit more I guess. It’s basically a finite-element analysis approach to modelling the brain and what goes on inside. It’d be interesting to try a physical modelling of that mathematical model. Lead sinkers and strain gauges perhaps? I don’t know there.

The other was in relation to my test apparatus that I described earlier. In flicking through the problems, I found this:

Now, there are obvious differences, but really the headform moves the centre of mass closer to the end. If we can find the details of the centre of mass, we can derive what the headform is doing. Moreover, it might be useful to model the mass of the cyclist’s body in the form of mass in that rod, perhaps a bulk mass towards one end.

In short though, the equations needed to answer the above question are undoubtedly in that book, and moreover, I do have a worked copy of that example, but we won’t look at that just yet, that would be cheating.

Solar cluster: Charge controller ponderings

I’ve been giving some thought to how to manage charging of the battery.

There’ll be two charge sources essentially, one will be mains power via a conventional battery charger, the other will be solar. Both are current-limited and will be below 24 volts.

The battery will not respond straight away to a step change in applied voltage, rather current will start flowing in and the battery voltage will begin to rise. There’ll be a delay in the voltage being applied and the observed battery voltage reaching that point. The only thing we really need to watch is that the current doesn’t exceed the inrush capabilities of the battery.

What we want to avoid is that, as we get close to charge, we do not “chatter” on the upper set-point. When the upper set point is reached, we should back off some minimum delay, before continuing to charge.

This is a possible implementation of that idea.

We consider 3 voltages:

Variable Notes
V_{CL} “Low” control voltage set-point. Charger should turn on near this point. Set by a potentiometer on a regulated supply.
V_{CH} “High” control voltage set-point. Voltages above this point are considered harmful and we should cut power when this voltage is reached. Set by a potentiometer on a regulated supply.
V_{CB} Battery control voltage. This is proportional to the battery voltage, set by a resistor divider or potentiometer across the battery.

We have two comparators that tell us when the battery is below the high set-point, telling us we’re “safe” to begin charging, and when the battery is below the low set-point, telling us the battery is “low” and needs charging. We use an SR latch to achieve this. The “safe” is inverted, and helps drive the “reset” side of the SR latch, the “low” signal drives the “set” side.

If the voltage gets above our high set point at any time, we must stop charging immediately. So we use an AND-gate to ensure that the power is shut off as soon as possible. We feed this into the SR latch reset pin via a NOT gate to the SR latch to reset the state.

If the voltage gets low, depending on our set-point and rate of discharge, we can tolerate some small delay in getting going. We ensure it is safe to do so by ANDing “LOW” with “SAFE”, then delay the rising edge pulse by a few seconds, possibly with an RC circuit or 555 timer, before passing that into the SR-latch.

The AND logic also prevents us from asserting “SET” and “RESET” on the SR latch simultaneously.

The graph I’ve drawn is a bit of an exaggeration, hopefully the discharge curves won’t be that steep. It’s possible I could do away with an op-amp and use hysteresis, however I feel using two means I can control the two set-points independently.

Two of these, and tweak the delays a bit so that the solar comes on first, and we should be able to run both in parallel to charge the same battery.

Solar cluster: Modding the switch for 12V operation

Probably going to be easier than expected. I popped open the cover to see whether it was like the much older Netcomm switch we have.

Sure enough, Linksys do it the same way in the LGS326AU:

This PSU is an open-frame PSU made by Asian Power Devices, Inc. Model NW-20A12-BAAB. Not sure if there’s someone here who knows more about this particular PSU.

It appears it’s the one 12V feed split in two. Red/Black are negative, green/yellow are positive. I’ll double check this. I think with a nice big inductor/capacitor as an in-line filter, this can be hooked straight up to the 12V line, perhaps with a small amount of zener overvoltage protection. It appears that the voltage is further rectified on the switch mainboard:

Solar cluster: Testing the nodes

Well, I managed to get some parts yesterday. The plugs I bought don’t quite fit, so I’ll have to buy some different ones. Apparently the ones I got are for a 2.1mm inner pin, the ones I need are a 2.5mm inner pin.

No problems there though, they sort-of jam in there, and I can use them for other projects. Jaycar have changed things around and most of the bits are behind the counter — might as well go through online crowds if I’m not able to inspect the part close up. That’ll be a Tuesday job.

I’ve just put up a photo of the last two nodes being tested and bootstrapped, along with a shot of the partially-wired up wiring loom. I sort-of whacked that together to prevent the wrong parts from coming into contact. There’s a 30A fuse on the battery feed and individual 10A fuses for each machine. I could use 5A fuses too.

So far, I’ve now built kernels on all 5 boxes, and all seem to be performing well, if there were going to be issues with a box, I think they’d have shown up by now.

I also cracked open one of my old 24-port switches (an unmanaged Netcomm 10/100Mbps), and was pleasantly surprised to see the PSU was a separate module, putting out 3.3V 4A. I’ll crack open the Linksys and see if the same is true there, if so, this could be a much better option than trying to convert 12V?240V?some low voltage. If the step to 240V can be avoided, I might as well.

Solar Cluster: Accumulating parts and planning the system

Well, figured I’d document this project here in case anyone was interested in doing this for personal amusement or for their workplace.

The list I’ve just chucked up is not a complete list, nor is it a prescribed list of exactly what’s needed, but rather is what I’ve either acquired, or will acquire.

The basic architecture is as follows:

  • The cluster is built up on discrete nodes which are based around a very similar hardware stack and are tweaked for their function.
  • Persistent data storage is handled by the storage nodes using the Ceph object storage system. This requires that a majority quorum is maintained, and so a minimum of 3 storage nodes are required.
  • Virtual machines run on the compute nodes.
  • Management nodes oversee co-ordination of the compute nodes: this ideally should be a separate pair of machines, but for my use case, I intend to use a virtual machine or container managed using active/passive failover techniques.
  • In order to reduce virtual disk latency, the compute nodes will implement a local disk cache using an SSD, backed by a Rados Block Device on Ceph.

I’ll be using KVM as the virtualisation technology with Gentoo Linux as the base OS for this experimental cluster. At my workplace, we evaluated a few different technologies including Proxmox VE, Ganeti, OpenStack and OpenNebula. For this project, I intend to build on OpenNebula as it’s the simplest to understand and the most suited to my workplace’s requirements.

Using Gentoo makes it very easy to splice in patches as I’ll be developing as I go along. If I come to implement this in the office, I’ll be porting everything across to Ubuntu. This will be building on some experimental work I’ve done in the past with OpenNebula.

For the base nodes themselves, I’ve based them around these components:

For the storage nodes, add to the list:

Other things you may want/need:

  • A managed switch, I ended up choosing the Linksys LGS-326AU which U-Mart were selling at AU$294. If you’ve ever used Cisco’s small business offerings, this unit will make you feel right at home.
  • DIN rail. Jaycar sell this in 1m lengths, and I’ll grab some tomorrow.

Most of the above bits I have, the nodes are all basically built as of this afternoon, minus the SATA adaptors for the three storage nodes. All units power on, and do what one would expect of a machine that’s trying to boot from a blank SSD.

I did put one of the compute nodes through its paces, network booting the machine via PXE/NFS root and installing Gentoo.

Power consumption was below 1.8A for a battery voltage of about 13.4V, even when building the Linux 4.4.6 kernel (using make -j8), which it did in about 10 minutes. Watching this thing tackle compile jobs is a thing of beauty, can’t wait to get distcc going and have 40 CPU cores tear into the bootstrap process. The initial boot also looks beautiful, with 8 penguins lined up representing the 8 cores — don’t turn up here in a tuxedo!

So hardware wise, things are more or less together, and it’ll mostly be software. I’ll throw up some notes on how it’s all wired, but basically the plan in the short term is a 240V mains charger (surplus from a caravan) will keep the battery floated until I get the solar panel and controller set up.

When that happens, I plan to wire a relay in series with the 240V charger controlled by a comparator to connect mains when the battery voltage drops below 12V.

The switch is a 240V device unfortunately (couldn’t find any 24-port 12V managed switches) so it’ll run from an inverter. Port space is tight, and I just got the one since they’re kinda pricey. Long term, I might look at a second for redundancy, although if a switch goes, I won’t lose existing data.

ADSL2+ will be managed by a small localised battery back-up and a small computer as router, possibly a Raspberry Pi as I have one spare (original B model), which can temporarily store incoming SMTP traffic if the cluster does go down (heaven forbid!) and act as a management endpoint. There are a few contenders here, including these industrial computers, for which I already maintain a modern Linux kernel port for my workplace.

Things are coming together, and I hope to bring more on this project as it moves ahead.

Improved Helmets: Further leads on statistics

Today I had a reply back from the statistics branch of Queensland Health . QUT run the Centre for Accident and Road Safety, Qld (CARRS-Q) who do a lot of research into this field already. They’re based at QUT’s Kelvin Grove campus, fairly easy for me to get to if needed.

It would appear they likely have access to the sorts of statistical data I’m chasing, and will also have the statisticians on hand to make sense of it all. They already publish much of their data online. In short, they’ll be a good mob to talk to.

Their article, Monograph 5 – Bicycle Helmet Research , appears to have a lot of information, I’m yet to study it fully but I’ve had a brief look.

I was also referred to the Australian Institute of Health and Welfare who were the authors of the article that Nick Rushworth (Brain Injury Australia) pointed me to. Specifically, their article Trends in serious injury due to land transport accidents .

There’s lots to go through in that collection alone. Thankfully, there’s an extra long weekend due to Good Friday and Easter Monday coming up, so plenty to keep me occupied, and a few good leads to chase up.

Improved Helmets: Re-analysing the AS/NZS 2063:2008 test case

This afternoon, I managed to stumble on one of my old text books from my first years studying Electrical Engineering at university. In the first year, we future engineers are all one big happy family, with civil, electronics and other groups, all lumped together. So we study the same things, including physics.

For me, studying at QUT in 2004, the text book we were told to read was Physics for Scientists and Engineers with Modern Physics , Serway and Jewett, 6th Edition (International student edition, ISBN 0-534-40949-0 ). In reading this, I realised I had made an error in my earlier analysis of this test case.

So we make the same assumptions as before. That doesn’t change. We fix our earlier incorrect equation, and re-calculate based on that. If someone does happen to notice something amiss, feel free to let me know. If you’re not a Hackaday.io user, I can be contacted a number of ways.

Another difference is that the CPSC tests use a headform mounted to a carriage that runs along a single rail, whereas Australian Standards testing appear to use the dual-guide-wire technique judging from the crash.org.au videos, one of which is here (Sorry guys, I’d link to the page, but then 1999 called asking for their proprietary Flash Player plug-in back).

Thus, without further ado, I present my re-analysis.

First, a diagram of the test set-up.

So y increases with distance from the anvil mounted on the floor. The guide wires are assumed to present negligible resistance, and we’ll ignore wind resistance.

Annoyingly, I can’t copy and paste the table from earlier, so please refer to my previous post on this for the assumed values.

Taking the correct equation for the height over time, and trying to solve for when the helmet meets the anvil, the impact time, we get the following equation:

0={1 \over 2}(-9.8)(t_I)^2 + 0t_I + 1.5 which re-arranged, gives:

t_I = \sqrt {-1.5 \over {({1 \over 2}) \times -9.8}} = \sqrt {-1.5 \over -4.9} = 0.553283

So a flight time of 553.283 milliseconds. In that time, it accelerates by -9.8m/s every second, so we can work out the impact velocity.

v_I=at_I=-9.8 \times 0.553283 = -5.422 We can work out the momentum at that the time of impact.

p_I = mv_I = -27.111 Our worst case is an elastic collision, so we can describe the momentum after impact as being the momentum at impact, in the opposite direction:

p_A=-p_I=27.110 This gives us a change in momentum as follows:

\Delta p = p_A - p_I = 27.110 - (-27.110) = 54.222 We can’t model an instantaneous change, so let’s assume it happened all in a millisecond. That gives us the following force after impact:

F_A={\Delta p \over \Delta t} = {54.222 \over {10^{-3}}} = 54221.767 Given the headform/helmet mass, that gives us an upward acceleration of:

a_A={F_A \over m}=10844.353 = 1106.567 g If the other scenario didn’t kill our cyclist, this definitely would.

Improved Helmets: Statistics trickle in

Well, today I received an email from the Queensland Department of Main Roads with some statistical data relating to bicycle, motorcycle and moped accidents. I thank them for their contribution.

The information is basic, but it covers the period from 2006 through to 2015, whether or not a helmet was worn, and whether the person died, was hospitalised, just received medical treatment or just had a minor injury.

Sadly, not information on whether there was TBI involved, but maybe Queensland Health could help me there. Similarly for emergency departments elsewhere in the world, I doubt the problem is just in Queensland.

I also have a fear that the information may not be tracked. I hope I’m wrong in that fear.

It’d be useful to know about upper-spinal injuries (neck vertebrae) since the weight of the helmet would be a contributor there. Basically injuries from the neck up.

I haven’t analysed the data as yet, but it’s right here if anyone wanted to look themselves.

Improved Helmets: An alternate test rig

I was doing some thinking last night, then it occurred to me. We are trying to do simulations of crashes using linear motion. Dropping a helmet vertically. That’s linear.

For sure, it’s a good-enough approximation when you hit something head-on… or is it? If you come off and fly through the air, then maybe, you’ll strike something dead-level.

More probable though, is you’ll follow an arc, under projectile motion. The most likely scenario is that as the bicycle/motorcycle tilts over, you follow it. It’s not going to be a direct-to-the-ground vertical drop of your head, but rather, a circular arc.

So how do we test for it? I suppose like this: