Topic: VP2 - UV and solar radiation message protocol

[miniC.rl]

Hi everybody,

first to all I would like TANKS to DeKay http://www.wxforum.net/index.php?action=profile;u=1954 for this https://github.com/dekay/im-me/blob/master/pocketwx/src/protocol.txt.

UV radiation
Message 4:
Here are readings for UV and readings from console.

Code: [Select]

40 00 00 FF C5 00 4C D2 -- Off (unplugged sensor)
40 00 00 00 45 00 98 29 -- 0
40 00 00 0B C5 00 73 40 -- 0.9
40 00 00 0B 05 00 65 14 -- 0.9
40 00 00 11 05 00 E1 B6 -- 1.3
40 00 00 12 85 00 A3 7E -- 1.5
40 00 00 12 45 00 B5 2A -- 1.4
40 00 00 11 45 00 EC 7A -- 1.4
40 00 00 11 C5 00 F7 E2 -- 1.4
40 00 00 0F 45 00 B4 18 -- 1.2
40 00 00 0D C5 00 C1 E0 -- 1.1
40 00 00 09 45 00 06 B8 -- 0.7
40 00 00 19 05 00 48 17 -- 2.0
Byte 3 and 4 are solar radiation (the first byte is MSB and the second LSB), but you can notice that lower nibble of 4th byte is always 5, so they use only 3 nibbles!
And here is the equation: UVI = ((VALUE>>4)-4)/200 rounded on first decimal place. Why -4? Because 0 is 0x45>>4 = 0x4 = 4

e.g. 40 00 00 11 45 00 EC 7A
0x1145>>4 = 0x114 = 276
(276-4)/200= 1.36 rounded on one decimal place = 1.4


Solar radiation
Meesage:6

Code: [Select]

60 00 00 FF C5 00 11 82 -- Off (unplugged)
60 00 00 00 45 00 AD 21 -- 0
60 00 00 00 85 00 BB 75 -- 2
60 00 00 01 05 00 97 DD -- 7 
60 00 00 01 85 00 8C 45 -- 11 
60 00 00 01 C5 00 81 89 -- 11 
60 00 00 02 45 00 C3 41 -- 16 
60 00 00 05 85 00 50 85 -- 39 
60 00 00 06 C5 00 04 19 -- 47 
60 00 00 08 45 00 04 80 -- 58 
60 00 00 08 C5 00 1F 18 -- 74 
60 00 00 15 C5 00 1E 2A -- 153
60 00 00 16 45 00 5C E2 -- 156
60 00 00 17 45 00 6B D2 -- 163
60 00 00 17 C5 00 70 4A -- 167
60 00 00 18 C5 00 5C 7B -- 176
60 00 00 1C C5 00 80 BB -- 202
60 00 00 1E 45 00 F5 43 -- 218
60 00 00 1D 85 00 BA 47 -- 221
60 00 00 25 05 00 CD DB -- 260
60 00 00 43 C5 00 F2 44 -- 478
60 00 00 48 45 00 19 2D -- 513
60 00 00 48 C5 00 02 B5 -- 513
60 00 00 56 85 00 57 1B -- 610
60 00 00 6E 85 00 3B 1F -- 782
60 00 00 72 45 00 1B 49 -- 810
60 00 00 74 05 00 A4 25 -- 816
60 00 00 75 45 00 9E D9 -- 830
60 00 00 79 45 00 EB B8 -- 847
60 00 00 78 05 00 D1 44 -- 847
60 00 00 8E 05 00 80 B6 -- 986
60 00 00 FA 85 00 9F E6 -- 1761
Byte 3 and 4 are solar radiation.  The first byte is MSB and the second LSB.
We can see that 0 is 0x45 and Off 0xffc5 and all data ends with 5, so the story is similar...
Thay says that readings are in range 0-1800. I had reading for 1761 and for 39 so 1761+39 = 1800 or 0xfa8+0x58 = 0x1000 Zero is starting from 0x4 so 0x1000 - 0x4 = 0xffc. Hmmmm I already saw that value!!! 0xFFC5 - sensor unplugged! And because we have two values we need 0x1000 - 0x8 = 0xff8.
So, probably max value of 1800 is 0xFF85. 0xFF8 or 4088 devided by 1800 is 2.27

w/m2 = round(((VALUE>>4)-4)/2.27) So let's check that silly 2.27!

Using Matlab, I plotted those values

Code: [Select]

val=[4,16,28,36,88,108,132,348,356,372,380,396,460,592,1084,1164,1384,1768,1828,1856,1876,1920,4008]; - (VALUE>>4)
res=[0,7,11,16,39,47,58,153,156,163,167,176,202,260,478,513,610,782,810,816,830,847,1761];The result was (almost) straight line!
Than I used polyfit to find the best fitted line with this one.

[P,S] = polyfit(res,val,1)
P =
   2.2704   -0.2488
S =
        R: [2x2 double]
       df: 22
    normr: 20.5292

So, Matlab says that I need to multiply values with 2.27 and to subtract 0.2488.

Than I plotted just this w = round(((VALUE>>4)-4)/2.27) and lines were almost perfectly fitted! Why almost?? Ok this is maybe little bit confusing...
I have VP2 Pro Wi-Fi, and I bought just cabled IIS without any sensor, and R485 to USB converter.
I found on this forum that they talk at 4800/8/n/1, and I start to get same data as Dekay.
Because I didn’t had cabled console to read real data, I done this:
Using RJ11 splitter I sent readings from sensors to both IIS. The bad thing was that I couldn’t manage to turn them on at the same time, so I had few seconds delay between  readings on wifi console and PC. Because of that , I have some outliers and/or bad readings.
So, if someone have cabled IIS and cabled console, please use Rj11 splitter + RS485toUSB and read data simultaneously and check is this formula valid or not, or share your readings in this topic.

And once again, THANK YOU DeKay!!!

[DeKay]

So, if someone have cabled IIS and cabled console, please use Rj11 splitter + RS485toUSB and read data simultaneously and check is this formula valid or not, or share your readings in this topic.

And once again, THANK YOU DeKay!!!

No problem!  And THANK YOU for sharing your work.  I'll certainly add it to my protocol document one of these days.

It would be really cool if you pulled together a figure showing in detail how you wired the splitter and converter to the cabled ISS, along with details on the converter you used and other bits of info you could share.

Nice job!   

[miniC.rl]

First, sorry for lots of grammar/spelling and other errors in previous post!  

This is setup in my office:


This is RJ11 splitter that I used:


Cables are maybe little bit long, but...

And RS485 to USB is cheap $10 China made, I couldn't find link on internet  

I tried to plug power cable on IIS cabled and to put battery in wifi ISS at the same time, but as I already says, I had delay for about 1 sec.

Davis use the same protocol for wifi and cabled version, so I guess that message 5 or probably 9 (or some other that we didn't catch) is for Battery low info.

I would like to replace my wifi IIS, and to read all the data directly. Possibilities are great. I may use PC, or Igep/Bigl/Raspberry Pi/NSLU2, or send the data over GPRS...

I also found on this forum that someone just solder rs485 driver on wifi version of ISS and got cabled version, but that depends on the firmware version and revision of ISS. I know because I tried that also, but only thing that I get was ...10101010101010101010101010101010101010...   I used oscilloscope to saw that signal and RS485 to USB converter.

I almost forgot, you need to be careful with cables that you use, because it could be cross linked cable. I also made that mistake because I didn't pay attention  

[miniC.rl]

Some interesting links:

DERIVED VARIABLES IN DAVIS WEATHER PRODUCTS
http://www.novalynx.com/manuals/WRM_apnote28.pdf

UVI to MEDs
http://meteo.lcd.lu/papers/uv/uvi/uvi_03.html

[DeKay]

Also interesting: this fellow took the Davis solar sensor apart to reveal the goodies beneath.
http://vantagepro2.meteo-quimper.fr/vantage-pro-2/davis-6450-sonde-rayonnement-solaire-pyranometre/

[Skywatch]

Also interesting: this fellow took the Davis solar sensor apart to reveal the goodies beneath.
http://vantagepro2.meteo-quimper.fr/vantage-pro-2/davis-6450-sonde-rayonnement-solaire-pyranometre

Way too cool!


Saw that the amplifier component is made by Texas Instruments. My dad is an engineer for them. I wonder if he took any part in it? 

[intra_au]

I've been programming RFBee to receive data from ISS and have decoded all packets.
I believe the data below is more accurate:

UV Index:
First byte is MSB, second is LSB, shift 6 bits right and divide result by 50.

Solar Radiation:

First byte is MSB, second is LSB, shift 6 bits right and multiply result by 1.757936

Arduino code:
void uvi()
{
  word tt = word(data[3], data[4]);
  tt = tt >> 6;
  g_uv = tt/50.0;
}

void solar()
{
  word tt = (word(data[3], data[4]));
  tt = tt >> 6;
  g_sol = tt * 1.757936;
}

[Bushman]

Gosh that is cool!  Will you release all the code for the full packet?  This is tempting me to  find some some time (fat chance I know...) and pick up an Aurduino and play.

[Scott216]

UV radiation
Message 4:
Here are readings for UV and readings from console.

Code: [Select]

40 00 00 FF C5 00 4C D2 -- Off (unplugged sensor)
40 00 00 00 45 00 98 29 -- 0
40 00 00 0B C5 00 73 40 -- 0.9
40 00 00 0B 05 00 65 14 -- 0.9
40 00 00 11 05 00 E1 B6 -- 1.3
40 00 00 12 85 00 A3 7E -- 1.5
40 00 00 12 45 00 B5 2A -- 1.4
40 00 00 11 45 00 EC 7A -- 1.4
40 00 00 11 C5 00 F7 E2 -- 1.4
40 00 00 0F 45 00 B4 18 -- 1.2
40 00 00 0D C5 00 C1 E0 -- 1.1
40 00 00 09 45 00 06 B8 -- 0.7
40 00 00 19 05 00 48 17 -- 2.0
Byte 3 and 4 are solar radiation (the first byte is MSB and the second LSB), but you can notice that lower nibble of 4th byte is always 5, so they use only 3 nibbles!
And here is the equation: UVI = ((VALUE>>4)-4)/200 rounded on first decimal place. Why -4? Because 0 is 0x45>>4 = 0x4 = 4

e.g. 40 00 00 11 45 00 EC 7A
0x1145>>4 = 0x114 = 276
(276-4)/200= 1.36 rounded on one decimal place = 1.4


Solar radiation
Meesage:6

Code: [Select]

60 00 00 FF C5 00 11 82 -- Off (unplugged)
60 00 00 00 45 00 AD 21 -- 0
60 00 00 00 85 00 BB 75 -- 2
60 00 00 01 05 00 97 DD -- 7 
60 00 00 01 85 00 8C 45 -- 11 
60 00 00 01 C5 00 81 89 -- 11 
60 00 00 02 45 00 C3 41 -- 16 
60 00 00 05 85 00 50 85 -- 39 
60 00 00 06 C5 00 04 19 -- 47 
60 00 00 08 45 00 04 80 -- 58 
60 00 00 08 C5 00 1F 18 -- 74 
60 00 00 15 C5 00 1E 2A -- 153
60 00 00 16 45 00 5C E2 -- 156
60 00 00 17 45 00 6B D2 -- 163
60 00 00 17 C5 00 70 4A -- 167
60 00 00 18 C5 00 5C 7B -- 176
60 00 00 1C C5 00 80 BB -- 202
60 00 00 1E 45 00 F5 43 -- 218
60 00 00 1D 85 00 BA 47 -- 221
60 00 00 25 05 00 CD DB -- 260
60 00 00 43 C5 00 F2 44 -- 478
60 00 00 48 45 00 19 2D -- 513
60 00 00 48 C5 00 02 B5 -- 513
60 00 00 56 85 00 57 1B -- 610
60 00 00 6E 85 00 3B 1F -- 782
60 00 00 72 45 00 1B 49 -- 810
60 00 00 74 05 00 A4 25 -- 816
60 00 00 75 45 00 9E D9 -- 830
60 00 00 79 45 00 EB B8 -- 847
60 00 00 78 05 00 D1 44 -- 847
60 00 00 8E 05 00 80 B6 -- 986
60 00 00 FA 85 00 9F E6 -- 1761
Byte 3 and 4 are solar radiation.  The first byte is MSB and the second LSB.
We can see that 0 is 0x45 and Off 0xffc5 and all data ends with 5, so the story is similar...
Thay says that readings are in range 0-1800. I had reading for 1761 and for 39 so 1761+39 = 1800 or 0xfa8+0x58 = 0x1000 Zero is starting from 0x4 so 0x1000 - 0x4 = 0xffc. Hmmmm I already saw that value!!! 0xFFC5 - sensor unplugged! And because we have two values we need 0x1000 - 0x8 = 0xff8.
So, probably max value of 1800 is 0xFF85. 0xFF8 or 4088 devided by 1800 is 2.27

Very nice work, I don't think I could have figured this out.  So it looks like if byte 3 = FF then the sensor is offline.

Have you done the same analysis for the byte 0 = 0x50 packet?  I think this is seconds between bucket tips and the calculation is (Byte3) x (Byte4 >> 4).  I'm not near my weather station right now, so I can't test it yet.

[Scott216]

I'm trying to decipher the seconds between bucket tips that's used for the rain rate calculation.  I think this info is in packet header 5.  I had a rain storm come through yesterday and logged the bucket tips along with the packet data.  I calculated the time between bucket tips based on when that data was transmitted by the ISS, so it's probably not exact since the ISS may send the data a few seconds after the actual tipping event.  The first 4 records I estimated the time between bucket tips so they may not be as accurate.  Anyway, I don't see anything in bytes 3 and 4 that I can make sense of.  I'd appreciate if someone would take a look at the data, maybe you can figure out how it's encoded.

Columns:
ISS Bucket Counter: this is the ISS counter from 0-127.  It increments every time the bucket tips. 
Seconds between tips: Seconds between bucket tips based on when I received the data from ISS
Data Packet: ISS data packet, header 5
Byte 3 MSN: Byte 3 most significant nibble, in decimal
Byte 3 LSN: Byte 3 least significant nibble, in decimal
Byte 4 MSN: Byte 4 most significant nibble, in decimal
Byte 4 LSN: Byte 4 least significant nibble, in decimal
Byte 3: decimal value of byte 3
Byte 4: decimal value of byte 4

CSV file is attached (although it has a txt extension)

[LRB-MT]

This is a very old topic but I found it useful and would like to add my 2 cents as to what I found with the solar calculation.  I spent a morning looking at byte values for the 0x60 header versus VP2 console reading.  I obtained results very close to what intra_au shows.  In other information there were two formulas that I tried that did not match. 

Code: [Select]

     // Calculation source: http://www.wxforum.net/index.php?topic=18489.msg178506#msg178506
     // tt = word(radio.DATA[3], radio.DATA[4]);
     // tt = tt >> 4;
     // sol = (float)(tt - 4) / 2.27 - 0.2488;
     //loopData.solarRadiation = (uint16_t)(radio.DATA[3] * 4) + ((radio.DATA[3] && 0xC0) / 64 ); // Another source: http://www.carluccio.de/davis-vue-hacking-part-2/What I found was that the value is 10 bits, is a straight line and I got a formula of y= mx + b where m = 1.758488 and b = -0.0451.  I suspect that I could leave off the b and have a value that matches the Davis console. 

Code: [Select]

loopData.solarRadiation = (uint16_t)((((radio.DATA[3] << 2) + (radio.DATA[4]>> 6))*1.758488)- .0451);  That is very close to what intra_au has.  Good luck to all those that are intercepting the ISS wireless data and rolling their own quasi Davis console.