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
Lightning Data
Moderator: mcrossley
-
- Posts: 265
- Joined: Tue 10 Sep 2013 8:40 pm
- Weather Station: Ecowitt GW1003 (GW1000)
- Operating System: Raspbian 10 (Buster) / Mono 6.12
- Location: Freiston, Lincolnshire, UK
- Contact:
Lightning Data
Need some help please to understand where a false lightning reading may be coming from.
Initially when I changed MX from running my Fine Offset (Maplin) station to my new GW1000 I saw a record of lightning on 07/02/2106 06:28:15 @ 158.4 miles.
Over the weekend we did have some storms in the area and these were recorded, so 9 strikes within 10 miles. These were showing in Cumulus correctly yesterday, Lightning strikes today was 0 and and the last strike time and distance were from the weekend.
I had issues with my GW1000 yesterday and had to default to factory and set it up again. Cumulus is showing 0 strikes today but the 07/02/2106 06:28:15 @ 158.4 miles has come back again.
I stopped MX from running and did a "search in all files" using Notepad++ looking for 2106. It found some hits in the graph data json files and 2 hits in \interface\lib\datatables\extensions\Scroller\examples\data\2500.txt but this doesnt appear to be weather data related. I am at a loss where this data is coming from.
Any ideas?
EDIT---Just to add this is obviously not caused by Cumulus. Just looking for where the values are stored in Cumulus and if they can be cleared
Thanks
Initially when I changed MX from running my Fine Offset (Maplin) station to my new GW1000 I saw a record of lightning on 07/02/2106 06:28:15 @ 158.4 miles.
Over the weekend we did have some storms in the area and these were recorded, so 9 strikes within 10 miles. These were showing in Cumulus correctly yesterday, Lightning strikes today was 0 and and the last strike time and distance were from the weekend.
I had issues with my GW1000 yesterday and had to default to factory and set it up again. Cumulus is showing 0 strikes today but the 07/02/2106 06:28:15 @ 158.4 miles has come back again.
I stopped MX from running and did a "search in all files" using Notepad++ looking for 2106. It found some hits in the graph data json files and 2 hits in \interface\lib\datatables\extensions\Scroller\examples\data\2500.txt but this doesnt appear to be weather data related. I am at a loss where this data is coming from.
Any ideas?
EDIT---Just to add this is obviously not caused by Cumulus. Just looking for where the values are stored in Cumulus and if they can be cleared
Thanks
- 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: Lightning Data
These are the default values that the GW1000 sends over the API until it detects its first strike.
158.4 ml = 255 km (max value you can put in a byte - 0xFF)
I have no idea why that time though!
I can override these to a more obvious default values like: distance=999, time= 01/01/1900 00:00:00
Would that be better?
158.4 ml = 255 km (max value you can put in a byte - 0xFF)
I have no idea why that time though!
I can override these to a more obvious default values like: distance=999, time= 01/01/1900 00:00:00
Would that be better?
-
- Posts: 265
- Joined: Tue 10 Sep 2013 8:40 pm
- Weather Station: Ecowitt GW1003 (GW1000)
- Operating System: Raspbian 10 (Buster) / Mono 6.12
- Location: Freiston, Lincolnshire, UK
- Contact:
Re: Lightning Data
Hi Mark,
Many thanks. I didnt know if the value was stored somewhere that could be easily change by myself.
Using the dates you suggested would be better unless you could use "---"'s instead of an actual value. I dont know the workings so need to leave to you. Whichever is easiest.
Andy
Many thanks. I didnt know if the value was stored somewhere that could be easily change by myself.
Using the dates you suggested would be better unless you could use "---"'s instead of an actual value. I dont know the workings so need to leave to you. Whichever is easiest.
Andy
- 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: Lightning Data
As the values are only displayed on new (or reset) units until the first strike, I'll leave as stated for the admin interface. The web tags could display dashes though...
-
- Posts: 265
- Joined: Tue 10 Sep 2013 8:40 pm
- Weather Station: Ecowitt GW1003 (GW1000)
- Operating System: Raspbian 10 (Buster) / Mono 6.12
- Location: Freiston, Lincolnshire, UK
- Contact:
Re: Lightning Data
Dashes on the webtags would work for me, until the first strike.
Thanks
Thanks
-
- Posts: 1808
- Joined: Sat 17 Dec 2011 11:55 am
- Weather Station: Davis Vantage Pro2
- Operating System: Windows 11 x64
- Location: Dorset - UK
- Contact:
Re: Lightning Data
I get this quite often. It's just down to the GW1000 losing power - it doesn't save the previous lightning data. The wsview app shows dashes, so that's probably the way to go.
-
- Posts: 214
- Joined: Tue 24 Nov 2015 11:30 pm
- Weather Station: Fine Offset & Davis Vantage Vue
- Operating System: Windows 10; Raspbian Buster
- Location: Switzerland
Re: Lightning Data
Things like this get me interested.
Short answer: it is FFFF FFFF seconds after midnight on 01 Jan 1970, the Unix base date.
Long answer: I looked for all sorts of things, but the answer is that the Unix time fomat is based on number of seconds since midnight on 01 Jan 1970. When expressed as a 32 bit unsigned integer (ie 32 binary digits), this 'rolls over' on 07 Feb 2106 at 06:28:15.
That is, the number of seconds between 01 Jan 1970 and that time is FFFF FFFF in hex or 1111 1111 1111 1111 1111 1111 1111 1111 in binary.
More clearly expressed in reverse, it means that the time given by FFFF FFFF is displayed as 07 Feb 2106 at 06:28:15 on a Unix-time based system.
Check for yourself in Excel by subtracting the 2 dates then using the =DEC2HEX() function.
Problem solved
Reference: You can find this and notes about many other strange dates at https://en.wikipedia.org/wiki/Time_form ... DYear_2106 (which I just edited!)
PS: There is an interesting bug in Excel (or maybe it is Windows?), which is based on days since day 1 = 01 Jan 1900. 1900 was not a leap year (centuries are not leap years, unless divisible by 400, so 2000 was a leap year but 2100 will not be). But Excel thinks it was - it shows 28/02/1900, 29/02/1900, 01/03/1900 as consecutive days. Apparently this is not an error, but a 'feature' to maintain backwards compatability with other systems which have this bug.
Last edited by ExperiMentor on Sat 16 May 2020 7:29 am, edited 1 time in total.
- 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: Lightning Data
Dog! I did the exact same calculation in reverse, working out the Unix time from the date and got nowhere. Problem was I had misread the date above as 2016 not 2106
32 bit Linux systems are going too have a problem in 86 years, I wonder if we'll be ready by then! Well I know I won't for one
32 bit Linux systems are going too have a problem in 86 years, I wonder if we'll be ready by then! Well I know I won't for one
-
- Posts: 265
- Joined: Tue 10 Sep 2013 8:40 pm
- Weather Station: Ecowitt GW1003 (GW1000)
- Operating System: Raspbian 10 (Buster) / Mono 6.12
- Location: Freiston, Lincolnshire, UK
- Contact:
Re: Lightning Data
Thanks for working this one out. Interesting to read and also interesting to read the wikipedia article.
Thought I would put my limited PHP knowledge to use today to try and work around the issue and treat it as a learning exercise as my template is php based.
Using a simple if / else statement, if the last lightning time is 06:28 on 7th February 2106 then php echoes " No lightning detections yet". It also adjusts the colspan in the row of my table to "4" and centres the text. If the data is anything apart from the above date and time it populates 2 rows of 4 columns with the appropriate data.
Seems to work well. Tested by temporarily altering the data file.
Just need some lightning now.
Thought I would put my limited PHP knowledge to use today to try and work around the issue and treat it as a learning exercise as my template is php based.
Using a simple if / else statement, if the last lightning time is 06:28 on 7th February 2106 then php echoes " No lightning detections yet". It also adjusts the colspan in the row of my table to "4" and centres the text. If the data is anything apart from the above date and time it populates 2 rows of 4 columns with the appropriate data.
Seems to work well. Tested by temporarily altering the data file.
Just need some lightning now.
-
- Posts: 265
- Joined: Tue 10 Sep 2013 8:40 pm
- Weather Station: Ecowitt GW1003 (GW1000)
- Operating System: Raspbian 10 (Buster) / Mono 6.12
- Location: Freiston, Lincolnshire, UK
- Contact:
Re: Lightning Data
Thnaks Mark for changing this in b3077.
Just need some lightning now.
Just need some lightning now.