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.
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 |
 |
“Low” control voltage set-point. Charger should turn on near this point. Set by a potentiometer on a regulated supply. |
 |
“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. |
 |
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.
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:
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:
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.
Well, having learned about the technical names for some of these injuries, I stumbled upon this article which describes, in lay terms, the various injury types.
Interestingly, they make reference to the cranial vault-brain dimensions that I was trying to figure out earlier:
In the subdural space is the cerebro spinal fluid. This fluid performs a number of functions, the main one being to protect the brain from impact concussion. The brain “floats” in the cerebro spinal fluid, lessening the weight on the base, and is supported at the base by the spinal cord. The brain, buoyant in the cerebro spinal fluid, can move within the cranium to a very limited degree. The space between the temporal bone and the brain is only one millimeter.
My earlier back-of-the-envelope calculation which yielded a gap of 700µm wasn’t far from the truth!
The picture I uploaded on this project was an idea that came to me as I was lying in bed thinking about the problem.
The thought was inspired by a helmet I saw for sale in my local bike shop.
It had a single row of spines for “decorative” purposes. The thought occurred to me, what would happen if those spines covered the entire surface of the helmet? Hence, I came up with this.
Seems Vicis has had a similar idea, their Zero1 helmet incorporates a crumple zone not unlike the one I’ve drawn on the whiteboard here. Theirs is focussed solely on “football” applications (grid iron).
Now, patents are really what could throw a spanner in the works for this project. I’m looking to see if there’s a patent on this, and if so, how broad that patent is. It would be a big tragedy if other helmet users such as cyclists and motorcyclists, were denied access because of this , I must tread carefully as they are bigger than I am.
A work colleague, Jessie Li came up with an interesting idea this morning.
She suggested that perhaps helmets could be built to a speed rating, and give a warning to the rider when that speed is exceeded. The idea is that the helmet is matched to the likely user risk scenario.
This would be interesting to try and work in with a project like the #DIY Smart Crash Helmet project.
One of the stated goals is to try and determine how statistically significant TBI is in motorcycle and bicycle accidents.
Null hypothesis here will be that motorcycle accidents will have a much higher prevalence of TBI than in bicycle accidents, down to the typical routes and speeds alone.
Nick Rushworth, executive officer of Brain Injury Australia has been most helpful in pointing me to some statistics on New South Wales road crashes as well as some more general statistics from 2004-05 on TBI cases in general . His assistance in this has been a big help.
The Queensland Department of Main Roads also produces a number of reports, as well as a request form. Transport for NSW also provide statistics. I think the data is there, we’ve just got to figure out a means to drill into it.
Recently, I learned about the IceStorm project, which is an effort to reverse engineer the Lattice iCE40-series of FPGAs. I had run across FPGAs in my time before, but never really got to understand them. This is for a few reasons:
I wasn’t interested in doing the proprietary toolchain dance, did enough of that with some TI stuff years ago. There, it was the MSP430, and one of their DSPs. The former I could use gcc, but still needed a proprietary build of gdbproxy to program and debug the device, and that needed Windows. The latter could only be programmed using TI’s Code Composer studio.
FPGAs were ten times worse. Not only was the toolchain huge, occupying gigabytes, but the license was locked to the hardware. The one project with anything FPGA-related, it was an Altera FPGA, and getting Quartus II to work was nothing short of a nightmare. I gave up, and vowed never to touch FPGAs.
Fast forward 6 years, and things have changed. We now have a Verilog synthesiser. We now have a place-and-route tool. We have tools for generating a bitstream for the iCE40 FPGAs. We can now buy FPGA boards for well under the $100. Heck, you can buy them for $5.
Lattice can do one of three things at this point:
Time will tell as to what they choose. I’m hoping it’s the latter, but ignoring us is workable too.
So recently I bought an iCE40-HX8K breakout board. This $80 board is pretty minimal, you get 8 LEDs, a FTDI serial-USB controller (which serves as programmer), a small serial flash EEPROM (for configuration), a linear regulator, a 12MHz oscillator and 4 40-pin headers for GPIOs.
The FPGA on this board is the iCE40HX8K-CT256. At the time of writing, that’s the top of that particular series with 7680 look-up tables, two PLLs, and some integrated SPI/I²C smarts.
There’s not a lot in the way of tutorials for this particular board, most focus on the iCEStick, which uses the lesser iCE40HX1K-TQ144, has only a small handful of GPIOs exposed and has no configuration EEPROM (it’s one-time programmable). (Update: got one now… turns out they do have an EEPROM that can be reprogrammed.)
Through some trial-and-error, and pouring over the schematics though, I managed to port Al Williams’ tutorial on Hackaday at least in part, to the iCE40-HX8k board. The code for this is on Github.
Pretty much everything works on this board, even PLLs and block RAM. There’s an example using the PLL on the iCEstick in this VGA demo project.
Some things I’ve learned:
FILTER_RANGE is a mystery though. Haven’t figured out what the values correspond to.
It’s likely this particular board is destined to become a DRAM/Interrupt/DMA controller for my upcoming 386, but we’ll see. In the meantime, I’m playing with a new toy. 🙂
Well, in the last post I started to consider the thoughts of building my own computer from a spare 386 CPU I had liberated from an old motherboard.
One of the issues I face is implementing the bus protocol that the 386 uses, and decoding of interrupts. The 386 expects an 8-bit interrupt request number that corresponds to the interrupting device. I’m used to microcontrollers where you use a single GPIO line, but in this case, the interrupts are multiplexed.
For basic needs, you could do it with a demux IC. That will work for a small number of interrupt lines. Suppose I wanted more though? How feasible is it to support many interrupt lines without tying up lots of GPIO lines?
CANBus has an interesting way of handling arbitration. The “zeros” are dominant, and thus overrule “ones”. The CAN transceiver is a full-duplex device, so as the station is transmitting, it listens to the state of the bus. When some nodes want to talk (they are, of course, oblivious to each-others’ intentions), they start sending a start-bit (a zero) which synchronises all nodes, then begin sending an address.
While each node is sending the same “bit value”, the receiving nodes see that value. As each node tries sending a 1 while the others are sending 0’s, it sees the disparity, and concludes that it has lost arbitration. Eventually, you’re left with a single node that then proceeds to send its CANBus frame.
Now, we don’t need the complexity of CANBus to do what we’re after. We can keep synchronisation by simple virtue that we can distribute a common clock (the one the CPU runs at). Dominant and recessive bits can be implemented with transistors pulling down on a pull-up resistor, or a diode-OR: this will give us a system where ‘1’s are dominant. Good enough.
So I figured up Logisim to have a fiddle, came up with this:
Interrupt controller using logic gates
interrupt.circ is the actual LogiSim circuit if you wanted to have a fiddle; decompress it. Please excuse the mess regarding the schematic.
On the left is the host-side of the interrupt controller. This would ultimately interface with the 386. On the right, are two “devices”, one on IRQ channel 0x01, the other on 0x05. The controller handles two types of interrupts: “DMA interrupts”, where the device just wants to tell the DMA controller to put data into memory, or “IRQ”s, where we want to interrupt the CPU.
The devices are provided with the following control signals from the interrupt controller:
| Signal | Controlled by | Description |
| DMA | Devices | Informs the IRQ controller if we’re interrupting for DMA purposes (high) or if we need to tell the CPU something (low). |
| IRQ | Devices | Informs the IRQ controller we want its attention |
| ISYNC | Controller | Informs the devices that they have the controller’s attention and to start transmitting address bits. |
| IRQBIT[2…0] | Controller | Instructs the devices what bit of their IRQ address to send (0 = MSB, 7 = LSB). |
| IDA | Devices | The inverted address bit value corresponding to the bit pointed to by IRQBIT. |
| IACK | Devices | Asserted by the device that wins arbitration. |
Due to the dominant/recessive nature of the bits, the highest numbered device wins over lesser devices. IRQ requests also dominate over DMA requests.
In the schematic, the devices each have two D-flip-flops that are not driven by any control signals. These are my “switches” for toggling the state of the device as a user. The ones feeding into the XOR gate control the DMA signal, the others control the IRQ line.
Down the bottom, I’ve wired up a counter to count how long between the ISYNC signal going high and the controller determining a result. This controller manages to determine which device requested its attention within 10 cycles. If clocked at the same 20MHz rate as the CPU core, this would be good enough for getting a decoded IRQ channel number to the data lines of the 386 CPU by the end of its second IRQ acknowledge cycle, and can handle up to 256 devices.
A logical next step would be to look at writing this in Verilog and trying it out on an FPGA. Thanks to the excellent work of Clifford Wolf in producing the IceStorm project, it is now possible to do this with completely open tools. So, I’ve got a Lattice iCE40HX-8K FPGA board coming. This should make a pretty mean SDRAM controller, interrupt controller and address decoder all in one chip, and should be a great introduction into configuring FPGAs.
Well, I’ve been thinking a lot lately about single board computers. There’s a big market out there. Since the Raspberry Pi, there’s been a real explosion available to the small-end of town, the individual. Prior to this, development boards were mostly in the 4-figures sort of price range.
So we’re now rather spoiled for choice. I have a Raspberry Pi. There’s also the BeagleBone Black, Banana Pi, and several others. One gripe I have with the Raspberry Pi is the complete absence of any kind of analogue input. There’s an analogue line out, you can interface some USB audio devices (although I hear two is problematic), or you can get an I2S module.
There’s a GPU in there that’s capable of some DSP work and a CLKOUT pin that can generate a wide range of frequencies. That sounds like the beginnings of a decent SDR, however one glitch, while I can use the CLKOUT pin to drive a mixer and the GPIOs to do band selection, there’s nothing that will take that analogue signal and sample it.
If I want something wider than audio frequencies (and even a 192kHz audio CODEC is not guaranteed above ~20kHz) I have to interface to SPI, and the pickings are somewhat slim. Then I read this article on a DIY single board computer.
That got me thinking about whether I could do my own. At work we use the Technologic Systems TS-7670 single-board computers, and as nice as those machines are, they’re a little slow and RAM-limited. Something that could work as a credible replacement there too would be nice, key needs there being RS-485, Ethernet and a 85 degree temperature rating.
Form factor is a consideration here, and I figured something modular, using either header pins or edge connectors would work. That would make the module easily embeddable in hobby projects.
Since all the really nice SoCs are BGA packages, I figured I’d first need to know how easy I could work with them. We’ve got a stack of old motherboards sitting in a cupboard that I figured I could raid for BGAs to play with, just to see first-hand how fine the pins were. A crazy thought came to me: maybe for prototyping, I could do it dead-bug style?
Key thing here being able to solder directly to a ball securely, then route the wire to its destination. I may need to glue it to a bit of grounded foil to keep the capacitance in check. So, the first step I figured, would be to try removing some components from the boards I had laying around to see this first-hand.
In amongst the boards I came across was one old 386 motherboard that I initially mistook for a 286 minus the CPU. The empty (PLCC) socket is for an 80387 math co-processor. The board was in the cupboard for a good reason, corrosion from the CMOS battery had pretty much destroyed key traces on one corner of the board.
Corrosion on a motherboard caused by a CMOS battery
I decided to take to it with the heat gun first. The above picture was taken post-heatgun, but you can see just how bad the corrosion was. The ISA slots were okay, and so where a stack of other useful IC sockets, ICs, passive components, etc.
With the heat gun at full blast, I’d just wave it over an area of interest until the board started to de-laminate, then with needle-nose pliers, pull the socket or component from the board. Sometimes the component simply dropped out.
At one point I heard a loud “plop”. Looking under the board, one of the larger surface-mounted chips had fallen off. That gave me an idea, could the 386 chip be de-soldered? I aimed the heat-gun directly at the area underneath. A few seconds later and it too hit the deck.
All in all, it was a successful haul.
Parts off the 386 motherboard
I also took apart an 8-bit ISA joystick card. It had some nice looking logic chips that I figured could be re-purposed. The real star though was the CPU itself:
Intel NG80306SX-20
The question comes up, what does one do with a crusty old 386 that’s nearly as old as I am? A quick search turned up this scanned copy of the Intel 80386SX datasheet. The chip has a 16-bit bus with 23 bits worth of address lines (bit 0 is assumed to be zero). It requires a clock that is double the chip’s operating frequency (there’s an internal divide-by-two). This particular chip runs internally at 20MHz. Nothing jumped out as being scary. Could I use this as a practice run for making an ARM computer module?
A dig around dug up some more parts:
More parts
In this pile we have…
I also have some SIMMs laying around, but the SDRAM modules look easier to handle since the controllers on board synchronise with what would otherwise be the front-side bus. The datasheet does not give a minimum clock (although clearly this is not DC; DRAM does need to be refreshed) and mentions a clock frequency of 33MHz when set to run at a CAS latency of 1. It just so happens that I have a 33MHz oscillator. There’s a couple of nits in this plan though:
So, not show stoppers. There’s an example circuit showing interfacing an ATMega8515 to a single SDRAM chip for driving a VGA interface, and some example code, with comments in German. Unfortunately you’d learn more German in an episode of Hogan’s Heroes than what I know, but I can sort-of figure out the sequence used to read and write from/to the SDRAM chip. Nothing looks scary there either. This SDRAM tutorial seems to be a goldmine.
Thus, it looks like I’ve got enough bits to have a crack at it. I can run the 386 from that 33MHz brick; which will give me a chip running at 16.5MHz. Somewhere I’ve got the 40MHz brick laying around from the motherboard (I liberated that some time ago), but that can wait.
A first step would be to try interfacing the 386 chip to an AVR, and feed it instructions one step at a time, check that it’s still alive. Then, the next steps should become clear.
Updated every 5 minutes.
Recent Comments