john@miles.io said:

RS232 works much better for capturing PPS timing.

Another advantage of RS232 over USB is that the configuration is stable when
things get unplugged and replugged, or powered off, or ...  Of course, that's
a disadvantage if your program wants to know when the gizmo got unplugged.

--
These are my opinions.  I hate spam.

Hi Hal, according to ntp.org the parallel port is also usable for PPS:
http://www.eecis.udel.edu/~mills/ntp/html/pps.html

Also, Take a look at this gentleman's page (Chrome will translate):
http://www.finetune.co.jp/~lyuka/interests/radio/gps/
there is quite a difference between the amount of jitter between the two interfaces!

But, you know at the end of the Day,
Anything over Ethernet network will slowly take apart the carefully built NTP server you built with its precision time source anyway :)

Looking around, PPS over TTY is better supported and easier to interface.

Where do we draw the line and say, enough is enough?!

-marki

-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf Of Hal Murray
Sent: Friday, 26 July 2013 9:17 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] RS 232

john@miles.io said:

RS232 works much better for capturing PPS timing.

Another advantage of RS232 over USB is that the configuration is stable when things get unplugged and replugged, or powered off, or ...  Of course, that's a disadvantage if your program wants to know when the gizmo got unplugged.

--
These are my opinions.  I hate spam.

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

Unless you are watching it with a ring-0 (kernel) driver, and/or using a
hard realtime OS to run the client software, it really won't matter that
much.  Anyone running Windows or most flavors of Linux has more to worry
about than the distinction between USB and RS-232, when it comes to latency.

For truly critical applications it's best if the counter itself does the
timestamping.  For ordinary NTP use on Linux or Windows the distinction
between RS232 and USB is pretty questionable.  Submillisecond jitter has
been documented in USB PPS applications (e.g.,
https://lists.bufferbloat.net/pipermail/thumbgps-devel/2012-March/000109.htm
l ), albeit with unspecified latency.  If that's not good enough, you need
to tackle the issue somewhere besides the physical layer.

when

that's

USB devices have gotten a bad reputation in this regard because of
developers' failure to understand the idea behind serial numbers.  As with
noise immunity, it's possible to do it right, it's just that too many people
don't bother.

-- john, KE5FX
Miles Design LLC

On Thu, Jul 25, 2013 at 8:40 PM, John Miles john@miles.io wrote:

In just normal UNIX (including Mac OS X) and linux you can see the
difference in the log files between USB and RS232.  There is three orders
of magnitude difference.  It's micro vs. milli seconds.

But as this filters down to the application level, what are you using this
timming informations for?  Maybe you have a database and you are time
tagging transactions?  In that case maybe all you need is tenths of
seconds.  Who knows?  THat is really what needs to be driing this process
the end use of the data

Chris Albertson
Redondo Beach, California

Ever since WINxp arrived on the scene hams who send code  via computer
to radios via parallel, serial or usb ports (with serial port converters
following) have seen the latency issue in spades.  We're talking about
effective baud rates less that 50.  3-4 milliseoond variable latency
changes making the code nearly unreadable.  The killer is that the
latency changes randomly.

Previous to WINXP one could do direct writes to the ports under software
controlled timing.  All was good.

The solution for WINXP  was to bypass WINDOWS handling of port data via
a DLL called DLPORTIO
There is a similar one for WIN7.  I haven't timed how accurate it is.
However 65 words per min (6 characters/second) code can be sent with no
detectable timing problems.

The simple act of open and closing a set of contacts at precise times
now requires a huge, faxt machine, tons of software and software to work
around the normal software.  That's progress?

Brian

On 7/25/2013 10:40 PM, John Miles wrote:

On 7/26/13 4:41 AM, briana wrote:

no.. what it means is that you have a bad system architecture.  You
shouldn't be trying to do hard real time on a machine primarily designed
for user interface experience and running office automation tools like
word and excel.  It is no more reasonable to expect a modern PC
(primarily a media display device) to do hard real time control than it
is to expect an iPhone to do so, or even a mainframe computer.  The days
are long past when a PC is basically a microcomputer with a few limited
peripherals.

Hams have problems because the developers have insufficient budget or
resources to devote the time to writing appropriate code using the
Windows media stack to get the synchronization performance desired.
They're looking for the "quick fix", a'la direct port writes.

Note that real time action in games works fairly well, as does keeping
the video and audio synchronized in various and sundry media players,
even when playing through USB connected devices.  Midi sequencers run
just fine with Windows.

So, it's more a matter of spending the enormous amount of time needed to
become facile with the entire multimedia API, all the various hooks and
widgets in Windows, etc.  This is a non trivial task, and one that
cannot be done in spare time on the weekends for most people. You
generally need to be immersed in the "windows way" of doing things
(which is exceedingly different from DOS, microprocessor, or Unix) and
understand how it works, and then you need to be using Windows
development tools and have the appropriate libraries, etc.  The Windows
ecosystem is quite powerful, but it's different than other ones, so a
life of Unix kernel hacking might give you the general background, but
will result in you fighting with Windows at every turn, because it's
just different.

And, in some cases, moving the timing critical operations off to a
separate device is going to be the wisest plan.  The Roland MPU401 Midi
box was one of the first to do this, back in the DOS days.

Hi Jim,

You mean to imply no commercial programs ever use "quick fixes"?

It's difference between seat-of-the-pants field engineering and a
theoretical pursuit.  There are no humanitarian costs associated with
failure so standards and formal test program and the like aren't required.

Your are right it is a question of market size the $$ that can be
charged for a package rather what could be with enormous effort.

Many ham programs are free or essentially so.  There would be no market
for them if they were not.  Hams are basically cheapskates.

To say the programs are not sophisticated or the coders non-skilled is
simply wrong. I suggest you in particular look at the free N1MM code and
what it does.  It does indeed use the quick fix.

The other fact is that hams use their PC's for many of the everyday
applications you describe as well.  Nor are most hams computer hardware
geeks, programmers, OS geeks (or even OS literate) or network engineers.
They put their kilobucks into radios, antennas and sundry hardware.
Separate computers/OS's for each piece of hardware they have simply
doesn't happen often.  In fact, given the array of hardware used,
separate computers and OS's would likely be a nightmare.

BTW, one fix for the timing problem that corrupted code timing is
something called WINKEY.  It is an external box.  You send it ASCII
characters and it sends out the perfectly timed code.  It does work but
has caused quite a few problems in setting it up.  There is more it has
to do than just the translation.  Radio teletype can be done in a
similar way with the equivalent of a modem.

Then there are multiple antenna rotors to position, logging of contacts,
antenna switch boxes, voice keyers, audio routing, networks, internet
data streaming, multiple radios to control and communicate with,
separate SDR's which automatically troll for stations to contact,
amplifier interfaces which pretune the high power amplifier when
necessary, multi monitor displays, satellite antenna tracking..  The
list goes on.  Having one central computer do everything is pretty much
of a must for a single operator.

BTW, calling it wireless isn't appropriate.  There generally is a huge
rat's nest of wires and cables behind the desk.

Regards
Brian

On 7/26/2013 13:06, Jim Lux wrote:

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2242 / Virus Database: 3209/6022 - Release Date: 07/26/13

On 7/26/13 8:46 AM, Brian Alsop wrote:

heavens no.. Plenty of quick fixes..

Yep. I'm one of them.  I think it is fundamentally unfair to whine about
"why won't what I buy today do what my 30 year old widget did, at no
cost".  There was a short time when PCs were slightly grown up from the
Altair/Imsai/Cromemco/Soroc/etc days, but were still pretty low level.
So simple hardware hacks (using the printer interface as a general
purpose parallel I/O) were easy and feasible.

But it's unrealistic to expect this from a modern PC.  The industry has
moved on. The sweet spot of "consumer gear providing a hardware hacking
platform at low cost" is long gone.  Today, if you want to do that sort
of parallel port hacking, you buy an Arduino or some other comparable
platform. (or, if you want to do it on a modern media player/PC, you
suck it up and learn to use the modern platform, but that's a big
investment of time).

It's the same in cars. It's unrealistic to expect to use your engine
hacking skills acquired in the 70s on hardware from the 60s with designs
dating to the 40s and 50s on a modern engine.  The modern tuner hackers
work with the engine maps and hack the ECU, but that, like working with
modern PCs, requires an investment in newer tools and a fairly hefty
investment of time in learning how the new systems work, and what's
adjustable.  That knowledge of engine thermodynamics and combustion will
be useful in hacking both 1960s and 2000s vintage cars, but the detail
skills are different: less knuckle busting today, more arcane keyboarding.

No.. I'm not saying that modern developers of ham software aren't clever
or sophisticated.  It is that they tend to rely on quick fixes which are
not long term reliable or durable over the underlying platform changes.
How many programs relied (still rely) on a stack of legacy software
adapters/emulators.  There's probably software out there that still uses
BIOS INT 14, running in  DOS emulation box, running in a WinXP
emulation, etc.

(and this is true in industry.. I'll bet there's someone in the US being
paid with a paycheck printed by some old IBM 1400 series code running in
emulation.  Certainly there is a lot of System/360 software and PDP/11
software running in emulation out there.)

Most hams aren't RF designers either, and don't design and build their
own radios.  What I argue is that if they want modern integration, and
that connecting the PC is an essential part of their system, then they
need to allocate some resources towards making that work.  Maybe they
shouldn't spend the kilobucks on the radio, but should spend X/2
kilobucks on the radio and X/2 kilobucks on the software to make the PC
work with the radio. That is, if the desired user experience is radio
and PC playing together.

Granted, hams (and many, many other users) have a tough time paying for
software. It's intangible, the reproduction cost is tiny, etc.

Hey, we have the same issue with spacecraft design.  More and more of
modern spacecraft is software based, but the long traditions are
hardware centric. And to be fair, the development model for software is
radically different than hardware.  There really isn't the "ready to cut
metal" step in software design and development that there is in
hardware.  But it's just as hard to get people to spend appropriate
resources on software development vs hardware in industry as it is to
convince hams that they should pay for software development vs buying
new hardware for their hobby.

ANd keeping it more along time-nuts... Think of the new array of
instruments that are USB or Ethernet only interfaces. That's a
fundamental difference in how you interact, and there's been a LOT of
growing pains and evolution, with a whole host of compatibility issues.
Look at all the versions of what the interface via GPIB looks like..
Early days you were basically sending binary coded switch closures; then
you sent commands with a couple letters followed by an argument
(FR1000MZ); then you have the whole hierarchical SCPI stuff now.

And the User interface side is also evolving.  I'm no huge fan of
Labview (from a software development/CM standpoint, mostly)but NI has
spent a fair amount of effort in making it consistent over the multitude
of operating system versions.

Sure.. And you're basically trying to shoehorn a real time control and
data acquisition system into what is, these days, really designed as a
media player and glorified typewriter.  You're trying to leverage an
inexpensive media player (the PC) to do something it's really not suited
for, and as a result, you either have frustration, or you spend a lot of
unpaid time making it work.

Wouldn't a better long term solution be to do what they DO for realtime
data acquisition and control..  Have a box with all the needed
interfaces (perhaps modular) and an appropriate data connection to a box
that does the user interface, and have that user interface via something
that is able to leverage low cost consumer gear?

But there, you get back to the market potential.  A lot of hams aren't
interested in spending money on a SCADA system. They want to spend in
small discretionary chunks of $50-200 to incrementally change their
system. And my basic contention is that you can't get to "well
integrated with modern PCs" by an incremental $100 strategy.

You can do almost hard real time (certainly at the millisecond scale)
with Windows, but it is expensive in terms of software.  There are
relatively few people who know how to do it, and they command
commensurate wages.  And, it would seem, that none of them have ham
radio as a hobby, or at least, if they are, they aren't interested in
using their real-time Windows skills on it.

For myself.. I've gotten to where I don't do the same things at home
(coding, RF design and build) as I do at work.  The itch gets scratched
at work, and I can use my time at home to scratch other itches.  Yep, I
am an appliance operator and proud of it.

And that's true of most data acquisition and control systems..

There is a difference between managing the latency (as in ensuring that sound and video are synchronized, but latency itself is acceptable) and minimizing the latency as in a Morse code keyer where the operator has to manually control the generation of elements that can be as narrow as 20mS (one dit at 60 words per minute) while getting timely aural feedback. That means you need the sound to start and stop within less than about 5 mS following the key closing and opening.

It is trivial to do on a microcontroller running at 1MHz but surprisingly harder to do on a 2GHz Windows machine.

It is not just a matter of time stamping the key closure, you have to get the sound system starting and stopping.

Didier KO4BB

Jim Lux jimlux@earthlink.net wrote:

--
Sent from my Motorola Droid Razr 4G LTE wireless tracker while I do other things.

On 7/26/13 12:50 PM, Didier Juges wrote:

Yep. although, since the propagation path is on the order of 100
milliseconds, providing feedback to the user directly from the interface
works quite well (e.g. generating tones directly from the keying).

The challenge is trying generate the sidetone through Windows.  But
really, there's no reason why you can't have a "keying box" that
provides the direct side tone and sends the events to the host computer.
Then the issue is more about keeping constant latency (or else the CW
will be really, really hard to copy)

It's not like an extra 10 milliseconds of delay between keying and the
emitted RF waveform makes any difference at the other end.

Hi

There's also the time honored approach of generating the side tone off of the generated RF. In that case the latency to the transmitter would matter quite a bit. I have no idea why you would run the key through a computer in that case ….

Bob

On Jul 26, 2013, at 4:52 PM, Jim Lux jimlux@earthlink.net wrote:

Actually computers generate probably 98% of the code during so called
radio contests.  During a contest weekend it is not at all unusual for
individuals to make thousands of contacts.  Computers automate the
drudgery of sending your call thousands of times and most exchanges.

However even during these contests, the manual key has to sometimes be
used to provide corrections or handle situations not covered by "canned"
messages.

Because of the tremendous adjacent and even on frequency interference,
computers have proved incapable of decoding code with the accuracy and
speed of a human in real time.

Brian

On 7/26/2013 22:04, Bob Camp wrote:

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2242 / Virus Database: 3209/6023 - Release Date: 07/26/13

Hi

….. but why route the key through the computer if you are generating the side tone off of RF…

Bob

On Jul 26, 2013, at 6:16 PM, Brian Alsop alsopb@nc.rr.com wrote:

Actually the sidetone is generated in most cases by the transmitter. It
can be fed into either earphones, speaker or the computer depending on
what you're doing.

The manual key can be connected to the computer, WINKEY box or directly
to the transmitter.  Connecting it to the computer or WINKEY allows one
to interrupt a canned message being sent by the computer to send
something else manually. ($%$#* hit the wrong message button)

Brian

On 7/26/2013 22:19, Bob Camp wrote:

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2242 / Virus Database: 3209/6023 - Release Date: 07/26/13

Hi

The advantage of generating the side tone from rectified RF is that you have quick feedback when you have no RF. The disadvantage is that it's the maximum latency approach.

Bob

On Jul 26, 2013, at 6:25 PM, Brian Alsop alsopb@nc.rr.com wrote:

On Fri, Jul 26, 2013 at 12:50 PM, Didier Juges shalimr9@gmail.com wrote:

The problem is the Windows sound system is designed for  media playback.
WIth Windows you can use ASIO drivers.  These are used by every musician
and anyone who does recording.  MS Windows as it comes out of the box is
just not suited to serious audio work.  The other OSes alradi have
something like this and a few ms of latency is very easy.
http://en.wikipedia.org/wiki/Audio_Stream_Input/Output

Although you can get it, you really don't need latency below about 20ms.
You can't notice it.  Sound moves at about 1 foot per 1ms.  So try this,
have someone tape a table top with their fingernails 20 feet away and see
if you can detct the speed of sound delay.  Or have him speak and see if
you see the lips out of sync with the sound.  For most people the distance
needs to about over 50 feet to detect any of this.

The more code example is not right because people learn to send by muscle
memory.  I bet they can send with not feedback at all.

Using standard PC hardware and the standard Linux kernal the latency from
on the control lines is WAY below the millisecond level, it's a handfull of
microseconds.  The pins goes directly to an interrupt handler and it is
very. fast.  Looks atr the douce code there is not a dozen lines of code
to handle it.

--

Chris Albertson
Redondo Beach, California

There are a number of things that can be done to go around Windows latency, but just like Time-Nuts are not satisfied with a just adequate timing solution, some hams don't like having an extra box if it can be avoided. When you take your rig and equipment to a far away destination, the most you can do with the minimum number of boxes, the better off you are.

Personally, I made my own keyer with an 8051 just because it was more fun than buying one, and I don't want to spend the time to go around Windows idiosyncrasies, but to each his own.

Didier KO4BB

Bob Camp lists@rtty.us wrote:

--
Sent from my Motorola Droid Razr 4G LTE wireless tracker while I do other things.

Most CW operators use "keyers" to generate the dits and dahs precisely. The keyer can be controlled directly by the computer or be a software Meyer or be controlled by an iambic key connected to the computer. A few operators still use straight keys like the J38 or a 'bug' like the Vibroplex. The key is the input method, or the keyboard.

Some software, like the N1MM contest logging software have an embedded software keyer and also support a separate external keyer.

Didier KO4BB

Bob Camp lists@rtty.us wrote:

--
Sent from my Motorola Droid Razr 4G LTE wireless tracker while I do other things.

There are other timing issues involved too.

Many radios still use relays to switch from transmit to receive. (PIN
diodes only in the more expensive ones).  The radio receives a key
closure but delays RF output from 8 to 20 ms or more to allow time for
relay closure.  This time delay becomes particularly important when one
is driving a high powered amp (like 1.5 KW).  It heavier relay in them
need at least 8 to as much as 20ms (even when hot shotted) to go from
transmit to receive.  Hot switching is to be avoided at all costs.
Some top of the line amplifiers do use PIN diodes too but they are not
very tolerant of higher than 2:1 SWR's. In the heat of action it is easy
to select the wrong antenna or put the amp in a >2:1 SWR situation.
Their replacement costs are $100 and up and more than one are used.  Yes
there are protection circuits which help preserve them most of the time.
It only takes one bad zap though.

BTW latency/aural feedback issues also affect the acoustic world.
Performers in locations with echos need to wear an earpiece which
carries non-echo band music to not get totally confused.  It is an
interesting phenomena to see a performer go totally flaky because of echos.

Brian

On 7/27/2013 05:05, Didier Juges wrote:

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2242 / Virus Database: 3209/6025 - Release Date: 07/27/13