In a (almost) ideal coaxial cable (almost) all RF electromagnetic field is inside the cable.
Unlike ladder balanced transmission line where it is everywhere else in the universe.
Leo
From: Peter Vince petervince1952@gmail.com
sure of the best advice to give him. I'm sure I heard that you should
never drop the coax down the middle of your support-pole, as the conducting
pole will mess up the characteristics of the cable by affecting the
currents in the outer braid.
Thank you all for your replies. A case of a little knowledge being a bad
thing in my case. But at least I was aware of a potential problem to be
considered! :-)
Thanks again,
Peter
If there are currents in the braid to upset then your antenna system is not working as you might believe.
On 5 Jul 2019, at 10:46, Peter Vince petervince1952@gmail.com wrote:
Thank you all for your replies. A case of a little knowledge being a bad
thing in my case. But at least I was aware of a potential problem to be
considered! :-)
Thanks again,
Peter
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, 5 Jul 2019 at 18:01, WigglePig wigglepig@gmail.com wrote:
If there are currents in the braid to upset then your antenna system is
not working as you might believe.
I was working on the simplistic assumption that for a current to flow,
there must be a complete circuit, so the current flows down the centre
conductor, and must come back up the braid. But I gather that unlike DC,
RF is "black magic", and only flows on the inside of the braid - if all the
impedances match.
Hi
The purpose of coax is to shield the signal. The outer portion of the cable
acts to protect the inner part from stray signals in the environment. In a normal
system, the outer braid is connected to ground. It is no different than a lot of audio
cabling in that respect.
Energy flow is indeed inside the cable if things are set up and operating correctly.
If it was on the outside, the shield would not be doing its job of protecting things.
This is only true to the extent that skin depth will allow it to happen.
Why does this matter? With something like a 1 pps timing pule, some portion of the
energy will be low enough in frequency to make it past the skin depth / thickness
of any practical cable. The components that create the fast rising edge will be contained,
but the low frequency stuff will not be. Fortunately we rarely use cables that are a
significant fraction of a wavelength at 1 Hz :)
Bob
On Jul 5, 2019, at 1:47 PM, Peter Vince petervince1952@gmail.com wrote:
On Fri, 5 Jul 2019 at 18:01, WigglePig wigglepig@gmail.com wrote:
If there are currents in the braid to upset then your antenna system is
not working as you might believe.
I was working on the simplistic assumption that for a current to flow,
there must be a complete circuit, so the current flows down the centre
conductor, and must come back up the braid. But I gather that unlike DC,
RF is "black magic", and only flows on the inside of the braid - if all the
impedances match.
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.
well, you have a point, the coax cable if it is ideal it will work as
somebody described earlier in that treed, but unfortunately life is
real, and therefore despite that the E and H field is mostly "inside of
the cable", but due to the cables loss particularly because braid has
resistance there will be a voltage between the two end of the cable's
shield. And that is related to a "mess" called transfer-impedance, and
about that you could find really interesting explanations like that:
https://spira-emi.com/references/pdf/tf4_cables_cntrs_hoeft.pdf and
thathttps://www.araconfiber.com/what-is-transfer-impedance/ and much
more, because that transfer impedance is a big headache for people who
are sending signals trough coax cables, and above a certain frequencies
the coaxial cable is not a "such a good thing" any more.
Just one very malicious note, that works reversible too: if you would
inject a signal to that braid's two ends, the signal would show up like
is it's source would be serial with the generator which is driving
"legally" the cable in "coaxial" mode. I know it is very nasty but it is
true, I found it out myself also some sixty-five years ego, and a whole
world of ideal system just collapsed at the front of me...
KJ6UHN
Alex
On 7/5/2019 10:47 AM, Peter Vince wrote:
On Fri, 5 Jul 2019 at 18:01, WigglePig wigglepig@gmail.com wrote:
If there are currents in the braid to upset then your antenna system is
not working as you might believe.
I was working on the simplistic assumption that for a current to flow,
there must be a complete circuit, so the current flows down the centre
conductor, and must come back up the braid. But I gather that unlike DC,
RF is "black magic", and only flows on the inside of the braid - if all the
impedances match.
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.
This email has been checked for viruses by AVG.
https://www.avg.com
In message 28F942E8-B61D-4FA5-929D-923184828FC1@n1k.org, Bob kb8tq writes:
Energy flow is indeed inside the cable if things are set up and operating correctly.
Please note in this context that nothing about lightning strikes
works the way you would assume it does.
Cables run inside steel tubes protect the steel tube from lightning
current because copper is a better conductor than steel - in
particular when the leading flank is measured in kV/uS and the
current in kA.
Likewise, a 90 degree bend or a loop on the cable is a huge
inductance to get all that high frequency energy through, so
lightning tend to jump from bends and loops, to less inductive
paths if possible
Be careful with EMI/EMC clam-on ferrites, they can explode in
lightning strikes.
--
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.
Am 05.07.19 um 23:26 schrieb Poul-Henning Kamp:
In message 28F942E8-B61D-4FA5-929D-923184828FC1@n1k.org, Bob kb8tq writes:
Energy flow is indeed inside the cable if things are set up and operating correctly.
Please note in this context that nothing about lightning strikes
works the way you would assume it does.
A friend of mine got his ham radio station pulverized by a lightning
hit in the garden. He had written his PHD thesis on the breakdown
mechanism when charge powers its way through gases.
I call that an a posteriori field research addendum. ;-)
Cables run inside steel tubes protect the steel tube from lightning
current because copper is a better conductor than steel - in
particular when the leading flank is measured in kV/uS and the
current in kA.
Likewise, a 90 degree bend or a loop on the cable is a huge
inductance to get all that high frequency energy through, so
lightning tend to jump from bends and loops, to less inductive
paths if possible
Be careful with EMI/EMC clam-on ferrites, they can explode in
lightning strikes.
Then I look upon my pole as a 2 meter long clamp-on ferrite.
That 7 mm Aircell cable won't conduct much better than the pole,
and the outside of the pole will look quite, eh, attractive, given that
king size common mode choke.
And then, at the 90° cable corner to my lab, the lightning bolt may
continue
downwards through earth on its highway to hell..
cheers, Gerhard
(Unix V6 on 1 of the 5 PDP 11/40E that ever existed)
On 7/5/19 2:26 PM, Poul-Henning Kamp wrote:
In message 28F942E8-B61D-4FA5-929D-923184828FC1@n1k.org, Bob kb8tq writes:
Energy flow is indeed inside the cable if things are set up and operating correctly.
Please note in this context that nothing about lightning strikes
works the way you would assume it does.
Cables run inside steel tubes protect the steel tube from lightning
current because copper is a better conductor than steel - in
particular when the leading flank is measured in kV/uS and the
current in kA.
Likewise, a 90 degree bend or a loop on the cable is a huge
inductance to get all that high frequency energy through, so
lightning tend to jump from bends and loops, to less inductive
paths if possible
Actually, the inductance of a bend isn't much more than the inductance
of a straight piece of wire of the same length. You have to have a
complete loop before the inductance starts to rise, and even then, a 1
turn loop doesn't have huge inductance, it's multiple loops where the
inductance starts to rise as Nturns^2.
Straight wire has an inductance of about 1 microhenry/meter (very weakly
dependent on diameter)
But a more exact calculation says that a 31.4 cm piece of wire, 10mm in
diameter has a self L of 0.26 microhenry.
A loop that is 100mm in diameter with a 10mm diameter conductor has an
inductance of about 0.15 microHenry. 100mm diameter is a length of 0.314
meters, so it actually has less inductance that a wire that's the
length of the perimeter.
A 1 meter diameter loop (perimeter 3.14 meters) has an inductance of 3
uH. Which is close to the self inductance of a 3.14 meter straight wire
(4 uH)
The origin of the "no sharp bends in lightning conductors" is more
related to the flashover voltage to surroundings - A sharp 90 bend has a
lower breakdown voltage than a gradual bend because the radius of
curvature is smaller.
There's also a mechanical stress effect - if you have a corner, the wire
on one side of the corner is carrying a current at right angles the
field from the other arm of the corner, and it will tend to move
(violently, given the large peak currents)
Be careful with EMI/EMC clam-on ferrites, they can explode in
lightning strikes.
Has anyone got this , is the PIC read data prohibited ?
Is it still a closely guarded secret?, there were some very clever and
novel ideas used in that slab, in my opinion.
Glen
On 7/5/2019 8:20 PM, Glen English VK1XX wrote:
Has anyone got this , is the PIC read data prohibited ?
Is it still a closely guarded secret?, there were some very clever and
novel ideas used in that slab, in my opinion.
Glen
Hi Glen. I worked on this project, but am an RF/Analog
guy. The product line was sold to Symmetricom 20 years
ago and they didn't continue the E1938A. At that point,
there were no closely guarded secrets. I don't know what
happened to the source code. The last contract manufacturer
for the E1938A was Scotts Valley Magnetics. You could
contact them and see if they have the PIC info. In theory,
they would have had to have it to program the PIC's.
The most clever thing in the PIC (AFAIK) is the oven
controller with the double integrator. "P, I, I^2, D".
Len Cutler was the mastermind behind this. I believe
he leveraged his experience with double integrators used
in Cs control loops. I remember him telling me that the
secret was to have an "anti-windup" algorithm. Whatever
he did, the results were phenomenal. I spent countless
days in the lab exercising the loop and it always worked
perfectly.
Rick Karlquist, N6RK
Hi Rick
Thank you very much for the reply and the suggested leads. I think your
work on the balanced bridge oscillator was both preeminant and seminal .
I have read all the papers on it, and there are few other things in my
30 years of this field professionally that really impress me as much in
the new approaches and new thinking on the entire unit. Agreed on the
PII^2D control system.
I've built a few OCXOs back in the 90s, the best I did on (inner) oven
control was using dual glass bead thermistors in a bridge configuration
with lots of gain driving a simple opamp integrator. The opamp was
chopper stabilized and I ensured the op amp never operated in the
crossover region of the opamp output driver. These were on AT cuts at
97 deg C ...
cheers
Glen. AI6UM / VK1XX
On 6/07/2019 2:37 PM, Richard (Rick) Karlquist wrote:
On 7/5/2019 8:20 PM, Glen English VK1XX wrote:
Has anyone got this , is the PIC read data prohibited ?
Is it still a closely guarded secret?, there were some very clever
and novel ideas used in that slab, in my opinion.
Glen
Hi Glen. I worked on this project, but am an RF/Analog
guy. The product line was sold to Symmetricom 20 years
ago and they didn't continue the E1938A. At that point,
there were no closely guarded secrets. I don't know what
happened to the source code. The last contract manufacturer
for the E1938A was Scotts Valley Magnetics. You could
contact them and see if they have the PIC info. In theory,
they would have had to have it to program the PIC's.
The most clever thing in the PIC (AFAIK) is the oven
controller with the double integrator. "P, I, I^2, D".
Len Cutler was the mastermind behind this. I believe
he leveraged his experience with double integrators used
in Cs control loops. I remember him telling me that the
secret was to have an "anti-windup" algorithm. Whatever
he did, the results were phenomenal. I spent countless
days in the lab exercising the loop and it always worked
perfectly.
Rick Karlquist, N6RK
I would agree that antiwindup is important when you have integrators. They
always seem to cause trouble without it, in applications as diverse as car
throttle control and time-domain filtering of respiratory data. I would
also recommend, sometimes, the use of feed-forward control to provide an
estimate of power demand without relying on the integrator : although most
useful for speeding the response, it can also reduce the expected
integrator term and hence allow more aggressive antiwindup.
On Sat, Jul 6, 2019 at 9:00 AM Glen English VK1XX <
glenlist@pacificmedia.com.au> wrote:
Hi Rick
Thank you very much for the reply and the suggested leads. I think your
work on the balanced bridge oscillator was both preeminant and seminal .
I have read all the papers on it, and there are few other things in my
30 years of this field professionally that really impress me as much in
the new approaches and new thinking on the entire unit. Agreed on the
PII^2D control system.
I've built a few OCXOs back in the 90s, the best I did on (inner) oven
control was using dual glass bead thermistors in a bridge configuration
with lots of gain driving a simple opamp integrator. The opamp was
chopper stabilized and I ensured the op amp never operated in the
crossover region of the opamp output driver. These were on AT cuts at
97 deg C ...
cheers
Glen. AI6UM / VK1XX
On 6/07/2019 2:37 PM, Richard (Rick) Karlquist wrote:
On 7/5/2019 8:20 PM, Glen English VK1XX wrote:
Has anyone got this , is the PIC read data prohibited ?
Is it still a closely guarded secret?, there were some very clever
and novel ideas used in that slab, in my opinion.
Glen
Hi Glen. I worked on this project, but am an RF/Analog
guy. The product line was sold to Symmetricom 20 years
ago and they didn't continue the E1938A. At that point,
there were no closely guarded secrets. I don't know what
happened to the source code. The last contract manufacturer
for the E1938A was Scotts Valley Magnetics. You could
contact them and see if they have the PIC info. In theory,
they would have had to have it to program the PIC's.
The most clever thing in the PIC (AFAIK) is the oven
controller with the double integrator. "P, I, I^2, D".
Len Cutler was the mastermind behind this. I believe
he leveraged his experience with double integrators used
in Cs control loops. I remember him telling me that the
secret was to have an "anti-windup" algorithm. Whatever
he did, the results were phenomenal. I spent countless
days in the lab exercising the loop and it always worked
perfectly.
Rick Karlquist, N6RK
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.
OK, good info, thanks.
Well I have bought 7 x E1938As, with the intention of building a better
GPSDO.
My interest in the E1938A firmware hex was if I had to replace any of
the PICs at sometime in the future.
My intention is to use the average of multiple stationary mode GPS 1PPS
signals to drive a single OCXO, the idea to be a better 1pps estimate.
I'll upsample the inputs to get the control sample rate up.
Eventually I want to explore the use multiple OCXOs, but not until I
think of a good way to take an average of multiple OCXOs, or, even if
that is a useful idea.
FPGA based, I'll put the OCXO drive and the 1ppS to the FPGA
differentially into maybe 8 FPGA inputs (that is each signal into 8
different FPGA pin pairs) , and use IDELAY blocks to delay the 8
different inputs to provide more edge resolution for each signal . The
IDELAY blocks can be dynamic but I'll probably use then fixed. output of
the FPGA can be sigma-delta converter, which can provide almost
arbritary number of bits. LVDS output of the 1 bit FPGA converter signal
will go to an outboard LVDS buffer with its own power supply so bumps on
FPGA VCCIO dont affect the output.
So first, I'll need to build a frequency/period counter in the same ilk
(same PCB)
I'll make these PCBs loaded available to all.
I have a protoype built and output at the moment is HD44780 LCD drive 8
bit bus to surplus 40x4 char displays I have around here. and also a
serial stream output. best to do only what is necessary on the FPGA
(rudimentary time/frequency output onto the LCD) , and feed data to an
analysis machine, RPI, PC whatever for analysis and display in Python 2.7X.
comments welcome.
-glen VK1XX / AI6UM
On 6/07/2019 10:06 PM, Adrian Godwin wrote:
I would agree that antiwindup is important when you have integrators. They
always seem to cause trouble without it, in applications as diverse as car
throttle control and time-domain filtering of respiratory data. I would
also recommend, sometimes, the use of feed-forward control to provide an
estimate of power demand without relying on the integrator : although most
useful for speeding the response, it can also reduce th
Hi
The gotcha with averaging multiple GPS modules is that there are a lot of common mode
issues present. The averaging will help with the random noise stuff, but will not do much for
the atmosphere, ephemeris, and other “external” limits. Unfortunately those limits are pretty
significant contributors.
More or less:
Sawtooth you can (and should) take care of with the correction information from the module.
No need to average there.
Random “I pick this / you pick that” stuff as constellations change will average out. ( = different
signal to noise numbers will be present in the voting process on each module). You can see
nanosecond level bumps from this. Since they are transient, exactly how much they contribute
to a long term average is debatable.
Ionosphere modeling errors will be the same for any rational group of modules running on the
same system in the same area. The same is true of troposphere related issues. These can
(but don’t always) get into the 10’s of nanosecond range. They can last long enough to pass
through normal long averaging filters.
The solutions are based on orbit and clock data broadcast in the ephemeris. Both can be off
by nanoseconds. Again, they are long term so they pas through averaging filters.
Probably better to focus on an ensemble of OCXO’s to lower the “local” noise floor:
As you sum independent devices, it is reasonable to expect things like ADEV to improve by
the square root of the number of devices. One limit to this is (as mentioned above) common
mode issues. With OCXO’s temperature would be a common mode item. Controlling or correcting
it would be a good idea.
A group of 4 OCXO’s in some sort of controlled enclosure could indeed be 2X better than a
single OCXO. Going up to 16 might get you 4X better. That range probably covers the range
(even at eBay prices) that one would be working in. Improvements of this sort have been demonstrated
in various (expensive) systems.
The same principle would apply to things like telecom Rb’s, but at a bit higher price. I do not know
of any commercial system doing that.
Bob
On Jul 6, 2019, at 7:00 PM, Glen English VK1XX glenlist@pacificmedia.com.au wrote:
OK, good info, thanks.
Well I have bought 7 x E1938As, with the intention of building a better GPSDO.
My interest in the E1938A firmware hex was if I had to replace any of the PICs at sometime in the future.
My intention is to use the average of multiple stationary mode GPS 1PPS signals to drive a single OCXO, the idea to be a better 1pps estimate. I'll upsample the inputs to get the control sample rate up.
Eventually I want to explore the use multiple OCXOs, but not until I think of a good way to take an average of multiple OCXOs, or, even if that is a useful idea.
FPGA based, I'll put the OCXO drive and the 1ppS to the FPGA differentially into maybe 8 FPGA inputs (that is each signal into 8 different FPGA pin pairs) , and use IDELAY blocks to delay the 8 different inputs to provide more edge resolution for each signal . The IDELAY blocks can be dynamic but I'll probably use then fixed. output of the FPGA can be sigma-delta converter, which can provide almost arbritary number of bits. LVDS output of the 1 bit FPGA converter signal will go to an outboard LVDS buffer with its own power supply so bumps on FPGA VCCIO dont affect the output.
So first, I'll need to build a frequency/period counter in the same ilk (same PCB)
I'll make these PCBs loaded available to all.
I have a protoype built and output at the moment is HD44780 LCD drive 8 bit bus to surplus 40x4 char displays I have around here. and also a serial stream output. best to do only what is necessary on the FPGA (rudimentary time/frequency output onto the LCD) , and feed data to an analysis machine, RPI, PC whatever for analysis and display in Python 2.7X.
comments welcome.
-glen VK1XX / AI6UM
On 6/07/2019 10:06 PM, Adrian Godwin wrote:
I would agree that antiwindup is important when you have integrators. They
always seem to cause trouble without it, in applications as diverse as car
throttle control and time-domain filtering of respiratory data. I would
also recommend, sometimes, the use of feed-forward control to provide an
estimate of power demand without relying on the integrator : although most
useful for speeding the response, it can also reduce th
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.
Glen English VK1XX writes:
My intention is to use the average of multiple stationary mode GPS
1PPS signals to drive a single OCXO, the idea to be a better 1pps
estimate. I'll upsample the inputs to get the control sample rate up.
I'd expect a lot of correlation among multiple GPS receivers, especially
when they're fed from the same antenna and are otherwise sharing the
same environment. Averaging will only deal with the non-correlated
errors in the signal.
Eventually I want to explore the use multiple OCXOs, but not until I
think of a good way to take an average of multiple OCXOs, or, even if
that is a useful idea.
I think you'll have trouble isolating these well enough to not (at least
occasionally) injection lock on each other.
FPGA based, I'll put the OCXO drive and the 1ppS to the FPGA
differentially into maybe 8 FPGA inputs (that is each signal into 8
different FPGA pin pairs) , and use IDELAY blocks to delay the 8
different inputs to provide more edge resolution for each signal.
There are a few recent papers on that topic and the IDELAY blocks are
indeed used in some of these. Getting them to track over voltage and
temperature is apparently a problem, so different methods of
implementing the TDC seem to be more useful depending on how far down
you want to push the resolution.
The IDELAY blocks can be dynamic but I'll probably use then
fixed. output of the FPGA can be sigma-delta converter, which can
provide almost arbritary number of bits. LVDS output of the 1 bit FPGA
converter signal will go to an outboard LVDS buffer with its own power
supply so bumps on FPGA VCCIO dont affect the output.
Getting the residual noise down on that signal will still be a
challenge, so you might want to (optionally) consider a proper DAC there
depending on how good an OCXO you intend to use.
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Hi Bob, and Achim . thanks for the comments. I've change the subject
line to fit more in line we the morphed discussion.
Good discussion, and like Bob said, there will be lots of common mode on
the GPSs. The diurnal GPS derived clock errors due to the ionosphere are
well described . Bob thats a good point about picking and choosing,
and long term effects.
My initial obs on two devices, tell me there IS significant
non-correlated noise between two of them, but this is on low cost GPS
and also I have not yet established how much noise is purely my edge
point sampling errors and nothing to do with the actual device, and the
two in question have different views of the sky....
Acbom, you have clearly thought about this. As for the IDELAYS etc,
IDELAYS yes have been used for this sort of thing since the mid 90s.
Enough of them and enough inputs and some known waveform to compensate
against, and some differential means, should be enough to mitigate the
temperature/process effects. If rising and falling edges are worked,
delay will affect both and compensate. While 1pps source might usually
be only accurate on one edge, nothing an external ECL / GaAs flip flop
won't fix to provide 1/2 pps.
One can also use PCB delay...150ps per inch... being careful of FR4
weave , zig zags etc.....although once the rise time of the signal gets
amongst the delay we want, thats uncertainty.
Assuming we end up with a single, nice clean compensated and as good as
possible timebase (from 1pps etc) (sounds like your territory, Bob), and
With multiple OCXO ( ALL being simultaneously inter-dependently
disclipined ) , there may be the opportunity to try different parameters
(or even algorithms) on the different OCXOs and pick the one with the
minimum squared error (or something like that) . What might kill that is
that the OCXOs vary quite alot even on the same model.
The goal of this is
a) to learn something- precision instrumentation is hard.
b) have a 1e-13 accurate long term (weeks on) frequency reference
c) have short term 1000 second stability <= 1e-12
glen
On 7/07/2019 6:56 PM, Achim Gratz wrote:
Glen English VK1XX writes:
OK so I have the NGOCOMM program for the E1938A.
I see looking at the DLLs it was written in Borland OWL.
Does anyone have the C++ source code, or know what is in it ,
and also does anyone know exactly what is in the E2PROM?
all this for extending the MAINTAINABLE life of these excellent OCXOs.
-glen