Weather Message 3.6 Beta 9

I have posted Weather Message 3.6 Beta 9 to the Weather Message website.  If you are a beta tester give this version a try.  I am thinking that this will be the last beta before the 3.6 public release.

WxByte/WxIngest/WxEmwin will not decode - Regional and Language Options

A user was having a difficult time trying to get WxEmwin to decode data.  It had worked, but stopped decoding the EMWIN stream.  The program was reporting 100% bad packets with header errors.

I got the user to run WxEmwin with the LOG option and reviewed the results.  The program was failing to decode the date in the EMWIN packet header.  The date looked ok to me.  I got the user to check their Regional and Language Options and discovered they were set to English(Australia).  The user was in the southern hemisphere.  That setting changes the internal date routines to expect the date in DD/MM/YYYY order.  The EMWIN header is in MM/DD/YYYY order.

I got the user to change their Regional and Language Options to English(United States) and WxEmwin started decoding data.  Previously, it worked for sometime at the beginning of the month, but failed after the 12th day. 

This issue affects all version 3.x releases of Weather Message.   It may also affect the version 2 programs - I did not test them for this problem.

I have made changes for the next release that will address this problem.  I reviewed all of the programs that validate dates.  If they are expecting the date in MM/DD/YYYY order, they will now use the culture settings for the United States to make those validations.

Thanks to Colin for his help in identifying this problem.

Integer Overflow Checks

I disabled integer overflow checks in Weather Message 3.6 Beta 8.  I don't recall seeing an integer overflow in the programs.  This change will reduce the cpu consumption for all programs to some degree.

With integer overflow checks enabled, the internal routines would check to see if an integer overflow occurred for each math operation on an integer.  That is simply not necessary in Weather Message.  There are lots of loops that use integers in Weather Message.  Checking for an overflow in those well behaved loops is not necessary.

EMWIN - Dual Ingesting (Serial and Internet) - Duplicate Graphic Files

I have several users that dual ingest.  They have the EMWIN serial ingest and internet ingest enabled at the same time.  One of those users noticed that they were getting duplicate graphic products.  After some research I discovered that the duplicate binary file routine was using local time instead of UTC.  That issue is now corrected.

The latest beta contains the fix for this problem.  Users that do not dual ingest may notice a decrease in the number of graphic files.  The EMWIN stream does output some duplicate graphics.

Introducing Grant Dark - Weather Message Sales

I want to introduce my associate Grant Dark.  Grant is the primary contact for sales and support for WxSiren Controller and emPager Pro.  He will also be helping Weather Message users.

I have worked with Grant for over 7 years.  He has a degree from Auburn University in agronomy.  How he became an acomplished computer technician, trainer and marketing person is another story.  He is married and lives on Lake Martin. 

Please join me in welcoming Grant to Weather Message Software.  If you are interested in WxSiren Controller or emPager Pro, email Grant directly at grant at wxmesg.com (replace the at with @).

WxSiren Controller Installed at Autauga County EMA

WxSiren Controller was installed Thursday February 18 at Autauga County EMA.  WxSiren will now be responsible for activating polygons based on polygons.  We performed tests to insure that the program operated properly.  We will run it through another round of tests in March.

Here is a link to the first Montgomery Advertiser article announcing the new system.  http://www.montgomeryadvertiser.com/apps/pbcs.dll/article?AID=2010100217040

Alarm Tab changes for Wind Speed

As part of the changes for setting wind speed and hail size, I made a couple of changes to make the Alarm tab cleaner and more informative.  The program will now use colors to indicate if a product as certain features.  Light-gray indicates that the feature is not available, a white background indicates it is available, while a light-green background indicates that the feature has been enabled.

Severe Thunderstorm - Wind Speed and Hail Size

The next beta release of Weather Message will support decoding the Wind Speed and Hail Size line in Severe Thunderstorm and Severe Weather Statements.  Forecast offices in the Central Region will start testing the "WIND...HAIL" line in SVR and SVS messages on March 1, 2010.

Only SVR and SVS products issued by Central Region forecast offices will contain the "WIND...HAIL" line.  If your forecast office is in the Central Region, you can use this option.  For other forecast offices, using this option will cause your alarm to not work.

Wind Speed will range from 60 miles-per-hour to 100 miles per hour.  Hail Size will range from .75 inches to 4.00 inches.  The alarm option will check for a match or greater speed.  (We could add variables for short messages if needed.)

This is a great addition.  I hope it will be implemented by all NWS forecast offices in 2011.

Note:  For everyone else, if you need this capability, you can use a regular expression to match wind speed embedded in the text.

WxEmwin - Pauses between packets - Revisited

Well sometimes you have to backup, punt and admit that you were wrong.  The explanation for pauses between some EMWIN Internet packets was a good definition.  It does happen as I explained in the previous post. 

The user that asked the question later sent me an example that I could not explain.  In his case, he was using WxEmwin to ingest an intermittent data stream create on a private network using WxRetran.  He setup WxRetran so that the stream was not sending data constantly like a regular EMWIN stream.  There was no fill file to make the stream constant.

After some research I found a problem in the buffering routines in WxEmwin.  When WxEmwin received a version 2 (compressed) packet, it kept that packet in the buffer until the next packet arrived or enough packets arrived to exceed the buffer processing point.  Once I saw it happen, I knew exactly what was causing the problem.

This issue would not really be noticed by regular EMWIN users.  When I added the option to disable/enable the version 2 (compressed) packet option to the program, the user changed the setting and noticed that the program no longer held packets in the buffer.  He just had to convince me that there was a problem.

So --- there was a good post about pauses between packets -- which lead to a real problem that was resolved in the last beta.

Tigertronics - ESP-96

A couple of my users have been communicating with Tigertronics about the upcoming EMWIN transition. They have been asking Tigertronics if they plan to provide a new receiver that is compatible with the EMWIN-N signal.

Based on the last information that I received, Tigertronics is evaluating whether to develop a new receiver. At this time, they do not have a receiver in development. In no case will one be available by April.

Users on the West coast will be able to use their existing receivers until the West coast satellite is decommissioned at the end of 2011. The East coast users that can receive the West coast satellite can continue to use their current receive system until the end of 2011.

If you have receive equipment that is not compatible with the EMWIN-N signal, you may want to consider repositioning your dish to see if you can receive the West coast signal.

April 26, 2010 --- GOES East will transition to EMWIN-N

From the EMWIN Transition page:  http://www.weather.gov/emwin/transition.htm

There are currently two GOES-N series satellites, GOES 13 and 14 in orbit and awaiting full time operations. Once they are placed into service the EMWIN-N broadcast will replace the current legacy broadcast. In order to receive and demodulate the EMWIN-N broadcast all users with legacy EMWIN systems will need to obtain EMWIN-N capable systems.

Although subject to change, the current plans are for:

• GOES 13 to replace GOES 12 (East) on or around April 26, 2010
• GOES 14 to replace GOES 11 (West) in December 2011

After GOES 13 becomes operational, GOES 12 will be moved to 60 degrees west to help support the Caribbean and South America. We are attempting to have the EMWIN-I 9.6 kbps signal remain on the GOES 12 satellite in order to ease the transition for users.

The transition could occur earlier due to premature failure of one or both of the current GOES satellites. All users should consider migrating to EMWIN-N capable systems. Please see the vendor page on the EMWIN website. Anyone with an EMWIN-N system can try out the broadcast by using GOES 14 satellite, which is providing a test broadcast.

Why the transition to EMWIN-N:

Changes in the next series of GOES satellites, the GOES-N thru P constellation, have necessitated development of EMWIN-N. Sometime before 2011 the current GOES satellites will be removed from operation and will be replaced by the new series. This will allow for the use of improved technologies, but all current EMWIN users will need to migrate due to frequency, power and modulation changes.

Coming Improvements Include:

• Data rate is doubled to 19.2 Kbps - More data!
• Forward error correction - Greater reliability
• Increased use of compression - More data!
• Enhanced data stream - Including regional Nexrad images
• Dedicated transponder
• No eclipse seasons

WxEmwin - Internet Ingest - Pauses between some packets

One of my users asked an interesting question today about WxEmwin's Internet ingest engine.  The user asked why there were pauses between some of the packets.  The user noted that data was being received ok, but it looked like there was some delay for some packets.

At 9600 baud, the current EMWIN data rate, one packet should be received about every second.  If the ingest engine is receiving a version 2 packet, the time between the packets could be longer.  A compressed packet increases the time between packets.

There are also other forces at work.  The TCP/IP subsystem in Windows uses the Nagle algorithm to improve the efficiency of the network by reducing the number of packets sent.  See Wikipedia's definition.

Windows may combine shorter packets into one larger packet before it is transmitted.  This act increases the efficiency of the network, but does cause small delays in packets.  The maximum transmission unit (MTU) for ethernet is 1500 bytes.  See Wikipedia.  This number could be less depending on the configuration of the network. 

A version 1 EMWIN packet contains 1106 bytes.  This number is less than a MTU of 1500 bytes.  Because of this windows could add additional bytes from the next EMWIN packet to reach the MTU support by the local network.  If the MTU is smaller it is possible that it could take multiple TCP/IP packets to transmit one version 1 EMWIN packet.

For version 2 EMWIN packets, this phenomena is more pronounced.  Version 2 packets are variable length.  This means that windows could possibly combine one or more packets into one larger packet before it is transmitted.

Regardless of whether packets are combined, WxEmwin's Internet ingest code will process the received packets properly.  You may simply notice some pauses in the status window.

Note:  The next release of WxBBSrvr will disable the Nagle algorithm so that I can evaluate the effect on the received data.

GOES 13 scheduled to replace GOES 12 on April 14, 2010

From NESDIS: GOES 13 is scheduled to replace GOES 12 on April 14, 2010.  See this link for more information:
 http://www.ssd.noaa.gov/PS/SATS/SPBULL/MSG0261654.01.txt

This change will have a big impact on EMWIN users.  GOES 13 will transition the EMWIN data stream from 9600 baud to 19200 baud.  This will affect anyone receiving data from the GOES East satellite. 

When the transition occurs, if you do not have equipment capable of receiving the new EMWIN-N signal, you will be required to reposition your dish to the GOES West satellite.

You can watch for update messages on the Satellite Information website:  http://www.ssd.noaa.gov/PS/SATS/