[aprssig] Clock/timing accuracy when generating an APRS signal

[Dave]

As an asside to this.

Though it will not affect (for the better) the noise issue, the best and 
easiest way to reduce "other process induced latency" on a Windows 
machine (at least) is to max out the working RAM it has, within reason. 

There is no point stuffing 8G into a machine running a 32 bit verion of 
the OS, as that can only address under 4G at best.  Unless the hardware 
is 64bit capable, and you plan going that route, but then there are 
issues running some older "Ham" 32 bit code, on 64 bit systems!  It never 
ends.

Anyway...  The less time it spends swapping stuff in/out of Virtual 
Memory (on disk) the better the overall system performance.

As hinted at by Stephen Smith, keeping to an absolute minimum, all the 
background "Accessories" (printer monitors, IM clients etc) helps no end 
too.  (Right click, and select 'Exit' if you have to have them load at 
boot time.)

But as he also said, there is no substitute for dedicated hardware, even 
if it has to have it's own dedicated processor.

Not sure about the TigerTronics devices.  I've heard mixed stores about 
them in other walks of Ham Radio life.  They are not that well liked in 
the SDR and ALE communities, for other reasons.

Take Care.

73

Dave G0WBX.


From:	Richard Corfield <richard.corfield at gmail.com>
To:	aprssig at tapr.org
Date sent:	Wed, 31 Aug 2011 23:20:56 +0100
Send reply to:	TAPR APRS Mailing List <aprssig at tapr.org>
Subject:	Re: [aprssig] Clock/timing accuracy when generating an APRS signal

> 
> Thanks for the info. The receiving PC is a Netbook and was using
> internal sound card. As I type this some process is hogging the system
> or it's running out of RAM so I watch the text follow a few characters
> behind me typing it. (Windows Update is a bad one, as is the virus
> scanner. I guess the real issue here is Google Mail doing something
> big in javascript).
> 
> I am now using a crystal in my transmitter (a PIC microcontroller). I
> had been trying to use its internal RC clock which is more like
> 2000ppm, though I wonder if that is stable enough over short time
> periods that I could train it using the accurate 1Hz signal from my
> GPS module.
> 
> The waveform generation is based on interrupts but they are high
> priority and very predictable. The bigger problem is that I have to
> round the amount of clock ticks per sample to a whole number so lose
> just under 1% at 2200Hz, and measure the length of a bit in terms of
> samples which is not a whole number. If needed I could use a second
> timer to improve that. If I can't assume that the receiver can adjust
> to small drift in timing by looking at when the tone switches then
> I'll need to keep the length of my bits quite accurate. Because the
> error will be different for each tone it will look like jitter rather
> than a constant error factor.
> 
> Thanks
> 
> - Richard
>