Cumulus Support

Hi Steve,

In recent weeks I've noticed the number of times the console resynchronises with the transmitter is increasing. A couple of times this week it's been 6 which is slightly worrying. But today there's only been one.

I have two transmitters - one for the ISS and another for the anemometer. The ISS transmitter is about 15 meters away and almost line-of-sight through a patio door. The other is at the front of the house about 2 meters higher than the console.

Is it possible to identify which one is resynchronising or how many times each is doing it?

Use the left/right cursor keys to change the active channel while in first wireless diagnostics screen on the console. (If I've understood the question correctly.)

There's only one command to read the stats in the DLL, and it has no parameters:

Description
Fills in the receptionStats parameter with the current ISS or Wireless Anemometer reception data. These values represent the statistics since midnight, since the last time the console was put into the setup screens, or since the reception data was cleared on the console (by holding the clear button when the diagnostics screen was being shown) whichever is most recent.

This corresponds to the "RXCHECK" command in the serial protocol, and again there is no way of specifying which stats:

"RXCHECK"
It sends the Console Diagnostics report. The following values are sent on one line as a text
string: total packets received, total packets missed, number of resynchronizations, the largest
number of packets received in a row., and the number of CRC errors detected.
Page 10 of 52
All values are recorded since midnight, or since the diagnostics are cleared manually.
Example:
>"RXCHECK"<LF>
<<LF><CR>”OK”<LF><CR>" 21629 15 0 3204 128"<LF><CR>
It shows we received 21,629 packets, missed 15 packets, there were no resynchronizations,
the maximum number of packets received in a row without an error was 3204, and there were
128 CRC errors detected.

When you look at the stats on the console, do you get only one set of stats, or one set for the ISS and one set for the anemometer?

prodata wrote:Use the left/right cursor keys to change the active channel while in first wireless diagnostics screen on the console. (If I've understood the question correctly.)

Ah - that answers my question. So at least there's a way to differentiate using the console. Do you know how the stats available from the console relate to the stats available to software?

Thanks John and Steve,

I've done as asked and here are the results. I'd had 3 resynchs in the last 20 mins!

Station 1. This is the ISS I believe.

Number of resyncs = 1
Max number of bad packets = 1
Current streak of consecutive bad packets = 0
Longest streak of good packets = 740.

Station 2. Probably the Anemometer Tx.

Number of resyncs = 3
Max number of bad packets = 2
Current streak of consecutive bad packets = 0
Longest streak of good packets = 1369.

Which suggests the anemometer Tx at the front of the house is the problematic one but it has a higher number of consecutive good packets which is a bit confusing.

It is disappointing that separate stats are not available from the DLL. But perhaps John knows something different. If not at least I can identify which Tx is the problem one.

If it persists I might try respositioning the console but as it and the ane Tx have been in the same locations for the last 3.7 years it is odd that it's playing up now.

I've just noticed something else in the station data stats on my website. http://www.cheadlehulmeweather.co.uk/system.htm

The count of resyncs is not cumulative through the day but the count since the last web update. On the link above it changed from 3 to 1 suggesting the resyncs are occuring more frequently than I thought.

Is this normal with a station coming up to its 4th birthday?

RayProudfoot wrote:The count of resyncs is not cumulative through the day but the count since the last web update. On the link above it changed from 3 to 1 suggesting the resyncs are occuring more frequently than I thought.

I suspect that what is happening is that sometimes the figures are for the ISS and sometimes for the anemometer.

steve wrote:Do you know how the stats available from the console relate to the stats available to software?

Don't know for sure I'm afraid Steve, but it always used to be the case (eg with VP1) that the anemometer channel took precedence for any reception stats reports, so I wouldn't be surprised if that still holds.

OT I know, but have you ever had a chance to look at an Envoy8X WDTU database - you might like that! The DiagnosticsData table (1 of 13 in total) includes per-channel stats for eg RSSI, Resynchs etc and includes fields (sorry, columns) for such delicacies as supercap voltage and solar panel voltage, though I think these latter two are populated only with the very latest ISS firmware. The 8X API hasn't been released, but WDTU can be set to autoupdate eg every minute and the database schema can obviously be seen from simple inspection, so the data could in principle be made available to Cumulus via an Access or MySQL database (your choice, as is MS SQL Server though possibly only the Express flavour would be relevant to non-professional users) as the intermediary.

steve wrote:

RayProudfoot wrote:The count of resyncs is not cumulative through the day but the count since the last web update. On the link above it changed from 3 to 1 suggesting the resyncs are occuring more frequently than I thought.

I suspect that what is happening is that sometimes the figures are for the ISS and sometimes for the anemometer.

If that's the case then there's not much I can do really except monitor the console. But in all other respects everything is working fine so is this something that I should worry about?

I did compare my station to yours Steve and your numbers were so much more 'impressive'. Perhaps I'm worrying unnecessarily.

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.

RayProudfoot wrote:Is this normal with a station coming up to its 4th birthday?

I really wouldn't be too bothered about the number of resynchs, unless it starts to get progressively worse and into large numbers. By all means monitor what's happening but a few resynchs a day is not a big deal. Provided the RSSI stays above 30 and % good packets is above 80-90% (and is not progressively deteriorating) I think that Davis support would say that's acceptable. At a guess, what's happening is that the circuit components are very slowly ageing and the timing is drifting very slightly, which might cause a small increase in the resynchs. But to understand more I think you need to be a radio engineer (which I'm not!). So unless it suddenly gets worse, I don't think that it's any cause for concern at all.

RayProudfoot wrote:If that's the case then there's not much I can do really except monitor the console. But in all other respects everything is working fine so is this something that I should worry about?

I don't enough about the stats to know what is considered a problem. But yours don't look too bad at all.

steve wrote: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.

I know what you mean. Chicken and egg to some extent, but understandable.

Thanks John and Steve for the reassurance. I did look at the diagnostics screen when I first bought the VP2 but today is the first time for a couple of years. I shall re-educate myself with the help in the VP2 User Guide.

Have a good weekend.

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?