Page 1 of 1

Lightning Data

Posted: Thu 14 May 2020 11:00 pm
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

Re: Lightning Data

Posted: Fri 15 May 2020 8:53 am
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?

Re: Lightning Data

Posted: Fri 15 May 2020 9:20 am
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

Re: Lightning Data

Posted: Fri 15 May 2020 9:43 am
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...

Re: Lightning Data

Posted: Fri 15 May 2020 10:27 am
by Big Daddy
Dashes on the webtags would work for me, until the first strike.

Thanks

Re: Lightning Data

Posted: Fri 15 May 2020 8:06 pm
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.

Re: Lightning Data

Posted: Fri 15 May 2020 8:23 pm
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.

Re: Lightning Data

Posted: Fri 15 May 2020 10:24 pm
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:

Re: Lightning Data

Posted: Sun 17 May 2020 5:36 pm
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.

Re: Lightning Data

Posted: Sat 23 May 2020 8:37 am
by Big Daddy
Thnaks Mark for changing this in b3077.

Just need some lightning now.