August 22, 2016

The Super Kickass Temperature Logger Thingamabob

It all started with an email. (Don't they always?)

In this case, the email was from the Dallas Coding Workshops and Hackathons group at Now, I've been a member of for a long time, and I've signed up for many more meetup groups than I probably should have, and for the most part, I've found that emails from are for events that I'm either not interested in, or that I'm not available to attend. In this case, however, the planets aligned: this was an event that both interested me, and for which I had the time to attend! The email came on August 10 and announced a Hackaton the weekend of August 19-20. I checked my calendar and found that I don't have the kids that week (yes, that's foreshadowing; stay tuned), and there was nothing pressing on my calendar.

For the first time in a long time, I clicked "YES" on the "Are you going?" link that provided me.

Friday Afternoon

On Friday I was able to get off work early and for the first time really considered the question: what am I going to do at the Hackathon? What am I going to bring? I went to Wal-Mart and bought a $5 tackle box from the crafting section, went home, and crammed it full of various dev boards, Arduinos, R-Pi's, USB cables, a soldering iron, jumper wires... basically, anything that looked like it might be useful or fun to work with. I quickly ran out of room in the tackle box and filled a small cardboard box with overflow items, all of which went into my car. I hadn't read the details of the event, so I threw a sleeping bag, a pillow, and a toothbrush into the trunk, and headed out into a rare summer downpour in Dallas.

2016-08-22 21.59.49 2016-08-22 22.01.37


June 6, 2014

AVC Boards have arrived!

I had given up all hope of receiving my AVC circuit boards and had convinced myself that they had become forever lost in the mail. And wouldn't you know, today they show up. Ten circuit boards when I only need one. (more…)

June 1, 2014

AVC Proof-of-Concept (sorta) Post

The AVC Proof of Concept deadline is today. (Or maybe it was yesterday.) This is my lame attempt at desperately hoping to still qualify for the contest.

You see, the circuit boards that I ordered from Dirty Boards on the 3rd of May still haven't arrived. Without circuit boards in hand, I really don't have much to show for my AVC entry.

On the off chance that the AVC staff will take mercy on me and allow me to remain in the contestant pool, my robot consists of:

Yeah, without pics, I realize the credibility in this post is near zero. But that's all I have right now- words and ideas. I'm well aware that the chances of me being ready in time are pretty slim, but I'm hoping the decision on whether or not to drop out can be my decision and not the decision of the AVC staff.

So I'll send them a link to this post and see what they say...

May 14, 2014

AVC Boards Have Been Ordered!

Well, it's been a while since I posted anything. I've been very heads-down with various priorities and this is the first opportunity I've had to come up and take a breath. I've just shed a few obligations so I'm hoping I'll be able to post more frequently.

I haven't abandoned my AVC project! In fact, I spent several weeks tweaking the schematic and then several more tweaking the PCB design. The inescapable fact of all this is that I just plain suck at PCB design. (more…)

March 18, 2014

AVC Parts Ordered!

I submitted my order to Mouser today. While that's on its way here I'll lay out my circuit board. When the order gets here, I'll verify footprints and then send off my gerber files to have a custom PCB made.

The June contest date is approaching way too fast! I don't even have my hardware done yet, so I can't do a whole lot of software development. Argh!

March 2, 2014

The Woes of Debugging DMA on the STM32 Platform

I spent a good chunk of today getting frustrated with my AVC code. I have custom firmware on my GPS so that it sends a fixed-length binary sentence to my microcontroller. Rather than polling the USART, or handing an interrupt every time a character comes in, I figured this is a perfect application for the DMA controller... tell the DMA controller how many characters there are, and have it wake up my code when I receive a full GPS sentence.

Well, during debugging, I found that my DMA IRQ was being handled once, but I couldn't get it to trigger a second time. After wrestling with this for hours, I finally thought, what if the second DMA interrupt really is happening, but because I've got the CPU stopped at a breakpoint, I'm missing it?

So, I took out my breakpoint and instead threw a character out the USART every time the DMA IRA was called. And lo and behold, I got a DMA IRQ five times a second, which is just how often the GPS is sending me data.

Embedded programming can be so frustrating.

February 27, 2014

AVC Replacement Parts Finally Arrived!

Despite selecting 'air mail' at checkout, Hobby King apparently found the absolute slowest shipping method to get replacement parts for my R/C car to me.

Well, I finally got them and I replaced the front right "C" bracket and took the car for a test drive today. I've never owned a hobbyist-grade R/C car before so some things seemed a bit weird to me. First, the car would go much faster in reverse than it would going forward. I solved this by swapping 2 of the 3 leads to the brushless motor (thus reversing the motor's direction), and inverting the throttle signal on my transmitter. I'm not sure if that's the right solution or not, but it worked.

The other thing is that the car seems to have no problem going from reverse to forward, but it insists on pausing when going from forward to reverse. I have no idea if that's normal or not. At least the car works.

In any case, I now have a platform for my AVC robot. I'm still cleaning up code to interface with my GPS module, and I'm writing a separate subsystem to drive some LED indicators to tell me the internal state of the software. I don't know how useful that will be in the final product, but at the moment, it seems like it's going to be useful for debugging.

I'm almost finished with parts selection. I'm going to have a GPS receiver and at least one 9DOF IMU chip on my vehicle. I'm still debating whether or not to include odometry sensors, IR distance sensors, and/or ultrasonic ranging sensors.

I've started designing the schematic for my controller board in Eagle.

February 9, 2014

USART woes on the STM32F4DISCOVERY board

Now that I have the ability to use a FAT filesystem on an SD card (post to come shortly), my next task was to write some code to allow me to send debug spew to a serial port. My plan is to use an Adafruit Bluefruit EZ-Link bluetooth link to send debug data to my laptop computer while debugging my AVC code. So yesterday I sat down to bang out the code. I mean, how hard can it be, right? Configure a USART with the proper baud rate, parity, data and stop bits, and pump data into the TX register. Piece of cake, right?

In about a half hour I had some code built and running. But I was getting garbage on my laptop over the FT232 cable I was testing with. I figured maybe I'd miscalculated the baud rate, or the clock speed, or something, so I tried doubling the bitrate on the microcontroller. Same problem, so I tried halving the original bitrate. No good.

I whipped out my Saleae Logic logic analyzer and took a gander at what was happening on the wire. The data simply made no sense. The width of each bit was not only not what I calculated it should be, but successive bit times weren't even an integer multiple of each other! The bit time was all over the map.. some short, some long, and very, very few were what they were supposed to be. (more…)

February 6, 2014

FAT and SDIO on the STM32F4: Early Experiments

I've been trying to marry the FatFS filesystem driver with a modified version of ST's SDIO sample code in order to read/write a FAT filesystem on an SD card for logging on my AVC robot.

It's been a frustrating few days. I've had intermittent results and I'm not sure why. I think there's some uncertainty with the DMA completion interrupts in my current lash-up. Moving from ST's library to Lukasz Iwaszkiewicz's software helped. I don't know the differences between the two codebases. Clocking the SD card at 25MHz (I think that's the clock speed in use) at the end of 12" jumper wires surely isn't helping anything. I also think that stopping the debugger and relaunching my code without powering off the SD card may leave its internal state machine confused. All of this is just conjecture, though, based largely on my wholescale ignorance of how the SD interface and the code I'm using actually work.

Currently, I'm able to read a file from the SD card but I'm having problems writing a file. (I started my attempt at writing this morning and only had 45 minutes to work on it before I had to leave for work.)

First experiments with the STM32F4DISCOVERY and an SD card.

First experiments with the STM32F4DISCOVERY and an SD card.

I'm designing a circuit board for my robot's brain that will solve the long wire problem when it's built, but I'm still a ways out from sending that off to be fabbed.

The Saleae logic analyzer that's barely visible in the picture has been worth its purchase price many times over. Many thanks to Supermodel Wife who bought it as a Christmas present for me despite knowing absolutely nothing about what it was!

February 2, 2014

AVC Parts from Hobbyking and Adafruit Arrived

AVC Parts have Arrived!

I got a box from Adafruit and a box from Hobbyking over the past couple of days, which should be all the parts I need to start developing my autonomous vehicle.

First the Hobbyking stuff. Despite several horror stories that I've read, the box that I received was a sturdy box in undamaged condition. I opened the box to find the contents were equally well packed and contents were all in good shape.

The box that I got from Hobbyking.

The box that I got from Hobbyking.

A nicely packaged box, in fact!

A nicely packaged box, in fact!

Clockwise from the top, I have a model car, two battery chargers, a transmitter and receiver, and three batteries:

Contents of the box.

Contents of the box.

As I said, everything was well packed. Upon closer inspection however, the right front wheel appeared to have an extreme amount of camber. While examining the suspension system to try to figure out how to adjust this, I discovered that the wheel was rubbing against the suspension arm. It turns out that the front "C" bracket is broken. Man, there's nothing more frustrating than to get a new toy only to discover it's broken.

I noticed the wheel hub rubbing against the suspension.

I noticed the wheel hub rubbing against the suspension.

You can see the cracked plastic "C" bracket here. (Click for larger version.)

You can see the cracked plastic "C" bracket here. (Click for larger version.)

I sent a support email to HobbyKing and am waiting on their response. Unfortunately, Hobbyking appears to be an eastern hemisphere low-cost leader and their support reflects that. I've been waiting over four days for a response to my support ticket.

The broken part is a fifty cent replacement part, but I found that it's only stocked in Hobbyking's international warehouse, which means it could take weeks before I receive it. I went ahead and ordered a replacement, along with a bunch of other replacement parts, because I have no faith in Hobbyking's support.

However, that won't stop me from starting to develop my code. My first task is to get some kind of logging going on. I'm planning on grafting FatFs to the SDIO example in the Standard Peripheral Library, which seems to be very well documented in the comments. I have a SD card slot that I ordered from eBay. I hope to find time to wire it up and test it before the weekend is out.

I also finished code last night to get the microcontroller's TIM2 PWM outputs to generate servo signals on channels 1 and 2. I spent a LOT of time wondering why the timings that my Saleae logic analyzer was showing me weren't consistent with my calculations. I finally discovered that the HSE_VALUE in stm32f4xx_conf.h, which defines the crystal frequency, is set to 25MHz when the STM32F4DISCOVERY board is fitted with an 8MHz crystal. Changing the constant in that header file fixed the problem and ended several hours of banging my head against the wall. My code now outputs a 1ms to 2ms pulse every 20ms and does so using the features of the hardware timer, so once the value is set no code is required to maintain a constant signal.

I'm debating between using the STM32F4DISCOVERY board on my final vehicle, or laying out a custom board with the same processor on it and making something a lot smaller and tailored to the task. I'm leaning toward a custom board but I'm a little leery of soldering some small SMT parts on there. I can do SMT passives no problem, and leaded chip packages are manageable, but one of the parts I'm looking at using is a 4mm by 4mm LGA 24 package. That's some pretty tight pin spacing with no access to the pads once the part is on the board. If I go this route I plan on using the Sparkfun Reflow Skillet method.