On 06/19/22 11:09, David Woolley wrote:
> On 19/06/2022 01:06, chris wrote:
>> In practice, that will be small, since the
>> data sheet figures for a typical max232 assume a 2.5nf capacitive
>> load on the output, whereas a few inches of wire into a rs232 line
>> receiver setup might be much faster.
>
> As we are talking about compliant RS232, which is the only real world
> reason for not just connecting TTL directly to the RS232 port, the the
> 2.5nF condition is the maximum capacitance that can appear across the
> driver output as the result of what it is driving. That sets a minimum
> possible slew rate.
>
> However a compliant RS232 system also has a maximum permitted slew rate,
> intended to minimise cross talk, and probably also to ensure that long
> cables don't ring, as the initial transient reflects backwards and
> forwards. 30V/µs is the maximum permitted slew rate for a compliant
> system. If your system exceeds that, even if it is using RS232 drivers,
> it is not a compliant system.
>

Yes, it does have a spec for the slew rate, but i'm not sure that would
always be met for modern devices, as such uarts can often be run at data
rates of up to 230 Kbytes / second, or about a 4uS bit time. That
implies much faster rise and fall times, which relates to slew rate.

We can theorise about that, but iirc, I bought two ttl to rs232
converters at the time. If I can find the second one, i'll set it up
on the bench and measure the propagation delay on a scope from input to
output. Also, see what effect the 2.5nF cap has on the waveform and
timing...

Chris

On 06/19/22 01:51, Jim Pennino wrote:
> chris<chris-nospam@tridac.net> wrote:
>> On 06/18/22 04:45, Phillip Hellewell wrote:
>>> Does anyone have answers to the specific issues I found, like why the github repo
>>
>> isn't being synced, or why I can't log into bugs.ntp.org, or why emails
>> to webmaster@ntp.org bounce?
>>
>> Sorry, no idea at all, but does seem to be a common thread running
>> through, the lack of community in terms of future direction and
>> progress.
>>
>> The build here is earlier than I remembered, from the end of 2019, but
>> one of the reasons I sort of gave up, was the difficulty in sorting out
>> the pps input options. PPS handling at hardware interface level is a
>> critical function if the most accurate results are to be obtained.
>> At present there is just a single hardware option for that, the
>> rs232 data carrier detect (dcd) line, which as David has said, is
>> less than ideal because of the need for level translation, which
>> introduces a delay. In practice, that will be small, since the
>> data sheet figures for a typical max232 assume a 2.5nf capacitive
>> load on the output, whereas a few inches of wire into a rs232 line
>> receiver setup might be much faster. Having no other options for pps
>> is serious limitation though. The key thing is that whatever interface
>> is used, it must be capable of generating an interrupt to system,
>> to minimise offset. Both the dcd and the parallel port ack line
>> satisfy that requirement, though modern pc hardware often has neither
>> interface.
>>
>> Do hw and sw here, but the limitations of the present system only
>> become evident when looking in depth at all aspects. Just wish there
>> could be some sort of plan to fix the various issues.
>>
>> Chris
>
> A delay in a hardware level translator will be a fixed amount easily
> fudged out and with jitter far less than that of the computer reading
> and processing the interrupt.

Agreed and that is the best option. Polling methods will always suffer
from more jitter. There will be timing uncertainty around the polling
rate, of which there is a minimum practical limit. Direct interrupt
methods are really the only way to go for best precision.

>
> An industrial strength serial/parallel card costs about $40 these days.
>
> You need more that just an interrupt to handle PPS, you need a high
> priority interrupt.
>

Using FreeBSD here and that needed a kernel rebuild to enable PPS
support. Also enabled kernel thread preemption, which should help
make the os more deterministic. Unless you write your own os
optimised for the task, there's not much else you can do afaics...

Chris

Hi Phillip,

Please let me know if you see this.

I'll dig thru my Sent folder to find my previous messages. Some of what
I want to chat about would be better handled via direct communication.

If I see something where others might have an interest, I make public
comments.

Thanks!

On 6/18/2022 11:58 AM, Phillip Hellewell wrote:
> On Saturday, June 18, 2022 at 1:33:02 AM UTC-6, Harlan Stenn wrote:
>> Phillip,
>>
>> I have send you several emails. Have you received any of them?
>
> Unfortunately, no. Maybe they went to my Spam folder? If you want to try again, I'll keep a closer eye on that.
>
> Or feel free to just answer here since this seems to be working. I do believe most of my questions are ones that a wider audience could benefit from.
>
> I am happy to know that my concerns are not getting ignored. Thank you for that.
>
> Phillip

--
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!
--
This is questions@lists.ntp.org
Subscribe: questions+subscribe@lists.ntp.org
Unsubscribe: questions+unsubscribe@lists.ntp.org

On 19/06/2022 11:30, chris wrote:
>
> Yes, it does have a spec for the slew rate, but i'm not sure that would
> always be met for modern devices, as such uarts can often be run at data
> rates of up to 230 Kbytes / second, or about a 4uS bit time. That
> implies much faster rise and fall times, which relates to slew rate.

But those aren't RS232 compliant devices, although the slew rate limit
is still low enough to support those data rates, but not with the full
cable length.
>
> We can theorise about that, but iirc, I bought two ttl to rs232
> converters at the time. If I can find the second one, i'll set it up
> on the bench and measure the propagation delay on a scope from input to
> output. Also, see what effect the 2.5nF cap has on the waveform and
> timing...

The 2.5nF is mainly intended to represent the capacitance of the cable,
which is deliberately operated with both source and load termination
impedances well above the characteristic impedances, so behaves like
capacitor. With the full length cable, rather than the lumped
capacitance, you would expect the voltage to staircase upwards, each
time the leading edge reflection returns.

The 2.5nF basically allows for the 50 foot maximum cable at 50pF/ft.

chris <chris-nospam@tridac.net> wrote:
> On 06/19/22 01:51, Jim Pennino wrote:
>> chris<chris-nospam@tridac.net> wrote:
>>> On 06/18/22 04:45, Phillip Hellewell wrote:
>>>> Does anyone have answers to the specific issues I found, like why the github repo
>>>
>>> isn't being synced, or why I can't log into bugs.ntp.org, or why emails
>>> to webmaster@ntp.org bounce?
>>>
>>> Sorry, no idea at all, but does seem to be a common thread running
>>> through, the lack of community in terms of future direction and
>>> progress.
>>>
>>> The build here is earlier than I remembered, from the end of 2019, but
>>> one of the reasons I sort of gave up, was the difficulty in sorting out
>>> the pps input options. PPS handling at hardware interface level is a
>>> critical function if the most accurate results are to be obtained.
>>> At present there is just a single hardware option for that, the
>>> rs232 data carrier detect (dcd) line, which as David has said, is
>>> less than ideal because of the need for level translation, which
>>> introduces a delay. In practice, that will be small, since the
>>> data sheet figures for a typical max232 assume a 2.5nf capacitive
>>> load on the output, whereas a few inches of wire into a rs232 line
>>> receiver setup might be much faster. Having no other options for pps
>>> is serious limitation though. The key thing is that whatever interface
>>> is used, it must be capable of generating an interrupt to system,
>>> to minimise offset. Both the dcd and the parallel port ack line
>>> satisfy that requirement, though modern pc hardware often has neither
>>> interface.
>>>
>>> Do hw and sw here, but the limitations of the present system only
>>> become evident when looking in depth at all aspects. Just wish there
>>> could be some sort of plan to fix the various issues.
>>>
>>> Chris
>>
>> A delay in a hardware level translator will be a fixed amount easily
>> fudged out and with jitter far less than that of the computer reading
>> and processing the interrupt.
>
> Agreed and that is the best option. Polling methods will always suffer
> from more jitter. There will be timing uncertainty around the polling
> rate, of which there is a minimum practical limit. Direct interrupt
> methods are really the only way to go for best precision.
>
>>
>> An industrial strength serial/parallel card costs about $40 these days.
>>
>> You need more that just an interrupt to handle PPS, you need a high
>> priority interrupt.
>>
>
> Using FreeBSD here and that needed a kernel rebuild to enable PPS
> support. Also enabled kernel thread preemption, which should help
> make the os more deterministic. Unless you write your own os
> optimised for the task, there's not much else you can do afaics...
There is still the matter of interrupt priority.

Serial ports normally show up on irq 3 and 4. If it is an add in card
they can show up anywhere, and if it happens to be something like
irq 19, then you will find your jitter in the PPS to be something in the
order of 10 to 20 microseconds even on a very fast machine.

On 2022-06-19, David Woolley <david@ex.djwhome.demon.invalid> wrote:
> On 19/06/2022 01:06, chris wrote:
>> In practice, that will be small, since the
>> data sheet figures for a typical max232 assume a 2.5nf capacitive
>> load on the output, whereas a few inches of wire into a rs232 line
>> receiver setup might be much faster.
>
> As we are talking about compliant RS232, which is the only real world
> reason for not just connecting TTL directly to the RS232 port, the the
> 2.5nF condition is the maximum capacitance that can appear across the
> driver output as the result of what it is driving. That sets a minimum
> possible slew rate.
>
> However a compliant RS232 system also has a maximum permitted slew rate,
> intended to minimise cross talk, and probably also to ensure that long
> cables don't ring, as the initial transient reflects backwards and
> forwards. 30V/µs is the maximum permitted slew rate for a compliant
> system. If your system exceeds that, even if it is using RS232 drivers,
> it is not a compliant system.
>

Who cares if it is compliant esp as most real RS232 do better. RS232
standards are about 50 years old. They were still using vacuum tubes:-)

Test your system to see what it can do.

On 2022-06-19, David Woolley <david@ex.djwhome.demon.invalid> wrote:
> On 19/06/2022 11:30, chris wrote:
>>
>> Yes, it does have a spec for the slew rate, but i'm not sure that would
>> always be met for modern devices, as such uarts can often be run at data
>> rates of up to 230 Kbytes / second, or about a 4uS bit time. That
>> implies much faster rise and fall times, which relates to slew rate.
>
> But those aren't RS232 compliant devices, although the slew rate limit
> is still low enough to support those data rates, but not with the full
> cable length.
>>
>> We can theorise about that, but iirc, I bought two ttl to rs232
>> converters at the time. If I can find the second one, i'll set it up
>> on the bench and measure the propagation delay on a scope from input to
>> output. Also, see what effect the 2.5nF cap has on the waveform and
>> timing...
>
> The 2.5nF is mainly intended to represent the capacitance of the cable,
> which is deliberately operated with both source and load termination
> impedances well above the characteristic impedances, so behaves like
> capacitor. With the full length cable, rather than the lumped
> capacitance, you would expect the voltage to staircase upwards, each

So teminate it to get rid of the refections.

> time the leading edge reflection returns.
>
> The 2.5nF basically allows for the 50 foot maximum cable at 50pF/ft.

William Unruh <unruh@invalid.ca> wrote:
> On 2022-06-19, David Woolley <david@ex.djwhome.demon.invalid> wrote:
>> On 19/06/2022 01:06, chris wrote:
>>> In practice, that will be small, since the
>>> data sheet figures for a typical max232 assume a 2.5nf capacitive
>>> load on the output, whereas a few inches of wire into a rs232 line
>>> receiver setup might be much faster.
>>
>> As we are talking about compliant RS232, which is the only real world
>> reason for not just connecting TTL directly to the RS232 port, the the
>> 2.5nF condition is the maximum capacitance that can appear across the
>> driver output as the result of what it is driving. That sets a minimum
>> possible slew rate.
>>
>> However a compliant RS232 system also has a maximum permitted slew rate,
>> intended to minimise cross talk, and probably also to ensure that long
>> cables don't ring, as the initial transient reflects backwards and
>> forwards. 30V/µs is the maximum permitted slew rate for a compliant
>> system. If your system exceeds that, even if it is using RS232 drivers,
>> it is not a compliant system.
>>
>
> Who cares if it is compliant esp as most real RS232 do better. RS232
> standards are about 50 years old. They were still using vacuum tubes:-)
>
> Test your system to see what it can do.

Hand-wringing over the serial physical characteristics are pointless
unless you have a very long cable or are designing your own interface.

Commercial hardware is orders of magnitude better at both latency and
jitter than most all computer hardware/software combinations unless you
are using computer hardware specifically designed for real time systems
with a real time OS.

The limiting factor for PC's and things like the Pi will be the jitter
in processing the interrupt generated by the PPS signal.

This tends to be on the order of 1 microsecond at best on every PC and
SBC board I have used.

FYI the best I've seen so far is about 900 nanoseconds on a Pi4.

On 19/06/2022 16:10, William Unruh wrote:
> So teminate it to get rid of the refections.

It's no longer RS232 if you terminate it anything less than, ISTR, 4k,
or reverse terminate in anything other than 300 ohms.

I think 100 ohm is typical for the characteristic impedance of a wire
pair, so given the open source voltage of the driver is 12 volts, by
terminating it you have removed all your noise margin, if you accept the
transition region is the full +/-3V.

If you want to use an EIA standard that uses terminated lines, you
should use RS 422, which also uses differential pairs, which also
improves noise immunity. Or RS 423, which, although it uses a
differential line receiver, is unbalanced, with one of the pair tied to
local functional ground at the transmitter.

On 06/19/22 13:57, Jim Pennino wrote:
> chris<chris-nospam@tridac.net> wrote:
>> On 06/19/22 01:51, Jim Pennino wrote:
>>> chris<chris-nospam@tridac.net> wrote:
>>>> On 06/18/22 04:45, Phillip Hellewell wrote:
>>>>> Does anyone have answers to the specific issues I found, like why the github repo
>>>>
>>>> isn't being synced, or why I can't log into bugs.ntp.org, or why emails
>>>> to webmaster@ntp.org bounce?
>>>>
>>>> Sorry, no idea at all, but does seem to be a common thread running
>>>> through, the lack of community in terms of future direction and
>>>> progress.
>>>>
>>>> The build here is earlier than I remembered, from the end of 2019, but
>>>> one of the reasons I sort of gave up, was the difficulty in sorting out
>>>> the pps input options. PPS handling at hardware interface level is a
>>>> critical function if the most accurate results are to be obtained.
>>>> At present there is just a single hardware option for that, the
>>>> rs232 data carrier detect (dcd) line, which as David has said, is
>>>> less than ideal because of the need for level translation, which
>>>> introduces a delay. In practice, that will be small, since the
>>>> data sheet figures for a typical max232 assume a 2.5nf capacitive
>>>> load on the output, whereas a few inches of wire into a rs232 line
>>>> receiver setup might be much faster. Having no other options for pps
>>>> is serious limitation though. The key thing is that whatever interface
>>>> is used, it must be capable of generating an interrupt to system,
>>>> to minimise offset. Both the dcd and the parallel port ack line
>>>> satisfy that requirement, though modern pc hardware often has neither
>>>> interface.
>>>>
>>>> Do hw and sw here, but the limitations of the present system only
>>>> become evident when looking in depth at all aspects. Just wish there
>>>> could be some sort of plan to fix the various issues.
>>>>
>>>> Chris
>>>
>>> A delay in a hardware level translator will be a fixed amount easily
>>> fudged out and with jitter far less than that of the computer reading
>>> and processing the interrupt.
>>
>> Agreed and that is the best option. Polling methods will always suffer
>> from more jitter. There will be timing uncertainty around the polling
>> rate, of which there is a minimum practical limit. Direct interrupt
>> methods are really the only way to go for best precision.
>>
>>>
>>> An industrial strength serial/parallel card costs about $40 these days.
>>>
>>> You need more that just an interrupt to handle PPS, you need a high
>>> priority interrupt.
>>>
>>
>> Using FreeBSD here and that needed a kernel rebuild to enable PPS
>> support. Also enabled kernel thread preemption, which should help
>> make the os more deterministic. Unless you write your own os
>> optimised for the task, there's not much else you can do afaics...
>
> There is still the matter of interrupt priority.

Yes and that depends on a raft of factors, including processor type,
hardware organisation and software architecture. Early processors
often had just a couple of interrupt pins, irq and nmi, so that
several devices had to be polled to find out the source of the
interrupt. That imposed it's own priority structure.
Later devices, starting in the 68000 era, used an interrupt vector
table, where interrupt sources were vectored directly to the interrupt
handler, with other methods used to organise priority.
All a bit of a wash now, with nanosecond processor response times, but
was a serious issue in the past, often requiring counting machine
cycles in interrupt handlers to ensure timing accuracy.

Real time embedded here for over 3 decades and still love the work, but
need to get more into the FreeBSD kernel to understand more about
timing. The FreeBSD internals book is well worth a read and is one
of the best documented ever seen here...

Chris

>
> Serial ports normally show up on irq 3 and 4. If it is an add in card
> they can show up anywhere, and if it happens to be something like
> irq 19, then you will find your jitter in the PPS to be something in the
> order of 10 to 20 microseconds even on a very fast machine.
>
>

On 20/06/2022 00:14, chris wrote:
> Early processors
> often had just a couple of interrupt pins, irq and nmi,

You mean microprocessors. NMI seems to be a concept that was introduced
with microprocessors, and multi-priority interrupts existed before even
the earliest microprocessors.

In terms of software, I don't think typical Linux code really fully
supports multi-level interrupts, and, if anything, may effectively
invert the priority order.

Jim Pennino wrote:
> William Unruh <unruh@invalid.ca> wrote:
>> On 2022-06-19, David Woolley <david@ex.djwhome.demon.invalid> wrote:
>>> On 19/06/2022 01:06, chris wrote:
>>>> In practice, that will be small, since the
>>>> data sheet figures for a typical max232 assume a 2.5nf capacitive
>>>> load on the output, whereas a few inches of wire into a rs232 line
>>>> receiver setup might be much faster.
>>>
>>> As we are talking about compliant RS232, which is the only real world
>>> reason for not just connecting TTL directly to the RS232 port, the the
>>> 2.5nF condition is the maximum capacitance that can appear across the
>>> driver output as the result of what it is driving. That sets a minimum
>>> possible slew rate.
>>>
>>> However a compliant RS232 system also has a maximum permitted slew rate,
>>> intended to minimise cross talk, and probably also to ensure that long
>>> cables don't ring, as the initial transient reflects backwards and
>>> forwards. 30V/µs is the maximum permitted slew rate for a compliant
>>> system. If your system exceeds that, even if it is using RS232 drivers,
>>> it is not a compliant system.
>>>
>>
>> Who cares if it is compliant esp as most real RS232 do better. RS232
>> standards are about 50 years old. They were still using vacuum tubes:-)
>>
>> Test your system to see what it can do.
>
> Hand-wringing over the serial physical characteristics are pointless
> unless you have a very long cable or are designing your own interface.
>
> Commercial hardware is orders of magnitude better at both latency and
> jitter than most all computer hardware/software combinations unless you
> are using computer hardware specifically designed for real time systems
> with a real time OS.
>
> The limiting factor for PC's and things like the Pi will be the jitter
> in processing the interrupt generated by the PPS signal.
>
> This tends to be on the order of 1 microsecond at best on every PC and
> SBC board I have used.
>
> FYI the best I've seen so far is about 900 nanoseconds on a Pi4.

Back before OoO processors, spread spectrum clocks and variable
frequency boosts, i.e. Pentium days around 1994-1997, it was trivially
easy to get far below your stated 1 us jitter.

It is indeed harder today!

A propr GPS clock these days needs to be inverted, i.e. the server asks
the clock what time it is _now_, and gets back a timestamp.

So, by taking the local system clock, sending off this querey, and then
checking the local clock again, you can both measure the latency of this
reading and get the official/gps-based time.

In order to work this way, the GPS needs a way to use its local osc
(typically running at 10 MHz) to count ticks since the last second
transition, there has been at least one reference clock that worked this
way.

Repeat this call maybe 5 times and pick the one with the lowest
turnaround time.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 06/20/22 11:48, David Woolley wrote:
> On 20/06/2022 00:14, chris wrote:
>> Early processors
>> often had just a couple of interrupt pins, irq and nmi,
>
> You mean microprocessors. NMI seems to be a concept that was introduced
> with microprocessors, and multi-priority interrupts existed before even
> the earliest microprocessors.
>
> In terms of software, I don't think typical Linux code really fully
> supports multi-level interrupts, and, if anything, may effectively
> invert the priority order.

That's correct, thinking of things like early Arm, 6502, 6800 and many
others. Suspect some of the early minis used similar ideas, perhaps
under different names. The pdp11 mini, for example, had a fully vectored
interrupt dispatch table from day one back in 1969. Not sure about the
Data General Nove from the same era...

As for Linux, dumped that for good in frustration about the bloat after
systemd. Little more than a windows replacement these days imho. FreeBSD
is much more easily configured for real time work and comes with far
less baggage. Of course, traditional unix, including Linux tasks run
to completion, where a fully preemptive kernel is needed for real time
work...

Chris

On 2022-06-19, David Woolley <david@ex.djwhome.demon.invalid> wrote:
> On 19/06/2022 16:10, William Unruh wrote:
>> So teminate it to get rid of the refections.
>
> It's no longer RS232 if you terminate it anything less than, ISTR, 4k,
> or reverse terminate in anything other than 300 ohms.

Who cares if it is no longer RS232, if it works. As has been pointed out
virtually no rs232 hardware is RS232 according to the standards. What
one wants is a signal pin that triggers an interrupt. If your bog
standard RS232 does that, then use it. I do agree that if you terminate
it with too low an impedance, you will get a small signal on the pin,
and it could be problematic, or could not, again depending on the
hardware.
>
> I think 100 ohm is typical for the characteristic impedance of a wire
> pair, so given the open source voltage of the driver is 12 volts, by
> terminating it you have removed all your noise margin, if you accept the
> transition region is the full +/-3V.
>
> If you want to use an EIA standard that uses terminated lines, you
> should use RS 422, which also uses differential pairs, which also
> improves noise immunity. Or RS 423, which, although it uses a
> differential line receiver, is unbalanced, with one of the pair tied to
> local functional ground at the transmitter.

On 21/06/2022 10:48, William Unruh wrote:
> Who cares if it is no longer RS232, if it works. As has been pointed out
> virtually no rs232 hardware is RS232 according to the standards.

Oddly that is the point I was trying to make. Someone was insisting
that you mustn't cut corners, and must use an RS232 driver when
interfacing to a nominally RS232 input port. I was analyzing the
consequences of actually conforming to RS232.