Achievement Unlocked: IM-ME Weather Station Receiver!

Ever have days like this?

I try to make it a habit not to talk about my job on this blog, but let's just say that the last three weeks have been pretty challenging.  Something came up late this week that made it look like a bomb would go off and blow my weekend all to hell.  I was certain this was going to happen and had resigned myself to busting ass this Easter long weekend instead of taking it easy.

But the bomb didn't go off.

Now, not only do I get to enjoy a long weekend, but I've also tacked on an extra day to give myself four days off.  That is three days longer than last weekend and four days longer than the weekend before.  To make things even better, the weather outside has been crappy.  That gave me the excuse I needed to do whatever the hell I felt like this weekend.  Manna from heaven, baby.

Manna Can Be What You Want It To Be

All this is good because I had a few things on my list that I wanted to get through.  The first item on the agenda was to eat a whole hell of a lot of cheesecake.  I've been trying to lose a few pounds over the last couple of months, and I've kept the idea of eating a cheesecake in mind the whole time as a reward.  My Lovely Wife doubled the recipe, so my cheesecake is the right half.

Before - My Half Is On The Right

After - Mission Accomplished

Now I'm no Cheesecake Master, but I did what I set out to do and packed this bad boy away in an evening.  And I was some full.  The detailed stats on this gluttony:

Weight: 1139 grams (2.5 lbs)
Calories: 3394 grams (not counting various toppings)
Fat: 188 grams
Carbohydrates: 332.6 grams
Protein: 84.3 grams

What I'm quite amazed by is that I stepped on the scale the next morning and my weight was exactly what it was the day before, despite all this food and despite pounding back a ton of water.  Yay me.  My Lovely Wife got the half on the left and did a bang up job of it too.  Let's just say that there isn't any of this taking up space in the fridge one day later.

The second item I had on my list for the weekend was making progress on using my Pretty Pink Pager as an alternative Davis Weather Station Console.  This was Goal #4 from the list of items I hoped to accomplish this year.  You might recall from my last blog post that  I had made some progress in decoding the data stream coming in from the Davis outdoor wireless Integrated Sensor Suite, and before that I had been able to sense the power coming from the ISS.  But it was still a pretty big step to go from what I had to getting real data.  And faithful readers of my blog (ha ha ha) might have noticed that I haven't posted for almost a month.  "Perhaps he fell into a cheesecake induced diabetic coma and died?", you may have wondered.

Well, wonder no more.  You see, the wheels of progress here at Mad Scientist Labs might grind slowly, but they grind fine.  I have been chipping away at this stuff for a long time and  finally have something worth showing.  Take a look!

Click To Embiggen

This photo shows my IM-ME perched on top of my laptop.  The STRMON output from my console is chugging away in a terminal in the background.  Note how the eight data bytes on the IM-ME display match the eight data bytes on the screen directly above.

Now I think that is pretty cool.

I first proposed that this might be possible back in January of last year, saying "It's so crazy, it just might work".  And you know what?  It works very well indeed.  Let's take a closer look.

This Took Forever To Get Right

Now here is what you are looking at:

• Freq is pretty obvious.  Chan is the corresponding channel number from 0 - 50.
• Data is the eight data bytes received from the ISS.  And guess what?  They come in Least Significant Bit first, and I have to reverse the bit order in my software.
• CRC indicates if the check is OK or not.
• LQI is the Link Quality Indicator.  The radio is kind enough to automatically collect this information for you and stick it onto the end of the packet if you ask it nicely.  It is an estimate of how easily the radio demodulated the last 64 symbols immediately following the sync word.  I don't have a good feel yet if "50" shown here is good or not.  About all I know is this is a 7-bit number, so I'm kind of in the middle of the range here.  It might get better if I clean up the offset (below).
• RSSI is the Received Signal Strength Indicator.  Again, the radio sticks this onto the end of the packet for you.  The NOW value shows the current value and updates in a blur.  You can see that when the carrier came along, it was at a booming level well above that of the background noise.
• OFFSET is an indication of how far you are off from the true center frequency of the signal.  It is actually the value in the FREQEST register that I grab after receiving the packet and setting the radio to idle.  This value is two's complement with a resolution of (Fref / 2^14), and that translates to around -13 kHz for the offset I have now.  I need to tune this in a bit, and I suspect that will improve the LQI number above.

I hit some funny problems as I went along.  Here are a few of the things I tripped over, keeping in mind that I don't do embedded firmware development for a living.  Or at all, for that matter.

• I could not get interrupts to fire for the life of me.  I was triggering what should have been one from my code and... nothing.  Only accidentally did I trip over the CC1110's Global Interrupt Enable bit that is disabled by default.  I enabled that and interrupts starting working fine.
• Davis got the bit order of the two sync bytes backwards from the manufacturer recommended 0xd3 0x91.  I had to tell the CC1110 to sync on 0xcb 0x89.
• My RSSI reading was locking up at unpredictable times.  Turns out this is actually intended behavior.  I had my sync word detection set up to be very lax and the IM-ME was syncing on random noise.  As it says in the datasheet...

"In RX mode, the RSSI value can be read continuously from the RSSI status register until the demodulator detects a sync word (when sync word detection is enabled). At that point the RSSI readout value is frozen until the next time the chip enters the RX state."

I'm really happy to have gotten this far.  There was a lot of stuff I had to dig in to and reverse engineer to get to this point.  There is still lots to do, but I believe the remaining bits are relatively straightforward by comparison.  On my list:

• Get this thing frequency hopping.  I just dwell on Channel 0 right now, but I know the sequence of hopping frequencies, and I have oodles of time to get from one channel to the next.  I don't know yet how the radio calculates what frequency to go to next, but I do have the raw frequencies, and that will do in a pinch.
• Correct out the offset frequency.  TI is kind enough to publish a design note on how to do exactly this.
• Actually check the CRC.  It always says OK right now.
• Decode what all these data values mean and show them on a non-debug display.  I've gotten some help here and have also figured out a few things in a look at this a while back, so I think I can get a few of the basic things displayed quite easily.
• Gracefully adapt between the 27 MHz oscillator in my IM-ME and the 26 MHz oscillator many other people have.  Some of the register settings are tied to the oscillator frequency.
• Clean up the code.  It is a dog's breakfast right now.

I have just uploaded my code to github with a little "git push origin packetrx".  You can find the code here.  It compiles with sdcc via the magic incantation "make -f Makefile.pocketwx" on the packetrx branch.  If you happen to have an IM-ME and a GoodFET, you can then run "make -f Makefile.pocketwx install".  Like I said, the code is pretty ugly and disorganized right now, but you might find it useful if you are looking at doing a bit of fixed length packet reception stuff on an IM-ME or any other CC1110 based device.  There isn't much stuff out there on this right now that I could find.

Now I know what you are wondering.  The number of people with an IM-ME, the means to program it, and a Davis wireless weather station to listen in on are Quantity 1: me.  But let's think about this a little more.  Fine outfits like Archer Trading Post will sell you standalone ISS outdoor units that we now know we can build a compatible receiver around.  But you can't walk into a store to buy an IM-ME anymore and it isn't expandable.  That is where Ciseco comes in.  They will sell you a CC1110 based XRF module in an XBee form factor for the low low price of £9.90 and dirt cheap shipping. And yes, I already have one.  In fact, I might be the only person to ever order just one, as they are meant to be used in pairs.

XRF Module: TI's Development Kit is 41.3x More Expensive at $649

This all opens the door to building a pretty capable DIY, open source weather station console based on high quality commercial components to gather up the data.  Davis sells really good outdoor hardware for this, but their indoor stuff is limited, low powered, expensive, and doesn't feature the kind of connectivity to hook into something like Pachube very easily.  A little module like this brings a lot of capability to the table.  This is my long term goal and won't happen anytime soon, especially with summer coming up and having to shift my time to various landscaping projects.  But I do have a lot of fun playing around with it, and maybe things will move along faster if some other hardcore Davis weather fanatics decide to jump on board.

Before heading out, I would be remiss if I didn't thank a couple folks for helping me get this far.  It was Travis Goodspeed who first mentioned that the CC1110 in the IM-ME should be compatible with the CC1021 in the console.  Travis also designed the GoodFET, a board he literally gives away to further people digging in to stuff like this.  It is a must have for IM-ME hacking.  Then there is Joby Taffey, who wrote the PinkOS operation system for the IM-ME.  I wouldn't have stood a chance without this code to get me rolling.  And of course there is Michael Ossman who wrote the IM-ME based spectrum analyzer based on Dave's pioneering work.  I'd have been screwed without all the previous work from these guys because, as this picture shows, I'm not much of a programmer.

RIP Dennis M. Ritchie

First You Get The Sugar...

The pursuit of an alternative Davis Weather Station console is, and always has been, a three step process.  Homer Simpson breaks it down from that famed episode where he comes upon a big pile of sugar that he believes will make him a fortune.

Watch This, Or Nothing From Here On Will Make Sense

The intricacies of wireless RF transmission put a slightly different spin on any Scarface reference you might want to make, so let's look at it this way.

First you get the signal: I unlocked this achievement a little while ago when I used my Pretty Pink Pager to successfully receive a signal from the Davis Outdoor Integrated Sensor Suite (ISS) out in my yard.  A good start, but there was still a long way to go.

Then you get the data: This turned out to be rather tricky, and is the subject of today's post.

Quite some time ago, I looked at how the radio chip in the Davis console is configured for each frequency hop it makes.  That was all well and good, but as I dug deeper in actually trying to grab the data over the air, I realized that there were a few more things I'd need to figure out.

The CC1021 datasheet (for the RF chip in the Davis console) treats this subject pretty lightly, but once you delve into the CC1110 datasheet (the compatible RF chip in the Pretty Pink Pager), you hit David Rumsfeld's known unknowns.  That datasheet makes it clear that there is a lot more going on than just the data coming in over the air.  I figured out how to see the data a long time ago by using STRMON and a terminal program, but there is more to it than that. There are actually three parts to the transmission from the ISS that need to be sorted out.

• Preamble.  From the CC1021 datasheet: "The recommended preamble is a ‘010101...’ bit pattern... This is necessary for the bit synchronizer to synchronize to the coding correctly."  This doesn't show up in the STRMON output.  How long is this bit pattern?  Where is it in relation to the data?
• Sync Words. Again from the CC1021 datasheet: "The recommended sync words for CC1021 are 2 bytes (D391), 3 bytes (D391DA) or 4 bytes (D391DA26) and are selected as the best compromise of the above criteria."  Does the Davis system really use these recommended sync words?  If so, how many bytes do they use?  Where are they in relation to the data?
• Data: I know what this is at any given time.  STRMON tells us that this is seven bytes of information plus an eighth byte for a checksum.  As we'll see in a bit, knowing what the data in the transmission is was critical in figuring out the other stuff.

All this unknown stuff is important if we want to build a compatible receiver.  Unlike the CC1021, the CC1110 lets you define a packet format to help you do the heavy lifting in decoding the incoming data stream.  We need to answer the questions above so the registers in the CC1110 can be programmed properly.  Unfortunately, the 1's and 0's don't appear on the SPI bus used by console's ATMEGA processor to configure the CC1021's registers.  That would be too easy.  The 1's and 0's show up on a separate pin called DIO (Data Input / Output), and are synchronized to a DCLK (Data Clock) pin.  If I was going to figure out the bitstream from the RF chip to the ATMEGA, I'd have to sniff this data.

My first attempt to do this did not go well.  I soldered a few wires directly to the console's processor in an attempt to break these lines out.  Something broke all right, and that was my console.  I had hoped it was just a blown LCD and ordered one of those up from Ryan at Archer Trading Post.  That didn't work, so I actually had to order up a whole new console.  Those are the breaks.  The new console arrived on Wednesday.  By Saturday, it looked like this.

Much To The Chagrin of My Lovely Wife,
This Is Our Kitchen Table

Note ancient ATI mousepad on the middle-right and the old school Micronta / Radio Shack analog multimeter top left.  I wish that meter would break so I could justify getting something that isn't older than some of the people reading this.  But it still works perfectly, and the manual I still have for it is in perfect condition.  I even still have the receipt: this baby set me back $29.95 back on August 20th, 1981.  But I digress.

I was a little more careful on my second attempt.  If you are going to try this (don't try this), here is the pinout you need to know.

CC1021 DCLK Pin 7 connects to ATMEGA (SCL/INT0) PD0 Pin 25
CC1021 LOCK Pin 9 connects to ATMEGA (SDA/INT1) PD1 Pin 26
CC1021 DIO Pin 8 connects to ATMEGA (ICP1) PD4 Pin 29

It was time to break out my $50 logic analyzer and try, try again.  I figured I didn't need to worry about LOCK.  But I did worry about something else: shorting some spins and frying another console.  The spacing between pins on the processor's TQFP package is a mere 0.8 mm, and I now know that new consoles don't come cheap.

With one hand I held a probe to the DCLK line, with my other hand I held a probe to the DIO line, and with my third hand I triggered the analyzer.  That third hand was actually that of My Lovely Wife, without whom I would have been well and truly screwed once again.  It worked, and this was what I got.

Sniffing CC1021 DIO / DCLK Data, Very Carefully.  Click To Embiggen.

Let's take a little closer look at that first bit around the trigger point.  Things are looking pretty good so far.

I Got A Clock.  I Got Some Data.

I was running STRMON and capturing its data at the same time.  The last stuff that scrolled across the screen when the capture taken above was done looked like this.  But...

What In Here Am I Looking For?

I had a bunch of questions to sort out before I could decode all of this.  First, I wasn't exactly sure what chunk of the capture log corresponded to the data I had collected.  Second, I didn't know how to sync up in the bitstream above to know where to start calculating the corresponding bytes.  Third, I wasn't sure of the bit order of the datastream, whether there were any parity or stop bits, etc.  This was going to be harder than I thought.  I had to turn my brain into a fuzzy pattern matching machine.

Since I had the STRMON data, I would start looking for the eight data bytes and then look for the Sync and Preamble bytes after that.  What helped was finding a spot in the bitstream where there were eight or nine 1's followed a short while later by eight or nine 0's.  There was some data in the capture log that had an 0xff byte, followed by something else, followed by a 0x00 byte.  It took a while and I went down several blind alleys, but I finally sorted it out.

This...

corresponds to this...

Here are the key points to know:

• The eight data bytes (six plus two byte CRC) appear in the bitstream as numbered in the STRMON output
• Each byte is Least Significant Bit (LSB) first.
• The data is taken on the rising edge of DCLK

So decoding the datastream above, we have to think it through like this.

LSB Order   Byte    MSB Order   Time After Trigger
00000110    0x60    01100000    8.125 ms
11000000    0x03    00000011    8.540 ms
01010101    0xaa    10101010    8.960 ms
11111111    0xff    11111111    9.375 ms
10000011    0xc1    11000001    9.795 ms
00000000    0x00    00000000    10.210 ms
10011011    0xd9    11011001    10.625 ms
10001000    0x11    00010001    11.045 ms

Here is a closeup of the first data byte to help you see what I'm talking about.

First Byte of Data

Looking from marker T2 and going by the rising edge of the clock, you get:

0 0 0 0 0 1 1 0

That is LSB order. So we reverse the bit order to get the more conventional MSB order.

0 1 1 0 0 0 0 0

That is 0x60, our first byte in the table above.  Going from there to the right, each byte works out exactly.  There is no Start Bit, Parity, or Stop Bit.  Booya.

Next thing we need to sort out is the Sync bytes.  Remember from above that what we are looking for is probably something that looks like D391DA26 or less.  It turns out the Sync bytes look like this.

Sync Bytes

What this capture tells us is this:

• The Davis system uses only two Sync bytes
• The Sync bytes are 0xD3 followed by 0x91
• The two Sync bytes immediately precede the data bytes.  There is no gap between them.

Looks like we are on a roll.  We should dive into the Preamble bytes while our luck holds.  Remember that "The recommended preamble is a ‘010101...’ bit pattern".  But how many bytes?  This many.

Preamble Bytes

What this capture tells us is this:

• The Davis system uses four Preamble Bytes
• The Preamble is more correctly a '101010...' pattern if we don't do a LSB to MSB conversion (and we shouldn't in this case)
• The four Preamble bytes immediately precede the Sync bytes.  There is no gap between them.

The reason I mentioned above that we shouldn't convert from LSB to MSB in the Preamble is because this isn't really data.  But more importantly, take a look at this from the CC1110 datasheet.

CC1110 Packet Format

You'll want to click on that bad boy to enlarge it, but you'll note that the CC1110 expects a Preamble to have a pattern that starts with '1010...', not '0101...'.  The pattern also has some integer number of bytes and is expected to butt right up against the Sync word.  In other words, it looks like the Davis system is compatible with the CC1110 packet format.  This is great news.  The CC1021 had no such mechanism to enforce policy like this.  It was up to the Davis firmware programmers to manage each and every bit that spewed forth from the CC1021.  Life should be a lot easier getting the CC1110 to do it in our alternative receiver.

The sharp eyed amongst you will notice that there is some stuff going on on either side of the Preamble, Sync, and Data bitstream in those first couple screen captures.  I haven't dug into this yet, but my suspicion is that this is there for a couple reasons:

• allow the CC1021 to detect and lock on to the carrier when it first starts being transmitted from the ISS
• allow the console to determine the frequency error on the signal transmitted from the ISS so it can precisely tune to the signal and minimize bit errors

I still have to dig into this part of it, but I've got a plane to catch this afternoon and I haven't started packing yet.  The next step in using this information to pull data into the Pretty Pink Pager will have to wait for another day.  In the meantime, let's reflect on the wisdom of Homer Simpson on the third step of this process.

Then you get the women: That is pretty much automatic when you do cool stuff like this all weekend.  Have a good one.

Making

I mentioned last time round that I blew out my Davis Weather Station VP2 wireless console.  A new one should be here by next weekend, and I really am being held up on my alternative weather station console in the meantime.  What I need to understand is the preamble sent by the ISS before real data is sent.  I have a rough idea what this is, but there are enough permutations and combinations that just guessing my way through it would not be fun.

There is, however, other stuff to do.  But before I get in to that, here is an aside for ya.  A lot is being said these days about "Making".  Make Magazine is the poster child for the movement, and the Arduino is that child's favorite toy.  Sites like Instructables (make your own Light Saber!) and Hack A Day show you how to do stuff.  Places like Adafruit and Sparkfun are places where you can get stuff.  I remember the days of Radio Electronics and Byte magazine.  They had articles showing you how you could make a television descrambler or a taser.  But every project had at least one part that was impossilbe to buy (usually an inductor).  There was no Internet and I had no credit card, so I would mail a hand-written letter with a post office money order inside and hope for the best.  Now it is different.  Anybody can get almost anything, and almost all of it is ridiculously cheap.  An Arduino kit costs $20.  My first computer, an Apple //e, was something like $3000, and the Arduino is arguably much more powerful.  I really believe we live in a great time for stuff like this.

Case in point: item #3 on my list of goals for this year is getting  some basic home monitoring setup going.  I mentioned the plan to use some JeeNodes from JeeLabs to make this happen.  I had ordered these from Modern Device some time ago.  It was time to crack the box open and start playing with software.  There was only one problem.

Some Assembly Required

Time to break out my handy dandy Hakko FX-888 that I picked up from Solarbotics late last year.  This thing is great.  It was pretty quick work to go from that to this.

Wireless Goodness

But Making isn't always about electronics stuff.  Not to me anyway.  I want to make great food.    Try #31 of Tartine Bread, for example.  This bread has nothing in it besides flour, water, and salt, and it is fantastic.

I Love Carbohydrates

I am still searching for the perfect combination of a crispy crust and open crumb.  I now seem to be getting the crust right, but the big open holes I used to be able to get in the crumb have deserted me.  I'm baking this bread once a week now and I try a few different things each time in my search for perfection.  Once I get it, I plan to put up a page on this blog that will basically serve as "Tartine Bread: The Missing Manual."  While Chad Robertson has written a fine book, it is sufficiently vague in enough spots to leave a bread-baking noob like me up shit creek.  I hope to fix that.

Try #31 got served along with a Sirloin Butt Beef Roast cooked in my Sous Vide rig for 15.5 hours at 58C.  This was honestly so good that it was unfair to anybody else who ate something today.

I Love Protein

We seasoned it very simply with kosher salt, pepper, and rosemary.  We seared it in a smoking hot cast iron pan for a minute per side to finish it off.  It was so tender it was almost falling apart, yet the texture was absolutely fantastic. You could be served this meat in any fine restaurant, after which you'd go looking for the chef to give him a big sloppy wet kiss in appreciation.

That was lunch.  And then it was time for supper.  Keeping a sourdough starter going as we do gives you a bunch of discard that you've got to use up.  So we gave these sourdough waffles from the gang at King Arthur's Flour a shot.  They were good.  Really good.  Stupid good.

I Love Waffles

A couple flavor combination I can heartily recommend:

• Plain yogurt, Saskatoon berries, and chocolate sauce
• Cottage cheese, bananas, and chocolate sauce
• Pretty much anything and chocolate sauce

Not a lot of headway in the hacking department this weekend, but things got made nonetheless.  And I had a great weekend doing it.

Make Your DIY Davis Datalogger Work With Weatherlink

Progress comes in fits and starts.  That is why the iPad preceded the iPad 2,  why there had to be light before there was a light bulb, and why there had to be a Martin Sheen before we were fortunate enough to get a Charlie Sheen.

I Need To Come Up With Better Examples

So it is with reverse engineering.  First I figured out how to get a computer connection to a Davis weather station console without buying their overpriced Weatherlink software / hardware combo.  That was all well and good, but my DIY interface didn't have datalogging capability until a tip on a wxforum post gave me the clue I needed to implement that too.  This was my iPad 2.

What's that you say?  The release of the iPad 3 is imminent?  Drat.  Indeed it is.  I need a problem to stretch this dubious metaphor even further.  And that problem is the fact that Davis software products like Weatherlink and the firmware updater don't work with the DIY interface and logger.  The software would scan through all the ports on my laptop and pause at the COM port assigned to the USB to Serial Adapter, but wouldn't initiate communications to it.

I thought that Davis was likely doing some kind of factory initialization on the flash chip that I was not privy to, and I wasn't going to bother disassembling the firmware image to figure out what I needed to do.  Cumulus works great and is free for personal use, and the Weatherlink software has been beaten to death with the ugly stick.  It burns my eyes.

Windows 95 Called - They Want Their GUI Back

Still, this problem bugged me.  Until now.  Enter belfryboy.  He is the Mr. Watson to my Alexander Graham Bell, the Dr. Watson to my Sherlock Holmes, and the supercomputer Watson to my Ken Jennings.  belfryboy is the guy who designed the schematic and PCB layout for a DIY logger.  He's made the Eagle design files publicly available and he'll even build one for you if you want.  He also lives in the UK, where they add a superfluous "u" to many words for no particular reason (the phrase "for no particular reason" is also superfluous in that sentence when you think about it, but I'm not about to start letting "thinking" get in the way).

It turns out this problem was bugging him too.  He took a different approach.  What if it had nothing to do with some factory initialization?  What if it was a handshaking issue?  So he started playing around and actually got it to work!!!  Here is what you need to do, and this applies to both a straight serial or a USB to Serial interface to the console.

• Connect CTS to RTS
• Connect DSR to DTR to DCD
• Make sure to use the 1Mb dataflash chip.  The console will not recognise the datalogger with larger capacity flash chips, even though it will log to it

To illustrate this, I opened up the Sparkfun USB to Serial converter schematic in Eagle.  The dashed lines show the changes that need to be made.

A Pretty Standard RS-232 Hardware Handshaking Dance

This is a pretty easy job to do on the back of an RS-232 DB-9 or DB-25, but you'll need a steady hand and some good soldering skills to do it on the FTDI chip on these USB to Serial converters.  The connections are mostly not adjacent to each other, so it will take more than just a simple solder bridge between pins.  Time to break out the 30 AWG wire.

But maybe you aren't up for this?  belfryboy has got you covered once again, as he has a new version of the DIY datalogger in the works and will build you one if you'd like.  He'll also be making the design files available once again for anybody to build their own.  I'll put up a link to them on this blog once they are available.

I have to take my hat off to belfryboy because this solution wouldn't have occurred to me.  Ever.  The console does not have any lines for hardware handshaking, just TxData and RxData.  Why didn't Davis just ignore hardware handshaking in their software instead of hardwiring it on to the logger board?  It makes no sense, but that is the way it is.

By the way, please spare me any wailing about how this encourages piracy of the Davis software.  There are many legitimate reasons for enabling this functionality in a DIY interface.  Here are a few.  There are others.

• Your Davis branded logger got zapped and no longer works (happened to belfryboy himself)
• You've got a Davis branded USB logger that is dropping out all of the time
• You've got multiple consoles and want a DIY version for the second one
• You've got the Davis branded logger but want to build a DIY wireless version of the interface
• You want to use the Davis updater software to update the firmware in your console

I haven't tried implementing this hardware handshaking fix myself yet.  Unfortunately, it seems that I have somehow fried my console after digging in to its innards one too many times.  I had thought it was just the LCD that was blown, but I got a replacement and that isn't working either.  These are the hazards when you mess around like I have been.  C'est la vie. This is going to put a temporary hold on any progress on my alternative wireless console, but rest assured that I will pick it up again once the new console arrives.

So there you have it.  A DIY datalogger that has 100% of the capabilities of the Davis version, and more than two weeks before the antipated announcement of the iPad 3.  That's how we roll here at Mad Scientist Labs.

This Is Me - Part 2

In the first part of this two part post, I talked about the motivation that got me to pull up my socks and change some things about myself that I wasn't happy with.  But prior to that, I wrote about some of the things I wanted to get gone this year, mentioning that a list like this helps to motivate me.  That post contained a set of specific goals I set for myself.  One of the things I wrote was this:

My best lift is the deadlift.  Pick a weight up off the ground and put it back down.  Simple enough.  I can usually do something like 350lbs to 365lbs for five or six reps depending on the day with a bodyweight in the low 140lb range.  Not bad.  This should translate into a 415lb+ one-rep max... So...

Goal #1: Deadlift 405lbs for a single rep.  That's four wheels a side.  This goal should be doable.  I just have to do it.

Italics added.  Keep those in mind.

I also wrote in Part 1 about some of the reading I've been doing in regards to working out.  One of the sites I didn't mention there that I hit up pretty regularly is Jamie Lewis' most excellent Chaos and Pain.  This site is NSFWOAE: Not Suitable For Work, or Anywhere Else.  Don't click that link.  You have been warned.

This Is Not Me

Jamie has a way of writing that doesn't just give you a wakeup call: his writing delivers violent and repeated blows to the head using your own arm as a club.  It leaves you lying in a pool of your own blood and other bodily fluids.

In this recent post (once again, don't click that link), he wrote:

One of the most virulent and offensive exhibitions of this "I suck and can't help it" mentality is the practice of setting a New Year's resolution.  In setting a NYR, you're doing a couple of things, all of which are about as cool as those grown men who brag about watching My Little Pony and write fan fiction for the show.  First, you're announcing to the world that you've identified a fault within yourself and refused to resolve it.  Second, you've decided to procrastinate on even pretending to resolve the issue until an arbitrary date.  Third, you're making a hell of a lot of noise about nothing, since only about 12% of people who make New Years Resolutions enjoy anything resembling success.(Quirkology)  It's a fucking embarrassment of fat, drunken David Hasselhoff with a hamburger proportions.  If you think you suck, fucking stop sucking immediately.  Women, I'm pointing at you and your motherfucking diets- there's no goddamned time like the present.  Stop putting shit off until tomorrow like you're a modern day J. Wellington Wimpy, who is perhaps the cartoon character most deserving of a curb stomp in history.

Can you hear the wake-up call?  One of my goals for the New Year was to do something I already believed I was capable of doing.  So why hadn't I done it?  Because I suck.  Because walking up to a bar loaded with almost three times your body weight and lifting it off the ground is hard.  It was time to grow a pair.

I did this two day's after reading Jamie's blog.

This Is Me

Not only did I hit a goal I had set for myself just days before, but it looks like I could have gone heavier and still have made it.  It isn't everyday that I can say I learned something from a barechested crazy man in an Viking hat, but I can today.  So can you.

Now go click on a few of those links.

This Is Me - Part 1

I have always been a skinny guy.  I have the genes of Phasmatodea, wrists like twigs, and legs like toothpicks.  This made Junior High and High School not a lot of fun at times.  It is apparently a lot of laughs to pick on the little guy.  And if he just happens to be a nerdy little guy, well... so much the better.

This Is Not Me

As the years went by and I grew older, so did everyone else.  Maturity does pretty much everyone some good, and I wasn't picked on anymore.  I went about my business as so many other skinny guys do: I jogged, put rocks in my pockets when the wind came up, and avoided all you can eat buffets.

Enter university, and my hair started thinning out.  The new round of jokes made at my expense were sometimes funny, sometimes not.  It didn't help that there wasn't much I could do about it.  It was also depressing in that thinning hair and a skinny frame did not make for the most attractive combination.  I came to believe that I would die a lonely death.

But as a friend of mine would say, "I'd rather be lucky than good".  I met someone wonderful who would later become My Lovely Wife.  She said that my thinning hair and skinny frame did not bother her.  Maybe.  Hopefully.  But it bothered me.  Each of these things had been a noose around my neck for too long, and I decided I would cut each of them away.

I would embrace the thinning hair.  I would shave my head and go from male pattern baldness to Lex Luthor cool in one go.  Easy.

This Is Not Me

But not so fast.  There was one problem: the combination of a bald head with my skinny frame would have me regularly mistaken as a cancer patient.  And that isn't cool at all.  I would have to put on some weight, but all of my years of being too thin made me fat-phobic.  If I was going to put on some weight, it would have to be good weight.  I started working out.  Not easy.

And I made mistakes, many of them.  My biggest mistake was believing what all of the workout gurus on the Internet were saying: you need to do endless amounts of crunches to get good abs, you need to hit the muscles from all angles to get them to grow, you better eat every few hours or your muscles will fall off, and you need to buy tons of supplements to get anywhere.  I would learn later that all of this is wrong.  All of it.  But I'll get back to this in a bit.

When I started working out, I bought a simple weight bench and a set of "standard" weights that you see collecting dust in so many basements.  I did endless amounts of curls with these things, along with other assorted bits of randomness.  And then one day I started to notice that my arms were getting a little bigger.  Not a lot, mind you, but enough to give me the positive reinforcement I needed to keep going.    When you've been skinny all your life, this is a big deal.

I began doing some research as I kept exercising, and my understanding of what is effective and what isn't as it came to exercise and nutrition gradually improved.  I learned that to get strong, you need to lift heavy things.  It sounds crazy, but it is true.  I decided that I would get myself an Olympic style bar and set of weights totaling 300lbs.  300 lbs!  I'd never need to buy more weight again!  But one solution leads to another problem, and the idea of pinning myself under a heavy barbell, only to be found dead two weeks later was not a good one.  So I bought myself a power rack.  I could then lift heavy weights safely in my own basement.  I was still making mistakes, but I was on the right track and continuing to gain strength.

At least I did one thing right.  I ate a ton of food.  Even though the workouts I was doing were far from optimal, my undersized and undernourished body soaked up calories like a sponge.  I was gaining a pound a week, and most of that was good weight (i.e. muscle).  I hit the scale every Monday and watched with glee as my "newbie gains" took hold and the dial on the scale inched upward.

My research led to to a couple of sites that I became very grateful for.  They actually had some science behind what they had to say.  This was a refreshing change from the "bro-speak" that is pervasive on the web.  If you've ever heard someone say something along the lines of "Everybody knows that you need to do X to get Y", you've got yourself a perfect example of bro-speak.  "Everybody knows that you need to eat breakfast to kick-start your metabolism in the morning".  "Everybody knows that you need to eat brown rice and chicken breasts if you want to get lean."  Etc.  Bro-speak is a good example of correlation vs. causation, and it is important to know the difference.  Sure, there are a lot of bodybuilders that eat endless amounts of brown rice and chicken breasts and get very lean doing so.  But just because they did so doesn't necessarily mean that that was the cause of their getting lean, and that they couldn't have gotten lean by eating some other way.  Consider this: ice cream sales go up in summertime.  Drownings go up in summertime.  This must mean that ice cream causes drowning, right?  Of course not.  Ice cream sales correlate to drownings (they follow the same kind of trend), but one doesn't cause the other.

Back to those sites.  The first site was Lyle McDonald's Bodyrecomposition.com.  I'd recommend that everyone read his site from top to bottom to really understand how the nutritional processes work in your body.  The sooner you understand how you get fat, that a calorie is a calorie, and that your weight depends simply on calories in vs. calories out, the better off you'll be.

The second of those sites was Leangains.com.

This Is Not Me

This is Martin Berkhan, the man behind Leangains.  A man who doesn't use steroids.  A man who walks around all day everyday at around 6% bodyfat.  And a man who once figured out he ate on average of an ounce of cheesecake every day for a year.  Martin developed a version of Intermittent Fasting (IF) where you restrict your calorie intake to within an eight hour window and fast the other sixteen.  He uses some pretty solid research to put a knife through the heart of many myths related to exercise and nutrition.  This is another site you need to read from top to bottom. You'll learn that your metabolism doesn't slow down if you don't eat every few hours, how partitioning calories around a workout can benefit getting stronger, and that "clean eating" is not a requirement to getting big and lean.  And he's got the clients to prove it.

A lot of what he wrote made good sense to me and I was thinking I'd give it a a shot.  The one thing that held me back was that I thought (like so many other people) that I would starve to death if I didn't have breakfast.  But then again, how do you know if you don't try?

Read that last bit again.

How do you know if you don't try?

How many times have we shot ourselves down when we might have been easily capable of doing something?  And I'm not talking about jumping off a bridge here. I was talking about skipping breakfast.  If I didn't like the experiment, no harm done.

I remember the first day I gave this a shot.  I stopped eating at 10:00 pm on a Friday night and didn't eat until 2pm the next day.  My expectations were that I'd feel crappy, tired, and hungry until I ate that day.  I was amazed that it actually went the other way.  The coffee I was drinking (caffeine helps to curb appetite) was like rocket fuel on my empty stomach.  I was full of energy.  And I also experienced another benefit to the fast that I had read aboout but thought was bullshit: my concentration levels were way up.

That night, I put a major hurt on an all you can eat buffet.  And this highlights another benefit of Intermittent Fasting: when you eat, you eat big.  The same amount of food eaten in a narrower window seems like more and leaves you satisfied.  If you've ever done the "eat every three hour thing" and always felt hungry, then give IF a try.

I've been eating this way now for the last two or three years and don't think I'll ever go back.  Eating big rocks.  I will often eat 1500 calories within around 90 minutes after my evening workout and then go to sleep for the night (for point of reference, a Burger King Whopper has 670 calories).  I don't get fat thanks to calories in vs. calories out.  Simple.

The Caloric Equivalent of Two of These Before Bedtime
Plus An Order of Value Onion Rings

But the bigger benefit to me has been how my ability to concentrate has increased.  This is something I noticed was degrading as I grew older.  I think my focus is now at least as good as it ever was.

Am I a big and lean like Martin?  Nope.  Not even close.  I could very likely eat more and train smarter, and my age and crappy genetics in this regard don't help.  But I am decently strong for my size and have around 20-25 lbs more muscle on me than when I started.  Years ago I was picked on.  Now friends and family will say to me out of the blue that I look really good.  That feels great, because I've worked damn hard to put those pounds on.  That positive reinforcement gives me the extra push I need when I'd otherwise feel too tired or lazy to go downstairs and hit the iron for the night.

Anyhoo, if you made it this far, you might be wondering if I have any point to make in all of this rambling.  I do, but that will have to wait to Part II.

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.