Did not receive....

Steve, I keep getting these errors but doesn’t seem to affect anything. Thoughts?

09:48:05:011 Warning - Console: Did not receive expected Live Sensor Data packet
09:50:03:073 Warning - Console: Did not receive expected Live Sensor Data packet
09:52:05:183 Warning - Console: Did not receive expected Live Sensor Data packet
09:53:05:214 Warning - Console: Did not receive expected Live Sensor Data packet

–Dave

Hi Dave,

My VP Live is doing the same very occasionally…I double clicked on the words at the bottom and lo and behold they disappeared (might have been a coincidence)… at the same time the % reception then changed…I’m therefore presuming that it might be something to do with the data packets being good/bad and gives the reception count over the 2 min period…I might be wrong though/just guessing…

Thanks Steve for the update…I like it :slight_smile:

If I double click they go away. That’s by design. The text above was copied from the activity log.

–Dave

Steve, I have another problem. Using 1.1.8, I can not send APRS data. When it first starts it tries to send the APRS data and I see the white LED for about 10 seconds and it then turns green. Checking CWOP it doesn’t show that the update took place. (Top of page indicating how long since last update.)

If I use the the Update APRS now from File it will transmit for about 10 seconds then turns red. Activity log has a failure notice about sending APRS data.

When I roll back to 1.1.7, during the installation, I get an error that the vpaprs.exe can’t be installed or whatever the windows error message says. Under Task Manager vpaprs.exe is still running and have to kill it from there to install 1.1.7. After installing 1.1.7 APRS data is sent normally.

This is repeatable and I’ve tried about 4 different times with the same results.

–Dave

I’m not sure about the “did not receive”. The only thing I’ve changed in the VPLive communications is the insertion of the time check which only occurs once per hour near the top of the hour. VPLive gets live sensor data by asking the console (or VVP) to just send a bunch of live data packets, which the console will then send at 2 second intervals without VPLive needing to do anything other than sit back and receive them. The error you see occurs when VPLive doesn’t get a live packet after waiting a reasonable time. When that happens, it just sends a new request and continues. I’m not seeing that on mine at all. It’s been running for 9 hours straight and hasn’t missed a single packet. If you get a few of those it’s no big deal. If you are getting lots, then it would be good to know what’s up. The only way I could really tell is to open up your activity window and check the “Info” check box. That will show a lot more info of what’s going on. Do that, and when you get some of those missed packet messages, copy the contents of that window and email it to me.

Regarding the APRS, again, I’m not sure what’s different at your location. Mine has been sending fine. But from the description, it sounds like there is definitely a bug I’ve introduced with the changes I made. You can run VPLive 1.1.8 with the vpaprs.exe from 1.1.7, and I would recommend you do that until I figure out and fix what’s wrong there.

Steve

Steve, I copied the vpaprs.exe from 1.1.7 to 1.1.8 but that didn’t help. Rolled back to 1.1.7 and all works well.

I’m thinking it may have something to do with my firewall. Don’t have much time to check on it now as we’re gong on vacation Tuesday morning and I have a bunch of stuff to do this afternoon and tomorrow to get ready. So I may not be able to really look into the firewall until the week after next.

Do you know what program I’d need to allow? I did give permission to vpaprs.exe but not sure it that would be all. As others haven’t done the old ‘me too’ it must be on my end. I’ll check when I can.

–Dave

The new VPLive 1.1.8 killed my APRS service. I had to uninstall it using add/remove programs and reinstall 1.1.7 in order to get APRS back up. Not sure what changed. I’m using it on a remote site that has satellite internet. Maybe the delays are causing a timeout. I like the clock sync feature, but APRS is more important.

Ah, something we have in common. Satellite internet. Have no idea why that would make a difference but we’re the only ones so far.

I suspect it’s timing out too quickly. Not sure what was changed.

Are you using Hughes?

–Dave

Yes. I’m on the 72W satellite (GE AMC-6).

The change I made to the APRS communication was to go from a send, wait, pray model (connect, sleep 3 seconds, send login, sleep 3 seconds, send data, sleep 3 seconds, where I never actually bother to look at what the APRS server sends back) to a send and read model, where the reads are immediate (they don’t wait for data). The reads are in a loop so I do a read, sleep 1/2 second, repeat, until I get the response string I expect or 3 seconds has elapsed. This way instead of just assuming I’ve connected ok, I actually inspect what I get back from the APRS server and make sure the connection is as it’s supposed to be. Apparently it’s ok to just wait three seconds and send, but I need to wait longer if I’m reading. I’m assuming this is a problem in your case because of the satellite latency. It takes more than 3 seconds for the response to get to you from the APRS server. But when you add the latency for the data going back to APRS, by the time the APRS server gets it, it is ready, even though I hadn’t received the response yet when I sent it. This may be what’s happening I will increase the time I spend reading for the response to 6 seconds instead of 3. I’d like you guys to try it after I get it ready. I’ll post a message here when it’s ready. The reason I made this change is to be more reliably sure that the send to APRS actually happened correctly. So I think trying to make this new way work is still worth it.

Steve

Yes. Let me know and I’ll try it. Satellite is optimized for web browsing. I know that trying to FTP and getting a port open and uplinking data is painfully slow. All I know was that the “blind” model was working fine. Why don’t you try to send the data anyway even if you timeout? This way, worst case, your model default to the old system.

The APRS servers go down from time to time. Vpaprs has an internal list of places to try. First it tries the core rotation, and if that fails, tries 6 specific servers in turn. In addition, there are two ports that can be used; one is preferrred, but that port is blocked for some people (I think some ISPs block it) so there is an alternate port to use. So there are several situations that can commonly happen that have to be worked around, and having one of the things fail is not uncommon. Let’s try the fix I have in mind and see how that works. I may add the blind method as one an end of the road thing to try if all else fails.

Steve

I’ve put a new build of VPLive 1.1.8 on the website http://www.softwx.com/weather/vplive.html

This contains some changes based on this thread:

  1. I increased the LOOP timeout slightly to see if this reduces the “did not receive” messages
  2. I made some changes to the vpaprs send program that submits to aprs/cwop. This new version should work better for high latency connections. It also creates a new file called aprsDiagnostic.txt that contains a little log of the last attempt to send to CWOP. The contents of this will help me diagnose problems in the aprs communications.

Give it a whirl and tell me if this works better.

Steve

1) I increased the LOOP timeout slightly to see if this reduces the "did not receive" messages 2) I made some changes to the vpaprs send program that submits to aprs/cwop.
  1. Have only been running about 15 minutes but no “did not receive” messages. I usually see them immediately :slight_smile:
  2. APRS now works when initiating it manually and automatically. Verified on CWOP. :slight_smile: :slight_smile:

Thanks for the support!

–Dave

Glad that solved the probelm. It would be great if you could post or email me the contents of your aprsDiagnostics.txt file so I can get an idea how long it takes to get the response from the APRS server when you are using satellite internet.

Steve

Confirmed. It works.

Thanks!

This is all that is in that file.

trying rotate.aprs.net:14580…connected
(j=1) sending callsign, trying first.aprs.net:14580…connected
(j=1) sending callsign, trying second.aprs.net:14580…connected
(j=1) sending callsign, trying rotate.aprs.net:23…connected
(j=1) sending callsign, (k=1) sending data, successful data send

Also no ‘did not receive’ in about 5 hours w/ APRS working fine also.

–Dave

Thanks for sending the aprsDiagnostics file. Based on what’s in it though, I might make another change. What those contents tell me is that after sending the callsign, nothing was received within 6 seconds. That’s kind of surprising, because I can also see that the welcome message was received within 500 milliseconds of connecting. What is finally succeeding is the blind send fallback method like I used before. If one of you guys with satellite are willing to bear with me a little bit, I’d like to make another version of vsaprs that will try something a little different, and provide me some more feedback. That feedback will help me tune vpaprs so it works optimally in all types of internet connections.

Steve