Take a look at this wind graph. You’ll notice two “stuck” readings. This happens about every 15-30 minutes with VirtualVP. This is a VWS graph. I use VPLive, VWS and Weatherlink. I’m currently using version 1.1.1.2 but it also did this with 1.0.3
I’ve notice the console sticks also.
Any Ideas?
John
I’m not sure what you mean by the console sticking. Do you mean the graph and/or data display on the VP console’s LCD display?
Does the sticking value resolve itself or do you need to do something manual to get it going again?
Do all the data sensor values get stuck, or just the wind?
Email me the log.txt file from your virtualVP file to support at softwx.com
Steve
I'm not sure what you mean by the console sticking. Do you mean the graph and/or data display on the VP console's LCD display?Graph AND VP console stick! Well it would be more accurate to say that the graph in VWS doesn't "Stick" it just records the stuck data.
Does the sticking value resolve itself or do you need to do something manual to get it going again?It always resolves itself after about 15 to 90 seconds
Do all the data sensor values get stuck, or just the wind?I wish I knew, its hard to tell if its more that just the wind data because the temp and others don't update as frequently. That said, I have never noticed any data updating during the "freeze" episodes!
Log file on its way!
Thanks for your help!
John
if the console stops updating , then the software will get stuck on the last good value
i.e its a hardware issue, and not a software issue
i.e maybe lost reception from the windspeed, or similar
thats my 2 cents worth anyway
When I first noticed this I went back to having VWS connect directly to the console (VirtualVP not running). That eliminated it!
Let me ask this… the way VirtualVP works is it possible for it to cause the console to mis-function?
I want to try one more time, I will remove VirtualVP again and see if it disappears.
UPDATE:
I reverted back to having VWS connect directly to the console (no VirtualVP) and its been running perfectly for over an hour now. So it is definently related to Virtual VP!
It may possibly be related to VirtualVP, but it’s not neccessarily be the fault of VirtualVP. According to my testing, VWS only requests live sensor data request every 3 seconds. This is because, I think, of a bug in VWS that sets the timeout to 3 seconds for communication between VWS and the console. When it sends a wake up command (which very ofter have to be sent a second time before the console responds) VWS hangs out until the timeout expires if the console doesn’t respond to the wake up (which is frequently the case right after getting loop data). The result is that the VWS command sequence of
send wakeup
wait for response
send get time
wait for response
get 1 loop packet
wait for response
repeat
ends up timing out 3 seconds after the wakeup is sent. This means that console has a very light load, only needing to do stuff every 3 seconds instead of the 2 seconds that most weather program use (so they don’t miss any live data which the console is getting about every 2.5 seconds).
Another good test would be running weatherLink direct to the console in bulletin (i.e. live data) mode.
Also, just checking the reception % is not sufficient. The number you should be checking is the number of resyncs. If your console is recyncing with the ISS, it could cause the freezes you describe. In cases where there are reception issues, just taking some of the console’s processor time away for serial communications can be enough to increase the number of resyncs. I hope Chuck is reading this thread because he and I went deep into this topic, and I wrote some programs to run specific tests of sending different combinations of commands to the console. My conclusion, which is difficult to verify, is that there are some consoles that you can cause to resync more frequently by sending legal combinations of commands that other consoles handle without problem. This may be because of a batch of some component in the console in combination with external impediments to good communication between the console and ISS. I’ve had three people report this issue. Others (most) don’t see it at all.
The reason I think the combination of VWS and VirtualVP is more likely to bring it out is because of the bug in VWS I mentioned earlier. Here’s why - VirtualVP ALWAYS responds to the wakeup command. What this means is that the 3 second communications timeout in VWS no longer happens. So VWS runs in a tight loop bombarding VirtualVP with rapid fire Get Time and Loop 1 commands. Code in VirualVP shields the console from getting a lot of that, but not all.
One thing you can do to reduce the command traffic between VirtualVP and the console is to go into the VirtualVP settings and turn off Fast Loop mode.
Steve
I don’t have a reception problem. On the resync idea here are my readings from the console’s dia screen:
42 210 95 4090
7 0 0 <— as displayed on the console
195 14
I should of taken a picture and posted but I hope the way I layed this out makes sense!
I will try Weatherlink bulletin mode to see if i see it! right now the wind has calmed down, so it might be awhile before i can continue testing.
According to my testing, VWS only requests live sensor data request every 3 secondsAre you talking about the Communation Rate setting? In VWS you can set the rate! currently I do have mine set to 3.
One thing you can do to reduce the command traffic between VirtualVP and the console is to go into the VirtualVP settings and turn off Fast Loop mode.It is off, never been on.
Thanks again,
John
you could try running weather display instead of VWS as a test too?
you could try running weather display instead of VWS as a test too?
Ahh, good idea, i will try that!
In my testing, hooking VWS up to the console direct, with a serial monitor in between, setting the VWS update rate had no effect on the communication between VWS and the console - it was still 3 seconds. If you set the update rate to something slow, it did slow down the update of the VWS screen, but the com traffic was the same. As a simple test, set the update rate to something faster than 3 seconds and see if the wind changes faster then every 3 seconds. Look at the console wind and the VWS display (set the console near the screen) together and see. It would occasionally in my tests when the console did repsond to the wake up, but most of the time not. With the serial monitor, you can actually see the 3 second timeouts. (unless he’s fixed it in the past few months).
Steve
Yes we did get pretty deep into that. After I changed my ISS to channel 2 I have no resync issues. I do get one maybe once a week but it only lasts 1-2 minutes. I believe my issue is with channel 1 for some reason. Been running solid ever since I changed the channel which has been 3 or 4 months now.
Chuck
I’m confused, Chuck have you seen this problem before? Did you fix it by switching to channel 2?
Steve, I did try to change the comm rate to 10 seconds and then 20. VWS acknowledges and updates at those intervals!?!
OK, I just witnessed a "freeze that lasted 70 seconds. VWS, WeatherDisplay and the VP console all stood still! The latter half of that “freeze” there was an “R” in the lower bottom right of the console. This is resyncing problems right? Why would I see this only using VirtualVP?
I’m confused!
John
The R is the console saying it is Resyncing the Wireless connection.
It has nothing to do with the datalogger and should have nothing to do with accessing the datalogger. If there is no info to get, there is no info to get, but the the communications between the weather software and the logger should not be effected by it.
You have to define what you mean by Freeze…
If the programs stop functioning for a period of 70 seconds, I would suspect you have something on your computer that is doing that and that it has nothing to do with the weatherstation.
Perhaps anti-virus is checking a file etc??
Yes I fixed the issue by going to channel 2. When mine use to do that, it would dash out the data meaning it did not get any data at all until it reconnected and started receiving data again from the ISS. As soon as the flashing X stops flashing you do not receive any data. I usually seen a L for lost signal and the R would show up after a few minutes. The time it was down (not getting data) varied from 1 to 5 minutes. Once the X started flashing data started coming in again. I tried everything until one day I said what the heck and changed the channel and it worked. Of course this only happened when I used VVP. If I used WD or Weatherlink, and my trial of VWS by themselves none of them had any issue.
Tinplate ran several test for me as mentioned above and he found something was not working right. I think he said it had something to do with the console but I am not sure. I would have to dig through my email and find out but it is time to get to bed have to get up early to go to work.
Chuck
Thank you all for your help and knowledge. Tomorrow i’ll try changing to ID #2 to see if that works.
Thanks,
John
Wow, problem fixed and reception improved! Switch to ID 2 this afternoon, haven’t seen the “freeze” problem once(its been over 5 hours)! Also I’ve had constant %100 reception (before on ID 1 it would jump between %75 and %100!
Thanks for your help, I’ll see if this sticks!
-John