Month: September 2011
I am working on a portable projector to take to an arts festival in Toronto. I was planning to power it from a 12V lead/acid battery, which would be stepped up to 110VAC by an inverter, which would then be stepped back down to 36VDC at 3A (regulated) to drive an 8000 lumen LED. Tonight, I hooked up the LED, inverter, and battery. It almost works, but the inverter is too wimpy to drive the LED. Instead what happens is there is a brilliant flash as the LED lights, the inverter output voltage drops, the LED driver resets, and then there is another flash and the cycle repeats.
Obviously, this will never do. The inverter is supposed to be good for 140 Watts, and so driving a 100 Watt LED sounds like it should be a piece of cake, but at 110V, the extra 40 watts is really only 360mA (W=VI, so I = W/V (Sort of. For non-resistive loads, there’s power factor correction)). If there’s any extra draw in the LED driver as it starts up, it could eat that right up. It’s also possible that the power rating on the inverter was simply a lie.
Switching to a 200 watt inverter didn’t fix the problem, nor did adding a 17,200uF capacitor in parallel with the battery. However, I did check the battery voltage immediately after running the system, and it was around 11.3V. That’s mighty low for a 12V SLA, so I’m going to borrow the 12V battery charger from work and try it on my batteries. It may be that I just didn’t have a sufficient charge. If that is the problem, it may mean I need to switch to a halogen spotlight, as the 12V batteries may discharge too quickly.
Version one of the ToyBrain boards had a bunch of problems:
- TX and RX were swapped on the serial line header
- The ICSP header was backwards
- There was no debug LED
- The SMD resistor pads for the reset pull-up resistor were too small
- The connection for the reset switch was a 0.1″ header rather than a proper footprint
- There was a lot of wasted space
Despite all of that, I managed to eventually get them working, with a slowed-down version of the Arduino bootloader, adapters for the ICSP and serial headers, and much messing about.
The new board is smaller, measuring about 1.5″ by 1.28″, and adds a proper reset switch, a SMD LED for debugging, corrected resistor footprints, and a (in my opinion) slicker layout. I still didn’t add voltage regulation or mounting holes, but I may be able to get a little space for the holes by moving a few traces in the corners of the board.
My ToyBrain boards are programmable over ICSP, but when I connect them to an FTDI USB-to-serial cable, I can’t load a program into them from the Arduino development environment. The error I get back is that the programmer is not responding, which could be caused by several things, listed here by increasing order of how tedious they are to check:
- I might have some misconfiguration on the USB ports or Arduino IDE. I can eliminate this possibility by using the same FTDI cable to program a known-working Arduino BBB. If that works, I know that my problem is off the end of the FTDI cable, in my own hardware.
- I tried this, and got a working blinking light program on my BBB. This means my cable and computer are fine.
- I might have messed up the bootloader configuration for my board. I think this is somewhat likely, as I’m using the Arduino bootloader on a board that is running at 8MHz. If the Arduino bootloader or IDE requires the Arduino 16MHz crystal for proper timing, it is now running at half the normal clock speed, resulting in the serial timings being double what they should be. I can test this by telling the IDE to attempt to talk to the board at half of whatever the normal speed is, using the platform support in recent Arduino IDE releases. If it’s a timing issue, that should fix it.
- This was the problem. I reflashed with the 8Mhz bootloader from here, and now I can load programs and have them run.
- I might have screwed something up in the reset or power circuitry of the Arduino (I already know I got TX and RX backwards). I can check out the connections with a voltmeter pretty easily. I can also burn an LED blink program to the board with ICSP and see if it runs.
- The power and reset circuitry is fine. I burned a LED blinking test program to the board using the command avrdude -c usbtiny -p m8 -U flash:w:test.hex and got a square wave on port B, so the chip is running code and the fuses make at least enough sense that the onboard oscillator starts.
- I may have used bad fuse settings, and put it in some mode that doesn’t result in the bootloader starting. I can test this by burning my own LED blink program to the bootloader section and seeing if it blinks an LED. This won’t make it load code, but it will at least confirm that the bootloader is getting started.
- This is covered by the previous section. The chip isn’t bricked, and it runs code.
As I suspected in my previous post, I did put the ICSP header on my boards backwards (or more accurately, flipped along its long axis). As a result, I burned up the chip on one of the boards when I plugged the ICSP header in. I also took a closer look at the chip that I had populated two of the boards with, an ATMega48, and found that it doesn’t have a separate bootloader section. The quicker wits among you are realizing that I should have checked that before I soldered it down.
Since one board had a chip that had been operating as a resistive heater, and the other two had chips I didn’t want to use, I was left with one good board.This evening, I managed to burn the Arduino bootloader to that board.
First, I threw together an adapter to flip the ICSP header back to the right layout. Using that and my trusty USBTinyICSP, I programmed the fuses for the chip like so:
avrdude -c usbtiny -p m8 -P usb -B 32 -U lfuse:w:0xc4:m hfuse:w:0xca:m efuse:w:0xFF:m
and burned in the arduino bootloader like so:
avrdude -c usbtiny -p m8 -P usb -B 32 -U ./arduino-0022/hardware/arduino/bootloaders/atmega8/ATmegaBOOT.hex
For the curious, the fuse settings are the same as the ones for the Arduino, as documented here, but with the clock selection set to 8MHz internal clock rather than 16Mhz external clock. I used this fuse calculator to find the proper values.
Since that seemed to have worked, I removed the chips from the other three boards, replaced them with ATMega8s, and put bootloaders on them as well. Now I’m going to add IC sockets for the motor driver chips and see if I can get an LED blink program onto them.
When I added the ICSP header to my ToyBrain boards, I mirrored the footprint so that some of the routing would be easier. I did not, however, correct the actual wiring, so now the ICSP header comes off the wrong side of the board.
This is going to be easy to fix in the next revision, but for now I’m going to roll up a little adapter to get the boards programmed.
More later, when it’s closer to noon than midnight.
There have been two things that I have done several times over the last couple of years. The first one is having a bit of code control an inductive load of about an amp, be it a DC motor, stepper motor, or solenoid. My ToyBrain boards are a general solution to that problem, so I can just drop one in and write the code, instead of reinventing the wheel (or at least the controller for the wheel).
The other problem that I end up solving a lot is having a microcontroller drive an RGB led to make color fades and washes. This shows up in different forms in a bunch of my projects, and is not hard to do. However, I keep doing it, so I might as well have a PCB to make it easy. My goal is to have something that can drive up to about 30A, for three channels, with PWM. I usually use an ATTiny85 for this, along with current-regulated MOSFET drivers operating as current sinks. That actually leaves me with two pins left over for other purposes, so I’ll have some GPIO lines on the board as well.
The point of having general solutions like this is that it saves me from doing the boring parts of a job and lets me get directly to the interesting parts. These sort of programmable widgets are becoming so cheap and simple that they are effectively the dust that real things are made of. There is actually a term for this process: Ephemeralization. AM and FM radios are effectively ephemeral at this point. You can buy a single IC that does everything needed to receive AM/FM audio signals, or get the radios pre-made in units of a great gross from somewhere in China for pennies each. The case it is in no longer needs to look “like a radio” (whatever that means) because the parts are so small and flexible that you can put any sort of case around them and have a radio. Cameras (of a certain quality level, at least) have pretty much gone that way, cell phones and computers are going next.
What kind of world do you get when everything has a computer in it because it was cheaper and easier to build the thing around a general-purpose computing device instead of designing a single-use custom solution?
The ToyBrain boards arrived. I have populated four of them with programming headers and microcontrollers. Two have ATMega8 chips, the other two have ATMega48 chips that I salvaged from some thermostats that I found.
I haven’t bothered fully populating the boards because I want to check that the ICSP headers are working by burning the Arduino bootloader to the chips, and that the serial headers are working by loading a program from the Arduino IDE.
Assuming that I haven’t miss-designed the circuit boards or baked the chips while soldering them, this will provide a smoke-test for the computer side of the boards. I still need to get a bunch of SN754410NE quad half-H-Bridge motor driver chips to handle the output side.
So far, I’ve come up with quite a few applications for the little boards:
- Re-animating gutted toys with new programming
- Controlling a single stepper motor with step/direction signals and limit switches
- Driving up to 4 channels of medium-current LED lights (RGB plus white?)
- Making loud noises by using the quad half H-bridges as push-pull speaker drivers
- Solenoid drivers and control hardware for chimes
I’m very eager to get a few of the boards out to beta testers and see what other people come up with.
For a piece of code I’m writing, I need to break the angle of a turn down into “continue”, “bear left (or right)”, and “turn left (or right)”. The program takes a topological map of points within a building and converts a path through the building into spoken directions. Intuitively, it seems to me, there is some small range of angles that are effectively “continue forwards” or “straight ahead”, some range of angles to the left and right of that that are “bearing” without being “turning”, and some range of angles to the left and right of that range that are “turning”.
Before I go any further, I should point out that this isn’t a study. Anything with n=7 and a population consisting of exclusively white male computer science students in their 20s is not exactly an unbiased sample. It’s a guess, based on the opinions of the people who happened to be standing around at the time.
My procedure was to show the participant a protractor, and ask them to imagine a person standing at the origin and facing the 90° mark. I then asked them what ranges, in degrees, constituted “straight forward”, “bear left/right” and “turn left/right”.
Participant "Straight" "Bear" "Turn" p1 70-110 L 100-140 L 140-180 R 80-40 R 40-0 p2 80-100 L 130-150 L 130-180 R 50-30 R 50-0 p3 60-120 L 130-150 L 130-180 R 50-30 R 50-0 p4 75-115 L 115-125 L 140-180 R 75-50 R 40-0 p5 70-110 L 110-130 L 160-180 R 70-50 R 20-0 p6 88-92 L 92-112 L 160-180 R 88-68 R 20-0 p7 75-105 L 105-125 L 125-180 R 75-55 R 55-0
Based on this, I’m going to say that “straight” corresponds to about 70-110 degrees, “bear” is about 110-130 on the left and 70-50 on the right, and anything outside of that is a “turn”. This is nothing more than a stupid rule of thumb, but if anyone complains, it’s easy enough to change the code.
I could complicate it further and add “bear slightly L/R” and “turn hard L/R”, but I’m not sure the gain in resolution translates to any gain for indoor navigation. Changing how the questions are presented or whether or not the user gets to refer to a protractor would probably also change the answers.
My neighbors are throwing away a pair of Swiffer vacuums. Combined with my ToyBrain boards (when they arrive), those will make some sweet housecleaning robots.
I used Gorilla Glue in several of the projects that I worked on last week. I’ve used it before without incident, but I think the continuous exposure over the week was enough to trigger a reaction. I got symptoms like dyshidrotic eczema, that is, tiny blisters filled with clear fluid and surrounded by raised, itchy, red bumps. On top of that, anywhere that I had already been having an allergic reaction (poison ivy and mosquito bites) flared up with its own constellation of welts. My fingers also swelled up enough to make it difficult to make a fist.
I’ve been treating it by taking dyphenhydramine (benadryl) regularly, and applying 1% hydrocortisone ointment in the morning and evening. The ointment is kind of a greasy mess, so I wear hypoallergenic chloroprene gloves after putting it on. It is gradually getting better, especially on the areas that get the most hydrocortisone coverage.
From now on, though, I’m going to put the gloves on before I use the glue, so I don’t have to use them for days afterwards.