Topic: Status of Blitz project

[92merc]

I didn't want to post this over on the Blitz forum.  I'm not looking to disparage the developers or the project.

But I've noticed nothing really new on the firmware front, or any major updates coming.  Their "What's new" was last updated November of 2019.

So something going on I didn't see?  Just hoping this project doesn't die off.  Hoping someone may know something.

[miraculon]

I haven't heard anything, maybe Cutty has.

It might be that the project is working well and stable. There are still areas that could use more stations, but I haven't followed the availability of them.

Quite frankly, I haven't checked into the Blitzortung forum in a while... 

Greg H.

[chief-david]

Would love to have a lightning detector. But unsure how I can get the wiring into the building.

They are doing another story on me for the alumni mag. Who knows. Maybe someone will come forward.

[Cutty Sark Sailor]

I haven't heard anything, maybe Cutty has.

It might be that the project is working well and stable. There are still areas that could use more stations, but I haven't followed the availability of them.

A)  I'll give you some thoughts:
B) Generally, that is true.. parts availability, logistics and fabrication is very much an issue, as always

Now -  thoughts:
Over the last year or so, there have been many subtle impacts of the Covid issue, and to some degree that has imacted Blitzortung as well...That and the intense data processing and system upgrades that began a bit before the Covid issue became intense. But that's only a corner of the situation. I mention it only to make the point that the damn thing has affected society in more ways than is obvious.

That and other coincidental events and situations over the last couple of years would generate concern.. I agree... many go back to the large server database issue of a couple years ago, and the installation of new processors... which did NOT go according to plan because of a hardware issue, and several algorithm changes, causing issues between the (at the time) shared data between BT and LMO platforms... LMO gradually has become only an 'adjunct' to BT rather than a 'valid' data source, partially because of that.

Tobias: the firmware/LMO developer... due to Career and Lifestyle impositions, he's extremely limited on resources and time to devote to the project. Richo, mostly because of health, and retirement, is much less involved in the development (with Blue pretty much designed and locked in). Mr. Friese, who supplied the ferrite antennas, has retired. However, as we've learned, someone qualified to own a BT shouldn't be affected by the lack of prebuilt antennas

Another factor is the enhancement and upgrading of the data processing and computations in the project overall...  As you're aware, Dr. Egon Wanke actually "owns" Blitzortung.  Over the last couple of years, he's focused on upgrading and improving quality and accuracy of the data processing for the currently utilized parameters.  Also over the last year, his professional demands have been more intense due to COVID...

Much has been done, however,  despite his resticted availability. You'll notice, if you haven't already, for example, the number of strokes 'used' for locations for your stations will have dropped significantly, compared to what it was in the past... doesn't mean you aren't effective... just means that with an increase in station density, there are 'more' stations providing the same 'stroke', which have 'better' stroke data than you do. e.g. Station A is 80km  from the stroke sends discharge impulse, becomes a 'locator'....you're 800km away and send skywave.  Skywave not selected, you drop from 'locator' to 'detector'.. whereas  before station A came online, you would have been a locator.

If you haven't noticed such, you will come season start!  I dread looking at the BT forum when that happens...

There are more subtle things over the last few years, but with all the server refinement in process as Egon is able to implement it, there isn't much sense in developing new firmware re-writes, even though there are some irritating bugs in the 9 series .. they don't affect the data sent, but are more on the 'operator's perspective'. 

A second major reason, the controller itself is running very close to memory maximum for firmware, even to the point that scripts to display operator's gui are NOT contained in latest release, but are pulled from BT server when GUI accessed.  Until Egon perfects the current data paradigms on server, I don't expect a rewrite of the firmware... and when it does arrive, I expect it will be rather drastic.. heh.

A third thing.. As you know, there are MANY systems out there that the operators found were not 'plug'n'play' and those folks found the system was not what they 'assumed', despite the project explanations. They are still online, however, not-optimized, and in many cases a big old boat anchor on the system... One of Egon's point development is noise paradigms, and you'll also see fewer 'valid' channel signals than before.  Eventually portions of that need to be implemented into the local firmware also.

One  'negative', which to me is a 'positive', is the retirement of the gentleman who supplied the 'kit' ferrite antennas... I say positive, because that may decrease the number of 'plug'n'players'  wasting their money on a 'prebuilt' system... if you follow me.

[PaulMy]

Hi Mike,
I moved to a new house about 18 months ago and reconnected my Komoka #1076 at the time and after a bit of fumbling around got it to again show on my IP 192.168.0.16.  And it has just been running and running without me hardly ever looking at it    
Your post remined me to login, and I see a New Firmware Version 9.2.  In my Status settings it shows Station 1076 FW 8.0-b2PCB 10.4/12.3 but I thought I had updated to ver. 8.x a couple of years ago (I can't recall exactly when and what). 


Should I upgrade?  and what preparation should I do to help avoid any catastrophe?


Thanks,
Paul

[DaleReid]

In deference to Cutty's comments with his continued all-in participation and managing the Region 3 board here:

I make a couple observations.  The developers and those with the inside connections to modify code and keep this whole project going indeed are not only brilliant, but crank out wonderful code and firmware.  These gizmos just keep working.

Sure there are a few things that I'd like to see different and IF I had designed it and IF I had the ability and knowledge, I might make some things a wee bit different. 

But it works, day in and day out.  I am in awe of not only the electronics but the servers and of course the software that makes this work at a much deeper level than most of us will ever appreciate.  In some ways it is like hearing the engineers at JPL being interviewed about monitoring a spacecraft, thinking that is neat, but not knowing the immense work that goes on day after day, boring but necessary, to keep things running.  I'm aware of very few commercial services that come close to the quality of product and up-time that Blitz offers.

The passion that the core development team must bring to their 'hobby' is also tremendous.  I was all in and even ran around the back yard with noise sniffing radios to try to locate the most quiet place to put antennas (with the restraints that my wife has about more wires), yet in the last year I've not been nearly as day in - day out involved with my own two sensors.  Cutty has fielded questions and the rest of the R3 crowd supported one another with PM question and answers. 

But since things just work, fortunately most things are on autopilot for this admittedly high level system.   THANK GOODNESS.

Anyway, the item about the controller memory being just about maxed out is interesting as a limitation when we normally just don't think of such things.  I recall in college in the late 1980s that one way to get a little better grade was to make extremely compact, but bulletproof code, for one professor. Of course he was involved with assembly language code for weather satellites, and every byte counted (8 bits).  Now the young guys just import another library and away we go.

Enough rambling.  I am guilty of not tweaking and understanding things better than I have or do.  Part of it is, like the developers, there are so many demands on my time for things I want to finish with my remaining years and a slow progressive worsening in 'abilities', which I thought would always be humming along at the same as when I was 30 years old.

As for winding ferrites, I sort of enjoyed it and have made two functioning sets, and would gladly wind a few more if a new series of kits comes up.  I didn't liken it to growing my own transistors as a badge of accomplishment, but a necessary thing to do, along with an appreciation of the work.  Sort of like trying to (so far unsuccessfully) write a driver for WeeWx to do a few things with clientrawout.txt data... but I digress.  Believe me, it gives you a whole new understanding.  And even tracing intermittent malfunctions to things like power supplies and learning why those can cause problems is expanding my understanding.

Speaking of winding, I'd better wind down. I just wanted to throw in a few observations, as old codgers often feel entitled to do, not because I was first on the block by a long shot, but I have been around long enough to crank down my gains as more and more stations come on line, up from something like 13 or so at one time, but I date myself.

I enjoy discussion, too bad we can't do it over coffee, a beer, or even a Cutty on cubes! 
Peace, Dale

[92merc]

Cutty, that explains a lot.  I did notice my used count go down quite a bit.  But way early on the red system, I was one of the few farther western stations.  There has been a big growth since.  But I'm sure some of it is due to the new processing.

I don't think my system is as optimized as I'd like it to be.  I think one of the big things I need to do is move my H field system up into my attic.  It's a bit too close to my electrical panel for my liking.  And I need to shield it a bit from my garage door openers.  I noticed those trigger it.

I'm glad to hear they are still working on the systems.  That's my main concern.  I saw the MicroSferics project somewhat moving forward.   Just wanted to make sure the Blitz system will still be around for a bit.

My plan is to finish my one wall in the garage off with sheet rock.  Run some new network wires so that I can put a security camera system out there.  Then I'll move the H-Field and all of that equipment to a shelf near the DVR.  And then move my PI Radio out there with an antenna in the attic for better reception.  So yeah, my garage will be networked!

[Cutty Sark Sailor]

Hi Mike,
............I thought I had updated to ver. 8.x a couple of years ago (I can't recall exactly when and what). 


Should I upgrade?  and what preparation should I do to help avoid any catastrophe?


Thanks,
Paul

Paul, I suggest downloading all the 8 and 9 series firmware to local storage.
Then upload latest to controller.  Now.... I think part of this may have to do with specific controller build series,...
there are some quirks in the 9 series firmware... usually manifesting with GUI performance... that have to do with memory load, and sourcing external scripts not stored locally.  Also with server sent controls... there are some commands and 'filters' set from, and controlled by the server which are not enabled by the older firmware... most are invisible.
Disregard any references to 'DSP filter' in tracker settings, as that IS 'enabled' on the controllers, BUT not fully implemented, and may cause some glitches in signal display, so leave it unchecked.
You will notice some 'behavior' changes perhaps in the way the watchdogs and interference algorthims work,., subtle. 
Some folks have reported better operation with 9.1 other than 9.2... there are some differences, so choose your poison, but I'd go straight to 9.2, see how it feels to you, and may refevert down to 9.1 if any gui crazies bother you.
Either way, when your system gets REALLY active, as the season begins, you may be bugged by GUI issues at times due the the extreme load on controller memory, and possible packet density... grit teeth, smile, and maybe reduce signal gains to reduce data.


While I have this keyboard hot...
Folks, observe your signals on your station link.. pay close attention to something at the very far left: 

that "Sieve-Corr" / "Filter-Corr"

Note ONE channel is coded 'valid'  (that is the single channel from your data for that impulse that the server as selected to be 'best', and a candidate for further examination. the others are 'discarded'.

The "Sieve"  is your stations 'DNA" for the last 1000 valid signals received from you.  "This" signal is 14000ns behind the 'red' channel's 'DNA" , (if it were 'ahead', the figure would be -)  so 14000ns is considered .   IF the optional filter (BLUE ONLY) are engaged, a 'standard' time correction is applied, based on that filter setting. Normally, the 'selected' 'sieve' channel will be the 'least' time corrected, however, you will often see quite a large correction applied on a 'valid' (selected) channel, even though the 'corr' is actually smaller on another channel... remember there are other parameters...

So, IF you have a lot of NOISE junk accumulated in the 'sieve' , then junk in = junk out, when a valid impulse arrives.  If you're switching Filters in and out, you are again 'modulating' your DNA...  One of the harder 'adjustments' that screw with things, is the 'relative' gain.. each controller is made 'relative' to every other one for time, trigger point, etc... Relative Gain the computed on the Controller, based on a Threshold (trigger) of 100mv.  If you use a trigger level different than 100mv, the contoller attempts to modify that relative gain data.  So, if in automatic, that 'relative gain' compuitation happens more frequently, and possibly with extra steps, which can really begin to screw with your Server expected DNA... so I suggest optimize to 100mv if valid for you, to perhaps decrease math ops, and certainly avoid as many' gain' and other parameter changes as possible.
If you are constantly ( READ: 'Automatic', or other tracker settings')  chainging gains, thresholds, etc, you are messing with your "DNA".

Hint: if you see consistent 'large' corrections, you probably have a lot of junk to overwrite in the sieve, the storms are REALLY moving fast  , (or moving backwards?   )    or you've got a bunch of rapidly changing variables accumulated in the 'DNA' bank...

...remember, you've got to overwrite UP TO 1000 valid signals before drastic parameter changes are accepted as the 'new normal DNA' for your system!

...draw your own conclusions...