GPS Timestamped I/Q data #software


Martin - G8JNJ
 

Hi All,

Does anyone know of a method to receive using Airspy products and then accurately GPS time stamp the I/Q data using Spyserver or any other software.

I'd like to be able to accurately compare signals from several remote receivers in order to process the data, and ideally perform Time Difference of Arrival (TDoA) calculations in a similar manner to that which can be achieved with the KiWi SDR network, however this is for a different application and purpose.

Regards,

Martin


prog
 

On Sat, Aug 21, 2021 at 06:07 PM, Martin - G8JNJ wrote:
Hi All,

Does anyone know of a method to receive using Airspy products and then accurately GPS time stamp the I/Q data using Spyserver or any other software.

I'd like to be able to accurately compare signals from several remote receivers in order to process the data, and ideally perform Time Difference of Arrival (TDoA) calculations in a similar manner to that which can be achieved with the KiWi SDR network, however this is for a different application and purpose.

Regards,

Martin
It's possible, but this will require a full rewrite of the firmware, lib and server software.


Martin - G8JNJ
 

On Sat, Aug 21, 2021 at 09:31 PM, prog wrote:
It's possible, but this will require a full rewrite of the firmware, lib and server software.
Thanks for the prompt reply.

OK understood, I guess that's not a realistic option to consider.

Can anyone else provide suggestions about other ways to achieve this, perhaps using GNU Radio ?

Regards,

Martin


prog
 

Unless you are processing the samples in a FPGA in the hardware, it will be extremely challenging using a pure software stack. It's not impossible, but it's not worth the time and effort either. 


jdow
 

That depends on the accuracy he needs. If he's happy within say a thousand feet it may be easier than one foot. And a km is even easier. It would take some moderately long term averaging to get rid of typical sources of system latency. It's a challenge for a masochist, though.

{o.o}

On 20210822 03:33:31, prog wrote:
Unless you are processing the samples in a FPGA in the hardware, it will be extremely challenging using a pure software stack. It's not impossible, but it's not worth the time and effort either. 


Martin - G8JNJ
 

It's for a BRAMS type project with a wider baseline of receivers.

https://brams.aeronomie.be/

Regards,

Martin


Greg Ella
 

MIT Haystack has developed an I/Q recording format that saves metadata along with the I/Q stream.
It is called digital_rf.  Here is a link to their Github: https://github.com/MITHaystack/digital_rf

These guys were GPS time stamping wireless sensor data:  https://www.frontiersin.org/articles/10.3389/fbuil.2018.00082/full

Lastly, if you use the PPS output of a GPS module to trigger a very narrow pulse, and feed it into the front end of your SDR at an appropriate level,
you will see an accurately timed broadband noise tick every second in your I/Q data.

Greg Ella
N0EMP


On Sun, Aug 22, 2021 at 9:15 AM Martin - G8JNJ via groups.io <martin_ehrenfried=yahoo.com@groups.io> wrote:
It's for a BRAMS type project with a wider baseline of receivers.

https://brams.aeronomie.be/

Regards,

Martin


jdow
 

OK, what degree of synchronization do they think they are getting? If one channel is audio and the other the GPS clock's 1 second pip the accuracy in an individual can be about 5 microseconds with 192 ksps sample rate. If it is a four channel sound card it can be estimated somewhat closer. But a mile is a handy number for my thinking so that's it. {^_-} And you still have a little ambiguity "which time tick is it". But that can be captured well enough other ways.

That leaves out simultaneous reception of WWV or other time service as ionospheric layers wobble around a whole lot more than a mile. So let's twiddle mental thumbs a minute to think.
...
(Comes back with an idea to try.)

How about a T in the coax with a small series capacitor to the GPS receiver's 1 PPS signal? If it has a good enough rising edge it should allow a fine calibration of the AirSpy's samples to the time tick. Then time interpolation is merely counting samples. Keep the level as low as possible so that you don't destroy (much) data. You might reduce data and pulse collisions by only running this alignment process once an hour or so. And be sure to drag out of the data the actual clock rate of the AirSpy to make it all as accurate as possible. This would require special software. But if this is coupled with a university somewhere the whole package could possibly come in cheaper than the R-75 alone. I bet a moderately fast R-Pi or Arduino could do the job. And it would improve time accuracy to about well under 100 meters. (More like100' actually.)

{^_^}

On 20210822 08:15:38, Martin - G8JNJ via groups.io wrote:
It's for a BRAMS type project with a wider baseline of receivers.

https://brams.aeronomie.be/

Regards,

Martin


Greg Ella
 

Exactly.  The "time tick" each second is being recorded with the RF, not at an audio rate.  If the computer itself is on an NTP time server,
and accurate to within perhaps 100 ms, you know which second you are in, and the time tick gives you a marker for the start of the second,
accurate to within 40 ns.  Any system delays such as asynchronous USB interface affect the signal of interest and the time tick congruently,
so any errors there are cancelled out.

Greg Ella
N0EMP


On Sun, Aug 22, 2021 at 3:39 PM jdow <jdow@...> wrote:
OK, what degree of synchronization do they think they are getting? If one channel is audio and the other the GPS clock's 1 second pip the accuracy in an individual can be about 5 microseconds with 192 ksps sample rate. If it is a four channel sound card it can be estimated somewhat closer. But a mile is a handy number for my thinking so that's it. {^_-} And you still have a little ambiguity "which time tick is it". But that can be captured well enough other ways.

That leaves out simultaneous reception of WWV or other time service as ionospheric layers wobble around a whole lot more than a mile. So let's twiddle mental thumbs a minute to think.
...
(Comes back with an idea to try.)

How about a T in the coax with a small series capacitor to the GPS receiver's 1 PPS signal? If it has a good enough rising edge it should allow a fine calibration of the AirSpy's samples to the time tick. Then time interpolation is merely counting samples. Keep the level as low as possible so that you don't destroy (much) data. You might reduce data and pulse collisions by only running this alignment process once an hour or so. And be sure to drag out of the data the actual clock rate of the AirSpy to make it all as accurate as possible. This would require special software. But if this is coupled with a university somewhere the whole package could possibly come in cheaper than the R-75 alone. I bet a moderately fast R-Pi or Arduino could do the job. And it would improve time accuracy to about well under 100 meters. (More like100' actually.)

{^_^}

On 20210822 08:15:38, Martin - G8JNJ via groups.io wrote:
It's for a BRAMS type project with a wider baseline of receivers.

https://brams.aeronomie.be/

Regards,

Martin


jdow
 

Well, the time tick maybe accurate to that 40 ns level; but, the audio has a sampling granularity of 5 us when sampling at 192 ksps. So I suspect the tick coupled to the AirSpy input could potentially improve sampling time granularity down to 100 ns. Interpolating down to more precision would be easier with the AirSpy. The time between meteors could be filled with precision enhancing tests. And, of course, the GPS derived time can be captured by the special SDR tool it would take to do all this. Some EE masters degree candidate could have a wonderful thesis project to design and code the receiver. Actually several people could get papers out of it. With some of the serious GPSDOs out there you get both time, time tick, and location. All that could be coded into the data file using a WAV type format. Additional hunks of data with header types that one program understands should be safe when played back on a program that does not understand that hunk type. (That is a good test for tools that save and play data files. Are they safe with hunk types it does not understand and does it play the file back as best it can?)

{^_^}

On 20210822 17:37:17, Greg Ella wrote:
Exactly.  The "time tick" each second is being recorded with the RF, not at an audio rate.  If the computer itself is on an NTP time server,
and accurate to within perhaps 100 ms, you know which second you are in, and the time tick gives you a marker for the start of the second,
accurate to within 40 ns.  Any system delays such as asynchronous USB interface affect the signal of interest and the time tick congruently,
so any errors there are cancelled out.

Greg Ella
N0EMP


On Sun, Aug 22, 2021 at 3:39 PM jdow <jdow@...> wrote:
OK, what degree of synchronization do they think they are getting? If one channel is audio and the other the GPS clock's 1 second pip the accuracy in an individual can be about 5 microseconds with 192 ksps sample rate. If it is a four channel sound card it can be estimated somewhat closer. But a mile is a handy number for my thinking so that's it. {^_-} And you still have a little ambiguity "which time tick is it". But that can be captured well enough other ways.

That leaves out simultaneous reception of WWV or other time service as ionospheric layers wobble around a whole lot more than a mile. So let's twiddle mental thumbs a minute to think.
...
(Comes back with an idea to try.)

How about a T in the coax with a small series capacitor to the GPS receiver's 1 PPS signal? If it has a good enough rising edge it should allow a fine calibration of the AirSpy's samples to the time tick. Then time interpolation is merely counting samples. Keep the level as low as possible so that you don't destroy (much) data. You might reduce data and pulse collisions by only running this alignment process once an hour or so. And be sure to drag out of the data the actual clock rate of the AirSpy to make it all as accurate as possible. This would require special software. But if this is coupled with a university somewhere the whole package could possibly come in cheaper than the R-75 alone. I bet a moderately fast R-Pi or Arduino could do the job. And it would improve time accuracy to about well under 100 meters. (More like100' actually.)

{^_^}

On 20210822 08:15:38, Martin - G8JNJ via groups.io wrote:
It's for a BRAMS type project with a wider baseline of receivers.

https://brams.aeronomie.be/

Regards,

Martin



Martin Smith
 

I've often wondered if it would be possible to use something like an up converter to deliberately inject an extremely attenuated signal directly into the antenna. So you would take the 1 pulse per second (PPS) signal from GPS (typical pulse width is generally 100 ms on, 900 ms off) and use that signal to enable/disable either a RF switch between an oscillator and a dummy load or the chip select/enable pin on a direct digital synthesis (DDS) chip producing a sine wave.


jdow
 

I'm having nightmares with the problems here. Switching on and off the reference voltage for a DDS is probably the best choice. But I bet even that would generate spurious glitches, which arguably provide more accurate ticks than a modulated signal.

The Phase IIb GPS satellites included a transmitter on a different frequency that was related to the nuclear detonation detection systems. The fellow who developed the circuit used what was essentially an on off switch using a single balanced mixer approach with a transmission line transformer. It has a REALLY annoyingly bad waveform. The fast rising and falling edges of the keying introduced glitches onto the signal. I was wandering around one day waiting for inspiration on what I was supposed to be doing when I noticed they had a problem. I volunteered to help. That was arranged (security issues). I identified the problem rapidly as I'd seen the like before. I ended up introducing an opposite polarity version of the modulation signal through a very small capacitor. That's why I suggest making that noise a feature and using it for a permanent calibration signal on the AirSpy input. You're not going to eliminate it with most any simple design. So making it a feature really appeals to me.

{^_^}

On 20210822 19:23:43, Martin Smith via groups.io wrote:
I've often wondered if it would be possible to use something like an up converter to deliberately inject an extremely attenuated signal directly into the antenna. So you would take the 1 pulse per second (PPS) signal from GPS (typical pulse width is generally 100 ms on, 900 ms off) and use that signal to enable/disable either a RF switch between an oscillator and a dummy load or the chip select/enable pin on a direct digital synthesis (DDS) chip producing a sine wave. 






David J Taylor
 

On 23/08/2021 01:37, Greg Ella wrote:
Exactly.  The "time tick" each second is being recorded with the RF, not at an
audio rate. If the computer itself is on an NTP time server,
and accurate to within perhaps 100 ms, you know which second you are in, and
the time tick gives you a marker for the start of the second,
accurate to within 40 ns.  Any system delays such as asynchronous USB interface
affect the signal of interest and the time tick congruently,
so any errors there are cancelled out.

Greg Ella
N0EMP
Adding a GPS/PPS to a Windows PC with a COM port you can get much better than
100 ms - sub-millisecond is easily possible (see attached).

With a Linux Raspberry Pi and GPS/PPS even from a simple puck antenna and $50
interface you can get tens of microseconds.

73,
David Gm8ARV
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv


Martin - G8JNJ
 

On Sun, Aug 22, 2021 at 09:39 PM, jdow wrote:
How about a T in the coax with a small series capacitor to the GPS receiver's 1 PPS signal?
Yes that's the method I used to help initially calibrate the KiWi sdr TDoA function when John and Christoph were developing it. It's a handy method as you are injecting right at the start of the receive chain, so all the group delay and other system propagation issues are in play, and can then be calibrated out at a later stage. The KiWi is ideal for this because it contains a built in GPS receiver, and with all the receivers in the network being the same, you don't get much variation in timing or processing delays between them.

I think the best solution my be to go down the RF 'tick' route, but with additional 'coarse' timing markers added in some way, possibly by adding a modulated carrier on an adjacent frequency that could be within the received passband and I/Q stream, which could then be separately decoded during the downstream signal processing stage.

Regards,

Martin


Greg Ella
 

jdow: There is no audio, and there is no 192 ksps sampling. a narrow square pulse triggered by the 1pps will be
broadband RF, and it will be sampled at whatever nnMHz sampling rate the SDR uses, and it will be in the same RF I/Q
data stream as the signal of interest.  If the Original Poster is designing a system at 49 MHz, it is trivial to make a square wave with sharp
enough edges to be visible up there.  A lower frequency analogy is when you are looking at the lower HF bands with a waterfall display and
your neighbor has an electric fence that is sparking.  Every time it sparks, you see a horizontal line all the way across the waterfall.

If the OP is designing a fixed frequency system, he could also trigger a small oscillator at a nearby frequency, maybe 50 KHz away from
their system frequency, still within the receive bandwidth of the SDR.

Greg Ella
N0EMP


On Mon, Aug 23, 2021 at 3:39 AM Martin - G8JNJ via groups.io <martin_ehrenfried=yahoo.com@groups.io> wrote:
On Sun, Aug 22, 2021 at 09:39 PM, jdow wrote:
How about a T in the coax with a small series capacitor to the GPS receiver's 1 PPS signal?
Yes that's the method I used to help initially calibrate the KiWi sdr TDoA function when John and Christoph were developing it. It's a handy method as you are injecting right at the start of the receive chain, so all the group delay and other system propagation issues are in play, and can then be calibrated out at a later stage. The KiWi is ideal for this because it contains a built in GPS receiver, and with all the receivers in the network being the same, you don't get much variation in timing or processing delays between them.

I think the best solution my be to go down the RF 'tick' route, but with additional 'coarse' timing markers added in some way, possibly by adding a modulated carrier on an adjacent frequency that could be within the received passband and I/Q stream, which could then be separately decoded during the downstream signal processing stage.

Regards,

Martin


Martin Smith
 

On Mon, Aug 23, 2021 at 06:02 AM, jdow wrote:


I'm having nightmares with the problems here.
I was just trying to think of the cheapest way of prototyping to test the idea.

You could do it digitally, always starting the synthesised sine wave at zero amplitude on the rising edge of the 1 PPS signal and stopping the sine wave sometime after the falling edge whenever the amplitude again reaches zero. Or even just ignore the falling edge all together and just transmit a fixed number of sine wavelengths always starting and finishing with zero amplitude. The device would still need to be able to tune the frequency of the up-converter to be near the signal of interest and you would always want to calibrate the synthesised signal with maximum attenuation and slowly stepping down the attenuation until a detectable signal level was reached. I was thinking of near field coupling to the antenna, because of cost, but maybe use a power combiner.

It would be an oddball GPS controlled almost Morse code like transmitter. If it works then you have then you have moved the synchronisation problem over to software.


Carlos Cabezas
 

A PRBS sequence triggered with GPS PPS and modulated into the baseband FI passband would be ideal. It would be easy to couple inside AirSpy receiver, even without any soldering.

Carlos
EB4FBZ

El mar., 24 ago. 2021 9:23, Martin Smith via groups.io <martin_z_smith=yahoo.ie@groups.io> escribió:
On Mon, Aug 23, 2021 at 06:02 AM, jdow wrote:

>
> I'm having nightmares with the problems here.

I was just trying to think of the cheapest way of prototyping to test the idea.

You could do it digitally, always starting the synthesised sine wave at zero amplitude on the rising edge of the 1 PPS signal and stopping the sine wave sometime after the falling edge whenever the amplitude again reaches zero. Or even just ignore the falling edge all together and just transmit a fixed number of sine wavelengths always starting and finishing with zero amplitude. The device would still need to be able to tune the frequency of the up-converter to be near the signal of interest and you would always want to calibrate the synthesised signal with maximum attenuation and slowly stepping down the attenuation until a detectable signal level was reached. I was thinking of near field coupling to the antenna, because of cost, but maybe use a power combiner.

It would be an oddball GPS controlled almost Morse code like transmitter. If it works then you have then you have moved the synchronisation problem over to software.






jdow
 

Now you must figure out the software latency and worse latency variation on that PRBS signal. You MIGHT make it wotk with a synthesizer chip that places a signal roughly where you are working and take it's output and play WWV with it. Feed it though a DBM with the "IF" port fed by a +/- 10 ma signal. For 50 seconds send time information with approximately 5 seconds before and after the actual tick blanked. The tick also feeds this mixer drive directly from the GPS time receivers 1PPS output. The Trimble unit I am running is close enough in time that the length of cable becomes interesting. And it gives you the time error to boot. A wee little PI or Arduino could receive the pulse along with the modulator. That triggers it to ask the GPS unit what time it is and what the tick's offset is. But, feeding that tick DIRECTLY to the modulator is what gives you potential for insane levels of accuracy.

{^_^}

On 20210824 01:47:12, Carlos Cabezas wrote:
A PRBS sequence triggered with GPS PPS and modulated into the baseband FI passband would be ideal. It would be easy to couple inside AirSpy receiver, even without any soldering.

Carlos
EB4FBZ

El mar., 24 ago. 2021 9:23, Martin Smith via groups.io <martin_z_smith=yahoo.ie@groups.io> escribió:
On Mon, Aug 23, 2021 at 06:02 AM, jdow wrote:

>
> I'm having nightmares with the problems here.

I was just trying to think of the cheapest way of prototyping to test the idea.

You could do it digitally, always starting the synthesised sine wave at zero amplitude on the rising edge of the 1 PPS signal and stopping the sine wave sometime after the falling edge whenever the amplitude again reaches zero. Or even just ignore the falling edge all together and just transmit a fixed number of sine wavelengths always starting and finishing with zero amplitude. The device would still need to be able to tune the frequency of the up-converter to be near the signal of interest and you would always want to calibrate the synthesised signal with maximum attenuation and slowly stepping down the attenuation until a detectable signal level was reached. I was thinking of near field coupling to the antenna, because of cost, but maybe use a power combiner.

It would be an oddball GPS controlled almost Morse code like transmitter. If it works then you have then you have moved the synchronisation problem over to software.







Carlos Cabezas
 

Then the problem will be how to decide or trigger when the tick exactly happened with enough accuracy. I already tried a similar idea, using a strong noise generator switched into the RF input with a solid state switch driven by PPS, and it was not possible to determine where the burst starts accurately. That's the magic of a PRBS.

In my mind, this could be implemented with a FPGA or CPLD clocked at 100MHz. Generating a BPSK modulated PRBS at 4-5MHz directly.

Carlos


El 24/08/2021 a las 11:11, jdow escribió:
Now you must figure out the software latency and worse latency variation on that PRBS signal. You MIGHT make it wotk with a synthesizer chip that places a signal roughly where you are working and take it's output and play WWV with it. Feed it though a DBM with the "IF" port fed by a +/- 10 ma signal. For 50 seconds send time information with approximately 5 seconds before and after the actual tick blanked. The tick also feeds this mixer drive directly from the GPS time receivers 1PPS output. The Trimble unit I am running is close enough in time that the length of cable becomes interesting. And it gives you the time error to boot. A wee little PI or Arduino could receive the pulse along with the modulator. That triggers it to ask the GPS unit what time it is and what the tick's offset is. But, feeding that tick DIRECTLY to the modulator is what gives you potential for insane levels of accuracy.

{^_^}

On 20210824 01:47:12, Carlos Cabezas wrote:
A PRBS sequence triggered with GPS PPS and modulated into the baseband FI passband would be ideal. It would be easy to couple inside AirSpy receiver, even without any soldering.

Carlos
EB4FBZ

El mar., 24 ago. 2021 9:23, Martin Smith via groups.io <martin_z_smith=yahoo.ie@groups.io> escribió:
On Mon, Aug 23, 2021 at 06:02 AM, jdow wrote:

>
> I'm having nightmares with the problems here.

I was just trying to think of the cheapest way of prototyping to test the idea.

You could do it digitally, always starting the synthesised sine wave at zero amplitude on the rising edge of the 1 PPS signal and stopping the sine wave sometime after the falling edge whenever the amplitude again reaches zero. Or even just ignore the falling edge all together and just transmit a fixed number of sine wavelengths always starting and finishing with zero amplitude. The device would still need to be able to tune the frequency of the up-converter to be near the signal of interest and you would always want to calibrate the synthesised signal with maximum attenuation and slowly stepping down the attenuation until a detectable signal level was reached. I was thinking of near field coupling to the antenna, because of cost, but maybe use a power combiner.

It would be an oddball GPS controlled almost Morse code like transmitter. If it works then you have then you have moved the synchronisation problem over to software.








Libre de virus. www.avg.com


jdow
 

PRBS is not magic, although they do have nice properties. Getting the sequence synchronized with the GPS time signal is "iffy". At us resolution it's not a problem. But it's a shame to waste the potential to determine times to nanosecond levels of accuracy. And, yes, getting the edge of the "click" has its own risetime issues. But the design would be stable from unit to unit to about 10% of the latency involved. So it could be calibrated out.

I went with ugly due to issues with potentially disparate clocks and resolution of the PRBS compared to the rising edge. (You look for it with the full 10 MHz bandwidth of the AirSpy in post processing.) That can be nicely frequency synchronized with the GPS clock. The phase may be a little unpredictable, although it will be pretty stable. With post processing the tick could be processed out to small 10s of ns or better. If we live at 100 ns then I'd go for a long code something like the GPS P-code with a long period before repeats to give time directly. For precision a 4 MHz chipping rate would be good. But that smears the signal out providing a raised noise floor for detecting the echos. A 100kHz chipping rate with a filtered waveform could keep the echo frequency clear at the cost of precision. So this is 100 ns to 1 us sort of timing resolution.

Of course, nothing prohibits both approaches being available during initial design and testing. The modest no-code period makes detecting the spike with some precision more likely while the PRBS allows a check on it and a fallback if the planned spike approach fails to work. Throughout all of this I am presuming the spike is kept very narrow, 100 ns or less. And I just thought of having an intentional variable phase adjustment on the 10 MHz signal from the GPS receiver so that the spike detection is optimized, which also improves time resolution.

(In the back of my mind I am thinking of the R888 HF toy with something like 122 Msps capability. Precision potentially would be wonderful. It might end up rather high power for the application. And the frequency imprecision of the AirSpy R820T2 chip would be removed. I am not sure that would adversely affect the post processing or not.)

(I designed elements of the Phase IIb GPS birds. A little bit of me figures it's a crime to waste the potential capability of the tool. I sweat bullets trying to make its synthesizer and PRBS generators er bullet proof and spot on accurate.)

{^_-}

On 20210824 02:56:31, Carlos Cabezas wrote:
Then the problem will be how to decide or trigger when the tick exactly happened with enough accuracy. I already tried a similar idea, using a strong noise generator switched into the RF input with a solid state switch driven by PPS, and it was not possible to determine where the burst starts accurately. That's the magic of a PRBS.

In my mind, this could be implemented with a FPGA or CPLD clocked at 100MHz. Generating a BPSK modulated PRBS at 4-5MHz directly.

Carlos


El 24/08/2021 a las 11:11, jdow escribió:
Now you must figure out the software latency and worse latency variation on that PRBS signal. You MIGHT make it wotk with a synthesizer chip that places a signal roughly where you are working and take it's output and play WWV with it. Feed it though a DBM with the "IF" port fed by a +/- 10 ma signal. For 50 seconds send time information with approximately 5 seconds before and after the actual tick blanked. The tick also feeds this mixer drive directly from the GPS time receivers 1PPS output. The Trimble unit I am running is close enough in time that the length of cable becomes interesting. And it gives you the time error to boot. A wee little PI or Arduino could receive the pulse along with the modulator. That triggers it to ask the GPS unit what time it is and what the tick's offset is. But, feeding that tick DIRECTLY to the modulator is what gives you potential for insane levels of accuracy.

{^_^}

On 20210824 01:47:12, Carlos Cabezas wrote:
A PRBS sequence triggered with GPS PPS and modulated into the baseband FI passband would be ideal. It would be easy to couple inside AirSpy receiver, even without any soldering.

Carlos
EB4FBZ

El mar., 24 ago. 2021 9:23, Martin Smith via groups.io <martin_z_smith=yahoo.ie@groups.io> escribió:
On Mon, Aug 23, 2021 at 06:02 AM, jdow wrote:

>
> I'm having nightmares with the problems here.

I was just trying to think of the cheapest way of prototyping to test the idea.

You could do it digitally, always starting the synthesised sine wave at zero amplitude on the rising edge of the 1 PPS signal and stopping the sine wave sometime after the falling edge whenever the amplitude again reaches zero. Or even just ignore the falling edge all together and just transmit a fixed number of sine wavelengths always starting and finishing with zero amplitude. The device would still need to be able to tune the frequency of the up-converter to be near the signal of interest and you would always want to calibrate the synthesised signal with maximum attenuation and slowly stepping down the attenuation until a detectable signal level was reached. I was thinking of near field coupling to the antenna, because of cost, but maybe use a power combiner.

It would be an oddball GPS controlled almost Morse code like transmitter. If it works then you have then you have moved the synchronisation problem over to software.








Libre de virus. www.avg.com