Category: Electronics
Some Short Notes
The ToyBrain project has been on hold for a variety of reasons, mostly time and money. I finally have enough money to order the motor driver chips I wanted from Digikey. They are on back order, but should arrive near the end of the month. Once I have those, I’m going to put together a little video of the first boards doing a variety of motor driving tasks. That video will go into a Kickstarter funding round to get the second edition of the boards produced and populated.
At least one of the ToyBrain boards is going to end up hooked to a computer via the serial port at one end, and a vibrating motor at the other end. I’m reviving an old project to add a teledildonics plugin to Pidgin. It will allow a remote user to use commands like /harder and /faster (and of course /softer and /slower) to control the speed of the vibrator. That one may not make it into the Kickstarter video.
I found an interesting post about laser power ratings recently. It covers the relationship between PWM and laser output power, which is going to be useful for the power supply that I’m building for my laser. Once I build that power supply, I’ll be in the rather interesting position of having designed a cutting laser power supply that can be built from easy-to-obtain materials. Hopefully, that will knock the price down enough that more people can do DIY CNC laser builds. I may also make that PCB available as a kit, so people can build their own.
I also looked up TEA Laser plans again, and started wondering about making a dye laser. The TEA laser emits in the UV range. so it could be used to pump a UV-reactive dye. Vitamin b12 (in energy shot drinks) and tonic water both are UV reactive, so it may be possible to make a yellow or blue laser using a dye that is drinkable. Normally, laser dye is a toxic dye in a toxic solvent, so this would be pretty neat for the home experimenter.
Behold!
I have HEALED this man’s WOUNDED STEREO!
One of the users of a mailing list that I’m on had a nice stereo receiver with one bad channel. Stereo has two channels, and while one worked, the other simply had no output. I opened it up and found that the signal lines from the amplifier run through a relay to the rear panel connectors. I can think of a couple of reasons for this, but the main one is that when you power it up, there is a period where the circuitry of the receiver stabilizes and effectively “boots up”. During that period, it might put some sort of really loud signal out over the speakers (and blow them inside out) unless they are disconnected. Once everything settles, it is safe to connect the speakers. The other possibility is that if you short the speaker connection, the receiver can detect the excessive current flow and disconnect the speaker hookups.
Whatever the reason for them, one of the relays was DPST, with one pole for each stereo channel, and one set of the poles didn’t close when the system powered up. I figured this out by plugging in an audio source, turning the receiver on, and then tracing back from the connector until I found an audio signal. There was nothing at the connector, nothing where the connector joined the PCB, nothing at one pole of the relay, music at the pole it was supposed to be connected to.
The fix was to remove the board with the relay on it, pop off the case of the relay, clean the contacts, push them a little closer together, and put it all back together. If the relay had really been shot, it was a pretty common size, and would have been easy to replace. Overall, the receiver was well-designed for repair, and the service manual was available online. I will give Onkyo props for using one size of normal philips-head screw throughout their case, but did they really need 41 of them?
Notacon Talk on Brain Hacking
This is the talk I gave at Notacon in 2008. It’s kind of goofy, but provides a broad overview of wireheading/neurohacking technologies.
Adding smarts to common materials
I found a couple of neat sites, and figured I’d link them here so they get more google juice, or link sauce, or whatever combination of a wet thing and food seems appropriate.
The first is the MIT High-Low Tech Lab’s Kit of No Parts. This site has suggestions for ways to incorporate electronics into a lot of other materials, such as wood and cloth, to make more engaging interactive objects. Things like speakers built out of seashells are a lot closer to art than useful products, but that’s part of the intent. It also inspires me to build a device that records and plays sound, and hide it inside a very large seashell as an art project.
The second site is called How To Get What You Want, but that’s rather predicated on you wanting fabric sensors, odd conductive materials (felting wool!), hacked toys, and so forth. There are a lot of good ideas here, waiting to be remixed into other cool stuff.
Projector Build
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.
New ToyBrain Board Design
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.
Pride Goeth…
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.
Victory is Mine
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.
Oops
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.
General Solutions
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?
Recent Comments