MesoWest CWOP Data NOT matching Weatherflow Data

Tempest Owners
21

The data is missing from the weewx database at times. Sometimes I only get partial obs added to the database. Data is missing in the raw packets sent to CWOP. Its not that CWOP or Mesowest isn’t getting the data which can happen at times. Weewx isn’t sending the complete ob at times.

CW9009>APRS,TCPXX*,qAX,CWOP-3:@202309z4333.05N/11621.16W_…/…g…t…r000p000P000b…h…L383.weewx-3.8.2-WeatherFlowUDP

I have seen this happen to most stations running the weatherflowUDP driver. Whether its a driver problem or a weewx problem, I really can’t say. But It’s been a problem. Even @cmottice was sending packets to CWOP with missing data for a while there though it hasn’t happened today.

22

I concur with @GaryFunk, I have been using the UDP Api for quite a while now… with no missing data. I would lean toward this being a weewx issue.

23

That can be anything from a network issue, to the hardware you are running the applications on to the applications. It is possible it might be the Hub but I find that the least likely.

24

You’d have to work with the weewx driver author to see how you mapped your sensors and what it’s assembling and saving to the weewx database under the hood.

WeatherFlow is a partial observation kind of station, where some data comes from obs_sky, some from obs_air, some from rapid_wind (using the WF UDP API terminology). Weewx itself can only publish the data it has, so it’s the driver’s responsibility to do the right thing to get the data it hears off the wire(less) into the database.

If anybody knows how to set up a second station in CWOP, I’d be willing to turn that upload feature on in my pi here that uses the same driver to seed my local weewx database. I took a quick look at the CWOP sites but didn’t find a way to register a second station with my email address. It seems to only like 1 station per person for registration…

25

CWOP is one station per email. Just sign up with a different email.

1 Like
26

…or crack a study guide and do for the Ham Radio Technician license, where you can send data RF via APRS using your call sign. :smile: These are two links from my Davis VP2, via weewx:

http://www.findu.com/cgi-bin/wxpage.cgi?call=K2BIG&tz=0&last=240

http://aprs.link/app/aprs/stations/weather-K2BIG

Looking at aprs.link, there are huge holes sin the data that I don’t see on findu.com:

temp-per-hour

My understanding is that APRS (and CWOP by extension) are “best effort” data sources, and will accept occasional missed observations as the cost of using them.

I personally know :blush: the author of the WeatherFlow UDP driver for weewx, and he is really curious what “log_raw_packets = True” shows is being received via UDP (another “best effort” protocol)…

3 Likes
27

I will log the packets and give upload the results in a day or so.

1 Like
28

@vreihen Here is my syslog for this morning. Wind and radiation data was missing from 719 AM to 819 AM. I included the raw packets received by CWOP for that period.Let me know if you want more data. I am going to keep logging for a while longer.

syslog.txt (1.2 MB)

CWOP Packets.txt (1.4 KB)

https://mesowest.utah.edu/cgi-bin/droman/meso_base_dyn.cgi?stn=C9009&unit=0&timetype=LOCAL

29

I’m going to ask @GaryFunk and @dan.gealt to check my math here.

The first thing that I did was grep all of the rapid_wind packets out of the syslog file. They are sent every 3 seconds (Sky battery wasting mode) or 15 seconds (Sky battery saver mode), and my understanding is that they are NOT cached for playback in the event that the Sky and Hub lose communications. It appears that you’re running in battery saver (15 second) mode.

grep rapid_wind syslog.txt

45%20PM

There’s a whole lot of rapid_wind packets missing between 7:11 and 7:47!

Second thing that I checked was the obs_sky packets, which are sent once per minute and are the only one that contains solar data. These ARE cached for playback when the Sky and Hub are having problems communicating.

grep obs_sky syslog.txt

11%20PM

The red box column on the left is the time that the packets were received via UDP, and the right box (imagine it longer) are the observation timestamps reported by the Sky/Hub. Notice how the right side increment by about 60 seconds, but the left side is all at the same time? It appears to me that the Sky was playing back buffered data because it was having issues communicating with the Hub.

The third thing that I checked was the obs_air packets, which are also sent once per minute by the Air and also subject to playback if the Air and Hub lose communications.

grep obs_air syslog.txt

14%20PM

Looks pretty solid to me, with packets coming in every 60 seconds and no playback.

My last check is to see what the hub_rssi (signal strength of Air/Sky as received by the Hub) is. The Air reports 0 because the function is not supported in the embedded firmware, but the Sky did not send status packets during that time window and was logging RSSI values between -81 and -83 (more negative = weaker signal).

grep hub_rssi syslog.txt

I don’t know what the typical noise floor is on 900 Mhz, but I suspect that -80 is probably the point where the signal is weak enough to be subject to interference. (Are 900 Mhz cordless phones and baby monitors still a thing?) If Gary and Dan concur with my diagnosis, my suggestion is to try moving the Hub closer to the Sky or maybe changing its orientation on your shelf.

You can see the RSSI of every sensor on the station status page of the WF web site. This one is a link to mine:

https://smartweather.weatherflow.com/settings/station/910/status

Let me know if you can get the Sky’s RSSI up (less negative) to -70, and if weewx is still dropping packets or playing back with this better signal…

2 Likes
30

Thanks @vreihen. Even since the firmware upgrade to v94 my wireless distance as been very limited. I have moved it closer to sky and air modules. I am getting between -50 to -60 RSSI. I will keep watching to see if it helps.

31

Good analysis @vreihen! Looks like the Air UDP data shows a pretty stable communication from the Air to the Hub and from the Hub to the network. The Sky sure looks like it was losing connection to the Hub and trying to backfill once it reconnected. I have had the same problem with an Air unit and mine showed all of the symptoms of a weak RSSI (also in the -80 to -90 range). I was able to correct my problem by changing the orientation of the Air with respect to the Hub (not a good answer for Sky, though). Once I got the RSSI up into the -70’s communications with the Hub has been pretty stable.

4 Likes