Saturday, March 17, 2012

Davis Weather Wizard - Hacking the Serial Port - V


Missed by Twenty-five thousandths? Well at least I gave the last 0.025% to other than I2C. Let's just say the Weather link is very...well.."I2C-like"

Device(Read)(Write)BP I2C read TIME @ 0xBE command:   TXT: 
10x03(0x01 R)0x02?(0x01)?[0x020xBE[0x03r:3[0x02 0xBE [0x03 r:3 
20x05(0x02 R)0x04(0x02 W)[0x040xBE[0x05r:3[0x04 0xBE [0x05 r:3 
30x07(0x03 R)0x06(0x03 W)[0x060xBE[0x07r:3[0x06 0xBE [0x07 r:3 
40x09(0x04 R)0x08(0x04 W)[0x080xBE[0x09r:3[0x08 0xBE [0x09 r:3 
50x0B(0x05 R)0x0A(0x05 W)[0x0A0xBE[0x0Br:3[0x0A 0xBE [0x0B r:3 
60x0D(0x06 R)0x0C(0x06 W)[0x0C0xBE[0x0Dr:3[0x0C 0xBE [0x0D r:3 
...
70x0F(0x07 R)0x0E(0x07 W)[0x0E0xBE[0x0Fr:3[0x0E 0xBE [0x0F r:3 
80x11(0x08 R)0x10(0x08 W)[0x100xBE[0x11r:3[0x10 0xBE [0x11 r:3 
1260xFD(0x7E R)0xFC(0x7E W)[0xFC0xBE[0xFDr:3[0xFC 0xBE [0xFD r:3 
1270xFF(0x7F R)0xFE(0x7F W)[0xFE0xBE[0xFFr:3[0xFE 0xBE [0xFF r:3 

There were a few things that bothered me about that address search. First, the fact there are 127 device addresses. This did not seem like a normal I2C device. Second, the first device does not even have a Write location. Other than those issues the outputs seemed normal so the plan was to drop the text generated commands (one by one) into the BP's serial port and examine the outputs for the one that had the same BCD values as the Wizard's display. ...Simple?

[0x02 0xBE [0x03 r:3
[0x04 0xBE [0x05 r:3
[0x06 0xBE [0x07 r:3
[0x08 0xBE [0x09 r:3
[0x0A 0xBE [0x0B r:3
[0x0C 0xBE [0x0D r:3
[0x0E 0xBE [0x0F r:3
...
[0xF4 0xBE [0xF5 r:3
[0xF6 0xBE [0xF7 r:3
[0xF8 0xBE [0xF9 r:3
[0xFA 0xBE [0xFB r:3
[0xFC 0xBE [0xFD r:3
[0xFE 0xBE [0xFF r:3

Well, there was one catch to this plan. I alluded to it on the last post. The bus gets hung up after every start command issued!

I2C>[0x03 0x04 [0x03 0xBE r:3]
I2C START BIT
WRITE: 0x03 ACK
WRITE: 0x04 ACK
Warning: *Short or no pull-up
I2C START BIT
WRITE: 0x03 ACK
WRITE: 0xBE ACK
READ: 0x00 ACK 0x00 ACK 0x00
NACK
I2C STOP BIT

So this was a typical output when I ran those commands trough. I could not yet find a reliable way to clear the error by toggling the power and pull ups either. The only way to clear the error for sure is to power cycle the Wizard.

Although while using the commands I did find a particularly interesting combination of toggling the lines would, in fact cause the console to beep!

I2C STOP BIT
I2C>[
Warning: *Short or no pull-up
I2C START BIT
I2C>P
Pull-up resistors ON
Warning: no voltage on Vpullup pin
I2C>W
Power supplies ON
I2C>pP
Pull-up resistors OFF
Pull-up resistors ON
Warning: no voltage on Vpullup pin


So, where does this leave us? Well besides the obvious, we did not gain control of the unit through I2C, I think I will cut my losses and let this project go! Yeah, I am admitting defeat! I think that since this is most likely a proprietary implementation of a 2-wire interface, that unless I set up a snoop with a logic analyzer between an actual Weather Link Data Logger and the Wizard to find the actual outputs and inputs with a known command sequence. I think that would be the only way, and that investment is not what I want to do at this time, hey my time is valuable and once more than a few idle hours get invested, it becomes, well, WORK! I get paid to engineer stuff for companies, and I think that when it gets to that point... I will just buy the damned software, throw out the disk, hook up the LOGGER and be done with it.

I will shelve this hack for now, unless I come up with another inspiring idea...it would be really cool to figure this out...But, if one of you, my dear readers, wants to part with their LOGGER! *hint*

~ ~ ~
SK

2 comments:

  1. First, don't give up. You are closer than you think.

    Second, I don't think you are driving the bus properly. Note all the errors from the BP in this post. From the Dangerous Prototypes site:

    "I2C is an open-collector bus, it requires pull-up resistors to hold the clock and data lines high and create the data ’1′. I2C parts don’t output high, they only pull low, without pull-up resistors there can never be a ’1′. This will cause common errors such as the I2C address scanner reporting a response at every address."

    Sound familiar?

    Once you sort that, I would take the approach of sending known commands and seeing if you get data back. I am sure you have seen this link that documents all the commands to the WWIII and gives various code samples.

    Finally, are you really 100% positive that this is I2C? It looks like a two wire protocol for sure, but that could just as well be serial. Note how the Bus Pirate is complaining about potential shorts.

    In an earlier post, you said "Also, it is not clear that the Vantage's TEST instruction is even included in the earlier models". I would say it is not. I unzipped the WWIII DLL and did a string search for TEST and got nothing. I do see the other commands. Take a look at this (hope this works):

    WWIII DLL Dump

    Keep at it.

    ReplyDelete
    Replies
    1. Yes, I see your picture of the DLL just fine and you are correct the 127 addresses are not valid for i2c.

      Even these addresses only last until the Wiz decides to pull the line low and BP complains of the short. The DLL is on the PC side I assume but I did trials of the LOOP command at every standard baud rate on both pins.

      It looks like the datalogger may be tranlating into another format. I have seen a couple of hex bytes which are generated by the WW, the pulses would be equivalent to the 115k Baud, but these bytes are not repeatable and may just be noise.

      If I come up with another idea I may try again, I almost think that the lines may be dual purpose; I2C-like (i.e. for some factory programming or configuration) and TTL serial pins...the I2C ACKs are definately there, I don't know how a simple serial pin would get this timing correct.

      But I so far I have not yet figured out another way to try to determine what the format is.

      Delete