[time-nuts] 3 corner hat
Martyn Smith
martyn at ptsyst.com
Wed Aug 26 14:14:30 UTC 2015
Hello,
Thank you for the answers.
I've already posted my formulas that work for phase noise.
But John, I will now try your method with the Timepod and see how they
compare.
I did get the N corner to work with the Timepod, but as you say, that's for
ADEV.
Just a personal note. The Timepod is the worlds best bit of electronics
ever, and if John Miles was English, I would recommend him for a knighthood.
John, hope you're blushing now.
Regards
Martyn
Today's Topics:
1. measuring os latency for pps (folkert)
2. 3 corner hat for phase noise (Martyn Smith)
3. Re: SRS PRS10 repair (Brian Inglis)
4. Re: SRS PRS10 repair (Brian M)
5. Re: measuring os latency for pps (Andrew Symington)
6. Re: 3 corner hat for phase noise (Tom Van Baak)
7. Re: SRS PRS10 repair (ziggy9+time-nuts at pumpkinbrook.com)
8. Re: 3 corner hat for phase noise (John Miles)
9. Re: 3 corner hat for phase noise (John Miles)
10. Re: measuring os latency for pps (Iain Young)
11. Re: SRS PRS10 repair (Magnus Danielson)
12. Re: measuring os latency for pps (Andrew Symington)
13. Re: SRS PRS10 repair (Brian Inglis)
14. Re: measuring os latency for pps (Chris Albertson)
15. Re: SRS PRS10 repair (Hal Murray)
16. Re: SRS PRS10 repair (Brian M)
17. Re: measuring os latency for pps (Anders Wallin)
----------------------------------------------------------------------
Message: 1
Date: Tue, 25 Aug 2015 17:24:36 +0200
From: folkert <folkert at vanheusden.com>
To: time-nuts at febo.com
Subject: [time-nuts] measuring os latency for pps
Message-ID: <20150825152436.GU25041 at belle.intranet.vanheusden.com>
Content-Type: text/plain; charset=us-ascii
Hi,
Not sure if it is interesting for you guys but I wrote a simple program
for e.g. Linux (or any other system with the pps api implemented) that
listens on a pps source waiting for a pulse and then toggles a gpio
pin. That way you can measure the latency introduced by the the kernel
when listening from userspace. Note that there's a little extra latency
due to the gpio-pin handling.
It is on github: https://github.com/flok99/pps2gpio
Folkert van Heusden
--
MultiTail cok yonlu kullanimli bir program, loglari okumak, verilen
kommandolari yerine getirebilen. Filter, renk verme, merge, 'diff-
view', vs. http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
------------------------------
Message: 2
Date: Tue, 25 Aug 2015 17:36:19 +0100
From: "Martyn Smith" <martyn at ptsyst.com>
To: <time-nuts at febo.com>
Subject: [time-nuts] 3 corner hat for phase noise
Message-ID: <DBE9DA002F984B4098FDFEB5AB8DDD5F at MiraLuz>
Content-Type: text/plain; format=flowed; charset="utf-8";
reply-type=original
Hello,
Does anyone have an EXCEL spreadsheet that calculates the individual phase
noise of 3 oscillators when they are compared against each other, e.g A vs
B, A vs C, B vs C.
I.e the 3 corner hat technique.
I do have a Timepod and I thought Timelab could do that, have haven't found
how to do that.
Regards
Martyn
------------------------------
Message: 3
Date: Tue, 25 Aug 2015 10:23:40 -0600
From: Brian Inglis <Brian.Inglis at SystematicSw.ab.ca>
To: time-nuts at febo.com
Subject: Re: [time-nuts] SRS PRS10 repair
Message-ID: <55DC968C.9030809 at SystematicSw.ab.ca>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
You have too many 1s in your startup string compared to the expected
"PRS_10\r".
If the MCU clock is not 10Mhz then the integrated UART rates will be off,
which should produce framing errors, but do UARTs still detect and systems
report these nowadays, or just pass along garbled data?
Otherwise, garbled data is most often a result of inadequate pin contact,
if the connectors are not seated properly, or the pins or sockets are loose
in their shells.
Age and rough treatment can have that effect.
"Internal hardware jumpers allow these pins to be configured as analog
outputs
to monitor the lamp intensity and varactor voltage for complete
compatibility
with the FRS."
Have you checked the jumpers in the manual Configuration Notes:
"Pin 4: TXD/PHOTO The default configuration uses this pin as an output for
RS-232 data.
Many system parameters (including the lamp intensity) may be monitored via
the RS-232
interface. The function of this pin may be changed to an analog monitor for
the lamp
intensity by removing one resistor (R347) and installing a 10 kΩ resistor
for another (R348)
on the microcontroller PCB."
On 2015-08-24 22:40, Brian M wrote:
> I tried through the weekend, double and triple checking wiring and setup.
> I've tried the following methods of getting serial comms working:
> PRS10 -> Arduino Uno (with processor bypassed) -> USB Host
> PRS10 -> Level Shifter -> BBB UART
> PRS10 -> MAX232 -> USB Serial adapter
>
> Shortly after power is applied to the PRS10, I do get a string of
> characters. Believe it should be the model information. Instead I get:
> wy+VPgy
>
> I guess the good news is that this output appears consistent with each
> power cycle of the device. And I'm getting the same results through all
> the
> hookup methods I've tried.
>
> My minicom settings are for software flow control at 9600 8N1 - from what
> the manual states, this should be the right settings. I've tried screen as
> well - and get the same text. I went crazy trying several other rates and
> setting combinations. No luck.
>
> Maybe I've missed something obvious.
>
> I agree that getting comms going to the MCU are going to be an important
> step. How do people address this type of problem? Scope the serial and try
> to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there
> further steps people try after that? If nothing else I think there's some
> interesting stuff to learn here. I also wouldn't mind tearing out the
> electronics, determining if the lamp is good, and attempt to build from
> there. I don't know the datecode for the unit, the PCB is marked with a
> datecode suggesting 2003? I don't have the full case. I'm trying to assess
> what are reasonable next steps. How do I determine if the MCU is healthy?
> If the MCU is fried, how do I determine if I just need to squeeze a new
> MCU
> board in there?
>
> Thanks! I appreciate the input so far!
> - Brian
>
> PS - after looking again at the signal on the scope, it does seem like it
> is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like
> what I saw on the main connector.
>
> On Sat, Aug 22, 2015 at 2:04 PM Mike Cook <michael.cook at sfr.fr> wrote:
>
>>
>>> Le 22 août 2015 à 03:40, Bob Camp <kb8tq at n1k.org> a écrit :
>>>
>>> Hi
>>>
>>> On any microprocessor based gizmo, getting the micro running (again) is
>>> generally priority number one. It sets everything up and gives you the
>> diagnostic
>>> info you need to go further. Garbled serial is better than none at all.
>> It suggests
>>> something short of a total MCU death spiral …
>>>
>>> Bob
>>>
>>>> On Aug 21, 2015, at 7:26 PM, Brian M <brayniac at gmail.com> wrote:
>>>>
>>>> Dear list -
>>>>
>>>> I have come into possession of a for parts prs 10. I'd like to try to
>>>> repair this device. What I've noticed so far. Serial is garbled. (Even
>> at
>>>> varying baud rates).
>>
>> You don’t say how you are connecting to the Rb. The manual states:
>> "RS-232 data is sent to the host on pin 4, received from the host on pin
>> 7. The baud rate is
>> fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No
>> DTR
>> or CTS controls are
>> used; rather, the XON/XOFF protocol has been implemented. The transmit
>> drive level is 0
>> and 5 V, not the +/-12 V normally associated with RS-232. These levels
>> are
>> compatible with
>> most RS-232 line receivers, but does not require their use (a TTL
>> inverter
>> may be used
>> instead), hence simplifies the interface when used inside an instrument
>> at
>> the sacrifice of
>> degraded noise immunity over long lines."
>>
>> So make sure that you adhere to that.
>>
>>
>>>> Lamp isn't lit.
>>
>> What’s the date code. Early versions may be reaching EOL, though 20yrs id
>> quoted.
>>
>>>> Doesn't look great. I'd like to know
>>>> if anybody else has wandered down this path. What are common failure
>> modes?
>>>> Anything match up with what I describe? Voltages to check would be
>> helpful.
>>>> The 10MHz out looked okay on a scope. Haven't gone further yet. I
>> suspect
>>>> the crystal is fine.
>>>>
>>>> Thanks in advance. Happy hacking!
>>>> - Brian
------------------------------
Message: 4
Date: Tue, 25 Aug 2015 10:35:22 -0700
From: Brian M <brayniac at gmail.com>
To: "Brian.Inglis at systematicsw.ab.ca"
<Brian.Inglis at systematicsw.ab.ca>, Discussion of precise time and
frequency measurement <time-nuts at febo.com>
Subject: Re: [time-nuts] SRS PRS10 repair
Message-ID:
<CAC+fX11++qPLfdoJ9BF+_aMU5rOYJqT9RvhfpVQdhArJRg2Cdw at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
The earlier suggestion of a missing inverter seems to be the right thing to
chase this evening. I was able to add an inverter and decode the first few
characters on a scope. I get the expected DC1-CR-P-R-S sequence.
Thanks for the input on this. I'll reply back after I've had more time to
hack at this.
- Brian
On Tuesday, August 25, 2015, Brian Inglis <Brian.Inglis at systematicsw.ab.ca>
wrote:
> Hi,
> You have too many 1s in your startup string compared to the expected
> "PRS_10\r".
> If the MCU clock is not 10Mhz then the integrated UART rates will be off,
> which should produce framing errors, but do UARTs still detect and systems
> report these nowadays, or just pass along garbled data?
> Otherwise, garbled data is most often a result of inadequate pin contact,
> if the connectors are not seated properly, or the pins or sockets are
> loose
> in their shells.
> Age and rough treatment can have that effect.
>
> "Internal hardware jumpers allow these pins to be configured as analog
> outputs
> to monitor the lamp intensity and varactor voltage for complete
> compatibility
> with the FRS."
> Have you checked the jumpers in the manual Configuration Notes:
> "Pin 4: TXD/PHOTO The default configuration uses this pin as an output for
> RS-232 data.
> Many system parameters (including the lamp intensity) may be monitored via
> the RS-232
> interface. The function of this pin may be changed to an analog monitor
> for the lamp
> intensity by removing one resistor (R347) and installing a 10 kΩ resistor
> for another (R348)
> on the microcontroller PCB."
>
> On 2015-08-24 22:40, Brian M wrote:
>
>> I tried through the weekend, double and triple checking wiring and setup.
>> I've tried the following methods of getting serial comms working:
>> PRS10 -> Arduino Uno (with processor bypassed) -> USB Host
>> PRS10 -> Level Shifter -> BBB UART
>> PRS10 -> MAX232 -> USB Serial adapter
>>
>> Shortly after power is applied to the PRS10, I do get a string of
>> characters. Believe it should be the model information. Instead I get:
>> wy+VPgy
>>
>> I guess the good news is that this output appears consistent with each
>> power cycle of the device. And I'm getting the same results through all
>> the
>> hookup methods I've tried.
>>
>> My minicom settings are for software flow control at 9600 8N1 - from what
>> the manual states, this should be the right settings. I've tried screen
>> as
>> well - and get the same text. I went crazy trying several other rates and
>> setting combinations. No luck.
>>
>> Maybe I've missed something obvious.
>>
>> I agree that getting comms going to the MCU are going to be an important
>> step. How do people address this type of problem? Scope the serial and
>> try
>> to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there
>> further steps people try after that? If nothing else I think there's some
>> interesting stuff to learn here. I also wouldn't mind tearing out the
>> electronics, determining if the lamp is good, and attempt to build from
>> there. I don't know the datecode for the unit, the PCB is marked with a
>> datecode suggesting 2003? I don't have the full case. I'm trying to
>> assess
>> what are reasonable next steps. How do I determine if the MCU is healthy?
>> If the MCU is fried, how do I determine if I just need to squeeze a new
>> MCU
>> board in there?
>>
>> Thanks! I appreciate the input so far!
>> - Brian
>>
>> PS - after looking again at the signal on the scope, it does seem like it
>> is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like
>> what I saw on the main connector.
>>
>> On Sat, Aug 22, 2015 at 2:04 PM Mike Cook <michael.cook at sfr.fr> wrote:
>>
>>
>>> Le 22 août 2015 à 03:40, Bob Camp <kb8tq at n1k.org> a écrit :
>>>>
>>>> Hi
>>>>
>>>> On any microprocessor based gizmo, getting the micro running (again) is
>>>> generally priority number one. It sets everything up and gives you the
>>>>
>>> diagnostic
>>>
>>>> info you need to go further. Garbled serial is better than none at all.
>>>>
>>> It suggests
>>>
>>>> something short of a total MCU death spiral …
>>>>
>>>> Bob
>>>>
>>>> On Aug 21, 2015, at 7:26 PM, Brian M <brayniac at gmail.com> wrote:
>>>>>
>>>>> Dear list -
>>>>>
>>>>> I have come into possession of a for parts prs 10. I'd like to try to
>>>>> repair this device. What I've noticed so far. Serial is garbled. (Even
>>>>>
>>>> at
>>>
>>>> varying baud rates).
>>>>>
>>>>
>>> You don’t say how you are connecting to the Rb. The manual states:
>>> "RS-232 data is sent to the host on pin 4, received from the host on pin
>>> 7. The baud rate is
>>> fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No
>>> DTR
>>> or CTS controls are
>>> used; rather, the XON/XOFF protocol has been implemented. The transmit
>>> drive level is 0
>>> and 5 V, not the +/-12 V normally associated with RS-232. These levels
>>> are
>>> compatible with
>>> most RS-232 line receivers, but does not require their use (a TTL
>>> inverter
>>> may be used
>>> instead), hence simplifies the interface when used inside an instrument
>>> at
>>> the sacrifice of
>>> degraded noise immunity over long lines."
>>>
>>> So make sure that you adhere to that.
>>>
>>>
>>> Lamp isn't lit.
>>>>>
>>>>
>>> What’s the date code. Early versions may be reaching EOL, though 20yrs
>>> id
>>> quoted.
>>>
>>> Doesn't look great. I'd like to know
>>>>> if anybody else has wandered down this path. What are common failure
>>>>>
>>>> modes?
>>>
>>>> Anything match up with what I describe? Voltages to check would be
>>>>>
>>>> helpful.
>>>
>>>> The 10MHz out looked okay on a scope. Haven't gone further yet. I
>>>>>
>>>> suspect
>>>
>>>> the crystal is fine.
>>>>>
>>>>> Thanks in advance. Happy hacking!
>>>>> - Brian
>>>>>
>>>> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
------------------------------
Message: 5
Date: Tue, 25 Aug 2015 10:53:26 -0700
From: Andrew Symington <andrew.c.symington at gmail.com>
To: Discussion of precise time and frequency measurement
<time-nuts at febo.com>
Subject: Re: [time-nuts] measuring os latency for pps
Message-ID:
<CAKc8Z5Jnp1nZY3P5LymkULnRZ9EXs4Cj+_09NBssq8o8wqPOKQ at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Folkert
If you have a board with a hardware timer that supports load/match/compare
then you can schedule an external interrupt to be generated at a
predetermined point in the hardware count. Thus, if you know the transform
between your disciplined clock and the hardware counter of the timer that
drives it, then you should be able to do this. I have spent some time
working with the (pretty neat) timers on board a beaglebone black, and I've
written some code to setup input capture and compare on up to 4 timers:
https://bitbucket.org/rose-line/roseline/src/35d551bf29e4bfec80f8ba667b199c8aa333b87f/core/modules/roseline.c?at=master
Cheers
Andrew
On Tue, Aug 25, 2015 at 8:24 AM, folkert <folkert at vanheusden.com> wrote:
> Hi,
>
> Not sure if it is interesting for you guys but I wrote a simple program
> for e.g. Linux (or any other system with the pps api implemented) that
> listens on a pps source waiting for a pulse and then toggles a gpio
> pin. That way you can measure the latency introduced by the the kernel
> when listening from userspace. Note that there's a little extra latency
> due to the gpio-pin handling.
>
> It is on github: https://github.com/flok99/pps2gpio
>
>
> Folkert van Heusden
>
> --
> MultiTail cok yonlu kullanimli bir program, loglari okumak, verilen
> kommandolari yerine getirebilen. Filter, renk verme, merge, 'diff-
> view', vs. http://www.vanheusden.com/multitail/
> ----------------------------------------------------------------------
> Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
------------------------------
Message: 6
Date: Tue, 25 Aug 2015 11:11:04 -0700
From: "Tom Van Baak" <tvb at LeapSecond.com>
To: "Discussion of precise time and frequency measurement"
<time-nuts at febo.com>
Subject: Re: [time-nuts] 3 corner hat for phase noise
Message-ID: <2747503EDAA24860875DDC7BD8C87926 at pc52>
Content-Type: text/plain; charset="utf-8"
This is from 3hat.c -- C code, but you get the idea:
A[i] = sqrt( (0 + SQUARE(AB[i]) - SQUARE(BC[i]) + SQUARE(AC[i])) /
2.0 );
B[i] = sqrt( (0 + SQUARE(AB[i]) + SQUARE(BC[i]) - SQUARE(AC[i])) /
2.0 );
C[i] = sqrt( (0 - SQUARE(AB[i]) + SQUARE(BC[i]) + SQUARE(AC[i])) /
2.0 );
And watch out for negative square roots.
/tvb
----- Original Message -----
From: "Martyn Smith" <martyn at ptsyst.com>
To: <time-nuts at febo.com>
Sent: Tuesday, August 25, 2015 9:36 AM
Subject: [time-nuts] 3 corner hat for phase noise
>
> Hello,
>
> Does anyone have an EXCEL spreadsheet that calculates the individual phase
> noise of 3 oscillators when they are compared against each other, e.g A
> vs
> B, A vs C, B vs C.
>
> I.e the 3 corner hat technique.
>
> I do have a Timepod and I thought Timelab could do that, have haven't
> found
> how to do that.
>
> Regards
>
> Martyn
>
------------------------------
Message: 7
Date: Tue, 25 Aug 2015 16:38:35 -0400
From: ziggy9+time-nuts at pumpkinbrook.com
To: time-nuts at febo.com
Subject: Re: [time-nuts] SRS PRS10 repair
Message-ID: <55DCD24B.5080908 at pumpkinbrook.com>
Content-Type: text/plain; charset=utf-8
FYI, if you have an FTDI USB/Serial dongle you can use the FTDI FT-Prog
utility to reprogram the chip to invert polarity from normal. I did that
with my 'Arduino' USB/TTL cable in order to talk to an Rb osc. No need to
mess around with additional inverters. You can get the utility from the
support area of their website.
Paul
On 08/25/2015 01:35 PM, Brian M wrote:
> The earlier suggestion of a missing inverter seems to be the right thing
> to
> chase this evening. I was able to add an inverter and decode the first few
> characters on a scope. I get the expected DC1-CR-P-R-S sequence.
>
> Thanks for the input on this. I'll reply back after I've had more time to
> hack at this.
>
> - Brian
>
------------------------------
Message: 8
Date: Tue, 25 Aug 2015 14:18:03 -0700
From: "John Miles" <john at miles.io>
To: "'Discussion of precise time and frequency measurement'"
<time-nuts at febo.com>
Subject: Re: [time-nuts] 3 corner hat for phase noise
Message-ID: <007301d0df7b$88f56760$9ae03620$@miles.io>
Content-Type: text/plain; charset="utf-8"
One nice thing about phase noise is that it's computable with complex FFTs,
rather than the one-dimensional phase or frequency differences that ADEV
uses. Another nice thing is that it's stationary -- meaning its probability
distribution can (usually) be treated as unchanging from one measurement to
the next. These two properties allow PN measurements to be performed with
vector averaging over time, resulting in a single "correct" value at each
bin. Unlike a stability measurement, the expectation with PN is that
repeated measurements will always yield the same plot.
So you don't need to use statistical hacks like N-corner hats to measure
phase noise with a TimePod or other multichannel instrument. Pull the SMA
jumpers off of the Ch0 and Ch2 jacks and feed two independent references to
them. Over time, the measurement will converge to the phase noise of the
source at the REF IN jack, even if it is quieter than either of the two
sources at the input jacks.
The TimePod/3120A firmware can't compensate for frequency offsets between
Ch0 and Ch2, so the two independent sources need to be very close in
frequency and they need to stay that way over the course of the measurement.
A pair of good-quality rubidium or GPS clocks can be a good way to go.
-- john, KE5FX
Miles Design LLC
> -----Original Message-----
> From: time-nuts [mailto:time-nuts-bounces at febo.com] On Behalf Of Tom Van
> Baak
> Sent: Tuesday, August 25, 2015 11:11 AM
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] 3 corner hat for phase noise
>
> This is from 3hat.c -- C code, but you get the idea:
>
> A[i] = sqrt( (0 + SQUARE(AB[i]) - SQUARE(BC[i]) + SQUARE(AC[i])) /
> 2.0 );
> B[i] = sqrt( (0 + SQUARE(AB[i]) + SQUARE(BC[i]) - SQUARE(AC[i])) /
> 2.0 );
> C[i] = sqrt( (0 - SQUARE(AB[i]) + SQUARE(BC[i]) + SQUARE(AC[i])) /
> 2.0 );
>
> And watch out for negative square roots.
>
> /tvb
>
> ----- Original Message -----
> From: "Martyn Smith" <martyn at ptsyst.com>
> To: <time-nuts at febo.com>
> Sent: Tuesday, August 25, 2015 9:36 AM
> Subject: [time-nuts] 3 corner hat for phase noise
>
>
> >
> > Hello,
> >
> > Does anyone have an EXCEL spreadsheet that calculates the individual
> > phase
> > noise of 3 oscillators when they are compared against each other, e.g
> > A vs
> > B, A vs C, B vs C.
> >
> > I.e the 3 corner hat technique.
> >
> > I do have a Timepod and I thought Timelab could do that, have haven't
> > found
> > how to do that.
> >
> > Regards
> >
> > Martyn
------------------------------
Message: 9
Date: Tue, 25 Aug 2015 14:40:18 -0700
From: "John Miles" <john at miles.io>
To: "'Discussion of precise time and frequency measurement'"
<time-nuts at febo.com>
Subject: Re: [time-nuts] 3 corner hat for phase noise
Message-ID: <007401d0df7e$a5943010$f0bc9030$@miles.io>
Content-Type: text/plain; charset="utf-8"
Actually, after typing all that, it occurred to me that you might have
actually meant to ask about N-cornered stability measurements. They aren't
supported by the current official release of TImeLab; you need to use the
beta version from http://www.miles.io/timelab/beta.htm .
For instructions, hit 'e' to bring up the Trace Properties dialog box and
move your mouse cursor over the 'Source A/Source B' fields. These allow you
to add channel labels to existing .tim files. For TimePod acquisitions,
it's easier to name the sources at acquisition time. Hover over the 'Ch
0/Ch 1/Ch 2' and 'Stability' fields on the Advanced tab of the acquisition
dialog to see how to do that.
Contrary to what the help text says, the TimeLab manual hasn't yet been
updated, so the help text is all there is, as far as documentation goes.
-- john, KE5FX
Miles Design LLC
> One nice thing about phase noise is that it's computable with complex
> FFTs,
> rather than the one-dimensional phase or frequency differences that ADEV
> uses...
------------------------------
Message: 10
Date: Tue, 25 Aug 2015 22:40:04 +0100
From: Iain Young <iain at g7iii.net>
To: Discussion of precise time and frequency measurement
<time-nuts at febo.com>
Subject: Re: [time-nuts] measuring os latency for pps
Message-ID: <55DCE0B4.7050602 at g7iii.net>
Content-Type: text/plain; charset=utf-8; format=flowed
On 25/08/15 18:53, Andrew Symington wrote:
> Hi Folkert
>
> If you have a board with a hardware timer that supports load/match/compare
> then you can schedule an external interrupt to be generated at a
> predetermined point in the hardware count. Thus, if you know the transform
> between your disciplined clock and the hardware counter of the timer that
> drives it, then you should be able to do this. I have spent some time
> working with the (pretty neat) timers on board a beaglebone black, and
> I've
> written some code to setup input capture and compare on up to 4 timers:
> https://bitbucket.org/rose-line/roseline/src/35d551bf29e4bfec80f8ba667b199c8aa333b87f/core/modules/roseline.c?at=master
Wait...You mean with your driver I essentially have a A->B->C->D TIC ?
_THAT_ I have a use or three for...
Since there is also code out there to drive a BBB from an external
reference via TCLKIN, this gets very interesting.
I might just have to compare your code against my own TIC code using
the PRUSS (Although that's only a traditional A-B or A-A TIC at the
moment, extending to 3 or 4 inputs would decrease the precision and
accuracy...)
> On Tue, Aug 25, 2015 at 8:24 AM, folkert <folkert at vanheusden.com> wrote:
>
>> Hi,
>>
>> Not sure if it is interesting for you guys but I wrote a simple program
>> for e.g. Linux (or any other system with the pps api implemented) that
>> listens on a pps source waiting for a pulse and then toggles a gpio
>> pin. That way you can measure the latency introduced by the the kernel
>> when listening from userspace. Note that there's a little extra latency
>> due to the gpio-pin handling.
Oh this might be very interesting, esp with something like the BBB,
which has the excellent counters that Andrew discusses above. Presumably
it is a five minute job to modify your code to do something other than
twiddle a GPIO pin.
It would be very useful to try and characterise that kernel delay. I
will add it to the list of things to try, once I finish moving the time
lab around!
Iain
------------------------------
Message: 11
Date: Tue, 25 Aug 2015 23:59:22 +0200
From: Magnus Danielson <magnus at rubidium.dyndns.org>
To: time-nuts at febo.com
Cc: magnus at rubidium.se
Subject: Re: [time-nuts] SRS PRS10 repair
Message-ID: <55DCE53A.9060101 at rubidium.dyndns.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hang on a minute, polarity does not switch all of a sudden.
However, a short or a glitch could cause the signal to be garbled such
that we incorrectly interpret it as inverted. It can also be the result
of the signal 0 to 5V being triggered on the 0V line on the wrong transient.
It might be that you have a perfectly good signal, but your RS232 can't
interpret it correctly.
So, check the signal, if it has nice digital shape, check if it is only
a matter of RS232 level error. You might need to convert it using a
level shifter. The RS232 trick being used may not be tolerated by all
RS232 inputs.
Cheers,
Magnus
On 08/25/2015 07:35 PM, Brian M wrote:
> The earlier suggestion of a missing inverter seems to be the right thing
> to
> chase this evening. I was able to add an inverter and decode the first few
> characters on a scope. I get the expected DC1-CR-P-R-S sequence.
>
> Thanks for the input on this. I'll reply back after I've had more time to
> hack at this.
>
> - Brian
>
> On Tuesday, August 25, 2015, Brian Inglis
> <Brian.Inglis at systematicsw.ab.ca>
> wrote:
>
>> Hi,
>> You have too many 1s in your startup string compared to the expected
>> "PRS_10\r".
>> If the MCU clock is not 10Mhz then the integrated UART rates will be off,
>> which should produce framing errors, but do UARTs still detect and
>> systems
>> report these nowadays, or just pass along garbled data?
>> Otherwise, garbled data is most often a result of inadequate pin contact,
>> if the connectors are not seated properly, or the pins or sockets are
>> loose
>> in their shells.
>> Age and rough treatment can have that effect.
>>
>> "Internal hardware jumpers allow these pins to be configured as analog
>> outputs
>> to monitor the lamp intensity and varactor voltage for complete
>> compatibility
>> with the FRS."
>> Have you checked the jumpers in the manual Configuration Notes:
>> "Pin 4: TXD/PHOTO The default configuration uses this pin as an output
>> for
>> RS-232 data.
>> Many system parameters (including the lamp intensity) may be monitored
>> via
>> the RS-232
>> interface. The function of this pin may be changed to an analog monitor
>> for the lamp
>> intensity by removing one resistor (R347) and installing a 10 kΩ resistor
>> for another (R348)
>> on the microcontroller PCB."
>>
>> On 2015-08-24 22:40, Brian M wrote:
>>
>>> I tried through the weekend, double and triple checking wiring and
>>> setup.
>>> I've tried the following methods of getting serial comms working:
>>> PRS10 -> Arduino Uno (with processor bypassed) -> USB Host
>>> PRS10 -> Level Shifter -> BBB UART
>>> PRS10 -> MAX232 -> USB Serial adapter
>>>
>>> Shortly after power is applied to the PRS10, I do get a string of
>>> characters. Believe it should be the model information. Instead I get:
>>> wy+VPgy
>>>
>>> I guess the good news is that this output appears consistent with each
>>> power cycle of the device. And I'm getting the same results through all
>>> the
>>> hookup methods I've tried.
>>>
>>> My minicom settings are for software flow control at 9600 8N1 - from
>>> what
>>> the manual states, this should be the right settings. I've tried screen
>>> as
>>> well - and get the same text. I went crazy trying several other rates
>>> and
>>> setting combinations. No luck.
>>>
>>> Maybe I've missed something obvious.
>>>
>>> I agree that getting comms going to the MCU are going to be an important
>>> step. How do people address this type of problem? Scope the serial and
>>> try
>>> to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there
>>> further steps people try after that? If nothing else I think there's
>>> some
>>> interesting stuff to learn here. I also wouldn't mind tearing out the
>>> electronics, determining if the lamp is good, and attempt to build from
>>> there. I don't know the datecode for the unit, the PCB is marked with a
>>> datecode suggesting 2003? I don't have the full case. I'm trying to
>>> assess
>>> what are reasonable next steps. How do I determine if the MCU is
>>> healthy?
>>> If the MCU is fried, how do I determine if I just need to squeeze a new
>>> MCU
>>> board in there?
>>>
>>> Thanks! I appreciate the input so far!
>>> - Brian
>>>
>>> PS - after looking again at the signal on the scope, it does seem like
>>> it
>>> is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like
>>> what I saw on the main connector.
>>>
>>> On Sat, Aug 22, 2015 at 2:04 PM Mike Cook <michael.cook at sfr.fr> wrote:
>>>
>>>
>>>> Le 22 août 2015 à 03:40, Bob Camp <kb8tq at n1k.org> a écrit :
>>>>>
>>>>> Hi
>>>>>
>>>>> On any microprocessor based gizmo, getting the micro running (again)
>>>>> is
>>>>> generally priority number one. It sets everything up and gives you the
>>>>>
>>>> diagnostic
>>>>
>>>>> info you need to go further. Garbled serial is better than none at
>>>>> all.
>>>>>
>>>> It suggests
>>>>
>>>>> something short of a total MCU death spiral …
>>>>>
>>>>> Bob
>>>>>
>>>>> On Aug 21, 2015, at 7:26 PM, Brian M <brayniac at gmail.com> wrote:
>>>>>>
>>>>>> Dear list -
>>>>>>
>>>>>> I have come into possession of a for parts prs 10. I'd like to try to
>>>>>> repair this device. What I've noticed so far. Serial is garbled.
>>>>>> (Even
>>>>>>
>>>>> at
>>>>
>>>>> varying baud rates).
>>>>>>
>>>>>
>>>> You don’t say how you are connecting to the Rb. The manual states:
>>>> "RS-232 data is sent to the host on pin 4, received from the host on
>>>> pin
>>>> 7. The baud rate is
>>>> fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No
>>>> DTR
>>>> or CTS controls are
>>>> used; rather, the XON/XOFF protocol has been implemented. The transmit
>>>> drive level is 0
>>>> and 5 V, not the +/-12 V normally associated with RS-232. These levels
>>>> are
>>>> compatible with
>>>> most RS-232 line receivers, but does not require their use (a TTL
>>>> inverter
>>>> may be used
>>>> instead), hence simplifies the interface when used inside an instrument
>>>> at
>>>> the sacrifice of
>>>> degraded noise immunity over long lines."
>>>>
>>>> So make sure that you adhere to that.
>>>>
>>>>
>>>> Lamp isn't lit.
>>>>>>
>>>>>
>>>> What’s the date code. Early versions may be reaching EOL, though 20yrs
>>>> id
>>>> quoted.
>>>>
>>>> Doesn't look great. I'd like to know
>>>>>> if anybody else has wandered down this path. What are common failure
>>>>>>
>>>>> modes?
>>>>
>>>>> Anything match up with what I describe? Voltages to check would be
>>>>>>
>>>>> helpful.
>>>>
>>>>> The 10MHz out looked okay on a scope. Haven't gone further yet. I
>>>>>>
>>>>> suspect
>>>>
>>>>> the crystal is fine.
>>>>>>
>>>>>> Thanks in advance. Happy hacking!
>>>>>> - Brian
>>>>>>
>>>>> _______________________________________________
>> time-nuts mailing list -- time-nuts at 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-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
------------------------------
Message: 12
Date: Tue, 25 Aug 2015 16:01:54 -0700
From: Andrew Symington <andrew.c.symington at gmail.com>
To: Discussion of precise time and frequency measurement
<time-nuts at febo.com>
Subject: Re: [time-nuts] measuring os latency for pps
Message-ID:
<CAKc8Z5JxUogXHuo-raHohoh6Qcqx5pCOFFF0Rt+fwaWJLs062g at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
>
> Hi Iain
>
>
>> If you have a board with a hardware timer that supports
>> load/match/compare
>> then you can schedule an external interrupt to be generated at a
>> predetermined point in the hardware count. Thus, if you know the
>> transform
>> between your disciplined clock and the hardware counter of the timer that
>> drives it, then you should be able to do this. I have spent some time
>> working with the (pretty neat) timers on board a beaglebone black, and
>> I've
>> written some code to setup input capture and compare on up to 4 timers:
>>
>> https://bitbucket.org/rose-line/roseline/src/35d551bf29e4bfec80f8ba667b199c8aa333b87f/core/modules/roseline.c?at=master
>>
>
> Wait...You mean with your driver I essentially have a A->B->C->D TIC ?
> _THAT_ I have a use or three for...
>
>
The one catch is that you can only setup a BeagleBone Black timer to be in
capture mode OR compare mode, not both. So, what I did was to set up two
parallel timers that are driven by the same oscillator (and thus I don't
drift relative to each other). I then perform synchronization against the
first free-running timer. I then bootstrap the second timer with the count
of the first one, which appears to have a fairly deterministic latency of
13 ticks. I can then setup a load/match to cause a rising edge at a very
deterministic point in time. I have sort have named this an IOTIMER.
> Since there is also code out there to drive a BBB from an external
> reference via TCLKIN, this gets very interesting.
>
Yes, I have a patch set for the 4.1.3x kernel, which sets up tclkin
(although I haven't tested it since the 3.x kernel branch).
https://bitbucket.org/rose-line/roseline/src/35d551bf29e4bfec80f8ba667b199c8aa333b87f/core/4.1.3-rt-roseline/patchset/?at=master
My kernel module is loaded by the device tree as follows. In the snippet
below I setup two IOTIMERS, the first of which (iotimer_a) performs compare
on timer4 and event generation on timer5. The argument "1" says use the
24MHz oscillator to drive both timers -- "0" is for TCLKIN and "2" is for
the 32kHz oscillator. The last parameter describes which edge to capture --
"0" is for rising, "1" is for falling, "2" is for both and "3" is for none.
/ {
roseline {
compatible = "roseline";
status = "okay";
iotimer_a = <&timer4 &timer5 1 0>;
iotimer_b = <&timer6 &timer7 1 0>;
pinctrl-names = "default";
pinctrl-0 = <&timer_pins>;
};
};
Obviously, you'll also need to do the pinmuxes (TLKCIN causes you to lose
HDMI).
/* Timer configuration */
timer_pins: pinmux_timer_pins {
pinctrl-single,pins = <
0x90 0x22 /* P8.7 MODE2 TIMER4 - 24MHz CAPTURE */
0x98 0x02 /* P8.10 MODE2 TIMER5 - 24MHz INTERRUPT */
0x9C 0x22 /* P8.9 MODE2 TIMER6 - TCLKIN CAPTURE */
0x94 0x02 /* P8.8 MODE2 TIMER7 - TCLKIN INTERRUPT */
0x1b4 0x2A /* P9.41A MODE2 TIMER4 TCLKIN */
0x1a8 0x0F /* P9.41B MODE7 TIMER4 INPUT (high-Z, tied to P9.41A) -
conflicts with HDMI */
>;
};
Once the kernel module is loaded, you can communicate with it from
userspace using ioctl. Simple example:
https://bitbucket.org/rose-line/roseline/src/35d551bf29e4bfec80f8ba667b199c8aa333b87f/applications/misc/test_ioctl.c?at=master
I still have to implement polling to notify the userspace of capture
events. Right now you have to keep checking until the sequence number
changes.
> I might just have to compare your code against my own TIC code using
> the PRUSS (Although that's only a traditional A-B or A-A TIC at the
> moment, extending to 3 or 4 inputs would decrease the precision and
> accuracy...)
Please do! And let me know how it performs :) And if you have released your
PRUSS code, please send me a link!
>
>
> On Tue, Aug 25, 2015 at 8:24 AM, folkert <folkert at vanheusden.com> wrote:
>>
>> Hi,
>>>
>>> Not sure if it is interesting for you guys but I wrote a simple program
>>> for e.g. Linux (or any other system with the pps api implemented) that
>>> listens on a pps source waiting for a pulse and then toggles a gpio
>>> pin. That way you can measure the latency introduced by the the kernel
>>> when listening from userspace. Note that there's a little extra latency
>>> due to the gpio-pin handling.
>>>
>>
> Oh this might be very interesting, esp with something like the BBB,
> which has the excellent counters that Andrew discusses above. Presumably
> it is a five minute job to modify your code to do something other than
> twiddle a GPIO pin.
>
> It would be very useful to try and characterise that kernel delay. I
> will add it to the list of things to try, once I finish moving the time
> lab around!
Great -- keep us in the loop!
Cheers
Andrew
------------------------------
Message: 13
Date: Tue, 25 Aug 2015 18:02:42 -0600
From: Brian Inglis <Brian.Inglis at SystematicSw.ab.ca>
To: Discussion of precise time and frequency measurement
<time-nuts at febo.com>
Subject: Re: [time-nuts] SRS PRS10 repair
Message-ID: <55DD0222.9040903 at SystematicSw.ab.ca>
Content-Type: text/plain; charset=utf-8; format=flowed
Looking at the data expected and received on the wire, there could be an
extra inversion after some bits delay until an inverted 1 is detected as a
start bit:
00001101 00110000 00110001 01011111 01010011 01010010 01010000 .01_SRP -
what you should see on your scope
01111001 01100111 01010000 01010110 00101011 01111001 01110111 ygPV+yw -
what you probably see on your scope
You should be able to connect your output data directly into any
current PC serial port as they should both work with 0-5V nowadays.
On 2015-08-25 11:35, Brian M wrote:
> The earlier suggestion of a missing inverter seems to be the right thing
> to chase this evening. I was able to add an inverter and decode the first
> few characters on a scope. I get the expected DC1-CR-P-R-S sequence.
>
> Thanks for the input on this. I'll reply back after I've had more time to
> hack at this.
> On Tuesday, August 25, 2015, Brian Inglis <Brian.Inglis at systematicsw.ab.ca
> <mailto:Brian.Inglis at systematicsw.ab.ca>> wrote:
> You have too many 1s in your startup string compared to the expected
> "PRS_10\r".
> If the MCU clock is not 10Mhz then the integrated UART rates will be
> off,
> which should produce framing errors, but do UARTs still detect and
> systems
> report these nowadays, or just pass along garbled data?
> Otherwise, garbled data is most often a result of inadequate pin
> contact,
> if the connectors are not seated properly, or the pins or sockets are
> loose
> in their shells.
> Age and rough treatment can have that effect.
>
> "Internal hardware jumpers allow these pins to be configured as analog
> outputs
> to monitor the lamp intensity and varactor voltage for complete
> compatibility
> with the FRS."
> Have you checked the jumpers in the manual Configuration Notes:
> "Pin 4: TXD/PHOTO The default configuration uses this pin as an output
> for RS-232 data.
> Many system parameters (including the lamp intensity) may be monitored
> via the RS-232
> interface. The function of this pin may be changed to an analog
> monitor for the lamp
> intensity by removing one resistor (R347) and installing a 10 kΩ
> resistor for another (R348)
> on the microcontroller PCB."
> On 2015-08-24 22:40, Brian M wrote:
> I tried through the weekend, double and triple checking wiring and
> setup.
> I've tried the following methods of getting serial comms working:
> PRS10 -> Arduino Uno (with processor bypassed) -> USB Host
> PRS10 -> Level Shifter -> BBB UART
> PRS10 -> MAX232 -> USB Serial adapter
>
> Shortly after power is applied to the PRS10, I do get a string of
> characters. Believe it should be the model information. Instead I
> get:
> wy+VPgy
>
> I guess the good news is that this output appears consistent with
> each
> power cycle of the device. And I'm getting the same results
> through all the
> hookup methods I've tried.
>
> My minicom settings are for software flow control at 9600 8N1 -
> from what
> the manual states, this should be the right settings. I've tried
> screen as
> well - and get the same text. I went crazy trying several other
> rates and
> setting combinations. No luck.
>
> Maybe I've missed something obvious.
>
> I agree that getting comms going to the MCU are going to be an
> important
> step. How do people address this type of problem? Scope the serial
> and try
> to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are
> there
> further steps people try after that? If nothing else I think
> there's some
> interesting stuff to learn here. I also wouldn't mind tearing out
> the
> electronics, determining if the lamp is good, and attempt to build
> from
> there. I don't know the datecode for the unit, the PCB is marked
> with a
> datecode suggesting 2003? I don't have the full case. I'm trying
> to assess
> what are reasonable next steps. How do I determine if the MCU is
> healthy?
> If the MCU is fried, how do I determine if I just need to squeeze
> a new MCU
> board in there?
>
> Thanks! I appreciate the input so far!
> - Brian
>
> PS - after looking again at the signal on the scope, it does seem
> like it
> is 9600 baud. ~100µS per bit. The data out on the MCU itself looks
> like
> what I saw on the main connector.
>
> On Sat, Aug 22, 2015 at 2:04 PM Mike Cook <michael.cook at sfr.fr>
> wrote:
>
>
> Le 22 août 2015 à 03:40, Bob Camp <kb8tq at n1k.org> a écrit
> :
>
> Hi
>
> On any microprocessor based gizmo, getting the micro
> running (again) is
> generally priority number one. It sets everything up and
> gives you the
>
> diagnostic
>
> info you need to go further. Garbled serial is better than
> none at all.
>
> It suggests
>
> something short of a total MCU death spiral …
>
> Bob
>
> On Aug 21, 2015, at 7:26 PM, Brian M
> <brayniac at gmail.com> wrote:
>
> Dear list -
>
> I have come into possession of a for parts prs 10. I'd
> like to try to
> repair this device. What I've noticed so far. Serial
> is garbled. (Even
>
> at
>
> varying baud rates).
>
>
> You don’t say how you are connecting to the Rb. The manual
> states:
> "RS-232 data is sent to the host on pin 4, received from the
> host on pin
> 7. The baud rate is
> fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop
> bit. No DTR
> or CTS controls are
> used; rather, the XON/XOFF protocol has been implemented. The
> transmit
> drive level is 0
> and 5 V, not the +/-12 V normally associated with RS-232.
> These levels are
> compatible with
> most RS-232 line receivers, but does not require their use (a
> TTL inverter
> may be used
> instead), hence simplifies the interface when used inside an
> instrument at
> the sacrifice of
> degraded noise immunity over long lines."
>
> So make sure that you adhere to that.
>
>
> Lamp isn't lit.
>
>
> What’s the date code. Early versions may be reaching EOL,
> though 20yrs id
> quoted.
>
> Doesn't look great. I'd like to know
> if anybody else has wandered down this path. What are
> common failure
>
> modes?
>
> Anything match up with what I describe? Voltages to
> check would be
>
> helpful.
>
> The 10MHz out looked okay on a scope. Haven't gone
> further yet. I
>
> suspect
>
> the crystal is fine.
>
> Thanks in advance. Happy hacking!
------------------------------
Message: 14
Date: Tue, 25 Aug 2015 17:04:21 -0700
From: Chris Albertson <albertson.chris at gmail.com>
To: andrew.c.symington at gmail.com, Discussion of precise time and
frequency measurement <time-nuts at febo.com>
Subject: Re: [time-nuts] measuring os latency for pps
Message-ID:
<CABbxVHtXiYYXWb4L3D97cYa7nmOpC-bv3JA6JV7Koa-7wKn12A at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
What are you measuring? Seriously. What is it you need to know, is it?
1) The time between the raising edge of the PPS and when the OS samples the
time
2) The time it takes between the PPS edge and when a user land process
is notified.
There are other things you can measure but if you want to see #1 above
you can't use a TIC. And you can't have the user space process set s
GPIO bit. The reason is that the PPS interrupt handler dramatically
shortens the time removing ALL of the kernel process or latency.
Look at the interrupt code. The clock is sampled there. The edge
triggers the interrupt then while inside the handler the internal
clock is sampled and stored and a flag is set to indicate the PPS was
received. Som tie MUCH later the flag is checked and the user-land
process is told the PPS has detected The delay does not matter
because the clock was sampled with very low latency even if the user
process was not notified right away.
I think the details are platform dependent, hardware on a PC is not
the same as a Raspberry Pi. So you need to look at the source.
On Tue, Aug 25, 2015 at 10:53 AM, Andrew Symington
<andrew.c.symington at gmail.com> wrote:
> Hi Folkert
>
> If you have a board with a hardware timer that supports load/match/compare
> then you can schedule an external interrupt to be generated at a
> predetermined point in the hardware count. Thus, if you know the transform
> between your disciplined clock and the hardware counter of the timer that
> drives it, then you should be able to do this. I have spent some time
> working with the (pretty neat) timers on board a beaglebone black, and
> I've
> written some code to setup input capture and compare on up to 4 timers:
> https://bitbucket.org/rose-line/roseline/src/35d551bf29e4bfec80f8ba667b199c8aa333b87f/core/modules/roseline.c?at=master
>
> Cheers
> Andrew
>
>
> On Tue, Aug 25, 2015 at 8:24 AM, folkert <folkert at vanheusden.com> wrote:
>
>> Hi,
>>
>> Not sure if it is interesting for you guys but I wrote a simple program
>> for e.g. Linux (or any other system with the pps api implemented) that
>> listens on a pps source waiting for a pulse and then toggles a gpio
>> pin. That way you can measure the latency introduced by the the kernel
>> when listening from userspace. Note that there's a little extra latency
>> due to the gpio-pin handling.
>>
>> It is on github: https://github.com/flok99/pps2gpio
>>
>>
>> Folkert van Heusden
>>
>> --
>> MultiTail cok yonlu kullanimli bir program, loglari okumak, verilen
>> kommandolari yerine getirebilen. Filter, renk verme, merge, 'diff-
>> view', vs. http://www.vanheusden.com/multitail/
>> ----------------------------------------------------------------------
>> Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at 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-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
------------------------------
Message: 15
Date: Tue, 25 Aug 2015 17:36:26 -0700
From: Hal Murray <hmurray at megapathdsl.net>
To: Discussion of precise time and frequency measurement
<time-nuts at febo.com>
Cc: hmurray at megapathdsl.net, magnus at rubidium.se
Subject: Re: [time-nuts] SRS PRS10 repair
Message-ID:
<20150826003626.9862D40605C at ip-64-139-1-69.sjc.megapath.net>
Content-Type: text/plain; charset=us-ascii
> Hang on a minute, polarity does not switch all of a sudden.
The standard RS-232 interface chips include an inverter. The normal output
from serial pins on microprocessors or PCI/USB serial chips expects that
inversion.
For short runs where you are designing both ends, it's common to skip the
RS-232 drivers.
So if you are trying to talk to something like a GPSDO board without the
typical 9 pin serial connector, there is a reasonable chance you may need to
add an inverter. (or maybe a real RS-232 interface chip)
--------
It's also possible to cheat on the RS-232 interface ship. A TTL/CMOS driver
will work with most RS-232 receivers and a resistor with maybe a pair of
diodes will protect a CMOS receiver from RS-232 levels. If you are doing
that, you need an inverter in there someplace. With a microprocessor, the
inverter is often available (for free) in the pad driver.
--
These are my opinions. I hate spam.
------------------------------
Message: 16
Date: Wed, 26 Aug 2015 04:28:34 +0000
From: Brian M <brayniac at gmail.com>
To: Discussion of precise time and frequency measurement
<time-nuts at febo.com>
Subject: Re: [time-nuts] SRS PRS10 repair
Message-ID:
<CAC+fX12-yqLU9YnaZQyVwksBDMJJzrhj_-LWV_zZBjmNEUB9vA at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi -
So I took the time tonight to poke at things with the scope. Hopefully it
will be of interest.
First off, I probed the MCU (MC68HC11) TX line directly. And, it looks like
I misstated in my last mail. The MCU itself is 5V TX idle TTL Serial. On
the unit's output, it is inverted and 0V idle. Not sure why that's the
case...
That said, I have lashed up some simple NPN inverters which are also
level-shifting to a BBB UART. And with that I've got serial comms
established. I get the power-on message and response from "ID ?" is "
PRS10_3.24_SN_[....]"
Thanks again to all for their input. Always more to learn =)
- Brian
On Tue, Aug 25, 2015 at 7:50 PM Hal Murray <hmurray at megapathdsl.net> wrote:
> > Hang on a minute, polarity does not switch all of a sudden.
>
> The standard RS-232 interface chips include an inverter. The normal
> output
> from serial pins on microprocessors or PCI/USB serial chips expects that
> inversion.
>
> For short runs where you are designing both ends, it's common to skip the
> RS-232 drivers.
>
> So if you are trying to talk to something like a GPSDO board without the
> typical 9 pin serial connector, there is a reasonable chance you may need
> to
> add an inverter. (or maybe a real RS-232 interface chip)
>
> --------
>
> It's also possible to cheat on the RS-232 interface ship. A TTL/CMOS
> driver
> will work with most RS-232 receivers and a resistor with maybe a pair of
> diodes will protect a CMOS receiver from RS-232 levels. If you are doing
> that, you need an inverter in there someplace. With a microprocessor, the
> inverter is often available (for free) in the pad driver.
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
------------------------------
Message: 17
Date: Wed, 26 Aug 2015 10:42:10 +0300
From: Anders Wallin <anders.e.e.wallin at gmail.com>
To: Discussion of precise time and frequency measurement
<time-nuts at febo.com>
Subject: Re: [time-nuts] measuring os latency for pps
Message-ID:
<CAPnVNRW1+AfcyOi3o2GDD7mVjFC6Yw78t77UWR5md0oGPrO+Zg at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Back in 2012 while playing with LinuxCNC, a program for real-time control
of CNC machines, I made a few graphs on the real-time vs. normal kernel
performance:
http://www.anderswallin.net/?s=latency
These are purely software generated and measured events (i.e. we set a
thread to run at 1 ms intervals and in software measure when it actually
runs).
It would be interesting to hear what (if any?) real-time kernels are used
on NTP servers and if that is one way to measure/generate 1PPS input/output.
Anders
On Wed, Aug 26, 2015 at 3:04 AM, Chris Albertson <albertson.chris at gmail.com>
wrote:
> What are you measuring? Seriously. What is it you need to know, is it?
>
> 1) The time between the raising edge of the PPS and when the OS samples
> the time
>
> 2) The time it takes between the PPS edge and when a user land process
> is notified.
>
> There are other things you can measure but if you want to see #1 above
> you can't use a TIC. And you can't have the user space process set s
> GPIO bit. The reason is that the PPS interrupt handler dramatically
> shortens the time removing ALL of the kernel process or latency.
> Look at the interrupt code. The clock is sampled there. The edge
> triggers the interrupt then while inside the handler the internal
> clock is sampled and stored and a flag is set to indicate the PPS was
> received. Som tie MUCH later the flag is checked and the user-land
> process is told the PPS has detected The delay does not matter
> because the clock was sampled with very low latency even if the user
> process was not notified right away.
>
> I think the details are platform dependent, hardware on a PC is not
> the same as a Raspberry Pi. So you need to look at the source.
>
> On Tue, Aug 25, 2015 at 10:53 AM, Andrew Symington
> <andrew.c.symington at gmail.com> wrote:
> > Hi Folkert
> >
> > If you have a board with a hardware timer that supports
> load/match/compare
> > then you can schedule an external interrupt to be generated at a
> > predetermined point in the hardware count. Thus, if you know the
> transform
> > between your disciplined clock and the hardware counter of the timer
> > that
> > drives it, then you should be able to do this. I have spent some time
> > working with the (pretty neat) timers on board a beaglebone black, and
> I've
> > written some code to setup input capture and compare on up to 4 timers:
> >
> https://bitbucket.org/rose-line/roseline/src/35d551bf29e4bfec80f8ba667b199c8aa333b87f/core/modules/roseline.c?at=master
> >
> > Cheers
> > Andrew
> >
> >
> > On Tue, Aug 25, 2015 at 8:24 AM, folkert <folkert at vanheusden.com> wrote:
> >
> >> Hi,
> >>
> >> Not sure if it is interesting for you guys but I wrote a simple program
> >> for e.g. Linux (or any other system with the pps api implemented) that
> >> listens on a pps source waiting for a pulse and then toggles a gpio
> >> pin. That way you can measure the latency introduced by the the kernel
> >> when listening from userspace. Note that there's a little extra latency
> >> due to the gpio-pin handling.
> >>
> >> It is on github: https://github.com/flok99/pps2gpio
> >>
> >>
> >> Folkert van Heusden
> >>
> >> --
> >> MultiTail cok yonlu kullanimli bir program, loglari okumak, verilen
> >> kommandolari yerine getirebilen. Filter, renk verme, merge, 'diff-
> >> view', vs. http://www.vanheusden.com/multitail/
> >> ----------------------------------------------------------------------
> >> Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
> >> _______________________________________________
> >> time-nuts mailing list -- time-nuts at 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-nuts at febo.com
> > To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> > and follow the instructions there.
>
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
------------------------------
Subject: Digest Footer
_______________________________________________
time-nuts mailing list
time-nuts at febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
------------------------------
End of time-nuts Digest, Vol 133, Issue 40
******************************************
More information about the Time-nuts_lists.febo.com
mailing list