Category Archives: Hardware
While in China I picked up a USB microscope for $25 USD. It’s an “2MP HD microscope with 600x magnification” according to the box and has 6 LEDs around the camera. I plugged it in and it was found right away by Linux as a video4linux device and works with VLC and Cheese. It’s been sitting next to my computer for about 2 weeks since I got back from China and I’ve been itching for some reason to use it. Tonight I made a small board on my CNC to test some new footprints and I thought it would be the perfect time to use the microscope to check out the cuts made by the bit. Using Cheese I was able to get some good shots of the PCB traces. The pictures are only 640×480, so I’m not too sure where the 2MP claim comes from.
I used my gcode_03 ULP script for Eagle (from my older site) to export the PCB to G-code. When I started working with the CNC for PCB routing I was using a 0.8mm end mill carbide bit, however I’ve noticed I get pretty clean cuts with a 30 degree “V” etching bit run at the max speed of my manually controlled spindle (Yes I know I need to find out the RPMs of that thing). The cuts made by the CNC are impressively clean and without burs. Each cut goes down 0.16 inches and the feed rate is 300mm/minute. The footprint is SOIC-8, the pads are 1.27mm x 0.635mm and the traces are 20mil. The cut is close to 0.5mm. The microscope did show what looks like copper particles in the track which was interesting to see. I’ve made a bunch of breakout boards and switch boards without shorting issues so I don’t know if these particles are big enough to cause a problem. Here are some pictures of the board using the microscope.
Wow, it’s been a crazy few months. I am taking some courses for my masters, started a few contracting gigs and went to China with DangerousPrototypes Hacker Camp. There is so much to write about and I’ve been dropping the ball on Protological. Time to change that. Time for some cool LED stuff!
While in China I picked up a 5 meter “5050” 12V LED strip with 30 LEDs per meter for 90RMB which is $14.50 USD. I didn’t buy the controller because I wanted to control it with a microcontroller of course! The controller chip is a knockoff LPD6803 LED driver chip that listens for clocked data. The only datasheet I could find was from Adafruit here and the english is really, really bad. I didn’t know ‘grey’ == ‘color’?! After some playing around I figured out the protocol for how the data is sent. The commands are 16-bit and shifted out MSB first, the clock is idle low and the data is latched in on the high transition of the clock. The MSB is always 1 to indicate that the value is data and the 3 colors are 5 bits each; allowing for 31 steps in brightness.
1000 0000 0000 0000
One would think that the colors are Red, Green and Blue, however some testing showed they are Green, Red and Blue.
1000 0000 0000 0000
D|Grn ||Red ||Blue|
So if you want to turn on an LED with 1 step of RGB the byte value is 1 00001 00001 00001 = 1000 0100 0010 0001 = 0x8421;
These strips can be chained together, so to ‘reset’ the strip pixel ID and have it listen for a new set of colors you send 32 0’s which is 8 bytes of 0x00. Once I got the protocol figured out it was really easy to hook up a micro and control the strip.
I used an LPC1768 Mbed microcontroller (because it’s super easy) and made a demo program with some simple animations. The strip is 30 LEDs per meter, 5 meters long. Each LED ‘pixel’ is a group of 3 RGB LEDs and they all show the same color. So there are 50 groups of 3 in my 5 meter strip. The way I drive the LEDs is I make a uint16_t array in RAM for the 50 pixels, then create a timer to run through the array and send it out to the strip using the SPI hardware. With 8 bytes of reset, 100 bytes of data, at 500KHz I was able to address the whole strip in about 4ms. I set my timer to update the strip at 10ms, giving me a 100Hz refresh rate.
The rest of the application just writes the data array in memory and lets the timer clock it out to the strip. I included the code here with 4 demos. This will build in the Mbed compiler and uses the P5 & P6 SPI pins on the LPC1768 for data and clock. It should be pretty straight forward to port to an Arduino or other microcontroller, just setup a timer and update the SPI config and write functions.
Here is a video of the demos in action:
And the source file: ledstrip_mbed_demo.cpp
I’ve found myself in the situation a few times where I was trying to explain that PCBs can be routed using a low cost CNC, like the 3040 CNC I purchased on Ebay a while back. Since I have routed dozens of PCBs this sounds obvious to me, however it is not very obvious to some of the engineers I have explained it to, it seems as if they can’t visualize what can be accomplished. In those moments I wish I had an example PCB to show them. Not to mention a few times I was stuck without a quick way to measure small lengths, or I wanted to know the SMD footprint used for a resistor to see if I had one, or when I needed to compare the pin spacing of a cable to see if it is 0.1″. A few days ago I found a post about TinkerRule, a reference PCB that could be used to solve pretty much all the engineering scenarios I just mentioned. I really liked what they did and it inspired me to see if I could make a reference PCB on my CNC in the form factor of a business card to fit in a wallet, that way not only would I have a useful tool, but I would have a demo of the capabilities of my CNC PCB router too!
It turns out that my small 3040 CNC is quite capable of making a 2.125 x 3.25″ PCB business card with a number of useful features, including an inch ruler, centimeter ruler, some reference traces, reference vias, reference holes, and 0.1″ grid. The board also has 150 mil letters so it is easy to read. Plus, since the single sided copper board I used is only about 50 mils thick, it’s only 50% thicker than a credit card, so it isn’t a noticeable addition to my wallet. This was the first pass and there are 2 missed sections, this was due to my setting of the router bit a little too shallow…things to fix on Rev 2.
I already have identified some things I want to change on Rev 2, any ideas or suggestions?
As I mentioned before I haven’t worked with the Arduino family much since I tend to be working on different processors than 8-bit ATMega chips. Recently I have been playing around with an Arduino Yun for a client and had a chance to explore the features of this microcontroller + Linux SOC board.
First I want to say that I think pairing a microcontroller with a Linux SOC is a great idea. The micro allows for very fast and accurate data sampling and GPIO control while the Linux SOC deals with all the networking and file system stuff using the Linux OS. So far I think the Yun is pretty good but there are a few things that are really frustrating.
First, the Arduino IDE and toolchain. I don’t like the fact everything is hidden and you MUST use the Arduino IDE (yes, even for command line compilation). You can’t use Makefiles and the gcc stuff is all tucked away so you can’t see it, and thus can’t modify it easily. Also each ‘sketch’ must be an *.ino file which is a pain in the rear if you are using a C editor like Eclipse. This isn’t so much a Yun issue as a limitation with the Arduino way of doing things. Personally I find a raw gcc binary and a USB programmer to be much better, but that’s what I learned on.
The other thing I dislike is the way the networked “Console” is implemented in the Yun. The Console is a way of sending text out to a PC, similar to the USB serial port on other Arduinos. The issue with the Yun, is to get the text you have to SSH into the device and then do a telnet to a locahost port. Honestly I can’t really think of a better way to get debug information out wirelessly, but it’s really clunky. I am going to be looking into using the USB serial port rather than the Console because it’s much simpler.
My final issue is that it takes >60seconds to get the Linux part of the Yun up and running. Why!? I have a RaspberryPi that boots in <10seconds, how can a 16M Linux install with only about 30 entries in the ‘ps’ output possibly take 60 seconds to boot? I’d also like to know what happens to the Linux system when you pull the power, hopefully I don’t run into some kind of config file truncation due to power loss in the middle of a flash write (Yes, I have dealt with that before).
I’m not a total hater. I do like the fact that you can write a file on the Linux part of the Yun without writing an entire file system for the ATMega. The project I am working on reads lots of values and logs them to files which are then post processed. Having gigs of space on a SD card is great for logging lots of data over time. Also, since the Yun uses SSH, you can SCP and SFTP files off the Arduino wirelessly which is a really nice way to collect all that data.
It’s also worth noting that you can update the firmware via WiFi right from the Arduino IDE. This is a really nice feature for once a system is deployed since it might be in a really difficult to access location. The issue with the WiFi update is that is seems really slow, on my limited tests it takes over 60 seconds to program which can really slow down my code-test-update cycle. I would recommend programming via USB for development and WiFi if you need it for production.
The summary is that while the interface and access is a little clunky, the Yun is pretty good little platform if you need a networked microcontroller to collect lots of information.
I finally got tired of punching numbers into my calculator for debounce circuits so I came up with a small javscript app to determine capacitance, resistance or time for a simple RC circuit. The script is already setup with values for input to a schmitt trigger inverter. This application is based on a single capacitor and resistor circuit as per this image.
I have a project which requires full control of the camera board on a Raspberry Pi from a custom C application, so I recently started looking into getting a toolchain and code running on the Pi. The Raspberry Pi is actually a really powerful and advanced SBC, with a full Broadcom VideoCore GPU and a connection to a 5MP camera that can do full 1080 HD video at 30 FPS. The project I am working on takes a single picture from the camera and saves it to the flash. I could use the raspistill application and some bash scripting, however I want full control over the camera and since eventually I will be processing video from a camera, the access should be as fast as possible by using the GPU. The first step was to build a tool chain and cross compiler to get things working, and then make a test application that uses the Multi-Media Abstraction Layer (mmal) library to access the VideoCore (VC) pipeline. I followed these two articles on how to use crosstool-ng to make a crosscompiler for the Pi. The next step was to make a simple application with some hooks into mmal and link it against the mmal libraries. It turns out the easiest way to build the mmal libraries is to clone the userland code for the Pi and build it locally using your new crosscompiler. I modified the cmake file in the makefile/cmake/toolchain/ directory to point to my custom crosstool-ng compiler rather than the compiler from git (Here are my modified buildme and cmake files).
Everything built successfully and the final step was to add in some mmal variables and function calls and build against the mmal libraries. This was more of a pain than I thought it was going to be. There are like 6 libraries that need to be preferences and 5 include paths for the VideoCore and mmal paths. After a few hours of searching and trial and error I found the correct include paths and library paths for GCC and the linker. One really annoying part was the fact that you have to explicitly add ALL libraries to the ld command, even if they are dependencies of libraries and the .so file is in the same directory as an already linked .so file. Take a look at this image and you will get the idea, all was fixed when I added -l entries for each missing lib. Here is what you need to build and link against if you want to access the camera on the Pi via mmal using VideoCore.
Library include path:
Libraries to link:
I have an electric scooter project that has been on and off again for a while now, I get to it when I can when it’s not cooking or freezing in the garage. The scooter runs on six 12V batteries for a total traction voltage of 60V, the lights/horn/blinkers/etc all run on 12v which requires a 60v to 12v DC/DC converter. I found a cheap 72v to 12v converter on Ebay from a manufacturing company in China (similar to this one) and figured I would spend the $30 and see how it performed. Well what I got in the mail wasn’t a DC/DC converter, but a 24v electric bicycle controller for a brushless DC motor. The interesting thing is the mailing envelope had “Motor controller” on it and not “DC/DC converter”. Here’s the new rule, you get what you pay for. Because I’m sure sending a $30 unit back to China is going to be more trouble than it’s worth, I think I am going to keep the controller and maybe make an electric bike some day…if I can figure out the non-documented pin out of the thing!
Oooh yeah I got 3 ESP8266 WiFi boards in the mail today from SeeedStudios. Now lets make a project! For those that don’t know the ESP8266 is a WiFi to serial board that is only $5-$6 USD. Apparently the board does all the WiFi and ethernet stuff, so all your project has to do is some basic setup and then RX and TX. I’ll be reporting on how easy this is here and posting any projects as well as code for microcontrollers.
Lets start off with a post that dives into one of the uglier sides of electronics, switch bounce. Every time a switch closes, mechanical contacts (which are just pieces of metal) touch each other and complete the circuit. For a short period of time the contacts chatter and open and close the circuit, this is a real nightmare if you are looking for a clean on and off signal. I ran into this issue with a set of limit switches for a CNC machine. I decided to put one of the switches on a scope and see what the bounce time was. Take a look at the scope trace below, as you can see there is about 1.5ms of bounce on these switches for both rise and fall. It’s been a while since I debounced a switch outside of firmware, so I went off looking for some info, what I found was Jack Ganssle’s site with two pretty good articles on debouncing. (While you’re there, check out his newsletter). I dug through my parts bin and found a few 74HC14 schmitt inverters which can be used for debounce since they have a hysteresis between the high and low voltage levels. Running through the equations on jacks page with a 5v supply, 0.1uF capacitor and a 2.37v high signal for the 74HC14 I came out with almost exactly 31K for the resistance.
I had a 33K resistor and a 0.1uF resistor so I hooked them up as per this schematic and left off the input resistor from Jack’s page and the rise time was just about 2ms. There are some other pages that discuss leaving off the input resistor so I decided to see if the response was acceptable. You can see the schmitt inverter flips with a nice clean edge, switch debounced!