Welcome to the Cumulus Support forum.

Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024

Cumulus MX V4 beta test release 4.0.0 (build 4019) - 03 April 2024

Legacy Cumulus 1 release 1.9.4 (build 1099) - 28 November 2014
(a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)

Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki

Build 3130 with Fine Offset and Solar

From build 3044 the development baton passed to Mark Crossley. Mark has been responsible for all the Builds since. He has made the code available on GitHub. It is Mark's hope that others will join in this development, but at the very least he welcomes your ideas for future developments (see Cumulus MX Development suggestions).

Moderator: mcrossley

Post Reply
BrunswickWeather
Posts: 76
Joined: Fri 11 Mar 2011 2:04 am
Weather Station: Ecowitt GW1103
Operating System: windows 11 Pro/Raspberry pi 4
Location: Brunswick Australia

Build 3130 with Fine Offset and Solar

Post by BrunswickWeather »

Build 3130 has fixed the memory roll over in Fine Offset with solar.
For a 24 hours read for data, it took about 6 mins with the new delay in the program.
The data appears OK.
Enclosed MXDiags file
You do not have the required permissions to view the files attached to this post.
User avatar
mcrossley
Posts: 12756
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Bullseye Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: Build 3130 with Fine Offset and Solar

Post by mcrossley »

From that log file I see that it downloaded 721 historic records.

Each logger record read takes ~ 200ms (of which 150ms is the default built-in delay - I'm assuming you haven't changed that).

But before each logger read, it now checks if the console has created a new logger entry, and if it has backs off for 2 seconds to allow the console to sort itself out and avoid a lockup. That will only happen once every 5 minutes though.
That read of the fixed memory also takes ~ 200ms (again with a 150ms delay).

So a fag packet calculation:- total time = (200 + 200) * 721 / 1000 = 288 seconds = 4.8 minutes
I think the log shows the total download time time is just over 4 minutes, so about right.

This could probably be reduced by reducing the built-in read delay from 150ms. If you try that I'd suggest small steps, but maybe start with 100ms, then if that is OK slowly reduce from there.
Post Reply