Understanding the Intel 4004 clock circuit
Noting that the Intel 4004 was normally sold as a chip set called the Intel MCS-4, the standard clock circuit used appears to be this (from this PDF, kindly provided by this vendor of MCS-4 test boards):
Adventures in exploding power supplies
So this went well... The Intel 4004 microprocessor has slightly weird power supply requirements by modern standards. You see, it needs to be supplied with +5V DC, and -10V DC at the same time to work. (It turns out that this is an artifact of the MCS-4 chipset using PMOS technology not the more modern CMOS. Wikipedia has a good description of the constraints of PMOS, but these include the requirement for a number of supply voltages including a relatively negative voltage.) Now, I found this example circuit in someone else's project: Which to me looked quite a lot like these kits from ebay being fed by an AC power supply: So I ordered a kit off ebay, and then ratted around in the garage to find a random AC power supply. Luckily I found one, because they're not super common compared to the DC power supplies I have huge mounds of. Now of course the kit had no assembly instructions apart from the markings on the PCB, which seemed mostly good enough when coupled with some random googling for polarity information. However, I really needed documentation about the input pins. However, that kit appears to be this aliexpress listing, which…
Raspberry Pi HAT identity EEPROMs, a simple guide
I've been working on a RFID scanner than can best be described as an overly large Raspberry Pi HAT recently. One of the things I am grappling with as I get closer to production boards is that I need to be able to identify what version of the HAT is currently installed -- the software can then tweak its behaviour based on the hardware present. I had toyed with using some spare GPIO lines and "hard coded" links on the HAT to identify board versions to the Raspberry Pi, but it turns out others have been here before and there's a much better way. The Raspberry Pi folks have defined something called the "Hardware On Top" (HAT) specification which defines an i2c EEPROM which can be used to identify a HAT to the Raspberry Pi. There are a couple of good resources I've found that help you do this thing -- sparkfun have a tutorial which covers it, and there is an interesting forum post. However, I couldn't find a simple tutorial for HAT designers that just covered exactly what they need to know and nothing else. There were also some gaps in those documents compared with my experiences, and…
1-Wire home automation tutorial from linux.conf.au 2019, part 3
This is the third in a set of posts about the home automation tutorial from linux.conf.au 2019. You should probably read part 1 and part 2 before this post. In the end Alistair decided that my home automation shield was defective, which is the cause of the errors from the past post. So I am instead running with the prototype shield that he handed me when I started helping with the tutorial preparation. That shield has some other bugs (misalignments of holes mainly), but is functional apart from that. I have also decided that I'm not super excited by hassos, and just want to run the orangepi with the OWFS to MQTT gateway into my existing home assistant setup if possible, so I am going to focus on getting that bare component working for now. To that end, the gateway can be found at https://github.com/InfernoEmbedded/OWFS-MQTT-Bridge, and is a perl script named ha-daemon.pl. I needed to install some dependancies, which in my case were for armbian: $ apt-get install perl libanyevent-perl cpanminus libdist-zilla-perl libfile-slurp-perl libdatetime-format-strptime-perl $ dzil listdeps | cpanm --sudo Then I needed to write a configuration file and put it at ha.toml in the same directory as the daemon.…
Gangscan 0.6 boards
So I've been pottering away for a while working on getting the next version of the gang scan boards working. These ones are much nicer: thicker tracks for signals, better labelling, support for a lipo battery charge circuit, a prototype audio circuit, and some LEDs to indicate status. I had them fabbed at the same place as last time, although the service was much faster this time around. I haven't got as far as assembling a board yet -- I need to get some wire thin enough for the vias before I can do that. I'll let you know how I go though.
Using a MCP4921 or MCP4922 as a SPI DAC for Audio on Raspberry Pi
I've been playing recently with using a MCP4921 as an audio DAC on a Raspberry Pi Zero W, although a MCP4922 would be equivalent (the '22 is a two channel DAC, the '21 is a single channel DAC). This post is my notes on where I got to before I decided that thing wasn't going to work out for me. My basic requirement was to be able to play sounds on a raspberry pi which already has two SPI buses in use. Thus, adding a SPI DAC seemed like a logical choice. The basic circuit looked like this: Driving this circuit looked like this (noting that this code was a prototype and isn't the best ever). The bit that took a while there was realising that the CS line needs to be toggled between 16 bit writes. Once that had been done (which meant moving to a different spidev call), things were on the up and up. This was the point I realised that I was at a dead end. I can't find a way to send the data to the DAC in a way which respects the timing of the audio file. Before I had to do small writes…
1-Wire home automation tutorial from linux.conf.au 2019, part 2
For the actual on-the-day work, delegates were handed a link to these instructions in github. If you're playing along at home, you should probably read 1-Wire home automation tutorial from linux.conf.au 2019, part 1 before attempting the work described here. Its especially important that you know the IP address of your board for example. Relay tweaks The instructions are pretty self explanatory, although I did get confused about where to connect the relay as I couldn't find PC8 in my 40 pin header diagrams. That's because the shields for the tutorial have a separate header which is a bit more convenient: I was also a bit confused when the relay didn't work initially, but that turns out because I'd misunderstood the wiring. The relay needs to be powered from the 3.3v pin on the 40 pin header, as there is a PCB error which puts 5v on the pins labelled as 3.3v on the GPIO header. I ended up with jumper wires which looked like this: 1-Wire issues Following on the tutorial instructions worked well from then on until I tried to get 1-Wire setup. The owfs2mqtt bridge plugin was logging this: 2019-04-08 19:23:55.075: /opt/OWFS-MQTT-Bridge/lib/Daemon/OneWire.pm:148:Daemon::logError(): Connection to owserver failed: Can't connect…
1-Wire home automation tutorial from linux.conf.au 2019, part 1
I didn't get much of a chance to work through the home automation tutorial at linux.conf.au 2019 because I ended up helping others in the room get their Orange Pi is booting. Now that things have settled down after the conference, I've had a chance to actually do some of the tutorial myself. These are my notes so I can remember what I did later... Pre-tutorial setup You need to do the pre-tutorial setup first. I use Ubuntu, which means its important that I use 18.10 or greater so that st-link is packaged. Apart from that the instructions as written just worked. You also need to download the image for the SD card, which was provided on the day at the conference. The URL for that is from github. Download that image, decompress it, and then flash it to an SD card using something like Balena Etcher. The tutorial used 32gb SD cards, but the image will fit on something smaller than that. hassos also doesn't put anything on the Orange Pi HDMI port when it boots, so your machine is going to look like it didn't boot. That's expected. For the tutorial we provided a mapping from board number (mac…
Introducing GangScan
As some of you might know, I am a Scout Leader. One of the things I do for Scouts is I assist in a minor role with the running of Canberra Gang Show, a theatre production for young people. One of the things Gang Show cares about is that they need to be able to do rapid roll calls and reporting on who is present at any given time -- this is used for working out who is absent before a performance (and therefore needs an understudy), as well as ensuring we know where everyone is in an environment that sometimes has its fire suppression systems isolated. Before I came along, Canberra Gang Show was doing this with a Windows based attendance tracking application, and 125kHz RFID tags. This system worked just fine, except that the software was clunky and there was only one badge reader -- we struggled explaining to youth that they need to press the "out" button when logging out, and we wanted to be able to have attendance trackers at other locations in the theatre instead of forcing everyone to flow through a single door. So, I got thinking. How hard can it be to build…
Support for Raspberry Pi and Orange Pi GPIOs in Home Assistant
So, I've been off in the GPIO library salt mines for a while, but am now ready to circle back and document how to get GPIO inputs and outputs working in Home Assistant. This now works on both Raspberry Pi and OrangePi, assuming that my patch gets merged. First off, let's talk about GPIO outputs. This is something which has been working for a while on both platforms (a while being a week or so, assuming you've patched Home Assistant with my pull request, but you're all doing that right?). To configure an output in Home Assistant, you would add the following to configuration.yaml: rpi_gpio: board_family: orange_pi switch: - platform: rpi_gpio ports: PA7: LED Where board_family can be either "raspberry_pi" or "orange_pi". Note that for Raspberry Pis, the pin numbers are always numbers whereas for OrangePi we are using "SUNXI" numbering, which is of the form "PA7". The circuit for this LED is really simple: Now we have a switch we can control in Home Assistant: GPIO inputs are similar. The configuration looks like this: rpi_gpio: board_family: orange_pi binary_sensor: - platform: rpi_gpio invert_logic: true ports: PA7: PUSHYBUTTON With a circuit like this: invert_logic set to true is required because our…