Friday, August 23, 2013

Prepping my Pickup for Burning Man

 I have been very busy this month preparing to attend Burning Man with one of my college buddies next week. Burning Man is a week-long festival that defies description out in the middle of the Nevada desert, with no power, no water, and no shade. For our camp, in addition to a small tent for sleeping, we decided to build a roof over the bed of my pickup for more shaded living and working area.  It has been coming together surprisingly well for something that we're just eye-balling and hacking together as we go.
The structure is based around this basic frame built of 2x4s ripped in half length-wise and mounted in the four post holes at the corners of my pickup's bed.
Here I am screwing down the cross-beams between the two basic side frames. We used three 2x4s, again ripped in half, so we had six 2x2 (1.25"x1.75"). We made bevel cuts on the top corners of the cross-beams to reduce the chance of ripping the top covering and as part of our aesthetic goal.
Here is Marcel drilling the mounting holes in the cross beams for our 100W solar panel, which is part of our camp's photovoltaic system, which I'll document later.
Here is the truck with the entire frame built and deployed. The awning behind the truck folds up on top for while we're driving, and will then be guyed down once we deploy the frame and staple a 12'x9' piece of heavy canvas to the frame on-site (as mocked-up in the first figure).
One important thing to note about the awning, since it is physically referenced off the ground instead of the bed of the truck like the rest of the frame, is that there will be quite a bit of relative movement as we change the load on the truck's suspension. We used long 1/4-20 bolts, fender washers, and a pair of nuts on each joint to act as a pivot.
We aren't going to install the canvas until we are on-site, so that we don't have to drive 80 with literally a giant sail on the back of my truck. Hopefully this structure will hold up to the elements at Burning Man, otherwise we are going to find ourselves with a lot less shade than we were hoping for.

For anyone else attending BM this year, the best way to find me will probably be calling me via amateur radio. Marcel (AI6MS) and I (W6KWF) plan to be using 146.535MHz with a PL of 127.3Hz, so give me a call.

Saturday, August 10, 2013

Computer Aided Dispatch in a Box

 As a member of the Cal Poly Amateur Radio Club, I volunteer as communications support for numerous community events throughout the year in SLO county. These events include bike rides put on by SLOBC, the Wildflower Triathlon put on by TriCal, etc. For these events, amateur radio operators are valuable because these events are usually held in areas suffering from poor cell phone coverage, and because amateur radio operators are particularly skilled at effectively moving information around on the radio. We are used to handle tracking all of the support course vehicles and rest stops, and relay information between remote sites, event organizers, and emergency response staff, such as paramedics.

During century bicycle rides or triathlons, it is normal for participants to become seriously injured or stranded. When this happens, it falls on the amateur radio dispatcher to call 911 and relay needed information for getting the injured participant help.
 For smaller events, it's usually viable to handle all of the information moving through dispatch using a pair of legal pads and a wristwatch, but when you operate for larger events, like the Wildflower Triathlon, where you have >10 event vehicles, several ambulances, and 30,000 people on-site, paper doesn't scale. For these events, we usually have several dispatchers on different frequencies, and then build an entire computer network around them so that they can use a local HTTP-based computer aided dispatch (CAD) system to pass and log information.

The problem is that there are a lot of events in-between a sheet of binder paper and spending a month and a half building a computer network for ~100 computers. That's where this project tries to solve the problem; a simple and clean box that you can plug into a WiFi router and in half an hour have a workable CAD network set up in a parking lot.

This project is still a work in progress. The first two photos show the front and back of the device, which currently consists of only a power light, a 2.1mm barrel jack for 9-18V, and an Ethernet jack for plugging into a WiFi access point.
The internals are based around a TI BeagleBoard (Thanks for the free hardware, TI and EDN!), and a 2A 5V switching voltage regulator. The extra space on the right is for additional hardware, which will likely either consist of a >100GB laptop hard drive for extra storage or an internal Li-Ion battery backup.
One issue I've been having with the hardware is TI's tendency to place resistors a little too close to mounting holes. R75 is just close enough to the standoff hole that if you aren't careful about which spacer you use and how you mount it, the standoff can short out that signal to the SD card and crash the BeagleBoard. Plastic standoffs are your friend.

On the software side, the BeagleBoard is running Ubuntu 12.04 Server, with a LAMP stack running the CAD software and whatever other services we decide we'd like (Samba, FTP, VoIP, etc). We're still evaluating various CAD packages, so I can't recommend one yet. We use BlackFlower for Wildflower, but since it is specifically targeted at only Wildflower Triathlon and Burning Man (which I'm going to this year!), it isn't well maintained or meet our more general needs here. I'm currently playing with Tickets, which is looking slightly more promising, but we'll see.

In the end, I hope to have a piece of hardware that you can pull out at an event, plug it in, point a web browser at, and have a usable CAD system. Then, at the end of the day, be able to click some kind of "Download report" link, and have a zip file of PDF reports to send to the event organizers as an archive of the event and how dispatch handled it.

Wednesday, August 7, 2013

AVR Dragon Hardware Review

 One of my good friends at Atmel, Paul Rako, recently sent me a sample of the AVR Dragon (Atmel store page), which is a in-circuit serial programmer (ISP) and On-Chip Debugger (OCD). The ISP functionality is familiar to most hobbyists in the AVR embedded programming scene; through the standard 2x3 pin header, you can erase the flash memory on an AVR and download new program code onto the chip. A typical example of an ISP programmer, and what I've been using exclusively up until now, is the wonderful, if sometimes a bit flaky, AdaFruit USBtinyISP.

As you look back through my blog, you can probably tell that only having ISP capabilities will get you pretty far, but where the Dragon really shines is in its ability to perform on-chip debugging. Most of the third-party programmers only implement the basic SPI-based erase-and-burn cycle you use when programming an AVR, but OCD allows you to set break-points in your program on the actual chip, and then step through your program code, read variable values, etc. All those glorious interactive debugging features that computer programmers have been spoiled with for decades. This makes embedded development MUCH easier, and an ability I've been suffering without while my projects have grown progressively more sophisticated.
 When I first opened the shipment from Atmel, I was very happy to see a piece of dev kit finally come in a reasonably sized, and attractive, box. I'll actually be able to store this thing in its box instead of having to shuck it and store the PCB floating around in gallon ziplocks like most of my other dev kits.
 Look at that minimally wasted space! ESD foam on top and bottom, so over all, I'm happy with the packaging, which is surprisingly important when you literally have an entire closet dedicated to development kits collected over the years.
 Nice touch on the backside silk screen logo. I'd like to have seen the pin-out references on the top, particularly since they're oriented for "top view," but it's still a handier reference than the printout I have floating around in one of my electronics binders.
Looking at the headers from the top of the board:

  • The first row has 3x Vcc and 3x GND, which seems a little strange for a programmer, but might be handy for some projects?
  • The second row has your 10 pin JTAG and 6 pin ISP headers, which are your two work-horse programming interfaces for AVRs big and small, and finally an unpopulated high voltage programming interface. The HV_PROG interface allows you to burn AVRs like old-school EEPROMs, and allows you to get around having to use the SPI ISP bus for programming. This is most useful when you want to use the reset pin as an IO pin (did you ever wonder why Atmel bothers assigning an IO port number to the reset pin?). 
  • And below the three programming interfaces... six rows of unpopulated, unlabeled, headers? Uhhh...
So the bottom third of the board's real estate dedicated to empty headers threw me for a loop until I noticed the sentence in the description, "A development area lets designers build their own circuitry or add sockets for the desired device footprint."

Fair enough; I can load the bottom of my Dragon with a socket and make it an AVR target board. I'll just pull up the manual and figure out what the on-PCB pinout looks like...

So apparently, Atmel didn't feel the need to put the Dragon's users manual on its product page? After finally resorting to searching through Google, I managed to find the users manual in Atmel's online help system, which quickly lead me to what I was looking for. I'm not entirely impressed with the rats-nest of jumper wires they have in the tutorial, and the three pairs of Vcc/GND make a lot more sense now, but I'm not convinced I'll not just stick to my standard practice of building separate target boards for each AVR model I use and keeping them in a ziplock in my drawer. I'd have expected a target area like that to use a bilateral switch array to allow for automatic retargetting to a specific AVR model, but that's asking a bit much of a $50 dev tool.

So overall, I'm happy with the packaging and feature set, but am a little disappointed that they made the board 50% larger for what seems like a half-thought-out target area. I look forward to being able to use a less kludgy programmer than the USBtinyISP, and finally being able to set break points in my code. As Paul says, "friends don't let friends go without on-chip debugging."