> In this scenario how can I coordinate the TSIP and PPS signals?
> Furthermore, and regarding to the API specified in rt_com.h:
> (tacking into account that I have the TSIP and PPS signals in the serial
> cable)
> How can I specify that I want to get an interrupt when I receive a PPS
> signal or when I receive a TSIP packet? And how can I specify what is the
> pin(s) whether I received the PPS or the TSIP signals?
Hi Carlos,
I've done this sort of thing several times in rtlinux, but I usually use
Microchip microcontrollers to actually do the work and then just read/set
them from rtlinux. Doing it all from rtlinux subjects you to the
system interrupt latency, but that can be pretty good most of the time on
the order of a few microseconds in many situations.
I recommend connecting your 1-pps either to the printer port interrupt
which you can access from the printer connector, or if you have an unused
ISA bus interrupt, jumper directly to that. I believe the interrupts are
all set to be "edge triggered" so you don't have to worry about missing an
interrupt, just the latency of it.
Setup the following:
long long int frac_secs;
unsigned long seconds;
Upon receiving the interrupt, read and store the TSC value, and then
increment your seconds counter variable. That TSC will
correspond to the "even second fractional edge time" of the 1-pps signal
and we will use it to measure the fractional time from the 1-pps edge to
any event you want to time-tag.
To get this stuff in to read GMT or GPS time as indicated from your rs-232
NMEA string, have a user program read, parse, decode, and convert the
$GPGGA time string into seconds of the day. For example:
sod = hh*3600 + mm*60 + seconds;
To sync up your interrupt driven clock, simply write the sod value into
the seconds variable described above. This will give you seconds of the
day. You can extend it to an SOE (Seconds of the Epoch) value by using
your linux system date/time functions if you like.
To now use the high-resolution GPS synced clock to time-tag things when an
event occurs, you simply read the current TSC value, the current "seconds"
value and the current frac_secs value. To get the number of CPU clocks
since the leading edge of the last 1-hz GPS signal, simply subtract
frac_secs from the TSC value you just read. IF you have a 1ghz CPU, that
will give you the number of nanoseconds since the last 1-hz pulse. To
convert that to seconds just multiply by 1e-9 and then add the result to
a (double)seconds. The accuracy will probably nominally be on the order
of 2-5 microseconds but with 1ns resolution. Things can get tricky at the
one second rollover. This method can make a very good clock with little
hardware or effort required.
I used a variation on this method where I implement all the code in a
Microchip microcontroller and have the externel hardware "event"
automatically time-tagged, and the result queued in a hardware fifo. With
the microcontroller, you can easily have reliable accuracy on the order of
1-2us all the time. I use it to time-tag when a laser is triggered and at
rates up to 10khz.
Good luck!!!!!
-C. Wayne Wright
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/
