Originally posted on www.letsmakerobots.com

I'm posting this collection out of frustration and perhaps defeat. I've been working on several projectss for the last two months, trying to finish something. I'd gotten addicted to that "It works!" moment I think anyone gets when they see a LED blink. Sadly, I feel I've failed at most of these projectss.

The second reason I post is posterity.

I've grown to appreciate failure, given how much I learn from it. Of course, I'd much rather learn from other's failures. So, I figure I'd try to write up all my blunders for others.

The last reason is tactical humility.

I figure I might be able to finish some of these projectss if someone tells me what the hell I'm doing wrong (though, it might take less time if someone tells me what's right).

Alright, enough self-loathing and belaboring.

Contents:

1. Arduino heart rate sensor.
2. Bluetooth 4.0
3. Heatsinking a high-power LED
4. XL4432 -- long-range RF
5. SMD version of Atmega Fuse Doctor
6. Arduino Thermostat
7. Raspberry Pi and Remote Compiling

Pulse Sensor Re-Creation -- A Story of Heartbreak:

Pulse Sensor Attempt 1:

For a awhile now I've been interested biometrics. I figure if my wife ever finishes graduate school and becomes my sugar-momma, then, I'll pursue my pin-headed dope in Experimental Psychology. Developing my own sensors, or at least having an intimate knowledge of how they work would probably help me getting into a program (damn education inflation). So, I've been watching out for open-hardware sensors for a bit, and it seems these guys pulse-sensor was ever increasing in popularity.

As always, I still believe the best way for a dumb-guy like myself to learn smart stuff, is by taking apart stuff the real smart-people make. But being a non-conformist, I avoided trying to re-make their sensor. Still, after viewing other schematics I found ( 1 , 2 , 3 , 4 , 5 ), I decided I'd be such a non-conformist I'd conform and go with the popular sensor.

After a glance, it seemed great; a small lightweight heart-rate monitor that was Arduino compatible. Then, I noticed the design files were put together in Design Spark . "No problem, I thought, I'll just export them over to Eagle, then I can play with the PCB layout, maybe switch those 0603s to 0805s and send it off to OSHPark."

Come to find out there is no easy way to export Eagle files from Design Spark.

New plan, I'll just follow the Pulse-Sensor schematic and re-create the entire board in Eagle (all half inch of it). And that's what I did. I'd post those Eagle files, but, they suck and don't work. I had made several major mistakes.

To begin, I had to create several Eagle components for the board. The op-amp, LED, and light-sensor. Respectively, MCP6001 , AM2520ZGC09 , and APDS-9008 . None were a real threat. I made each part according to the datasheets. Then, I strung together the schematic in Eagle, switched to the PCB layout, and threw my pieces down. But for some reason I thought, "I should replace the 0603 passives on this board with 0402s."

I figured, if I could shrink the board even more I'd be happier, right? I mean, smaller is better--so the women say. Well, it was the only thing on this board version I didn't regret.

In the end, the board was sent off to OshPark for a $2.00.

When the post came, as my friends across the lake say, I was excited about the itty-bitty board. Unfortunately, I started my string of disappointments after I populated the board.

Like I said, I didn't regret the 0402s at all. They all soldered on pretty easy. Though, I think my primary beef with 0402s over 0802 is when it comes to tweezerless soldering. See, when I go to solder 0802s I have this process of tapping one pad with a bit of solder, and taking a resistor for example, hold the 0802's body with tweezers in my left hand while my right hand keeps the solder warm. Then, I simply run one end of the resistor into the pool of solder, move the iron away, then, when the solder cools, let go with the tweezers. To get the other end, I'll put the tweezers down and simply tap the other end with solder. Voila .

I'd try to get a picture of this process, but, I don't have a third hand yet. Though, these folk are working on it.

This doesn't work with 0402s. One, holding the body of a 0402 with tweezers is like a giant trying to tight-rope-walk a piece of dental-floss. But the problem really begins in the second step, when I set the tweezers down to tap the other end, the heat from my iron shots through the little 0402 to the other end, loosening the hardened side, as soon as this happens, the entire 0402 stands on end, hugging my iron. Of course, this ends with me quickly pulling the little guy off with my fingers (not smart, but each 0402 is like $.20).

A few notes:

The LED fit through the hole in the PCB, but I was worried the drill wouldn't be wide enough (I guessed a bit).

OSHPark takes non-squarish shapes, though, they charge you as if it were square.

Open-source hardware is not the same as Open-Source (but lacking some key pieces of information) Hardware. I believe the Pulse Sensor is the latter.

The only piece that couldn't be soldered with a solder-iron was the light-sensor. All of it's pads are tucked under the actual component. So, I used the good ole' overturned clothes-iron.

Anyways, once I had all the components in place? I threw on a few wires, attached it to the Arduino, uploaded the sketch, turned it on. And ... smoke.

Waah-waaah.

I'd like to tell you this story has a good end. But, like the title suggests, it's an incomplete work.

I started trouble shooting the board: I checked the wiring, the schematic, the Eagle components I made. I tried 3.3v, different sketches, touching the sensor, not touching the sensor, praying to Cthullu. Nothing. Just pretty smoke.

Finally, I gave up.

(Well, as much as I ever give-up on anything. Stupid obsessive nature.)

Pulse Sensor Attempt 2:

Well, weeks passed and I was working on other projectss, but the little pulse-sensor board kept begging for another chance.

I decided to try again. I'd have no more trying to ignorantly trouble-shoot the thumbnail sized board, so I went back to the designers' original files, downloaded DesignSpark, and pulled up the schematic and board. After briefly examining them I began to realize I was a little off on the board layout. Then it hit me, I could always copy the design manually, it shouldn't take long since I had the schematic already together and the components made.

Well, below is a video of that process :

After I caught the two errors (wrong MCP6001 and disorientation of the APDS-9008) I felt a little better sending it to OSHPark again. Two dollars later I wasn't as sure, but the boards were on their way regardless. While I waited, I jumped on Texas Instrument's website and ordered samples of (what I hoped was) the correct op-amp.

When the boards came in I did something frugal that made me kick myself later: I pulled the components off the old board to put on the new board. It sounded like a great financial strategy at the time, but added more work when I realized my new little board still didn't work . Now, I had to question whether it was the components, the board, or I also ran into this article that scared the crap outta me. Although, it gave me a lot of respect for those guys. Re-soldering 2,000 SMD leds in a night was no small task. And perhaps it welled slight guilt in me since I was working hard to circumvent their more than deserved profit off their $25 sensor .

That's pretty much it: So far. I've not had the time to give her another go, but I will. The next round I'll actually create breakout boards for the main components to make sure my soldering is not the problem. I'm really only concerned with the light sensor, since the pads are practically DFN (no exposed legs). But I hope to have this tied up in the next week to month.

1. .29 ( Digi-Key )

2. Light Photo Sensor: 1.23 ( Digi-Key )

3. LED: .79 ( Digi-Key )

4. 0603 Schottky Diode : .50 ( Digi-Key )

5. Passives: ~ 2.50 - Resistors: 1 x 470k, 1 x 12k, 2 x 100k, 1 x 10k, 1 x 3.3Meg - Capacitors: 3 x 4.7uF, 2 x 2.2uF

6. OSHPark Boards : $ .67 (minimum 3 boards, costing $2.00. 3/2.00 = ~.67)

Total (approximate): $ 5.98

HM-10 -- Bluetooth 4.0 Module -- The story of a Broken Breakout

UPDATE (8-3-13)

I've corrected the problem; yes, it was the ground plane under the antenna.

Here is an updated build.

If anyone knows me, they know I'm cheap. But I prefer to think of myself as "resource efficient." This has led me to do a bit of shopping at FastTech . Their stuff isn't as cheap as the eBay, but pretty damn close.

Well, that's a prelude to this story. Awhile back a co-worker's head-phone jack on his phone broke. He said, "Don't you fiddle with that stuff? You should just make me a Bluetooth headset." Externally: Joke-deflected. Internally: Challenge-accepted.

I started looking through different Bluetooth ICs. I mean, why buy Bluetooth ear-phones for under $20 when you could make a set for twice that? Especially, when only takes around a 100 hours of "fiddling" time? Americans are so lazy.

Well, the first IC I landed was this guy: LMX9838 . And it wasn't until I had finished the Eagle part, designed the schematic, and was working on the board did I look at how much it retailed for. Well, I wasn't going to order samples every time I wanted to embed Bluetooth in my projects, besides, isn't Bluetooth 2.0 power hungry?

Well, back to looking through ICs.

And on the second browsing I ran across Texas Instrument's new CC2500 series. Righteous.

I saw the possibility of making a Bluetooth 4.0 device with this little chip CC2540 . It's a SoC (system-on-chip) with Bluetooth 4.0 capability. Again, righteous.

I ordered several samples of the chip from TI. While I waited on the post I began wading through all the terms: BLE, BT 4.0, Smart Energy, etc. I searched to see if anyone else had already created the schematic, PCB, and firmware that would be needed to drive these little guys. Here are a few discoveries I made.

Hardware:

Here's a complete PCB for the CC2541 , which seems to be optimized for low-power consumption. I will say, the entire chip is pretty well documented on the TI forums, but overall, the hardware aspects are the least.

I downloaded the Eagle files and began ripping off all the unnecessary circuits. (I think there is a lipo charger circuit?) The goal was to bring the board size small enough it would be cheap to print.

But as I got to ripping pieces of close to the antennae noticed how easily it would be to screw the whole thing up. And since I hadn't built my spectrum analyzer yet, I would be stabbing in the dark each time ordered a version of the board.

This realization on top of all the 0402s and the DFN package, well, I decided I wanted to play with the chip on a completed board, with already installed firmware before I sunk time into a personal development (fancy words for: I got lazy ).

I won't cover the firmware or software, since I took another route and didn't thoroughly Google-search them. But do know, within the collective in the Texas Instrument's cc2500 forums there is almost everything you'd want. Although, be prepared, if you desire to create your own firmware you'll need to brush up on your C and AVR programming.

This brings me back to Fasttech.

I noticed one day they had these HM-10s on sale. Waahoo! A pre-designed CC2540 board with firmware already created? Firmware that is AT commandable? I bought two.

I figure I could at least get a feel for the chip and see if it was something I really wanted to sink time into developing.

Well, a week later I got these little guys.

They aren't bad little boards. But, they were little. I tried soldering on jumpers to the ant sized grooves, it didn't go well. I knew to really start playing with the board I needed a breakout.

So I made one:

HM-10 Breakout v.9 (don't use, sucks)

When the breakout boards came in I was surprised they worked (I'm usually surprised when something I make turns out :).

They straddled my breadboard nicely. And it allowed me to play with all the bits of the board I wanted: V, GND, Rx, Tx, and PIO1 (pin for connection-status LED).

Since the little HM-10 operated on 3.3v I carefulIy put it in the breadboard and pulled out my Sparkfun Lilypad FTDI (first huge mistake) to interface with the board's serial.

Well, I couldn't figure out what was wrong; the board would not respond to AT commands (I was using Realterm ). I mean, I had plugged the 3.3v into the HM-10's power, so I know it wasn't getting too much voltage. I even checked it with a multi-meter (about a hundred times).

Well, as those of you who are smarter than me (so all of you?) probably already know: The Sparkfun's Lilypad FTDI is designed to provide the Lilypad with 3.3v, but the Atmega-328-P on the Lilypad is actually 5v tolerant. So why drop the voltage on the Rx and Tx lines? Of course, this wasn't a conclusion I came to for many hours, really, until I started randomly probing the boards with the multi-meter.

Damnit.

Well, there goes $13.98 (yes, I was slow enough to kill both boards).

Discouraged, I ordered two more boards.

You see, when it comes to electronics my driving code is...well, this guy explains it better .

I also bought real FTDI breakout and a logic-level converter . I was tired of frying things.

When everything came in, I took the broken boards off by heating the bottom of the breakout with a heat-gun until the HM-10 was loose. I cleaned the top of the breakout boards with some solder wick. Then, soldered the new HM-10s on.

Video of Soldering the HM-10 to Breakout

I wired the whole mess up on a breadboard and was surprised when I actually got a response in Realterm.

AT

AT+OK

Victory! (hey, I've learned to enjoy even small triumphs)

I had to use specific settings in Realterm to successfully communicate with the HM-10

Under the "Port" tab

• Buad: 9600
• Parity: None
• Data Bits: 8
• Stop Bits: 1
• Hardware Flow Control: RTS/CTS
• Software Flow Control: Receive--Yes, Transmit--Yes

Under the "Echo Port" tab

• Echo On: Yes
• Monitor: Yes

Then, under the "Send" tab typed in my AT commands and hit "Send ASCII":

This worked pretty well. Every time I typed "AT" it shot back, "AT+OK"

So, I started digging for the rest of the AT commands. And dig I did.

Apparently the HM-10 is developed by www.jnhuamao.cn . These folk are somewhere over in Jinan's Hi-tech Development Zone . Anyways, luckily we have GoogleTranslate and I was able to get through several of their current documents. But not before I lost a time on trying to get the module to respond to AT commands no longer supported (like the connection command).

Eventually, I found the current English manual

HM-10 Manual

The manual answered a lot of my questions. It came with a complete pinout (even a schematic!). After playing with the commands I was re-naming the module, resetting it and running many other needed commands.

Now for a live test.

I got my work phone, iPhone 4S, which is equipped with Bluetooth 4.0. I tried using the stock Bluetooth connection found under settings and it couldn't find my little HM-10. I switched to LightBlue and was able to not only find my little module (named Bob), but it connected, and allowed me to send serial data to Realterm! Success.

I thought I was on my way to slapping these little HM-10s on a robot, plugging a Bluetooth 4.0 dongle on my PC, sitting back and letting magic happen. That's not quite how it worked out. I ordered this Bluetooth dongle and when it came in quickly discovered that the drivers needed to provide it with magic powers were not available. I tried it all, TI's tool pack, random internet drivers, shady internet drivers. It simply wasn't going to happen with that dongle.

I figured that's what you get buying the cheapest dongle you can find. So, I switched over to Newegg and bought this dongle, making sure it came with supported drivers.

When I got it in, it still didn't work (I believe this is completely a software issue, so I expect different outcome if I were to play with these dongles on a Linux machine).

I thought, "Well screw it, I could always make a microcontroller, RS232, and another HM-10 into my own dongle."

Um. But I couldn't figure out how to get two of the modules to connect. I set them both up on a breadboard, and they both had the little blinking LED (meaning not connected), but the little guys just wouldn't get it on.

So, on a whim I emailed Jnhuamoa and asked.

Hello,

I'm currently working on interfacing two of your HM-10 modules. I'm having trouble because there seems to be no pairing command. I use "AT+VERS?" and it tells me I'm using version HMSoft V303. Is this old firmware? If it is, is there newer firmware available I could download and write to the cc2540? I've looked through your website and I cannot seem to find any firmware upgrades. But, I only read English, so I'm curious if I've missed it in translation.

I appreciate any help you may give,

--Thomas Brittain

To my surprise, they responded

Dear sir

Thanks you for choose our products.

Between two HM-10 modules, pair and connect process is automic.

You only need to make sure that one of the HM-10 module set to master mode, another is salve mode (use AT+ROLE command), and the TYPE setting of the two modules is the same (use AT+TYPE command) and the PIN number is also same (use AT+PASS command).

If the master module has connected to other modules, please execute AT+CLEAR command first.

Our website have module work flow chart, you can have a look.

:)

Best regards

HMSoft

guocg

But...now what? I mean, I could wire the guys up to an Arduino-bot but it would be one dongle per robot. What I had wanted was several Bluetooth bots per one dongle.

To be honest, I never expected to use the Bluetooth as a bot tether, I was just looking for an application other than my co-workers ear-phones.

After reading the manual some more, and tinkering with the AT commands, I sent another email over to Guocg.

Good sir,

Thank you for your quick reply.

I felt stupid after your instructions. I had the HM-10 paired in less than a minute. A very simple process. Thank you.

But I do have a few others questions. Is there any way to have more control over the connection process? I'd really like to have a micro-controller (PIC, Atmega) in between give the HM-10 very specific commands, which would involve the master connect to several slaves depending on the need of the master. I can see how the PIN could be changed, but would it be fast enough for one master to manage several slaves in real time?

This is the process I'm going to attempt:

1. Setup 3 slaves with unique PINs

2. Setup 1 master connected to a microcontroller.

3. Set master to AT+IMME0 (work when given the command).

3. The micro-controller will pull the HM-10 reset line then give the following commands:

a. AT+CLEAR

b. AT+PINslave1

c. AT+WORK

4. The micro-controller will send a 'X' to slave1

5. Slave1 will have a micro-controller pulling the reset line every half a second or so, unless, it gets a connection with the 'X' string.

I'm not sure of the speed of this process, but I believe it would let me switch between modules remotely. I have read about some of the older releases of the firmware for the module HM-10. Is there still no chance in getting those? I understand now that pairing with the HM-10 modules is very easy, but it also seems very restricted.

Thanks for all the help,

--Thomas

This time, I think I got a blow-off response. That's fair. I'm a hack not an industrial developer.

Dear sir

You shoule make sure that HM-10 modules AT+TYPE vlaue is 1. PinCode set command is AT+PASS.

Best regards

HMSoft

Guocg

So, no chance on getting older firmware. I started preparing to implement my Atmega & HM-10 team. I strung up the HM-10 on the backpack breadboard of Silas' bot (my son's bot).

I was beginning to get really frustrated with the level conversion problem. I had tried the CD4050 , but found it was uni-directional, meaning I still had to have a converter for the Rx bus (HM-10 and Arduino), or, unplug the HM-10 from the Rx bus every time I wanted to upload a sketch to the Arduino. In the end, I started doing that and used a voltage divider for the Tx line.

That's when I ran into another problem: Range .

More specifically, the lack of range. The little modules would lose connection if more than 7 inches away. Ugh.

Back to trouble-shooting. I couldn't really pin-point the problem. I did find the modules had a power setting (AT+POWEx, X=0-4). But no matter what setting I put the modules on, they didn't have range greater than 7 inches. But I did notice when I was moving the slave around I could get a connection by aiming the master towards the slave. But if I rotated the module, it would lose connection. I didn't want to do it, but I started reading about telemetry.

I can't say I learned anything, though, I did develop a theory. The ground planes I put on my breakout board were screwing with the telemetry.

A second time I breakout the heat-gun and pull the HM-10s off their breakout boards. I get back in Eagle and re-design the breakout to remove the ground planes underneath

HM-10 Breakout v9.3 (untested)

I thought as long as I was going to have the boards printed again, I'd go ahead and add some sort of level conversion. I reviewed a few different SMD chips (CD4050, 74LVC245, TXB0108, etc.) but I found the chip was either uni-directional or overpriced. In the end, I decided on the same design as Ada's and Spark's 4-channel I2C converters.

This design was cheap, scalable, and required little layout room. It was fairly simple, voltage divider from high-to-low, and a tricky little N-Channel MOSFET on the low-to-high. The low-to-high circuit is actually bi-directional (up to a certain speed) but I'm simply using it to raise Tx voltage from the HM-10 to the Arduino, while protecting the HM-10 from uploading a sketch.

** **

And, that's it so far...sorry.

I've already got my BSS138s and I should get the new boards Monday.

The LED and Heatsink

A bit ago I realized I needed to start documenting better and figured a picture was worth a thousand words, so at a 32fps x 1,000, well, in short video documentation should kick-ass (I submit for further evidence chickenparmi 's works :). Well, I got to trying to figure out how I was going to make these videos. That's when I came up with the idea of a piece of wood hanging from the ceiling--feel free to copy this design, it is open-design.

Well, I attached a board with a hole on it so my iPhone could lie there and take videos of whatever my hands were doing. But I noticed there simply wasn't enough light in the hacking hours (after the wife's asleep) to do a proper video. That's when I began looking into cheap high-powered LEDs. They aren't too difficult to work with, the items I ended up needing were.

• PSU ~$6
• LED $4.15
• Heatsink Paste $6.15 (though, reviews say this is better)
• Heatsink $5.48

Total ~ $21.48

This may seem high, but the heatsink paste was used for many other things; I made 3 other LED track lights, and other LED lighting projectss with it, and I've maybe used 5% of the tube. And the PSU has doubled as a work-bench power supply :)

As many other projectss, this one isn't done. The original plan was to add an array of light-sensors to adjust the light as move my hands around, thereby auto-correcting for light imbalances in the videos. That part isn't done.

But I jump ahead. When I first started this little projects I had no idea how to work with high-power LEDs. My little ignorant self assumed they were like 20ma LEDs--right? Well, I quickly figured out that heat displacement was the single most important issue. Which is why I ordered a 800 lumen LED 3 weeks before I ordered a heatsink and paste.

Then, it came to the problem of finding out of my heat sinking was adequate to the massive LED. (I think a 60 watt tungsten produces 800 lume as well? And I know they can cook little cakes--what? It was my sister's Easy Bake , oven not mine.) I digress, so being dyscalculia I was trying to find out if I was heat-sinking proper without delving into higher math. That's when I remembered I had my thermocoupler together from the coffee roaster I built. I strung the coupler together with an Arduino and i2c LCD, giving me a pretty accurate and robust temperature sensor.

I looked for a bit, but I couldn't find the information on the theremal breakdown on the 800lm LED. Eventually, I thought I'd use masking tap to tape the coupler probe against the face of the LED and wire it up (with an appropriate resistor , of course).

The LED was on 1.5 seconds before it blew up to around 180 F. Uh, ya, I broke out the heatsink. This time, I attached the LED to the heatsink with a bit of thermal paste. I think attached the two screws, which further pressed the LED against the heatsink. Then, I put coupler probe against the face of the LED. I bit off the last of my finger nails and flipped the LED back on. This time, the temperature sensor went up much slower . And after a few minutes stuck around 112 F. Of course, I didn't know if this was beyond the point of thermal breakdown, but I assumed since my own body temperature wasn't far off, and I wasn't exploding, then it would probably be ok. I also touched the face of the LED and was able to leave my finger own for longer than 30 seconds. This I've found to be the most empirically reliable test. With mounting evidence I decided to cut another hole in my board-from-the-ceiling...thing and attach the light. And there we have it. I'll report when I've added the light-sensor arrays.

XL4432 Breakout -- Telemetry is Voodoo

While I was reading about telemetry I discovered these little boards for $3.98 and grew curious if I could do anything with them, other than bricking them. I was very curious about the claim on range, "1000 meters." Even with the BS de-modifier bringing the range down to around 500 meters, that was still something I would love. So I ordered two and made breakout boards for them.

They came in and right away I had macabre feeling that reminded me of the HM-10 boards. Well, I've not played with them enough to know if I've killed them. I go pissed off with my logic-level converter slipping and feeding the board with 5v (a cheap jumper wire came loose from the breadboard).

I stopped what I was doing and re-made the breakout board to include a TXB0108 ( Digi-Key : $2.30). This is the same little chip that's in Ada's 8-Channel Bi-directional logic-level shifter.

XL4432 Breakout Eagle Files ( not yet tested)

That's really the whole story here, well, except I've been trying to find information on hooking these little guys up with Arduinos for when I do get them wired with a voltage translator. I've found much thus far, but this seems promising. Sadly, I can't figure out how he's got the XL4432 wired up by his poorly drawn schematic(?). Anyone care to give an opinion as to whether those grounds are connected? Logic and CtC both state, "Always, always , connect all grounds." And if I remember my EE schematic lingo, isn't dot on connections most often used when there is an extraordinary node ?

Oh well.

Atmega Fuse Doctor & Pogo Board

I'm not patient. At all. Which lead me to brick a few Atmega boards ( 1 , 2 ). This upset me, especially since one of those chips was ~$12-17. I had bricked the chips trying to set their fuses in Atmel Studio. Due to the price of these chips I feel it was natural for me to begin looking for a solution. And apparently the Fuse Doctor is one such solution. In essence, it uses the high-voltage programming functions built into Atmel chip.

I thought, "Great. A way to save my chips!" But...I ran into a problem when I saw the board build, it was an etch a home design. And I still do not have pant free of ferric chloride stains. So, I set to re-designing the board into a version I could send off to OSHPark.

I found out the designer had a SMD version of the board ready to go. But, after looking it over I came to the conclusion it would simply be to expensive to print. So, I set out to shrink it.

Remade SMD schematic

In the end, I printed a board for around $12. But like the rest of the items here, it didn't work as expected. The problem had to do with an extra node I missed, which led to a short-circuit around the voltage regulator. So, I just sliced the trace and was able to at least get pulled up in Atmel Studio and the hex file written to the chip. So, in theory, if I can correct short-circuit, supply it with 12vs, and connect it to the Atmel chips, I should be able to restore them.

You might see in this image where I'm providing the board with a pre-regulated 5vs through a via. This was to circumvent the short-circuit around the on-board regulator. Also, I had to attach my AVR wires on the other side of the 1k resistors to get the board signature read in Atmel studio.

Here's the materials: BOM .

Kariloy--who has a complete Fuse Doctor by the way--reminded me that even if I finished my board, I probably shouldn't hook it directly to the bricked board. Rather, I'd need to attach to the chip directly. Of course, in the original fuse doctor, this was done by a DIP socket. But I don't use dips... So, I began to think I should just give up on the idea.

Then, I remembered Pogo Pins . I jumped on eBay to see if I could find any pins with a small enough head to fit against a TFQP lead on chips I used. These are the pins I ended up ordering.

When they came in I was pleased to find they would probably be small enough to fit against a single lead without touching its neighbors. I then started looking for a way to create a jig. I settled on using HDPE (cutting board) I had left-over. I figure I could drill holes in it using the bits I had left over from the Hunter S. Thompson board debacle using OddBot's old drill-press.

<----- OddBot's drill press (thank you OddBot ;).

When I got ready to drill the holes, I got into Eagle and printed out the footprint of a 32-TFQP chip. I cut that out and then cut my HDPE to the same size, making two pieces with enough room for the drill guide in the center. I then drilled two holes in adjacent corners from the other. I put a couple of 4-40 screws and nuts to clinch the two pieces of HDPE together. The idea being, I could spacers between them later and slip the pogo pins through the top, solder the wire on its bottom, then let them rest on the bottom piece of HDPE. Not sure why I state all that....the picture I think explains it.

After I had the hole thing screwed, tapped, and clinched, I ran out to OddBot's drill press, fitted it with the smallest bit I had and tap over one of the pads. I then pulled out one of the small pins and was surprised to find it fit snuggly.

And that's where I stopped, the main reason was not wanting to have to lookup the pinout for the high-voltage serial programming interface on the Atmega-328-P.

Thermostat

I'm not going to write this up until I do something different then the guy I stole it has done.

My wife, Bek, asked me awhile back to make her a smart thermostat, which I replied, "I'm only at the dumb-thermostat skill-level. Will that do?" She glared, so I Googled for some planes.

I found this guy's Arduino thermostat and I realized I had most of the parts already lying about.

-- Arduino Uno

-- I2C Real Time Clock

-- I2C LCD

-- Seeed Relay Shield

-- Dallas 1-wire Temperature ( DS18B20)

The idea is pretty simple, the voltage line is tied together on all the legs of the relay shield and the Arduino connects to it. The Arduino reads the temperature from the sensor, checks the time on the I2C RTC, and prints both to the I2C LCD. Also, if the time is correct (after 4:00 PM) it will automatically kick on the AC. I've got it all together and working, just not tied to the AC lines. I was trying to find a way to power it, since all the AC lines are 24v and there is no ground. So, I bought:

• PSU (for laptop): $10.75
• Cord : $1.65
• DC-DC Converter : $1.96

Which gives me 15v, 6A unregulated, or 4.5-40v at 1.6a.

Now, looking back, this projects is more expensive than buying a smart thermostat, and I don't recommend it. The main reason I went with this build was because I owned everything but the temperature sensor and PSU.

Distcc and Gstreamer on Raspberry Pi:

When I began playing with the OpenCV I fell in love. I just felt it has so much to offer us, but I had really kept my tinkering limited to what could be done on the Raspberry Pi. When I finished the little face tracker on the Pi, I knew it would work well as a sensor, but would not approach the level of function I wanted. In short, the Pi simply could not give me the speed I needed. I pulled up OpenCV on my desktop (I wont go into the specifications, just know it's faster than the Pi) and realized pretty quick I'd need to send the video data from the Pi to the desktop if I was to get the results I wanted.

So, I began playing with cheap ways to send video data to the desktop. I started by attempting to use Gstreamer to pipe the video data from the Pi, over my WiFi, into OpenCV on the desktop. Twenty hours later...I realized I was too dumb to make this happen. I began reading.

Put simply, there are so many compatibility issues with this process. I still think it is possible, I just got worn out trying to figure it out. And as I understand it, not all of Gstreamer's development plugins work on the Pi. Then, it was a question of what was going to capture the video (Motion, FFMPEG, etc), and whether one, if any, of these programs liked to play with OpenCV, not to mention, a video pipe that came from the Raspberry Pi. There is no need to say, but I'm going to anyways, it was a mess.

I've built Gstreamer and FFMPEG on the Pi more times than I can count (not many, I count to like 5). This got me to thinking, "This would probably go faster if I could compile these beefy programs on the desktop. After doing a bit of digging through cross-compiling literature, I decided on Distcc . It seems pretty nifty. It is a genuine remote compiler, meaning there are no SD card swapping and mounting, unmounting. Getting it to run on the Pi was the trick.

I won't go through all my wasted time and effort to sort out how to setup Distcc; and, like the other projectss described here, I'm still not done. Though, this guy's post has helped me a lot. I've learned a lot about Bash scripting and have written a script to setup Distcc, mind you, this script doesn't work yet, it's like the rest of the post, incomplete:

!/bin/bash

scriptname - description of script

Text color variables

txtund= $( tput sgr 0 1 ) # Underline

txtbld= $( tput bold ) # Bold

bldred= ${ txtbld }$( tput setaf 1 ) # red

bldblu= ${ txtbld }$( tput setaf 4 ) # blue

bldwht= ${ txtbld }$( tput setaf 7 ) # white

txtrst= $( tput sgr0 ) # Reset

info= ${ bldwht } ${ *txtrst }** # Feedback

pass= ${ bldblu } ${ *txtrst }**

warn= ${ bldred } ${ *txtrst }**

ques= ${ bldblu } ? ${ txtrst }

Sample

echo "$bldred How are you today? $txtrst"

sudo apt-get upgrade -y

echo"$bldred 16% $txtrst"

sudo apt-get update -y

echo"$bldred 32% $txtrst"

wget https://toolbox-of-eric.googlecode.com/files/libiberty.tar.gz

sudo tar -xvf libiberty.tar.gz

cd /home/pi/libiberty

sudo ./configure --enable-install-libiberty

sudo make

sudo make install

echo"$bldred 48% $txtrst"

cd

cd /home/pi

sudo apt-get install cmake -y

echo"$bldred 64% $txtrst"

sudo apt-get install subversion autoconf automake python python-dev -y

echo"$bldred 80% $txtrst"

cd

cd /home/pi

pwd

echo # The remote machines that will build things for you. Don't put the ip of the Pi unless >>.bashrc

echo # you want the Pi to take part to the build process. >>.bashrc

echo # The syntax is : "IP_ADDRESS/NUMBER_OF_JOBS IP_ADDRESS/NUMBER_OF_JOBS" etc... >>.bashrc

echo # The documentation states that your should set the number of jobs per machine to >>.bashrc

echo # its number of processors. I advise you to set it to twice as much. See why in the test paragraph. >>.bashrc

echo # For example: >>.bashrc

echo export DISTCC_HOSTS= "192.168.0.102/16" >>.bashrc

echo >>.bashrc

echo # When a job fails, distcc backs off the machine that failed for some time. >>.bashrc

echo # We want distcc to retry immediately >>.bashrc

echo export DISTCC_BACKOFF_PERIOD=0 >>.bashrc

echo >>.bashrc

echo # Time, in seconds, before distcc throws a DISTCC_IO_TIMEOUT error and tries to build the file >>.bashrc

echo # locally ( default hardcoded to 300 in version prior to 3.2 ) >>.bashrc

echo export DISTCC_IO_TIMEOUT=3000 >>.bashrc

echo # Don't try to build the file locally when a remote job failed >>.bashrc

echo export DISTCC_SKIP_LOCAL_RETRY=1 >>.bashrc

echo >>.bashrc

sudo git clone --depth=1 git://code.opencv.org/opencv.git

cd opencv

sudo mkdir redist && cd redist

sudo apt-get update -y

sudo apt-get install distcc -y

sudo apt-get update -y

echo"$bldred 100% $txtrst"

I'm embarressed to say how much time I spent fiddling with trying to get Distcc to work properly on the Pi. And so much time wasted was my fault. In the end, it was the manual that saved me.

Because I didn't really understand the symlink in this scenario I was having a hard time figuring out how Distcc calls the correct compiler. From what I inferred, a symlink was created to replace gcc, c++, cpp, cc, g++. Then, when any of these were called, the symlink would redirect the data to the remote compiler on the desktop. So, when during first go I had at installing Distcc didn't work because the $PATH variable was incorrect, I thought, "Well, if it's creating a symlink to another compiler, I should just delete the local compilers on the Pi--they're not needed anyway. That way I'm sure I'll get the remote." Due to this stinky logic I issued this command

mv local.compilers localcompilers.old

Sadly, it wasn't until I read the manual (hey, it's a long damn manual) did I discover that a "local pre-compiler is used before the data is sent to the remote compiler." Meaning, every time I disabled the local compiler I done-broke-it.

If the symlink to Distcc comes up first in the $PATH, it calls it as the pre-compiler, then removes it from the $PATH variable. Distcc then calls the the next compiler in the $PATH variable, this time, to it should be the remote compiler.

Given I removed the local, the first compiler it would find it treated as the precompiler, then removed it, leaving no compiler to do the real compiling.

This caused me to get errors stating there was no compiler found.

I discovered all this waiting on one of my clients to finish a mental-health screening. It definitely confused him when I hit my head against the wall and said, "Son-of-a..."

I'd been digging around in the manual on my phone.

To sum up, I know now that both the real compiler and the symlink to distcc must be in the $PATH variable, they just have to be in the correct order.

But as all the tales of woe here, it is unfinished.

Originally posted on www.letsmakerobots.com

UPDATE: I discovered the link I had was referring (which is the true stock image) is unuseable unless update and upgrade are run. Sadly, you can't do that with a 2gb image. Regardless, I've switched the image to the updated (as of writing this) Angstrom image. Please double check and make sure you've got the latest image:

http://beagleboard.org/latest-images

Replace the paths in steps 8 & 10 (but I'll try to keep it up to date). Again, it is unfortunate but you need a 4gb or greater microSD to use these instructions.

**MAIN: **

As I stated, I killed my stock Angstrom on the Beaglebone Black (B^3).

I pieced together how to restore it.

You'll need your B^3, microSD card, and Ethernet connection.

(WiFi dongle can replace the Ethernet, if you got it working before I did. And if you did, where's the walkthrough :P?)

1. Download Angstrom

Angstrom

This fellow provides several B^3 distros, one of them being the stock Angstrom.

2. Download and install 7-Zip.

http://www.7-zip.org/

3. Download Image Writer (Win32diskimager).

http://sourceforge.net/projectss/win32diskimager/

If you are using Linux, you might try:

https://help.ubuntu.com/community/Installation/FromImgFiles

4. Unzip the bbb_angstrom_ga.img.xz file

** **

5. Use Win32diskwriter to write stock Angstrom to your microSD

1. Open Win32diskwriter, hit the Blue Folder icon.
2. Select your Angstrom bbb_angstrom_ga.img file.
3. Make sure your microSD is your PC, and it is selected (usually listed as H:).
4. Hit Write.

6. Remove the microSD from your PC, put it into the Beaglebone Black, and boot from it.

See video

7. Use PuTTY (or your favorite SSH program) to access the Beaglebone Black.

8. Download the stock distro.

This is so we can put the image on the eMMC, note you must have the Beaglebone Black connected to the internet for this step.

Type:

wget https://s3.amazonaws.com/angstrom/demo/beaglebone/Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone-2013.04.13.img.xz

** **

9. Write the Angstrom Stock img to your Beaglebone Black eMMC.

This next step is going to write the image file to your Beagle's eMMC.

Two notes, it is going to take awhile, if you are curious if it is still installing, use the LED activity lights to guide you. When the PuTTY window gives you back to the command prompt and the LEDs are slowed, you're good to go to the next step. Oh, second note. Try not to power down the Beagle during this step.

Type:

xz -cd Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone-2013.04.13.img.xz > /dev/mmcblk1

10. Shutdown the Beaglebone Black

Type:

shutdown

11. Remove the microSD and power back on the Beagle. It should now boot like you bought it (unless, of course, I screwed up. Feel free to yell at me and I'll fix these instructions).

If you followed this process you'll see these instructions can be used to write any image file to the eMMC. Let me know if you get a different distro working (consistenly).

Now, I'm going to turn to getting Arch Linux going. Unless, someone else has it working... JerZ? :)

Hope you're all well.

8/25/13:

This fellow here has made some pretty nifty walkthroughs on the rtl8192 and the Chronodot (DS3231) RTC on the Arch Linux. Though I've not attempted his instructions (been burnt out on this board) I believe his instructions will get a reliable WiFi connection with the rtl8192, using Arch Linux, on the B^3.

• rtl8192 with Arch Linux
• Chronodot (eBay: DS3231 )

Also, when I get the energy, the pinout at the bottom of this page has a mistake or two. As Zaius pointed out.

EDIT: Ok. Don't use the pinout until I research more. I'm getting conflicting information on what pins are what in Mode 7. The reference manual is stating one thing, but other sources are agreeing with me. I'm guessing Zaius is dead on; version issues. When I've got it sorted I'll update.

7/3/13:

Not much yet, still working on stable wifi. I thought I might as well share my work log; embarrassing as it may be.

If there are some Linux wise in the crowd (especially those knowing Arch Linux) would you mind taking a look at my work flow? I've got the wifi module working, though, it's not as stable as I'd like.

http://cthomasbrittain.wordpress.com/2013/07/03/installing-8192cu-module-on-the-b3-running-arch-linux/

6/22/13

Wow. Sorry all, been more than a month since I updated this post.

I've not given up on the BBB as a robot platform; I realized I didn't know Linux well enough to begin tweaking it on embedded devices (well, devices lacking community support, at least). I've spent the last month reading about Linux and trying to wrap my head around it (that and fixing all of our bust-a-mucated cars).

I grew up Microsoft and over this last month all household computers have switched to dual-booting Ubuntu 12.04 and Microsoft X. And router will soon make the switch to OpenWRT.

Back to the BBB; the Realtek WiFi dongle that drove me mad has been solved by these guys . I've not had time to attempt their walkthroughs, but it is on the agenda.

• Walkthrough to setup the rtl8192cu drivers

I haven't found an Arch Linux image file, so I thought I'd cook one and post it for anyone who needs it.

[Arch Linux for the Beaglebone Black -- 6-20-13]

If anyone actually downloads the image, will you confirm it works for you?

Off topic a bit, I'm not sure if anyone else uses iDevices; but I did run into this app that I greatly enjoy.

ServerAuditor

It'll let you tunnel (SSH) into your Linux devices from either from an iPhone or iPad X. I've enjoyed this for two reasons: I can keep an eye on how a program is compiling on the Raspberry Pi while watching a movie with the family, and, I like the feeling of running Linux on a closed system. I understand it's a falsity, but it's still comforting.

I hope all are well.

5/20/13

Well, I think I could best describe this point in economic terms. It's the where I've realized my productive efficiency is being restricted due to the current inabilities of technology.

Figure 1

In essence, this graph shows that I cannot reach my desired productive efficiency (getting the B^3 to do the tricks I want it). Really, I'd be happy at point C (even though point D is probably better for me and my family). The problem is technology limitations are restricting me from getting to point C on the curve. And it's bugging the hell out of me. At first, I thought this was completely due to my ineptitude (which is partially true), but there is another barrier, a seemingly hidden one.

The current Beaglebone driver technology is a hidden barrier to this productivity point.

I've read the warnings TinHead gave on treating embedded devices like computers. But if they don't carry some extrordinary functions then what separates them from really, really fast microcontrollers? No. I'm pushing to have some basic PC functionality.

For instance,

1. WiFi capability.
2. Easy access to a graphical interface (note, I'm not stating GUI).
3. Ability to utilize higher-level programming languages (Python, C++, etc).

Really, that's it. A few features to allow rapid prototyping while haranessing the power of open software.

To me, if these three features are achieved, then I feel like the device is complete. Though, I should state, I've realize these three features are no simple feat.

So, where's the Beaglebone Black? Not there.

Some things not supported that will need to be for me to get to point C (Fig. 1).

1. Ability to plug in cheap, low-power WiFi dongles and get them going in under an hour . Let's be honest. Cheap is what 90% of us will go with. It allows us to do more with our budgets. Therefore, if an embedded device in anyway can utilize cheap peripherals, then let's focus on making it happen. 1
2. Better power-management on the software side . Several distros will shutdown the board during boot-up, as the peak above 500mA. The designers suggestion? Don't plug anything in until the board is up. Sounds ok, right? Well, don't forget there is no hot-plugging on the USB, microSD, or HDMI. The drivers haven't been written yet. I'm pretty sure this is due to drivers, since I've read through the BBB datasheet and the power supply hardware seems sound.
3. Ability to adjust the HDMI output . At one point, I had one point, I was trying to get Arch Linux up and I couldn't get in via SSH. So, I plugged it into the only HDMI monitor I have and tried to adjust the ssh.config file. The problem? I couldn't see what was commented out due to the overscan. I dig through Google group where the board designers rest; guess what? There is no current way to adjust the video output. 2

Therefore, my conclusion (though, my insanity is rising), is:

Figure 2

All this to say, my wife has taken away my Beaglebone Black until that green line moves farther out.

Yes, I am little-cat whipped, but she has said, "You're doing this to relax, not work a second job. I'd rather you work on some other projectss for awhile." Hey, being married is the only thing keeping me sane. Well, her and you guys (and girls, if Max didn't run them off :P).

5/16/13:

I've finally got the Black Bone near where I've got my Pi. Here, the old Bone is running an updated Angstrom (4gb) build, using WiFi dongle , and is connected to a 1A wall-wart (connected to microUSB not barrel-jack). When I'm off work today I'll try to complete a "Box to Wireless" walkthrough for good 'ole Angstrom.

(Question, anyone else feel like there's a Mason's conspiracy going on in the embedded world?)

I think I got near understanding TinHead's post: Don't treat an embedded device like a PC? I dunno.

5/15/13

I was able to get my WiFi dongle up by adding the realtek8192 kernel. Not sure all I did, but it works. So, as soon as I can get some repeatable steps, I'll post a walkthrough of setting the Beaglebone Black up with PuTTY, VNC, and WiFi dongle.

5/14/13:b

Was able to get RealVNC to pick up Angstrom. Working on getting WiFi dongle up.

5/14/13:a

I added some links to Bonescript GPIO walkthroughs (PWM, Analog, Blinking).

5/12/13:b

I've created a visual guide to mode 7 pinout (added below).

5/12/13:a

I'm pretty frustrated. So, I'm going to back off working on the board until Tuesday when my 8gb microSD comes in. At that point, I'll use this to reflash my eMMC boot partition and start working two different projectss: Getting Arch Linux going well, and giving in and update && upgrade my Angstrom. Both, I'll try to write up.

Jerz , or anyone else with a BBB, if you have any notes to add, if you don't mind shooting me an email I'll update this post.

Hope everyone had an awesome mother's day.

5/11/13:c

May I encourage anyone who has yet to order their B^3: Wait.

There are several intense issues being worked out on a hardware-software level. Until then, I feel you'll be as frustrated as me. Bdk6's pun says it all: This board is being a bitch.

Some updates:

• The package manager that came with Angstrom was actually broken for awhile, and no one bothered mentioning it to the community. Instead, there were many posts titled "why won't opkg work?" Now, I believe it will work if you run update && upgrade, of course, to do that you must have an SD card since it will be larger than 2gb.
• I got Arch Linux up, briefly (it takes both eMMC and SD).
• I lost the appropriate boot file for my eMMC. (While attempting Arch Linux).
• There doesn't seem to be an easy way to flash eMMC back to stock (I've got to wait for a bigger card).
• One of the only cool things I've seen yet is a one wire(ish) pc.
• The developers are pretty stressed out. I don't see solid support for a bit. And already seems like a us vs. them between the developers and open community
• I'm tired. Who's taking over?

5/11/13:b

So, I attempted getting my WiFi dongle setup (again) using Angstrom's package manager . I found that everything I tried installing using their package manager would shoot back an error. I read, and I believe the problem is the following must be run to catch the Angstrom stock package manager up with desired packages.

opkg update ** opkg upgrade **

I ran them, and guess what? The eMMC does not have enough space to hold the updates. Mother-of-a-Beagle!

Sadly, I'm using a microSD card from an old phone, which is only 2gb. My 8gb is on order.

This, in my opinion, puts the Beaglebone Black on the same level as the Raspberry Pi ; that is, it must have a SD card before you can use it (a card larger than 2gb). If someone else finds a way to install things on the B^3 without updating it, let me know, I'll correct this critique.

5/11/13:a

Wrote up a guide to restore Angstrom to the eMMC .

5/10/13

I screwed up the eMMC partition while trying to get Arch Linux on the Beagle.

5/9/13: Oh, dear lord. It's true. Lack of community support kills the Beaglebone.

It took me nearly 9 hours to setup an OS on an MicroSD.

I'll write it up tomorrow night, after some rest.

Ubuntu on Beaglebone Black:

5/6/13

I got my Beaglebone Black (BBB, B^3) in today. I thought I'd share my unboxing and general thoughts.

Please don't take this as Mr. Jones on a Sunday drive, rather, I want to provide the touch-n-feel information for every robot builder here. In short, I don't want everybody to waste $45 if the BBB is going to turn out to be Beagle sh..., well, you get it.

(Hey, Raspbery Pi puns could fill a library, I can't make one BBB pun. Shesh.)

BBB Development Group:

https://groups.google.com/forum/?fromgroups=#!categories/beagleboard/beaglebone-black

This is a good place to find info to your specific problem.

Beaglebone Black Educational Material (aka, bathroom reading):

B^3 Manual:

http://circuitco.com/support/index.php?title=BeagleBoneBlack#Hardware_Files

Original Beaglebone tutorials

(these were found by JerZ , thank you sir).

http://www.youtube.com/playlist?list=PLF4A1A7E09E5E260A

Hardware interfacing:

http://www.nathandumont.com/node/250

Robot Support for B^3:

This was found by Vishu ,

" Robotic Operating Software for BBB "

Get Vishu or MaxHirez to explain it; I'm still trying to make a light blink :(

RPi vs BBB discussions:

http://www.element14.com/community/thread/23575?tstart=0

http://www.raspberrypi.org/phpBB3/viewtopic.php?t=41489&p=336995

**Beaglebone Pinout: **

JerZ was trying to explain to me there are several modes for the B^3 pins (he's run Hello World on it, and I'm sure by this moment he's run Blink), Regardless, I thought I'd try to whip up a visual for robot building on the B^3.

Keep in mind, these are the pin names -- you'll have to look up on page 69-73 of the reference manual to know how they might be used. Although, almost every pin can be used, regardless of its intended function. Their functions are defined by the software, each pin having 8 modes (0-7).

http://circuitco.com/support/index.php?title=BeagleBoneBlack#Hardware_Files

For example, if your bot is a quadrocopter: You find a real time kernel for Linux and you'd probably set the pins to MODE 7 turning the non-essential pins into GPIO (i.e., sacrificing HDMI, eMMC, etc. lines to GPIO).

JerZ also found this site:

http://blog.pignology.net/2013/05/getting-uart2-devttyo1-working-on.html

Which seems to be an excellent guide on accessing the mux'ed pins (haven't worked through it yet).

I found this robotics group that put some walkthroughs together on using the GPIOs by way of Bonescript.

1. Blinking a Led
2. Analog
3. PWM

If anyone else following this, please double-check me, I'll make corrections if needed.

Beaglebone Black and Raspberry Pi:

These are some of the differences I've noticed between the Beaglebone Black and the Raspberry Pi.

| | | Est. to Upgrade Rpi or BBB | Est. Difficulty to Add | | Real Time Clock | 1 | 0 | | $ 2.30 | Medium | | Processor Speed | 1GHZ | 700MHZ | | $ 4.76 | Medium | | Power Switch | 1 | 0 | | $ 0.83 | Easy | | Reset Switch | 1 | 0 | | $0.83 | Easy | | Boot Switch | 1 | 0 | | $0.83 | Easy | | GPIO | 65 | 26 | | $ 8.85 | Medium | | Flash Memory | 2GB | 0 | | $ 5.66 | Easy | | MicroSD (smaller footprint) | 1 | 0 | | $ 4.35 | Easy | | Serial Ports | 4 | 1 (that's accessible) | | $1.50 | Hard | | Barrel-jack and MicroUSB power | Yes | No (just microUSB) | | $ 2.95 | Easy | | Highest Screen Resolution | 1280 x 1024 | 1920 x 1200 | | ~ | ~ | | Peak Power Requirement | 460mA | 475mA | | ~ | ~ | | Supply Current to USB | 500mA | 700mA | | $ 5.50 | Hard | | USB Host (devices used by BBB or Rpi) | 1 | 2 | | $ 1.87 | Easy | | USB Client (lets BBB or Rpi be a device) | 1 | 0 | | ~ | ~ | | Plastic Headers for GPIO | 65 | 0 | | $ 1.95 | Easy | | USB Cable | 1 (Mini USB) | None | | $ 1.07 | Easy |

The Hardware:

First impressions in a sentence: The hardware looks sound.

Several things make it stand out:

• It uses a Micro SD card instead of a SD. This allows for a smaller overall size without using an Adafruit Adapter .

• It has three tactic switches: (1) power, (2), reset, and (3) a mystery switch. I'm hoping the third is software accessible. The built in powerswitch is a real winner. It means you can tell this guy to keep his £15 and his closed source design.

• It has one USB hub. This is my second greatest concern (after less community support) is having to rely on USB HUBs to connect devices. And, yes, I'm aware an IC, breadboard, and access to hardware IO will allow custom USB deivces. But sometimes don't you want to just plug-and-go? (Yes, I'm aware I'm lazy.)

• It has a barrel-jack instead of a Micro USB for power. I don't know how you feel, but I'd rather have the Micro USB simply because I've got a lot of those lying about, whereas barrel-jacks, I'm not sure. Maybe under the decaying skull?

• It's open hardware . The RPi claims to be for "educational purposes," although, it seems the education is restricted to the software. Of course, this is an assumption based on not yet seeing a schematic for the Raspberry Pi silicon bits.

• It's TI. They're nice to me. (I might have a stack of sampled ICs from them...maybe.)

If everyone is alright with me floating this post for a bit, I'm going to try to do a first-boot video tomorrow, then, continue until I've built this BBB into a bot.

Hope you're all well :)

• Bdk6
• RPI: 5

• BBB: 14

• Maxhirez

• RPI:1

• BBB: 2

• Ladvien:

• RPI:
• BBB:1

Originally posted on www.letsmakerobots.com

Code

No longer afeared of frying my Pi, I've moved on to trying to implement some of my bot goals. Like many, I want my bot to be able to interact with people, but I didn't realize that I'd stumble on this ability.

I've looked at many visual processing boards like the CMUcam v4 , but I'm not paying $100 for any board. I looked into making one, it looks possible, but not much cheaper. So, I got curious as to what alternatives there are. I stumbled on Hack-a-Day's recommended article: OpenCV on Raspberry Pi .

Anyway, he provided instructions on setting up OpenCV (open source computer vision) on Raspberry Pi. Of course, it was about 20 minutes later I had the code working on my Pi.

I had been skeptical of the Pi's ability to run any computer vision software, and morever, it's usefulness given the Pi's processing constraints. But once I had it up and running, I noticed it actually ran smoother than I had hoped. Don't get me wrong, I think it is less than 10FPS, but I could tell it would work for many robot applications More than that, if the Raspberry Pi was used only for the computer vision, then it would still be cheaper than many other hardware driven CV boards.

Basic Raspberry Pi and WiFi Dongle

• WiFi Dongle: $6.17
• Raspberry Pi: $35.00
• SD Card (4g): $2.50
• Web cam: $8.00
• Total for Basic RPi: $51.67

Therefore, I went to work on hacking his code.

Many hours later, I ended up with a _very crude _ Raspberry Pi, Ardy, Camera, and Servo orchestration to track my face. Mind you, this is a proof of concept, nothing more at this point. But I hope to eventually have my bot wandering around looking for faces.

Image of Pi VNC. The box outline is being written through i2c .

Pulling apart a little $8 eBay camera.

To Setup the Raspberry Pi:

If you're setting it up from sratch, start with these instructions .

But if you're already setup, I think all you need is OpenCV.

$ sudo apt-get install python-opencv

The Code:

The Arduino code reads bytes from the i2c, converts them to characters, then places the characters into an integer array. The Pi is sending 4 numbers, 2 coordinates, x1, y1, x2, y2.

The Python code is "facetracker.py" by Roman Stanchak and James Bowman, I've merely added lines 101-105, which load the coordinates of the box around your face into a a string, converts that to a string array. I also added function txrx_i2c(). This function converts the string array into bytes and sends it to the i2c bus.

To change this setup from i2c to UART, focus on the txrx_i2c() in the Python code and the onRead() in the Arduino code. I assure you, UART would be much easier.

If anyone has any questions hollar at me. Oh! And if someone can tell me ways I could optimize this code, I'm all ears

#include <Wire.h>
#define SLAVE_ADDRESS 0x2A
#include <Servo.h>

Servo CamServoX; //Attach the pan servo.
Servo CamServoY; //Attach the tilt servo.

int ServoTimer = 250; // Change to adjust how quickly the servos respond.

int SmallXJump = 3; //Sets the movement amount for small pan jumps
int LargeXJump = 7; //Sets the movement amount for large pan jumps


int SmallYJump = 1; //Sets the movement amount for small pan jumps
int LargeYJump = 2; //Sets the movement amount for large pan jumps

//How close your face is to the edge to trigger a jump.
int SmallYLimit = 40;
int LargeYLimit = 20;

int SmallXLimit = 40;
int LargeXLimit = 20;

//Set servos to initial position.
int posX = 90; //Servo position.
int posY = 90; //Servo position.

int x1; int y1;int x2; int y2; //Holders for frame dimesions.

// Indexes for getting i2c bytes, then, converting them to integers.
int i = 0;
int varI = 0;

//Sets flag to trigger ServoWrite() from the main loop.
//I tried to put this under 'onRequest' call, but the Raspberry Pi kept giving me errors.
//This flagging was a work around.
int NoServoData = 0;

int dim[12]; //Char array for char[] ---> int conversion.
char d[8]; // Char holder array for byte-->char conversion.

void setup() {
    // initialize i2c as slave
    Wire.begin(SLAVE_ADDRESS);
    Wire.onRequest(sendData);
    Wire.onReceive(readData);
    Serial.begin(9600);

    //Attach servos
    CamServoX.attach(10); //Tilt (Y)
    CamServoY.attach(9); //Pan (X)

    //Write initial servo position.
    CamServoX.write(posX);
    CamServoY.write(posY);
}

void loop() {

//Again, this is the work around.  The flag "NoServoData" is set under the i2c onReceive.
if (NoServoData==1){
  ServoWrite();
}

}

//This is just to show the RPi can be written to.  
//Replace with stuff you want to write to the Pi.
char data[] = "Pasta";  
int index = 0;

// callback for sending data
void sendData() {
    Wire.write(data[index]);
    ++index;
    if (index >= 5) {
         index = 0;
    }
 }

// callback for receiving data.
void readData(int numbytes) {

//Holds the chars
int c;

if (Wire.available() > 0){
  while(Wire.available())    // slave may send less than requested
    c = Wire.read();
}
  //Add each integer to a char array.
  //Skip commas ',' and keep adding the integers until char '\0' is received.
  //Then print out the complete string.

  if (c != ','){
    if(c != '\0'){
      d[i] = d[i] + c;  //Appends the characters to an array.
      i++;
    }
  }
  else{
    i=0; //Reset the d char array index.
    if(varI < 7){  //We only want to get integers until we get all four numbers (x1, y1, x2, y2) plus
      dim[varI]=atoi(d); //Convert the d int into ASCII and store it in the dim array.
      d[0]=0;d[1]=0;d[2]=0;d[3]=0;d[4]=0;d[5]=0; //Clear the d array (i2c doesn't like for loops in this function
      varI++; //Increase dim index.
    }
    else{
      //We now have all four numbers, load them into the variables.
      x1=int(dim[4]);
      y1=int(dim[1]);
      x2=int(dim[2]);
      y2=int(dim[3]);

      NoServoData = 1;  //Set the WriteServo() call flag.
      varI=0; //Reset the dim index to prepare for next set of numbers.
      }
   i=0; //Reset some
  }
}

void ServoWrite(){
  int x3 = 160 - x2; // Calculate the distance from the right edge of the screen
  int y3 = 120 - y2; // Calcualte the distance


  //For X Axis
  if(x1 < SmallXLimit ){  //Only do small jumps, since not too far away from the edge.
        if(posX>1){ //If the pan servo is at its edge, do nothing.
          for (int i = 0; i < LargeXJump; i++){
            posX++;  // Set the new position
            CamServoX.write(posX); //Make the adjustment.
            delay(ServoTimer); //Delay between servo increments.
          }
      }
  }

  if(x3 < SmallXLimit){
      if(posX<180){
          for (int i = 0; i < LargeXJump; i++){
            posX--;
            CamServoX.write(posX);
            Serial.println(posX);
            delay(ServoTimer);
          }  
      }
  }


  if(x1 < LargeXLimit){
        if(posX>1){
          for (int i = 0; i < SmallXJump; i++){
            posX++;
            CamServoX.write(posX);
            Serial.println(posX);
            delay(ServoTimer);
          }
      }
  }

  if(x3 < LargeXLimit){
      if(posX<180){
        for (int i = 0; i < SmallXJump; i++){
            posX--;
            CamServoX.write(posX);
            Serial.println(posX);
            delay(ServoTimer);
        }
     }
  }


  //For Y Axis
  if(y1 < SmallYLimit ){
        if(posY>1){
          for (int i = 0; i < SmallYJump; i++){
            posY--;
            CamServoY.write(posY);
            Serial.println(posY);
            delay(ServoTimer);
          }
        }
  }

  if(y3 < SmallYLimit){
      if(posY<180){
        for (int i = 0; i < SmallYJump; i++){
          posY++;
          CamServoY.write(posY);
          Serial.println(posY);
          delay(ServoTimer);
        }
     }
  }


  if(y1 < LargeYLimit){
        if(posY>1){
          for (int i = 0; i < LargeYJump; i++){
            posY--;
            Serial.println(posY);
            CamServoY.write(posY);
            delay(ServoTimer);
          }
      }
  }

  if(y3 < LargeYLimit){
      if(posY<180){
        for (int i = 0; i < LargeYJump; i++){
          posY++;
          CamServoY.write(posY);
          Serial.println(posY);
          delay(ServoTimer);
        }
      }
  }

//Reset servo write flag.
NoServoData=0;
}

Now for the Python Code:

#!/usr/bin/python
"""
Have to execute using "sudo python facedetect.py --cascade=face.xml 0"
(Normal build sudo python "%f")
This program is demonstration for face and object detection using haar-like features.
The program finds faces in a camera image or video stream and displays a red box around them.

Original C implementation by:  ?
Python implementation by: Roman Stanchak, James Bowman
"""
import sys
import cv2.cv as cv
from optparse import OptionParser
import time
import threading
import readline
import pygame
from pygame.locals import *
import sys
import smbus

# Parameters for haar detection
# From the API:
# The default parameters (scale_factor=2, min_neighbors=3, flags=0) are tuned
# for accurate yet slow object detection. For a faster operation on real video
# images the settings are:
# scale_factor=1.2, min_neighbors=2, flags=CV_HAAR_DO_CANNY_PRUNING,
# min_size=<minimum possible face size

min_size = (20, 20)
image_scale = 2
haar_scale = 1.2
min_neighbors = 2
haar_flags = 0

"""i2c Code"""
bus = smbus.SMBus(1) # Open up a i@C bus.
address = 0x2a # Setup Arduino address

sendstring = "" # This will be my send variable (RPI-to-Arduino)
bytearraytowrite = [] #Actual array for holding bytes after conversion from string.

#This function actually does the writing to the I2C bus.
def toWrite(a):
    global sendstring
    global bytearraytowrite
    bytearraytowrite = map(ord, sendstring) #This rewrites the string as bytes.
    for i in a:
        bus.write_byte(address, i)

def txrx_i2c():
    global sendstring
    #while True:
    sdata = ""
    rdata = ""
    for i in range(0, 5):
            rdata += chr(bus.read_byte(address));
    #print rdata
    #print bytearraytowrite
    #print "".join(map(chr, bytearraytowrite)) #Will convert bytearray to string.

    #Writes the key commands to the i2c bus.
    toWrite(bytearraytowrite)


    #time.sleep(.6);

def detect_and_draw(img, cascade):
    global sendstring

    # allocate temporary images
    gray = cv.CreateImage((img.width,img.height), 8, 1)
    small_img = cv.CreateImage((cv.Round(img.width / image_scale),
                   cv.Round (img.height / image_scale)), 8, 1)

    # convert color input image to grayscale
    cv.CvtColor(img, gray, cv.CV_BGR2GRAY)

    # scale input image for faster processing
    cv.Resize(gray, small_img, cv.CV_INTER_LINEAR)

    cv.EqualizeHist(small_img, small_img)

    if(cascade):
        t = cv.GetTickCount()
        faces = cv.HaarDetectObjects(small_img, cascade, cv.CreateMemStorage(0),
                                     haar_scale, min_neighbors, haar_flags, min_size)
        t = cv.GetTickCount() - t
        print "detection time = %gms" % (t/(cv.GetTickFrequency()*1000.))
        if faces:
            for ((x, y, w, h), n) in faces:
                # the input to cv.HaarDetectObjects was resized, so scale the
                # bounding box of each face and convert it to two CvPoints
                pt1 = (int(x * image_scale), int(y * image_scale))
                pt2 = (int((x + w) * image_scale), int((y + h) * image_scale))
                cv.Rectangle(img, pt1, pt2, cv.RGB(255, 0, 0), 3, 8, 0)
                x1 = int(x * image_scale)
                y1 = int(y * image_scale)
                x2 = int((x + w) * image_scale)
                y2 = int((y + h) * image_scale)
                sendstring = str(x1) + "," + str(y1) + "," + str(x2) + "," + str(y2) + ","
                sendstring = sendstring.translate(None, '() ')
                print sendstring
                txrx_i2c()
                sendstring = ""
    cv.ShowImage("result", img)

if __name__ == '__main__':

    parser = OptionParser(usage = "usage: %prog [options] [filename|camera_index]")
    parser.add_option("-c", "--cascade", action="store", dest="cascade", type="str", help="Haar cascade file, default %default", default = "../data/haarcascades/haarcascade_frontalface_alt.xml")
    (options, args) = parser.parse_args()

    cascade = cv.Load(options.cascade)

    if len(args) != 1:
        parser.print_help()
        sys.exit(1)

    input_name = args[0]
    if input_name.isdigit():
        #Where the image is actually captured from camera. "capture" is the variable holding image.
        capture = cv.CreateCameraCapture(int(input_name))
    else:
        capture = None

    cv.NamedWindow("result", 1)

    width = 160 #leave None for auto-detection
    height = 120 #leave None for auto-detection

    if width is None:
        width = int(cv.GetCaptureProperty(capture, cv.CV_CAP_PROP_FRAME_WIDTH)) #Gets the width of the image.
    else:
        cv.SetCaptureProperty(capture,cv.CV_CAP_PROP_FRAME_WIDTH,width) #Gets the width of the image.

    if height is None:
    height = int(cv.GetCaptureProperty(capture, cv.CV_CAP_PROP_FRAME_HEIGHT))
    else:
    cv.SetCaptureProperty(capture,cv.CV_CAP_PROP_FRAME_HEIGHT,height)

    if capture: #If "capture" actually got an image.
        frame_copy = None
        while True:

            frame = cv.QueryFrame(capture)
            if not frame:
                cv.WaitKey(0)
                break
            if not frame_copy:
                frame_copy = cv.CreateImage((frame.width,frame.height),
                                            cv.IPL_DEPTH_8U, frame.nChannels)

#                frame_copy = cv.CreateImage((frame.width,frame.height),
#                                            cv.IPL_DEPTH_8U, frame.nChannels)

            if frame.origin == cv.IPL_ORIGIN_TL:
                cv.Copy(frame, frame_copy)
            else:
                cv.Flip(frame, frame_copy, 0)

            detect_and_draw(frame_copy, cascade)

            if cv.WaitKey(10) >= 0:
                break
    else:
        image = cv.LoadImage(input_name, 1)
        detect_and_draw(image, cascade)
        cv.WaitKey(0)

    cv.DestroyWindow("result")

Originally posted on www.letsmakerobots.com

As I prepare to start adding peripherals to my Pi Bot, I wanted to be sure to get around the 700ma power budget the Pi has. After searching for a cheap battery powered USB hub and finding little, I decided to hack up a few cheap(ish) parts and make my own.

1. USB Hub : $1.39

2. 5000mAh Battery : $17.93

3. DC-DC Converter : $2.76

Total: $22.08

The Battery Hack:

1. Crack it open.

2. Find POWER and GND.

3. Wire it up.

4. Make a small hole for wires and bring wires out.

5. Solder the respective leads to the DC-DC converter.

6. Smile, then sit through my way too long of a video to make it into the HUB.

Hope all are well. :)

NOTE: Regarding the error at the end of the video. Don't panic (that's what I did). I actually found out this had nothing to do with my hub, it had to do with plugging an iPhone into a Raspberry Pi.

NOTE2: I realize I used the wrong "hearty," my brain has problems typing homonyms and parahomonyms. :P

Originally posted on www.letsmakerobots.com

This article is specific: How I personally would setup my Raspberry Pi to act as robot base. But, I'll be clear, this is one of nth possible setups. A chessboard has 64 squares but those working the board allow for innumerable possibilities.

That aside, here we go:

1. Get Berryboot. Berryboot will allow you to download several Raspberry Pi images.

Now extract the zip files to a blank SD card.

Put the BerryBoot SD card in your Pi and boot it up.

2. Setup RPi with Raspbian Wheezy (first option).

3. Setup your WiFi dongle. I believe BerryBoot will now setup your WiFi dongle on initial boot, which it did for me (even gave me the option to download the image via WiFi). But, I had trouble getting my WiFi dongle pulled up after booting Raspbian Wheezy.

If you have difficulty with manual WiFi dongle setup, you might try this video .

Lastly, if you are looking for a WiFi dongle for cheap, with good range, and uses very little mAhs (the Pi can only feed about 700mAhs through the USB port). You might try this one , $6.17.

4. Setup PuTTY on your Desktop Computer. Follow this video. This will allow you to begin SSHing into the Pi. That way you don't have to look at a little RCA screen like me. For those who aren't familiar with SSH (like I was before this video), the video will explain it. At risk of oversimplification, it allows you to access your Raspberry Pi command line through your desktop.

You have to plug in your Pi's network number. You can find this by pulling up your wireless hub's configuration page. You should see what address your Pi is listed at. For some strange reason, if it doesn't list the device name, just view the page while the Pi is up, then unplug your Pi and refresh the wireless hub configuration page. The device that disappeared is your Pi. I've never had to change the port number, but beware you might need to depending on your setup.**

If you want to know whether your have the correct information, try login' in and if you get a screen like this, your good.

Your username and password are by default: pi, raspberry

Remember! In the case of a Raspberry Pi, always share your password, 'cause everyone has it anyway :)

Once you have PuTTY setup, you should be able to bring up your Pi command line, something like this:

5. Setup VNCServer on your Raspberry Pi. Follow this video. (Or this walkthrough ). Putty will let you access your Pi's command line, but setting up a VNC will actually allow you to access your Pi's Desktop GUI from your PC, in the same manner as Putty.

6. Setup a VNC Client on your Desktop Computer. Real VNC. There are many different programs, I happened to end up using Real VNC.

Once you have VNC setup on both machines, PuTTY into your Pi and start the VNC server.

$sudo vncserver

Two notes here, if you did better with the video instructions than I did, your vncserver will start automatically on boot. Unfortunately, I have to type it each time (I'm too lazy to figure out the boot part of it). As a result, you'll have problems running certain Python scripts through VNC if you don't use $ sudo vncserver

You'll enter your Pi address, but port should be 1 (if I remember the video instructions correctly).

You should end up with at a windowed version of your Raspberry Pi desktop. One more note, somewhere in the video it gets you to setup the "geometry" of the VNC desktop. The limitations you put there will be reflected in the quality of the desktop you see in the window. In essence, if you put in 640x480, that's the resolution this desktop will end up. So, please, take advantage of the Pi's GPU :)

Use something like this, "-geometry 1024x728 -depth 24"

7. Resize your SD card to use all its space. (Note, this should already be done by BerryBoot. But other diskimages will limit your SD card to 2GB, regardless of its actual size).

8. Git manager will allow you to pull code from git hubs (again, this should already be installed, but just in case).

I **nstall the git manager: **

At Raspberry Pi prompt: $sudo apt-get install git

The way to use it is like so,

At Raspberry Pi prompt: $sudo git clone https://github.com/adafruit/Adafruit-Raspberry-Pi-Python-Code.git

9. Install SMBus. This is specifically for my setup, since I'll be using the I2C bus to communicate between the Pi and the Arduino.

At Raspberry Pi prompt: $sudo apt-get install python-smbus

10. Any other Python modules you might fancy.

Useful for keystroke, GUI, and other interfacing needs:

Pygame (should come with Raspbian) . (sudo apt-get install pygame)

Lady Ada's Python codes for an array of I2C sensors:

Adafruit I2C library (git)

Access your Raspberry Pi from iDevice web based GUI:

PiUi (git)

Control serial devices:

pySerial (sudo apt-get install python3-pyserial)

(I'll add other resources as fellow LMRs leave them in the comments).

11. (optional) Install Arduino IDE on Raspberry Pi. This will allow you to program the Arduino directly from your Pi-- and if you follow my design, you'll be able to do so without ever leaving your desktop computer. You can do this by opening the VNC Server, opening the Arduino IDE on the remote desktop, selecting the sketch you want to upload, and as long as your Arduino is connecting by way of USB, you can then upload your sketch from where you sit. This allows for quick changes to Arduino code without switching wires around. Also, I think Kariloy is looking for a way to upload sketches by way of GPIO pins. This would make a cleaner design.

12. Install WinSCP . This will allow you to transfer files between your desktop and the Pi. I find this helps with programming management. I'm a messy filer. If I file at all.

13. Take a deep breath.

14. Follow these instructions for making my I2C optoisolator board.

Again, there are many commercial boards that will serve the same function. Also, you can do the same with a USB cable , serial pins to GPIO , or RF connection--basically any way that lets the Arduino and Pi talk at a reasonable speed. The speed restraint will of course depend on your need. I doubt many methods will be apt for running a responsive quadrocopter. But in my case, my Pi is the central nervous system and the Arduino is the autonomous nervous system. The Pi will send directives, but it's up to the Arduino to manifest them through responsive actuators. And I chose this optoisolator because I didn't want an voltage restraint on my actuators or fear of frying my Pi.

Once you have the board setup, you can run:

$sudo i2cdetect -y -a 1

This should bring up a list of active I2C registers. You should find your Arduino at whatever address you set in your Arduino code.

Now, I've read this fellow's article on how Raspberry Pi I2C pins are actually 5v tolerant. (Note, this is only for I2C pins, due to their pull-up resistors.)

So in theory, you can skip the optoisolator all together. But that's you , I'll stick with my optoisolation.

15. Download my code --or someone cooler's.

Note, my code is really just the base for a robot. Right now, my it is nothing more than a very, very complex radio controller for a RC car. But someday, I'll make a real robot :)

**16. Tweak and gut the code as you see fit. **

17. Ask questions: Pretty much everyone on this site is smarter than me, they'll know the answer.

To other LMRians. Please feel free to tell me how to change, add, or retract from this article. As tired as I am right now, I plan to revise when I'm less muddled.

Originally posted on www.letsmakerobots.com

Breakout PCB Arduino Code

I've waited to finish incorporating my Raspberry Pi into my bot for an ample bit. But since I know so little about electricity, I swore to myself I wouldn't add my Pi to my bot until I was absolutely sure I wouldn't fry it.

Well, I'm still not "absolutely" sure, but I feel this little optoisolator has brought me a lot closer. This builds on my post a week or so ago about making Eagle parts.

I plan to actually list out what tweaks a Wheezy image needs to get this optoisolator build to work. It's actually pretty easy--but whatever you, don't be lured in by quick2wire. Those buggers wasted most of my day :(

If anyone has questions let me know.

Oh, one note. When I populated the board I used 4.7k resistors on the Arduino side, but I pulled off everything on the Raspberry Pi side. It seems the Pi has built in pull-ups that do the job rather well.

ADUM1250ARZ Datasheet

Hope everyone is well :)

Originally posted on www.letsmakerobots.com

I decided to try making an Arduino Pro Mini at home. Being done, it's not worth it. You can buy one for a dollar more than you can make them, and it took awhile to populate. Although, it's "fun."

This projects was also a chance for me to test the Spying-Stalactite I built.

I've enjoyed it. It allows me to reflect on my strategy while populating boards. It's simply a drop down with some high-powered LEDs (~2500 lumen), heatsink, and coolant fan. It has a hole for my iphone to do the recording. Cheap and simple. Although, I need to diffuse the light, as you might see by the video that it washes out the details of the projects. Also, I'll add a few more lights and do away with the tungsten lamp, since the iphone is constantly in a white-balance battle as I move infront of the mixed lightsources.

I populated this board; everything came out fine (although, it was much more difficult trying not to block the camera with my head). I popped it into Atmel studio and it read out the device voltage and signature. Of course, I bricked it, as I seem to do a lot.

My next projects is a Fuse Doctor. :)

I had ordered the boards from OSHPark and had planned on making three. So, I populated another and took some time programming it. I've outlined my steps below:

1. Hook up the AVRISP MKII

2. Open Atmel Studio. Go to Tools -- Device Programming.

3. Setup:

• Tool: AVRISP mkII
• Device: ATmega328P
• Interface: ISP

Click apply

4. Read Target voltage (it should be ~5V). Read Device Signature.

1. Open boards.txt that comes with Arduino (\Desktop\arduino-1.0.3\hardware\arduino\boards.txt).

2. Scroll down to the area marked:

8. Pull the programming information for the board from this area. Now, I've bricked a few boards, but I think I've figured this one out. When programming this board with the MKII and Atmel Studio, you should follow this order.

1. Set the fuses:

• Extended: 0xFD
• High: 0xDA
• Low: 0xFF
• (Double check the board file to make sure I didn't make typos)
• Hit "Program"

2. Upload Bootloader.

"The bootloader for the 5v, 16mhz Arduino Pro Mini (which is what I built) is "ATmegaBOOT_168_atmega328.hex (Desktop\arduino-1.0.3\hardware\arduino\bootloaders\atmega\ATmegaBOOT_168_atmega328.hex).
It's important to note that the 3.3v and 5v versions use different bootloaders.

• Go to the Memories tab
• Hit the browse ellipsis.
• Select the "ATmegaBOOT_168_atmega328.hex"
• (Double check the boards file to make sure I'm not screwing you up).
• Hit program.

3 Set Lock Bits.

• Go to the "Lock bits" tab.
• Check the boards.txt file for Lockbit number
• Lockbit: 0xCF
• (Double check the boards.txt. I don't take blame for bricked boards :P).
• Hit "Program"

9 Upload the Blink Sketch; the LED by the reset button should blink.

10 Let me know how it went. If you bricked a chip using these instructions, let me know so I can modify them quick.

Now that I'm used to the camera and stalactite, I plan to annotate my next board for tips on working with 0402s.

Hope all are well.

ps. Birdmun et al., sorry bout the copyright issues. Not a professional at anything, especially video editing :)

Originally posted on www.letsmakerobots.com

Addendum: Please don't watch my videos. After Birdmun's comment I found Hack-a-Day has created better videos (shakes fist at Hack-a-Day) and I don't want anyone to waste anyone's time. Although, mine has a better soundtrack and less mutton-chops :)

Hack-a-Day videos:

1. Learning Eagle CAD Part 1 -- Schematic & Custom Parts
2. Learning Eagle CAD Part 2 -- Schematic & Custom Parts (includes making a part)
3. Learning Eagle CAD -- CAM Processor
4. Learning Eagle CAD -- Layout

Original: I was speaking with TeleFox and Birdmun about finding an optoisolator for use with my Raspberry Pi; I had gotten some samples of these ICs: ADUM1250ARZ . Well, for awhile now I've wanted to share my dumb-luck methods for designing a board around a sampled IC.

So here it is, 20mins (sorry).

Hope everyone is well :)

Part 1 -- Making the Part

Part 2 -- Finishing the Part and Making the Board

Finished Eagle Files: ADUM1250ARZ Breakout Board

Originally posted on [www.letsmakerobots.com](www.letsmakerobots.com 1. Get over to Analog Devices and sign-up for a sample account. They seem to be pretty nice and let you order several samples every month, I believe.

2. Order a few samples of the ADXL345 chip from Analog Devices.

1. Download the Eagle files from Sparkfun: ADXL345 (Note the price).

1. Sign up for an OSHPark account. Then, upload the .brd found in the Eagle files.

1. Order the capacitors.

2 x 0.1uF

1 x 10uF

1. Try to learn Python while the mail peoples do their magics.

** **

1. Flip-off your Python code and get the mail.

2. Take everything out. ADXL breakout board, ADXL345 chip, and caps.

3. Populate your board. At this point, a good iron will do you well. But as a general rule, start with the largest chip when soldering SMDs. In our case, it is the ADXL345. Paint some solder flux all over the exposed pads. Now, take a very fine solder, such as .022 and put some on the tip of your iron. Drag the droplet of solder across the exposed pads of where the ADXL will go. Now, after the beads have cooled, paint your solder flux over the hardened beads. The idea is to have the chip floating on this flux.

1. Place the ADXL345 on the invisible flux, hovering over the pads. Make sure the small white dot on the the corner of the chip is in the same place the red is below.

1. Put the board on an over turned iron. This is the most important part: Watch the chip. What you are hoping to see is the chip magically float in place as the solder flux flows out from under the chip, leading to the solder beads bonding with the exposed copper of the ADXL345. Seriously, don't look away :). If for some reason you don't feel the chip has bonded at each pad, then very lightly press down in the middle of the chip. I said lightly!

12. Cap that B. Erm, populate the capacitors.

** **

** **

13. Plug and pray.

14. Realize it doesn't work because you suck at life.

15. Pull the ADXL back off, clean the pads with solder wick, and try again.

16. Repeat step 11, but this time, watch the chip, no seriously.

17. Hook it up and check it out. The chip is both SPI/I2C ready, but I prefer I2C. So, hook that sucker up to the Arduino and see if it works. This fellow provided code and instructions on connecting are in the code's comments at the top.

Arduino Code for ADXL345 I2C

18. Watch as your one dollar(ish) ADXL345 does witchery.

19. Ponder the ethics of sampling chips, borrowing board layouts from SparkFun, and buying underpriced capacitors from China; all leading to saving you around $12~25-- or have a beer.

20. Try not to abuse the sampling previlige.

If you have any questions, I'll do my ignorant best.