The realtime file

[william]

I have a WMR 200A WS and have created a graphics program that uses the Cumulus text file "realtime" for its data input. The program assists small planes to land by calculating things like preferred runway, head and side wind and alarms etc. The problem is if there is loss of data from the WS, the realtime file time/date stamp continues to update with the last record attached. This stamp should reflect when the last valid record was sent which would allow me to time my program out. An easier way of doing it would be to write a NULL character into the realtime file when this loss of data occurs so my program knows there is no valid data.

[beteljuice]

You must be talking about the server file time stamp, you should be checking the first field within realtime.txt which is the record timestamp !

[steve]

That's how Cumulus works in general. Loss of communication for any length of time was not an issue for me, so the simplest way to handle it was to reuse the last data that was received. It's possible that at some point I'll write the code to handle it in a different way.

[william]

You must be talking about the server file time stamp, you should be checking the first field within realtime.txt which is the record timestamp !

The first field is the date, the second field is the time which does not tell me when the data stopped. With the WS unplugged the Cumulus program just keeps writing the last file with a new time. My program views this as new data which it is not. As a pilot maybe trying to land, this could be somewhat catastrophic. A better format would be the exact last file as it occured just before the data interruption, ie, with NO updating date or time.

I managed to stop Cumulus sending data to the realtime file after I pull the plug to stop data by setting the "restart if data stops" under Station Configuration. This caused my program to time out because the last entry to realtime was not being updated. This took a couple of minutes.

I have not tested the effects of a sensor dropping out on the positioning of fields in realtime yet. Anyone know?

If anyone is interested in this project I can send them a zip file with the executable, "aws_display". I intend to eventually supply this program along with the text to voice program, AdvisoryList" for small planes flying in uncontrolled air space but only when all the "I" are dotted and the "T" are crossed.

[steve]

As you will know, the WMR200 has separate transmitters for each sensor, so it is possible for one sensor to stop transmitting but not the others. So some of the data would continue to update correctly, and the timestamp could correctly change. So some other indication (such as a 'null' data value for each affected value) would be required. Perhaps one day I will add this. If all data stops updating, e.g. the console stops sending data for some reason, Cumulus has two settings which will cause it to restart - "Restart if unplugged" and "Restart if data stops". If after restarting, no data is received, then Cumulus will no longer update the realtime.txt file, and manual intervention will be required to correct the fault with the console, and then restart Cumulus to get it to connect again. In addition, there is the <#DataStopped> web tag, which you could use to detect the latter situation, without causing Cumulus to restart.

Regarding the "somewhat catastrophic" consequences for pilots trying to land, it's clear that an Oregon Scientific weather station, and free software which was written for hobbyist meteorological purposes and not aviation purposes, is not suitable for depending on in situations where lives are at risk, such as guiding planes in to land. I'm quite alarmed by your use of the phrase "somewhat catastrophic" in relation to your use of Cumulus, and for the record I will state here that I do not approve of your apparent use of Cumulus in this way, and I will not be responsible for the consequences.

[william]

You must be talking about the server file time stamp, you should be checking the first field within realtime.txt which is the record timestamp !

The first field is the date, the second field is the time which does not tell me when the data stopped. With the WS unplugged the Cumulus program just keeps writing the last file with a new time. My program views this as new data which it is not. As a pilot maybe trying to land, this could be somewhat catastrophic. A better format would be the exact last file as it occured just before the data interruption, ie, with NO updating date or time.

Point taken about the weather station being used to land planes. This is orientated towards farmers, crop dusters and small private airports. Some use a wind sock at present. I have also let Airservices Australia know about the project. I worked for AA for 15 years, some of that time doing this very thing.

If one sensor goes out the best way for this file to behave is to have the field filled with say "XXX" indicating a missing field. The NULL character cannot be use as it represents end of file or end of string.

We used identifiers at AA, eg, WS:05 for wind speed. This way your program can look for WS: and check for a valid field over it known length. This allows fields to be in any position in the file and the number of fields is unimportant, allowing NEW variables to be introduced easily. Its is also much easier to interpret or read.