WXforum.net
Weather Software => Station Software Development => Topic started by: michaelgalassi on August 25, 2019, 11:56:06 AM
-
I'm adding support for CWOP uploads to fwx (https://github.com/michaelgalassi/fwx (https://github.com/michaelgalassi/fwx)) and I'm having trouble figuring out how to encode solar radiation.
In chapter 12 (Weather Reports) of the APRS Protocol Reference it states that L = luminosity (in watts per square meter) 999 and below and that l (lower case L) = luminosity (in watts per square meter) 1000 and above.
The temptation is to use the format "L%03d" for L and when the value goes over 999 switch to "L%04d" but this seems somewhat odd to me.
What have others done in this regard? Does anyone have some valid CWOP packets with solar radiation which they could share with me?
Thank you!
-
Below is the PHP code I'm using. It may be derived from a weewx driver - can't remember. You can look at raw packets for each CWOP station. Here is the link to mine http://www.findu.com/cgi-bin/raw.cgi?call=FW3280 (http://www.findu.com/cgi-bin/raw.cgi?call=FW3280). More code in my github link in my signature.
Mike.
if ($_GET['solarradiation'] < 1000) {
$solar = 'L' . sprintf('%03d', round($_GET['solarradiation']));
} elseif ($_GET['solarradiation'] < 2000) {
$solar = 'l' . sprintf('%03d', round($_GET['solarradiation'] - 1000));
} else {
$solar = "";
}
-
The APRS protocol was designed to be as concise as possible and not utilize extra characters whenever possible. This is why the method of lower case l was used for solar radiation > 999 w/m2. It was rather ingenious because when reviewing raw data packets the lower case l looks like a 1. So why is all of this odd?
-
Thank you Mike & galfert, that was the little bit I needed. The protocol reference's phrasing does not make clear that the lower case L scenario is the excess after 1000 watts/m^2 have been subtracted which is why I was confused.
-michael
-
I added the code to do that and these are my resulting packets.
http://www.findu.com/cgi-bin/raw.cgi?call=CW3202 (http://www.findu.com/cgi-bin/raw.cgi?call=CW3202)
Looking at yours (Mike), I notice that you use what looks like free-form text at the end of each packet to provide your weather station model (Ambient Weather...). I didn't find in the doc any specification for how this might be done. All the other fields start with a specific character and have a specific length so it is obvious where they start and end. What would happen if a next version of the APRS protocol defined a field called "A" which takes 2 bytes of data which would match the "A" in Ambient Weather, would this mess things up by injecting the data "mb" into various databases?
Is the protocol reference v1.0.1 dated 29th of August 2000 the most current one?
Sorry about the inane questions.
-michael
-
1.0.1 is the latest but there is an addendum taking it to 1.1
http://www.aprs.org/aprs11.html
Then there is a proposal for 1.2 which I don't think are officially ratified
http://www.aprs.org/aprs12.html
Original 1.0.1
http://www.aprs.org/doc/APRS101.PDF
-
Looks good michael! Thanks galfert for the spec links. Oops, looks like I don't code APRS software type. I agree the station equipment list is pretty unorganized. When I was coding mine I tried to blend in as close to what was out there at the time https://weather.gladstonefamily.net/cgi-bin/wxequip.pl (https://weather.gladstonefamily.net/cgi-bin/wxequip.pl). Looks like the spec planned on only 2-4 characters but the cat is out of the bag on that one. The CWOP ingest parser seems pretty forgiving for software and weather unit types. Another suggestion for protocol updates would be to drop both from the packets since software and station type are pretty static.
Hopefully CWOP remains viable enough to be a standards driver.