Edit - I’ve uploaded a newer version (v.1.1.10) after someone discovered a bug in 1.1.9. The lat/long controls somehow got their range values set back to default. This limited the longitude to 100. If your true longitude is greater than 100 and you went into that form in v.1.1.9, your longitude will have been changed to 100. Download the new version and check that your longitude degrees are correct. The minutes and seconds will not have been changed, nor any of the latitude values. Sorry for the trouble.
A new version of VPLive is now available on the SoftWx website http://www.softwx.com/weather/vplive.html
I wanted to get this out sooner, but I’ve had an issue at work that was demanding my full attention. With that passed, here finally is the new version of VPLive containing the changes brought about by the new recommendations from the CWOP folks and the APRS server folks. If you look over the changes below, you’ll see that I’ve made it so I can deal with most of these server issues now without having to make a new version of VPLive. I haven’t tested this a lot because I wanted to get it out as soon as I could. It’s currently working for me. Let me know if you have any issues with it.
v.1.1.9 has these changes:
Implemented new CWOP recommendations for offsetting the APRS upload time based on the last digit of the user’s CWOP callsign.
Added a “wobble” factor to randomly change the send time by an amount less than 1 minute so that data is not always sent on even minute boundaries.
Removed manual entry of APRS server and port.
Server and port list are no longer hard coded into the program. That data is now in a file called AprsServers.txt.
Added feature for periodically and automatically downloading the AprsServers.txt file from the SoftWx website.
Default AprsServers.txt file specifies the first server attempt as cwop.aprs.net, port 14580, per the new CWOP specifications.
Added recognition and handling of “Port full” response from APRS servers.
I decided to just force it, because the APRS server owners are pretty serious about this issue. The stations all submitting at even 5 minute boundaries are killing them, especially now that most computers are synced via the internet to atomic clock time servers. After giving some time for people to switch their software over, they will be identifying stations that persist in sending on the 5’s, and refusing connections from those CWOP IDs (unless their callsign ends in a 0 or 5). Since they’re being that strict about it (and I understand their motivation), I decided to keep the data entry screen simple and make adherence to the CWOP recommendation be automatically handled in code.
Sounds like a bug, but you’re the first to report it. Email me the contents of your vplive.ini file so I can see if there is anything about your configuration to give me a clue what’s happening. Also let me know if you are running XP or Vista. Does this happen every time it tries to send the CWOP data or just sometimes? There is also a file called aprsDiagnostic.txt that I would like you to send me. Email me at
I figured it out. It’s not a bug, but maybe a better worded error message would have helped (if that is even possible) … :roll: :oops: #-o
As I am a HAM Radio Operator and use my HAM call / ARxxx identifier vs CWxxxx, I do not use the downloaded APRS server list (do not have that checked). Instead I have a list of servers that I manually entered (the rotate servers). I had fat fingered one of the port numbers and I guess that when ever it tried to use that particular entry, that is when the error showed up.
I’m glad you found it. I am thinking of adding logic to handle the server selection based on the callsign (CWxxxx using the CWOP servers, and other callsigns using the APRS servers).
If I install this over v1.1.8.17 will I get settings preserved or will I have to start over? I ask because I installed Startwatch and lost all my settings.
All this software just works for months, so every time I see an update I’m apprehensive because I’ve forgotten how it all works!!!
Vista Home Premium
StartWatch
VirtualVP with N8VBvCOM driver
VPLive
VWS
Vantage Pro 2
It “should” keep the settings, and likely will, but occasionally on Vista this doesn’t happen. This is an important enough update though, I think you should definitely do it. To be safe though, you can make a copy of your current settings, and copy it back if you install the new version and it loses your settings. Depending on your Vista configuration and user previleges, the settings files will be in one of two places:
c:\Users{username}\AppData\Local\Virtual Store\Program Files\VPLive\vptools.ini
or
c:\Program Files\VPLive\vptools.ini
You have to turn off the feature in Windows that hides system folders before you’ll see the AppData folder.
OK, I have a vptools.ini in both places mentioned above with a 7 minute time difference! Why would that be? The time is this morning when I installed StartWatch and had to redo ITS settings. I have started VPLive manually for the current running iteration, the 7 minute earlier one might have been when I was starting with StartWatch. I’ll go try restarting the computer, letting StartWatch start everything, and see what the timestamp on the ini file is. I’ll be back
The vptools.ini file that matched up with the latest Startwatch startup of everything was in the Vista virtualstore location. The one in Program Files didn’t get a new timestamp. Not sure what happened earlier today.
I installed the new version of VPLive, it kept my settings, and all’s well after a restart allowing StartWatch to start everything. My CWOP page is updating, and it looks like I’m golden for another 6 or 8 months when I’ll forget all this again!!
Thanks for the wonderful stuff, Steve, and the quick responses here. It’s great!
Glad that worked out. Make sure you set your VPLive CWOP submission to a minimum of 10 minutes (they don’t want 5 minute uploads anymore).
Sorry for the settings bobble with StartWatch. That should be a lot less likely in the future, as the latest version of StartWatch uses the recommended per user location for storing the settings file, which should keep the confusing virtualStore from getting involved.
I think lots of developers are having a problem with this Vista thing with not wanting stuff to write to Program Files. They hard code it instead of writing to the Windows default locations and that screws up everything. I have a couple obscure things where they gave up and insist on installing in the root of C:. We did that in the old DOS days, and got away from it with Windows, now some are back doing it to avoid having to figure out the Vista thing I guess. Sometimes I wonder if this isn’t some of the problem with the complaining about Vista. But, that’s WAY off topic!!
