I should really like I2C more than I do. In principle, it’s a brilliant protocol, and in comparison to asynchronous serial and SPI, it’s very well defined and clearly standardized. On paper, up to 127 devices can be connected together using just two wires (and ground). There’s an allowance for multiple clock-masters on the same bus, and a way for slaves to signal that the master to wait. It sounds perfect.
In reality, the tradeoff for using only two wires is a significantly complicated signalling and addressing system that brings both pitfalls and opportunities for debugging. Although I2C does reduce the number of signal wires you need, it gets dangerous when you have more than a handful of devices on the same pair of wires, and you’re lucky when they all conform to the same standard. I’ve never seen twenty devices on a bus, much less 127.
But still, I2C has its place. I2C was designed to connect up a bunch of slower, cheaper devices without using a lot of copper real estate compared to its closest rival protocol: SPI. If you need to connect a few cheap temperature sensors to a microcontroller (and their bus addresses don’t clash) I2C is a great choice. So here’s a guide to making it work when it’s not working.
Continue reading “What Could Go Wrong? I2C Edition”
[Andrew Sowa] wanted to use an off-the-shelf relay board from Numato Labs. The board lacks a suitable computer interface, which meant that [Andrew] would have to build one, and its input connectors are screw terminals, which meant a lot of wiring. Undeterred, he created an i2c expansion board using an MCP23017 I/O port expander, and with a novel card-edge designed to mate with the screw terminals, solving both problems at once.
Continue reading “i2c Relay Expander Uses Nifty Card-Edge Connection”
PJON, pronounced like the iridescent sky rats found in every city, is a cool one wire protocol designed by [gioblu].
[gioblu] wasn’t impressed with the complications of I2C. He thought one-wire was too proprietary, too complicated, and its Arduino implementations did not impress. What he really wanted was a protocol that could deal with a ton of noise and a weak signal in his home automation project with the smallest amount of wiring possible.
That’s where is his, “Padded Jittering Operative Network,” comes in. It can support up to 255 Arduinos on one bus and its error handling is apparently good enough that you can hold an Arudino in one hand and see the signals transmitted through your body on the other. The fact that a ground and a signal wire is all you need to run a bus supporting 255 devices and they’ll play nice is pretty cool, even if the bandwidth isn’t the most extreme.
Aside from the cool of DIY protocols. We really enjoyed reading the wiki describing it. Some of the proposed uses was running your home automation through your ducting or water pipes (which should be possible if you’re really good at isolating your grounds). Either way, the protocol is neat and looks fun to use. Or check out PJON_ASK if you want to do away with that pesky single wire.
[Alvaro Ferrán Cifuentes] has built the coolest motion capture suit that we’ve seen outside of Hollywood. It’s based on tying a bunch of inertial measurement units (IMUs) to his body, sending the data to a computer, and doing some reasonably serious math. It’s nothing short of amazing, and entirely doable on a DIY budget. Check out the video below the break, and be amazed.
Cellphones all use IMUs to provide such useful functions as tap detection and screen rotation information. This means that they’ve become cheap. The ability to measure nine degrees of freedom on a tiny chip, for chicken scratch, pretty much made this development inevitable, as we suggested back in 2013 after seeing a one-armed proof-of-concept.
But [Alvaro] has gone above and beyond. Everything is open source and documented on his GitHun. An Arduino reads the sensor boards (over multiplexed I2C lines) that are strapped to his limbs, and send the data over Bluetooth to his computer. There, a Python script takes over and passes the data off to Blender which renders a 3D model to match, in real time.
All of this means that you could replicate this incredible project at home right now, on the cheap. We have no idea where this is heading, but it’s going to be cool.
Continue reading “Amazing IMU-based Motion Capture Suit Turns You Into a Cartoon”
Old Mini and Mainframe computers often had huge banks of diagnostic lights to indicate the status of address, data and control buses or other functions. When the lights blinked, the computer was busy at work. When they stopped in a particular pattern, engineers could try and figure out what went wrong by decoding the status of the lights.
[Folkert van Heusden] has an old MSX-based Philips VG-8020 computer and decided to add his own set of BlinkenLights to his system. The VG-8020 was a first generation MSX released in 1983 and featured a Zilog Z80A microprocessor clocked at 3.56 MHz, 64KB of RAM, 16KB of VRAM, and two cartridge slots.
The cartridge slots of the MSX are connected to the address and data buses in addition to many of the control signals, so it seemed logical to tap in to those signals. Not wanting to play around with a whole bunch of transistors, he opted to use an Arduino Nano to connect to his computer and drive the LEDs. In hindsight, this seemed like a wise decision as it allowed him to do some processing on the incoming data before driving the LEDs.
Instead of creating a new PCB, he cut open one of his beloved game cartridges. A switch was added to the slot select control pin (SLTSL) and eight wires soldered directly to the data bus. These were hooked up as inputs to the Arduino. A bank of eight LEDs with limiting resistors were connected to outputs on the Arduino. A quick test confirmed it all worked, including the switch to enable / disable the cartridge. He had to experiment with the code a bit as the LEDs were initially blinking too fast.
A couple of months later, he upgraded his BlinkenLight display to include the 16 bit address, 8 bit data and 8 lines for control signals. To do this, he used two MCP23017 – I2C 16 input/output port expander chips. For the LEDs, he installed a bank of four NeoPixel LED bars. A Pro-Mini takes care of the processing, and a custom PCB in the cartridge format houses all of it neatly. Check out the two videos below showing the BlinkenLights in action.
And if these BlinkenLights got you interested, take a look at this awesome Z80 Computer With Switches And Blinkenlights that has a hand operated crank to advance clock cycles.
Continue reading “MSX with BlinkenLights”
Historically when hams built low power (QRP) transmitters, they’d use a crystal to set the frequency. Years ago, it was common to find crystals in all sorts of radios, including scanners and handheld transceivers. Crystals are very stable and precise and it is relatively easy to make a high quality oscillator with a crystal and a few parts.
The big problem is you can’t change the frequency much without changing crystals. Making a high quality variable frequency oscillator (VFO) out of traditional components is quite a challenge. However, today you have many alternatives ranging from digital synthesis to all-in-one IC solutions that can generate stable signals in a wide range of frequencies.
[N2HTT] likes to build radio projects and he decided to take an Si5351 clock generator and turn it into a three frequency VFO for his projects. The Si5351 uses a crystal, so it is very stable. However, you can digitally convert that crystal frequency into multiple frequencies over a range of about 8kHz to 160MHz.
Continue reading “Triple Frequency VFO on a Bamboo Breadboard”