Signal recording possibility?

[kaklik]

Hello,

is there some option to record raw signal samples from system Blue?  We want to use the blitzortung station as trigger unit for other devices onboard the storm chasing cars.

For now, we have the system Blue station installed on board of the car as a mobile device. It seems the station could be relatively effectively used for waveform visualization in "monitor" mode. But it could not be used for scientific analysis until we have the raw signal waveforms of each lightning.

We are especially interested in the "nearby lightning" e.g. up to 20km from the car. I suspect the range could be partially selected by altering the gain.

As a partial solution to the signal recording, we tried to sniff the UDP packets sent to the servers. But unfortunately, the signals seem to be filtered and only a portion of detected signals are really sent to the servers.

[cutty]

Hello,

is there some option to record raw signal samples from system Blue?  We want to use the blitzortung station as trigger unit for other devices on board the storm chasig cars.

For now we have the system Blue station instilled on board of the car as mobile device. It seems the station could be relatively effectively used for waveform visualization in "monitor" mode. But it could not be used for scientific analysis until we have the raw signal wave forms of each lightning.

We are especially interested in the "nearby lightning" e.g. up to 20km from the car. I suspect the range could be partially selected by altering the gain.

As partial solution of the signal recording we tried to sniff  the UDP packets sent to the servers. But unfortunately, the signals seems to be filtered and only a portion of detected signals are really send to the servers.

What is your User ID and Station Number?
Need to confirm and upgrade your status.

Each system BLUE has test outputs, optional, install SMA jacks.  One of those outputs is RAW analog signal prior to  ADC.  You could shape trigger with that.  BUT it would only be a 'trigger'.  I'd suggest the E channel, since it's basically 'omni', while the H channels are lobed.  The 'signal characteristics' are actually done on the server, not the controller.  A single BT station is simply a wideband analog to digital receiver. It doesn't know where it is, for example. It will send that periodically, but doesn't remember it. All it uses is the synced 1PPS. The server  knows, however.  So you keep moving around, server may decide you have a GPS problem, for example.
Not designed for your application, as such.

Second... distance is NOT related to an individual unit. This is not a 'stand alone' system. It depends on the network to calculate. Local  doesn't know where the stroke occurred, just that it did. All you'd have 'locally' is YOUR signal data, not the computed analysis. 

Correct on the compression. That is decided  by the controller, relative to some feedback on occasion from the server. Not all data needed for BT purposes, currently, so it's not sent to save BW,etc.  And when it reaches the servers more adjustments are made. Your are 'relative' to every other station, and a GPS sync.   Secondly, on the server, a 'footprint' for your data characteristics is maintained,  and incoming signals compared... so if you keep moving, that 'footprint' is apt to change, and it's possible for the server to consider your 'new signals' not-valid, since  your spatial movements keeps changing the time  relativity between 'expected' impulse signals.

[kaklik]

What is your User ID and Station Number?
Need to confirm and upgrade your status.

Thanks for your answer!

I had accounts separated from our stations, because we have a single account to maintain multiple stations by multiple people.  The station which I use by described scenario is 2375, but I think it is factically irrelevant.

Each system BLUE has test outputs, optional, install SMA jacks.  One of those outputs is RAW analog signal prior to  ADC.  You could shape trigger with that.  BUT it would only be a 'trigger'.  I'd suggest the E channel, since it's basically 'omni', while the H channels are lobed.  The 'signal characteristics' are actually done on the server, not the controller.  A single BT station is simply a wideband analog to digital receiver. It doesn't know where it is, for example. It will send that periodically, but doesn't remember it. All it uses is the synced 1PPS. The server  knows, however.  So you keep moving around, server may decide you have a GPS problem, for example.
Not designed for your application, as such.

Second... distance is NOT related to an individual unit. This is not a 'stand alone' system. It depends on the network to calculate. Local  doesn't know where the stroke occurred, just that it did. All you'd have 'locally' is YOUR signal data, not the computed analysis. 

Correct on the compression. That is decided  by the controller, relative to some feedback on occasion from the server. Not all data needed for BT purposes, currently, so it's not sent to save BW,etc.  And when it reaches the servers more adjustments are made. Your are 'relative' to every other station, and a GPS sync.   Secondly, on the server, a 'footprint' for your data characteristics is maintained,  and incoming signals compared... so if you keep moving, that 'footprint' is apt to change, and it's possible for the server to consider your 'new signals' not-valid, since  your spatial movements keeps changing the time  relativity between 'expected' impulse signals.

Yes, I know all of that. That is described somewhere in the system documentation. I narrow my question, therefore.
We want to use the station as a lightning signal analog conditioner and analog to digital converter. Therefore I look for a digital signal representation of each lightning signal received by our stations.
In case if there is a possibility of not interrupting the classic station mode working in the blitzortung network. It would be a bonus, but it is not necessary from our side. We do not need to force your servers to use our station's data to locate lightning. We need the signal to analyze the different characteristics of lightning.
For example, we are interested in research of lightning initiation by cosmic rays. For such research, we need an instrument, which could describe the spatial evolution of lightning. Although, I am perfectly aware that blitzortung station is not fully capable of that, the blitzortung station is the perfect tool to obtain general evidence of lightning activity.
Unfortunately, the blitzortung system design seems to throw away some of the relevant lightning events.  We noticed that, the real-time lightning map is far more detailed (a flash of single lightning is normally described by multiple points, which are mostly valid), but the archive data are filtered and most of the flashes of lightning are compressed to a single point and some real lightning disappears completely.  That is our motivation why we need "raw data".