Page 2 of 3

Re: VP2 Console/Transmitter resyncs increasing

Posted: Sat 19 Jan 2013 4:36 pm
by RayProudfoot
gemini06720 wrote:Ray, just another question - do the resyncs happen during the day or during the night - what I mean, are the resyncs happening more frequently during the night, for example?
Because the count is not cumulative it's hard to say. I had two yesterday afternoon when checking the diagnostics for my reply. I've tried to work out if they're weather related but so far no joy. But as John Dann said, they're not sufficient to cause concern.

Re: VP2 Console/Transmitter resyncs increasing

Posted: Sun 20 Jan 2013 2:01 am
by gemini06720
Ray, the purpose of my question was to 'investigate' if the Super Capacitor ('Supercap') might be deteriorating - as you might be aware, the 'Supercap' is what supplies the power to the ISS - the 'Supercap' is recharged during the day by the solar panel - but at night, the 'Supercap' is the only power supply for the ISS. True, the 3 volts Lithium Ion battery should take over during those long nights. But a weakening state of both units might cause the ISS and/or the anemometer transmitters to stop their transmissions.

Just a thought...

Re: VP2 Console/Transmitter resyncs increasing

Posted: Sun 20 Jan 2013 10:07 am
by RayProudfoot
Hi Ray,

The possibility of the battery starting to fade did cross my mind but as you can see on my system page the Davis DLL reports power as okay. Maybe it just says that right up to the point of being drained.

We've had no sun for many days so even though the panel faces SE the battery will still be working through the day I think. John Dann at ProData (my supplier) doesn't think it's something to worry about unless the number of resyncs stars to increase substantially. I will change the battery in the spring. It is the original after all so has lasted nearly 4 years.

Re: VP2 Console/Transmitter resyncs increasing

Posted: Sun 20 Jan 2013 10:13 am
by gemini06720
RayProudfoot wrote:...I will change the battery in the spring. It is the original after all so has lasted nearly 4 years.
Ray, as incredible as it might sounds (reads), it was just a couple of weeks when I got a message on my console that the battery voltage was getting low ... more than six (indeed '6') years after placing the original battery in the ISS ... talk/write about a good and efficient product ... well worth the hundreds of canadian dollars invested in a weather station... :mrgreen:

Re: VP2 Console/Transmitter resyncs increasing

Posted: Sun 20 Jan 2013 10:17 am
by RayProudfoot
In that case I shall leave it until I get the warning. Yes, the efficiency of the electronics is not obvious when you consider a Davis but for a single battery to last so long is amazing especially in these cloudy isles.

Shouldn't you be in bed? :o

Re: VP2 Console/Transmitter resyncs increasing

Posted: Wed 17 Apr 2013 7:08 pm
by RayProudfoot
I'm resurrecting this thread because last week something odd happened with my console. One afternoon the Total number of data packets received value reset to zero. I've never seen this happen before. But what has happened since is just as baffling.

Since that day the Number of times the console resynchronised with the transmitter has remained at zero each time I've checked. As you can see from the title of this thread this is now the opposite of what was thought to be a problem.

Has any other VP2 owner experienced this and is it something I should be concerned about?

Re: VP2 Console/Transmitter resyncs increasing

Posted: Wed 17 Apr 2013 7:44 pm
by mcrossley
The count seems to reset if you go into the setup screens, or Cumulus is restarted and resets the clock.

My "Number of times the console resynchronised with the transmitter" is always zero, that should only increment if there are problems shouldn't it?

Re: VP2 Console/Transmitter resyncs increasing

Posted: Wed 17 Apr 2013 8:07 pm
by RayProudfoot
mcrossley wrote:The count seems to reset if you go into the setup screens, or Cumulus is restarted and resets the clock.
Correct Mark but I had done neither. When I noticed mid-afternoon the counter had reset I'm sure if I had done any of those I would have twigged.
My "Number of times the console resynchronised with the transmitter" is always zero, that should only increment if there are problems shouldn't it?
Well I have two transmitters and from earlier discussions a few resyncs per day is not considered a problem. But all of a sudden they've gone to zero and nothing has changed.

I suppose I shouldn't be concerned as it's a problem that's gone away but I'm curious as to why it has.

Incidentally Mark, could you PM me your address please?

Re: VP2 Console/Transmitter resyncs increasing

Posted: Thu 14 May 2015 10:14 pm
by MikeLempriere
steve wrote:
prodata wrote:OT I know, but have you ever had a chance to look at an Envoy8X WDTU database - you might like that!
I haven't really taken much notice of the Envoy8x; sounds interesting, but I don't think there would be many Cumulus users buying one.
Sorry I'm replying to a 4 year old note, but I'm not seeing anything newer... From my point of view, 4 years later...

I've had a Vue Console on the wall by the door - right where it's super easy to see, for years - and never look at it. When I want to see the weather info, I want to see the last 24 hours, trends, etc - in other words I want to look at it on a computer screen via Cumulus.

The Envoy8x is about the same price as a Vue Console. Also, the Envoy8x can handle soil moisture etc sensors, whereas the Vue console cannot. To see soil moisture sensors, you must buy the more expensive Pro2 console, and it is limited to only 2 soil stations.

I see it as "why would anyone bother buying a console"?

Re: VP2 Console/Transmitter resyncs increasing

Posted: Fri 15 May 2015 6:33 am
by mcrossley
Does Cumulus work with the 8X? I thought about it as I want to use my wind transmitter as an ISS - attach the solar and UV to it. But does the 8X combine all the data and present it over the standard protocol as if it were a standard console?

Re: VP2 Console/Transmitter resyncs increasing

Posted: Fri 15 May 2015 7:48 am
by steve
The Envoy8X doesn't use the same protocol as the other consoles and the Envoy, and hence doesn't work with Cumulus. Davis have yet to publish any protocol details, as far as I know.

But substitute 'Envoy' for 'Envoy8x' and I agree to a certain extent. I almost always look at Cumulus data - and usually on the web rather than Cumulus itself, even though MX allows remote viewing; it's just a habit I've got into. But I do look at my VP2 console screen from time to time, if I'm in the room where the console is.

Re: VP2 Console/Transmitter resyncs increasing

Posted: Fri 15 May 2015 8:24 am
by prodata
I have access to them (if I can remember where I put the document!), but they're not written up in the same level of detail as in the main Serial Tech Ref. You're welcome to take a look, but I suspect that you'll encounter a problem of scoping what you're aiming to do.

For example, remember that the 8X is capable - at least in principle - of receiving data from eight ISS transmitters simultaneously - how would you envisage handling the data flows from those? OK, that's a bit of an extreme example, but the point is that you can have any arbitrary mix of transmitters that you wish on anything up to all eight available wireless channels. Where do you draw the line in terms of which Tx combinations you're going to accommodate?

Davis solved the problem with the WDTU software by creating an SQL database schema extensive enough to cover all conceivable combinations of transmitters. TBH I think that anyone interested in using an 8X is potentially better off running WDTU on a Windows box and then designing their own query/presentation software to query the various SQL tables as necessary and to generate the type of data presentation that they're after (which WDTU doesn't do - it's primarily just a data acquisition tool, dumping data into its SQL database, but not much more).

Don't get me wrong - the 8X is a powerful and very flexible VP2 receiver unit and it's a shame that it doesn't sell in greater numbers (I think it's really waiting for someone to devise a suitable presentation front-end). But, while the 8X still uses a form of the standard Davis serial protocol via a WL logger and so in principle data can be pulled from it in the same generic way as with a regular VP2 console, it does have its own way of organising data and can't be treated just a as sort of standard console on steroids.

Steve and Mark: if you're interested in looking at an 8X in any more detail then feel free to contact me offline.

Re: VP2 Console/Transmitter resyncs increasing

Posted: Fri 15 May 2015 8:40 am
by steve
I think you're right, and the 8X doesn't fall within the scope of what Cumulus is intended for. If Cumulus was purely for Davis stations, it might be a different matter, but trying to shoehorn all of the different station types into the one program is difficult enough as it is. I don't want to go down the road of writing huge amounts of code specific to one device, particularly one which isn't owned by significant numbers of people who would be likely to use Cumulus anyway.

Re: VP2 Console/Transmitter resyncs increasing

Posted: Tue 29 Oct 2019 4:44 pm
by Grimers
Just seen this thread, I'm also having the same issue. I have taken two photos of the console from just a short time ago. Apparently, a few resyncs a day is considered normal, but does this look normal?

Image

Image

Re: VP2 Console/Transmitter resyncs increasing

Posted: Wed 30 Oct 2019 9:26 am
by RayProudfoot
Although I started this topic 6 years ago I still have the same console and the two transmitting units - the ISS and one for the anemometer. Here are my latest stats as at 09:15 for comparison.

Total Number of Data packets received = 12151
Number of missed data packets = 203
% of good packets = 98.4%
Number of times the console resynchronised with the transmitter = 1
Longest streak of consecutive packets received = 859
Number of packets received with CRC errors = 185
The console firmware version = 3.12
Console battery condition = 4.08v


Hopefully John Dann will give you some clues where the problem lies.