September 2016

Solar Cluster: Getting PCBs made

So a few weeks ago, I gave the charge controller a test, seeing if it in fact reacted in the manner I expected before deciding whether to proceed with the existing prototype or whether I should iterate the design.

In the end, I decided I’d tweak the design and get new boards built. By using SMD parts and a 4-layer board, I was able to shrink my design down to a 5×5cm square, which is relatively inexpensive to have fabricated.

I’ll be getting a few boards which means I can have some spares in case something goes bang or if I want to scale out my battery bank.

The updated design is published in the files section. This also incorporates @K.C. Lee‘s advice regarding back-to-back MOSFETs.

After some fun and games, one PCB fab house telling me to “check my passwords match” (when I know for certain that they did match), and another seemingly ignoring the inner two layers, I settled on a PCB manufacturer (thanks to PCBShopper) and got the boards ordered.

I put down my home address for the billing address and my work address as the delivery address. Both given as being in “Queensland, Australia”.

This is a learning experience for me, I’m used to just drawing my circuit out with a dalo pen, but unfortunately my skills aren’t up to producing a board for SOICs.

They reported that they shipped the boards on the 21st, and had previously estimated about 2-3 weeks for delivery. No problem there.

Just one niggling concern…

Not familiar with Swiss Post procedures, I’d have expected it to show Hong Kong → Australia, but maybe that’s how they do things. I do hope someone didn’t get Queensland, Australia mixed up with Quebec, Canada!

Update: Just been in touch, no the manufacturer didn’t get it mixed up, and it’s the right tracking number. They’re chasing it up with Swiss Post.

Improved Helmets: Thinking about modelling the brain

So I’m doing some more thought exercises on this project. Yes, been a long time since I posted anything and I only just got around to having a look at the report into Phillip Hughes’ death.

In this case, the ball managed to strike a vertebral artery. There are typically two of these, and they flow to the basilar artery which feeds the brain stem. The other major route is via the carotid arteries . Both of these sets branch out into much finer blood vessels within the brain.

That, to my mind would have triggered a sharp impulse in the blood pressure in those arteries. The arteries are somewhat elastic, but they probably don’t appreciate that level of abuse: they have pretty thin walls in that part of the body and are quite small in diameter as they branch out from the brain stem. In the report, they talk about “traumatic basal subarachnoid haemorrhage“.

According to Wikipedia, that means blood is leaking out of vessels and into the protective layers that surround the brain. We often joke about the smoke escaping from an electronic component when we put too much current through it.

This would seem to be the blood vessel equivalent: a minor artery or three went “pop”.

It would appear that this is definitely one mode of failure in the brain that should be considered when designing protective gear. It’s particularly an issue for soldiers with IEDs. In their case, the helmet can work “perfectly”, but it’s the pressure wave hitting the body causing pressure up the blood vessels in the neck that do damage, as well as pressure waves in the cerebral fluid itself.

The other mode of failure seems to be in the neurons and their connections.

Thinking about this latter point, we know that the brain is a very delicate organ when taken out of its casing. It is described as having the consistency of tofu in some articles.

This makes me wonder whether the brain should be considered a solid at all. To my way of thinking, perhaps a very dense mesh of interconnected nodes is a more accurate representation of what’s going on.

As the head moves through space (which is what seems to do much of the damage), Newton’s First Law does its worst. If you consider a single node in this mesh travelling through a linear path, the node experiences a tension force from each connection to its neighbours.

These connections have a limit to the amount of tension they can withstand. When they break, that’s when brain damage takes place.

Now, under constant velocity, or at rest, these tension forces are within tolerance, nothing bad happens. However, when a sudden blow is experienced, it is this additional tension as individual nodes get jostled around from their own inertia and the transferred tensional forces from neighbouring nodes that may trigger these connections to break.

Modelling both of these situations is an interesting problem. The latter could be done with strain gauges, but they’d have to be sensitive ones. How sensitive? Not sure. 2AM isn’t a great hour to be answering such questions.

As for the vessels, perhaps piezo transducers at differing locations might give some insight into how much pressure is in different parts.

It may also be possible to have a tree-structure of tubes representing the arteries, and measure how much they expand as the pressure wave hits by measuring how much light is blocked between a LED and a photo diode with the “artery” running in the path: the fatter it is the less light hits the diode.

More food for thought I guess. 🙂

Solar Cluster: Load test using the power controller

So, last night I started doing some light testing of the power controller. I installed a 5A fuse and hooked it up to a 10Ah LiFePO₄ battery and a homebrew 3A charger (LM2576-based with a 16V IBM laptop PSU as mains source) set to its maximum voltage (~15V).

The controller came to life and immediately started flashing its “high voltage” and “low temperature” LEDs, indicating that:

  • It thought the temperature was high enough to warrant a fan turning slowly (above ~20°C)
  • It thought the battery voltage was too high for comfort (IPMI complains when the voltage gets much about 13.6V.)

In order to get the battery to discharge, I plugged in an old Icom IC-706MkII G transceiver, set it on receive mode. I didn’t have an antenna attached, so this would have represented a very light load for what would be production use.

The battery started discharging, and after a few tens of minutes, the high voltage warning LED had stopped flashing and instead the “good voltage” LED was staying constantly on. So battery was in a range the controller was happy with.

It was going to take a long time though, for that set to drain a 10Ah battery in receive mode.

This morning, I got out the big guns. I plugged the actual cluster in and fired it up. After about 30 minutes of run time, the battery had drained sufficiently that the charger started flashing the “good voltage” LED, indicating battery was getting low. It had also turned on the MOSFET controlling the charger I had plugged in, and the charger was desperately trying to keep up with the ~5A load that the cluster was drawing. (Did I mention this was a 3A charger?)

So far so good. I powered off the cluster and unplugged it. It continued to let the charger do its job, and after another short while, the battery had regained some charge. It kept the charger on until momentarily, it peaked over the “high voltage” threshold. The “high voltage” LED blinked a few times, then the MOSFET turned off and the “good voltage” LED remained solid.

The battery was sitting at 13V. A little short of my 13.5V set-point, but close enough given it was on a fairly weak charger. So that ATTiny24A is doing exactly what I intended.

Maybe the high set-point could do with some adjustment, or a turn-off delay added (with a separate “high critical” set-point for immediate shut-off), but so far, so good.

It might be worth me getting some PCBs fabricated and shrinking the prototype board down using SMD parts, but this controller works so far.

Solar Cluster: Power controller firmware taking shape

So after a long hiatus, some of it involving some yak shaving (e.g. #Open-source debugWire debugger yes, I’ll get back to that), I managed to get a version of the firmware together for the power controller that seems to be doing what I ask of it.

The means of overcoming the road block was knocking up a very crude (and slow!) UART driver so I could print data out on the serial port. I avoided doing this previously because I didn’t have an easy way to interface to a TTL serial port. Recently though, I bought some FTDI serial cables, one 5V and one 3.3V, so now I had little excuse.

I feel these will give me some valuable insights into tacking the debugWire project.

I was able though, to bit-bang a UART using avr-libc’s _delay_us, and get a respectable 4800 baud serial stream out. This obviously dropped to 300 baud when I had other tasks running, but still, that’s enough to do what I’m after. (Once upon a time, that was considered fast!)

After figuring out where I was going wrong… perhaps I had been sniffing too much solder smoke that day… I re-wrote my firmware, using this UART library as a means of debugging the code. I set up Timer1 to run at 1.2kHz, which meant I could also use it as a baud rate generator for my software UART and upping the baud rate to 1200bps.

Some further work on a breadboard, and I had more-or-less working firmware.

I’ve thrown the code up on GitHub, it’s very much in a raw state, and I might do a second revision of the PCB, since this prototype seems to be more or less on the money now.