Emwin Software Defined Receiver

Changes have been made to WxByte to allow it to connect to the Emwin Software Defined Receiver's demodulator TCP/IP output data stream. This eliminates the need to use two serial ports.

Status - Update

I still have two pending issues that need to be resolved before version 3.0 can be released. I have a strange tcp/ip problem in Weather Message Server and Byte Blaster Server. The problem occurs with the internal tcp/ip buffer fills. This causes the applications to hang until the offending client disconnects.

The tcp/ip vendor sent me a correction, however, it appears to still have this problem under different circumstances. I have sent another email to them regarding this problem.

A couple of users have reported a strange GDI+ error with WxIngest. I have temporarily removed the sliding data window to see if this resolves the issue.

As soon as these two issues are addressed, I'll go ahead and release 3.0.

I am going to try and release 2.10 as the public release for Weather Message Classic. There have been several changes over the year and it needs to be version that new users are downloading.

Status

This has been a busy week for me. I have had meetings every night. I will catch up my email replies tonight.

Weather Message 3.0 Beta C has been running on my production server all week. I saw one problem that I am trying to address with my tcp/ip vendor. Other than that, I think we are about ready for a software release. I will do some more clean up this weekend and start getting the website for the software release.

Thanks to all who have helped with the beta version.

ByteBlaster Server Notes

I number of changes have been made to the 3.0 ByteBlaster Server. It now requires that clients send a verification packet once. The original byteblaster server required that clients send a verification packet once every 12 minutes. There is no need for that requirement and it has now been dropped.

I have noticed a number of unusual disconnects in the byteblaster server log. After alot of research and some changes, I have found that some clients are not sending an identification / verification packet. If no verification packet is received, the server will disconnect the client after 12 minutes.

The verification packet should be sent right after connection and once every 12 minutes. The format of this packet is:
ByteBlast Client|NM-email@server.com|V1

Replace email@server.com with the appropriate email address. The verification packet should be Xor'd with hex FF before sending.

TCP/IP Server Component Update

I did discover a bug in my tcp/ip vendor's component. I had to send them a sample application to prove the problem. They got me a fix on Friday and I got it installed in all of the programs Friday night. I am still testing the changes.

TCP/IP Server Component Issue

I have been watching the new 3.0 Byte Blaster Server run for a week. I suspected that something was not exactly right. The question was it a me problem or something else. After 5 hours or research, I believe that I found a problem with my TCP/IP Vendor's IP Component.

When the buffer completely fills, the component should tell me that it is full so that I can disconnect the client or perform other tasks. It appears that is just waits for the buffer to empty, which is not correct. I am not sure if this is a problem in their latest release or if it has been there all along.

I have sent an email asking about this issue. They don't respond to emails on the weekends, so I will have to wait until Monday for a reply.

This effects Weather Message Server and the ByteBlaster Server software. It is not a big issue for Weather Message Server, was we always want to send data to the clients. For the ByteBlaster Server, we want to disconnect clients that have full buffers.

I will most likely go ahead and post a beta tonight. When a solution to the buffer full problem is identified, I'll refresh the beta.

Received Block Monitor

I have been reading about graphics and GDI+. GDI+ is the new graphics drawing include in the .Net 2.0 framework. This sparked my interest in creating a simple block monitor for the Serial and Internet ingest engines. Here is a picture of the block monitor.

Each block represents a 1024 byte packet for the incoming file. Green blocks show good packets, yellow for packets not received and red for bad packets.

You can activate this monitor by clicking on the Green Led to the right of the file name. For WxByte, you click on the file name to the right of the Connect button.