Author Topic: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions  (Read 54169 times)

0 Members and 1 Guest are viewing this topic.

Offline rdsman

  • Senior Contributor
  • ****
  • Posts: 245
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #25 on: October 08, 2012, 07:34:12 PM »
I've sworn off "risky commands".  I think that I will just "sniff" the SPI bus directly and see what I get for the Vantage Vue Hop Sequence.  Here it is:

Index: 00, FREQ2: 23, FREQ1: 0D, FREQ0: 97
Index: 01, FREQ2: 22, FREQ1: B4, FREQ0: AB
Index: 02, FREQ2: 23, FREQ1: 12, FREQ0: 89
Index: 03, FREQ2: 23, FREQ1: 7F, FREQ0: 39
Index: 04, FREQ2: 23, FREQ1: 30, FREQ0: 2D
Index: 05, FREQ2: 22, FREQ1: DC, FREQ0: 31
Index: 06, FREQ2: 23, FREQ1: 9C, FREQ0: DD
Index: 07, FREQ2: 23, FREQ1: 52, FREQ0: C3
Index: 08, FREQ2: 22, FREQ1: F4, FREQ0: E5
Index: 09, FREQ2: 23, FREQ1: 66, FREQ0: 85
Index: 10, FREQ2: 23, FREQ1: 21, FREQ0: 5B
Index: 11, FREQ2: 22, FREQ1: C3, FREQ0: 7D
Index: 12, FREQ2: 23, FREQ1: 43, FREQ0: EF
Index: 13, FREQ2: 23, FREQ1: 8E, FREQ0: 0B
Index: 14, FREQ2: 23, FREQ1: 03, FREQ0: B7
Index: 15, FREQ2: 22, FREQ1: CD, FREQ0: 5F
Index: 16, FREQ2: 23, FREQ1: 3A, FREQ0: 0F
Index: 17, FREQ2: 23, FREQ1: 70, FREQ0: 67
Index: 18, FREQ2: 22, FREQ1: E6, FREQ0: 13
Index: 19, FREQ2: 23, FREQ1: A6, FREQ0: BF
Index: 20, FREQ2: 23, FREQ1: 1C, FREQ0: 6B
Index: 21, FREQ2: 22, FREQ1: BE, FREQ0: 8D
Index: 22, FREQ2: 23, FREQ1: 48, FREQ0: E1
Index: 23, FREQ2: 23, FREQ1: 84, FREQ0: 29
Index: 24, FREQ2: 22, FREQ1: F9, FREQ0: D5
Index: 25, FREQ2: 23, FREQ1: A1, FREQ0: CD
Index: 26, FREQ2: 22, FREQ1: D7, FREQ0: 41
Index: 27, FREQ2: 23, FREQ1: 2B, FREQ0: 3D
Index: 28, FREQ2: 23, FREQ1: 5C, FREQ0: A3
Index: 29, FREQ2: 23, FREQ1: 92, FREQ0: FB
Index: 30, FREQ2: 22, FREQ1: B9, FREQ0: 9B
Index: 31, FREQ2: 23, FREQ1: 08, FREQ0: A7
Index: 32, FREQ2: 23, FREQ1: 75, FREQ0: 57
Index: 33, FREQ2: 23, FREQ1: 35, FREQ0: 1D
Index: 34, FREQ2: 22, FREQ1: E1, FREQ0: 21
Index: 35, FREQ2: 23, FREQ1: 4D, FREQ0: D1
Index: 36, FREQ2: 23, FREQ1: AB, FREQ0: AF
Index: 37, FREQ2: 23, FREQ1: 6B, FREQ0: 75
Index: 38, FREQ2: 22, FREQ1: EF, FREQ0: F3
Index: 39, FREQ2: 23, FREQ1: 17, FREQ0: 79
Index: 40, FREQ2: 23, FREQ1: 57, FREQ0: B3
Index: 41, FREQ2: 22, FREQ1: C8, FREQ0: 6D
Index: 42, FREQ2: 23, FREQ1: 89, FREQ0: 19
Index: 43, FREQ2: 23, FREQ1: 3E, FREQ0: FF
Index: 44, FREQ2: 22, FREQ1: FE, FREQ0: C5
Index: 45, FREQ2: 23, FREQ1: 61, FREQ0: 95
Index: 46, FREQ2: 22, FREQ1: D2, FREQ0: 4F
Index: 47, FREQ2: 23, FREQ1: 7A, FREQ0: 47
Index: 48, FREQ2: 22, FREQ1: EB, FREQ0: 03
Index: 49, FREQ2: 23, FREQ1: 26, FREQ0: 4B
Index: 50, FREQ2: 23, FREQ1: 97, FREQ0: ED

This is the actual data being clocked into the radio chip.  Index "00" corresponds with the Vue console of display "0", it could be off by one.

Now, back to my real job.........

Ray

Offline DeKay

  • Forecaster
  • *****
  • Posts: 397
    • Mad Scientist Labs
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #26 on: October 09, 2012, 02:38:00 PM »
I've sworn off "risky commands".  I think that I will just "sniff" the SPI bus directly and see what I get for the Vantage Vue Hop Sequence.  Here it is:

Index: 00, FREQ2: 23, FREQ1: 0D, FREQ0: 97
Index: 01, FREQ2: 22, FREQ1: B4, FREQ0: AB
Index: 02, FREQ2: 23, FREQ1: 12, FREQ0: 89

<snip>

Been there, did that.

And if you read my earlier posts in this thread, you'll see the rest of the details on how the radio is configured to receive transmissions from the ISS.  Click this link for more than you'll likely ever want to know about this stuff.

Offline rdsman

  • Senior Contributor
  • ****
  • Posts: 245
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #27 on: October 09, 2012, 04:20:57 PM »
DeKay:

I've followed your progress!  Nice work, by the way.  My next goal is to get "Hopping".

Ray

Offline DeKay

  • Forecaster
  • *****
  • Posts: 397
    • Mad Scientist Labs
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #28 on: October 09, 2012, 11:32:38 PM »
DeKay:

I've followed your progress!  Nice work, by the way.  My next goal is to get "Hopping".


Sorry.  I don't quite catch your meaning.  You know what the hop sequence is.  Do you mean to build your own bit of hardware of some kind???

Offline rdsman

  • Senior Contributor
  • ****
  • Posts: 245
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #29 on: October 10, 2012, 04:58:33 PM »
Quote
Sorry.  I don't quite catch your meaning.

DeKay:

I don't have the CC1101 hopping yet, just monitoring a single channel.  The hopping sequence was captured by a microprocessor running in SPI Slave mode.  The data was captured from the expansion connector and filtered to provide only frequency data.   I have not analyzed a long sequence to see if it is random in nature or simply repeats every time.

My plan (goal) is to have a second CC1101 running in parallel with the Vue console.  I will initialize it, but feed it the frequency information from the Vue.  This way I can start and stop it, read registers or do anything else needed to perfect the hop sequence.  I can simultaneously print the STR information also.

Now all of this may seem necessary, but I have real reason for doing this.  If I program the CC1101 and park it on a channel, it only takes about 5 seconds for my screen to be completely full of data packets, depending on the channel.  I don't live in a metropolis, but talk about RF congestion!

This is what I meant by get "Hopping".  I will not be back home until October 21, so for now I can only dream about it.......

Ray

Offline C5250

  • Forecaster
  • *****
  • Posts: 840
    • Local weather
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #30 on: October 10, 2012, 10:01:09 PM »
It's not random. The sequence is hard coded in the firmware, but DeKay has documented it, so you don't even have to figure out where it is.
Precious little in your life is yours by right and won without a fight.

Offline DeKay

  • Forecaster
  • *****
  • Posts: 397
    • Mad Scientist Labs
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #31 on: October 10, 2012, 11:43:54 PM »
I didn't know that the Vue used the CC1101 vs. the CC1021 in the Pro2.  Developing a compatible receiver would have been much easier had I access to the CC1101.  For one thing,  I wouldn't have had to open my console and probe the pins of the radio chip with a sewing pin attached to the lead of my logic analyzer to sniff the actual data from the ISS.  Kids today have it easy, I walked to school uphill both ways, yadda yadda.

Offline rdsman

  • Senior Contributor
  • ****
  • Posts: 245
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #32 on: October 11, 2012, 07:13:06 AM »
C5250:

Thanks!

DeKay:

It's either using the CC1101 or a real close relative based upon the register values it writes.  (Barefooted in the snow!)

Ray

Offline DeKay

  • Forecaster
  • *****
  • Posts: 397
    • Mad Scientist Labs
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #33 on: October 14, 2012, 11:55:31 AM »
I don't have the CC1101 hopping yet, just monitoring a single channel.  The hopping sequence was captured by a microprocessor running in SPI Slave mode.  The data was captured from the expansion connector and filtered to provide only frequency data.   I have not analyzed a long sequence to see if it is random in nature or simply repeats every time.

What is the specific setup you are you using to capture this?  Would you share this code assuming it is on a platform commonly available?

My plan (goal) is to have a second CC1101 running in parallel with the Vue console.  I will initialize it, but feed it the frequency information from the Vue.  This way I can start and stop it, read registers or do anything else needed to perfect the hop sequence.  I can simultaneously print the STR information also.

It would be nice to see the sequence of register writes to the CC1101 as it prepares to read each packet.  It will be repetitive except for the specific frequency bytes.  I tried by best to translate the sequence for the CC1021 in my Pro2 to the CC1110 in my IM-ME, and it works OK, but it might not be optimal.  There is also a bunch of stuff written only when the console first boots up that would be good to know as well.

Another thing that would be very interesting is to set the console to re-transmit and analyze the command sequence.  This would give a clear picture on how to build a compatible transmitter.  Knowing this, it is quite likely that we could build our own temperature / humidity stations for peanuts.  I probably have most of the info I need to do this now, but it would go a lot quicker with data you might be able to supply.

Offline rdsman

  • Senior Contributor
  • ****
  • Posts: 245
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #34 on: October 16, 2012, 10:52:50 AM »
I'm using an Arduino running on 5.0 volts at 16 mHz with 3.3 to 5 volt logic level conversion to capture the data.  The program was compiled with Arduino 1.0.  (I have a data analyzer, but I've never been able to capture more than 50 seconds of data with it.)  

The data is taken from the expansion connector using SCK, MOSI and GND.  The program simply captures the data and prints it via the Serial Port.  It is shown below:


Code: [Select]
/*
  
  Arduino program to decode the Davis Vantage Vue
  Hop Sequence.  Index displays "99" until the
  program catches up with the console.
  
  by rdsman
    
  07 OCT 2012
  
  YOU MUST USE AN ARDUINO RUNNING ON 3.3 VOLTS
  OR PROVIDE LOGIC LEVEL CONVERSION!
  
  YOU HAVE BEEN WARNED!
*/
#include "Arduino.h"
//
//  Arduino Digital Pin Numbers.
//
#define SS   10  //  Forced LOW.      
#define MOSI 11
#define MISO 12  //  Not used in this program.
#define SCK  13
//
//  Global Variables.
//
volatile byte comp, freq, sync;
volatile byte freq2, freq1, freq0;
volatile byte index = 99;
//
//  Setup Loop.
//
void setup()
{
  delay(100);
  Serial.begin(115200);
  delay(100);
  Serial.println("Ready to begin processing....");
  Serial.println();
  delay(1000);
  initialize();
}  
//
//  Main Loop.
//
void loop() // run over and over
{
  if (comp)
    {
      comp = 0;
      Serial.print("Index: ");
      if (index < 10)
        Serial.print("0");
      Serial.print(index);
      Serial.print(", ");
      Serial.print("FREQ2: ");
      printHex(freq2);
      Serial.print(", ");
      Serial.print("FREQ1: ");
      printHex(freq1);
      Serial.print(", ");
      Serial.print("FREQ0: ");
      printHex(freq0);
      Serial.println();
      delay(2000);  // Yes, we want it to stop!
    }  
}
//
//  Hex print utility - Prints leading "0".
//
void printHex(byte value)
{
  Serial.print(value >> 4 & 0x0F, HEX);
  Serial.print(value >> 0 & 0x0F, HEX);
}
//
//  Setup the microprocessor.
//
void initialize()
{
  cli();                       //  Disable global interrupts while we make our changes.
    
  pinMode(SS, INPUT);          //  Set up the SPI pins.
  digitalWrite(SS, LOW);            //  SS is tied LOW.
  pinMode(MOSI, INPUT);
  pinMode(MISO, OUTPUT);
  pinMode(SCK, INPUT);
                               //  Turn off everything that might interfere!
  ADCSRA = 0x00;               //  Disable the analog comparator.
  TCCR1B = 0x00;               //  Disable Timer 1.
  TCCR2B = 0x00;               //  Disable Timer 2.
  
  SPCR = (1 << SPIE | 1 << SPE);  //  Initialize the SPI.
  
  sei();                       //  Enable global interrupts.
}
//
//  SPI Interrupt Service Routine.
//
ISR(SPI_STC_vect)
{
  byte temp = SPDR;
  
  if (!sync)
    {
      switch (temp)
        {
          case 0x0D:
            freq = 1;
            break;
          case 0x0E:
            freq = 2;
            break;
          case 0x0F:
            freq = 3;
            break;
          default:
            freq = 0;
            sync = 0;
            comp = 0;
            return;
        }
      
      sync |= 0x01;
      return;
    }    
  
  if (sync)
    {
      switch (freq)
        {
          case 1:
            freq2 = temp;
            break;
          case 2:
            freq1 = temp;
            break;
          case 3:
            freq0 = temp;
            comp |= 1;
            if (index < 51)
              index++;
            break;
          default:
            break;
        }
    }  
  
  sync = 0;
  if (freq2 == 0x23 && freq1 == 0x0D)  //  The index gets reset here, could be off by one!
    index = 0;                         //  Matches the Vue console - for what its worth.
}
//
//  The End.
//


« Last Edit: October 18, 2012, 09:38:44 AM by rdsman »
Ray

Offline DeKay

  • Forecaster
  • *****
  • Posts: 397
    • Mad Scientist Labs
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #35 on: October 16, 2012, 02:17:11 PM »
I'm using an Arduino running on 5.0 volts at 16 mHz with 3.3 to 5 volt logic level conversion to capture the data.  The program was compiled with Arduino 1.0.  (I have a data analyzer, but I've never been able to capture more than 50 seconds of data with it.) 

The data is taken from the expansion connector using SCK, MOSI and GND.  The program simply captures the data and prints it via the Serial Port.  It is shown below:

Excellent!  As my dad used to say, this is as handy as a back pocket on your underwear.  My Jeenode is 3.3V, so I'm good to go without needing to do any level conversion.

Offline rdsman

  • Senior Contributor
  • ****
  • Posts: 245
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #36 on: October 18, 2012, 09:55:19 AM »
Previously I posted that one of my goals was to synchronize an external CC1101 to the frequency data coming from the Vantage Vue.  I've modified the capture code to implement a "Poor Mans" STX/ETX protocol.  The incoming data is captured via the SPI port and sent out the UART at 115200 bps.  The protocol looks like this:

STX FREQ2 FREQ1 FREQ0

The spaces were added to make it easier to read.  We don't really need the ETX, so it's left off.  The question is will we be fast enough.  The screenshot below shows the incoming data from the Vue on the top trace.  The outgoing serial data is on the bottom trace.  The outgoing is completed before the Vue has finished writing to the internal radio registers.


Ray

Offline rdsman

  • Senior Contributor
  • ****
  • Posts: 245
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #37 on: October 18, 2012, 06:17:51 PM »
If you read my last post, you must read this one.  I have Bad news and Good news.  First the Bad, it was a Bad, Bad, Bad idea to think that using the serial port would work.  It looked good on paper and on the Logic Analyzer.  But in reality, by the time I was ready to receive data on the new frequency, the Vue had already received it and was moving on.

Now the Good news, I have it working!  I'm still getting the data via SPI, but sending it out via I2C.  Here is a snipet of the result:

E0  00  4B  01  00  0E  2D  45
50  00  4B  FF  70  0B  76  46
A0  00  4B  AE  2A  09  C0  28
E0  00  4B  01  00  07  BC  6C
50  00  4A  FF  70  03  81  FA
20  01  07  D4  C2  40  0B  C0
E0  01  2A  01  02  0A  8E  94
50  01  2A  FF  75  08  A5  70
70  01  2A  99  02  85  F1  CF
E0  01  2A  01  01  05  2A  28
50  01  2A  FF  71  05  21  8E
70  10  44  65  98  22  A3  2D
30  01  32  FF  C0  84  4C  67
E0  01  32  01  03  05  D2  2E
50  01  32  FF  70  07  AC  99

I am completely locked to the frequency pattern of the Vue console.  I get all of the 20, 30, 50, 70, 90, E0 and A0 messages.  What about the 80 series?  It doesn't appear to come from the ISS.  I've monitored it for hours without ever receiving a single 80 series message.  I have some other revelations to report, but I will save them for now.

The capture code is posted below.  The receiving end is so ugly, that my dog ran away.  I will clean it up and post it in the near future.  There is a lot of mystery left before we move on to frequency hopping on our own!



Code: [Select]
/*
 
  Arduino program to extract the Davis Vantage Vue
  frequency information and send it via I2C to the
  RF Bee or some other device.
 
  by rdsman
   
  18 OCT 2012
 
  YOU MUST USE AN ARDUINO RUNNING ON 3.3 VOLTS
  OR PROVIDE LOGIC LEVEL CONVERSION!
 
  YOU HAVE BEEN WARNED!
*/
#include "Arduino.h"
#include "Wire.h"
//
//  Arduino Digital Pin Numbers.
//
#define SS   10  //  Forced LOW.
#define MOSI 11
#define MISO 12  //  Not used in this program.
#define SCK  13
//
//  Global Variables.
//
volatile byte comp, freq, sync;
volatile byte freq2, freq1, freq0;
//
//  Setup Loop.
//
void setup()
{
  delay(100);
  initialize();
  delay(100);
  Wire.begin();

//
//  Main Loop.
//
void loop() // run over and over
{
  if (comp)
    {
      comp = 0;
      Wire.beginTransmission(0x22);  //  The I2C address was picked "Out Of The Air".  It means nothing....
      Wire.write(freq2);             //  It wasn't even converted to 7 bit format, so on the Logic Analyzer
      Wire.write(freq1);             //  it will show as 0x44!
      Wire.write(freq0);
      Wire.endTransmission();
    } 
}
//
//  Setup the microprocessor.
//
void initialize()
{
  cli();                       //  Disable global interrupts while we make our changes.
     
  pinMode(SS, INPUT);          //  Set up the SPI pins.
  digitalWrite(SS, LOW);       //  SS is tied LOW.
  pinMode(MOSI, INPUT);
  pinMode(MISO, OUTPUT);
  pinMode(SCK, INPUT);
                               //  Turn off everything that might interfere!
  ADCSRA = 0x00;               //  Disable the analog comparator.
  TCCR1B = 0x00;               //  Disable Timer 1.
  TCCR2B = 0x00;               //  Disable Timer 2.
 
  SPCR = (1 << SPIE | 1 << SPE);  //  Initialize the SPI.
 
  sei();                       //  Enable global interrupts.
}
//
//  SPI Interrupt Service Routine.
//
ISR(SPI_STC_vect)
{
  byte temp = SPDR;
 
  if (!sync)
    {
      switch (temp)
        {
          case 0x0D:
            freq = 1;
            break;
          case 0x0E:
            freq = 2;
            break;
          case 0x0F:
            freq = 3;
            break;
          default:
            freq = 0;
            sync = 0;
            comp = 0;
            return;
        }
     
      sync |= 0x01;
      return;
    }   
 
  if (sync)
    {
      switch (freq)
        {
          case 1:
            freq2 = temp;
            break;
          case 2:
            freq1 = temp;
            break;
          case 3:
            freq0 = temp;
            comp |= 1;
            break;
          default:
            break;
        }
     
     sync = 0;   
       
    }   
}
//
//  The End.
//


Ray

Offline DeKay

  • Forecaster
  • *****
  • Posts: 397
    • Mad Scientist Labs
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #38 on: October 18, 2012, 06:35:21 PM »
I am completely locked to the frequency pattern of the Vue console.  I get all of the 20, 30, 50, 70, 90, E0 and A0 messages.  What about the 80 series?  It doesn't appear to come from the ISS.  I've monitored it for hours without ever receiving a single 80 series message.  I have some other revelations to report, but I will save them for now.

Well, 80 is temperature, so either you are doing something wrong or the temperature has reached absolute zero at your house.

You might be synced in frequency but perhaps you are losing something in the data.  I've documented the STRMON output here, so check the values you are getting to see if they make any sense.  You should check the CRC as well.

Offline Bushman

  • Forecaster
  • *****
  • Posts: 7394
    • Eagle Bay Weather
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #39 on: October 18, 2012, 10:10:31 PM »
Absolute zero?  So THAT is where my ex-wife went.  ;)
Need low cost IP monitoring?  http://wirelesstag.net/wta.aspx?link=NisJxz6FhUa4V67/cwCRWA or PM me for 50% off Wirelesstags!!

Offline C5250

  • Forecaster
  • *****
  • Posts: 840
    • Local weather
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #40 on: October 18, 2012, 10:23:27 PM »
I've documented the STRMON output here, ...

Uhm... this:
Code: [Select]
The lowest three bits in the low order nibble is the transmitter ID.
  0 = ISS
  1 = Anemometer transmitter
  4 = Temperature / humidity station
  5 = Envoy retransmitting ISS
  7 = Temperature / humidity station
is not correct.

The first three LSB bits of the first STRMON byte are the absolute TX ID, that is as configured with the dip switch -1. In no way do they signify what type of station is transmitting. Keep in mind that the transmitter doesn't know what it is.  :-)

Further, certain sensor packets are also used for other purposes.
Precious little in your life is yours by right and won without a fight.

Offline rdsman

  • Senior Contributor
  • ****
  • Posts: 245
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #41 on: October 19, 2012, 09:51:50 AM »
I've barely scratched the surface on using the CC1101 correctly, so I am probably doing many things wrong!  However, these are my initial observations:

I have not received one single 80 message.
I get all other messages every time that STRMON prints them!
I don't get a 40 or 60 message - Neither does my STRMON output.
I get a 20, 30 and 70 message - Same as my STRMON output.
The 30, 50, 70, 90 and E0 messages are 8 bytes long that match exactly to the STRMON output - every time.
The 20 and A0 messages appear to be 8 bytes long, but the CRC bytes never match the STRMON output.  If I calculate the CRC using my first 6 received bytes, it matches the STRMON output.


 
Ray

Offline rdsman

  • Senior Contributor
  • ****
  • Posts: 245
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #42 on: October 19, 2012, 04:28:27 PM »
Gentlemen:

By using my finely honed engineering skills, I have discovered (stumbled upon) the problem with my code.  Here is a snipet of the results:

80  03  34  2F  39  0C  08  9C
30  03  2E  FF  C2  89  EB  BE
E0  03  35  01  02  09  35  3D
50  04  38  FF  72  01  E1  C1
80  04  40  2F  3B  05  10  87
90  04  3F  0D  92  34  F5  AA
E0  05  39  01  00  06  20  07
50  07  53  FF  72  01  48  DE
80  07  58  2F  38  0A  C4  8D
A0  05  5E  CA  08  0A  DC  CB
E0  04  5E  01  00  05  B2  CA
50  03  5E  FF  71  07  CD  CB
80  02  5E  2F  3A  0A  A6  21
20  02  53  D4  C2  88  46  8E
E0  03  43  01  02  0F  30  17

My latest version matches byte for byte with STRMON.  There is still plenty left to do!


Ray

Offline rdsman

  • Senior Contributor
  • ****
  • Posts: 245
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #43 on: October 27, 2012, 09:08:56 PM »
I haven't worked on this since my last post, so there is no progress to report.  However, for those of you who want to follow along or help, I've posted my current work on my website.  The link below will take you to a site where you can download Davis.zip.  

http://www.raydees.com/Downloads.html


« Last Edit: October 28, 2012, 07:40:16 PM by rdsman »
Ray

Offline rdsman

  • Senior Contributor
  • ****
  • Posts: 245
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #44 on: January 06, 2013, 12:44:04 PM »
I've updated my work on emulating the Davis protocol with the RFBee.  The library has been cleaned up and now implements a super simple hopping scheme.  It can currently maintain a PER of less than .2%   There are two example sketches included.  The first one simply prints out the received packets as:

Index: 04  Packet: E0  03  87  45  00  08  9E  AA  FF  FF  RSSI: -75  LQI: 30  Count: 15766  Miss: 4

The second one uses Dekay’s formulas and outputs something useful, such as:

SPD: 3  DIR: 155  TMP: 49  HUM: 73  RSSI: -77

Hopefully, this will be interest some of you!

Ray

Offline DeKay

  • Forecaster
  • *****
  • Posts: 397
    • Mad Scientist Labs
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #45 on: January 06, 2013, 07:46:07 PM »
I've updated my work on emulating the Davis protocol with the RFBee.  The library has been cleaned up and now implements a super simple hopping scheme.  It can currently maintain a PER of less than .2%   There are two example sketches included.  The first one simply prints out the received packets as:

Index: 04  Packet: E0  03  87  45  00  08  9E  AA  FF  FF  RSSI: -75  LQI: 30  Count: 15766  Miss: 4

The second one uses Dekay’s formulas and outputs something useful, such as:

SPD: 3  DIR: 155  TMP: 49  HUM: 73  RSSI: -77

Hopefully, this will be interest some of you!


Very interesting indeed!  I'm impressed by the low packet error rate!  I was thinking of doing something similar and you've beaten me to it.    \:D/

Next step would be to pick up a BMP085 for humidity and a DHT22 for temperature / pressure.  These are five or six bucks each with free shipping on EBay and there are already existing Arduino libraries to drive them.  From there the Davis LOOP and a few other commands could be cloned and whammo... a DIY console minus the display suitable for connecting to Cumulus and the like.

Again, great job   =D&gt;

Offline Bushman

  • Forecaster
  • *****
  • Posts: 7394
    • Eagle Bay Weather
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #46 on: January 06, 2013, 08:17:56 PM »
Forget the console - build low cost temp/hum sensors and the world is your oyster!
Need low cost IP monitoring?  http://wirelesstag.net/wta.aspx?link=NisJxz6FhUa4V67/cwCRWA or PM me for 50% off Wirelesstags!!

Offline belfryboy

  • Forecaster
  • *****
  • Posts: 489
  • waiting for the rain.....
    • Belfryboy Blog
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #47 on: January 07, 2013, 03:09:29 AM »
Forget the console - build low cost temp/hum sensors and the world is your oyster!
I already do, pin compatible with davis, and all for around £35

Offline Bushman

  • Forecaster
  • *****
  • Posts: 7394
    • Eagle Bay Weather
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #48 on: January 07, 2013, 10:02:54 AM »
Forget the console - build low cost temp/hum sensors and the world is your oyster!
I already do, pin compatible with davis, and all for around £35

More info PLEASE!!!  Pics, links etc.
Need low cost IP monitoring?  http://wirelesstag.net/wta.aspx?link=NisJxz6FhUa4V67/cwCRWA or PM me for 50% off Wirelesstags!!

Offline rdsman

  • Senior Contributor
  • ****
  • Posts: 245
Re: A Walk on the Wireless Side: Deciphering ISS to Console Transmissions
« Reply #49 on: January 07, 2013, 12:39:15 PM »

Next step would be to pick up a BMP085 for humidity and a DHT22 for temperature / pressure.  These are five or six bucks each with free shipping on EBay and there are already existing Arduino libraries to drive them.  From there the Davis LOOP and a few other commands could be cloned and whammo... a DIY console minus the display suitable for connecting to Cumulus and the like.


The RFBee doesn't have enough horsepower to do the full emulation.  One of the ideas that I have is to use the RFBee as just another sensor attached to the I2C bus.  It's contents could be read just like a real time clock, BMP085 or the DHT22.  Then use a MEGA based unit to tie everything together.  Any thoughts on this approach?

Ray

 

anything