Journey vs. Destination

I’ve been working on a way to demonstrate a networking feature. I should tell you all about the networking feature but let’s just pretend that, like all routing protocols, we don’t really care about how it works.

Actually, that is why it is hard to demo networking protocols: either the demos do something and everyone says, “oh, I could do that over TCP/IP” or they don’t have any interface other than wireshark and everyone says, “wow, I’m bored.”

Yeah, I’ve been working in networking and missing my microprocessors quite a lot.

ANYWAYS… the demo! I have:

• 8 BeagleBone Black, rev Cs
• 8 LCD screen capes (these are absolutely marvelous)
• 8 Webcameras
• 8 brochure stands
• 2 100W power supplies (each feeding four units, 5V 2A)
• 1 hub to rule them all
• 1 laptop to run the obligatory wireshark
• Assorted cables (Power, Ethernet, one USB for config/debug)

We’re running something that acts like Dropbox so they all share the same data. (Seriously, I could tell you how but I’d use phrases like “Bit Torrent for the Internet” and get dirty looks from my workplace or crossed eyes from you.)

Before I go on with a few details about the build, how would you demonstrate Dropbox? As a walk-up, show-n-tell style demo on a crowded expo floor? Something that makes sense once you use it is remarkably complex for a demo.

For my demo, every second, each BBB takes a picture. It displays it on its screen and puts it in the shared directory. In another window, it uses a slideshow program to look at all of the pictures in the shared directory. Think of it like a security system, I show you what I see and what everyone else sees. This setup lets people see the how fast files are sync’d and the Ethernet traffic that passes on the wire to implement the protocol (look wireshark, no TCP traffic!).

The main difficulty I have working with the single board computers like BBB and Raspberry Pi is that I don’t know the overly crowded space. Good software might have terrible websites, yet vaporware always looks real. It took me a multiple hours of research and testing to settle on streamer to take still pictures and on feh to display them.

For the most part I used three units to do the setup and testing. Eventually, I got it working well-enough to go ahead and set up on all eight units. That was when most of the problems actually showed up, of course.

My pictures kept getting overexposed. They’d start out ok but get lighter all the time until all images turned white if the system was left alone. Of course, it took some time to figure out that the exposure setting was the problems since if I interacted with the units, it took much longer to get to white. Eventually I searched for possible causes, downloaded v4l-utils so I could try v4l2-ctl which communicates with the camera to change settings.  I added it to my start script and apt-get installed on all 8 units.

However, my pictures kept being overexposed at the top, for the top 20%. It wasn’t due to light flicker, pointing at a window (or covering the lens) got the same top part lighter than the rest image. It was definitely the image capture program. I’d put camorama as a step to verify the webcam worked from the display (it is a touch display, so pretty, so nice).  It didn’t have the same problem, but it doesn’t get stills. So I tried a different capture program: fswebcam. That didn’t help the problem and all a change of each control parameter didn’t help. However, fswebcam lets me take a bigger picture and then crop it down. So… problem solved-ish, once I apt-get installed on all 8 units.

I don’t know if that was an artifact of the camera I chose (the fairly expensive Microsoft LifeCam HD-3000). I tried a $6 from the random-cheap bin at Central Computer and it worked fine though the stills didn’t look as nice so I put it in a drawer, forgot about it. I may try to see if it causes the top-image-light problem but since I’m locked into the gear I have for this month, the only way is forward.

Though the slideshow program has been the stable and reliable part of the system for the last few weeks, I’m not sure I like feh. It has a term that will cause it to reload the image. So if I am on Charlie, looking at Alpha’s pictures, feh can reload every second so it shows the latest of Alpha’s pictures. Well, it can do that only if it is not also in automatic slideshow mode. It can reload images or change images. It is as though there exists only one timer in the world and feh must do the best it can with its feeble resources.

It is open source, I could download the code, understand it, fix it, and copy it to all of my units. Or I can make the slideshow a little faster so you are never stuck on one unit for too long.

The slideshow already gets a bit frenetic. Even with only three units it is a bit dizzying: the BBBs bright blue blinking lights, the screen’s orange blinking light and green shining one, the slideshow updating its window every second or ten, and the captured image updating every second. I had five units working Wednesday and will have seven or eight working all at once tomorrow.

I’m not sure how many they will run in Paris, it is ok with me if they only unpack three. And, I’m not sure I’ll have all eight working in the lab tomorrow because DeltaPuppy seems sick. Who gets a kernel oops in a mv command? I sort of expected that when I named GolfPuppy and HotelPuppy, those sound like slackers. Delta has spent more time getting its hardware put on different mountings so maybe it just got knocked around too much. (Yesterday, the mechE turned down my offer of ESD bag and carrying box, popped it into his bag; I begin to see why Delta is sick. Though, maybe this isn’t a sick puppy, just a victim of happenstance, he isn’t always sick…)

Our intern is going to Paris to herd the demo along (and a couple other dogsbody duties [omg, pun totally intended, snicker]). He didn’t even flinch when I gave him the two page long “here’s how you run it” instructions. Not even when I gave him the five page long “here’s how you build the system”, told him he needed to know in case anything went wrong. I think he’s really excited about going. I hope he brings me back something French.

I’m not going. I thought I might want to go. But things here are keeping me here and that’s ok.

The multi page instructions have been replaced with an expect script. Now it takes N lines to set up N units. And you don’t have to look up their identifiers, just know the first eight letters of the international phonetic alphabet. (The intern doesn’t know about this improvement yet, I’m looking forward to surprising him.) Also, expect is wonderful. I haven’t used it in years but it really is efficient. Now I know why my coworker asked why I was typing things instead of making a script.

Speaking of scripts, I wish I could turn off all the cruft that starts with the BBB. There are all these programs and I don’t really want them running (heck, I don’t want them there). I know I could edit init.d but I’m a little worried about breaking something. I haven’t yet seen a good guide to stripping down the BBB Debian system to the bare bones. Anyone have any suggestions?

Overall, I like the BBBs, I love these screens, I’m indifferent about the webcams, and I’m uncertain about the final mounting. I retain my Linux-is-hard-because-nothing-quite-works feeling. There is little standardization (one program likes to use man, another info, another has a sparse man page but gives a nicely detailed output with a command line –help invocation). And I like that this demo is built from off the shelf components, only a bit of extra software (most of which the demo team will provide in tutorial sessions). It has an “I built it, so can you” vibe going for it.