Difference in wind speed stats between MX and Cumulus 1

[freddie]

I've noticed a difference in wind speed stats between MX and Cumulus 1 - and a consequent effect on derived temperatures (apparent and wind chill). I have both running and processing data (via VVP) from a Davis Vantage Pro 2 station. Cumulus.ini is identical between the two, except for destination file paths, WOW etc. is set to "off" on MX, and MX has the LOOP2 setting switched off.

Compare the following two web pages, for an example:
http://www.hosiene.co.uk/weather/yesterday.htm (Cumulus 1)
http://www.hosiene.co.uk/weather-test/yesterday.htm (MX)

The difference has been apparent over the past few days.

[steve]

Do you have Cumulus calculating the average, or reading it from the console, and if you have Cumulus calculating it, do you have 'use speed for average' set? Do you have any calibration settings for wind?

[freddie]

Sorry for the delay in replying, I've been away from home.

For both versions, Cumulus calculates the average speed. Use speed for average is not set. There is an identical multiplier for average speed of 1.15.

[steve]

I'll have a look at the code which calculates the average. Could you switch them both over to using the console average and see if there is still a difference?

[freddie]

I'll have a look at the code which calculates the average.

Okay thank you.

Could you switch them both over to using the console average and see if there is still a difference?

I will do that at 0900 tomorrow, and leave it for 24 hours.

[steve]

I look at your two sites from time to time to compare the wind speed readings, and I see today that MX has stopped reading new data. The same thing happened to me last night, I suspect you have hit the same problem - unable to access today.ini? I have a fix for that in the next build.

[freddie]

Hi Steve,

Build 3009 now installed, and both MX and Cumulus 1 are now using the Davis wind speed - with effect from 1025 today.

[steve]

Thanks. It looks like you were still having problems today with the bug that I (hopefully) fixed in 3009, so we should be able to compare the values properly starting tomorrow.

[steve]

I've been comparing the data used by C1 and MX in the calculations (by using VVP like you), and I've noticed something I didn't expect. VVP sends LOOP packets much more often than every 2 to 3 seconds:

17:33:04:268 Info - Virtual Console5: Sending LOOP 1 of 20
17:33:04:502 Verbose - VpConsole: Inserting Loop at start of queue
17:33:04:502 Verbose - VpConsole: Sending Wake Up Console
17:33:04:564 Verbose - VpConsole: Received Wake Up Console response
17:33:04:580 Verbose - VpConsole: Sending Get Live Sensor Data
17:33:04:595 Verbose - Serving Get Live Sensor Data from cache
17:33:04:595 Info - Virtual Console5: Sending LOOP 2 of 20
17:33:04:611 Verbose - VpConsole: Received Get Live Sensor Data response
17:33:04:658 Info - VpConsole: Received Loop packet 30 (2.075 seconds since last packet)
17:33:04:658 Info - Virtual Console5: Sending LOOP 3 of 20
17:33:06:576 Verbose - VpConsole: Inserting Loop at start of queue
17:33:06:576 Verbose - VpConsole: Sending Wake Up Console
17:33:06:639 Verbose - VpConsole: Received Wake Up Console response
17:33:06:654 Verbose - VpConsole: Sending Get Live Sensor Data
17:33:06:670 Verbose - Serving Get Live Sensor Data from cache
17:33:06:670 Info - Virtual Console5: Sending LOOP 4 of 20
17:33:06:686 Verbose - VpConsole: Received Get Live Sensor Data response
17:33:06:732 Info - VpConsole: Received Loop packet 31 (2.074 seconds since last packet)
17:33:06:732 Info - Virtual Console5: Sending LOOP 5 of 20
17:33:08:651 Verbose - VpConsole: Inserting Loop at start of queue
17:33:08:651 Verbose - VpConsole: Sending Wake Up Console
17:33:08:714 Verbose - VpConsole: Received Wake Up Console response
17:33:08:729 Verbose - VpConsole: Sending Get Live Sensor Data
17:33:08:745 Verbose - Serving Get Live Sensor Data from cache
17:33:08:745 Info - Virtual Console5: Sending LOOP 6 of 20
17:33:08:760 Verbose - VpConsole: Received Get Live Sensor Data response
17:33:08:807 Info - VpConsole: Received Loop packet 32 (2.075 seconds since last packet)
17:33:08:807 Info - Virtual Console5: Sending LOOP 7 of 20
17:33:10:726 Verbose - VpConsole: Inserting Loop at start of queue
17:33:10:726 Verbose - VpConsole: Sending Wake Up Console
17:33:10:788 Verbose - VpConsole: Received Wake Up Console response
17:33:10:804 Verbose - VpConsole: Sending Get Live Sensor Data
17:33:10:820 Verbose - Serving Get Live Sensor Data from cache
17:33:10:820 Info - Virtual Console5: Sending LOOP 8 of 20
17:33:10:835 Verbose - VpConsole: Received Get Live Sensor Data response
17:33:10:882 Info - VpConsole: Received Loop packet 33 (2.075 seconds since last packet)
17:33:10:882 Info - Virtual Console5: Sending LOOP 9 of 20
17:33:12:801 Verbose - VpConsole: Inserting Loop at start of queue
17:33:12:801 Verbose - VpConsole: Sending Wake Up Console
17:33:12:863 Verbose - VpConsole: Received Wake Up Console response
17:33:12:879 Verbose - VpConsole: Sending Get Live Sensor Data
17:33:12:894 Verbose - Serving Get Live Sensor Data from cache
17:33:12:894 Info - Virtual Console5: Sending LOOP 10 of 20

That's 10 packets in 8 seconds. You can see that it sends more LOOP packets to the VC than it gets from the station. This must mean that MX is getting repeated wind readings for the calculation. I wondered if the 'allow fast looping' setting in VVP is something to do with this. But when I turn that off, I can't get VVP to respond to MX at all.

The DLL which Cumulus 1 uses works in a different way to the Cumulus MX code. It only ever asks for one LOOP packet at a time, and with VVP, the packet come straight back, with no delay. This is why the VP2SleepInterval setting is needed in Cumulus 1. What do you have yours set to?

[freddie]

The DLL which Cumulus 1 uses works in a different way to the Cumulus MX code. It only ever asks for one LOOP packet at a time, and with VVP, the packet come straight back, with no delay. This is why the VP2SleepInterval setting is needed in Cumulus 1. What do you have yours set to?

I don't have VP2SleepInterval set in Cumulus.ini - either on C1 or MX.

[steve]

You need to set VP2SleepInterval in the [Station] section of Cumulus.ini for Cumulus 1 if you are using Virtual VP, or it will (a) likely uses lots of CPU and (b) give unexpected results for things like the average wind speed calculation. Something like VP2SleepInterval=1200 is probably suitable.

[freddie]

You need to set VP2SleepInterval in the [Station] section of Cumulus.ini for Cumulus 1 if you are using Virtual VP

Okay, I will do this tonight. At the same time I will install build 3010 on MX. Should I revert back to using Cumulus to calculate the average, or should it be just one thing changed at a time?

Something like VP2SleepInterval=1200 is probably suitable.

What are the units? Milliseconds?

[steve]

Should I revert back to using Cumulus to calculate the average, or should it be just one thing changed at a time?

Yes, go back to the calculated average, I think. You seem to be getting the same figures now, using the console average, to 1 dp anyway, which is presumably the difference between the conversion from mph and rounding done by the Davis DLL and Cumulus MX.

Something like VP2SleepInterval=1200 is probably suitable.

What are the units? Milliseconds?

Yes. It's the time that it waits between each read of the data in milliseconds.

[freddie]

Should I revert back to using Cumulus to calculate the average, or should it be just one thing changed at a time?

Yes, go back to the calculated average, I think. You seem to be getting the same figures now, using the console average, to 1 dp anyway, which is presumably the difference between the conversion from mph and rounding done by the Davis DLL and Cumulus MX.

Calculated average and build 3010 used since 2000-ish yesterday evening. Build 3011 used since 1000 this morning.

[freddie]

As well as small speed differences in the 24 hour average, I also see small differences in dominant direction. Has the algorithm changed?