meteohub.de

Update to Meteohub V4.9o (NSLU2, x86, SheevaPlug, DreamPlug, iConnect, DC01) brings these features:

• Fixes a bug on DC01 that prevents from changing HTTP password
• Fixes a bug that prevents to make sure cron scheduler operates in user defined timezone. You have to press "save" on "settings" page in order to force cron scheduler into defined time zone.
• Experimental support for Davis Envoy8x. Just live data (every 5 sec) for station types ISS Vue, ISS Pro 2, ISS Pro 2 Plus, Wind, Rain, Temp, Temp/Hum and Leaf/Soil.

Update Link: http://www.meteohub.de/files/update-v4.9o.upd

Boris,

CWOP Altimeter is still broken in this version. Of interest is the one test report I sent, CWOP received the local console pressure and not Altimeter or SLP. Boris, if you would rather work directly via email on this minor issue as to prevent clogging up the message board, I am happy to do so. I doubt the majority of the readers here care about this issue.

There appears to be one other CWOP issue that may NOT be related to anything in Meteohub, but it is worth mentioning. I have noticed over the past several days very unreliable uploading of data to CWOP. Looking at the raw packet stream, it appears that CWOP servers are sporadically rejecting (more likely ignoring) some weather stations for some reason. Part of the reason for this may be related to this news article below.

Source: http://wxqa.com/news.html
Sep 20, 2012 - For many years, CWOP and APRS servers operated at Texas A&M and supplied reliable and valuable service to the CWOP community. Those servers were deactivated at 1800z on Sept 12 because Gerry Creager (AP009), who kept them going, moved to a new position at the University of Oklahoma. Gerry hopes to be able to provide the same service to the CWOP community from a new location in the near future. In addition to operating CWOP1, CWOP4, CWOP Aggregator and findU backup, Gerry also operated first.aprs.net and firenet.us. When either of these links becomes active, the CWOP1 server will follow close behind. CWOP1 availability can also be checked here.

Effectively, what this means is that of the four dedicated CWOP servers that were in active use, only two servers (CWOP2 and CWOP3) remain operational.

Why this is important is that in order for me to check the proper function of the CWOP Altimeter, I have to reconfigure my station to transmit data via the CWOP checkbox. When I select this option, I do not always see my raw packets on the network, regardless of the upload frequency I select. If raw data isnt making it into CWOP, then I cant tell if adjustments are working correctly. I was lucky this morning that one of my packet streams made it to the CWOP server so that I could see that the CWOP Altimeter was still broken. One packet made it to CWOP out of the four that were sent over a 20 minute window.

Again, I am not entirely sure what is going on (be it CWOP servers or something else), but I do see lots of unreliability of late when selecting CWOP as a target server instead of using the APRS servers.

Yes, please lets sort out the altimeter thing via email. When I get your finding right, Meteohub reports console pressure instead of altimeter or SLP. I will check this.

The CWOP-Calculation seems to have changed, indeed. Please take a look at this Graph
http://weather.gladstonefamily.net/qcha ... 06637&td=c,
compared to an official station in 1,5 km distance. With the Update to 4.9o the pressure drops immediatly around 75mB

I changed from SLP to Altimeter for CWOP.
the value transmitted to CWOP is the same that is dislayed
via "meteograph.cgi?text=actual_thb0_altimeter_hpa".
Data looks pretty close to SLP on low altitudes.

Non-CWOP APRS packets still get SLP.

Currently Meteohub uses these CWOP URLs:
#define CWOPURL0 "cwop.aprs.net"
#define CWOPURL1 "cwop1.tamu.edu"
#define CWOPURL2 "cwop2.tamu.edu"
#define CWOPURL3 "cwop.fuller.net"
#define CWOPURL4 "sip.tssg.org"
Isn't that the rigth list anymore?

Boris,

Recently, I have experienced what appeared to be a dropped packet issue. I only discovered this issue because I've been troubleshooting the Altimeter settings with you and began noticing that after changing servers between CWOP and APRS, I would sometimes lose packets. This left me wondering if I had done something wrong or if perhaps something was broken during upgrading to various builds of meteohub.

I've been in contact with the people that understand the working of the APRS and CWOP servers via the WXQC mailing list in order to try and sort my problem out. After sharing the raw data I was generating and describing the problems I was seeing, discussions revealed that there are a few issues at play that are causing problems not only for me as a meteohub user but also a moderate percentage of other CWOP and APRS users using other weather clients.

One problem looks to be related to the recent shutdown of several servers located in Texas (this is the news article I posted a few days back). The outcome of this means the list you have for cwop.aprs.net is no longer accurate.

The last two remaining servers for CWOP are

CWOP-2 cwop.fuller.net
CWOP-3 cwop.tssg.org

The other servers in your list are no longer valid. At some point in the future, one or two of the CWOP servers may return, but it is unknown if and when that may happen. If it does happen, they likely will not have the same name. You will probably want to modify your CWOP list to reflect these changes.

There is another issue that is related to DNS querries and exactly how meteohub and other weather clients perform this task. It is quite lengthy for posting here so I will send you a private email outlining the discussions I've had so you can see the issues that were identified.

I'll send you the private email shortly.

Best regards,
Dave

Can I get an update on the status of the CWOP bug. I'm having the same issue. I just got done analyzing my packet data and was ready to add an offset, when I found these posts. Thanks for any information.

Chuck

Chuck,

Which issue are you talking about ... is it an incorrect barometric pressure reading being reported when selecting CWOP as the weather network or is it that your raw packets are not being seen when sending data to CWOP?

For the first issue, I am working with Boris on figuring out why it appears console pressure is being sent to CWOP instead of altimeter.

For the second issue, you should know that two of the four CWOP servers are no longer available. Various weather clients are stumbling when they try to send weather data as they encounter dead servers. Some client programs seen to deal with this problem better than others. I know that Boris has updated the server list in Meteohub to only use the two live servers but when this release will come out for the general public I cant say. I would expect very soon.

How to deal with both of these issues depends on if you are a ham radio operator or not. I will assume you are not a ham as that is the vast majority of users.

As a workaround for non hams experiencing the first issue...
Deselect CWOP as the weather network to use and instead select APRS as the weather network. In the server field for APRS, type cwop.aprs.net:14580#-1 This will bypass the CWOP altimeter algorithm and allow you to transmit pressure readings...the exact pressure readings you transmit will depend on what sensor you are using for pressure and how you have configured your console. After you have entered the above weather network information in meteohub, save the page. Now open up a web browser and go to APRS.FI and enter your weather station id in the "track callsign" box in the upper right hand corner. When your station is located on the map, click on it and in the box that pops up, towards the bottom, select "start tracking". After selecting this, on the right hand side of the main screen select "raw packets". You can now monitor your raw data as it is seen on the network before its ingested by MADIS. Look at the pressure data closely and make sure it is sensical. If any adjustments need to be made, you can do so in your weather console or in meteohub as a virtual sensor adjustment or as a sensor calibration adjustment.

As a workaround for non hams experiencing the second issue in meteohub, deselect CWOP as the weather network to use and instead select APRS as the weather network. In the server field for APRS, type cwop.tssg.org:14580#-1. Doing this hard codes your data as going to one server only. You will want to keep your eyes open for meteohub updates and update as soon as possible as its not the best idea to hard code your data to one server in this way. Proper behavior has the servers you use "rotate" around to distribute the load properly and this bypasses that ability. Once the update is out and things are working correctly, you will want to go back to using CWOP by unchecking the APRS box and selecting the CWOP box. Be aware that as a CWOP member using the CWOP network in meteohub, you also have the altimeter problem as described above but you may not know it. A check of your data on MesoWest or the NWS will show this. It may make sense for you to read the workaround issue above and see if that helps in the short term.

As a workaround for hams experiencing issue two, you have other options. As a ham and a CWOP member, you have the option of using either CWOP or the APRS dedicated servers in meteohub. The CWOP servers are open to the public for non ham related weather transmission and this data makes it way into MADIS via the FINDU APRS packet network transmission route. But as a ham you also have access to the regulated APRS servers assuming you have a valid amateur radio callsign and the proper access codes to use them. Data sent by either the public CWOP servers or the private APRS servers is seen by FINDU and makes it way into the MADIS system. Since you have the option and other non hams do not, proper amateur etiquette dictates that you should limit your wx transmission to the APRS servers, leaving the public CWOP servers open for non ham use. As a ham CWOP member, your server access should be routed through APRS servers by selecting this in meteohub and making sure CWOP is not checked. In the server field you should select rotate.aprs2.net:14580#XXXXX or rotate.aprs.net:14580#XXXXX where XXXXX is the access code you were given when signing up for CWOP access. If you are in North America, noam.aprs2.net:14580#XXXXX probably makes more sense as that limits you to NA servers in the Tier 2 network. LIkewise European hams would probably be better served using their regional tier 2 servers at euro.aprs2.net:14580#XXXXX. Our Aussie friends can find relief using aunz.aprs2.net:14580#XXXXX

As a workaround for hams experiencing issue one, as of right now I've configured metohub to use a virutal sensor and upload that virutual barometric sensor to CWOP using the APRS servers as described above. I've gone into some detail in other posts about how to use AWK code to create a virtual sensor in meteohub that calculates altimeter. I'm happy to share that should anybody need it but you can also search for it easily enough too.

Dave

I apologize. I didn't realize there were two different issues. I am asking about the issue related to incorrect pressure readings being received by CWOP. I noticed that I started receiving barometric pressure error messages after upgrading to 4.9p. I only started looking into it this weekend. I will review your work around details. Thank you for providing them. (My example of the issue is attached)

Chuck

Yes, it appears you have the first issue with the wrong pressure being transmitted to CWOP.

I just found a bug in the code that sometimes prevents from getting the right sensor altitude. This is a bit more complicated as it sounds because Meteohub can feed many stations all with different altitudes.

Please give this update a try (www.meteohub.de/files/update-v4.9q.upd) by downloading, placing into the Meteohub PC network share "/public/transfer/". Then install via Meteohub webinterface "update (file)" by giving the path "/data/transfer/..."

Boris, I think you've got the altimeter fixed. Here are my actuals inside Meteohub.
actual_system_version_text 4.9q
actual_system_version_num 49
actual_system_build_num 1187
actual_localdate2 30.09.2012 17:32:38
actual_thb0_press_hpa 917.6
actual_thb0_press_psi 13.31
actual_thb0_press_mmhg 688.2
actual_thb0_press_inhg 27.10
actual_thb0_sealevel_hpa 1014.8
actual_thb0_sealevel_psi 14.72
actual_thb0_sealevel_mmhg 761.1
actual_thb0_sealevel_inhg 29.97
actual_thb0_altimeter_hpa 1013.0
actual_thb0_altimeter_psi 14.69
actual_thb0_altimeter_mmhg 759.7
actual_thb0_altimeter_inhg 29.91
With a console pressure of 917.6 hpa and an altitude of 826 meters, calculated Altimeter should be 1012.96. Meteohub reports 1013.0...nice.

Checking raw packets and pressure data using APRS.FI, I see...
2012-10-01 00:32:04 UTC: N5XL>APRS,TCPIP*,qAC,T2LAX:@010032z3348.73N/11147.18W_315/006g013t094r000p000P000b10130h14eMH49
2012-10-01 00:42:04 UTC: N5XL>APRS,TCPIP*,qAC,T2USANW:@010042z3348.73N/11147.18W_270/006g013t093r000p000P000b10132h14eMH49
From this, I can see the raw packets being transmitted when APRS is selected and Altimeter is selected is correctly showing Altimeter (entries with T2 in them are actually APRS tier 2 servers)...nice.

Switching over to the CWOP servers and checking the raw packets, I see...
2012-10-01 00:52:06 UTC: N5XL>APRS,TCPXX*,qAX,CWOP-3:@010052z3348.73N/11147.18W_270/002g012t093r000p000P000b10137h15eMH49
2012-10-01 01:02:05 UTC: N5XL>APRS,TCPXX*,qAX,CWOP-2:@010102z3348.73N/11147.18W_225/003g009t092r000p000P000b10140h15eMH49
As console pressure has risen to 918.4 and 918.7 hpa in the time its taken me to gather the data, calculated altimeter should now be 1013.82 and 1014.15. Meteohub reports 1013.7 and 1014.0. This is seen in the raw packets and Altimeter is correctly expressed when using CWOP servers...nice.

The final check is to see if the data is making it to MesoWest. Correctly showing values in MesoWest means that all stages of this process are working as they should.
Time Mesowest Meteohub
17:32 1013.00 vs 1013.0
17:42 1013.21 vs 1013.2
17:52 1013.68 vs 1013.7
18:02 1013.99 vs 1014.0
This is exactly as it should be and confirms CWOP receives Altimeter properly...nice.

This emergency release of 4.9q build 1187 looks good to go as it corrects the barometric pressure issue and looks to have also addressed the CWOP server connection issue as well. Nice job.

For those of you that update to 4.9q, be advised that you will want to check the weather network page in meteohub as there are new options available that were not available with older versions of meteohub. With 4.9q, next to the CWOP weather network, you now have the option of selecting different barometric pressure readings to be sent to CWOP. The correct barometric pressure to send to CWOP is ALTIMETER and not SLP (Sea Level Pressure). You will also want to make sure that your weather station elevation is accurate as meteohub uses this number to calculate both Altimeter and SLP. The correct elevation to use for your station is where your barometric pressure sensor is located. Typically, the pressure sensor is located in the display console and not with the other outside sensors. If your console is located on the second floor of your home, simply add the height of the console to the base elevation you see in listed in topographic maps for your precise location.

Amateur radio operators who are CWOP members should use the APRS networks to help alleviate traffic congestion on CWOP leaving them open for the general public to use. As a ham, the correct servers to use are rotate.aprs.net:14580#XXXXX or rotate.aprs2.net:14580#XXXXX, where XXXXX is the access code you were given when signing up for CWOP as a ham. To utilize these APRS servers, you need an access code and a valid amateur radio license. You may have received this code when you signed up for CWOP. If you did not, you can request a code. This access code is only necessary for hams using the APRS or APRS tier2 servers...if you do not have an amateur radio license, you dont need a code and you use the CWOP servers instead of the APRS servers. Hams should refer to the CWOP FAQ "servers to use" page for more information on how to obtain the code. http://www.wxqa.com/servers2use.html

One last item for hams using the tier 2 APRS servers. Instead of using rotate.aprs2.net:14580#XXXXX as suggested, it would be a much better use of bandwidth to limit your traffic to the regional tier 2 servers by using the following servers...

North American hams using T2 servers should use noam.aprs2.net:14580#XXXXX
European hams using T2 servers should use euro.aprs2.net:14580#XXXXX
AU/NZ hams using T2 servers should use aunz.aprs2.net:14580#XXXXX

While this is not specifically called out in the CWOP faq, as a amateur radio operator you have an obligation to be held to a higher standard of operation and bandwidth conservation is very much part of that training. Hopefully, these regional T2 servers will make it into future revisions of the CWOP FAQ.

Hope this helps...

Dave
N5XL

Hello Boris,
when you add in the software and some enhancements, such as summarization rain? -> viewtopic.php?f=13&t=8062

Or automatic data backup and storage options directly on FTP in a certain interval. It's done via rsync, but ordinary people as this and I can not adjust.

They are pretty important things