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
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
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
Moderator: mcrossley
-
- 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
You do not have the required permissions to view the files attached to this post.
- 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
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.
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.