cloudy cloudy

Author Topic: MADIS Data Caution Flags  (Read 3275 times)

0 Members and 1 Guest are viewing this topic.

Offline AR567/KC9DBE

  • Posts: 17
MADIS Data Caution Flags
« on: November 30, 2004, 02:59:48 PM »
I'm new to this and am still in the testing phase of new software/hardware/data transmission products and as such have only been running a system for about 2 week.  I had an issue arise this morning and followed these troubleshooting steps.  I decided to post the whole thing for two reasons.

1 To elicit an idea on how to streamline the troubleshooting process and
2. For any other newbies out there someday that might use it as a boilerplate for troubleshooting issues on their own systems.

Comment and suggestions are welcome but please be gentle - my heart isn't nearly as strong as it once was :).

David C. KC9DBE/AR567

=========================
I've been getting flagged as caution by MADIS since last Wednesday.  Initially, I didn't think much of it since my neighbor's boyfriend parked his great big huge metal semi tractor between my ISS transmitter and my weather station rec'v (Davis Vantage Pro Wireless) and it always seems to cut my reception down from about 98% to about 35-40% no matter what I do short of throwing rocks with messages back and forth :).  Then last night I got another automated message that listed just about every data packet as suspect - even those after they left in the truck at 0430 hrs (why can't they behave like normal people and leave at 9 AM without waking up the rest of us I wonder).

Anyway - I looked at the last hours QC messages and it's till marking every data package with a caution flag.

  *********************************************************************************
  * 30-NOV-2004 *   SLP    * POT TEMP *  DEW PNT *    DD    *    FF    *   ALT    *
  *  1200 UTC   *   (MB)   * (DEG F)  *  (DEG F) *   (DEG)  *  (KNTS)  *   (MB)   *
  *********************************************************************************
  * TOTAL OBS   *      0   *   6651   *   6149   *   6669   *   6669   *   6341   *
  *   QST OBS   *      0   *    330   *    345   *     62   *     62   *   1853   *
  * PERCENT QST *   0.00   *   4.96   *   5.61   *   0.93   *   0.93   *  29.22   *
  *********************************************************************************
  *    AR567    *          *          *          *   120    *   -21    *  16(   2)*


As you can see it's concerned with wind direction/speed - which doesn't flag a possible error in MADIS as I remember from reading the docs - what is a concern is that 16 error over in the ALT column.  Next I went over to UoU to use the MesoWest interface to check the station.

Tabular Listing: November 29, 2004 - 7:55 through November 30, 2004 - 7:55 CST Time(CST) Temperature Dew Relative Wind Wind Wind Quality Pressure Sea Level Altimeter
  Point Humidity Speed Gust Direction control  Pressure 
 ° F ° F %  mph  mph    in  in  in
7:30 37.0 34.1 89 26 31 WNW Caution 28.84 29.65 29.62
7:15 37.0 34.1 89 26 31 WNW Caution 28.84 29.65 29.62
7:00 37.0 34.1 89 26 31 WNW Caution 28.84 29.65 29.62
6:45 37.0 34.1 89 26 31 WNW Caution 28.84 29.65 29.62
6:30 37.0 34.1 89 26 31 WNW Caution 28.84 29.65 29.62
6:15 37.0 34.1 89 26 31 WNW Caution 28.84 29.65 29.62



Okay - this is bad - the graphs look like those flatlines of ECG's in those bad medical drama's on TV - this is very bad.  Wait a minute - now this is interesting, the data is exactly the same for every update.  Bad feed from FindU or bad feed to FindU? (Jumping on preverbial horse to thunder off to our next troubleshooting stop).

 

Well now this isn't looking promising at all - but on the up side it's beginning to look like a data reporting error vs a hardware error.  The graphs (shown above) of Temp/Humdity and Wind/Gusts both are flatlined for the last couple days (grumbling sound about boyfriends/semis/proper parking spaces).  Time for a look at the raw data being recieved by FindU

time (UTC) temp
F wind
direction  speed
MPH gust
MPH rain 1hr
in rain 24hr
in rain mn
in humidity
% barometer
mb
20041130140612  37  286  26.0  31.0 0.01 0.55 0.55 89 1003.0
20041130140111  37  286  26.0  31.0 0.01 0.55 0.55 89 1003.0
20041130135610  37  286  26.0  31.0 0.01 0.55 0.55 89 1003.0
20041130135111  37  286  26.0  31.0 0.01 0.55 0.55 89 1003.0
20041130134610  37  286  26.0  31.0 0.01 0.55 0.55 89 1003.0
20041130134111  37  286  26.0  31.0 0.01 0.55 0.55 89 1003.0
20041130133610  37  286  26.0  31.0 0.01 0.55 0.55 89 1003.0
20041130133111  37  286  26.0  31.0 0.01 0.55 0.55 89 1003.0
20041130132610  37  286  26.0  31.0 0.01 0.55 0.55 89 1003.0
20041130132111  37  286  26.0  31.0 0.01 0.55 0.55 89 1003.0
20041130131610  37  286  26.0  31.0 0.01 0.55 0.55 89 1003.0
20041130131110  37  286  26.0  31.0 0.01 0.55 0.55 89 1003.0


There it is big as life - FindU's data feed is bad.  The question is why?  The Weather Display (testing a client/server configuration) server is updating because I can see the regular updates in my client which means that data is flowing from the Davis station to the PC and from the PC to Weather Display.  Next simplist thing is to reboot the WD Server and see if it resets the APRS upload/generation module.  But first since I feed data to Weather Underground let's see what kind of data they are recieving.


Time,TemperatureF,DewpointF,PressureIn,WindDirection,WindDirectionDegrees,WindSpeedMPH,WindSpeedGustMPH,Humidity,HourlyPrecipIn,Conditions,Clouds,dailyrainin,SoftwareType,
2004-11-30 00:00:08,35.8,34.0,30.220,ENE,68,2,5,93,0.00,OVC,OVC,0.00,WeatherDisplay:10.19,
2004-11-30 00:05:08,35.8,34.0,30.210,ENE,68,2,5,93,0.00,OVC,OVC,0.00,WeatherDisplay:10.19,
2004-11-30 00:10:08,35.8,34.0,30.210,ENE,65,3,5,93,0.00,OVC,OVC,0.00,WeatherDisplay:10.19,
2004-11-30 00:15:08,35.8,34.0,30.210,NE,53,5,5,93,0.00,OVC,OVC,0.00,WeatherDisplay:10.19,
2004-11-30 00:20:08,35.8,34.0,30.210,NE,45,6,8,93,0.00,OVC,OVC,0.00,WeatherDisplay:10.19,


Hummm....well it just looks like the CWOP/APRS feed is getting data that isn't updating for some reason.

Well after a reboot of the system it still was sending the same data so we went back and unchanged all the changes we made two nights ago.  I was creating a APRS output file to send over to my APRS machine but was never able to get WinAPRS to accept it as valid so I turned that off.  Once I turned it back on data started to update correctly again. #-o  I think we can confidently chalk this one up to a operator headspace and timing configuration error.  Issue resolved - time invested about an hour.