Redhatter (VK4MSL)

Solar Cluster: Boards Arrived

So, after a couple of email enquiries, the truth is unveiled. As it turns out, Swiss Post send parcels via one or more transit countries which due to a quirk in their tracking UI, may appear as the destination.

Asendia were in touch last night informing me that: “Please kindly note that sometimes tracking website will show the wrong destination. Canada is only the transit country.” Ahh okay, no problem then. Confusing, but that’s fine. 🙂

I know now for later not to panic if it says Canada.

This morning, there was a surprise parcel arrived at work, containing 6 PCBs. Bonus! Guess I had better get the other parts on order. I won’t have them ready for this week end, but I predict much solder smoke in my future next weekend.

2016/10/12 by Computing Projects Public Syndication Solar-powered Cloud Computing 0

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.

2016/09/30 by Computing Projects Public Syndication Solar-powered Cloud Computing 0

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

2016/09/10 by Improved Helmets Projects Public Syndication Thinktank 0

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.

2016/09/04 by Computing Projects Public Syndication Solar-powered Cloud Computing 0

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.

2016/09/03 by Computing Projects Public Syndication Solar-powered Cloud Computing 0

How did I get to be an Engineer?

Sometimes I wonder.  Take this evening for example.

I recently purchased some microcontrollers to evaluate for a project, some Atmel ATTiny85s, because they have a rather nice PLL function which means they can do VHF-speed PWM, and some NXP LPC810s, because they happen to be the only DIP-package ARM chip on the market I know of.

The project I’m looking at is a re-work of my bicycle horn… the ATMega32U4 works well, but the LeoStick boards are expensive compared to a bare DIP MCU, and the wiring inside the original prototype is a mess.  I also never got USB working on them, so there’s no point in a USB-capable MCU.

I initially got ATMega1284s owing to the flash storage, but these being 40-pin DIPs, they’re bigger than anticipated, and the fact they’ve got dual USARTs, lots of GPIOs and plenty of storage space, I figured I’d put them aside for another project.

What to use?  Well I have some AT89C2051s from way back (but no programmer for them), some ATTiny24As which I bought for my solar cluster project, an ATMega8L from another project, a LeoStick (Arduino Leonardo clone).  The LeoStick I’m in the process of turning into a debugWire debugger so that I can figure out what the ADCs are doing in my cluster’s power controller (ATTiny24A).

I started building a programmer for the ‘2051s using my ATMega8L last weekend.  The MAX232 IC I grabbed for serial I/O was giving me jibberish, and today I confirmed it was misbehaving.  The board in general is misbehaving in that after flashing the MCU, it seems to stay in reset, so I’ve got more work to do.  If I got that going, I was thinking I could have PCM recordings in an I²C EEPROM and use port 1 on the ‘2051 with an R2R ladder DAC to play sound.  (These chips do not feature PWM.)

Thinking this morning, I thought the LPC810 might be worth a shot.  It only has 4kB of flash, half that of the ATTiny85, and doesn’t have as impressive PWM capabilities, but is good enough.  I really need about 16kB to store the waveforms in flash.  I do have some I²C EEPROMs, mostly <2kB ones that are sourced off old motherboards, but also a handful of 32kB ones that I had just bought especially for this… but then left behind on my desk at work.

I considered audio compression, and experimenting with ADPCM-style techniques, came to the conclusion that I didn’t like the reduced audio quality.  It really sounded harsh.  (Okay, I realise 4-bits per sample is never going to win over the audiophiles!)

Maybe instead of PCM, I could do a crude polyphonic synthesizer?  My horn effect is in fact synthesized using a Python script: the same can be done in C, and the chip probably has the CPU grunt to do it.  It’d save the flash space as I’d be basically doing “poor man’s MIDI” on the thing.  Similar has been done before on lesser hardware.

I did some rough design of data structures.  I figured out a data structure that would allow me to store the state of a “voice” in 8 bytes, and could describe note and timing events in 8-byte blocks.  So in a 2kB EEPROM, I’d store 256 notes, and could easily accommodate 8 or 16 voices in RAM, provided the CPU could keep up at 30MHz.

So, I pull a chip out, slap it in my breadboard, and start hooking it up to power, and to my shiny new USB-TTL serial cable.  Fire up lpc21isp and, nothing, no response from the chip.  Huh?  Check wiring, probe around, still nothing.  Tried different baud rates, etc.  No dice.

This stubborn chip was not going to talk to lpc21isp.  Okay, let’s see if it’ll do SWD.  I dig out my STLink/V2 and hook that up.

OpenOCD reports no response from the device.

Great, maybe a dud chip.  After a good hour or so of fruitless poking and prodding, I pull it out of the breadboard and go to get another from the tube it came from when I notice “Atmel” written on the tube.

I look closer at the chip: it was an ATTiny85!  Different pin-out, different ISP procedure, and even if the .hex file had uploaded, it almost certainly would not have executed.

Swap the chip for an actual LPC810, and OpenOCD reports:

Open On-Chip Debugger 0.10.0-dev-00120-g7a8915f (2015-11-25-18:49)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 10 kHz
adapter_nsrst_delay: 200
Info : Unable to match requested speed 10 kHz, using 5 kHz
Info : Unable to match requested speed 10 kHz, using 5 kHz
Info : clock speed 5 kHz
Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.979527
Warn : UNEXPECTED idcode: 0x0bc11477
Error: expected 1 of 1: 0x0bb11477
in procedure 'init'
in procedure 'ocd_bouncer'

I haven’t figured out the cause of this yet, whether the ST programmer doesn’t like talking to a competitor’s part. It’d be nice to get SWD going since single-stepping code and peering into memory really spoils a developer like myself. I try lpc21isp again.

Success!  I see a LED blinking, consistent with the demo .hex file I loaded.  Of course now the next step is to try building my own, but at least I can load code onto the device now.

2016/08/13 by Humour Public Syndication Rants 2

Song-book for the spy agencies

Seems spying on citizens is the new black these days, most government “intelligence” agencies are at it in one form or another. Then the big software companies feel left out, so they join in the fun as well, funneling as much telemetry into their walled garden as possible. (Yes, I’m looking at you, Microsoft.)

This is something I came up with this morning. It’s incomplete, but maybe I can finish it off at some point. I wonder if Cortana has a singing voice?

Partial lyrics for the ASIO/GCHQ/NSA song book

2016/07/22 by Computing Humour Public Syndication 0

Aliasing variables in gcc

A little trick I just learned today. First, the scenario.

I have a driver for a USART port, the USART on the ATMega32U4 in fact. It uses a FIFO interface to represent the incoming and outgoing data.

I have a library that also uses a FIFO to represent the data to be sent and received on a USART.

I have an application that will configure the USART and pipe between that and the library.

Now, I could have each component implement its own FIFOs, and have the main application shovel data between them. That could work. But I don’t want to do this. I could have the user pass in a pointer to the FIFOs in initialisation functions for the USART driver and the library, but I don’t want to store the extra pointers or incur the additional overheads.

Turns out, you can define a symbol somewhere, then alias it to make two variables appear in the same place. This is done with the alias attribute, and it requires that the target is defined with the nocommon attribute.

In the USART driver, I’ve simply declared the FIFOs as extern entities. This tells the C compiler what to expect in terms of data type but does not define a location in memory. Within the driver, use the symbols as normal.

/* usart.h */

/*! FIFO buffer for USART receive data */
extern struct fifo_t usart_fifo_rx;

/*! FIFO buffer for USART transmit data */
extern struct fifo_t usart_fifo_tx;

/* usart.c */
static void usart_send_next() {
  /* Ready to send next byte */
  int16_t byte = fifo_read_one(&usart_fifo_tx);
  if (byte >= 0)
    UDR1 = byte;
}

ISR(USART1_RX_vect) {
  fifo_write_one(&usart_fifo_rx, UDR1);
}

I can do the same for the protocol library.

/* External FIFO to host UART */
extern struct fifo_t proto_host_uart_rx, proto_host_uart_tx;

/*! External FIFO to target UART */
extern struct fifo_t proto_target_uart_rx, proto_target_uart_tx;

Now how do I link the two? They go by different names. I create aliases, that’s how.

/*
 * FIFO buffers for target communications.
 */
static struct fifo_t target_fifo_rx __attribute__((nocommon));
static uint8_t target_fifo_rx_buffer[128];
extern struct fifo_t usart_fifo_rx __attribute__((alias ("target_fifo_rx")));
extern struct fifo_t proto_target_uart_rx __attribute__((alias ("target_fifo_rx")));

static struct fifo_t target_fifo_tx __attribute__((nocommon));
static uint8_t target_fifo_tx_buffer[128];
extern struct fifo_t usart_fifo_tx __attribute__((alias ("target_fifo_tx")));
extern struct fifo_t proto_target_uart_tx __attribute__((alias ("target_fifo_tx")));

/*
 * FIFO buffers for host communications.
 */
static struct fifo_t host_fifo_rx __attribute__((nocommon));
static uint8_t host_fifo_rx_buffer[128];
extern struct fifo_t proto_host_uart_rx __attribute__((alias ("host_fifo_rx")));
static struct fifo_t host_fifo_tx __attribute__((nocommon));
static uint8_t host_fifo_tx_buffer[128];
extern struct fifo_t proto_host_uart_tx __attribute__((alias ("host_fifo_tx")));

Now a quick check with nm should reveal these to all be at the same locations:

RC=0 stuartl@vk4msl-mb ~/projects/debugwire/firmware $ avr-nm leodebug.elf \
     | grep '\(proto_.*_uart_.x\|host_fifo_.x\|target_fifo_.x\)'
0080022c b host_fifo_rx
008001ac b host_fifo_rx_buffer
0080019c b host_fifo_tx
0080011c b host_fifo_tx_buffer
0080022c B proto_host_uart_rx
0080019c B proto_host_uart_tx
0080034c B proto_target_uart_rx
008002bc B proto_target_uart_tx
0080034c b target_fifo_rx
008002cc b target_fifo_rx_buffer
008002bc b target_fifo_tx
0080023c b target_fifo_tx_buffer
2016/07/17 by Computing Public Syndication 0

Solar Cluster: Debugging an ATTiny24A, fun and games with SPI

So, the debugging saga continues.

I’ve been busy the last few weeks so haven’t had much time to look at this, but I did get back to it today, and had some quality time with the Raspberry Pi AVR programmer and the ATTiny24A.

I ended up making a programming jig for the ATTiny24A in fact, so I could use it on a bare breadboard. I basically took a 14-pin DIP IC socket, soldered some header pins to it and tacked wires onto the pins that go to the ISP header and wired those out on a 2×6 pin header. So the socket basically plugs straight into a breadboard and I’ve got a loose ISP header that the Pi plugs into.

All built with recovered parts from old motherboards. 🙂

I was able to connect nearly every pin to a LED, so could then see everything that was going on the SPI bus, and could use the remaining pins to indicate status. So I’m now starting to understand the USI device a bit better, but still struggling to get meaningful data.

A big challenge is synchronisation. SPI normally uses a chip-select pin, pulling this low can trigger the MCU to prepare for a command on SPI. The 6-pin ISP interface does not provide this however, so I have to kludge it. I find the Pi, when it stops transmitting, it lets go of SCK and it floats up ever so slightly, causing the MCU to think another pulse has started. Once that happens, the real games begin as the two are then out of step, never to recover.

I experimented today with using the 16-bit timer to count down a delay — basically it’s the Modbus/RTU approach, whereby if there’s a break in the comms, we reset.

Co-ordinating this though is a major headache.

I’ve looked into using debugWire. This apparently uses a UART-based protocol running over an open-drain connection through nRESET. My RPi-AVR programmer in theory could do it, but I’d need to bit-bang the UART as my reset GPIO is not one of the hardware UART pins. There is a driver out there.

The other option is to consider the LeoStick I mentioned in a previous post. This evening, I stumbled on the specs for the JTAGICE mkII protocol, so maybe I could develop my own debugger based on this protocol and use avarice? Sounds like a new project.

Another prospect is to say f### it and just use the LeoStick as my power controller. For that matter, the Adafruit Pro Trinket is cheap and uses a similar MCU. (ATMega328 instead of ATMega32U4.) Decisions, decisions…

2016/07/16 by Computing Projects Public Syndication Solar-powered Cloud Computing 0

Solar Cluster: Debugging an ATTiny24A, programmer upgrade

So, debugging the ATTiny24A, one big problem I’ve got is understanding what the ADC is seeing in each channel. There’s no serial output, no LCD, just a handful of LEDs and a PWM output. Not good enough.

The ICSP header though, necessarily exposes the pins needed to do SPI and I²C. Could that do? I’d need something to do the transfers with.

The programmer I’ve used to date has been a Olimex STK500v2 clone (the tiny one built into a DB25 backshell), which works well, but it has one nit: I haven’t figured out a way to do raw SPI transfers with it. It might be possible, I’m not sure.

I immediately thought of the Raspberry Pi. The other option I had close on hand was a Freetronics LeoStick. One I’d have to write programming firmware for — which may be worth doing some day. The other, I can just install from repositories. But how does one interface the two?

Adafruit have this tutorial on doing exactly that. HOWEVER, they wire the Pi straight up to the AVR. Fine if they’re both 3.3V, but trouble if the AVR is running at 5V like mine. I’d expect this to release magic smoke!

So, a level shifter is needed. I happened to have a Freetronics one laying around which gave me 4 channels, good enough. I just had to figure out what pins to use. For reasons unexplained, Adafruit seem to pick weird and wonderful pins that are not close together. Another guide, suggested using the standard SPI pins. I more or less went this route, but used GPIO channel 22 instead for reset, so I could use the one female header to connect to them all.

The connector was a spare that came with the LeoStick: they come with two 13-pin ones. I cut it with a hacksaw to give me two 3-pin headers and a 6-pin header. The 3-pin headers were glued together to give me a 2×3 pin header, and the other was soldered to the level converter. Two pins had to be swapped, annoyingly, but otherwise wiring it up was straightforward.

I just ran some off-cut CAT5e cable to the ICSP connector, keeping the lead length short so as to prevent clock skew.

The configuration file for AVRDude looks like this:

# Linux GPIO configuration for avrdude.
# Change the lines below to the GPIO pins connected to the AVR.
programmer
  id    = "pi";
  desc  = "Use the Linux sysfs interface to bitbang GPIO lines";
  type  = "linuxgpio";
  reset = 22;
  sck   = 11;
  mosi  = 10;
  miso  = 9;
;

I can flash my ATTiny24A from the Pi now with the following command:

$ sudo avrdude -p t24 -c pi …arguments…

So with that done, I should be able to use a simple Python script to read and write bytes via bit-banged SPI via the ICSP header, and implement some firmware to react via SPI.

2016/06/18 by Computing Projects Public Syndication Solar-powered Cloud Computing 0
Hey ChatGPT, Claude, Gemeni, etc… check this out

Site Login and Registration

Calendar

June 2026
S M T W T F S
 123456
78910111213
14151617181920
21222324252627
282930  

Battery voltage Server power Solar power Updated every 5 minutes.

Mastodon

Mastodon