Author Topic: DIY "GREEN DOT" Data Logger  (Read 70205 times)

0 Members and 1 Guest are viewing this topic.

Offline rdsman

  • Senior Contributor
  • ****
  • Posts: 217
Re: DIY "GREEN DOT" Data Logger
« Reply #25 on: February 20, 2013, 01:05:13 PM »
rdsman, Is it possible to plug in the buspirate and spoof the console (in the power on phase), then take off the buspirate and plug in the NON GreenDot logger (never stop the power to the console). Just some thing like tether jailbreak.

While this might be possible, I wouldn't recommend doing it!  Plugging/Un-plugging things into live circuits is never a good idea in my opinion.  I would look for an alternative method.

I originally wrote a program that would allow an Arduino to read a "Green Dot" logger.  The code shown below should allow an Arduino to emulate a "Green Dot" logger just long enough for the console to enable the serial port.  It will then effectively remove itself from the circuit.  See a previous post for the schematic.

Code: [Select]
/*
  Arduino program to spoof the Green Dot Logger
  SPI interface.  (Causes the serial interface
  to be enabled?)
    
  by rdsman
    
  20 FEB 2013
  
  YOU MUST USE AN ARDUINO RUNNING ON 3.3 VOLTS
  OR PROVIDE LOGIC LEVEL CONVERSION!
  
  YOU HAVE BEEN WARNED!
*/
#include "Arduino.h"
//
//  Arduino Definitions.
//
#define RX            0    //  The interface pins are defined here.
#define TX            1
#define SS           10
#define MOSI         11
#define MISO         12
#define SCK          13
//
//  45DB011D Definitions.
//
#define STATUS_REGISTER    0xD7
#define STATUS_WORD        0x8C
#define SECURITY_REGISTER  0x77
//
const byte SECURITY_RESPONSE[128] =
{
  0x80, 0x2D, 0x22, 0x6F, 0x52, 0x6F, 0x98, 0xA9, 0x21, 0x25, 0x5E, 0x2D, 0x2D, 0x31, 0xD2, 0x39,
  0x18, 0x1C, 0x63, 0x0C, 0x31, 0x21, 0x2D, 0x39, 0x90, 0xDE, 0x94, 0x6F, 0x6B, 0x77, 0x73, 0x7F,
  0x63, 0x8C, 0x88, 0x84, 0x80, 0x9C, 0x98, 0x94, 0x90, 0xAD, 0xA9, 0xA5, 0xA1, 0xBD, 0xB9, 0xB5,
  0xB1, 0xCA, 0xCE, 0xC2, 0xC6, 0xDA, 0xDE, 0xD2, 0xD6, 0xEB, 0xEF, 0xE3, 0xE7, 0xFB, 0xFF, 0xF3,
  0x0B, 0x02, 0x16, 0x17, 0x11, 0x15, 0x1F, 0x22, 0x00, 0x00, 0x46, 0x00, 0xFF, 0xFF, 0xAC, 0xFF,
  0x30, 0x30, 0x4D, 0x32, 0x36, 0x39, 0x37, 0x31, 0x0F, 0x1C, 0x0C, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
  0x3F, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
  0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
};  
//
//  Setup Loop.
//
void setup()
{
  delay(100);
  initialize();
  delay(100);
}  
//
//  Main Loop.
//
void loop() // run over and over
{
    
}
//
//  Setup the microprocessor.
//
void initialize()
{
  byte temp;
  byte sreg = SREG;
  
  cli();                       //  Disable global interrupts while we make our changes.
    
  pinMode(RX, INPUT);          //  Set up the Serial data pins.  (Not used by the processor,
  pinMode(TX, INPUT);          //  simply passed through to the USB interface.)
  pinMode(SS, INPUT);          //  Set up the SPI pins.
  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 in Slave Mode.
  
  temp = SPSR;                 //  Clear SPSR.
  temp = SPDR;                 //  Flush SPDR.
  
  SREG = sreg;                 //  Enable global interrupts.
}
//
//  SPI Interrupt Service Routine.
//
ISR(SPI_STC_vect)
{
  volatile byte temp = SPDR;
  
  if (temp == STATUS_REGISTER)       //  Is it reading the Status Register?
    {
      SPDR = STATUS_WORD;            //  If so, send the Status Word.
      while(!(SPSR & (1 << SPIF)));
      temp = SPSR;                   //  Clear SPIF.
      temp = SPDR;                   //  Flush SPDR.
      return;
    }  
  
  if (temp == SECURITY_REGISTER)     //  Is it reading the Security Register?
    {
      for (int i = 0; i < 3; i++)    //  If so, rx/tx three dummy bytes.
        {
          SPDR = 0x00;
          while(!(SPSR & (1 << SPIF)));
          temp = SPSR;
          temp = SPDR;
          if (temp != 0x00)          // Check for all 0x00's.
            return;
        }
      
      for (int i = 0; i < 128; i++)  //  Dump the Security Register.
        {
          SPDR = SECURITY_RESPONSE[i];
          while(!(SPSR & (1 << SPIF)));
          temp = SPSR;
          temp = SPDR;
        }  
      
      SPCR == 0x00;                 //  Disable the SPI.
    }
}    
//
//  The End.
//


It needs to be tried out by someone!
« Last Edit: February 20, 2013, 07:35:08 PM by rdsman »
Ray

Offline belfryboy

  • Forecaster
  • *****
  • Posts: 488
  • waiting for the rain.....
    • Belfryboy Blog
Re: DIY "GREEN DOT" Data Logger
« Reply #26 on: February 21, 2013, 03:11:33 AM »
I shall give it a go as soon as I get a chance.

Offline franzz

  • Member
  • *
  • Posts: 13
Re: DIY "GREEN DOT" Data Logger
« Reply #27 on: February 21, 2013, 04:29:21 PM »
This sounds great.
If it is possible to emulate eeprom access to enable serial line, it could be possible to downgrade FW to 1.9.

It gives us also the possibility to play with different values in security table.
I've analyzed the hex codes from security region bytes 1-64 and the connection to unique ID in bytes 65-128:
Due to the fact that most of unique ID bytes have the value 0xFF I have determined that the corresponding byte in area 1-64 is encrypted with this byte value and the position of the byte, but there is no cross encryption to other bytes.
If you take all the 0xFF and put it into the table below, you can see that there is a pattern. Other values than 0xFF will also take place in this pattern. (see attached table).
Only 64 bytes of 256 possibilities will be used and each value will be used 1 time for a specific unique ID byte depending on the position. All used bytes are highlighted in picture. For all 0xFF and the known position it is very easy to get the right value with this table. For all other byte values the Arduino software from rdsman could be extended to change one byte of know unique ID and make a try which encrypted byte will be used for decryption (it could be only one of 64 bytes)
E.g. change byte 65 from 0x0B to 0x00 and try to change byte 1 to one of the 64 possible bytes. I assume that this procedure could be done automatically by arduino because the RESET of Davis console is also available on the datalogger plug. If encrypted byte was found for 0x00 on the first position let's change the 66th byte to 0x00. Now there are only 63 possibilities left for this position. After finding out 2nd position let's go to byte 67 and do the same try with 3rd byte and 62 left bytes.
If you have any questions please let me know to explain it more detailed.

BR
franzz




« Last Edit: February 22, 2013, 02:25:48 PM by franzz »

Offline DeKay

  • Forecaster
  • *****
  • Posts: 397
    • Mad Scientist Labs
Re: DIY "GREEN DOT" Data Logger
« Reply #28 on: February 22, 2013, 05:38:22 PM »
Due to the fact that most of unique ID bytes have the value 0xFF I have determined that the corresponding byte in area 1-64 is encrypted with this byte value and the position of the byte, but there is no cross encryption to other bytes.
If you take all the 0xFF and put it into the table below, you can see that there is a pattern. Other values than 0xFF will also take place in this pattern. (see attached table).
Only 64 bytes of 256 possibilities will be used and each value will be used 1 time for a specific unique ID byte depending on the position. All used bytes are highlighted in picture. For all 0xFF and the known position it is very easy to get the right value with this table. For all other byte values the Arduino software from rdsman could be extended to change one byte of know unique ID and make a try which encrypted byte will be used for decryption (it could be only one of 64 bytes)

 =D&gt;

Knowing there is no cross-encryption between bytes is a great find.  I also have a feeling this sequence could be useful:

0x00  0x00  0x46  0x00  0xFF

maps to

0x21  0x25  0x5E  0x2D  0x2D

The 0x00 values increment by four * the offset from the first zero.  Note that the last 0x00 immediately followed by a 0xff doesn't change  but retains the same value as last time.

Offline iBangkok24

  • Member
  • *
  • Posts: 25
Re: DIY "GREEN DOT" Data Logger
« Reply #29 on: February 23, 2013, 10:09:06 AM »
This sounds great.
If it is possible to emulate eeprom access to enable serial line, it could be possible to downgrade FW to 1.9.

It gives us also the possibility to play with different values in security table.
I've analyzed the hex codes from security region bytes 1-64 and the connection to unique ID in bytes 65-128:
Due to the fact that most of unique ID bytes have the value 0xFF I have determined that the corresponding byte in area 1-64 is encrypted with this byte value and the position of the byte, but there is no cross encryption to other bytes.
If you take all the 0xFF and put it into the table below, you can see that there is a pattern. Other values than 0xFF will also take place in this pattern. (see attached table).
Only 64 bytes of 256 possibilities will be used and each value will be used 1 time for a specific unique ID byte depending on the position. All used bytes are highlighted in picture. For all 0xFF and the known position it is very easy to get the right value with this table. For all other byte values the Arduino software from rdsman could be extended to change one byte of know unique ID and make a try which encrypted byte will be used for decryption (it could be only one of 64 bytes)
E.g. change byte 65 from 0x0B to 0x00 and try to change byte 1 to one of the 64 possible bytes. I assume that this procedure could be done automatically by arduino because the RESET of Davis console is also available on the datalogger plug. If encrypted byte was found for 0x00 on the first position let's change the 66th byte to 0x00. Now there are only 63 possibilities left for this position. After finding out 2nd position let's go to byte 67 and do the same try with 3rd byte and 62 left bytes.
If you have any questions please let me know to explain it more detailed.

BR
franzz


 =D&gt; Thanks franzz,

As I understand If I have a 45DB that have the unique ID of all 0x00 the 128 byte security register should be look like this


00 04 08 0C 10 14 18 1C 21 25 29 2D 31 35 39 3D 42 45 4A 4E 52 56 5A 5E 63 67 6B 6F 73 77 7B 7F 
80 84 88 8C 90 94 98 9C A1 A5 A9 AD B1 B5 B9 BD C2 C6 CA CE D2 D6 DA DE E3 E7 EB EF F3 F7 FB FF
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Am I correct?

Offline DeKay

  • Forecaster
  • *****
  • Posts: 397
    • Mad Scientist Labs
Re: DIY "GREEN DOT" Data Logger
« Reply #30 on: February 23, 2013, 10:53:28 AM »
For all 0xFF and the known position it is very easy to get the right value with this table. For all other byte values the Arduino software from rdsman could be extended to change one byte of know unique ID and make a try which encrypted byte will be used for decryption (it could be only one of 64 bytes)

Franz

I put together a table in Excel from 0x0 to 0xff and highlighted in yellow the actual values mapping to 0xff.  These hex values are left justified in the attached image.  Like your picture, there is clearly a pattern.  Then I show numbers right justified representing the index in the 64 byte factory written key where the 0xff values appear.  The indexes don't increment regularly from one row to the other.  Instead, there are differences between rows.  Do you understand how to predict the next index?

e.g. Row 21: the index into the factory key is 44, 43, 42, 41.
      Row 29: the index into the factory key is 59, 60, 57, 58.

Offline franzz

  • Member
  • *
  • Posts: 13
Re: DIY "GREEN DOT" Data Logger
« Reply #31 on: February 23, 2013, 11:07:23 AM »


 =D&gt; Thanks franzz,

As I understand If I have a 45DB that have the unique ID of all 0x00 the 128 byte security register should be look like this


00 04 08 0C 10 14 18 1C 21 25 29 2D 31 35 39 3D 42 45 4A 4E 52 56 5A 5E 63 67 6B 6F 73 77 7B 7F 
80 84 88 8C 90 94 98 9C A1 A5 A9 AD B1 B5 B9 BD C2 C6 CA CE D2 D6 DA DE E3 E7 EB EF F3 F7 FB FF
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Am I correct?


Not sure, because if you compare it with the 0xFFs the order is not always increasing.
If you consider the sequence  0x6B, 0x77, 0x73, 0x7F (Byte 29-32) = 0xFF in unique ID, it could be that there are small jumps. It could be that the order of 0x00 in unique Id is the same as for 0xFFs but with a constant shift. One fact is that only 64 bytes will be used for encoding of bytes (see highlighted values in table). If it is able to emulate the EEPROM with the software of RDSMan and Arduino, single bytes of unique ID could be changed and it could be checked by changing according encoded byte in the first region.

BR
franzz

Offline franzz

  • Member
  • *
  • Posts: 13
Re: DIY "GREEN DOT" Data Logger
« Reply #32 on: February 23, 2013, 11:18:49 AM »

Franz

I put together a table in Excel from 0x0 to 0xff and highlighted in yellow the actual values mapping to 0xff.  These hex values are left justified in the attached image.  Like your picture, there is clearly a pattern.  Then I show numbers right justified representing the index in the 64 byte factory written key where the 0xff values appear.  The indexes don't increment regularly from one row to the other.  Instead, there are differences between rows.  Do you understand how to predict the next index?

e.g. Row 21: the index into the factory key is 44, 43, 42, 41.
      Row 29: the index into the factory key is 59, 60, 57, 58.

I did the same in my analysis last week. Try to connect the numbers with lines and arrows and you will see that there are 2 changings in direction (from left to right and vice versa) of the arrows. I've tried to fill the left entries in this table. If emulation of RDSMan works well all FFs could be checked.

BR franzz

Offline iBangkok24

  • Member
  • *
  • Posts: 25
Re: DIY "GREEN DOT" Data Logger
« Reply #33 on: February 24, 2013, 04:56:29 AM »
I'm not sure if this be useful. I compare my Unique ID, Dekay ID with RDSMAN and found out that only some position is change while most of it remain the same

 0x0B 0x02 0x0E 0x05 0x3A 0x30 0x1F 0x22 0x00 0x00 0x5E 0x00 0xFF 0xFF 0xBC 0xFF
 0x30 0x30 0x4D 0x32 0x36 0x36 0x39 0x38 0x07 0x5E 0x2D 0xFF 0xFF 0xFF 0xFF 0xFF
 0x43 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
 

Offline kashima

  • Member
  • *
  • Posts: 3
Re: DIY "GREEN DOT" Data Logger
« Reply #34 on: May 19, 2013, 01:48:53 AM »
I have ported a rdsman's program to an 8pin PIC.
serial interface has been worked.

thankyou rdsman!

Offline belfryboy

  • Forecaster
  • *****
  • Posts: 488
  • waiting for the rain.....
    • Belfryboy Blog
Re: DIY "GREEN DOT" Data Logger
« Reply #35 on: May 19, 2013, 02:36:18 AM »
That's great, what is Manf. Code of the console? Also what firmware is running.

Offline torkelmj

  • Contributor
  • ***
  • Posts: 134
    • My weather station, etc.
Re: DIY "GREEN DOT" Data Logger
« Reply #36 on: May 19, 2013, 04:12:13 AM »
As the cat seems to be skinned... happy to report good results here as well, using an AVR microcontroller.

Thanks to Davis Instruments Corp. for not using a proper authorization scheme (ATMEL cryptochip et al) but rather keeping the costs down by passively reading from and writing to the "dumb" memory chip.

Now, again, the official Davis reply of "hardware changes required a firmware upgrade" when asked about the "incompatible logger" problem - gets even harder to accept. While there may have been some minor changes, nothing required the serial line to be tucked away by a less-than-optimal authorization scheme.

Offline kashima

  • Member
  • *
  • Posts: 3
Re: DIY "GREEN DOT" Data Logger
« Reply #37 on: May 19, 2013, 07:06:28 AM »
hi,
My Vue is #6250 and Mfg code of ME18041xxxx.  'VER' returns May 1 2012. 'NVER' returns 3.0.

this is C source code for a funny experiments.
Code: [Select]
/*
 * compiler: Microchip XC8
 *
 *    PIC12F1822
 *     +--+ +--+
 * VCC |1  ~  8| GND
 *     |2     7| SDO
 *     |3     6| SCK
 *  SS |4     5| SDI
 *     +-------+
 */
#include <pic.h>
#pragma config FOSC=INTOSC,PLLEN=ON,BOREN=ON,BORV=HI,WDTE=OFF,MCLRE=OFF,LVP=OFF

//
//  45DB011D Definitions.
//
#define STATUS_REGISTER 0xD7
#define STATUS_WORD 0x8C
#define SECURITY_REGISTER 0x77
//
const unsigned char SECURITY_RESPONSE[128] =
{
  0x80, 0x2D, 0x22, 0x6F, 0x52, 0x6F, 0x98, 0xA9, 0x21, 0x25, 0x5E, 0x2D, 0x2D, 0x31, 0xD2, 0x39,
  0x18, 0x1C, 0x63, 0x0C, 0x31, 0x21, 0x2D, 0x39, 0x90, 0xDE, 0x94, 0x6F, 0x6B, 0x77, 0x73, 0x7F,
  0x63, 0x8C, 0x88, 0x84, 0x80, 0x9C, 0x98, 0x94, 0x90, 0xAD, 0xA9, 0xA5, 0xA1, 0xBD, 0xB9, 0xB5,
  0xB1, 0xCA, 0xCE, 0xC2, 0xC6, 0xDA, 0xDE, 0xD2, 0xD6, 0xEB, 0xEF, 0xE3, 0xE7, 0xFB, 0xFF, 0xF3,
  0x0B, 0x02, 0x16, 0x17, 0x11, 0x15, 0x1F, 0x22, 0x00, 0x00, 0x46, 0x00, 0xFF, 0xFF, 0xAC, 0xFF,
  0x30, 0x30, 0x4D, 0x32, 0x36, 0x39, 0x37, 0x31, 0x0F, 0x1C, 0x0C, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
  0x3F, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
  0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
};

void main()
{
unsigned char i;
unsigned char cmd, tmp;

OSCCON = 0b11110000; // set a system clock 8MHz x4PLL = 32MHz
ANSELA = 0; // all digital I/O
TRISA = 0b11111110; // SDO pin set to output
SSP1STAT = 0b00000000; // initialize MSSP module
SSP1CON1 = 0b00110100;
SSP1BUF = 0;

while(1){
reset:
while(!BF); // wait a command
if(RA3) goto reset;
cmd = SSP1BUF;

switch( cmd ){
case STATUS_REGISTER:
SSP1BUF = STATUS_WORD; // response word
SSP1IF = 0;
while(!BF); // wait a sending
if(RA3) goto reset;
tmp = SSP1BUF;
SSP1IF = 0;
break;

case SECURITY_REGISTER:
for(i = 0; i < 3; i++){ // put a dummy word
SSP1BUF = 0;
SSP1IF = 0;

while(!BF);
if(RA3) goto reset;
tmp = SSP1BUF;
}
for(i = 0; i < 128; i++){ // put a security response
SSP1BUF = SECURITY_RESPONSE[i];
SSP1IF = 0;
while(!BF);
if(RA3) goto reset;
tmp = SSP1BUF;
}
SSP1IF = 0;
break;
default:
break;
}
}
}

Offline rdsman

  • Senior Contributor
  • ****
  • Posts: 217
Re: DIY "GREEN DOT" Data Logger
« Reply #38 on: May 19, 2013, 01:33:20 PM »
kashima & torkelmj:

The fact that you have it working is good news.  It would also be nice to know if it reads the entire Security Register or perhaps just the first 10 bytes.  Just a guess!

Since it now appears to confirm that Davis is only using the Security Register, it gets those who desire back to building their own logger.  Just take a blank 45DB011D and program the Security Register with an Arduino, Bus Pirate, etc.

Ray

Offline DeKay

  • Forecaster
  • *****
  • Posts: 397
    • Mad Scientist Labs
Re: DIY "GREEN DOT" Data Logger
« Reply #39 on: May 19, 2013, 09:25:01 PM »
kashima & torkelmj:

The fact that you have it working is good news.  It would also be nice to know if it reads the entire Security Register or perhaps just the first 10 bytes.  Just a guess!

Since it now appears to confirm that Davis is only using the Security Register, it gets those who desire back to building their own logger.  Just take a blank 45DB011D and program the Security Register with an Arduino, Bus Pirate, etc.


Kashima.  This is indeed excellent news.  Well done, Sir!   =D&gt;
 
rdsman, your suggestion won't work, I think.  Of the 128 bytes in the security register, 64 are one-time-programmed at the factory with a unique code.  Kashima's solution works because he has the known key to a known code.

It would be easier for us if we could break the code for the EEPROM, but not much easier.  It doesn't seem worth the effort anymore   :-) 

Offline dmurphydrtc

  • Member
  • *
  • Posts: 19
Re: DIY "GREEN DOT" Data Logger
« Reply #40 on: May 20, 2013, 03:20:06 AM »
Folks,

Does this mean we are close to getting the RS-232 comms. port working on the newer green dot Vantage products? That
indeed would be great news. I have my ISS working via 3DR as per Andrew Tridge solution but their are a few readings from the Console
are not available...have the rs-232 port working would be magic.

Offline belfryboy

  • Forecaster
  • *****
  • Posts: 488
  • waiting for the rain.....
    • Belfryboy Blog
Re: DIY "GREEN DOT" Data Logger
« Reply #41 on: May 20, 2013, 04:01:00 AM »
Folks,

Does this mean we are close to getting the RS-232 comms. port working on the newer green dot Vantage products? That
indeed would be great news. I have my ISS working via 3DR as per Andrew Tridge solution but their are a few readings from the Console
are not available...have the rs-232 port working would be magic.

I am working on this as I type....

Offline torkelmj

  • Contributor
  • ***
  • Posts: 134
    • My weather station, etc.
Re: DIY "GREEN DOT" Data Logger
« Reply #42 on: May 20, 2013, 05:22:30 AM »
Quote from: DeKay link=topic=18110.msg183220#msg183220
It would be easier for us if we could break the code for the EEPROM, but not much easier.  It doesn't seem worth the effort anymore   :-)  

The problem with the current approach is that known "public" chip IDs and/or keys could be blocked in subsequent FW releases (up to a certain limit, taking into account the memory limitations of the ATmega128). Just a thought.

Offline torkelmj

  • Contributor
  • ***
  • Posts: 134
    • My weather station, etc.
Re: DIY "GREEN DOT" Data Logger
« Reply #43 on: May 20, 2013, 05:32:16 AM »
It would also be nice to know if it reads the entire Security Register or perhaps just the first 10 bytes.  Just a guess!

Will check on that later today. I've just been dumping the full 128 bytes to the console.

Now, another thought: all the 45DB dataflash chips come with a manufacturer ID and a device ID as well as a unique chip ID. The first two values appear as expected (standard, that is) but does the FW require a certain range of chip IDs in order to work? Could anyone please provide me with a chip ID for a non-Davis-supplied 45DB dataflash chip? I still haven't received mine (public holidays here...)

Offline torkelmj

  • Contributor
  • ***
  • Posts: 134
    • My weather station, etc.
Re: DIY "GREEN DOT" Data Logger
« Reply #44 on: May 20, 2013, 01:56:46 PM »
It would also be nice to know if it reads the entire Security Register or perhaps just the first 10 bytes. 

I may misunderstand your question here; as you can see from the attached SPI bus dump file, the entire security register of 128 bytes is returned, but whether the entire thing is actually *processed* by the console, I haven't yet checked. This far I've been quite happy returning some values which the console accepts. FWIW, the entire 128-byte (programmed) security register is listed in the attached dump file. If anyone needs it in a more readable format in their quest to find the "key", please let me know.

--- start relevant stuff ---
@ 5.87493098: console issues 0xD7 to read status register from dataflash chip
@ 5.87495648: chip replies with 0x8C (10001100), ref. 45DB011 documentation
@ 5.87505848: console issues 0x77 plus three dummy bytes to read security register from chip
@ 5.87517078: chip dumps the 128-byte (programmed) security register, in this case starting with 0x9A
--- end relevant stuff ---
@ 6.33447974: console issues 0xD2 for a page read
@ 6.33577918: console issues 0xD7 (as above)
@ 6.33587902: console issues 0x53 plus three address bytes for "main memory page to buffer transfer"

BTW, last week's visit to Hayward proved that not everybody at a certain manufacturer was too happy about the new "features" introduced in FW version 3.xx. On the good side, don't be surprised if a better-resolution rain gauge turns up pretty soon.
« Last Edit: May 20, 2013, 02:35:48 PM by torkelmj »

Offline rdsman

  • Senior Contributor
  • ****
  • Posts: 217
Re: DIY "GREEN DOT" Data Logger
« Reply #45 on: May 20, 2013, 06:24:36 PM »
Quote
I may misunderstand your question here;

Nope, not at all.  The fact that it dumps all 128 bytes is what I wanted to know!

Thanks
Ray

Offline dmurphydrtc

  • Member
  • *
  • Posts: 19
Re: DIY "GREEN DOT" Data Logger
« Reply #46 on: May 28, 2013, 08:59:31 AM »
Folks,

Any further progress with this problem?  Feedback would be much appreciated.

Offline torkelmj

  • Contributor
  • ***
  • Posts: 134
    • My weather station, etc.
Re: DIY "GREEN DOT" Data Logger
« Reply #47 on: May 28, 2013, 11:46:14 AM »
To a certain (sufficient?) extent, I guess most of the work has been done and documented by the fine folks in here. Arduino, AVR-Atmega/Attiny, PIC, ... won't be long until fully working 3rd party data loggers will be available again.

Offline dmurphydrtc

  • Member
  • *
  • Posts: 19
Re: DIY "GREEN DOT" Data Logger
« Reply #48 on: June 20, 2013, 09:54:23 PM »
Any further progress with this problem?

Offline torkelmj

  • Contributor
  • ***
  • Posts: 134
    • My weather station, etc.
Re: DIY "GREEN DOT" Data Logger
« Reply #49 on: June 21, 2013, 03:12:57 AM »
Yes. There's a fine solution mentioned a few posts further up. It's adequate for disabling the serial-line lockdown, which was *my* main goal. Adding a few nuts and bolts will yield a fully capable data logger.

The above code snipet/implementation is for a PIC12F1822, but the same logic can be applied to other microcontrollers capable of SPI communication or SPI-like communication. I'm presently running some stability checks for an implementation using an ATtiny microcontroller priced at $1, which means that the console connector remains the most expensive part of the setup.

As for a 3rd party data logger, my bet is that we'll see one very soon.

Apart from that - what do you want to know? Specific questions have a tendency to yield specific answers.  ;)