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

Lightning Data

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
Big Daddy
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

Post by Big Daddy »

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
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: Lightning Data

Post by mcrossley »

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?
Big Daddy
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

Post by Big Daddy »

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
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: Lightning Data

Post by mcrossley »

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...
Big Daddy
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

Post by Big Daddy »

Dashes on the webtags would work for me, until the first strike.

Thanks
Mapantz
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

Post by Mapantz »

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.
Image
ExperiMentor
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

Post by ExperiMentor »

mcrossley wrote: Fri 15 May 2020 8:53 am I have no idea why that time though!
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
:clap: :clap: :clap: :clap:

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.
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: Lightning Data

Post by mcrossley »

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 :bash:

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 :lol:
Big Daddy
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

Post by Big Daddy »

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.
Big Daddy
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

Post by Big Daddy »

Thnaks Mark for changing this in b3077.

Just need some lightning now.
Post Reply