What’s In That Survey Kit? (Fall 2019 Edition)

October 4, 2019 |   |  Comment  |  Hardware, nerd, Wireless

The life and contents of a survey kit is a dynamic one. Here’s what’s in my kit these days. The Pelican 1510 is airline carry-on size, because there’s no way they’ll let you check that stuff with the batteries (which are all just under the airline limit of 100Wh), and the contents are valuable enough that you probably don’t want it out of sight, or trust it to the airline baggage handlers. If you’re carrying this stuff, it’s because you need it at your destination. Downside is that the 1510 doesn’t allow the overhead bin to be closed on Embraer 135/145 regional jets.

Links go mostly to Amazon where I get all this stuff

All this fits inside the case…
See? Whole thing weighs a little over 20 lbs, and there’s room to spare. Bright yellow inside makes it harder to lose stuff in there. Tripod is held in place with some velcro straps screwed to the lid.

  • Floater items that go between kits:
    • BatPower PDE2 96Wh USB Battery Pack (Amazon has removed this item. The upcoming Accelerator 2.0 battery pack from AccelTex will have full power type C PD ports on it)
    • EU/US power plug adapter
    • Swift Body Platform Harness (for carrying survey laptop and avoiding Survey Elbow, the nerd version of tennis elbow)

Also, if you’ve started adding this up in your head, you can see why I carry this on instead of leaving it to the baggage system. Make sure your business has insurance, especially if you’re self employed. If you’re traveling overseas, you’ll need special insurance coverage. I used to carry audiovisual insurance (the kind news crews carry) when doing streaming, and those policies will even cover against force majeure and acts of God. I don’t know if there’s an IT equivalent.

On Network Models

March 31, 2018 |   |  1 Comment  |  nerd, networking, Wireless

One of the most fundamental concepts underlying modern data networking is that of the network

“stack”, which consists of individual “layers” that allow one to describe a network without actually getting lost in the weeds of specific underlying technologies. There are two models that are in common usage (there are several others as well but are less common):

  • the seven-layer OSI Model (which is largely theoretical), published in 1984 as ISO standard 7498 and officially known as the “Open Systems Interconnection Reference Model” (Kansas connection: the OSI model’s designer, Charles Bachman III, was born in Manhattan, the son of the head football coach at K-State at the time)
  • the four-layer TCP/IP Model (which is a more practical model owing to the widespread use of the internet). The TCP/IP model predates the OSI model and can trace some of its roots to BBN’s early work on internetworking in the late 1960s.

One of the key principles of the model is that each layer is carried by the layer below it. The layers each have their own methods and protocols, which are (for the most part) independent of the layers below that are carrying them from A to B. In the TCP/IP column, I’ve also indicated what type of system operates at that layer.

Network Model
OSI TCP/IP OSI Protocol data unit (PDU) Function
Host
layers		 7. Application Application

(Computer)

 Data High-level APIs, including resource sharing, remote file access
6. Presentation Translation of data between a networking service and an application; including
5. Session Managing communication sessions, i.e. continuous exchange of information in the form of multiple back-and-forth transmissions between two nodes
4. Transport Transport

(ISP)

Segment

 Reliable transmission of data segments between points on a network, including segmentation, acknowledgement and multiplexing
Media
layers		 3. Network Internetwork

(Router)

 Packet Structuring and managing a multi-node network, including addressing, routing, and traffic control
2. Data link Link

(Switch)

 Frame Reliable transmission of data frames between two nodes connected by a physical layer
1. Physical Bit Transmission and reception of raw bit streams over a physical medium

The importance of understanding these network models comes into play is when you are designing or troubleshooting a network. Understanding at what level your problem is happening is a major step towards solving it. I’ve seen and answered countless questions on Quora about “why doesn’t X” work, or “can someone on the internet trace me by my MAC address?” and various other questions that can be enlightened by an understanding of the network models. As a general rule, the lower you are in the model, the more physically localised you’re dealing with.

It’s probably difficult to wrap your head around if you’re not used to this kind of stuff. So let me offer up an example of how this same network model manifests itself in the real world, completely unrelated to computer networking. You’ve almost certainly seen it in action. You’ve benefited from it in your life. I give you: Container Shipping.

Container shipping relies on a standardized set of steel containers (also defined by the ISO) that can be used to haul goods efficiently around the world.

Here’s what the Transport Layer looks like:

Notice that the container is itself full of smaller containers (plain cardboard boxes: The session layer) – which themselves may contain additional boxes for retail (presentation layer), which contain an actual product (application layer). When the container is closed and sealed, its contents go wherever it goes.

But how does it get there? It makes use of the Network Layer. This is where it goes through one or more shipping companies (like ISPs) that get the contents from the factory in China (server) to the buyer (client). As in computer networking, This transportation company can use multiple types of ways to get it there, such as trucks, trains, ships, and airplanes. These are Layer 2, the Link Layer, and are all capable of carrying these containers.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Each of these Layer 2 conveyances rides on a different physical medium: Roads (land), Rails (land), Shipping routes (sea), flight paths (air).

It’s also worth noting that two of these physical media are bounded media (roads and rails) which constrain the path the vehicle takes. This is akin to a wire or fiber optic cable.  The other two (sea and air) are unbounded, which means the vehicles can take any path they choose. This is akin to free-space optical transmission and wireless RF transmission – it also means those are more susceptible to interception (hijacking/piracy).

I mentioned earlier that a layer 3 device is a router. Its job is to get the data from one network to another. What does this look like in container shipping? One of these giant cranes that remove the containers from one conveyance, to be loaded onto another. Sometimes, it will buffer them in a container yard before sending it on to its destination.

 

Once the container gets to its destination, it is signed for (an ACKnowledgement in the network world), and the signature is sent back to the shipper to confirm that it arrived at its destination – this is a transport layer function, as it is the shipper’s responsibility to make sure stuff gets there on time. The buyer and shipper (Layer 7) don’t really care *how* it got there, just that it did.

 

EC2 Monitoring with Raspberry Pi

May 4, 2017 |   |  2 Comments  |  Cloud Computing, Code, Hardware, nerd, networking

I’ve been doing a little Raspberry Pi hacking lately, and put together a neat way to have physical status LEDs on your desk for things like EC2 instances.

The Hardware

In its most basic form, you can simply hook up an LED and a bias resistor between a ground line and a GPIO line on the Pi, but that doesn’t scale especially well – You can run out of GPIO lines pretty quickly, especially if you’re doing different colors for each status. Plus, it’s not overly elegant.

The solution? Unicorns!

No, really. The fine folks at Pimoroni in Sheffield, UK have made a lovely little HAT device for the Pi called a Unicorn. Its primary purpose is lots of blinky lights to make pretty rainbows and stuff, hence the name. However, this HAT is a 4×8 (or an 8×8) array of RGB LEDs, addressable via the I2C bus, which doesn’t eat up a line per LED (good thing, otherwise it would require 96 analog lines). The unicornhat library (python3-unicornhat) is available for Python 2 and Python 3 in the Raspbian repo. When installed onto the Pi, the Unicorn will fit within a standard Raspberry Pi case.

The Code

This is my first foray into Python, so there was a bit of a learning curve. If you’re familiar with object-oriented code concepts, this should be easy for you. Python is much more parsimonious with punctuation than PHP or perl are.

For accessing the EC2 data, we’ll need Amazon’s boto3 library, also available in the Raspbian repo (python3-boto). One area where boto3 is really nice is that the data is returned directly as a dict object (what users of other languages would call an array), so you don’t have to mess with converting JSON or XML into an object structure, and it can be manipulated as you would any other associative array (or a hash for you old-timers that use perl). AWS returns a fairly complex object, so you kind of have to dig into it via a few iterative loops to extract the data you’re after.

From there, it’s a matter of assigning different RGB values to the states. I chose these ones:

  • stopped: red
  • pending: green
  • running: blue
  • stopping: yellow(ish)

I also discovered that I needed to assign a specific pixel to each instance ID, otherwise they tended to move around a bit depending on what order AWS returned them on a particular request.

Here’s what the second iteration looks like in action:

import boto3 as aws
import unicornhat as unicorn
import time

# Initialize the Unicorn
unicorn.clear()
unicorn.show()
unicorn.brightness(0.5)

# Create an EC2 object 
ec2 = aws.client('ec2')

# Define colors and positions
color = {}
color['stopped']={'red':255,'green':0,'blue':0}
color['pending']={'red':64,'green':255,'blue':0}
color['running']={'red':32,'green':32,'blue':255}
color['stopping']={'red':192,'green':128,'blue':32}
	
pixel = {}
pixel['i-0fa4ea2560aa17ffd']={'x':0,'y':0}
pixel['i-06b95cd864acb1a8c']={'x':0,'y':1}
pixel['i-0661da0f50ffb604c']={'x':0,'y':2}
pixel['i-063ec151e0f44ef9b']={'x':0,'y':3}
pixel['i-02c514ca567d8a033']={'x':0,'y':4}

# Loop until forever
while True:

	response = ec2.describe_instances()
		
	
	statetable = {}
	resarray = response['Reservations']
	for res in resarray:
		instarray = res['Instances']
		for inst in instarray:
			iid = inst['InstanceId']
			state = inst['State']['Name']
			# print(iid)
			# print(state)
			statetable[iid] = state
	
	
	for ec2inst in statetable:
		x = pixel[ec2inst]['x']
		y = pixel[ec2inst]['y']
		r = color[statetable[ec2inst]]['red']
		g = color[statetable[ec2inst]]['green']
		b = color[statetable[ec2inst]]['blue']
		# print(x,y,r,g,b)
	
		unicorn.set_pixel(x,y,r,g,b)
		unicorn.show()


	time.sleep(1)

For the moment, this is just monitoring EC2 status, but I’m going to be adding checks in the near future to do things like ping tests, HTTP checks, etc. Stay tuned.

Balloonar Eclipse!

May 20, 2012 |   |  Comment  |  Flying, fun, nerd

Here in Kansas City, we’re on the very edge of the eclipse path, and it was a beautiful night for a balloon flight too. (KOJC 210053Z 34006KT 10SM CLR 22/09 A3013 RMK AO2 SLP196 T02170094). As I was out looking at the eclipse, along comes Jason Jones of Old World Balloonery with a load of passengers, and I got a balloonar eclipse as a bonus.

My crappy phone camera gave me neat lens flare showing the eclipse in progress next to the balloon:

 

Energy-Efficient Lighting: LED Bulbs

February 22, 2010 |   |  3 Comments  |  nerd

The biggest electrical energy drain in your home is usually lights. It goes without saying that if you can address that area, you’ll be a whole lot happier when the electric bill comes.

To this end, we’ve been replacing the lights in our home, starting with CFL a few years ago.Rather than an all-out replacement campaign, we simply replaced bulbs as they went out, under the premise that those are the ones that are on most of the time, and consequently consume more energy. There are several lights in our house that are incandescent, but are rarely used. As such, changing them is not a cost-effective proposition, given the higher cost of the bulbs. There are other areas in the house that are on dimmers, so CFL was not an option there.

One area where I absolutely love the CFL’s usually annoying habit of having to warm up to full brightness over a few minutes? The master bathroom. The overhead light there needs to be reasonably bright, but first thing in the morning, a 100W bulb is an assault on the senses. The 13W CFL there now warms up gently (slower on colder mornings) and isn’t quite so rough when you wake up.

Even CFL bulbs have a limited lifetime (about 2-3x that of incandescents), so those are starting to die now, and need to be replaced. Disposal of fluorescent lights is problematic due to a number of toxic substances involved. Over the past few years, LED bulbs have become a much more mature technology, and the price has come down substantially. Most residential LED bulbs are expected to last 20 years.

Where I’m using LED bulbs in my house:

Kitchen Track Lighting. Gradually replacing the eight halogen GU10 bulbs. So far, I’ve got three 4W Philips LED bulbs from Home Depot ($30). They’re just as bright as the 50W halogens, and they don’t emit any IR to speak of (the halogens would melt butter on the counter!). Net Cost savings over the 10-year lifetime of eight bulbs: around $1500.

LED StackMaster Bedroom. Just got a set of four Dimmable 8W LED lamps from LED Liquidators (please ignore the horrible web design – it seems to be a common problem with online LED retailers) that claim to be equivLED Stack Bulb in Ceiling fanalent to 60W. These go in the ceiling fan and are ideally suited to that application – they’re on a lot, on a dimmer, and the fan has a lot of vibration, which is really hard on incandescents. Net cost savings over 20-year lifetime of the bulbs: $800.

And if you’re into that sort of thing, it also reduces your carbon footprint.

Update, December 2010: All four of these bulbs have failed – they’ve got entire strips of LEDs that are flickering or flat out not working. An e-mail to customer service in October went unanswered. Called by phone and they said “customer service will call back and take care of it”. We shall see.

An interesting look at the Canadian economy

June 17, 2008 |   |  Comment  |  nerd

Take a look at this data coverage map from Sprint. Orange is EV-DO, Yellow is 1xRTT:

Wireless Data Coverage to the north

That spot with lots and lots of EV-DO, disproportionate to the rest of the country? That’s Alberta. The entire province is a mere 3.5 million people.

The isolated (but large) blob in the northeastern part of the province is centered on Fort McMurray, population 47,000. The EVDO coverage area is probably several thousand square miles.

Three guesses where all the oil is 🙂

Doh!

April 2, 2008 |   |  Comment  |  nerd, Wireless

So, the rolling hotspot went dead just north of Wichita. All due to a dead battery.

It seems the Mogul, when running WiFi and EVDO, draws more power than my 12V charger can provide. I shoulda brought the 110V charger that came with the unit and plugged it into the power strip in the car. Once we got to the hotel, I borrowed one from Jason Lee, and battery levels increased when running WMWifiRouter on the AC adapter. I think the culprit is the cheap 12V adapter I got at Wal-Mart… it was $7, instead of the $40 that Sprint wanted. It was labeled as a BlackBerry charger, so my guess is there’s a current limiting circuit in there designed to keep the BB from incinerating itself, but is insufficient to power a Mogul running at full bore. I checked on JLee’s charger, and it sources 5V/1A, which is a pretty serious amount of juice.

Liveblogging from the road!

April 1, 2008 |   |  Comment  |  nerd, Wireless

As promised, I’m rolling down I-35, chatting on IRC, and having a webcam chat over MSN with my dad (who uses a Linksys EVDO router for his access at home). Matt is hacking code from his laptop. Clif is paying attention to the road. Since we’re gonna be on interstate highway the whole way, we can pretty much count on a solid EVDO connection the whole way.

I’ve got a running ping going to 4.2.2.2 (a public DNS server). It’s interesting to watch the ping times start to get a little long, then we lose a packet, and then the ping times drop back down to the low 100s. I’m guessing those are tower handoffs. The fact that it works at all is nothing short of miraculous.

Recipe For a Road Trip

March 31, 2008 |   |  1 Comment  |  nerd, Wireless

Half the Resurrection IT crew is getting into the LovingWaiterMobile and hitting the road tomorrow for MinistryTECH/Spring RoundTable. Being geeks, we need net on the go. Here’s how:

Take one Sprint Mogul (or equivalent):

Add the following:

Version 3.0 Rev.A/GPS/WiMo 6.1 firmware update
WMWiFiRouter software
Google Maps for Windows Mobile
An external power source (not strictly necessary, but highly recommended if you’re going to do this for more than about 20 minutes)

Stir carefully and set up the ad-hoc connection on your client devices, and connect.

The result:

Beats the pants off this for sheer elegance, while providing the same functionality:

So where does Google Maps come in? Simple – for GPS Navigation. Which it can do while dishing up wi-fi to our laptops. Now we just need something that will upload our position to a live map 🙂