IM-ME Proof of Life

I have been making progress on using a Pretty Pink Pager as a receiver for the Davis Instruments Wireless Integrated Sensor Suite (ISS).  The ISS, in case you weren't aware, is the outside part of the weather station that records wind speed, wind direction, rainfall, temperature, and humidity.  Anyhoo, I got this going last night.

Click to Embiggen

Here is what this display is showing:

• Freq is the frequency the IM-ME is set to receive to, in Hz.  The hex value below that is the corresponding settings written to the FREQ2, FREQ1, and FREQ0 registers on the CC1110 processor in the IM-ME.  I wrote a simply Python script to make sure I was properly converting the raw frequency to the register values as a double-check.
• Chan is the channel ID.  The Davis system uses 51 channels for its Frequency Hopped Spread Spectrum (FHSS) scheme.  This really doesn't do anything.  Yet.
• Cal is the result of the frequency calibration executed using the RFST_SCAL command.  This value gets written to the FSCAL3, FSCAL2, and FSCAL1 registers on the CC1110 processor.
• RSSI is the current Received Signal Strength Indicator.  In other words, this is the received power picked up by the IM-ME.  It updates many times per second.
• Max is the good stuff.

I fired up my little program and watched as the RSSI value bounced around in the noise at a value of around 65 to 70.  Then I brought over my wireless console over and put it into diagnostics mode by pressing the TEMP and HUM(idity) buttons at the same time.  Pressing 2nd CHILL brings up a second display that shows the channel number the receiver expects the ISS to transmit next.

Just after the Davis console started scanning for Channel 0, the Max value of the RSSI jumped from around 70 to the 113 value shown above.  YES!  The IM-ME was seeing the power in the signal transmitted from the ISS.  This made me pretty happy to say the least as it proved out a number of things:

• I was properly calculating the frequencies based on the hex values sniffed when I worked out the Davis frequency hopping sequence.
• I was getting other basic aspects of the radio configuration correct.
• I can write a simple program.

The first bit about the frequencies being calculated correctly was a big deal.  I had been led to believe from some of the Davis FCC documentation that the 51 hop frequencies were evenly spaced by 500 kHz between 902.5 and 927.5 MHz.  The values I sniffed in the link above told a different story: the frequencies were only roughly aligned to that spacing, with significant deltas of 100 kHz or more in places.  I wasn't sure which was correct, and I wasn't prepared to take my ISS to work to look at the signal on a spectrum analyzer to find out.

One thing I built in to my little test program was the ability to adjust the center frequency of the radio in steps as large as 1 MHz and as small as 1 kHz.  This let me tune to other channels in the hop sequence.  If I saw a big spike in the RSSI value at the right time, I would know that I wasn't getting lucky on just the first channel.  And indeed, I was able to tune to the next calculated channel frequency and watch the Max RSSI value jump up at the right time in the sequence, as expected

As far as being able to write a simple program, that is probably overstating it a bit.  If it weren't for the amazing work by Michael Ossman, who wrote the IM-ME spectrum analyzer on which my program is based, I'd be totally screwed.  Michael, in turn, based his work on an earlier reverse engineering effort on the IM-ME at Dave's Hacks. And so on down the line it goes.  I will of course share whatever I come up with once things get further along.

So I can see the power in the signal now, but I'm still a ways off from getting actual data.  The first problem that I have to overcome is determining how the ISS sends synchronization and preamble information to the console.  I never really realized how much this involved until I dug in to it this weekend.  The CC1021 in the ISS and the console leaves this chore to the firmware of the processor controlling it.  The CC1110 does a lot more to handle this automatically, but you still have to tell it what to look for.  And the problem is I don't know what to tell it to look for: that information isn't available for sniffing on the SPI bus.  What I think I'm going to have to do is open up the console yet again and look at the signal lines that carry the data bits back and forth between the CPU and the radio chip.

Stay tuned.

Baby Steps

Tool chain: Check!
IM-ME: Check!
GoodFET: Check!

Let's get this party started.

Blogger, You Suck Hard

I am angry.

This evening I went to sit down and finish yet another epic blog post that I've been working on for days.  Just a quick proof read plus a few cleanups here and there.  I open the post in Blogger's editor.  It goes on for pages.  It looks great, and it should, because I have put all kinds of effort in to this.  I type a couple characters and hit Control-Z.  Suddenly every word and image in my post disappears.  I see the Autosave button flash.

And I am right fucked.

Because it is gone.  All gone.  Undo does nothing.  Hitting the Back button does nothing.  Closing the post and reopening does nothing.  Frantics searches bring up nothing that can bring it back.  Why don't I just revert to an earlier draft?  Because there is no revert to a previous draft.

What the fuck Blogger?  Is a working undo something that is really that hard?  Really???  Why can't I revert to an earlier draft?  Why didn't the Undo work?  I am not the only one complaining.  There are many more who have suffered this problem.  And tell me, why do you sit there with your thumb up your ass and not respond to your users?  It goes on an on and on.  You could always do a Google Search to see how pissed off people are. Are you too blind to realize that the best workaround being suggested is to use Windows Live Writer as an editor?  Even with that I am still up shit creek because I use Linux.

So fix this.  Fix it now.  And then how about a basic table editor, for chrissake.

Happy Birthday to My Best Friend

This blog tends to cover a lot of ground: from landscaping to food to hacking.  Some stuff is pure technical geekery, while other stuff is more personal.  This blog entry will be some of the latter.

It has been said many times that man's best friend is his dog.  Here is mine.  Her name is Abby and she is indeed my best friend.

Say Hello to Abby

I write this on a special day as it is Abby's 11th birthday.  Her mother was a purebred Chesapeake Bay Retriever and her father was a German Shepherd that happened to be nosing about at the right time.  Abby was an accident, but a happy accident.  Happy Accident #1.

My Lovely Wife and I were new in town, and we were about to move into our new home on an acreage in a week.  She was phoning around for alarm systems when someone told her that she'd just be better off with a big dog given our remote location.  Our friend gave us directions to a pet store, but since we didn't know the city, we went to the wrong place.  Happy Accident #2.

It was very much love at first site, despite knowing nothing about her breed.  We looked it up in one of the books at the pet store and it described Chesapeakes as "large, solid dogs".  Indeed, she weighed 18lbs at eight weeks of age.  We didn't know it then, but the size of her knees were a giveaway that she would someday fit the advice given to us by the alarm system salesperson.

We took her home a week later.  Our new home was about a half hour drive away from the store.  We were within a quarter mile of the new place before she turned her head towards me and threw up all over my jacket.  Happy Accident #3.

Over the years, Abby would grow out of her car sickness and grow in to her knees, tipping the scales around 82 lbs at one point.  We brought her with us when we picked up and drove 2000 miles to our current home around eight years ago.  One of the prerequisites in picking our new home was some place that would be dog friendly.  Chesapeake's were bred to retrieve game fowl from the icy waters of the Chesapeake Bay on the U.S. East Coast, and when a nice place right on the river came along... well...

Less Icy In the Summer

Our home on the river means we have lots of wildlife wandering by, and then fleeing for their life once Abby catches wind of them.  The trails we maintain through the forest alongside the river's edge makes walking the dog a joy, not a chore.  My Lovely Wife's "job" is to keep the home fire's burning while I am at work, and they enjoy several beautiful walks each day.  The two are inseparable.

Abby On Bush Trail Patrol

Fortunately for us, we don't have to worry too much when Abby tears after some critter like a bat out of hell.  She is big enough and strong enough that she can handle herself for the most part.  For the most part.  Abby likes to act first and think about questions later.  A good question to ask up front might have been "Should I really go after that porcupine?  Again?"

Not Such A Good Idea, As It Turned Out

Another Chesapeake behavior that Abby features is a certain stubbornness. Strangely, this feature is not mentioned in books that encourage people to get a Chesapeake.  She listens to us when she wants to.  At times this is maddening; at other times, hilarious.  But it gives her an unpredictable nature to her character that makes Abby the dog she is, and I'm not sure I'd want her to be any different.  I like to think of it as selective understanding.

While she has many Chesapeake qualities, her German Shepherd side comes through in several ways as well.  The coloring around her muzzle is one obvious spot, but another one a little less obvious is the Shepherd instinct to always walk a little bit ahead and lead the way.  This has an interesting side effect: she is in every picture we have ever taken.

Abby Hamming It Up... Always

Abby's many interesting qualities and the environment she lives in have combined to give an endless stream of wonderful stories over the past eleven years.  Since it takes a long time to type in an endless stream of wonderful stories, I'll pick three favorites.

Story #1: A year after we got Abby, we had a visit from some friends whose daughter was maybe a year old at the time.  She was just getting good at walking but was not yet at the point where she could build a lot of speed.  Somehow, this little girl quickly built a connection with a dog that was much taller than she was and many times her weight.  The little girl would toddle out from the kitchen table to the living room with Abby walking slowly behind.  They would switch around at the coffee table in the living room so that Abby walked in front on the way back to the kitchen with the little girl following behind.  They did this once or twice before anybody really realized what was going on.  It was one of the most amazing things I've ever seen.

Story #2: My Lovely Wife plugged a kettle in before heading upstairs to take a shower.  Abby started barking soon after.   My Lovely Wife yelled at her to stop but Abby keeps at it.  Finally, My Lovely Wife heads back downstairs to see what all the barking is about before starting her shower.  It turns out that the cord on the kettle was shorting out and the kettle's base was starting to smoke and melt down.  My Lovely Wife was able to unplug it before any serious damage was done.  Abby just might have saved our house from catching fire and burning down.

Story #3: Not that long ago, a group of people came in to our yard to sell us some religion.  They rang the front doorbell and Abby went crazy.  My Lovely Wife mistakenly answered the side door.  She was busy and didn't have much patience for what she knew this crew was here to do.  She was holding Abby by the collar at the side doorstep as Abby was working hard to pull away.

Them [nervously]: "My!  HE's a big one!  I hope HE isn't hungry!"  [Abby gets called a HE all the time because of her size].

Abby decided to answer the only way she could, and she did so with the timing of Bob Hope.

Abby: BEEEELLLLCCCCCCCCHHHHHHHH.

Them: "Oh, I can see you are busy.  We best get going now."

And they drove the hell out of our yard at high speed.

I think you get the idea.  My Lovely Wife and I believe that Abby is a very special dog and we love her will all our hearts.  She has certainly slowed down over the years, and I know she won't last forever.  But neither will I.  That is why Abby's will bequeaths everything she owns to me, and why my will bequeaths everything I own to her.  Until that fateful day comes to pass, I cherish every day with her.  Every single day.  And that is no accident.

Happy Birthday Abby, and many more.

--------------

P.S.  If you'd like to know more about Abby, My Lovely Wife keeps a diary of her various adventures here on Dogster.  There you'll find many more stories and pictures that will be sure to get a laugh.  Skip anything related to garter snakes if you are squeamish.

Troubles with IM-ME and the GoodFET

I have been spending some time recently with my IM-ME Pretty Pink Pager and my GoodFET.  Most of this time has been unproductive, unfortunately.  I think I might finally have sorted out all the issues causing this, and I'm using this post as an opportunity to record it all so I know what to do next time, if there is a next time.  This is all running under Linux: your mileage will vary under another OS.

I came across my first hurdle some months ago.  Commands like this:

goodfet.bsl --fromweb
goodfet.monitor test

would give me this:

Resyncing
Resyncing
Resyncing

These messages would spit out every couple of seconds.  Now these commands don't require any kind of connection from the GoodFET to the IM-ME: the messages indicate that the laptop and my GoodFET can't communicate.  After much pulling out of hair (made more painful with the fact that my head is shaved), I discovered that my GoodFET PCB had two bad vias.  Unfortunately, these vias were under the processor, and the processor is surface mounted to the PCB.  It took some tricky soldering, but I was able to patch around these vias and get back in business.  However, it seems I needed to use the --slow parameter to goodfet.bsl to get it to work.  Whatever, I was happy.

Tricky Soldering

Then over the Christmas break, I broke out the IM-ME and the GoodFET in the hopes of getting something productive done.  No way.

Resyncing
Resyncing
Resyncing

This would again spit out once every couple of seconds despite the fact everything seemed to be working well the last time I'd left it.  More hair pulling ensued.  Nothing would work.  In a fit of desperation, I went back to an older version of the GoodFET client that I had on my laptop.

It worked perfectly.

I'm not sure why (maybe this?), and right now I don't care.  But a fairly recent version of the GoodFET client software was totally broken for me.  The client dating back to Feb 26th 2011 works great.  And I just checked out the lastest SVN version of the GoodFET code and that is worked great as well.  Just my luck.

So everything is working.  Fantastic.  I sit down at my laptop this afternoon to see if I can get something productive done once again.

Resyncing
Resyncing
Resyncing

Argh!  This time the messages were flooding across my terminal window.  Last time, they were separated by a second or two.  This seemed to be more an issue on the laptop side than the GoodFET.  I had noted that the laptop had been put to sleep since it was last working.  "Simple enough", thought I.  Something wasn't being handled coming out of sleep and all I needed to do was unplug the GoodFET's USB connection and plug it back in again.  No luck.  Taking the batteries out of the IM-ME while unplugged from USB either didn't help.  Restarting the laptop fixed the problem, but the problem would come back every time coming out of sleep.  A bit of Googling and I came across a blog post from years ago that discussed a fix for a similar problem for stuck USB memory sticks.  That particular trick didn't work for me, but this one does.  As root:

# modprobe -vr ftdi_sio
# modprobe -v ftdi_sio

The ftdi module is responsible for communicating with the USB to Serial chip (FTDI FT232RL) on the GoodFET.  Apparently, the ftdi driver has a sleep problem of some kind.  Removing and re-inserting the ftdi module sorts things out.  This is with the 3.1 Linux kernel, BTW.  Hopefully this gets fixed sometime.

I noticed that the Feb 26th version of the GoodFET client software would flood the screen with Resyncing messages after the laptop came out of sleep, but the latest version of the software does the usual message every second or two.   Dunno why this is.  Either way, the modprobe dance above fixes either version.

Finally, if you see something like this:

[dk@laptop client]$ goodfet.cc info
  File "/usr/local/bin/goodfet.cc", line 22
    print "# %s" %s;
               ^
SyntaxError: invalid syntax

then you are getting burned by Python versions.  Distributions like Arch Linux default to Python3, but the GoodFET client assumes Python2.  To fix this, edit the first line of the various GoodFET scripts you use from this:

#!/usr/bin/env python

to this:

#!/usr/bin/env python2

and you'll be good to go.

Now to get something useful done...

ADDENDUM: So just after posting this, what did I get?  You guessed it..

Resyncing
Resyncing
Resyncing

The only thing I changed this time was the USB cable.  I went from a longer, more flexible cable with a choke at the end to a shorter, stiffer cable with no choke.  Operation with this shorter, cheaper cable is definitely unreliable.  Moral of the story: try a different cable if all else fails.

Pretty Pachube Plotting Progress

Edit: January 4, 2012. My Pretty Pachube plots seem to be showing up only part-time. I suspect that there is some throttling going that I need to get a grip on, perhaps because the feed data I am plotting is not my own. Please leave a note in the comments if you have an idea of what might be going on.

In my last post, I wrote about motivating myself for 2012.  Goals #1 and #2 had to do with working out, but I felt like a bucket of crap on the first day of the New Year and had little energy and less motivation (thank you very much, rhinopharyngitis).  I just felt like lying around like an inanimate carbon rod.

The Only Thing Keeping Me From "Employee of the Week"

But NO!  I have things I've gotta get done, so I thought I'd work a bit toward Goal #3.  Goal #3 was to get a basic home monitoring system set up, and one of the ideas I had was pushing that data out to Pachube to act as a repository for the data I would collect.  I'm not actually pushing out any data just yet, so I thought I'd dig into the presentation side of it.

Searching around on the Pachube web site, I came across the  Zoomable 30 day graph documented on the apps section of their site.  There is a nice little setup there where you can set up the graph's basic configuration online.  Give it a feed and datastream ID, a few parameters on size and color, and it spits out some code to cut and paste into a blog entry or web page.  Simple, eh?

Don't use it.  It has a couple of limitations:

1. It can't put multiple lines on the same plot
2. It doesn't work.

It actually does work until you try and plot more than one graph on the same web page.  The script doesn't handle multiple instances properly, and you end up wasting a bunch of time before finding this out.  Ask me how I know.

The link above does, however, include the following comment:

Note: if you are looking to combine multiple datastreams on the same graph, either by summing them or displaying them separately, see this post in the community forum for a solution. 

That is almost a solution, but it doesn't work with non-numeric data stream names.  What you really need to use is the script pointed to in this link.  This works great, and here is a summary of getting it to work on any web page or blog post.

First of all, you need these two lines of script before trying to show a plot:

<script src="http://www.google.com/jsapi" type="text/javascript">
</script>
<script src="http://thecodergroup.com/store/pachube/pachube_multi.js" type="text/javascript">
</script> 

Once you've done that, you can follow the examples in this forum post for the Javascript needed for the plots themselves (if you want to see the Javascript behind each of the examples below, just hit Control-U to see the source of this page).  These examples use data collected from a bash script from this page running on a DD-WRT powered router. 

Let's start off simple.  First, here is a plot of the uplink datarate.
Next, a plot of the downlink datarate.
Let's geta little fancier.  How about a plot of the uplink and downlink datarate on the same graph?
Or the sum of the two values plotted as a single value?
Pretty cool, I'd say.  There is one thing to be careful of here though.  The "div name" that is the first parameter to the script needs to be different for each of the plots you use.  This keeps the data behind each of them separate.  Weird things will happen if you don't.

There are other ways to present Pachube data.  I could just look at the data right off the Pachube web site.  Look here for the Pachube version of the plots I presented above.  Nothing fancy, but not bad.  There is yet another method of plotting data out there using the iGoogle Pachube Gadget and the associated method of publishing to a web page discussed here, but I found that to be a lot less flexible.

Despite taking a little longer to sort out than I anticipated, I'm pretty happy with the flexibility of this presentation. But wait, there's more!  There are more apps, such as ones that will send SMS alerts or Twitter messages when a particular condition is reached.  I haven't dug into these yet, but it is on my list of things to do once I've got my own data going in.