Ones and Zeros

The year before last, we noticed more than usual of the flat, shield-shaped slow-flying stink bugs. Last year it was worse. We were finding them in the house. This year, there are many dozens on the porch screens and some dozen or more manage to get in.

Stink bugs teach us to be respectful. If you squish them, the smell is very strong and hard to remove. I learned that as a kid and the lesson stuck.

Turns out these are Halyomorpha halys or brown marmorated stink bugs. They’re exotics. They’re not native to this area and were from Asia originally. North America has their own stink bugs - it’s a group of beetles widely spread across the world. But this species was introduced sometime in the 1990s in Pennsylvania. Official initial sighting reports vary, but the earlest I found was in 1993 near Allentown. That means it was likely introduced a few years before. Accidental introduction with an imported plant is the most likely means.

Halyomorpha has currently spread through Pennsylvania, up to around Boston area, definately in northern Virginia, and has been sighted in Florida and California as well.

And yes there is an economic impact, they’re not just cluttering up our porch screens. They suck the juices from plants and fruit and damage the fruit for commercial sale. The plants become stressed by the bugs and grow and produce less.

They’re naturally resistant to pesticides and live for two years. Halyomorpha is hardy and lives in cold climates. Where I live they lay eggs once a year. In more southern climates, they’ll have two generations a year.

So one more exotic invasive species to deal with. The potential economic impact of Halyomorpha alone is much larger than a number of the scenarios that Dept of Homeland Security is examining. Expand that to all the exotic invasive species and we have a major issue. It’s not all just pythons in the Everglades, the problems are right here at home and more immediate than Al Queda.

When we moved into our current house (quite some years ago now) I decided that I didn’t want to run cat-5 wiring yet again. A few trials backed up that opinion. We decided to try this then new-fangled “WiFi” thing. I’d been using it at work and other places.

When I put our WiFi router in we had the only one within reception distance.

Now, of course, I think there’s one per house. Ok, that’s exaggerating. But it’s not uncommon to see 4 or 5 on my WiFi scanner at the same time. Most are only turned on for a while. I don’t understand this, ours is on all the time. After all, if you’re going to look something up on Wikipedia, check on an actor in IMDB while watching a movie on TV, check tomorrow’s weather during a commercial, or verify the lyrics to a song, you need a laptop that’s just sleeping, and an active WiFi connection. (All those examples are from last night.)

But, I’m not disappointed that my neighbors turn off their WiFi sometimes. It reduces the interference for us.

WiFi routers have an “auto channel select” which picks an unused channel out of the 11 or 15 channels (depending on what standard protocol set your router and computer know). This sorta works. Near my WiFi router there’s no substantial interference from the neighbors so my router defaults to channel one. But sitting with my laptop out on the deck, my laptop does see interference.

Unfortunately, most of the other WiFi routers my neighbors have also end up defaulting to channel one for the same reason. The result is WiFi congestion, low bandwidth, and even an occasional dropped connection. It makes me long for the days of pulling cables in the crawl space.

So hence my WiFi experiment. There are three non-overlapping channels for WiFi: 1, 6, and 11. The others overlap to some extent and the overlap degrades the bandwidth a little through the spread-spectrum link protocols. But having two or three of us all using the same channel stresses the spread-spectrum capabilities too far apparently.

I’ve now set my WiFi router to use channel 6, which isn’t widely used in my neighborhood. It’s still too weak on the deck to easily establish a connection for my older MacBook Pro laptop. (However, my wife’s newer laptop and our iPhones make connections easily there.) But the real test is maintaining a connection.

So far it’s working nicely. I’m just hoping our neighbors don’t catch on and change their channels too.

(Note: I’m using the term “WiFi router” pretty loosely here and just got uncomfortable with that.  Ignore this if you’re already familiar with networking equipment.  A “WiFi router” is a combination of a WiFi point-of-presence, a router (or more accurately in my case a hub), and a firewall. All three software devices are contained in one hardware device. This device is basically a specialized computer dedicated to these software programs. We see it as one thing since there’s one physical thing to see.)

The directional gyro was replaced in the plane today.  This evening, after a rather more careful pre-flight inspection than usual, I took off and checked the DG out in flight.  In short, it works.

The DG’s heading wandered a bit when the plane was a idle or taxi.  But that’s normal, there’s not enough vacuum to spin it up fully then.  But it self-erected properly and promptly.

After takeoff I flew headings in a big triangle at cruise to verify that the compass and the DG (when set correctly) agreed with each other.  I was concerned for a while because they were about 10 degrees different.  But at cruise in this plane, the compass vibrates.  When it does, it goes off heading due to resonance.  When I hold it still with my non-magnetic finger, its heading is valid.  And it and the gyro agrees then too.

I tried some turns around a point, the DG moved smoothly and evenly in both directions.  When I adjust the heading bug, the DG doesn’t “drift” as it was before.   Time to go back home.

Naturally, there’s a plane on a long straight in approach for the runway.  Everyone else was doing the normal 45 degree approach to downwind, so the guy on straight in was cutting across our path.  But we all worked it out and I had a nice smooth landing.  It was a landing that made me feel like a super pilot.  But no matter, I know I’ll have another landing sometime soon that’ll keep me humble.

Our plane is back in service.

I’ve been working on an application for the iPhone but it’ll never be on the app store. Courses and reading are all good, but if you’re going to know how to build something you ultimately have to learn by building. So when I learn a new system I always make sample projects. This one comes from the Stanford iPhone applications course (via iTunesU) that I’m doing.

This application makes polygons with user-variable number of sides. A slider or buttons control the number of slides, other buttons control a dashed or solid line around the polygon. There are various other features for drawing and updating text, etc. (A screen capture of the app is to the right. )

An interesting extra item in this exercise was to allow the user to drag a finger on the polygon and rotate it. This is my thinking behind the software development for this one feature.

It took me a bit of reading and experimentation to figure out that the rotate operation (CGContextRotateCTM) always rotates around the origin of the UIView. In the iPhone the origin is the top left of the coordinate space. But I wanted to rotate the polygon around it’s center, not the orgin. I ended up doing this:

CGContextTranslateCTM(context, self.bounds.size.width/2, self.bounds.size.height/2);
CGContextRotateCTM(context, rotateAngle);
CGContextTranslateCTM(context, -self.bounds.size.width/2, -self.bounds.size.height/2);

This translates the center of the polygon to the coordinate space origin, rotates that space, then translates the polygon back to its starting location, but rotated now. There are other ways to do this transform and I’ll have to learn them at some point, but this seemed the best for now.

Figuring the angle to rotate was interesting too. First, I had to refresh my trig knowledge as I don’t use it much. I have several points: the center of the polygon, and the position that the user has their finger on. When I touch my finger to the polygon I get the “touchesBegan” event. Then when I drag my finger on the polygon, the app gets a series of new finger positions as “touchesMoved” events. When I lift my finger, the app gets the “touchesEnded” event. All the events have their location as a parameter.

Given these positions I needed to calculate the starting angle of the finger drag from the center of the polygon, and the successive angles as new events came in. The new angle of rotation (rotateAngle above) is the difference of those two calculated angles.

I used the right triangles as shown here in the square polygon to find the angles. The center of the square has the blue dot, the first event (”touchesBegan” event) locations is red, and the second is green (”touchesMoved” event). I used the formula of opposite side length/hypotenuse side length to find the sine, then used arcsine to find the actual angle.

Due the way I was calculating the angle, I had to adjust the sign of the angle value and it’s magnitude depending on the relative location of the center and the touch points. My calculation gave angles 0-90 degrees only. The triangle would be upright or upside down in the example here. Or it would be reversed if the touch point was to the left of the center. (All angle calculations were in radians though.)

In my code I’d be saving the cumulating angle of rotation, I initialized this to zero. The new angle of rotation was this old saved angle plus the difference of the two angles I’d calculated above. Then, I redrew the UIView to show the polygon rotated. When the “touchesEnded” event happens, then the old saved angle plus the current angle difference is saved as the new cumulative angle of rotation.

So now the polygon turns under my finger as if I were moving a real physical object mounted on a turntable.