Topic: VP2 GETTIME programming

[JohnLinford]

This is a question for programmers that have written their own code to interface with the VP2.

For no other reason than that I can, I wrote my own software to interface to my VP2 data logger. It's worked fine for many years but recently I decided to implement the SETTIME function and have run into a strange problem!

Normally I have the application running in the LOOP sequence, restarting each time it terminates. If I want to update the time, I wait until the current LOOP is completed. At this point there is no data being moved between the VP2 and my application. I now issue the SETTIME command, I get the ACK and then send the date/time + CRC. I get an ACK back from the VP2 and by observation on the VP2 display, I can see that the time has been set OK. So far so good.

What happens next is curious.

I send a new LOOP command but I do not get loop data back. Most times I get nothing but occasionally I get what appears to be a truncated loop response. The display on the VP2 freezes. This carries on for a while, maybe a couple of minutes, during which time I send wake-up messages and LOOP requests every 10 seconds or so. Eventually, the VP2 seems to work out what's going on and starts sending LOOP data normally again.

I have both a VP2 and an Envoy; both exhibit this weird behaviour. Have any other programmers come across this?

Many thank in advance,

John

[vinceskahan]

you might want to take a look at the weewx source code on GitHub for how they do it in the Vantage driver (python)

[ConligWX]

Here is the weewx vantage driver

https://github.com/weewx/weewx/blob/master/bin/weewx/drivers/vantage.py

[mcrossley]

That is normal behaviour, when you set the time the VP2 has to go through a number of routines to reset and realign things internally. This can take a minute or so, during which time it will not be responsive. Some stations - but not all - will even lose sync with the ISS. After the process is complete you will find things like the reception stats have been reset to zero

[JohnLinford]

Thanks for the replies. I checked out the weewx code and it is very similar to mine, except that weewx doesn't seem to wait for an ACK from the VP2 before sending the SETTIME, which is a bit naughty but probably inconsequential.

Mark - that's very interesting, thank you. Astonishing that it can take so long to sort itself out but it does seem that that is what is happening. I have occasionally seen the ISS lose sync but usually the system recovers inside a couple of minutes and carries on OK.

I used to set the time at start-up and each day at 01:00Z but there is no need to do it that often, as the internal clock does not drift that much. So I have now changed my code to update the VP2 clock once a month and I will just have to put up with a few minutes of lost data, which isn't really an issue.

Thanks again folks.

John

[BigOkie]

That is normal behaviour, when you set the time the VP2 has to go through a number of routines to reset and realign things internally. This can take a minute or so, during which time it will not be responsive. Some stations - but not all - will even lose sync with the ISS. After the process is complete you will find things like the reception stats have been reset to zero

Mark, is that why if I look in the CMX logs around that time (4am is when my console syncs time) I see for about two minutes in the logs 'LOOP data unavailable' or words to that effect?

[mcrossley]

It is, and this thread has made me think I'll make the console clock setting more flexible in Cumulus. So if you enable clock setting, for example make setting the clock on start-up optional, and let you select a day interval rather than doing it every day as present.