Author Topic: Station Signals - Tool - Region 3  (Read 12031 times)

0 Members and 1 Guest are viewing this topic.

Offline Cutty Sark Sailor

  • WxElement panel
  • Forecaster
  • *****
  • Posts: 2751
    • Frankfort Weather - TwinHollies WeatherCenter
Re: Station Signals - Tool - Region 3
« Reply #50 on: May 24, 2015, 11:32:35 AM »
A bit behind on updates, but today added 2 new stations to the signals page... http://sferics.us
1345 Marion Iowa
1346 Bobcaygeon Ontario Canada
All active 'AMERICAS' (ex-'Region 3') stations should now have their server received 'signals' and 'FFTs' available... excluding the Green Stations, as Egon has gradually changed the processing to handle the more implicit RED data.  Note that "Greens" are not ignored, just the signal data at this source is not available.  Note also that the 'signals' server was offline for approximately 24 hours, but is back up as this is written...

Cheers!
Mike

CoCoRaHS KY-FR-1  CWOP DW5536

       Blitzortung
       689
& 1439

sferics.us

 


Offline schwab

  • Senior Member
  • **
  • Posts: 70
Reprogramming to Post Signals from Green Stations
« Reply #51 on: May 25, 2015, 07:17:50 AM »
Signals from Green Stations are displayed on www.lightningmaps.org under the station tab but not on Blitzortung.org or sferics.us

Is there a way these already viewable signals can be posted for green stations again on Blitzortung.org so they will then ultimately appear on sferics.us?

Thanks.

Offline Cutty Sark Sailor

  • WxElement panel
  • Forecaster
  • *****
  • Posts: 2751
    • Frankfort Weather - TwinHollies WeatherCenter
Re: Station Signals - Tool - Region 3
« Reply #52 on: May 25, 2015, 09:18:31 AM »
My info from Egon is that the signal source should already be changed to another source, temporarily, with another change in access upcoming in a week or two... and I'll 'skate' by as long as I can with those pages, knowing at least one more 'update' will be required. I do not know if Greens will be available at that source after this move.  This will be about the third/fourth change, so kinda waiting for a 'permanent' location, as the signals site will have to be 'rewritten' to some degree.... Yes, we could pull the LMO green signals, with a bit of a hack or two, but they would be what you already see on LMO, with a variation or two...  but it would be better, at this end, to wait until the server changes are all made. I'm sorry, but I just don't have a better answer for now.

CoCoRaHS KY-FR-1  CWOP DW5536

       Blitzortung
       689
& 1439

sferics.us

 


Offline Cutty Sark Sailor

  • WxElement panel
  • Forecaster
  • *****
  • Posts: 2751
    • Frankfort Weather - TwinHollies WeatherCenter
Re: Station Signals - Tool - Region 3
« Reply #53 on: July 28, 2015, 10:18:24 AM »
Possible circumstantial frequency display error in FFT System Red discovered: 
Americas operators, see http://sferics.us/bo1/index.php?topic=180.0

Also found signal access for GREEN stations, need help implementing into current pages structure, however.

CoCoRaHS KY-FR-1  CWOP DW5536

       Blitzortung
       689
& 1439

sferics.us

 


Offline Cutty Sark Sailor

  • WxElement panel
  • Forecaster
  • *****
  • Posts: 2751
    • Frankfort Weather - TwinHollies WeatherCenter
Re: Station Signals - Tool - Region 3
« Reply #54 on: March 01, 2016, 08:17:33 AM »


From Tobi (Jan 24th 2012):

Quote
The zigzag is inserted by the server, not by the station! The threshold to decide whether it's encoded as noise or not depends on the noise floor value for each channel separately. It is multiplied by a percentage which is defined by the server (currently 50%). Example: Noise floor is 40mVpp with 50% -> Everything below 20mVpp is encoded as noise. There's also a noise gap value, which means that noise encoding stops/starts a defined distance before/after non-noise. This value is currently set to 5.

 To be more exactly, it's not just one threshold but a minimum and maximum value where noise is allowed. To continue with the example, the noise floor of 40mVpp is a result of measured noise peaks between -10mV to 30mV. Then a factor of 50% will result in 0mV to 20mV min/max threshold for noise encoding. This means, noise with a DC offset will not be encoded! The maximum block length is 64 samples. The encoding itself needs 3 bytes, which results in a max. compression of 95%. A lot of (close) lightning produces only short peaks, which means that most data before and after a peak can be saved as noise. Yes, we loose some (unnecessary) information, but due to the high efficiency we benefit at other places (network, server bandwidth and data processing).

 Other values in the signals are delta encoded which uses 4bit instead of 8bit for each value. The max. compression is 35/67 = 48%.

 If the delta encoding doesn't work due too high deltas (> 7), then the samples will be saved as their raw values.

 The encoding applies to each signal data separately. Before sending all the data, the whole UDP packet can be compressed. On the status page you can see the encoding efficiency for each channel and the compression efficiency for each server. Higher values are better.

These 'coding' triggers are only visible on the server side station signals... not on your 'local' display. They may or may not be displayed depending on how the developers are running Server at any given time, and what they're looking for. (Hint, Hint...)

CoCoRaHS KY-FR-1  CWOP DW5536

       Blitzortung
       689
& 1439

sferics.us

 


 

anything