ISS NTP operation problems.
At the end of November a question
https://lists.ntp.org/pipermail/questions/2020-November/041883.htmlwas
posed to the ntp.org list concerning NTP problems on the International
Space Station.
With William's permission I'm following up on the time-nuts list.
I analyzed NTP/IP packet captures provided by William and reported on
external visible behaviors. The much simplified diagram is
2 x Ground NTP(strat 1) --------------- ISS NTP server(strat 2)
-----(gigastor)------- ISS NTP clients(strat 3)
There is a ~600-700 msec RTT between the ground NTP servers and the ISS NTP
server.
As William describes, the clients are having trouble synchronizing with the
stratum 2 ISS NTP server.
This server is not working well. Here is the UTC time offset seen from an
external packet capture device (Gigastor)
[The Gigastor is only approximately sync'd to UTC, hence the 4 second
offset]
[image: image.png]
The y-axis scale is seconds.
Note also that after each step the initial error is about -500 ppm. When
the server is in alarm the error stays at -500ppm.
When not in alarm the server's clock frequency is changing in the wrong
direction with a resulting error of up to ~ -1500ppm.
Could this be an example of the Integral Windup problem mentioned recently
by PHK and Magnus?
Have others seen this behavior in NTP?
Getting additional diagnostic information from the ISS is quite difficult.
Even simple changes (e.g., remove ntp.drift) require much planning.
Steve Sommars
Steven Sommars writes:
There is a ~600-700 msec RTT between the ground NTP servers and the ISS NTP server.
How stable is that ?
Is there a lot of sample-to-sample jitter ?
Have they clamped the poll-rate on the S2 ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Hi,
On 2021-01-08 09:24, Poul-Henning Kamp wrote:
Steven Sommars writes:
There is a ~600-700 msec RTT between the ground NTP servers and the ISS NTP server.
How stable is that ?
Is there a lot of sample-to-sample jitter ?
Have they clamped the poll-rate on the S2 ?
Another aspect, how much have delay shifted with how ISS moves around,
and how well the packets match each other and (about) same delay of
transmission. There is a certain assumption about stability of link, but
a systematic modulation of link delay could potentially eat into causing
mismatches that for sure would upset things.
Cheers,
Magnus
On 1/8/21 12:24 AM, Poul-Henning Kamp wrote:
Steven Sommars writes:
There is a ~600-700 msec RTT between the ground NTP servers and the ISS NTP server.
How stable is that ?
Is there a lot of sample-to-sample jitter ?
Have they clamped the poll-rate on the S2 ?
If the pathway is like the ones to/from ISS that I am familiar with,
they're using the Ku-band or S-band link through TDRSS. In both cases,
the signal has to go from White Sands (or Guam) up to TDRSS, which is in
GEO, and then back down to ISS. There are also handoffs between, say,
TDRSS W and TDRSS E, where there will be a gap in comms, and then it
will resume, with a different light time delay.
There will also be some delays in translating the IP packets in and out
of the data streams, which encapsulate IP datagrams in some other packet
form (I can't remember if they're using CCSDS AOS or something else, but
there's a fair amount of encapsulation and segmentation going on to put
the IP traffic into a virtual channel). There could be delays in the
processing at HOSC that change during a pass, depending on their
buffering strategy.
This is a propagation path that I suspect NTP is just not designed to
deal with.
And, oh yes, getting diagnostic information or changes is quite the
tedious process, taking many days, typically.
Hi Jim,
On 2021-01-08 15:06, Lux, Jim wrote:
On 1/8/21 12:24 AM, Poul-Henning Kamp wrote:
Steven Sommars writes:
There is a ~600-700 msec RTT between the ground NTP servers and the
ISS NTP server.
How stable is that ?
Is there a lot of sample-to-sample jitter ?
Have they clamped the poll-rate on the S2 ?
If the pathway is like the ones to/from ISS that I am familiar with,
they're using the Ku-band or S-band link through TDRSS. In both cases,
the signal has to go from White Sands (or Guam) up to TDRSS, which is
in GEO, and then back down to ISS. There are also handoffs between,
say, TDRSS W and TDRSS E, where there will be a gap in comms, and
then it will resume, with a different light time delay.
Not a trivial path. Then again, the connection to White Sands or Guam
also comes into the path.
There will also be some delays in translating the IP packets in and
out of the data streams, which encapsulate IP datagrams in some other
packet form (I can't remember if they're using CCSDS AOS or something
else, but there's a fair amount of encapsulation and segmentation
going on to put the IP traffic into a virtual channel). There could
be delays in the processing at HOSC that change during a pass,
depending on their buffering strategy.
Beyond that, exactly how high priority it has in the scheduling of
buffers as traversing that path, will be very relevant.
This is a propagation path that I suspect NTP is just not designed to
deal with.
Well, I wonder if NTP over that path is even the best solution. Taking
time off a GPS/GNSS receiver onboard the ISS would be a significant
improvement. Just having the PPS would help immensly.
And, oh yes, getting diagnostic information or changes is quite the
tedious process, taking many days, typically.
For good and bad.
Cheers,
Magnus
Using NTP, with long and asymmetric path delays, seems like a recipe for
disaster. Can they not simply use a GPS receiver?
On 1/8/21 6:59 AM, Magnus Danielson wrote:
Hi Jim,
On 2021-01-08 15:06, Lux, Jim wrote:
On 1/8/21 12:24 AM, Poul-Henning Kamp wrote:
Steven Sommars writes:
There is a ~600-700 msec RTT between the ground NTP servers and the
ISS NTP server.
How stable is that ?
Is there a lot of sample-to-sample jitter ?
Have they clamped the poll-rate on the S2 ?
If the pathway is like the ones to/from ISS that I am familiar with,
they're using the Ku-band or S-band link through TDRSS. In both cases,
the signal has to go from White Sands (or Guam) up to TDRSS, which is
in GEO, and then back down to ISS. There are also handoffs between,
say, TDRSS W and TDRSS E, where there will be a gap in comms, and
then it will resume, with a different light time delay.
Not a trivial path. Then again, the connection to White Sands or Guam
also comes into the path.
I don't know where the ground NTP server is, but if it's at HOSC at
Marshall Spaceflight Center, there's a fairly high performance dedicated
link to White Sands and Guam with fairly consistent latency.
(HOSC - Huntsville Operations Support Center, also the POIC - Payload
Operations and Integration Center)
There will also be some delays in translating the IP packets in and
out of the data streams, which encapsulate IP datagrams in some other
packet form (I can't remember if they're using CCSDS AOS or something
else, but there's a fair amount of encapsulation and segmentation
going on to put the IP traffic into a virtual channel). There could
be delays in the processing at HOSC that change during a pass,
depending on their buffering strategy.
Beyond that, exactly how high priority it has in the scheduling of
buffers as traversing that path, will be very relevant.
Indeed - after all, they also support VoIP and teleconferencing via the
Ku-band link and there's a whole raft of QoS rules and constraints. The
scheduling of the Ku-band link is pretty complex, because it needs a
high gain antenna on a gimbal that's on ISS, and there's a whole host of
constraints when there are visiting vehicles, etc.
This is a propagation path that I suspect NTP is just not designed to
deal with.
Well, I wonder if NTP over that path is even the best solution. Taking
time off a GPS/GNSS receiver onboard the ISS would be a significant
improvement. Just having the PPS would help immensly.
That is probably harder than it seems. There's a lot of isolation among
systems on ISS - partly for safety, partly from history, partly from
institutional inertia. My payload on ISS (SCaN Testbed) had a
MIL-STD-1553 connection and a unidirectional Ethernet connection (out of
payload only). There's multiple GNSS receivers on ISS, but not all are
visible to an arbitrary payload - their output might get packaged up as
telemetry and store/forward sent to the ground via episodic
transmissions on the Ku-band system. One of the experiments on my
payload was to actually try to measure the time and position offsets
between our radio(which had S-band Tx/Rx and GPS receiver) and the
various time sources on the Station.
It is exceedingly unlikely that there is a 1pps signal available for
distribution on board - it's just not something that someone would have
written a requirement for. The folks designing Station are not time-nuts
- the idea of a "house frequency/time standard" would not have occurred
to them, except perhaps in the context of a limited subsystem.
The best bet is probably hooking into the "Broadcast Ancillary Data"
(BAD) which does get fed to a lot of subsystems and experiments on
Station in various forms. It has current (predicted) position and time
(Flight Dynamics Facility at GSFC calculates where ISS is going to be,
that gets uplinked, and then broadcast across Station) with some sort of
time hacks.
Station (writ large, not just the part in space) is kind of an unusual
place to work - think of it as a village or small town of several
thousands of people, each with a specialization and some knowledge of
what their neighbor does, but very few with details about the whole
thing. And because it's a thriving, but isolated, community, they speak
a different language. And the overall architecture was determined in the
1970s and has been substantially modified over the years since then, but
still has a lot of ties back to "the way it was done". I used to
liken trying to find out stuff to being dropped on the edge of a small
town in France, and you don't know French, but you do know some Spanish,
and you have to find the person you're looking for by asking questions
and being handed off from one person to the next. Once you're "in the
system" you can get stuff done pretty easily, but oh wow, if you are
new, or trying to do something "different" it can be quite the
adventure. I'm glad I did it. I'd rather not do it again.
Is this a new problem or has it being happening since day 1?
Jim Palfreyman
On Fri, 8 Jan 2021 at 5:42 pm, Steven Sommars stevesommarsntp@gmail.com
wrote:
At the end of November a question
https://lists.ntp.org/pipermail/questions/2020-November/041883.htmlwas
posed to the ntp.org list concerning NTP problems on the International
Space Station.
With William's permission I'm following up on the time-nuts list.
I analyzed NTP/IP packet captures provided by William and reported on
external visible behaviors. The much simplified diagram is
2 x Ground NTP(strat 1) --------------- ISS NTP server(strat 2)
-----(gigastor)------- ISS NTP clients(strat 3)
There is a ~600-700 msec RTT between the ground NTP servers and the ISS NTP
server.
As William describes, the clients are having trouble synchronizing with the
stratum 2 ISS NTP server.
This server is not working well. Here is the UTC time offset seen from an
external packet capture device (Gigastor)
[The Gigastor is only approximately sync'd to UTC, hence the 4 second
offset]
[image: image.png]
The y-axis scale is seconds.
Note also that after each step the initial error is about -500 ppm. When
the server is in alarm the error stays at -500ppm.
When not in alarm the server's clock frequency is changing in the wrong
direction with a resulting error of up to ~ -1500ppm.
Could this be an example of the Integral Windup problem mentioned recently
by PHK and Magnus?
Have others seen this behavior in NTP?
Getting additional diagnostic information from the ISS is quite difficult.
Even simple changes (e.g., remove ntp.drift) require much planning.
Steve Sommars
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
On Fri, Jan 8, 2021 at 11:40 AM Lux, Jim jim@luxfamily.com wrote:
On 1/8/21 6:59 AM, Magnus Danielson wrote:
Hi Jim,
On 2021-01-08 15:06, Lux, Jim wrote:
On 1/8/21 12:24 AM, Poul-Henning Kamp wrote:
Steven Sommars writes:
There is a ~600-700 msec RTT between the ground NTP servers and the
ISS NTP server.
How stable is that ?
Is there a lot of sample-to-sample jitter ?
Have they clamped the poll-rate on the S2 ?
If the pathway is like the ones to/from ISS that I am familiar with,
they're using the Ku-band or S-band link through TDRSS. In both cases,
the signal has to go from White Sands (or Guam) up to TDRSS, which is
in GEO, and then back down to ISS. There are also handoffs between,
say, TDRSS W and TDRSS E, where there will be a gap in comms, and
then it will resume, with a different light time delay.
Not a trivial path. Then again, the connection to White Sands or Guam
also comes into the path.
I don't know where the ground NTP server is, but if it's at HOSC at
Marshall Spaceflight Center, there's a fairly high performance dedicated
link to White Sands and Guam with fairly consistent latency.
(HOSC - Huntsville Operations Support Center, also the POIC - Payload
Operations and Integration Center)
There will also be some delays in translating the IP packets in and
out of the data streams, which encapsulate IP datagrams in some other
packet form (I can't remember if they're using CCSDS AOS or something
else, but there's a fair amount of encapsulation and segmentation
going on to put the IP traffic into a virtual channel). There could
be delays in the processing at HOSC that change during a pass,
depending on their buffering strategy.
Beyond that, exactly how high priority it has in the scheduling of
buffers as traversing that path, will be very relevant.
Indeed - after all, they also support VoIP and teleconferencing via the
Ku-band link and there's a whole raft of QoS rules and constraints. The
scheduling of the Ku-band link is pretty complex, because it needs a
high gain antenna on a gimbal that's on ISS, and there's a whole host of
constraints when there are visiting vehicles, etc.
This is a propagation path that I suspect NTP is just not designed to
deal with.
Well, I wonder if NTP over that path is even the best solution. Taking
time off a GPS/GNSS receiver onboard the ISS would be a significant
improvement. Just having the PPS would help immensly.
That is probably harder than it seems. There's a lot of isolation among
systems on ISS - partly for safety, partly from history, partly from
institutional inertia. My payload on ISS (SCaN Testbed) had a
MIL-STD-1553 connection and a unidirectional Ethernet connection (out of
payload only). There's multiple GNSS receivers on ISS, but not all are
visible to an arbitrary payload - their output might get packaged up as
telemetry and store/forward sent to the ground via episodic
transmissions on the Ku-band system. One of the experiments on my
payload was to actually try to measure the time and position offsets
between our radio(which had S-band Tx/Rx and GPS receiver) and the
various time sources on the Station.
I must admit that I'm very surprised that GPS receivers worked and
were able to compute a fix.
The majority of GPS receiver chipsets have altitude and speed limits
built in, both because of assumptions/discarding pathological results,
but also because of ITAR and similar regulations. Were these special /
licensed receivers which didn't have the "Erk, I think I'm on an ICBM"
logic?
W
It is exceedingly unlikely that there is a 1pps signal available for
distribution on board - it's just not something that someone would have
written a requirement for. The folks designing Station are not time-nuts
- the idea of a "house frequency/time standard" would not have occurred
to them, except perhaps in the context of a limited subsystem.
The best bet is probably hooking into the "Broadcast Ancillary Data"
(BAD) which does get fed to a lot of subsystems and experiments on
Station in various forms. It has current (predicted) position and time
(Flight Dynamics Facility at GSFC calculates where ISS is going to be,
that gets uplinked, and then broadcast across Station) with some sort of
time hacks.
Station (writ large, not just the part in space) is kind of an unusual
place to work - think of it as a village or small town of several
thousands of people, each with a specialization and some knowledge of
what their neighbor does, but very few with details about the whole
thing. And because it's a thriving, but isolated, community, they speak
a different language. And the overall architecture was determined in the
1970s and has been substantially modified over the years since then, but
still has a lot of ties back to "the way it was done". I used to
liken trying to find out stuff to being dropped on the edge of a small
town in France, and you don't know French, but you do know some Spanish,
and you have to find the person you're looking for by asking questions
and being handed off from one person to the next. Once you're "in the
system" you can get stuff done pretty easily, but oh wow, if you are
new, or trying to do something "different" it can be quite the
adventure. I'm glad I did it. I'd rather not do it again.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
--
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
-- E. W. Dijkstra
Is this a new problem or has it being happening since day 1?
It's unclear how long it has been happening. The team responsible for
managing the NTP Server noticed irregularities with its ability to sync to
ground but we don't know how long it had been going on for. In an effort to
fix it the following changes were made to the ISS NTP Server:
tinker panic 0
tos maxdist 60
tinker step 0.256
tinker stepout 150
server <groundserver> iburst trust minpoll 4 maxpoll 5
peer <2ndISSNTPServer>
After these changes were made my team began noticing sync issues with our
NTP clients. We chased part of this down to high root dispersion from the
NTP server due to the tos maxdist 60 setting. Implementing that setting on
our NTP clients allowed them to sync with the ISS NTP server ~90% of the
time, attempting to chase down the final 10% is what brought me to Steve
(and now here).
With only 2 full days worth of packet captures in October and no data
before the server changes were made (or even what symptoms inspired the
changes -- only that they were noticing "sync issues" with ground), we're
left with the current graphs Steve has made from the captures. The hope is
to get more data on the ISS NTP server after another meeting with this team
in late January. Unfortunately in the meantime this is all we have (which I
know doesn't fully answer your question), sorry about that.
William Dell
On Fri, Jan 8, 2021 at 2:20 PM Jim Palfreyman jim77742@gmail.com wrote:
Is this a new problem or has it being happening since day 1?
Jim Palfreyman
On Fri, 8 Jan 2021 at 5:42 pm, Steven Sommars stevesommarsntp@gmail.com
wrote:
At the end of November a question
https://lists.ntp.org/pipermail/questions/2020-November/041883.htmlwas
posed to the ntp.org list concerning NTP problems on the International
Space Station.
With William's permission I'm following up on the time-nuts list.
I analyzed NTP/IP packet captures provided by William and reported on
external visible behaviors. The much simplified diagram is
2 x Ground NTP(strat 1) --------------- ISS NTP server(strat
-----(gigastor)------- ISS NTP clients(strat 3)
There is a ~600-700 msec RTT between the ground NTP servers and the ISS
NTP
server.
As William describes, the clients are having trouble synchronizing with
the
stratum 2 ISS NTP server.
This server is not working well. Here is the UTC time offset seen from
an
external packet capture device (Gigastor)
[The Gigastor is only approximately sync'd to UTC, hence the 4 second
offset]
[image: image.png]
The y-axis scale is seconds.
Note also that after each step the initial error is about -500 ppm. When
the server is in alarm the error stays at -500ppm.
When not in alarm the server's clock frequency is changing in the wrong
direction with a resulting error of up to ~ -1500ppm.
Could this be an example of the Integral Windup problem mentioned
recently
by PHK and Magnus?
Have others seen this behavior in NTP?
Getting additional diagnostic information from the ISS is quite
difficult.
Even simple changes (e.g., remove ntp.drift) require much planning.
Steve Sommars
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Warren,
On 2021-01-08 23:15, Warren Kumari wrote:
On Fri, Jan 8, 2021 at 11:40 AM Lux, Jim jim@luxfamily.com wrote:
On 1/8/21 6:59 AM, Magnus Danielson wrote:
That is probably harder than it seems. There's a lot of isolation among
systems on ISS - partly for safety, partly from history, partly from
institutional inertia. My payload on ISS (SCaN Testbed) had a
MIL-STD-1553 connection and a unidirectional Ethernet connection (out of
payload only). There's multiple GNSS receivers on ISS, but not all are
visible to an arbitrary payload - their output might get packaged up as
telemetry and store/forward sent to the ground via episodic
transmissions on the Ku-band system. One of the experiments on my
payload was to actually try to measure the time and position offsets
between our radio(which had S-band Tx/Rx and GPS receiver) and the
various time sources on the Station.
I must admit that I'm very surprised that GPS receivers worked and
were able to compute a fix.
The majority of GPS receiver chipsets have altitude and speed limits
built in, both because of assumptions/discarding pathological results,
but also because of ITAR and similar regulations. Were these special /
licensed receivers which didn't have the "Erk, I think I'm on an ICBM"
logic?
These receivers do not follow the ITAR rules for sure. Just being beyond
18 km is breaking one ITAR rule, being faster than 1 MACH is another
(don't recall the exact number for ITAR, but there aboutish).
But it works.
A fun special satellite measures the GPS satellite occulation behavior,
thus how the signal bends from below the horizon to just above. That is
an atmospheric measurement tool. For sure not ITAR compliant.
Cheers,
Magnus
On 1/8/21 2:15 PM, Warren Kumari wrote:
This is a propagation path that I suspect NTP is just not designed to
deal with.
Well, I wonder if NTP over that path is even the best solution. Taking
time off a GPS/GNSS receiver onboard the ISS would be a significant
improvement. Just having the PPS would help immensly.
That is probably harder than it seems. There's a lot of isolation among
systems on ISS - partly for safety, partly from history, partly from
institutional inertia. My payload on ISS (SCaN Testbed) had a
MIL-STD-1553 connection and a unidirectional Ethernet connection (out of
payload only). There's multiple GNSS receivers on ISS, but not all are
visible to an arbitrary payload - their output might get packaged up as
telemetry and store/forward sent to the ground via episodic
transmissions on the Ku-band system. One of the experiments on my
payload was to actually try to measure the time and position offsets
between our radio(which had S-band Tx/Rx and GPS receiver) and the
various time sources on the Station.
I must admit that I'm very surprised that GPS receivers worked and
were able to compute a fix.
The majority of GPS receiver chipsets have altitude and speed limits
built in, both because of assumptions/discarding pathological results,
but also because of ITAR and similar regulations. Were these special /
licensed receivers which didn't have the "Erk, I think I'm on an ICBM"
logic?
Yes - these are all flight qualified GNSS receivers specifically
designed for space use. JPL has been building receivers for this kind
of application for decades.
As a practical matter, one can buy standard GPS receivers (like the ever
popular Novatel OEM 6 and 7 series) that are enabled for space. Whether
they survive single event effects or total dose accumulation is another
issue, but a lot of people fly them and they work pretty well. I didn't
have any problems with them on a cube-sat I flew.
Responses to several comments.
Opportunities to collect critical NTP debugging data on the ISS will be
limited.
Specific suggestions sent to me off-list would be appreciated.
Earth station to ISS delays: I inferred the 600-700 msec RTT using the
reported root distance
[I've seen much higher delays on some terrestrial NTP paths. ]
To really understand RTT / RTT stability NTP server diagnostic data is
needed.
GPS/GNSS, PPS distribution: seems like a good idea, but this is outside
the area I'm helping with
NTP (4.2.8) algorithmic changes are probably out of scope for the near
future.
If a real-world PLL problem can be documented, the ntp daemon maintainers
might be motivated to investigate.
So far I haven't been able to reproduce on my home Rpi some key features of
the offset graph I showed.
- pll error begins at -500 ppm
- pll error grows to -1000 or even -1500 ppm
- After step pll error is again -500 ppm
- Does not self correct within 24 hours
By placing large positive or negative values into the NTP drift file I can
produce offset charts with a series of steps, but eventually the steps stop
and the offset is small.
Thanks for all the replies.
Magnus, Warren,
ITAR are US rules for US products. Thus ITAR don’t apply for non US products. Has that changed?
The original COCOM rule was “don’t do altitude above 18000m and speed exceeding 1000 knots. “
COCOM was then replaced by the Wassenaar agreement. I would have expected it the current list - but could not find it.
Did I miss it or has it moved somewhere else?
Kind regards,
Björn
Sent from my iPhone
On 9 Jan 2021, at 00:13, Magnus Danielson magnus@rubidium.se wrote:
Warren,
On 2021-01-08 23:15, Warren Kumari wrote:
On Fri, Jan 8, 2021 at 11:40 AM Lux, Jim jim@luxfamily.com wrote:
On 1/8/21 6:59 AM, Magnus Danielson wrote:
That is probably harder than it seems. There's a lot of isolation among
systems on ISS - partly for safety, partly from history, partly from
institutional inertia. My payload on ISS (SCaN Testbed) had a
MIL-STD-1553 connection and a unidirectional Ethernet connection (out of
payload only). There's multiple GNSS receivers on ISS, but not all are
visible to an arbitrary payload - their output might get packaged up as
telemetry and store/forward sent to the ground via episodic
transmissions on the Ku-band system. One of the experiments on my
payload was to actually try to measure the time and position offsets
between our radio(which had S-band Tx/Rx and GPS receiver) and the
various time sources on the Station.
I must admit that I'm very surprised that GPS receivers worked and
were able to compute a fix.
The majority of GPS receiver chipsets have altitude and speed limits
built in, both because of assumptions/discarding pathological results,
but also because of ITAR and similar regulations. Were these special /
licensed receivers which didn't have the "Erk, I think I'm on an ICBM"
logic?
These receivers do not follow the ITAR rules for sure. Just being beyond
18 km is breaking one ITAR rule, being faster than 1 MACH is another
(don't recall the exact number for ITAR, but there aboutish).
But it works.
A fun special satellite measures the GPS satellite occulation behavior,
thus how the signal bends from below the horizon to just above. That is
an atmospheric measurement tool. For sure not ITAR compliant.
Cheers,
Magnus
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Björn,
you are correct. The link you have provided points to the actual and latest document of the Wassenaar Arrangement for so-called "Dual-Use" items.
This international agreement is transformed to National laws, which often include some amendments.
For the European Union it is the COUNCIL REGULATION (EC) No 428/2009, which is regularly updated, latest on is the
COMMISSION DELEGATED REGULATION (EU) 2020/1749.
BTAW: For time-nuts the chapter 3.A.1.b is interesting, which covers microwave and millimeter wave items.
Under sub-clause 3.A.1.b.10 limitations for phase noise of these items are defined as follows:
Oscillators or oscillator assemblies, specified to operate with a single sideband (SSB) phase noise, in
dBc/Hz, less (better) than -(126 + 20log10F – 20log10f) anywhere within the range of 10 Hz ≤ F≤ 10 kHz;
(F is the offset from the operating frequency in Hz and f is the operating frequency in MHz)
From the technical viewpoint it does not make much sense to specify the phase noise limits with a slope of -20 dB/decade, while in practice (and theory) the slope close to carrier is -30 dBc/Hz.
Not too seldom, it is not recognized that this rule is limited to microwave and millimeter wave oscillators. As the document does not define where "microwave" begins, this rule is sometimes applied to crystal oscillators below 200 MHz- which to my opinion is wrong, as microwaves are starting above 1 GHz or so.
Regards
Bernd
-----Ursprüngliche Nachricht-----
Von: time-nuts [mailto:time-nuts-bounces@lists.febo.com] Im Auftrag von Björn
Gesendet: Samstag, 9. Januar 2021 06:04
An: Discussion of precise time and frequency measurement time-nuts@lists.febo.com
Betreff: Re: [time-nuts] ISS NTP operation problems.
Magnus, Warren,
ITAR are US rules for US products. Thus ITAR don’t apply for non US products. Has that changed?
The original COCOM rule was “don’t do altitude above 18000m and speed exceeding 1000 knots. “
COCOM was then replaced by the Wassenaar agreement. I would have expected it the current list - but could not find it.
Did I miss it or has it moved somewhere else?
Kind regards,
Björn
Sent from my iPhone
On 9 Jan 2021, at 00:13, Magnus Danielson magnus@rubidium.se wrote:
Warren,
On 2021-01-08 23:15, Warren Kumari wrote:
On Fri, Jan 8, 2021 at 11:40 AM Lux, Jim jim@luxfamily.com wrote:
On 1/8/21 6:59 AM, Magnus Danielson wrote:
That is probably harder than it seems. There's a lot of isolation
among systems on ISS - partly for safety, partly from history,
partly from institutional inertia. My payload on ISS (SCaN Testbed)
had a
MIL-STD-1553 connection and a unidirectional Ethernet connection
(out of payload only). There's multiple GNSS receivers on ISS, but
not all are visible to an arbitrary payload - their output might get
packaged up as telemetry and store/forward sent to the ground via
episodic transmissions on the Ku-band system. One of the
experiments on my payload was to actually try to measure the time
and position offsets between our radio(which had S-band Tx/Rx and
GPS receiver) and the various time sources on the Station.
I must admit that I'm very surprised that GPS receivers worked and
were able to compute a fix.
The majority of GPS receiver chipsets have altitude and speed limits
built in, both because of assumptions/discarding pathological
results, but also because of ITAR and similar regulations. Were these
special / licensed receivers which didn't have the "Erk, I think I'm on an ICBM"
logic?
These receivers do not follow the ITAR rules for sure. Just being
beyond
18 km is breaking one ITAR rule, being faster than 1 MACH is another
(don't recall the exact number for ITAR, but there aboutish).
But it works.
A fun special satellite measures the GPS satellite occulation
behavior, thus how the signal bends from below the horizon to just
above. That is an atmospheric measurement tool. For sure not ITAR compliant.
Cheers,
Magnus
time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go
to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
On 1/9/21 12:30 AM, Bernd Neubig wrote:
Björn,
you are correct. The link you have provided points to the actual and latest document of the Wassenaar Arrangement for so-called "Dual-Use" items.
This international agreement is transformed to National laws, which often include some amendments.
For the European Union it is the COUNCIL REGULATION (EC) No 428/2009, which is regularly updated, latest on is the
COMMISSION DELEGATED REGULATION (EU) 2020/1749.
BTAW: For time-nuts the chapter 3.A.1.b is interesting, which covers microwave and millimeter wave items.
Under sub-clause 3.A.1.b.10 limitations for phase noise of these items are defined as follows:
Oscillators or oscillator assemblies, specified to operate with a single sideband (SSB) phase noise, in
dBc/Hz, less (better) than -(126 + 20log10F – 20log10f) anywhere within the range of 10 Hz ≤ F≤ 10 kHz;
(F is the offset from the operating frequency in Hz and f is the operating frequency in MHz)
From the technical viewpoint it does not make much sense to specify the phase noise limits with a slope of -20 dB/decade, while in practice (and theory) the slope close to carrier is -30 dBc/Hz.
Not too seldom, it is not recognized that this rule is limited to microwave and millimeter wave oscillators. As the document does not define where "microwave" begins, this rule is sometimes applied to crystal oscillators below 200 MHz- which to my opinion is wrong, as microwaves are starting above 1 GHz or so.
Regards
Bernd
Based on my somewhat sketchy and unreliable experience interpreting
export control rules (see digression below) and the knowledge that this
is the province of export control lawyers, not engineers.
This might be interpreted as "oscillators that would/could be used in
microwave or millimeter wave equipment", not that the oscillator itself
is microwave. However, it could also be interpreted as the basic
oscillator (e.g. the VCO in a PLL) performance.
in numbers, for a 100 MHz oscillator , this is -106 dBc/Hz at 10 Hz
offset to -166 dBc/Hz at 10kHz
-----Ursprüngliche Nachricht-----
Von: time-nuts [mailto:time-nuts-bounces@lists.febo.com] Im Auftrag von Björn
Gesendet: Samstag, 9. Januar 2021 06:04
An: Discussion of precise time and frequency measurement time-nuts@lists.febo.com
Betreff: Re: [time-nuts] ISS NTP operation problems.
Magnus, Warren,
ITAR are US rules for US products. Thus ITAR don’t apply for non US products. Has that changed?
The original COCOM rule was “don’t do altitude above 18000m and speed exceeding 1000 knots. “
COCOM was then replaced by the Wassenaar agreement. I would have expected it the current list - but could not find it.
Did I miss it or has it moved somewhere else?
Yes, you're right, it's the Wassenaar Arrangement, and more
technically, the two lists, munitions and dual use. (The Wassenaar
Agreement is something about labor laws)
A lot of people (particularly in US) use ITAR (International Traffic in
Arms Regulations) as a catchall word for export controlled, although the
list is actually the USML (United States Munitions List), and it's
purely a US thing. And of course there's also the EAR (Export
Administration Regulations) which has the CCL (Commerce Control List).
They're handled by the State Department and Commerce Department
respectively.
And, as an export control specialist explained when I was first at JPL
20 years ago and working on an export license and end-user-certificate
for a TWTA: You are an engineer - the export control regulations were
not created nor are they "understandable" as engineering specifications
or requirements. The determination is made (seemingly arbitrarily) by
someone at State or Commerce. Use the lists as "guidance" but don't try
to lawyer your way through them to find exceptions. This is
particularly true for the EAR/CCL which is often more about trade wars
than "engines of war". It's like the recent tariff stuff - ferrite
cores by themselves, no tariff. Ferrite cores for use in computer power
supplies, 25% tariff. (I might have that backwards) Same exact core part
number, just how it's sold.
Most (but not all) of the Wassenaar munitions list and USML have the
"specifically designed for" clause, which helps a lot with dual use
things like GNSS receivers. Diesel engines designed for submarines -
restricted; other diesel engines - have at it.
The lists have a pervasive effect beyond the obvious. For example, you
will find that there are certain "breakpoints" in data sheet performance
on things like high speed ADCS. You find a lot of 16 bit ADCs that have
sample rates of 65 MSPS. What's special about that particular sample
rate? The part probably runs faster. "3.A.1.a.5.5. A resolution of 16
bit or more with a "sample rate" greater than 65 MSPS;" Likewise, you
see a lot of parts that have 300kRad dose tolerance, even though,
because are bipolar, they are Megarad hard. Why, right there in the USML
there's a restriction on parts that are "rated" at more than 300kRad.