I initially had high hopes for the raspberry pi 3 and snapped up three of them. I hoped to see one take the place of my media center, another two for monitoring tasks. Unfortunately I became less than enthused about the pi for a media center as it has no good way to stream of youtube or vidangel. Additionally it couldn’t keep up with streaming some HD videos.

It has now been a few months since my initial disappointment and I decided to try out the new firmware and see if things got better.

The first tests i ran were using iperf. One raspberry pi, rpi1, was left behind at the old firmware. Another pi, rpi2, was upgraded to the latest.

Initial iperf test (iperf client running on my macbook, server on each raspberry pi – tests were run independently, on one raspberry pi at a time):

I also tried this with a parallel iperf test (iperf -c -P 10)

I also wanted to test sustained (iperf -c -t <10,120>)

Even on a udp iperf test (-u on the server, -b 50m on client) rpi1 gets 32 Mbits/sec, rpi2 gets about 39 Mbits/sec. In all cases there is a 5-9 Mbits/sec average higher increase with the new firmware. Pretty significant!

Note that if I run these same tests where my macbook is the client but a virtual machine on my network is the server, I see transfer rates in the 500 Mbit/sec range (the -P 10 test gave 513 Mbits/sec and the UDP test -b 1000m gave 627 Mbit/sec). This at least demonstrates that my infrastructure is more than capable of higher transfer rates. Thank goodness for 802.11ac routers!

It is also worth noting a few differences between the pi and vm tests. One difference is that the virtual machine is on a direct-cabled server, whereas both the raspberry pi and macbook are on wireless. Thus for the VM test, only one traversal of wifi is needed, whereas macbook to pi tests involve two traversals.

Now, if I upgrade rpi1 I would expect the numbers to be equal. Right…?

Strangely, no. Even after the upgrade I see rates in the 30Mbits/sec for rpi1. Digging deeper I found one minor discrepency between the two – i set aside 256 MB for gpu ram on rpi1, but only 128 MB on rpi2. Even after switching rpi1 to 128 MB, I still see the same numbers on both. I noticed I had a wireless keyboard adapter on the slower pi – but removing it didnt affect the transfer rates.

Another difference is that there is a raspberry pi camera on the faster pi – it would be interesting to see if that affects things.

I tried testing the ethernet interfaces and found performance across the pis identical.

At the moment I’m not sure how to account for the roughly 25% higher wifi performance on one pi over the other.

Having a bushel or two of apples on hand, I decided to make an apple pie the whole family could enjoy.  I borrowed two recipes.  For posterity i have included the actual recipe in addition to the links.

For the apple pie guts I used Apple Pie by Grandma Ople:

1 recipe pastry for a 9 inch double crust pie
1/2 cup unsalted butter
3 tablespoons all-purpose flour
1/4 cup water

1/2 cup white sugar
1/2 cup packed brown sugar
8 Granny Smith apples – peeled, cored and sliced
Directions
Preheat oven to 425 degrees F (220 degrees C). Melt the butter in a saucepan. Stir in flour to form a paste. Add water, white sugar and brown sugar, and bring to a boil. Reduce temperature and let simmer.
Place the bottom crust in your pan. Fill with apples, mounded slightly. Cover with a lattice work crust. Gently pour the sugar and butter liquid over the crust. Pour slowly so that it does not run off.
Bake 15 minutes in the preheated oven. Reduce the temperature to 350 degrees F (175 degrees C). Continue baking for 35 to 45 minutes, until apples are soft.

and for the crust I used French Pastry Recipe:

Ingredients
3 cups all-purpose flour
1 1/2 teaspoons salt
3 tablespoons white sugar
1 cup shortening

1 egg
1 teaspoon distilled white vinegar
5 tablespoons water
Directions
In a large mixing bowl, combine flour, salt, and sugar. Mix well, then cut in shortening until mixture resembles coarse meal.
In a small bowl, combine egg, vinegar, and 4 tablespoons of water. Whisk together, then add gradually to flour mixture, stirring with a fork. Mix until dough forms a ball. Add one more tablespoon of water if necessary.
Allow dough to rest in refrigerator 10 minutes before rolling out.

The results we’re fantabulous:

I am currently writing custom software to create a variety of distributed media solutions.  One of these involves a raspberry-pi security camera.  Right now my software isn’t finished, but I wanted to prove the concept out using existing software.  System requirements:

Raspberry pi:

• Broadcast audio (over the LAN) to a server
• Broadcast video (over the LAN) to a server
• Receive (and play over the speaker) audio

Laptop:

• Receive audio/video from the raspberry pi (and display it)
• Send audio (from the laptop’s own microphone) to the pi.

I bought a raspberry pi b+, cheapo USB microphone, and IR camera (with built-in LEDs), and some speakers.  The whole package was around $100, which is just plain awesome.  Im sure my grandkids will marvel, 40 years down the road, that for the cost of an Obama-approved school lunch, I could buy so much.

Here’s a schematic of the setup:

This can be accomplished with a few scripts, which i based heavily on those found here: http://blog.tkjelectronics.dk/2013/06/how-to-stream-video-and-audio-from-a-raspberry-pi-with-no-latency/

Run the following on the pi:

function on_signal (){
    launch "kill -9 $piVideoPid $piAudioPid $osxAudioPid"
}
trap 'on_signal' EXIT

# Receive os x audio
gst-launch-1.0 -v udpsrc port=9102 caps=\"application/x-rtp\" ! queue ! rtppcmudepay ! mulawdec ! audioconvert ! alsasink device=plughw:ALSA sync=false &
osxAudioPid=$!

# Send pi audio
gst-launch-1.0 -v alsasrc device=plughw:Device  ! mulawenc ! rtppcmupay ! udpsink host=$broadcastIp port=$piAudioPort &
piAudioPid=$!

# Send pi video
raspivid -t 999999 -w 1080 -h 720 -fps 25 -hf -b 2000000 -o - |  gst-launch-1.0 -v fdsrc ! h264parse ! rtph264pay config-interval=1 pt=96  ! gdppay ! tcpserversink host=$localIp port=$piVideoPort

Run the following on the laptop (a macbook in my case).  Note if this were a linux box you would probably use “autoaudiosrc”.

function on_signal (){
    launch "kill -9 $piVideoPid $piAudioPid $osxStreamPid"
}
trap 'on_signal' EXIT

piIp=<raspberryPiIp>

# Stream OSX microphone (note the capsfilter, apparently needed due to os x bug)
launch "gst-launch-1.0 -v osxaudiosrc ! capsfilter caps=audio/x-raw,rate=44100 ! audioconvert ! audioresample ! mulawenc ! rtppcmupay ! udpsink host=$broadcastIp port=$macAudioPort" "ASYNC"
osxStreamPid=$!

# Receive audio
launch "gst-launch-1.0 -v udpsrc port=$piAudioPort caps="application/x-rtp" ! queue ! rtppcmudepay ! mulawdec ! audioconvert ! osxaudiosink" "ASYNC"
piAudioPid=$!

# Receive video
launch "gst-launch-1.0 -v tcpclientsrc host=$piIp  port=$piVideoPort ! gdpdepay ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink sync=false" "ASYNC"
piVideoPid=$!

echo "Waiting on $piVideoPid $piAudioPid $osxStreamPid"
wait

You should be able to see and talk to whoever is on the other end of the pi. Biggest problem is audio feedback, if the laptop and pi are close to one another.  I havent even begin to think about this, but the coolest things to note are:

• You get a silky-smooth h264 video
• The audio is acceptable
• It works almost entirely using gstreamer.  The cool thing about that is gtreamer has a very easy programmatic API.  So… that makes my job easy when I get to that part of my project.

Enjoy!

Here it is, my first post of the new blog!

My nephew inspired the thought that led me to bring back the blog.  I told him he could easily setup something on my website if he wants to learn web programming.  Then I realized that for me to share the website, I’d have to figure out how to actually setup apache for subdomains.  I also wanted it to support https and http.

Turns out this is fairly simple:

• Add an A record to DNS for each subdomain
• Inside apache, include at least the following:

NameVirtualHost *:80

NameVirtualHost *:443

• For each subdomain make a conf file (in /etc/httpd/conf.d/) that includes a VirtualHost entry for each subdomain:

<VirtualHost *:80>
ServerName carson.fenimorefamily.com

# Index file and Document Root (where the public files are located)
DirectoryIndex index.html index.php
DocumentRoot <directoryForYourSubdomain>
</VirtualHost>

<VirtualHost *:443>
SSLEngine on
SSLCertificateFile <crtFileName>
SSLCertificateKeyFile <keyFileName>

ServerName carson.fenimorefamily.com

DirectoryIndex index.html index.php
DocumentRoot <directoryForYourSubdomain>
</VirtualHost>

Note that I basically repeat the same section for SSL and normal.  Why? Because in the SSL virtual host you actually turn on the SSL engine.  All the rest of the innards of each section could be placed in a separate file and included, I suppose, but prudence (or laziness) suggests otherwise for now.

Here’s looking forward to blogging about useful technical stuff; I’m purposefully not sharing juicy tidbits from my personal life, as I think the only interested parties for those things are web bots and terrorists.

I’ll even try to do some retroactive blogging of projects from the past eight years.  To that end I’ll write a TODO list here and see how well I do at whittling it down.

• Mapping out the East Coast – Really keeping a log of places we’ve been and interesting facts
• Becoming landlords
• The chicken pi – my solution for monitoring a bunch of chickens
• Some woodworking stuff – I have pictures, why not post
• My recent raspberry-pi camera solutions
• Some details from my thesis
• My latest discoveries in web programming (oh how i used to loathe web, until angular came along)
• Programming a game with my nephew

This was a nerd get together. The only rules: eat a couple dogs before going on to lesser things (E.g. smores). The other rule: bring your wife and kids, unless your Carson. Carson was exempt.

Here we have an assortment of pictures of the Hot Dog BBQ: http://www.oakenweld.com/coppermine/thumbnails.php?album=35

As the owner of a brand spanking new Canon SD1000, I unpackaged the included software and found a nifty tool called PhotoStitch.  The camera itself only provides a special function which assists you in providing overlap between successive images of a panorama. The magic of the stitchery is in the desktop software.

PhotoStitch does a descent job, given its design parameters: it is intended to do the stitching largely unaided.  Hugin, an open source tool for creating panoramas, requires that you specify the alignment control points.  Although seemingly daunting, the task is actually extremely easy.

As one majoring in computer vision, I should understand the algorithms a little better – to be able to compare the two on an algorithmic level.  What is clear, subjectively, is that Hugin is just more powerful. If it makes a mistake, i can go back and add a couple more control points and out pops a better alignment.  Here below is a sample of output from PhotoStitch (software from Canon) and Hugin (open source software).

PhotoStitch

Hugin

A few pics from the party in the preceding post.

We chose to take part in the long standing tradition of the hot dog bar today in the Magicc Lab.  The first hot dog bar started in the spring of 2007 while at the INL, established with the de facto condiments: ketchup, mustard, relish, and Sour Kraut.  Later that year mayonaise was added to the condiment canon. This year, beyond the sheer joy of partaking of hot dog goodness, we also investigated the evolutionary history of the dog.   Look below to see the four major stages of hot dog evolution:

1. Emerging from the sea of primordial null dog soup, the basic frank emerged, exhibiting little taste or desirable texture.  These dogs have been given the name sawdust dog (SD), or just plain wiener.  This basic life form has survived deserved extinction for eons because of its low market price.
2. Slight evolution spawned the Oscar Meyer Beef frank, a $5/pack dog with barely noticeable improvements over the SD. It is expected – or at least hoped – that this branch will dwindle into extinction soon.
3. After steady evolution, the SD developed into the present day polish dog. The polish offshoot may optionally include a cheese core, but the basic idea is an infusion of more palatable spices into the same basic link.  Note the baboon buttox and lengthy arms that are crude predecessors to fully evolved bratwurst, below.
4. The Bratwurst represents the apex of evolution.  Full-bodied taste is carried by its well-developed bipedal frame.  Sporting a refined neck tie and a full smile, this dog looks as good as it tastes.  Other names include heaven-on-a-bun, or the King of Dogs. Some have suggested the name of this species be changed from Bratwurst to BratBest, to better reflect its palatability.

Hot Dog Evolution:

Link links:

Travis Millet, pictographer of the dogolution:

http://themilletfamily.blogspot.com/

The Crispy Dog, thanks to Jeff Kennington:

http://www.oakenweld.com/coppermine/thumbnails.php?album=20

A friend stopped by yesterday mourning the loss of his MacBook Pro power  adapter.  Since he had already ordered a new one from Apple, I asked if we could try to resuscitate the “broken” one.    It turned out to be a simple fix:

• Chisel along the seam of the power adapter; this may be he hardest part – mainly because it seems so unreasonably hard to get the blasted thing open.  Keep on chiseling, it will give with time.
• Snip the old wires and solder on the new ones.

Did I really need to make this list? Bottom line: if your macbook adapter broke because you bent the cord to death, just pop it open and resolder.

Here we are, yet again, memory of memories, cross-country skiing in Rexburg.