Showing posts with label WxService Updates. Show all posts
Showing posts with label WxService Updates. Show all posts

Friday, January 20, 2023

WxService Update Available

    WxMonitor ow4j230125

    • Switched to darker gray background for wind image display. Darker gray provides better contrast and readability.
    • Display wind direction when wind speed is zero. Users would like to know which way the wind vane is pointing even if the wind isn't blowing.

    Monday, February 21, 2022

    WxService Update Available

    WxService ow4j220221

    • Updated to OWAPI 1.2 (One-Wire API 64 bits)

    WxMonitor ow4j220221

    • Switched to default Java platform look & feel (from system L&F)
    System look & feel was too unpredictable between Windows, KDE and Gnome desktops. Using default Java makes it look the same everywhere (it looks like Java everywhere).

    Wednesday, September 22, 2021

    WxService Update Available

    WxMonitor ow4j210922

    • Modified Wind Image rendering for faster updates
    When WxMonitor is downloading the backlog of data from the previous 12 hours on startup, it animates the display so you can see what transpired while you were away. However, the Wind Image display takes quite a lot of resources to animate at the full incoming data rate, so I made it update at 10 frames per second. It still looks smooth and you can see everything. The full dataset still gets pushed through all the filters, so the highs and lows are accurately recorded. The goal is to get to real-time data display quicker.

    Monday, March 15, 2021

    WxService Update Available

    WxService ow4j210214

    • Updated to 64 bits OWAPI library by default
    • Java 11 LTS support
    • Single executable jar (all self-contained dependencies)
    Everything else is pretty much the same as it ever was... same as it ever was... because over the years, the code has just become pretty solid, and there's no reason to change it further.

    Sunday, July 22, 2018

    WxService Update Available

    WxService ow4j180316


    • Modified WxMonitor display to make the wind vector easier to read, and display peak wind speed as red dots, while the average speed is still a blue vector. The direction is now a white line on a gray background. 

    Wednesday, May 30, 2018

    WeatherBug Personal Weather Stations Phased Out

    WeatherBug was purchased by EarthNetworks, and the personal weather stations WeatherBug Backyard system has been phased out. 1-Wire Weather Service for Java has not deleted support for reporting in this format, but there is no longer any reason to attempt it.

    If your 1-Wire system is reporting errors while attempting to send weather data to http://data.backyard2.weatherbug.com/data/livedata.aspx, you can remove the weatherbug formatter from wxservice.formatter.task.names and apply your changes.

    For more information, see Changes to the WeatherBug Backyard/Earth Networks PWS Program, and What Happened to WeatherBug?

    1-Wire Weather Service for Java includes support for CWOP NOAA MADIS, so you can migrate your backyard reporting over there if you wish. Most of the default settings are already configured, so all you need to do is obtain a station ID as described here, and configure your station ID, latitude & longitude, and add the aprs formatter to the formatter task names.

    Changes to the WeatherBug Backyard/Earth Networks PWS ProgramChanges to the WeatherBug Backyard/Earth Networks PWS Program

    Sunday, December 10, 2017

    WxService Update Available

    WxService ow4j171209

    • Modified WxMonitor wind vector display to clean up a problem I've had since day one with 'crawly' wind direction display. The problem is, even when I retain precision and round properly, trying to display a short direction indicator line on the outer circle, the graphics resolution simply isn't good enough to draw a line with the proper slope and length. When I draw a line at the full radius, the problem goes away, because the resolution error is spread out along the full length of the line, instead of a short line segment. This is easiest to visualize if you imagine a two-pixel length line. The length and slope errors become overwhelming. When the line is thousands of pixels long, the length and slope errors are usually negligible. 
    • Changed the way WxMonitor displays UI updates. The monitor will now 'animate' each sensor update, instead of coalescing them. This improves the behavior for historical markers, such as the wind vector memory. It is also entertaining to watch the last 12 hours of data being animated when first starting WxMonitor. 
    • Modified the default command line behavior. The backlog default is now set to 12-hours, and the polling interval default is 5 seconds. If these values are acceptable to you, there's no need to specify anything on the startup command except for which weather server you want to connect to.

    Thursday, November 23, 2017

    WxService Update Available

    WxService ow4j171123

    • Simplified sensor data module, and moved domain-specific 'timeout' into the Weather Underground formatter, where it is actually needed. Basically code cleanup. 
    This change will not affect normal operation of anyone's weather station; I just wanted to do some code maintenance. 

    Wednesday, October 19, 2016

    WxService Update Available

    WxService ow4j161019

    • Fixed a problem with reporting to CWOP
    My weather server spontaneously started having problems reporting to cwop.aprs.net:14580, after about 4 years of continuous service. Evidently the CWOP servers have been made more "strict", and sloppy formatting is no longer tolerated. I implemented the CWOP protocol from this documentation, and I am pretty sure I followed it to the letter. Nevertheless, either this has changed quietly in the meantime, or I never had it right. Anyway, it's working now. 

    (Download...)

    Sunday, April 6, 2014

    WxService Update Available

    WxMonitor ow4j141330

    • Improved the barometer tool tip to display a more conversational forecast status string.

    Thursday, February 20, 2014

    WxService Update Available

    WxService ow4j140220

    • Fixed a glitch in the total rain accumulation calculation. The reset time wasn't being calculated reliably, causing total accumulation to continue into the next day (or other configured recording interval).

    Wednesday, February 19, 2014

    WxService Update Available

    WxService ow4j140219

    • Added support for WeatherBug publishing. To use the WeatherBug formatter, first register your station, and then follow the WxService setup instructions for expanding the zip file into your preferred location, and start WxMonitor. Switch to the Configuration tab and change weatherbug.formatter.password to the value you selected when you registered your Backyard weather station. Set weatherbug.formatter.station.id to the station ID that you received when you registered your station. Set weatherbug.formatter.station.number to the station number you received when you registered your station. Finally, add WeatherBug.formatter to wxservice.formatter.task.names (separated by semicolons), and click "Apply". The WeatherBug formatter transmits weather data to WeatherBug servers every five minutes (300000 msec) by default. You can change this by editing the weatherbug.formatter.interval property. One second is 1000 msec and one minute is 60000 msec.
    • Added code to explicitly set all temperature sensors to maximum resolution. This does not guarantee that any sensor will actually deliver higher resolution, and most 1-Wire devices are supposed to operate at maximum resolution by default. This is just an attempt to ensure the highest resolution.

    Monday, January 13, 2014

    WxService Stops Responding After Approx 17 Hours

    I noticed recently that WxService would stop responding after a WxMonitor client was connected for about 17 hours (or half that with two WxMonitor clients, etc.). It turns out that StAX XMLInputFactory cannot create more than 64000 readers in JDK 1.7.0_45. In other words, WxService can only respond to 64,000 update requests until the XML parser stops responding. At one request per second, a single WxMonitor makes about that many requests in about 17 hours. Fortunately, there is a work-around that should hold us until Oracle produces a fix for this problem.

    Using Notepad or other simple text editor, create a a file containing the following text:
    #Hack for JAXP00010001 error.
    jdk.xml.entityExpansionLimit=0
    and save it as C:Program Files/Java/jre7/lib/jaxp.properties (that is, place the file jaxp.properties in $JAVA_HOME/jre/lib).

    I will publish an update when this is no longer a problem.

    Update: The latest WxService includes a code change that uses a different thread pool implementation that seems more compatible with JAX-WS. By "more compatible", I mean "the one it uses internally by default". There were some features that I liked with the one I had been using, but locking up wasn't one of them, so there you go. If you're experiencing lockups, download the latest version

    Friday, October 4, 2013

    WxService Update Available

    WxMonitor ow4j130929

    • Modified the Wind Vector to show the wind direction in blue when the average wind speed is zero. The reason for this is that when there is no wind, the wind direction is meaningless. The wind vane will be pointing somewhere, but the direction is completely arbitrary. What's more, without the wind and its turbulence to buffet the wind vane and dither the data, the displayed direction will only be precise to the nearest compass point. When the average wind picks up above zero, the indicator turns red to indicate active status. 

    Wednesday, August 28, 2013

    WxService Update Available

    WxMonitor ow4j130826

    • Fixed discrepancy with event intervals when wind speed and wind direction both contribute to a single composite value (wind history).  
    • Changed wind history display defaults to 120000 msec. (two minutes) interval and 3600000 msec. (one hour) length; updated config.html to document this.  
    (Download...)

    Friday, August 9, 2013

    WxService Update Available

    WxMonitor ow4j130809

    • Widened Add Property dialog input field labels to display correctly on OpenJDK in Linux.

    WxService ow4j130809

    • Refactored WindVane averaging algorithm to use pre-calculated sin and cos values, since we know what they are all the time. Looks up the values based on one of the 16 cardinal compass points. 

    Thursday, August 8, 2013

    WxService Update Available

    WxMonitor ow4j130807

    • Made the WxMonitor animation speed configurable. The animation speed can be controlled by the configuration property wxmonitor.sensor.event.animation.interval. It is normally set for 38, or about one sensor event per minute (fast). You can set it as low as 1, or about 38 sensor events per minute (slow). 
    • Made the WxMonitor animation length configurable. The animation length can be set from 0 milliseconds (no event backlog) to 86,400,000 milliseconds (24 hours) as the last argument on the command line.

    WxService ow4j130807

    Consensus Averaging vs. Vector Averaging

    One Wire Weather Service for Java has been using Consensus Averaging to smooth wind vane data and increase device resolution, from its initial implementation several years ago. I thought it gave good results, although the algorithm proved difficult for me to analyze clearly.

    I was reviewing some weather data recently, and I noticed that the wind direction seemed to have slight but noticeable affinity for the sixteen primary compass points. Since nature doesn't do that, I had to suspect a problem with the hardware or software. I decided to start with the software, since that's easier to tweak. I began looking for angle averaging algorithms on the web, simply to get an idea of what kinds of solutions other people had come up with. There are several, some of them quite convoluted, home-brew algorithms. However, I found several similar examples of vector averaging. 

    Vector averaging entails converting each angle (wind compass heading from the wind vane) to a vector on the unit circle, and finding the x and y coordinates, averaging the coordinates, and taking the arc tangent, converting them back to an angle. The code to do this is actually very simple.

        /**
         * Calculates the average value by converting the angles to 
         * vectors on the unit circle and averaging the Cartesian 
         * coordinates. This avoids the 360~0 wrap-around at North. 
         * Math.atan2 returns the angle between -pi and pi. Therefore, 
         * we add tau to the result to force a positive angle, mod by
         * tau and convert to degrees.
         * @param data array of sensor data to average.
         * @return average directional value.
         */
        public double averageValue(double[] data) {
            int length = data.length;
            double sin = 0, cos = 0;
    
            for (int ii = 0; ii < length; ii++) {
                sin += Math.sin(data[ii]);
                cos += Math.cos(data[ii]);
            }
            double theta = Math.atan2(sin / length, cos / length);
    
            return Math.toDegrees((tau + theta) % tau);
        }
    

    where tau = 2π.

    One of the main reasons for averaging wind vane data is that the resolution of the wind vane itself is very coarse - only 16 compass points. But wind is turbulent, so the wind vane swings back and forth over several points. This turbulence dithers the data, so the average has a much higher resolution.

    I mentioned earlier that consensus averaging did increase the wind vane resolution, but some affinity remained. I had difficulty analyzing the algorithm, so it wasn't obvious to me how to modify it. But the vector averaging algorithm appears to exhibit no affinity; the output is completely de-correlated, without requiring any tweaks or tuning. It "just works".

    Vector averaging does have one potential problem: if two vectors are 180 degrees out of phase, they will cancel out, yielding an undefined angle. Fortunately, we have about 40 data points for each average sample. In order for the average to be zero, all of the vectors would have to be in opposition. That would be exceedingly unlikely for a wind vane that is supposed to point into the wind, even with very low air motion. The widest wind vane swing is about 90 degrees over relatively short time periods (e.g., a two minute averaging interval).

    Update: I found out from the authors of consensus averaging that the original implementation did not have the benefit of a software math library with floating point arithmetic and trigonometric functions. That makes all the difference in the world. Necessity is a mother ... ~ KU

    Sunday, July 28, 2013

    WxService Update Available

    WxMonitor ow4j130728

    • Made WxMonitor animate the backlog of sensor events missed since the last update. In the case of WxMonitor initial start-up, if WxService has been running for 24 hours or more, the past 24 hours' events will be animated. If the computer running WxMonitor has been sleeping or hibernating, the animation will cover the duration that the computer was offline, or 24 hours, whichever is lesser. It takes about 30 seconds to animate 24 hours worth of data, and it's entertaining and informative to watch.
    • Widened the buttons on the Configure tab and the Add Property dialog to provide more room when running on Open JDK under Linux, which uses boldface for the dialog font button labels. They didn't fit in the allotted space. A future update will also address a similar problem with the text field labels.

    WxService ow4j130728

    • Updated WxService to use OWAPI library version 1.11, which includes support for 64-bit 1-Wire drivers when installed on a 64-bit operating system. (Note: for some reason, the Dallas/Maxim OWAPI library is still tagged with version 1.11, so I'm not sure how one can tell which library is actually present by looking at the WxService logs.)

    Thursday, July 18, 2013

    WxService Update Available

    WxMonitor ow4j130713

    • Added a status bar message string "Downloading 24 hour sensor backlog from %s.", where %s is the URL of the WxService. This provides an indication that the initial backlog of sensor data has not yet been received. On a fast network, you may not get a chance to view this message. On a slow network (e.g., being served from a host that is running behind a DSL connection), it could take up to a minute to catch up.

    WxService ow4j130713

    • Changed getSensorData to return all data for the last 24 hours, if the time argument is 0. This is the case when WxMonitor has not received any prior data (as on startup). This change allows WxMonitor to accurately reflect the minimum and maximum readings, and fill all of the averaging buffers on startup. 
    This may seem like a step backwards in performance, but it is a major improvement in accuracy. I think accuracy beats the illusion of performance without the accuracy, every time.

    (Download...)