[hpsdr] GPSDR_io - An open standard for time-stamped RF data exchange.

[Mike Hamel]

Van,

I like your idea for an open standard for timestamping raw A/D samples
(or possibly 1 stamp for a block of samples given overhead?). This is
quite a fascinating subject.

In terms of multilateration, the resolution might also be limited by
wavelength as well as the timing jitter. Put another way it will never
be better than your 50 foot example with 50nS jitter, but it intuitively
seems there must be a frequency dependent component in there as well,
depending on how many degrees of carrier phase can be resolved.

> This even works for noise sources that are stationary, anyway, you get
> the idea.

That brings up another thing I was wondering about HPSDR features (here
I go off topic again, sorry).

Do any of the SDR software packages make use of multiple RX frequencies
to cancel static crashes on the low bands?  For example tune an
auxilliary channel to a quiet place (if there is such a thing) out of
band and subtract signals that appear common to both frequencies?  I'm
sure this must've been done but I haven't seen the feature documented.
It would seem like a great feature for low bands this time of year.

This is very cool stuff.

Mike
wo1u

L. Van Warren wrote:
> ***** High Performance Software Defined Radio Discussion List *****
> 
> We have a chance to make history, with an array of GPS disciplined SDR's -
> GPSDR's for short
> 
> This is the ham radio equivalent of HTML - a "lingua franca" for RF data
> exchange.
> 
> Enabling radio amateurs to share signals + timing information over the
> internet from their GPSDR's opens an amazing vista of experimentation and
> opportunity.
> 
> It requires defining AND implementing a way of doing business where business
> = GPS disciplines Oscillator time-stamps SDR spectral buffers.
> 
> Those signals common to 4 such receivers can be uniquely located in
> space-time regardless of their location using multilateration.
> 
> Mapping signal location leads to discovery, mundane as in your light dimmer
> or microwave oven, exciting as in tracking black holes, satellites, etc.
> 
> If we could figure out how to do it with SoftRocks, that would be awesome
> and cost-effective. For technical reasons we need hardware with RF ADC's.
> 
> Why? In a nutshell, the time stamp has to be put on the RF sample buffer
> before down conversion, or a huge amount of time (and therefore position)
> resolution is lost, proportional to the frequency multiple of the carrier
> and the "audio" signal. For example 10 MHz / 10 kHz = 1000 fold uncertainty.
> 
> If the limit on GPS disciplined oscillators is 50 nanoseconds of jitter and
> light travels 1 foot per nanosecond, the time-stamped RF buffer approach can
> locate a signal to 50 feet give or take. But if we downconvert first and
> correlate, this increases to 50,000 feet, or about 10 miles. Not such a
> great foxhunt. So we don't downconvert before correlation.
> 
> The problem is that continuous RF sample buffers are too large to ship over
> the internet for cross-correlation.
> 
> One solution is to place all the GPSDR's in a short period listening mode,
> where they listen for a few milliseconds, share information for correlation,
> etc. "Listen, share, correlate."
> 
> Once signals are located through this shared correlation process, the
> time-stamp can be replaced by a position stamp, the samples can be
> downconverted, and the continuous (audio) signal can be shared for
> traditional SDR consumption via a Panadapter, spectral, or waterfall
> display, or for our dear blind friend Ron - a good pair of binaural
> headphones.
> 
> "Listen, share and correlate" is inherently parallel and with enough radio
> amateurs, becomes a novel form of "cloud computing" with applications to
> every slice of the RF spectrum for which sampling receivers can be built.
> 
> This even works for noise sources that are stationary, anyway, you get the
> idea.
> 
> An open standard for data exchange would include all the sampling receivers
> currently on the market with the flexibility to produce the format.
> 
> So what can I do? I can define the format of time stamped spectral sample
> buffers and conversion to packets (torrents?) I can define packet exchange
> topologies that scale. I can write some software to simulate this.  I will
> submit a strawman. You can help out by providing your ADC format, and
> remembering I can't solder...
> 
> 
> 73's
> 
> Van / AE5CC / wdv.com
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
> 

 1249261664.0