Topic: Stop VPLive from dropping data

[Beaudog]

For those of you still using VPLive to report to CWOP you are probably seeing drop outs for several minutes or even an hour or so.

This is caused by the change in the CWOP servers and them now wanting a header of TCPIP rather than TCPXX.    So far only two of the servers have been converted over 2 and 4.   Server 1, 3, and 5 are still accepting the TCPXX header.    VPLive has not been updated to correct this and probably never will.

You can temporarily stop the drop outs by doing this.
Uninstall the latest version of VPLive 1.2.5    and then download the previous version 1.1.10.
Go to the VPLive folder and open AprsServers.txt.   Change the server list to look like this

cwop1.aprs.net,14580
cwop3.aprs.net,14580
cwop5.aprs.net,14580

Save the file.

This will cause VPLive to use only those servers and not 2 and 4.
For some reason the latest version of VPLive does not read the Cwopservers.txt as it is supposed and seems to be hard coded to use cwop.aprs.net command which causes the program to use all five of the servers on a random basis. Thus sometimes picking 2 and 4 which drop the data stream.  Version 1.1.10 works as it is supposed to and reads the AprsServer file.

This is only going to work as long as  server 1,3,and 5 continue to except the TCPXX stream.  So you will have to watch and adjust the file to match which server is still accepting data. Hopefully Steve will show up at some time and make the fix but, maybe not.  So, we are going to have to find another program to replace VPLive fairly soon.

[BCJKiwi]

I'm a little puzzled by this. Checked our data at http://www.findu.com/cgi-bin/raw.cgi?call=yourcallsign and we have no missing data.
Data has been received via all 5 servers over the last 24 hours using TCPXX.

[Beaudog]

It does indeed look like that you are not losing any packets.   I can't explain that but CWOP has been very specific that all software must now support the TCPIP header.

WUHU, Cumulus and I think Weather Display have all modified there code to the TCPIP format because of lost data.

[chief-david]

VPLive is not working for most with CWOP

http://www.wxforum.net/index.php?topic=18793.msg181234;topicseen#msg181234

I switched to Weather display.
Cumulus is donation and will send to CWOP
I believe WL still sends to CWOP-but I don't use that now.

[Weather Display]

nd I think Weather Display have all modified there code

there was no change needed as WD was using TCPIP anyway

[Beaudog]

I'm a little puzzled by this. Checked our data at http://www.findu.com/cgi-bin/raw.cgi?call=yourcallsign and we have no missing data.
Data has been received via all 5 servers over the last 24 hours using TCPXX.

If you are EW0594 it says that you are using cumulus and not VPLive

EW0594>APRS,TCPXX*,qAX,CWOP-3:@131930z3654.58S/17446.28E_000/000g002t056r044p110P109h97b10164eCumulusDsVP
 EW0594>APRS,TCPXX*,qAX,CWOP-3:@131940z3654.58S/17446.28E_273/001g002t056r034p111P110h97b10164eCumulusDsVP
 EW0594>APRS,TCPXX*,qAX,CWOP-4:@131950z3654.58S/17446.28E_000/000g002t056r026p113P112h97b10164eCumulusDsVP

I had to get that from the Silver Acorn wx page as the link you provided does not work

[BCJKiwi]

@ beaudog
Well, I expected that you would replace "yourcallsign" in  http://www.findu.com/cgi-bin/raw.cgi?call=yourcallsign  with your callsign, not go looking for ours - sorry for not making it clearer.

I do not understand why you would be concerned with what is sending the info - VPlive, WD, Cumulus or whatever, they should all be the same at the point of arrival at CWOP. If there is a general issue with VPLive, perhaps it is not actually in the TCPIP/XX header?

I searched all the documentation on the CWOP site and associated links BEFORE POSTING and could find no reference to TCPIP as all the documentation I could find says TCPXX.

It is obvious there is more going on here as if others (e.g. WD) have always been sending via TCPIP, it would seem that the CWOP documentation is out of date, and that both TCPIP and TCPXX have been accepted for some time and perhaps the change (if any) is that TCPXX is being turned off.

Beaudog, Would you please point me to the new specification ("CWOP has been very specific that all software must now support the TCPIP header") so I can refer it on to Steve so Cumulus can be updated.
Thanks

[Weather Display]

so I can refer it on to Steve so Cumulus can be updated.
Thanks

but cumulus already has changed
as already been posted by beaudog

[Beaudog]

"
 Forum: Announcements and News   Topic: Cumulus 1.9.4 beta available
 
steve

 Post subject: Re: Cumulus 1.9.4 beta available

Posted: Thu May 23, 2013 9:13 am
 
 

Replies: 19
Views: 9166

 
Cumulus 1.9.4 beta build 1077 is available. ⋅ Change CWOP header to use "TCPIP*" rather than the deprecated "TCPXX*" ⋅ Option to save NOAA-style reports with UTF-8 encoding Download link: http://www.nybbles.co.uk/downloads/beta194/CumulusSetup.exe ...


Cumulus was updated with build 1.9.4  1077

You are using build 1080          Your version is reporting as required.

Some info here    http://tech.groups.yahoo.com/group/wuhu_software_group/message/21955

The requirement has existed for sometime, They have just started enforcing it as new servers come on line.

 The CWOP/findu guys are kind lax in putting this stuff out unless you keep up with the CWOP mailing list. 
 

[BCJKiwi]

Well I'll query that with Steve as I am running the latest Cumulus build (1080 of 3 Jun 2013) and as you can see;

EW0594>APRS,TCPXX*,qAX,CWOP-3:@131930z3654.58S/17446.28E_000/000g002t056r044p110P109h97b10164eCumulusDsVP

it appears to be using TCPXX.

Beaudog, thanks for the reference.

[Beaudog]

Well it is clear that you don't understand.    The line you are looking at is not the line that cumulus is sending.  That is the line that findu is showing after the packet has been passed thru CWOP to FINDU.  They ain't the same. Different servers owned by different people with different rules.

Now I will grant you that not many people understand how this works (including me).  Probably only Russ Chadwick or Gladstone and a very few others do.

This was already discussed on the sandysoft forum back in April.

I think Ted Lund tried to explain it back in April or may   look here.

http://server.gladstonefamily.net/pipermail/wxqc/

And my explanation of how to temporarily fix VPLive is correct even if you (a cumulus user ) don't believe it.


And an excert from Ted Lund:

The servers re-write the headers, the output is not expected to match
the input. If you're verified the server will write it as
WB5HUP>APRS,TCPIP*,qAC,CWOP-1:, if you're not the server will write it
as WB5HUP>APRS,TCPXX*,qAX,CWOP-1: . You should be sending only
WB5HUP>APRS,TCPIP*.

WView is VERY broken, also. WView is illegally placing the q-construct
in the packet and its getting dropped because its says its looped.  I
patched mine and sent the details to Mark Teel back in February who
anticipated the next release ~April. I still haven't seen it.

[BCJKiwi]

Well in that case (and having looked at the thread(s) in the link you supplied), I guess the issue is that EW0594 is not considered to be "verified" so the one place you can go to check what is happening is actually reporting something different (i.e. we are sending TCPIP* but it reports TCPXX*) - not very helpful when you don't know the detailed inner workings and vagaries of the system!

This is even more disappointing since we followed the proper procedure and received the email which verified our location - unless of course this verification refers to something else?

[Beaudog]

Verification of location has nothing to do with the headers.

The verified in the example is for the packet with an amateur callsign.   Packets with verified amateur callsigns can be sent across the amateur radio network. Packets with CWOP numbers can not go across the radio network and must go via another means.

It is also appears to be  handled differently depending on if you are using your amateur call sign or CWOP number and/or CWOP or APRS servers.

You have to remember that the whole APRS,CWOP,FINDU thing is not a nice single point controlled operation. It is a conglomerate of individually owned servers operated by private parties that are free to do as they please. Thus, some CWOP servers are still accepting TCPXX and others are not.

The lash up between APRS,CWOP and  FINDU  was done years ago.  I doubt that anyone other than Chadwick or Gladstone knows how it works and they have probably forgotten.  Thus some of the bad info still to be found on their information pages.

You have fallen into the trap of trying to make things work the way you think they should when in fact they do not.

The header gets changed somewhere in the pass from CWOP servers to the FINDU server.  WHY I don't know ask Gladstone.  The last I new he owns the FINDU servers.   It would not surprise me if he got up one day and just turned them off.

You can also go ask Steve put I assure he does not know the answer either and finds getting info about any of it very difficult.

[Beaudog]

Just ran a test using cumulus.

If I use the CWOP servers it strips off the IP and replaces it with XX

If I use my callsign and the APRS servers it leaves the header as TCPIP.

N4DMS>APRS,TCPXX*,qAX,CWOP-1:@151355z3143.03N/10952.75W_326/001g007t074r000P000p000h44b10207VL1112
 N4DMS>APRS,TCPXX*,qAX,CWOP-1:@151404z3143.03N/10952.75W_284/002g004t073r000P000p000h45b10206VL1112
 N4DMS>APRS,TCPIP*,qAC,FIRST:@151420z3143.02N/10952.77W_325/003g007t075r000p000P000h44b10206eCumulusDsVP
 N4DMS>APRS,TCPIP*,qAC,THIRD:@151429z3143.02N/10952.77W_306/004g006t076r000p000P000h43b10206eCumulusDsVP
 N4DMS>APRS,TCPIP*,qAC,SIXTH:@151438z3143.02N/10952.77W_294/004g008t075r000p000P000h44b10206eCumulusDsVP
 N4DMS>APRS,TCPIP*,qAC,FIRST:@151447z3143.02N/10952.77W_289/005g007t075r000p000P000h45b10207eCumulusDsVP
 N4DMS>APRS,TCPXX*,qAX,CWOP-3:@151530z3143.02N/10952.77W_310/004g009t080r000p000P000h38b10210eCumulusDsVP

[BCJKiwi]

I read and believe I understand what you write but it does not help in confirming things are working as they should.
To recap;
It seems reasonable for the uninitiated in the vagaries of the systems involved to expect that the only checking mechanism available will provide a response that is useful. You have made it clear that this is not so.

The threads you referred me to clearly state that the difference in the displayed result depends on verification - no mention of call sign type that I saw.

However, as I and ( I would guess ) most users have no desire nor ability to change how any of this works, once we know and understand that this aspect of the system is broken, we just have to accept it and move on.

Over and out.