Topic: Looking for list of the CWOP data codes used in the raw data packet.

[weatherjim]

Can anyone direct me to a location where I could find all of the codes and there definition used to make up the raw data packet for CWOP. Most of the raw data for my station is self explanatory but I have on on the end of the data packet which I don't understand ws20?
Thanks

[SLOweather]

I just went through this.

Google CWOP upload string or CWOP upload protocol.  I found some info at http://www.raspberrypi.org/phpBB3/viewtopic.php?t=23942&p=381562.

To answer your question, the very end of the string is the hardware or software used to upload the data. So ws20 probably refers to your program.

[weatherjim]

Thanks, I was guessing along those lines. I am using WeatherSnoop, so that makes since. I did a lot go Googling but no complete list, I'll try the locations that you listed.

[SlowModem]

Here's one of mine:

DW0148>APRS,TCPXX*,qAX,CWOP-1:@120737z3541.04N/08442.41W_210/000g000t068r000p000P000h95b10220eWUHU216DAVISVP2.

I use WUHU and have a Davis VP2.  So what was said earlier is correct.  It just depends on what your software sends to cwop.

[weatherjim]

Thanks again for narrowing down my search.  Here is a sample of my raw data
EW5524>APRS,TCPXX*,qAX,CWOP-2:@131555z4305.10N/07403.98W_134/001g002t074P000h84b10226ws20.

Since I have Apple computers in my house, there is a limited amount software available for my Rainwise weather station. I am finding out that WeatherSnoop is a good quality software package and the developer is behind his product. Which is very rare in today's world.

[SlowModem]

From the cwop faq page

http://wxqa.com/faq.html

7. How is the weather data coded into the data packet? When you look at examples of APRS position weather packets here, or here, the part after the longitude "E" or "W" carries the weather data as symbols followed by numbers. The underscore "_" followed by 3 numbers represents wind direction in degrees from true north. This is the direction that the wind is blowing from. The slash "/" followed by 3 numbers represents the average wind speed in miles per hour. The letter "g" followed by 3 numbers represents the peak instaneous value of wind in miles per hour. The letter "t" followed by 3 characters (numbers and minus sign) represents the temperature in degrees F. The letter "r" followed by 3 numbers represents the amount of rain in hundredths of inches that fell the past hour. The letter "p" followed by 3 numbers represents the amount of rain in hundredths of inches that fell in the past 24 hours. Only these two precipitation values are accepted by MADIS. The letter "P" followed by 3 numbers represents the amount of rain in hundredths of inches that fell since local midnight. The letter "b" followed by 5 numbers represents the barometric pressure in tenths of a millibar. The letter "h" followed by 2 numbers represents the relative humidity in percent, where "h00" implies 100% RH. The first four fields (wind direction, wind speed, temperature and gust) are required, in that order, and if a particular measurement is not present, the three numbers should be replaced by "..." to indicate no data available. Solar radiation data can also be coded into the data packet.

[weatherjim]

I just stumbled across a location in APRSWXNET documentation that give a little more detail about the upload code for the weather station type in the data packet.

http://weather.gladstonefamily.net/aprswxnet.html

[SLOweather]

Interesting... Last week, Google indexed that but the page wasn't available. I had to look at a cached copy.

I just stumbled across a location in APRSWXNET documentation that give a little more detail about the upload code for the weather station type in the data packet.

http://weather.gladstonefamily.net/aprswxnet.html

[SLOweather]

A couple of things... Most parameters seem to need a fixed data width, like 3 digits for temp. The docs aren't too clear on L for solar. I've seen both 3 and 4 digit solar readings (L876, L0876). And I've seen both e and a ".", and also no delimiter before the final equipment field. That's the only one that seems to be free form.

[weatherjim]

That's interesting , but maybe when the raw data is parsed and the required data has been received they do a character vs numerical check on the following bytes of data. Then the published format for the following fields could vary somewhat, field with decimal placement would have to be accounted for. For instance b10256 (1025.6) vs b9999 (999.9).

Just guessing on my part.
Jim

[SLOweather]

Heh, well, I broke the upload by not paying attention. Just now I tested my manual string. It doesn't seem to like 4 digit baro, but likes 5 digits. (b9997 not good, b09997 OK.)

You can see that the raw file gets there:
http://www.findu.com/cgi-bin/raw.cgi?call=EW5508

But bad strings don't make it into the weather table:
http://www.findu.com/cgi-bin/wx.cgi?call=EW5508

A couple of those tests were bad due to a stray S in the lat/lon.

[weatherjim]

Well, so much for my guessing on the formatting. But what would be going on with solar L, 3 vs 4 numbers then?
Also my raw data does not use " e " before the equipment data bytes, just ws20. I'll check with weather snoop to see if it was omitted accidentally.  Maybe I can get a protocol list from them.