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 ([email protected])
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 <[email protected]>
To: [email protected]
Subject: [time-nuts] measuring os latency for pps
Message-ID: <[email protected]>
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" <[email protected]>
To: <[email protected]>
Subject: [time-nuts] 3 corner hat for phase noise
Message-ID: <DBE9DA002F984B4098FDFEB5AB8DDD5F@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 <[email protected]>
To: [email protected]
Subject: Re: [time-nuts] SRS PRS10 repair
Message-ID: <[email protected]>
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 <[email protected]> wrote:
Le 22 août 2015 à 03:40, Bob Camp <[email protected]> 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 <[email protected]> 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 <[email protected]>
To: "[email protected]"
<[email protected]>, Discussion of precise time and
frequency measurement <[email protected]>
Subject: Re: [time-nuts] SRS PRS10 repair
Message-ID:
<cac+fx11++qplfdoj9bf+_amu5royjqt9rvhfpvqdharjrg2...@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 <[email protected]>
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 <[email protected]> wrote:
Le 22 août 2015 à 03:40, Bob Camp <[email protected]> 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 <[email protected]> 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 -- [email protected]
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 <[email protected]>
To: Discussion of precise time and frequency measurement
<[email protected]>
Subject: Re: [time-nuts] measuring os latency for pps
Message-ID:
<cakc8z5jnp1nzy3p5lymkulnrz9exs4cj+_09nbssq8o8wqp...@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 <[email protected]> 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 -- [email protected]
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" <[email protected]>
To: "Discussion of precise time and frequency measurement"
<[email protected]>
Subject: Re: [time-nuts] 3 corner hat for phase noise
Message-ID: <2747503EDAA24860875DDC7BD8C87926@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" <[email protected]>
To: <[email protected]>
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: [email protected]
To: [email protected]
Subject: Re: [time-nuts] SRS PRS10 repair
Message-ID: <[email protected]>
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" <[email protected]>
To: "'Discussion of precise time and frequency measurement'"
<[email protected]>
Subject: Re: [time-nuts] 3 corner hat for phase noise
Message-ID: <[email protected]>
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:[email protected]] 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" <[email protected]>
To: <[email protected]>
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" <[email protected]>
To: "'Discussion of precise time and frequency measurement'"
<[email protected]>
Subject: Re: [time-nuts] 3 corner hat for phase noise
Message-ID: <[email protected]>
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 <[email protected]>
To: Discussion of precise time and frequency measurement
<[email protected]>
Subject: Re: [time-nuts] measuring os latency for pps
Message-ID: <[email protected]>
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 <[email protected]> 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 <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [time-nuts] SRS PRS10 repair
Message-ID: <[email protected]>
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
<[email protected]>
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 <[email protected]> wrote:
Le 22 août 2015 à 03:40, Bob Camp <[email protected]> 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 <[email protected]> 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 -- [email protected]
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
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 <[email protected]>
To: Discussion of precise time and frequency measurement
<[email protected]>
Subject: Re: [time-nuts] measuring os latency for pps
Message-ID:
<cakc8z5jxuogxhuo-rahohoh6qcqx5pcofff0rt+fwawjls0...@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 <[email protected]> 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 <[email protected]>
To: Discussion of precise time and frequency measurement
<[email protected]>
Subject: Re: [time-nuts] SRS PRS10 repair
Message-ID: <[email protected]>
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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]>
wrote:
Le 22 août 2015 à 03:40, Bob Camp <[email protected]> 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
<[email protected]> 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 <[email protected]>
To: [email protected], Discussion of precise time and
frequency measurement <[email protected]>
Subject: Re: [time-nuts] measuring os latency for pps
Message-ID:
<cabbxvhtxiyyxwb4l3d97cya7nmopc-bv3ja6jv7koa-7wkn...@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
<[email protected]> 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 <[email protected]> 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 -- [email protected]
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
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 <[email protected]>
To: Discussion of precise time and frequency measurement
<[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [time-nuts] SRS PRS10 repair
Message-ID:
<[email protected]>
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 <[email protected]>
To: Discussion of precise time and frequency measurement
<[email protected]>
Subject: Re: [time-nuts] SRS PRS10 repair
Message-ID:
<cac+fx12-yqlu9ynazqyvwksbdmjjzrhj_-lwv_zzbjmneub...@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 <[email protected]> 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 -- [email protected]
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 <[email protected]>
To: Discussion of precise time and frequency measurement
<[email protected]>
Subject: Re: [time-nuts] measuring os latency for pps
Message-ID:
<capnvnrw1+afcyoi3o2gdd7mvjfc6yw78t77uwr5md0ogpro...@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 <[email protected]>
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
<[email protected]> 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 <[email protected]> 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 -- [email protected]
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
> _______________________________________________
> time-nuts mailing list -- [email protected]
> 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 -- [email protected]
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
[email protected]
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
------------------------------
End of time-nuts Digest, Vol 133, Issue 40
******************************************
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
