Generating multiple related signals
Rather than reinvent the wheel, someone's probably done this.
I've got an application where we want to measure the distance betweeen a bunch of satellites - without external signals (like GPS)
One idea is to radiate a beacon signal from each satellite, and measure it on the other satellites.
Each satellite has an internal clock (OCXO of some sort, assume ~1 ppm, at, say, 10 MHz) all set to approximately the same frequency.
Each satellite has a receiver that can receive signals from the other satellites. You then run a correlator to determine the skew between the received signal and your local oscillator. Obviously all the oscillators drift somewhat over time, but that's figure-out-able in post processing, which has to be done as an ensemble of data.
What I'd like is a way to generate N different signals, one for each satellite, spaced fairly close together (say, 1-2 kHz) apart that is "locked" (in a time-nuts precise sense) to the onboard oscillator.
One way would be to have a PLL with a divide by 10,000 from the 10MHz, and a divide by 10,001 (or 10,005 or whatever) from the 10.001 MHz from the VCO, and a 1Hz loop bandwidth. This is straightforward, but would likely require an additional chip (not a crisis, but...).
What would be nice if there were a "digital arithmetic" way (implementable as part of logic in a modern FPGA, a Zynq or Kintex) to do this? There are onchip DPLLs, but I don't know about their loop filters, etc. (I will look into this).
I'd also like to be able to generate a "bit clock" from the source that is synchronous to 1pps (divided from the 10 MHz clock, or the 10.00N clock) to carry a time code (TBD format and rate). i.e. I could take my synthesized 10.001, divide by 10001 and get 1 kHz, divide that by, say, 20 to get 50 bps, and divide by 50 to get 1pps, to sync the message. This is clearly doable in an FPGA, and at the 1 kHz time scale, doable by software.
This bit clock would modulate (BPSK or AM OOK) the 10.00N carrier which then gets radiated.
I've seen some published ideas along this line, but the proposed implementations (concepts in papers) don't deal with things like "precise timing recovery" and making sure things like edges are precise, and so forth.
There's also people (like TVB) who have programmed a PIC to generate things like Irig Time code, and probably could also do the PLL function with an external loop filter and VCXO (it's sort of a standard disciplined clock thing).
But that adds components, and in the space world, if we can minimize the number of parts, that's good (board space, mass, interconnects, testing, etc.)
sounds like LORAN to me?
----- Original Message -----
From: "Jim Lux via time-nuts" time-nuts@lists.febo.com
To: "time-nuts" time-nuts@lists.febo.com
Cc: "Jim Lux" jim@luxfamily.com
Sent: Tuesday, September 30, 2025 10:49:12 AM
Subject: [time-nuts] Generating multiple related signals
Rather than reinvent the wheel, someone's probably done this.
I've got an application where we want to measure the distance betweeen a bunch of satellites - without external signals (like GPS)
One idea is to radiate a beacon signal from each satellite, and measure it on the other satellites.
Each satellite has an internal clock (OCXO of some sort, assume ~1 ppm, at, say, 10 MHz) all set to approximately the same frequency.
Each satellite has a receiver that can receive signals from the other satellites. You then run a correlator to determine the skew between the received signal and your local oscillator. Obviously all the oscillators drift somewhat over time, but that's figure-out-able in post processing, which has to be done as an ensemble of data.
What I'd like is a way to generate N different signals, one for each satellite, spaced fairly close together (say, 1-2 kHz) apart that is "locked" (in a time-nuts precise sense) to the onboard oscillator.
One way would be to have a PLL with a divide by 10,000 from the 10MHz, and a divide by 10,001 (or 10,005 or whatever) from the 10.001 MHz from the VCO, and a 1Hz loop bandwidth. This is straightforward, but would likely require an additional chip (not a crisis, but...).
What would be nice if there were a "digital arithmetic" way (implementable as part of logic in a modern FPGA, a Zynq or Kintex) to do this? There are onchip DPLLs, but I don't know about their loop filters, etc. (I will look into this).
I'd also like to be able to generate a "bit clock" from the source that is synchronous to 1pps (divided from the 10 MHz clock, or the 10.00N clock) to carry a time code (TBD format and rate). i.e. I could take my synthesized 10.001, divide by 10001 and get 1 kHz, divide that by, say, 20 to get 50 bps, and divide by 50 to get 1pps, to sync the message. This is clearly doable in an FPGA, and at the 1 kHz time scale, doable by software.
This bit clock would modulate (BPSK or AM OOK) the 10.00N carrier which then gets radiated.
I've seen some published ideas along this line, but the proposed implementations (concepts in papers) don't deal with things like "precise timing recovery" and making sure things like edges are precise, and so forth.
There's also people (like TVB) who have programmed a PIC to generate things like Irig Time code, and probably could also do the PLL function with an external loop filter and VCXO (it's sort of a standard disciplined clock thing).
But that adds components, and in the space world, if we can minimize the number of parts, that's good (board space, mass, interconnects, testing, etc.)
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Don Latham
PO Box 404,
Frenchtown, MT, 59846
406-626-4304
Hi Jim!
On Tue, 30 Sep 2025 12:49:12 -0400
Jim Lux via time-nuts time-nuts@lists.febo.com wrote:
Rather than reinvent the wheel, someone's probably done this.
I've got an application where we want to measure the distance betweeen a bunch of satellites - without external signals (like GPS)
One idea is to radiate a beacon signal from each satellite, and measure it on the other satellites.
I guess, there is a reason why you don't want to go the CDMA/PRN route?
That would be very easy to do on an FPGA. Something similar to the
PRN sequence described in the JPL Green Book[1] is also quick and
easy to aquire.
What I'd like is a way to generate N different signals, one for each satellite, spaced fairly close together (say, 1-2 kHz) apart that is "locked" (in a time-nuts precise sense) to the onboard oscillator.
I do not quite see where this signal would be used and why you need
different signal frequencies for different satellites.
One way would be to have a PLL with a divide by 10,000 from the 10MHz, and a divide by 10,001 (or 10,005 or whatever) from the 10.001 MHz from the VCO, and a 1Hz loop bandwidth. This is straightforward, but would likely require an additional chip (not a crisis, but...).
Is there a reason why you want the 10MHz signal to be 1kHz spaced?
Wouldn't it be easier to have the spacing at the RF or at least at
some IF frequency?
The canoncial way to generate these frequencyies would be to use
a DDS or some wide band VCO chip with integrated PLL like the HMC830.
If you run the chip in integer mode, you get a decently low number of
spurs and a fix phase relation. This way you can get fairly close
frequency at RF or IF frequencies.
Now, if you need the frequency at 10MHz+k*1kHz, then I'd just divide
the output of the VCO chip down by 4 or 8, so you get low enough.
What would be nice if there were a "digital arithmetic" way (implementable as part of logic in a modern FPGA, a Zynq or Kintex) to do this? There are onchip DPLLs, but I don't know about their loop filters, etc. (I will look into this).
The PLLs of FPGAs are fairly poor in terms of noise performance and
thus not really suitable to be used in an RF chain. If you only need
them to generate a timing signal, i.e. if you just want to run them
to generate a 10MHz+k*1kHz, then a simple counter approach works.
If you use something similar to a Λ-divider[2], add a low pass filter,
you can get a bit lower phase noise and thus jitter. But it will not
magically make things better.
I'd also like to be able to generate a "bit clock" from the source that is synchronous to 1pps (divided from the 10 MHz clock, or the 10.00N clock) to carry a time code (TBD format and rate). i.e. I could take my synthesized 10.001, divide by 10001 and get 1 kHz, divide that by, say, 20 to get 50 bps, and divide by 50 to get 1pps, to sync the message. This is clearly doable in an FPGA, and at the 1 kHz time scale, doable by software.
If you generate the 10MHz+k*1kHz in the FPGA, this is fairly easy to
do. Including the phase alignment with the 1PPS.
Attila Kinali
[1] "Pseudo-Noise (PN) Ranging Systems", CCSDS 414.0-G-2, 2014
https://ccsds.org/Pubs/414x0g2.pdf
[2] "The Sampling Theorem in Pi and Lambda Digital Frequency Dividers",
by Calosso & Rubiola, 2013
(Note: while the paper talks about using a shift register, it was
actually implemented in an FPGA, IIRC a MAX5, i.e., any FPGA based
counter, where the output pins switch synchronously would work, if
the resulting output waveform has certain properties)
--
The driving force behind research is the question: "Why?"
There are things we don't understand and things we always
wonder about. And that's why we do research.
-- Kobayashi Makoto
On Tue, 30 Sep 2025 23:12:07 +0200, Attila Kinali attila@kinali.ch wrote:
Hi Jim!
On Tue, 30 Sep 2025 12:49:12 -0400
Jim Lux via time-nuts wrote:
Rather than reinvent the wheel, someone's probably done this.
I've got an application where we want to measure the distance betweeen a bunch of satellites - without external signals (like GPS)
One idea is to radiate a beacon signal from each satellite, and measure it on the other satellites.
I guess, there is a reason why you don't want to go the CDMA/PRN route?
That would be very easy to do on an FPGA. Something similar to the
PRN sequence described in the JPL Green Book[1] is also quick and
easy to aquire.
yes, and that has been done - there’s a recent paper from someone who did something like this. FWIW, that’s an international standard. JPL (and me personally) participate in the CCSDS process. In an odd coincidence, I just spent 2 weeks in Hamburg doing the fall meeting of CCSDS. The Green Books are “explanatory” (informative in standards speak) - but there’s Blue Books (Normative standards) too. And we’re developing a standard for PN ranging in the Prox-1 protocol used for relay comms between rovers and orbiters.
What I'd like is a way to generate N different signals, one for each satellite, spaced fairly close together (say, 1-2 kHz) apart that is "locked" (in a time-nuts precise sense) to the onboard oscillator.
I do not quite see where this signal would be used and why you need
different signal frequencies for different satellites.
. The science receivers cover ~100 kHz to 30 MHz, so that lets the timing signals be received by the same receiver, and subject to the same delays and sample rate variations as the science data. As to why different - makes life easier - we typically process this data by running the wideband sampled signal into a Polyphase Filter Bank. SunRISE uses 4096 channels between 0-25 MHz. So if you pick a channel for each timing signal, it’s easy to process them independently. The individual satellites have different oscillators which will drift. Yes, with a PN code, you could separately recover it, but it’s a bit more complicated.
so with N satellites, you wind up with N(N-1)/2 cross links, from which you can solve for the “shape” of the constellation (if N > 5, otherwise there are ambiguities), and simultaneously, solve for the frequency offsets, allowing one to do interferometry with N(N-1)/2 baselines.
One way would be to have a PLL with a divide by 10,000 from the 10MHz, and a divide by 10,001 (or 10,005 or whatever) from the 10.001 MHz from the VCO, and a 1Hz loop bandwidth. This is straightforward, but would likely require an additional chip (not a crisis, but...).
Is there a reason why you want the 10MHz signal to be 1kHz spaced?
Wouldn't it be easier to have the spacing at the RF or at least at
some IF frequency?
The canoncial way to generate these frequencyies would be to use
a DDS or some wide band VCO chip with integrated PLL like the HMC830.
If you run the chip in integer mode, you get a decently low number of
spurs and a fix phase relation. This way you can get fairly close
frequency at RF or IF frequencies.
Now, if you need the frequency at 10MHz+k*1kHz, then I'd just divide
the output of the VCO chip down by 4 or 8, so you get low enough.
What would be nice if there were a "digital arithmetic" way (implementable as part of logic in a modern FPGA, a Zynq or Kintex) to do this? There are onchip DPLLs, but I don't know about their loop filters, etc. (I will look into this).
The PLLs of FPGAs are fairly poor in terms of noise performance and
thus not really suitable to be used in an RF chain. If you only need
them to generate a timing signal, i.e. if you just want to run them
to generate a 10MHz+k*1kHz, then a simple counter approach works.
If you use something similar to a Λ-divider[2], add a low pass filter,
you can get a bit lower phase noise and thus jitter. But it will not
magically make things better.
I'd also like to be able to generate a "bit clock" from the source that is synchronous to 1pps (divided from the 10 MHz clock, or the 10.00N clock) to carry a time code (TBD format and rate). i.e. I could take my synthesized 10.001, divide by 10001 and get 1 kHz, divide that by, say, 20 to get 50 bps, and divide by 50 to get 1pps, to sync the message. This is clearly doable in an FPGA, and at the 1 kHz time scale, doable by software.
If you generate the 10MHz+k*1kHz in the FPGA, this is fairly easy to
do. Including the phase alignment with the 1PPS.
Attila Kinali
[1] "Pseudo-Noise (PN) Ranging Systems", CCSDS 414.0-G-2, 2014
https://ccsds.org/Pubs/414x0g2.pdf
[2] "The Sampling Theorem in Pi and Lambda Digital Frequency Dividers",
by Calosso & Rubiola, 2013
(Note: while the paper talks about using a shift register, it was
actually implemented in an FPGA, IIRC a MAX5, i.e., any FPGA based
counter, where the output pins switch synchronously would work, if
the resulting output waveform has certain properties)
--
The driving force behind research is the question: "Why?"
There are things we don't understand and things we always
wonder about. And that's why we do research.
-- Kobayashi Makoto
Hi Jim,
On 2025-09-30 18:49, Jim Lux via time-nuts wrote:
Rather than reinvent the wheel, someone's probably done this.
I've got an application where we want to measure the distance betweeen a bunch of satellites - without external signals (like GPS)
One idea is to radiate a beacon signal from each satellite, and measure it on the other satellites.
Each satellite has an internal clock (OCXO of some sort, assume ~1 ppm, at, say, 10 MHz) all set to approximately the same frequency.
Each satellite has a receiver that can receive signals from the other satellites. You then run a correlator to determine the skew between the received signal and your local oscillator. Obviously all the oscillators drift somewhat over time, but that's figure-out-able in post processing, which has to be done as an ensemble of data.
What I'd like is a way to generate N different signals, one for each satellite, spaced fairly close together (say, 1-2 kHz) apart that is "locked" (in a time-nuts precise sense) to the onboard oscillator.
One way would be to have a PLL with a divide by 10,000 from the 10MHz, and a divide by 10,001 (or 10,005 or whatever) from the 10.001 MHz from the VCO, and a 1Hz loop bandwidth. This is straightforward, but would likely require an additional chip (not a crisis, but...).
What would be nice if there were a "digital arithmetic" way (implementable as part of logic in a modern FPGA, a Zynq or Kintex) to do this? There are onchip DPLLs, but I don't know about their loop filters, etc. (I will look into this).
I'd also like to be able to generate a "bit clock" from the source that is synchronous to 1pps (divided from the 10 MHz clock, or the 10.00N clock) to carry a time code (TBD format and rate). i.e. I could take my synthesized 10.001, divide by 10001 and get 1 kHz, divide that by, say, 20 to get 50 bps, and divide by 50 to get 1pps, to sync the message. This is clearly doable in an FPGA, and at the 1 kHz time scale, doable by software.
This bit clock would modulate (BPSK or AM OOK) the 10.00N carrier which then gets radiated.
I've seen some published ideas along this line, but the proposed implementations (concepts in papers) don't deal with things like "precise timing recovery" and making sure things like edges are precise, and so forth.
There's also people (like TVB) who have programmed a PIC to generate things like Irig Time code, and probably could also do the PLL function with an external loop filter and VCXO (it's sort of a standard disciplined clock thing).
But that adds components, and in the space world, if we can minimize the number of parts, that's good (board space, mass, interconnects, testing, etc.)
There are some really good papers and books to go back to. You propose a
FDMA solution, and I would strongly advice against that, do not use
frequency as a separator as that causes complexities in corrections, we
know that from GLONASS. Rather, use CDMA. They search term you want is
"Gold codes". They key idea is that you have two synchronous
pseudo-random generators, and by shifting the start-phase between them,
their XOR result becomes a Gold code that has very low cross-correlation
to any of the other Gold-codes. For the GPS C/A code with 1023 chips, it
is really two 1023 long pseudorandom generators and the start phase is
shifted on one of them to produce 1023 codes. For GPS they chose
combinations which was slightly better than others.
GPS satellites also have ranging between satellites which is part of
their AUTONAV capability, which operates ranging codes on separate
antennas on very different frequency. It's been done before. Much
details is not released, but you don't really need much either, as what
you are after comes out quite naturally considering it is ranging codes.
Since orbits is not perfect circular, the range will shift over the
cycle in orbit, which as you realize is a very nice feature and combine
that with Kalman filter for orbit also gives good prediction so you can
break away orbit drifts from timedrifts.
As said, don't trust the DPLL. Either measure your FPGA phase noise
carefully, see results from Enrico Rubiola group, or retime it with good
clock.
The whole GPS signal and tracking it is well researched and written.
Recycle that in sufficiently suitable form and you have a rich set of
references to just repurpose for your project. Depending on your
satellite orbit, you may need ionospheric delay corrections or not, and
dual frequency is a powerful tool to build direct ionospheric
measurement and correction.
I think giving up on some ideas you can gain the minimalization you are
after, as some "potentially good ideas" is far from it.
I would ask these questions:
What frequencies are available?
What bandwidths are available?
Is multiband possible?
What precission is needed?
What precission do you wish for?
What altitude of orbits?
Single or multiple orbits?
The rest can most probably be banged into a suitable system structure
fairly easy from that.
Cheers,
Magnus
Am 2025-10-01 3:41, schrieb Jim Lux via time-nuts:
On Tue, 30 Sep 2025 23:12:07 +0200, Attila Kinali attila@kinali.ch
wrote:
The canoncial way to generate these frequencyies would be to use
a DDS or some wide band VCO chip with integrated PLL like the HMC830.
The HMC830 is EOL, so if you might need more: get them while you can!
If you run the chip in integer mode, you get a decently low number of
spurs and a fix phase relation. This way you can get fairly close
frequency at RF or IF frequencies.
Now, if you need the frequency at 10MHz+k*1kHz, then I'd just divide
There once was a BCD DDS made by Qualcomm that could produce these
decimal frequencies exactly. Maybe I should add that as an option
to my SinCostab / DDS on opencores.org. :-)
What would be nice if there were a "digital arithmetic" way
(implementable
as part of logic in a modern FPGA, a Zynq or Kintex) to do this?
There are onchip DPLLs, but I don't know about their loop filters,
etc.
(I will look into this).
or do the DDS-VCO/phase comparator/CIC/FIR lowpass completely in
the digital domain on-chip.
Gerhard
On Wed, 1 Oct 2025 12:25:37 +0200, Magnus Danielson magnus@rubidium.se wrote:
Hi Jim,
On 2025-09-30 18:49, Jim Lux via time-nuts wrote:
Rather than reinvent the wheel, someone's probably done this.
I've got an application where we want to measure the distance betweeen a bunch of satellites - without external signals (like GPS)
One idea is to radiate a beacon signal from each satellite, and measure it on the other satellites.
Each satellite has an internal clock (OCXO of some sort, assume ~1 ppm, at, say, 10 MHz) all set to approximately the same frequency.
Each satellite has a receiver that can receive signals from the other satellites. You then run a correlator to determine the skew between the received signal and your local oscillator. Obviously all the oscillators drift somewhat over time, but that's figure-out-able in post processing, which has to be done as an ensemble of data.
What I'd like is a way to generate N different signals, one for each satellite, spaced fairly close together (say, 1-2 kHz) apart that is "locked" (in a time-nuts precise sense) to the onboard oscillator.
One way would be to have a PLL with a divide by 10,000 from the 10MHz, and a divide by 10,001 (or 10,005 or whatever) from the 10.001 MHz from the VCO, and a 1Hz loop bandwidth. This is straightforward, but would likely require an additional chip (not a crisis, but...).
What would be nice if there were a "digital arithmetic" way (implementable as part of logic in a modern FPGA, a Zynq or Kintex) to do this? There are onchip DPLLs, but I don't know about their loop filters, etc. (I will look into this).
I'd also like to be able to generate a "bit clock" from the source that is synchronous to 1pps (divided from the 10 MHz clock, or the 10.00N clock) to carry a time code (TBD format and rate). i.e. I could take my synthesized 10.001, divide by 10001 and get 1 kHz, divide that by, say, 20 to get 50 bps, and divide by 50 to get 1pps, to sync the message. This is clearly doable in an FPGA, and at the 1 kHz time scale, doable by software.
This bit clock would modulate (BPSK or AM OOK) the 10.00N carrier which then gets radiated.
I've seen some published ideas along this line, but the proposed implementations (concepts in papers) don't deal with things like "precise timing recovery" and making sure things like edges are precise, and so forth.
There's also people (like TVB) who have programmed a PIC to generate things like Irig Time code, and probably could also do the PLL function with an external loop filter and VCXO (it's sort of a standard disciplined clock thing).
But that adds components, and in the space world, if we can minimize the number of parts, that's good (board space, mass, interconnects, testing, etc.)
There are some really good papers and books to go back to. You propose a
FDMA solution, and I would strongly advice against that, do not use
frequency as a separator as that causes complexities in corrections, we
know that from GLONASS. Rather, use CDMA. They search term you want is
"Gold codes". They key idea is that you have two synchronous
pseudo-random generators, and by shifting the start-phase between them,
their XOR result becomes a Gold code that has very low cross-correlation
to any of the other Gold-codes. For the GPS C/A code with 1023 chips, it
is really two 1023 long pseudorandom generators and the start phase is
shifted on one of them to produce 1023 codes. For GPS they chose
combinations which was slightly better than others.
certainly, that is a solution. But it spreads the signal across multiple frequency bins (with any reasonable chip rate.. I'd have to think about this, if you used a chip rate like 100 Hz). The idea is that you're doing an "in-band" measurement with the science measurement, which is ~100kHz to 30 MHz, channelized into single digit kHz bins. You'd like to minimize the number of bins.
The whole GPS signal and tracking it is well researched and written.
Recycle that in sufficiently suitable form and you have a rich set of
references to just repurpose for your project. Depending on your
satellite orbit, you may need ionospheric delay corrections or not, and
dual frequency is a powerful tool to build direct ionospheric
measurement and correction.
indeed - this is for satellites that are high enough that ionosphere doesn't get in the picture - SunRISE is spread across a max of ~20km and will sit 300km above GEO. I'm looking at this for a GPS-not-available enviroment (say at Earth Sun L4 or L5, or Earth Moon L4/L5). And the "interplanetary plasma density" is sufficiently low that at HF frequencies, there's probably not much effect (there are opinions on this, of course).
I would ask these questions:
What frequencies are available?
Has to be "in band" (MF-HF - we call it DecaHectometric -for the wavelengths) - if you add a transmitter/receiver in another band, then it's easy (but that adds parts and complexity) - It's for space and has to survive for years and years, so it's not like I can just slap a Novetel GPS on there.
What bandwidths are available?
TBD Small - right now we channelize 0-25 MHz into 4096 channels of 6.1 kHz, and we'd not like to consume any more than we need to.
Is multiband possible?
What precission is needed?
1 meter/1 nanosecond - this is driven by the need to know time and position for the interferometry. For SunRISE it's roughly half a radian in phase at 11.3 MHz (30m lambda)
What precission do you wish for?
What altitude of orbits?
Single or multiple orbits?
All in essentially the same orbit, flying as a constellation with some relative motion. SunRISE has 6 SVs in circular orbits that are "slightly" different so they're always changing relative to each other, but stay within 20km and not closer than 1km. For a future system, it might grow to, say, 50 or 100km. But beyond that, the value for interferometry gets limited due to grating lobes. At 1 MHz, the wavelength is 300m, and at 20km separation, that's 60 wavelengths, which is great for angular resolution, but has many grating lobes.
If you want several channels nicely spaced, use OFDM.
You assign a dedicated channel for each satellite.
Il giorno mar 30 set 2025 alle 20:51 Jim Lux via time-nuts <
time-nuts@lists.febo.com> ha scritto:
Rather than reinvent the wheel, someone's probably done this.
I've got an application where we want to measure the distance betweeen a
bunch of satellites - without external signals (like GPS)
One idea is to radiate a beacon signal from each satellite, and measure it
on the other satellites.
Each satellite has an internal clock (OCXO of some sort, assume ~1 ppm,
at, say, 10 MHz) all set to approximately the same frequency.
Each satellite has a receiver that can receive signals from the other
satellites. You then run a correlator to determine the skew between the
received signal and your local oscillator. Obviously all the oscillators
drift somewhat over time, but that's figure-out-able in post processing,
which has to be done as an ensemble of data.
What I'd like is a way to generate N different signals, one for each
satellite, spaced fairly close together (say, 1-2 kHz) apart that is
"locked" (in a time-nuts precise sense) to the onboard oscillator.
One way would be to have a PLL with a divide by 10,000 from the 10MHz, and
a divide by 10,001 (or 10,005 or whatever) from the 10.001 MHz from the
VCO, and a 1Hz loop bandwidth. This is straightforward, but would likely
require an additional chip (not a crisis, but...).
What would be nice if there were a "digital arithmetic" way (implementable
as part of logic in a modern FPGA, a Zynq or Kintex) to do this? There are
onchip DPLLs, but I don't know about their loop filters, etc. (I will look
into this).
I'd also like to be able to generate a "bit clock" from the source that is
synchronous to 1pps (divided from the 10 MHz clock, or the 10.00N clock) to
carry a time code (TBD format and rate). i.e. I could take my synthesized
10.001, divide by 10001 and get 1 kHz, divide that by, say, 20 to get 50
bps, and divide by 50 to get 1pps, to sync the message. This is clearly
doable in an FPGA, and at the 1 kHz time scale, doable by software.
This bit clock would modulate (BPSK or AM OOK) the 10.00N carrier which
then gets radiated.
I've seen some published ideas along this line, but the proposed
implementations (concepts in papers) don't deal with things like "precise
timing recovery" and making sure things like edges are precise, and so
forth.
There's also people (like TVB) who have programmed a PIC to generate
things like Irig Time code, and probably could also do the PLL function
with an external loop filter and VCXO (it's sort of a standard disciplined
clock thing).
But that adds components, and in the space world, if we can minimize the
number of parts, that's good (board space, mass, interconnects, testing,
etc.)
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
That is exactly what I was looking at. The question is how does one generate all those nicely spaced channels, with low phase noise, with minimal extra components.
On Thu, 2 Oct 2025 19:13:45 +0200, Mattia Rizzi mattia.rizzi@gmail.com wrote:
If you want several channels nicely spaced, use OFDM.
You assign a dedicated channel for each satellite.
Il giorno mar 30 set 2025 alle 20:51 Jim Lux via time-nuts time-nuts@lists.febo.com ha scritto:
Rather than reinvent the wheel, someone's probably done this.
I've got an application where we want to measure the distance betweeen a bunch of satellites - without external signals (like GPS)
One idea is to radiate a beacon signal from each satellite, and measure it on the other satellites.
Each satellite has an internal clock (OCXO of some sort, assume ~1 ppm, at, say, 10 MHz) all set to approximately the same frequency.
Each satellite has a receiver that can receive signals from the other satellites. You then run a correlator to determine the skew between the received signal and your local oscillator. Obviously all the oscillators drift somewhat over time, but that's figure-out-able in post processing, which has to be done as an ensemble of data.
What I'd like is a way to generate N different signals, one for each satellite, spaced fairly close together (say, 1-2 kHz) apart that is "locked" (in a time-nuts precise sense) to the onboard oscillator.
One way would be to have a PLL with a divide by 10,000 from the 10MHz, and a divide by 10,001 (or 10,005 or whatever) from the 10.001 MHz from the VCO, and a 1Hz loop bandwidth. This is straightforward, but would likely require an additional chip (not a crisis, but...).
What would be nice if there were a "digital arithmetic" way (implementable as part of logic in a modern FPGA, a Zynq or Kintex) to do this? There are onchip DPLLs, but I don't know about their loop filters, etc. (I will look into this).
I'd also like to be able to generate a "bit clock" from the source that is synchronous to 1pps (divided from the 10 MHz clock, or the 10.00N clock) to carry a time code (TBD format and rate). i.e. I could take my synthesized 10.001, divide by 10001 and get 1 kHz, divide that by, say, 20 to get 50 bps, and divide by 50 to get 1pps, to sync the message. This is clearly doable in an FPGA, and at the 1 kHz time scale, doable by software.
This bit clock would modulate (BPSK or AM OOK) the 10.00N carrier which then gets radiated.
I've seen some published ideas along this line, but the proposed implementations (concepts in papers) don't deal with things like "precise timing recovery" and making sure things like edges are precise, and so forth.
There's also people (like TVB) who have programmed a PIC to generate things like Irig Time code, and probably could also do the PLL function with an external loop filter and VCXO (it's sort of a standard disciplined clock thing).
But that adds components, and in the space world, if we can minimize the number of parts, that's good (board space, mass, interconnects, testing, etc.)
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Typically you'd use an FPGA to drive a DAC whose output is broadband enough to contain the entire band of interest. At that point, the question of generating synchronous and/or orthogonal carriers is just a software (or HDL) problem. I/Q baseband in -> multicarrier RF out.
You would definitely not try to generate multiple carriers using PLLs/DLLs, etc. on the FPGA itself, except perhaps in the most trivial situations.
-- john, KE5FX
-----Original Message-----
From: Jim Lux via time-nuts time-nuts@lists.febo.com
Sent: Thursday, October 2, 2025 11:30 AM
That is exactly what I was looking at. The question is how does one generate all those nicely spaced channels, with low phase noise, with minimal extra components.
time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe send an email to time-nuts-leave@lists.febo.com
Typically, you send the DAC clock directly to the DAC from the PLL chip.
and also send a (divided if necessary) version to the FPGA for internal
/output clocking of the data.
some DACs will have frame clock output and you can send that to the
FPGA instead.
Most low speed DACS (< 500Msps) will be DDR LVDS, which the FPGA can
trivally generate to about 1250 Mbps.
the FPGA sends data and sample clock to the DAC and synchronous data .
It doesnt matter how crappy that sample clock output is as the DAC will
only use it to clock data into a FIFO on chip. FPGA timign constraints
in the HDL code get correct bit/clock alignment per LVDS pair.
above 500Msps in general, SERDES rules. which can be useful for some
applications.
The DAC will take care of the data alignment and phase between the data
input and the DAC with a small elastic FIFO.
There are plenty of off-the-shelf SDR platforms to do this on.
-glen . (manufacturer of such things)
On 3/10/2025 6:54 am, John Miles via time-nuts wrote:
Typically you'd use an FPGA to drive a DAC whose output is broadband enough to contain the entire band of interest. At that point, the question of generating synchronous and/or orthogonal carriers is just a software (or HDL) problem. I/Q baseband in -> multicarrier RF out.
You would definitely not try to generate
Jim
I would also vote for the CDMA method like other suggest:
unless: unless you have near-far problems.
If the ratio between different signals is going to exceed 25dB, then you
might want to consider a combo of TDMA/FDMA along with your CDMA.
IE one satellite 10km away, and another satellite 2000km away (26dB)
Or
The radiation pattern of two satellites being such that, you might get a
10dB null in the radiation pattern, which means that sats may have
higher wanted/unwanted ratio.
IE
SAT1 : 500km away with 0dBi toward you
SAT2 : 5000km away (20dB weaker) with -10dBi toward you = 30dB
signal difference.
To mitigate this, you can borrow a method from the CDMA phone network :
- where mobile stations can have their power output varied (in 1 dB
steps at about a 1kHz rate) over 60dB range
On 3/10/2025 6:54 am, John Miles via time-nuts wrote:
Typically you'd use an FPGA to drive a DAC whose o
Not if you have a power limited system, and it’s mostly a wideband receiver (ADC into the FPGA). My goal is to come up with a minimum parts count solution to doing ranging between satellites, and solving for oscillator frequencies, as well. It’s easy to pull a single pin or two out of an FPGA and run it through a few passive components to make a low power transmitter.
I had thought of just putting a carrier, BPSK or OOK modulated with a time code - easy to recover the phase, and if separated from the other signals (remember you might have 50 of them) pretty easy. Or, as has been suggested, do CDMA, BPSK with a Kasami or Gold code (or something with good cross correlation properties) at some lowish rate, and modulate the time code on top of that (like GPS does).
A lot depends on the “process gain” (the preprocessed bandwidth vs the post processed bandwidth) - the source oscillators are typically fairly good (OCXO in the current instrument), so integrating over 1 second or 10 seconds seems plausible. A process gain for the carrier phase of 30 or 40 dB seems quite possible.
Some practical aspects: It takes only a few milliwatts to get enough signal to the other spacecraft. So filtering a 3.3V logic signal to radiate is good, even though the radiating antenna is inefficient (think a 1 meter whip or equivalent), and the receiver is using a voltage probe (short dipole with high Z amplifier). The range is short (50km max).
Yes, if someone sold one, one could probably also do ranging with the inevitable microwave data link between the satellite and a “mother ship” that relays the data back to Earth. You have to have something for commanding and telemetry. But, as a practical matter, off the shelf radios do not generally include “time transfer” quality links. And you’d still need to do satellite to satellite ranging to figure out the positions.
But it is a valid point - maybe spend the time figuring out how to make the link radio do the time transfer. We do this now with the JPL designed Iris radios, which do coherent two way ranging. But they’re pretty pricey ($500k-$1M depending on quantity) compared to $50-100k for a vanilla X or S band radio (or even less if you don’t want “space qualified” build and components - there are people basically flying USRPs and Plutos).
(and with the growing interest in lunar networks, and putting 3GPP at the Moon, and adding ranging to Prox-1 relay protocol, maybe that gets solved? What’s the time distribution performance of cell phone systems?)
On Thu, 2 Oct 2025 13:54:34 -0700, john@miles.io wrote:
Typically you'd use an FPGA to drive a DAC whose output is broadband enough to contain the entire band of interest. At that point, the question of generating synchronous and/or orthogonal carriers is just a software (or HDL) problem. I/Q baseband in -> multicarrier RF out.
You would definitely not try to generate multiple carriers using PLLs/DLLs, etc. on the FPGA itself, except perhaps in the most trivial situations.
-- john, KE5FX
-----Original Message-----
From: Jim Lux via time-nuts
Sent: Thursday, October 2, 2025 11:30 AM
That is exactly what I was looking at. The question is how does one generate all those nicely spaced channels, with low phase noise, with minimal extra components.
time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe send an email to time-nuts-leave@lists.febo.com
Excellent point on the near/far problem.
Taking SunRISE as an example - 6 space vehicles, with the range being anywhere from 20km to 1km at any given time.
Power management is an idea, but if you reduce for the near pair, then the SNR for the far pair is reduced, and you need “all the links, almost all the time” for solving for the relative positions. In a notional radio astronomy constellation there might be 50-100 satellites spread over a 50-100 km diameter sphere - so the near/far might be as bad as 40 dB (1km vs 100km)
One could probably do some sort of sequenced power levels - step different levels, so any given pair might be “too faint” or “overloaded”, but in the long run would be ok.
The relative motion between space vehicles is slow (a few cm/s) so integrating over a long time period is probably ok (either the error is small enough you can just average, or you model some sort of “distance vs time” function which is probably close to linear in the short run) - remember, I want to have a time uncertainty well under a nanosecond, so 1 cm/second is 30 ps/second change in delay. For SunRISE, this kind of thing is done in post processing of recorded GPS observable, where there’s a fit over multiple days, with added modeling terms for things like radiation pressure and solar wind, etc. (using GIPSYx). (Side note, the recent NISAR satellite is using GPS based precision orbit determination, which is more complex, because it’s in LEO, and it’s physically large so the disturbances are larger - and you have to deal with motion of the GPS antenna as the spacecraft changes attitude - I’m sure there will be some interesting papers coming out of that.)
So far, this is just speculative “is it even possible” - people have been proposing such constellations for decades, but they’ve sort of left the “position and time” aspect “for others”, mostly because until recently, nobody had even come close. But with SunRISE, we’re actually doing part of it (well, we will after we launch next August, ULA willing). So, given the “many years” between idea and mission, it’s time to start working the PNT problem. And I’m coming at it from a “what can we do in a small sat, lower cost model”. SunRISE’s satellites cost about $2-4M each (that’s the recurring cost to build one and test it) and are 10x20x30 cm. So if you had a constellation of 50 of them, that’s $100-200M, which is not unreasonable - you’d also need some “mother ships” to relay data back to Earth and provide “overall supervisory control” and they’d be, say, $20M each so a total “procurement cost” for the mission of ~300M. That’s not super unreasonable. Assuming someone wants that science for the price. As a comparison, there’s a proposal (FARSIDE) for an array observatory on the far side of the Moon, which was over $1B. True, the decadal study didn’t think it was worth pushing (they want IR/UV telescopes).
But there’s lots of practical problems for PNT in a no-GPS, not terrestrial, environment that need solutions that are low (enough) cost, (or really, any cost, since there isn’t any generalized solution today).
On Fri, 3 Oct 2025 09:00:49 +1000, glenlist via time-nuts time-nuts@lists.febo.com wrote:
Jim
I would also vote for the CDMA method like other suggest:
unless: unless you have near-far problems.
If the ratio between different signals is going to exceed 25dB, then you
might want to consider a combo of TDMA/FDMA along with your CDMA.
IE one satellite 10km away, and another satellite 2000km away (26dB)
Or
The radiation pattern of two satellites being such that, you might get a
10dB null in the radiation pattern, which means that sats may have
higher wanted/unwanted ratio.
IE
SAT1 : 500km away with 0dBi toward you
SAT2 : 5000km away (20dB weaker) with -10dBi toward you = 30dB
signal difference.
To mitigate this, you can borrow a method from the CDMA phone network :
- where mobile stations can have their power output varied (in 1 dB
steps at about a 1kHz rate) over 60dB range
On 3/10/2025 6:54 am, John Miles via time-nuts wrote:
Typically you'd use an FPGA to drive a DAC whose o
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Hi Jim
I generally agree except using FPGA pins as transmitters is NOT recommended
FPGA paths internally are high jitter and rather noisy.
You might annoy the radio astronomy and ham folks if you use FPGA pins
as transmitters
That's the reason why we dont use FPGA outputs as direct DAC clocks...
They dont just have pS or fS of jitter, they have nS of jitter, and lots
of it. Having said that, there are improvements from the bad old days
around this with the advent of local pin DDR-FF IOB clocking but your
clock signals still end up going through routing and switching fabric
which add jitter.
In wanting the "minimum parts count solution" :
- what are your radiation dosage expectations, constraints etc ? CERN
have a pretty good COTS list.
As for distance/frequency correction to improve the integration , as
you know, you can measure the dopper and know the slope etc etc and
compensate.
This is probably getting off time-nuts topic but nevertheless interesting.
-glen
On 4/10/2025 01:13, Jim Lux via time-nuts wrote:
Not if you have a power limited system, and it’s mostly a wideband receiver (ADC into the FPGA). My goal is to come up with a minimum parts count solution to doing ranging between satellites, and solving for oscillator frequencies, as well. It’s easy to pull a single pin or two out of an FPGA and run it through a few passive components to make a low power transmitter.
I had thought of just putting a carrier, BPSK or OOK modulated with a time code - easy to recover the phase, and if separated from the other signals (remember you might have 50 of them) pretty easy. Or, as has been suggested, do CDMA, BPSK with a Kasami or Gold code (or something with good cross correlation properties) at some lowish rate, and modulate the time code on top of that (like GPS does).
A lot depends on the “process gain” (the preprocessed bandwidth vs the post processed bandwidth) - the source oscillators are typically fairly good (OCXO in the current instrument), so integrating over 1 second or 10 seconds seems plausible. A process gain for the carrier phase of 30 or 40 dB seems quite possible.
Some practical aspects: It takes only a few milliwatts to get enough signal to the other spacecraft. So filtering a 3.3V logic signal to radiate is good, even though the radiating antenna is inefficient (think a 1 meter whip or equivalent), and the receiver is using a voltage probe (short dipole with high Z amplifier). The range is short (50km max).
Yes, if someone sold one, one could probably also do ranging with the inevitable microwave data link between the satellite and a “mother ship” that relays the data back to Earth. You have to have something for commanding and telemetry. But, as a practical matter, off the shelf radios do not generally include “time transfer” quality links. And you’d still need to do satellite to satellite ranging to figure out the positions.
But it is a valid point - maybe spend the time figuring out how to make the link radio do the time transfer. We do this now with the JPL designed Iris radios, which do coherent two way ranging. But they’re pretty pricey ($500k-$1M depending on quantity) compared to $50-100k for a vanilla X or S band radio (or even less if you don’t want “space qualified” build and components - there are people basically flying USRPs and Plutos).
(and with the growing interest in lunar networks, and putting 3GPP at the Moon, and adding ranging to Prox-1 relay protocol, maybe that gets solved? What’s the time distribution performance of cell phone systems?)
That's the reason why we dont use FPGA outputs as direct DAC clocks...
They dont just have pS or fS of jitter, they have nS of jitter, and lots
of it. Having said that, there are improvements from the bad old days
do they?
http://jmfriedt.free.fr/EFTF2025_jmfriedt.pdf uses https://github.com/oscimp/amaranth_twstft/
with the raw FPGA output bandpass filtered but benefiting from spectrum spreading to reach
sub-1e-12 from 25 ms to 100 s, and https://github.com/oscimp/wr_acorn generates a 1-PPS
output disciplined on White Rabbit on a general purpose GPIO pin in the sub-1e-10 at 1 s.
Best, Jean-Michel
Yes ! t needed to be bandpass filtered...
and....
yes timing / jitter over those long periods sure, but the jitter for
low sideband noise radio work is fS to nS.
25mS to 100s is eternity for radio PM/AM noise.
For clean radio in VHF/UHF spectrum, we're looking at jitter on the fS
to nS scale
best regards
On 4/10/2025 2:42 pm, jeanmichel.friedt--- via time-nuts wrote:
That's the reason why we dont use FPGA outputs as direct DAC clocks...
They dont just have pS or fS of jitter, they have nS of jitter, and lots
of it. Having said that, there are improvements from the bad old days
do they?
http://jmfriedt.free.fr/EFTF2025_jmfriedt.pdf uses https://github.com/oscimp/amaranth_twstft/
with the raw FPGA output bandpass filtered but benefiting from spectrum spreading to reach
sub-1e-12 from 25 ms to 100 s, and https://github.com/oscimp/wr_acorn generates a 1-PPS
output disciplined on White Rabbit on a general purpose GPIO pin in the sub-1e-10 at 1 s.
Best, Jean-Michel
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Am 2025-10-03 21:40, schrieb glen english LIST via time-nuts:
That's the reason why we dont use FPGA outputs as direct DAC clocks...
They dont just have pS or fS of jitter, they have nS of jitter, and
lots of it.
Then I wonder how we get GB/s data streams from chip to chip with ns of
jitter,
let alone lots of ns.
There are 74LVC74 for the signals that need reclocking, or the ECL/CML
equivalents.
Cheers, Gerhard
If one is careful in the place and route, you can get fairly low jitter (low enough? Have to try it a measure it), but we have done this before (Virtex 6).
This is a radio astronomy imager that is intended to be far enough from Earth that one can’t use GPS (e.g. EM L4 or something like that). If a ham or anyone can detect the phase noise on the milliwatts of signals, more power to them (<grin>). The idea is that it’s a fairly narrow band signal (<few kHz) and only strong enough to propagate across a 50-100km distance and be 10-20 dB above the galactic background at HF (which is fairly high, compared to kTB, thousands of Kelvins)
Minimum parts count is generically the goal - the part you don’t have can’t fail, nor consume power or mass. Finding rad tolerant parts for this, whatever they are, probably isn’t a problem. If I do add a part, it would probably be some sort of (very) small FPGA to do the waveform synthesis and encoding of PN signal (if used) and data bits. The bits would come on something like I2C or raw bits from a bigger FPGA/processor in the instrument (the one that is receiving the signal and doing onboard processing through a polyphase filter bank).
It’s totally a time nuts topic, I think - “how do you accurately measure relative clock rates across an ensemble of 50-100 nodes with low bandwidth links and no external reference”. It’s sort of trying to solve the NTP problem, in space, without the internet stack.
On Sat, 4 Oct 2025 05:40:32 +1000, glen english LIST via time-nuts time-nuts@lists.febo.com wrote:
Hi Jim
I generally agree except using FPGA pins as transmitters is NOT recommended
FPGA paths internally are high jitter and rather noisy.
You might annoy the radio astronomy and ham folks if you use FPGA pins
as transmitters
That's the reason why we dont use FPGA outputs as direct DAC clocks...
They dont just have pS or fS of jitter, they have nS of jitter, and lots
of it. Having said that, there are improvements from the bad old days
around this with the advent of local pin DDR-FF IOB clocking but your
clock signals still end up going through routing and switching fabric
which add jitter.
In wanting the "minimum parts count solution" :
- what are your radiation dosage expectations, constraints etc ? CERN
have a pretty good COTS list.
As for distance/frequency correction to improve the integration , as
you know, you can measure the dopper and know the slope etc etc and
compensate.
This is probably getting off time-nuts topic but nevertheless interesting.
-glen
On 4/10/2025 01:13, Jim Lux via time-nuts wrote:
Not if you have a power limited system, and it’s mostly a wideband receiver (ADC into the FPGA). My goal is to come up with a minimum parts count solution to doing ranging between satellites, and solving for oscillator frequencies, as well. It’s easy to pull a single pin or two out of an FPGA and run it through a few passive components to make a low power transmitter.
I had thought of just putting a carrier, BPSK or OOK modulated with a time code - easy to recover the phase, and if separated from the other signals (remember you might have 50 of them) pretty easy. Or, as has been suggested, do CDMA, BPSK with a Kasami or Gold code (or something with good cross correlation properties) at some lowish rate, and modulate the time code on top of that (like GPS does).
A lot depends on the “process gain” (the preprocessed bandwidth vs the post processed bandwidth) - the source oscillators are typically fairly good (OCXO in the current instrument), so integrating over 1 second or 10 seconds seems plausible. A process gain for the carrier phase of 30 or 40 dB seems quite possible.
Some practical aspects: It takes only a few milliwatts to get enough signal to the other spacecraft. So filtering a 3.3V logic signal to radiate is good, even though the radiating antenna is inefficient (think a 1 meter whip or equivalent), and the receiver is using a voltage probe (short dipole with high Z amplifier). The range is short (50km max).
Yes, if someone sold one, one could probably also do ranging with the inevitable microwave data link between the satellite and a “mother ship” that relays the data back to Earth. You have to have something for commanding and telemetry. But, as a practical matter, off the shelf radios do not generally include “time transfer” quality links. And you’d still need to do satellite to satellite ranging to figure out the positions.
But it is a valid point - maybe spend the time figuring out how to make the link radio do the time transfer. We do this now with the JPL designed Iris radios, which do coherent two way ranging. But they’re pretty pricey ($500k-$1M depending on quantity) compared to $50-100k for a vanilla X or S band radio (or even less if you don’t want “space qualified” build and components - there are people basically flying USRPs and Plutos).
(and with the growing interest in lunar networks, and putting 3GPP at the Moon, and adding ranging to Prox-1 relay protocol, maybe that gets solved? What’s the time distribution performance of cell phone systems?)
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
For the intended use case - Not so worried about spurious emissions on my signals from a regulatory standpoint - we're a long ways from anyone we might interfere with. I'm going to be radiating milliwatts (if that) - just enough to be received some 50-100km away by a receiver that is galactic background limited.
(odd thing, too, spacecraft don't typically have unintended emissions requirements, some of them are quite loud in the <100 MHz band)
On Sat, 4 Oct 2025 19:45:33 +1000, glenlist via time-nuts time-nuts@lists.febo.com wrote:
Yes ! t needed to be bandpass filtered...
and....
yes timing / jitter over those long periods sure, but the jitter for
low sideband noise radio work is fS to nS.
25mS to 100s is eternity for radio PM/AM noise.
For clean radio in VHF/UHF spectrum, we're looking at jitter on the fS
to nS scale
best regards
On 4/10/2025 2:42 pm, jeanmichel.friedt--- via time-nuts wrote:
That's the reason why we dont use FPGA outputs as direct DAC clocks...
They dont just have pS or fS of jitter, they have nS of jitter, and lots
of it. Having said that, there are improvements from the bad old days
do they?
http://jmfriedt.free.fr/EFTF2025_jmfriedt.pdf uses https://github.com/oscimp/amaranth_twstft/
with the raw FPGA output bandpass filtered but benefiting from spectrum spreading to reach
sub-1e-12 from 25 ms to 100 s, and https://github.com/oscimp/wr_acorn generates a 1-PPS
output disciplined on White Rabbit on a general purpose GPIO pin in the sub-1e-10 at 1 s.
Best, Jean-Michel
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Gerard, except that those transceivers that do the gigabit serial links
have their own, fenced off circuitry and isolated regions on the die.
They also have their own fenced off, isolated power supplies and ground
regions.
And, they require clocks with < a few hundred pS of jitter for their PLL
references to work.
Jim : a few mW from your satellite with a -60dB spur is really bad if
you are a radio astronomer !
example frequency : 1000MHz, 1mW ERP
spurs at -60dBc = -90dBW
distance from earth station : 5000km, signal = -245dBW/m2
say it was spread over 100 Hz, uniformly = -265dBW/m2/Hz or 0.3 Jy
(Attila, pls check) .
Detection threshold of of SKA at this frequency : micro Jys
so your -60dB spur will be like a jumbo je taking off overhead
so, satellite spurs do matter. Starlink is causing lots of problems
right now....
On 4/10/2025 20:38, Gerhard Hoffmann via time-nuts wrote:
Am 2025-10-03 21:40, schrieb glen english LIST via time-nuts:
That's the reason why we dont use FPGA outputs as direct DAC clocks...
They dont just have pS or fS of jitter, they have nS of jitter, and
lots of it.
Then I wonder how we get GB/s data streams from chip to chip with ns
of jitter,
let alone lots of ns.
There are 74LVC74 for the signals that need reclocking, or the ECL/CML
equivalents.
Cheers, Gerhard
Hello,
I wanted to thank you very much for these beautiful and very interesting
links. I learned so much. TWSTFT is amazing.
The prospect of using SDR and modern radio transmissions to distribute
accurate and stable time is very appealing to me, an amateur with a
rather limited budget.
I own several SDRs, including a second hand USRP B200. Which seems to be
supported by amaranth_twstft.
The prospect of an amateur radio based accurate clock distribution
network is extremely appealing.
GPSDOs work, but they have issues, like jitter sawtooth phase errors etc.
By knowing the position of emitting and receiving stations, can TWSTFT
be used in a kind of "receive only" mode?
I also believe that one could use it just for simpler frequency
transfer, without dealing with two way ranging?
Best regards,
Sebastien
On 10/4/25 06:42, jeanmichel.friedt--- via time-nuts wrote:
That's the reason why we dont use FPGA outputs as direct DAC clocks...
They dont just have pS or fS of jitter, they have nS of jitter, and lots
of it. Having said that, there are improvements from the bad old days
do they?
http://jmfriedt.free.fr/EFTF2025_jmfriedt.pdf uses https://github.com/oscimp/amaranth_twstft/
with the raw FPGA output bandpass filtered but benefiting from spectrum spreading to reach
sub-1e-12 from 25 ms to 100 s, and https://github.com/oscimp/wr_acorn generates a 1-PPS
output disciplined on White Rabbit on a general purpose GPIO pin in the sub-1e-10 at 1 s.
Best, Jean-Michel
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
By knowing the position of emitting and receiving stations, can TWSTFT be used in a kind of
"receive only" mode?
the issue is that "geostationary" satellites are not stationary, but precess around their
equilibrium position daily by +/-30 km or 200 ms excursion, see Fig 20 of
https://pubs.gnuradio.org/index.php/grcon/article/view/131/109 so much worse than the VLF
broadcasting stations discussed elsewhere on this list. Identifying and sharing the position
of the geostationnary satellite would be a fantastic feat that quite a few people would be
interested in or have demonstrated
https://www.ion.org/publications/abstract.cfm?articleID=15002
https://epapers2.org/eftf2024/ESR/paper_details.php?paper_id=2117
but there is no open, functional solution, while orbit determination is way beyond my skills
despite having collected passively the time of flight broadcast by European NMIs (see Fig 17
of the above GRCon presentation) and spent quite some time investigating GMAT and Orekit.
If interested to pursue, all you need is a 60-cm satellite dish pointed to Telstar11N and
tuned according to e.g. https://webtai.bipm.org/ftp/pub/tai/data/2025/time_transfer/twstft/op/twop60.677
frequency settings.
On a side note, I learned yesterday that ACES was broadcasting the Ku microwave beam generated
from PHARAO constantly, a nice challenge as well, for the next ISS pass overhead. I have not searched
the web to find if the frequency is a publicly available information (but will be easier to find
with the solution now).
I also believe that one could use it just for simpler frequency transfer, without dealing with two
way ranging?
The satellite is moving at a few ns per seconds so a few 1e-9 accuracy, and we have no
control of the frequency offset introduced by the satellite transceiver from the 14 GHz
uplink to 11 GHz downlink, so unfortunately I do not believe there is much use there.
Thanks for the interest, JM
Best regards,
Sebastien
On 10/4/25 06:42, jeanmichel.friedt--- via time-nuts wrote:
That's the reason why we dont use FPGA outputs as direct DAC clocks...
They dont just have pS or fS of jitter, they have nS of jitter, and lots
of it. Having said that, there are improvements from the bad old daysdo they?
http://jmfriedt.free.fr/EFTF2025_jmfriedt.pdf uses https://github.com/oscimp/amaranth_twstft
with the raw FPGA output bandpass filtered but benefiting from spectrum spreading to reach
sub-1e-12 from 25 ms to 100 s, and https://github.com/oscimp/wr_acorn generates a 1-PPS
output disciplined on White Rabbit on a general purpose GPIO pin in the sub-1e-10 at 1 s.Best, Jean-Michel
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com