Discussion:
Advice on sighting a roof mounted gps area please
(too old to reply)
Alex Pummer
2017-04-20 02:20:42 UTC
Permalink
most likely the cooper is much ticker than the penetration of the lowest
frequency for which the cable is used, therefore the high frequency
"does not" see the steel inside of the cooper, that steel could cause
problem if the coax also used to carry some power -- DC or AC -- because
at lower frequency or DC the cable's current carried mostly in the
cooper, and while the cooper constitute just a small fraction of the
center wire cross section, a cable with "steel core" could carry much
less current, than a cable with full cooper. But the steel core cable
has one advantage it is usually stronger than a full cooper cable and
therefore it is usable for outside installation with larger support
distance.

73
KJ6UHN, [a former engineer of a cable manufacturer ]
Alex

On 4/19/2017 11:57 AM, Hal Murray wrote:
> ***@n1k.org said:
>> I’d want to be pretty sure what the center conductor was made out of. I’ve
>> seen some stuff in coax that “one would think” should not be there (copper
>> over steel 
).
> Does that effect the propagation time?
>
> If I gave you a good scope picture of a pulse after going through chunk of
> coax, could you figure out the ratio of copper to steel? Would you need to
> know the length or could you figure that out too?
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-***@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2016.0.8012 / Virus Database: 4769/14347 - Release Date: 04/19/17
John Ponsonby
2017-04-20 16:46:44 UTC
Permalink
Please forgive my ignorance but what is a TICC?
Regards
John P
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Tom Van Baak
2017-04-20 20:00:28 UTC
Permalink
> Please forgive my ignorance but what is a TICC?
> Regards
> John P

Short answer:

https://www.febo.com/pages/TICC/

https://www.tapr.org/kits_ticc.html

Long answer:

When working with precise time one of the very first instruments you'll want is a frequency counter. But when your clocks get accurate enough that your counter always reads 9.999 or 9.999999 or 10.000000000 a different measurement approach is called for. This is where a phase meter or Time Interval Counter (TIC) is useful: instead of making a frequency measurement for a fixed duration (gate time), you can instead continuously monitor the slow and steady drift in phase (time) between two sources; over seconds, over hundreds of seconds, even over days. Programs like Stable32 or TimeLab can make phase, frequency, or stability plots from the data set.

That's why a TIC can be used to measure coax temperature coefficient. A frequency counter can't do that.

Most of us get our counters from eBay where the favorite TIC's are SR 620, hp 5335, hp 5370, hp 53132. But it has always been a challenge to make a modern, cheap, homebrew TIC that matches commercial instruments in performance. Over the years a number of time nuts have tried to make sub-nanosecond counters. The most recent time interval counter by John Ackermann, the "TICC", is a winner. See the links above for details.

By using a recent off-the-shelf TDC (time to digital) chip from ti.com John avoided the complexity and analog calibration of earlier amateur designs. In order to allow arbitrary range of interval, he actually uses two TDC chips; one to precisely time the start pulse, and another to time the stop pulse.

Moreover, John's "TICC" exposes the underlying start and stop channel timestamps so that the board not only acts like a simple start=A stop=B TIC, but can also be used as a dual-channel time-stamping counter (TSC). Unlike commercial counters, both the A and B inputs can collect data simultaneously and independently if you want. This avoids certain deadtime, collision and sampling issues that many commercial TIC's have. So it's a very nice design, and low cost, and open source.

/tvb


_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Mark Sims
2017-04-20 18:52:19 UTC
Permalink
That is the TAPR TICC small, low cost, open source, two channel time interval counter. It offers around 60 ps resolution / 100 ps jitter for $200. It's a rather nifty device...

https://www.tapr.org/kits_ticc.html

------------------

> Please forgive my ignorance but what is a TICC?
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hal Murray
2017-04-24 22:54:39 UTC
Permalink
***@n1k.org said:
> You have a “gate” from the GPSDO and a “signal” from somewhere else. If you
> want the STM to do the whole thing, the “gate” pin needs to get the job done
> in X +/- 1 cycles of the “signal” pin. Delay X (if it’s consistent) isn’t
> a problem. Having a
> +/- 1 cycle delay *is* a problem. The interrupt servicing structure in the
> MCU may or may not be able to hit things +/- 10 ns or even +/- 100 ns.
> Sometimes a “lower power” MCU with simple code is better at this than a
> multi core gizmo running a high level operating system.

Some of the counter/timer hardware has another register where the hardware
will save a copy of the main counter when another signal happens. If your
gate time is the time between two pulses rather than the width of a single
pulse, then all the software has to do is read that copy-register before the
next pulse happens.


--
These are my opinions. I hate spam.
Bob kb8tq
2017-04-25 00:16:32 UTC
Permalink
Hi


> On Apr 24, 2017, at 6:54 PM, Hal Murray <***@megapathdsl.net> wrote:
>
>
> ***@n1k.org said:
>> You have a “gate” from the GPSDO and a “signal” from somewhere else. If you
>> want the STM to do the whole thing, the “gate” pin needs to get the job done
>> in X +/- 1 cycles of the “signal” pin. Delay X (if it’s consistent) isn’t
>> a problem. Having a
>> +/- 1 cycle delay *is* a problem. The interrupt servicing structure in the
>> MCU may or may not be able to hit things +/- 10 ns or even +/- 100 ns.
>> Sometimes a “lower power” MCU with simple code is better at this than a
>> multi core gizmo running a high level operating system.
>
> Some of the counter/timer hardware has another register where the hardware
> will save a copy of the main counter when another signal happens. If your
> gate time is the time between two pulses rather than the width of a single
> pulse, then all the software has to do is read that copy-register before the
> next pulse happens.

Works a bit better if the input is edge sensing rather than level sensing ….
(copy on positive edge vs keep copying the whole time the input is high)

Bob


>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-***@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Orin Eman
2017-04-25 05:24:32 UTC
Permalink
On Mon, Apr 24, 2017 at 5:16 PM, Bob kb8tq <***@n1k.org> wrote:

> Hi
>
>
> > On Apr 24, 2017, at 6:54 PM, Hal Murray <***@megapathdsl.net> wrote:
> >
> >
> > ***@n1k.org said:
> >> You have a “gate” from the GPSDO and a “signal” from somewhere else. If
> you
> >> want the STM to do the whole thing, the “gate” pin needs to get the job
> done
> >> in X +/- 1 cycles of the “signal” pin. Delay X (if it’s consistent)
> isn’t
> >> a problem. Having a
> >> +/- 1 cycle delay *is* a problem. The interrupt servicing structure in
> the
> >> MCU may or may not be able to hit things +/- 10 ns or even +/- 100 ns.
> >> Sometimes a “lower power” MCU with simple code is better at this than a
> >> multi core gizmo running a high level operating system.
> >
> > Some of the counter/timer hardware has another register where the
> hardware
> > will save a copy of the main counter when another signal happens. If
> your
> > gate time is the time between two pulses rather than the width of a
> single
> > pulse, then all the software has to do is read that copy-register before
> the
> > next pulse happens.
>
> Works a bit better if the input is edge sensing rather than level sensing
> ….
> (copy on positive edge vs keep copying the whole time the input is high)



They are in my experience. You get the choice of positive edge, negative
edge and if you're lucky, both. I used the capture feature on PIC timers
back in the late 90s to capture automotive engine timing signals and log
engine timing etc., but that's another story.

But the big gotcha is that the external signal is going to be synchronized
to an internal clock, often by a couple of D flip-flops. This introduces a
delay of two to three internal clocks (it can be three if the D flip-flop
setup or hold time is violated and the first flip-flop goes metastable).
It was looking for where/how the synchronization was done on the STM32
timers that led me to the application note (AN4776) that I posted earlier.

FWIW, it's equally entertaining to work out when a write to a pin that's
designated as output actually appears on the pin. Immediately (subject to
propagation delays) never seems to be the answer for the ARM based chips
I've asked about. The answers tend to be of the form mumble mumble
pipelining mumble mumble...

Orin.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob kb8tq
2017-04-25 11:42:50 UTC
Permalink
Hi

> On Apr 25, 2017, at 1:24 AM, Orin Eman <***@gmail.com> wrote:
>
> On Mon, Apr 24, 2017 at 5:16 PM, Bob kb8tq <***@n1k.org> wrote:
>
>> Hi
>>
>>
>>> On Apr 24, 2017, at 6:54 PM, Hal Murray <***@megapathdsl.net> wrote:
>>>
>>>
>>> ***@n1k.org said:
>>>> You have a “gate” from the GPSDO and a “signal” from somewhere else. If
>> you
>>>> want the STM to do the whole thing, the “gate” pin needs to get the job
>> done
>>>> in X +/- 1 cycles of the “signal” pin. Delay X (if it’s consistent)
>> isn’t
>>>> a problem. Having a
>>>> +/- 1 cycle delay *is* a problem. The interrupt servicing structure in
>> the
>>>> MCU may or may not be able to hit things +/- 10 ns or even +/- 100 ns.
>>>> Sometimes a “lower power” MCU with simple code is better at this than a
>>>> multi core gizmo running a high level operating system.
>>>
>>> Some of the counter/timer hardware has another register where the
>> hardware
>>> will save a copy of the main counter when another signal happens. If
>> your
>>> gate time is the time between two pulses rather than the width of a
>> single
>>> pulse, then all the software has to do is read that copy-register before
>> the
>>> next pulse happens.
>>
>> Works a bit better if the input is edge sensing rather than level sensing
>> ….
>> (copy on positive edge vs keep copying the whole time the input is high)
>
>
>
> They are in my experience. You get the choice of positive edge, negative
> edge and if you're lucky, both. I used the capture feature on PIC timers
> back in the late 90s to capture automotive engine timing signals and log
> engine timing etc., but that's another story.
>
> But the big gotcha is that the external signal is going to be synchronized
> to an internal clock, often by a couple of D flip-flops. This introduces a
> delay of two to three internal clocks (it can be three if the D flip-flop
> setup or hold time is violated and the first flip-flop goes metastable).
> It was looking for where/how the synchronization was done on the STM32
> timers that led me to the application note (AN4776) that I posted earlier.
>
> FWIW, it's equally entertaining to work out when a write to a pin that's
> designated as output actually appears on the pin. Immediately (subject to
> propagation delays) never seems to be the answer for the ARM based chips
> I've asked about. The answers tend to be of the form mumble mumble
> pipelining mumble mumble…


This is also is what gets you into limitations like the input clock to the timer being
no greater than 1/4 the applicable MCU clock. The other key there being that the
clock they use may be the I/O clock at 50 MHz and not the CPU clock at 200
MHz. Indeed the information on this sort of thing may be 900 pages into a
1200 page document ….

I’m not trying to say that I *know* this is the case on the F7’s. It is stuff I’ve run
into on other ARM parts. It’s never easy to dig into. My take away has always
been that for precision / deterministic stuff, go to a FPGA. Something like the
FPGA / ARM combo’s might work. The cost for them always seems a bit
crazy unless you need a *lot* of ARM <-> FPGA I/O horsepower.

Bob


>
> Orin.
> _______________________________________________
> time-nuts mailing list -- time-***@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
jimlux
2017-04-25 12:53:07 UTC
Permalink
On 4/25/17 4:42 AM, Bob kb8tq wrote:
> Hi
>
>> On Apr 25, 2017, at 1:24 AM, Orin Eman <***@gmail.com> wrote:
>>
>> On Mon, Apr 24, 2017 at 5:16 PM, Bob kb8tq <***@n1k.org> wrote:
>>
>>> Hi
>>>
>>>
>>>> On Apr 24, 2017, at 6:54 PM, Hal Murray <***@megapathdsl.net> wrote:
>>>>
>>>>
>>>> ***@n1k.org said:
>>>>> You have a “gate” from the GPSDO and a “signal” from somewhere else. If
>>> you
>>>>> want the STM to do the whole thing, the “gate” pin needs to get the job
>>> done
>>>>> in X +/- 1 cycles of the “signal” pin. Delay X (if it’s consistent)
>>> isn’t
>>>>> a problem. Having a
>>>>> +/- 1 cycle delay *is* a problem. The interrupt servicing structure in
>>> the
>>>>> MCU may or may not be able to hit things +/- 10 ns or even +/- 100 ns.
>>>>> Sometimes a “lower power” MCU with simple code is better at this than a
>>>>> multi core gizmo running a high level operating system.
>>>>
>>>> Some of the counter/timer hardware has another register where the
>>> hardware
>>>> will save a copy of the main counter when another signal happens. If
>>> your
>>>> gate time is the time between two pulses rather than the width of a
>>> single
>>>> pulse, then all the software has to do is read that copy-register before
>>> the
>>>> next pulse happens.
>>>
>>> Works a bit better if the input is edge sensing rather than level sensing
>>> ….
>>> (copy on positive edge vs keep copying the whole time the input is high)
>>
>>
>>
>> They are in my experience. You get the choice of positive edge, negative
>> edge and if you're lucky, both. I used the capture feature on PIC timers
>> back in the late 90s to capture automotive engine timing signals and log
>> engine timing etc., but that's another story.
>>
>> But the big gotcha is that the external signal is going to be synchronized
>> to an internal clock, often by a couple of D flip-flops. This introduces a
>> delay of two to three internal clocks (it can be three if the D flip-flop
>> setup or hold time is violated and the first flip-flop goes metastable).
>> It was looking for where/how the synchronization was done on the STM32
>> timers that led me to the application note (AN4776) that I posted earlier.
>>
>> FWIW, it's equally entertaining to work out when a write to a pin that's
>> designated as output actually appears on the pin. Immediately (subject to
>> propagation delays) never seems to be the answer for the ARM based chips
>> I've asked about. The answers tend to be of the form mumble mumble
>> pipelining mumble mumble…
>
>
> This is also is what gets you into limitations like the input clock to the timer being
> no greater than 1/4 the applicable MCU clock. The other key there being that the
> clock they use may be the I/O clock at 50 MHz and not the CPU clock at 200
> MHz. Indeed the information on this sort of thing may be 900 pages into a
> 1200 page document ….
>
> I’m not trying to say that I *know* this is the case on the F7’s. It is stuff I’ve run
> into on other ARM parts. It’s never easy to dig into. My take away has always
> been that for precision / deterministic stuff, go to a FPGA. Something like the
> FPGA / ARM combo’s might work. The cost for them always seems a bit
> crazy unless you need a *lot* of ARM <-> FPGA I/O horsepower.
>


It might be faster to just try some experiments. You could probably set
up an experiment with a signal generator or oscillator with a bit of an
offset so the zero crossing of the unknown slides across the phase of
the processor clock. Not to say that you'd uncover obscure corner
cases, but it *might* be easier than reading the 1000s of pages and
jumping back and forth in the doc between the description of the
"counter timer core" and the "clock distribution core" and the
"processor instruction timing" and the "input output multiplexer" and
the (well, you get the idea). I find that rummaging on the web for
some example code, getting it working, then modifying it seems to be a
good way - coming up with how to set all those configuration bits in
countless registers from scratch is a chore - some sort of starting
place is a good thing.


_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob kb8tq
2017-04-25 13:28:53 UTC
Permalink
Hi
> On Apr 25, 2017, at 8:53 AM, jimlux <***@earthlink.net> wrote:
>
> On 4/25/17 4:42 AM, Bob kb8tq wrote:
>> Hi
>>
>>> On Apr 25, 2017, at 1:24 AM, Orin Eman <***@gmail.com> wrote:
>>>
>>> On Mon, Apr 24, 2017 at 5:16 PM, Bob kb8tq <***@n1k.org> wrote:
>>>
>>>> Hi
>>>>
>>>>
>>>>> On Apr 24, 2017, at 6:54 PM, Hal Murray <***@megapathdsl.net> wrote:
>>>>>
>>>>>
>>>>> ***@n1k.org said:
>>>>>> You have a “gate” from the GPSDO and a “signal” from somewhere else. If
>>>> you
>>>>>> want the STM to do the whole thing, the “gate” pin needs to get the job
>>>> done
>>>>>> in X +/- 1 cycles of the “signal” pin. Delay X (if it’s consistent)
>>>> isn’t
>>>>>> a problem. Having a
>>>>>> +/- 1 cycle delay *is* a problem. The interrupt servicing structure in
>>>> the
>>>>>> MCU may or may not be able to hit things +/- 10 ns or even +/- 100 ns.
>>>>>> Sometimes a “lower power” MCU with simple code is better at this than a
>>>>>> multi core gizmo running a high level operating system.
>>>>>
>>>>> Some of the counter/timer hardware has another register where the
>>>> hardware
>>>>> will save a copy of the main counter when another signal happens. If
>>>> your
>>>>> gate time is the time between two pulses rather than the width of a
>>>> single
>>>>> pulse, then all the software has to do is read that copy-register before
>>>> the
>>>>> next pulse happens.
>>>>
>>>> Works a bit better if the input is edge sensing rather than level sensing
>>>> ….
>>>> (copy on positive edge vs keep copying the whole time the input is high)
>>>
>>>
>>>
>>> They are in my experience. You get the choice of positive edge, negative
>>> edge and if you're lucky, both. I used the capture feature on PIC timers
>>> back in the late 90s to capture automotive engine timing signals and log
>>> engine timing etc., but that's another story.
>>>
>>> But the big gotcha is that the external signal is going to be synchronized
>>> to an internal clock, often by a couple of D flip-flops. This introduces a
>>> delay of two to three internal clocks (it can be three if the D flip-flop
>>> setup or hold time is violated and the first flip-flop goes metastable).
>>> It was looking for where/how the synchronization was done on the STM32
>>> timers that led me to the application note (AN4776) that I posted earlier.
>>>
>>> FWIW, it's equally entertaining to work out when a write to a pin that's
>>> designated as output actually appears on the pin. Immediately (subject to
>>> propagation delays) never seems to be the answer for the ARM based chips
>>> I've asked about. The answers tend to be of the form mumble mumble
>>> pipelining mumble mumble…
>>
>>
>> This is also is what gets you into limitations like the input clock to the timer being
>> no greater than 1/4 the applicable MCU clock. The other key there being that the
>> clock they use may be the I/O clock at 50 MHz and not the CPU clock at 200
>> MHz. Indeed the information on this sort of thing may be 900 pages into a
>> 1200 page document ….
>>
>> I’m not trying to say that I *know* this is the case on the F7’s. It is stuff I’ve run
>> into on other ARM parts. It’s never easy to dig into. My take away has always
>> been that for precision / deterministic stuff, go to a FPGA. Something like the
>> FPGA / ARM combo’s might work. The cost for them always seems a bit
>> crazy unless you need a *lot* of ARM <-> FPGA I/O horsepower.
>>
>
>
> It might be faster to just try some experiments. You could probably set up an experiment with a signal generator or oscillator with a bit of an offset so the zero crossing of the unknown slides across the phase of the processor clock. Not to say that you'd uncover obscure corner cases, but it *might* be easier than reading the 1000s of pages and jumping back and forth in the doc between the description of the "counter timer core" and the "clock distribution core" and the "processor instruction timing" and the "input output multiplexer" and the (well, you get the idea). I find that rummaging on the web for some example code, getting it working, then modifying it seems to be a good way - coming up with how to set all those configuration bits in countless registers from scratch is a chore - some sort of starting place is a good thing.

Indeed the whole process of rummaging through a massive pile of docs on a cheap little part can be
a major hassle. You often do better running their “configuration wizard” and just trying out the result.
I’ve even run into cases where the wizard knows more about the part than the doc's do. When I go back
with questions, the answer is often “trust the wizard, ignore the doc’s”. That makes you feel really good
about spending a week digging through all that stuff …..

Regardless of how you do it, if the objective is an instrument you trust, there is no easy shortcut way
to get it all done. The corner cases will always pop up and get you down the road. If it’s a learning
experiment to see what happens … go for it.

Bob


>
>
> _______________________________________________
> time-nuts mailing list -- time-***@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Jerry Hancock
2017-04-26 04:29:11 UTC
Permalink
Do typical frequency counters start their gate in phase with the incoming signal? I guess the
answer would be, "It depends." I was just thinking about how I would program the STM32F7
counter I am designing.

btw, Gilbert, a local time-nut, sold me a 5335 today so I will be able to buiild one great one
out of the two I will have.

Jerry
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Magnus Danielson
2017-04-26 07:45:32 UTC
Permalink
Hi,

On 04/26/2017 06:29 AM, Jerry Hancock wrote:
> Do typical frequency counters start their gate in phase with the incoming signal? I guess the
> answer would be, "It depends." I was just thinking about how I would program the STM32F7
> counter I am designing.

No. The start of the gate arms the "start" event where you time-stamp
the start event. The end of the gate arms the "stop" event. Variation
can be that you start counting the gate time and arm it with a start
event. Typically the internal gate time is counted in the coarse clock,
so the time-resolution as given by interpolators always guarantee that
the wished gate-time and actual gate time is never really the same.
Rather, gate time is a guidance value but you then measure the actual
length, and neither start or stop is on the same edge.

> btw, Gilbert, a local time-nut, sold me a 5335 today so I will be able to buiild one great one
> out of the two I will have.

Not a bad first counter. It still does some tricks that none of my other
counters do, and I kind of have a bunch of them by now.

Cheers,
Magnus
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob kb8tq
2017-04-26 10:59:55 UTC
Permalink
Hi

> On Apr 26, 2017, at 12:29 AM, Jerry Hancock <***@hanler.com> wrote:
>
> Do typical frequency counters start their gate in phase with the incoming signal? I guess the
> answer would be, "It depends." I was just thinking about how I would program the STM32F7
> counter I am designing.

Since they don’t start (or stop) the gate in any specific relation to the input signal, the trick is to
make sure you don’t get an extra count when the gate opens or closes. This is right back to the
edge triggered vs level triggered issue. It also gets indirectly into the rechecking process in the
MCU. Some of the “edge trigger” stuff is done in odd ways ….(= got two of the same after rechecking
into a shift register …).

Bob


>
> btw, Gilbert, a local time-nut, sold me a 5335 today so I will be able to buiild one great one
> out of the two I will have.
>
> Jerry
> _______________________________________________
> time-nuts mailing list -- time-***@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Jerry Hancock
2017-04-26 13:06:27 UTC
Permalink
I don’t know what I was thinking when I asked this question as we don’t control the gate timing in a referenced counter.


> On Apr 26, 2017, at 3:59 AM, Bob kb8tq <***@n1k.org> wrote:
>
> Hi
>
>> On Apr 26, 2017, at 12:29 AM, Jerry Hancock <***@hanler.com> wrote:
>>
>> Do typical frequency counters start their gate in phase with the incoming signal? I guess the
>> answer would be, "It depends." I was just thinking about how I would program the STM32F7
>> counter I am designing.
>
> Since they don’t start (or stop) the gate in any specific relation to the input signal, the trick is to
> make sure you don’t get an extra count when the gate opens or closes. This is right back to the
> edge triggered vs level triggered issue. It also gets indirectly into the rechecking process in the
> MCU. Some of the “edge trigger” stuff is done in odd ways ….(= got two of the same after rechecking
> into a shift register …).
>
> Bob
>
>
>>
>> btw, Gilbert, a local time-nut, sold me a 5335 today so I will be able to buiild one great one
>> out of the two I will have.
>>
>> Jerry
>> _______________________________________________
>> time-nuts mailing list -- time-***@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>
> _______________________________________________
> time-nuts mailing list -- time-***@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
David
2017-04-26 13:49:46 UTC
Permalink
High end frequency counters usually go to some effort to prevent
synchronization between the input signal and the gate. Some DSOs do
as well. Synchronization can exasperate certain errors and
asynchronous operation provides better results when many measurements
are averaged.

On Tue, 25 Apr 2017 21:29:11 -0700, you wrote:

>Do typical frequency counters start their gate in phase with the incoming signal? I guess the
>answer would be, "It depends." I was just thinking about how I would program the STM32F7
>counter I am designing.
>
>btw, Gilbert, a local time-nut, sold me a 5335 today so I will be able to buiild one great one
>out of the two I will have.
>
>Jerry
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Jerry Hancock
2017-04-25 18:41:30 UTC
Permalink
So the STM App note An-4776 teaches how to use an external clock and it looks pretty accurate in implementation. I’ve read thru the code and it looks easy to implement. Now I just need to bring another signal in and count it. I’ll be working on some code this afternoon to implement the method.

I also found a 5335 for cheap and ordered it. It was listed on eBay as being in “excellent” condition though both pictures had all the lights lit so I can only assume it is stuck in power on reset or test. I’ll see when it gets here.

As far as measurement techniques, if I use my scope and sync to a known signal using the trigger on my 3336, it looks like I can measure to .001hz pretty reliably. So using the STM application, the 5335 and the scope + 3336, I should be off and running.

I’ll report back in a few days.

Jerry
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob kb8tq
2017-04-25 20:22:24 UTC
Permalink
Hi

Keep in mind the previously stated limitation - Your GPSDO is only just
so accurate. If you *could* read 0.001 Hz on a 100 MHz signal in a second,
the GPSDO would not be anywhere near good enough as a reference. Keeping
track of that sort of stuff is one reason a lot of companies train you very early
in converting everything to PPM / PPB / PPT rather than talking about Hz. It’s
a lot easier to note that 1 ppt is past what a GPSDO will do at 1 second than
listing out all the various fractional Hz / MHz signals that are at the limit.

——

The main weak point on the 5335 is the input circuit. With the attenuator set
to 0 db, you can fry it with a 5V signal. Back when it was new and 5V TTL
was all over the place, it was a major risk. Today it’s less of a risk, but still
worth being aware of. An accidental connection to +12 is also a good way
to nuke it ….With the attenuator set as you normally would for a 5V or 12V
signal there really isn’t much risk.

Bob

> On Apr 25, 2017, at 2:41 PM, Jerry Hancock <***@hanler.com> wrote:
>
> So the STM App note An-4776 teaches how to use an external clock and it looks pretty accurate in implementation. I’ve read thru the code and it looks easy to implement. Now I just need to bring another signal in and count it. I’ll be working on some code this afternoon to implement the method.
>
> I also found a 5335 for cheap and ordered it. It was listed on eBay as being in “excellent” condition though both pictures had all the lights lit so I can only assume it is stuck in power on reset or test. I’ll see when it gets here.
>
> As far as measurement techniques, if I use my scope and sync to a known signal using the trigger on my 3336, it looks like I can measure to .001hz pretty reliably. So using the STM application, the 5335 and the scope + 3336, I should be off and running.
>
> I’ll report back in a few days.
>
> Jerry
> _______________________________________________
> time-nuts mailing list -- time-***@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Mark Sims
2017-04-26 06:31:07 UTC
Permalink
If your frequencies of interest can be divided down to to the 1PPS range, the TAPR TICC makes for an excellent frequency counter. The TADD-2 Mini divider handles 1/2.5/5/10 Mhz or with a PIC chip swap 1/5/10/15 MHz. The TICC has around 100 ps of jitter so you can get 1E-10 resolution at 1 second... the TICC noise floor at 1000 seconds is less than 1E-13.

I used the TICC to adjust my 5065A and FTS-4060 cesium C-fields. Referenced to a 5071A, the results are better than 0.00002 Hz (the spec'd limit of the devices).

Attached is a plot of the FTS-4060 using a 5071A as the reference. Over a 1000 second interval the average frequency is off 0.000002 Hz.

Ignore the yellow debug output in the plot... I'm currently working on how to scale and plot the new MTIE (Maximum Time Interval Error) data that Heather can now calculate.
Bob kb8tq
2017-04-26 11:32:31 UTC
Permalink
Hi


> On Apr 26, 2017, at 2:31 AM, Mark Sims <***@hotmail.com> wrote:
>
> If your frequencies of interest can be divided down to to the 1PPS range, the TAPR TICC makes for an excellent frequency counter. The TADD-2 Mini divider handles 1/2.5/5/10 Mhz or with a PIC chip swap 1/5/10/15 MHz. The TICC has around 100 ps of jitter so you can get 1E-10 resolution at 1 second... the TICC noise floor at 1000 seconds is less than 1E-13.
>
> I used the TICC to adjust my 5065A and FTS-4060 cesium C-fields. Referenced to a 5071A, the results are better than 0.00002 Hz (the spec'd limit of the devices).
>
> Attached is a plot of the FTS-4060 using a 5071A as the reference. Over a 1000 second interval the average frequency is off 0.000002 Hz.

This gets one off into the area of “how do I build a 9/10/11/12 digit a second counter?”. As everybody has guessed by now,
that’s the project I would do rather than a straight counter. TICC, F7, a dirt cheap FPGA card ….

Bob


>
> Ignore the yellow debug output in the plot... I'm currently working on how to scale and plot the new MTIE (Maximum Time Interval Error) data that Heather can now calculate.<ticc.gif>_______________________________________________
> time-nuts mailing list -- time-***@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
al wolfe
2017-04-26 18:52:41 UTC
Permalink
I am surprised that no one has mentioned the idea of heterodyning a
known frequency with the unknown to measure the unknown. I use a
Minicircuits doubly balanced mixer fed on one port from a PTS160
synthesizer that is locked to 10 mhz. from a TrueTime xl-ak GPS locked
receiver. The second port is fed by the unknown though an attenuator.
The third port of the mixer gives me the sum and difference. If the
difference is an audio note then a cheep but frequency locked counter
will read out the difference or measure the period of the beat note
which can be added to the frequency of the synthesizer. A program such
as Lady Heather can also be used to determine the audio frequency to
much less then sub-cycle accuracy. The only fly in the ointment is
figuring out which side of the unknown the synthesizer is set to.

Alternatively, the PTS160 with 0.1 cycle control can be set to nearly
zero beat with the unknown. Then watching either lissajous or dual
trace scope patterns and timing the beat notes one can get the unknown
frequency very close.

Al, retired, mostly
AKA k9si
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Loading...