APRS started to become more popular at about the time I was busy running a packet BBS and then I abandoned packet radio completely when my eldest son was born, so I missed out on a lot of the specs and techniques when they were originally discussed. However, as a Ham I’ve always thought I should know more about it, so I’ve been taking a look at the specs to see how it works. I might even consider digging my TNC out to try it out on air at some point.
I’ve been looking at the APRS spec document and also at some of the data flying round on the Internet (which is a good source whilst I don’t have an off-air decoding facility). I’ve started to make some sense of the data types that appear (including the weather packets), but I’ve found something that appears to be inconsistent with the specs. Take the following packet for example…
It’s a weather report with timestamp and position data. What’s puzzling me is the timestamp. It’s 6 digits followed by a ‘z’ which the specs suggest should be a zulu time in Day/Hour/Minute format. Hwoever, it looks very much like a zulu time in Hr/Min/Sec format (the hour field would be 50 in DHM format). I’d have put this down to one station sending rogue data, but there seem to be quite a lot of packets, not all from the same station, with this format of timestamp.
Has the spec changed to allow an extra format, or are these stations all sending data that’s not compliant with the spec? I suspect it’s the latter because otherwise there doesn’t appear to be any way to know if you’re looking at a DHM or HMS time for many days in the month. For example, say it’s the 20th of July, does 200400z mean 4am on the 20th or 4 minutes past 8pm? Also there are plenty of packets around that seem to comply with the spec, so it’s unlikely that the old timestamp format has been superceded.
Hopefully someone can answer this and deconfuse me!
It would make sense as an ‘h’ (actually as 06:50:00, i.e. 10 minutes before 7am), but it’s definitely a ‘z’. All the examples I’ve looked at that are like this do appear to be valid H/M/S timestamps, just with a ‘z’ rather than a ‘h’.
I’ve looked at this a little further and the vast majority of the weather packets with non-standard timestamps appear to end with the strings…wv32, XRSW, e1w or wiz3d. I’m guessing that this is a comment message indicating the software being used?
XRSW is probably a Perl script which can send CWOP messages.
e1w is probably generated by some software for a T238 1-wire weather station.
wiz3d is probably Raindrop Labs wiz3d software
wv32 is probably WeatherView32
Can anyone confirm if this is correct?
I know WV32 can now send CWOP data for itself, but there was (is still?) a script (wuhu?) that is an addon for WV32 that could be used to send CWOP before this was added into WV32. Does ‘wv32’ indicate the built-in WV32 CWOP or the addon…or do they both send the same string?
That’s what I’m comparing the timestamps against. The spec suggests that HHMMSSz isn’t a correct time format in APRS. However, it doesn’t (and shouldn’t IMO) define the allowable values for software types.
The problem that you are seeing is a bug in the WeatherView 32 software. The software is reporting the time in hhmmss format instead of the CWOP ddhhmm format. Dave Heider has been informed of this problem, but to the best of my knowledge he has not fixed it yet.
Thanks Mike. I guess you made the change you suggested to fix the posting problem? I’ve not had a response from the developers yet, but as some are East Coaster’s and stay up late coding it’s a bit early yet for them to have surfaced!
I saw this problem apparently generated by other software as well, e.g. XRSW, e1w (T238 1-wire weather station?) and wiz3d (Raindrop Labs?). Do you know if the authors of those packages have been advised of the problem? I must admit though that I’ve not looked at this since I last posted, so it’s possible that the examples I saw have all been fixed now.
I know that WUHU is still around as there was some issues with it during the recent WU meltdown as noted in this message sent to the CWOP Quality Control Mailing list…
To: Discussion of weather data quality issues
Date: Jan 7, 2006 6:33 PM
To: [email protected]
Subject: [wuhu_software_group] Please update WUHU to latest version (142).
Today, many users (including myself) discovered that WUHU was locked up
when it was attempting to upload to the Weather Underground.
Apparently one of their servers had crashed. When it did, the web
server sent an endless steam of error information back to WUHU. This
caused WUHU to lock up and hog the processor.
I have addressed this problem in version 142.
I would highly recommend that all WUHU users update to the latest
version in case the WU servers encounter this situation again.
I am not sure about the other software packages, I have one Rainwise system that uses the WV32 software and that is why I know about it’s bug. I am currently working on some software to allow my Coastal Environmental stations to report to CWOP, but that is all I am familier with.