My last post discussed receiving and decoding signals from the Maplin socket controller. Here, I'll describe how I went the opposite way - faking the signal to control the sockets directly with an Arduino.
As it turned out, this was a lot simpler than receiving. For one thing, the transmitter module is just 4 pins rather than 8, and can be directly driven from the Arduino with no further components. For another, I already had a representation of what the signal needed to look like - I just had to drive the transmitter input pin with the right timings.
So, here's some trivial code to do just that - it turns channel 3, ID 2 on for 3 seconds, then off for 10 seconds, repeatedly. The transmitter module plugs directly into analogue pins A3-A5, as shown in the photo. The antenna pin is left unconnected for the time being - in practice, you'd probably want to connect a suitable antenna (or just a short piece of wire, as per the data sheet) to get optimal range.
Maplin have recently had special offers on remote-controlled mains sockets - as cheap as £5 for a socket and controller pair. Since the control frequency is on the standard 433MHz band, and I had a pair of Arduino-friendly 433MHz transmitter/receiver modules lying around, I thought I'd have a play to see if the control protocol can easily be reverse-engineered for use with the Arduino.
So, I dutifully hooked the receiver module up to 5V and an oscilloscope, and started pressing buttons on the controller. Things looked promising - a simple ASK pulse train, probably Manchester encoded.
A single data packet. Not shown is the leading low pulse between each packet - approx 13ms.
I posted previously about a cool ATTiny project by ELM, which implemented wave table synthesis. After playing with that, I decided that at some point I'd like to take it a little further. That point came last night.
My kids' favourite tune is Twinkle Twinkle Little Star, and we usually sing it at bedtime. I recently picked up a cheap moon-shaped wall-mounted night light from Homebase for £5 (no link, sorry - it doesn't seem to be on their website. Also available from B&Q, but again, nothing on the website), and it's pretty useless in its standard form - the batteries last for no time at all, because it uses an incandescent light bulb. So I decided to put it to better use, and convert it to LED lighting, and to put in a music box version of Twinkle Twinkle at the same time.
I picked up some digital potentiometers, partly as a building block for making a programmable filter for the ukulele tuner, but also just to play around with, as they seem pretty cool.
They act exactly like a traditional potentiometer (i.e. there's an end-to-end resistance of 10KΩ, with a 'wiper' that can travel from one end of the resistance to the other), but the position of the wiper can be controlled via digital signals. It seems that they do actually use physical resistors internally, in some fancy switched network. Anyway, these can normally be used to generate a variable voltage, but I'm also interested in being able to dynamically change resistance in order to tune a filter.
Originally, I assumed these would be an I2C interface (previous models I'd seen were), and didn't pay too much attention to the datasheet. I2C is great, because you can use 2 pins to control a whole string of devices, so long as they all have unique addresses. But it turns out that they're actually SPI, which is not so good for small microcontrollers, as even in its minimal form, it uses 3 wires per slave device. I'd ideally like to control 4 digital potentiometers with a single ATTiny85 - with just 5 data pins available (6 if I don't care about being able to reprogram more than once).
It's all well and good being able to place an ATTiny in my universal ZIF ICSP board, flash it, and then put it back in the circuit being prototyped. But wouldn't it be better to be able to flash it in place, without all that tedious plugging and unplugging from sockets?
Well, I could add a 6-pin ICSP header to all my projects, which would make that possible. But it's a bit of a pain to do that, and once the project is complete, that header will never be used again. Seems like a waste.
And so, partly inspired by a post at JeeLabs (although I'd independently been thinking along the same lines), I came up with a different approach - the Frankentiny.
The principle is to create a small daughter board, comprising an 8 pin socket, and ICSP header, which can plug into another 8 pin socket. This way, I can plug the ATTiny under development into the Frankentiny board, and plug that board into the socket in the circuit being developed. When I need to reflash, I just disconnect the power, connect the ICSP cable, and click "upload". As far as the prototype circuit is concerned, this board indistinguishable from an ATTiny.
This takes a little bit of caution to make sure that there are no delicate components connected to the ATTiny pins used by ICSP, but that's not much to ask in return for the convenience.
The previous post discussed my gradual drift to using a dedicated ICSP programmer to reflash AVR chips. This post describes how to make useful ICSP slave boards, to make life easier yet.
First up, some pinouts. I'm mostly interested in the 6-pin ICSP header, and the ATTiny85 (absolutely tiny, not many I/O pins), ATTiny2313 (a bit bigger, tiny memory, but built-in UART and more I/O pins), and ATmega328 (as used in Arduino). These are all drawn on a Mac in "Shapes", by the way. Another experiment, and it seems OK for basic diagrams, if a little buggy. £2.99 from the App Store.
I've only marked the pins that are important for ICSP. Connecting one of these up to an ICSP header is trivial - just connect the corresponding pin labels together between the ICSP header, and an IC socket. Notes:
If you want to flash an IC that's to be fused for an external oscillator, or already is fused that way, then you'll need to do some work with the XTAL1 and XTAL2 pins before the ICSP master will communicate properly with the slave. For simple ATTiny work, you don't need to bother with external oscillators, but for Arduino, you do.
On the ATmega328, the Vref and AVcc pins also connect to Vcc on the ISP header.
Ah - but see how a lot of the pins are all in roughly the same place and order? Well, I wondered if you could connect up a single socket in such a way that it can be used to program any of these 3 chips? Luckily, we can!
Continue reading "Even lazier ICSP programming"
Larry Wall once said that laziness is one of the 3 main virtues of a programmer. I guess that makes me a great programmer... Anyway, this post describes my ongoing quest to make programming an ATTiny as painless as possible, something that I seem strangely driven to achieve.
First, a note of explanation of the technique behind all of this. AVR chips include functionality called In Circuit System Programming (or ICSP, sometimes shortened to ISP). In essence, this allows the non-volatile memory on the chip to be reprogrammed at any time, even when it's already embedded in a circuit. ICSP works by holding the /RESET line low, which disables the normal operation of the chip, and then manipulating some special data lines to effectively communicate with an in-built primitive bootloader. AVR sell a number of programmer boards that implement ICSP, but they can be quite pricey (~ £50). All modern Arduino boards include a 6-pin ICSP header, clearly labelled, which allows your Arduino to be reflashed in situ, if you have such a programmer. To avoid confusion, I'm going to refer to the device that is generating ICSP control signals as the ICSP master, and the device being programmed as the ICSP slave.
The cheapest way to start programming any AVR chip, assuming that you have an Arduino already, is to use the Arduino as an ICSP master, using a sketch that simulates one of AVR's branded boards. This is all documented very well here.
Important note: The ArduinoISP sketch delivered with Ardunio 1.0 is broken. The easiest solution is to install Arduino 022 alongside your 1.0 installation, and follow those instructions (rather than the 1.0 instructions on the same site).
That works pretty well, but there are drawbacks:
It uses up breadboard space, and takes sufficient time to build the circuit that you won't want to dismantle and remantle every time you program a chip.
You have to upload the ArduinoISP sketch to your Arduino each time. If you're working on a project that uses an Arduino talking to another AVR chip, then you have to keep switching sketches. That's dull.
You can't reflash your Arduino's chip, as it can't be both an ICSP master and ICSP slave at the same time.
Having to install two versions of the Arduino IDE is annoying.
I use a Linux box with a cheap (but extended-range) bluetooth dongle to monitor the invertor for my solar panels, and also my central heating monitor. This is fine, except that occasionally the bluetooth dongle seems to crash, and it needs to be physically unplugged to recover. Since there doesn't seem to be any comprehensive way to do this through software (you can reset the device, but it doesn't perform a power interruption so doesn't recover it sufficiently), I decided to make a little hardware dongle to do it for me.
The design is extremely simple - just use an ATTiny to periodically (perhaps once a day) interrupt the 5V USB line. All other USB lines (data +/-, GND) pass straight through. Rather than power the attached device directly from an ATTiny I/O pin (which can only source ~40mA) I drive the attached device's power line through a PNP transistor (in this case rated at ~ 200mA, which is enough for my purposes, but 500mA would be needed for general purpose USB loads).
Continue reading "Automatic USB disconnector"
Using just an ATTiny45 and a loudspeaker, he's able to produce a full, polyphonic musical box using wavetable synthesis, capable of playing tunes with over 300 notes. It's a far cry from those musical greetings cards inserts, which are usually just monophonic square wave tone generators and a piezo transducer.
To achieve the necessary speed and compactness (just 4KB of flash space), it's all written in AVR assembler. I'm not sure I've got time, or room in my head, to learn yet another assembler instruction set, but this is certainly some pretty serious inspiration to get the most of these amazing little chips.
Given that I've got ATTiny85s, with double the flash space, I'd quite like to tinker and add some simple extra functionality to this (e.g. deep sleep mode, playing one cycle of the tune for each press of the reset button; and my own choice of tune) but that might have to wait a while.
Having captured audio over a microphone, and converted to a voltage suitable for the Arduino ADC, the next challenge is capturing the analogue data and converting it into an estimation of the frequency of the current note being heard. That's a fairly tricky problem, as it turns out.
Firstly, the default Arduino analogRead() function is way too slow. At 100 microseconds per read, that's a maximum sample rate of 10kHz - and even that is only possible when tight-looping doing reads, and nothing else. According to Nyquist's theorem, at a bare minimum I need to be able to sample at at least twice the highest note's fundamental frequency, which is probably going to be about 1kHz, so double up to 2kHz. I'd ideally like to sample at least 5-6 times the highest fundamental, and calculating the incoming frequency requires some maths too. So, I decided to look into alternative approaches.
A naive approach to frequency counting is to count zero-crossings in a given direction - i.e. observe the waveform, and everytime it goes from negative to positive, increment a counter. Counting the number of crossings in a given time directly gives you the frequency. It turns out that both the ATTiny85 and the ATmega328 (Arduino) chips both contain an analogue comparator, hooked up in such a way that zero crossing counting can be done extremely efficiently.
Continue reading "Instrument Tuner - Zero Crossing analysis"
I've been experimenting with creating some sort of instrument tuning helper device, as it seemed like a good mix of analog and digital, as well as a useful thing to have around the house after the arrival of a Ukulele shortly after Christmas.
More on the trials and tribulations at the code level later, but I thought I'd experiment with the Fritzing circuit design package as a means of recording my more complex circuits, starting with the AF input stage for the tuner. At first glance, Fritzing seems like everything I need:
It can handle breadboard representations - in fact, you can enter your circuit via the breadboard view and it will automatically generate a schematic and PCB design, if you want them.
Gosh. It seems like forever since I blogged here. And that's maybe because it is.
I've discovered a new playground recently with Arduino, and the world of physical computing, and so it seemed worthwhile to start recording some of my adventures.
Arduino is an incredibly easy way to prototype embedded computing hardware - sometimes known as physical computing, because it's all about the process of interfacing microcontrollers with the physical world. Once upon a time, prototyping such hardware required a lot of knowledge, equipment, money and effort - so although I was capable of doing it, I rarely bothered. But Arduino changes all that - making it trivial to run software within gadgets, and to develop intelligent hardware that can easily interface to a standard PC.
Arduino consists of an IDE, a standardised hardware platform, and a set of libraries, all of which are open source. If you've never tried it, then I urge you to give it a go - you can buy a starter kit that will give you weeks of fun, for less than £50, and it's a completely open-ended hobby.
Anyway, this section of the blog will be used to document some of my Arduino projects, and the lessons that I've learnt along the way. That's assuming that I can tear myself away from playing for long enough to type things up...!
« previous page
(Page 1 of 1, totaling 14 entries)
next page » Frontpage
If you have found my site or software useful, please consider donating a small amount of money using the button below.