Juergen Beisert wrote: > Hi, > > currently I'm trying to write a clock driver for my selfmade USB based DCF77 > receiver. Communication works trough the "usblib", there is no kernel > driver involved. But now I'm in trouble how to forward the time to the > NTPD. There are various DCF77 drivers in the ntp source tree. But they all > are based on a serial device. I have no. I have to poll my USB device two > times a second. Hmmm, the basic heartbeat of ntpd is at once per sec. Going faster will be requiring some work. Also we try to avoid any lengthy synchronous transactions where ntpd processing is blocked for longer times. Thus an asynchronous programming model has evolved where the request to the device are sent via the transmit path or the periodic 1 sec call for refclocks. Results are processed as they arrive via the input loop (in Unix-like environments when the SIGIO/SIGPOLL signal arrives). For this to work the communication library should provide means to facilitate asynchronous notification or the interactions (request/reply) need to be short and the timestamping problem (fetching the local time at the second event) needs to be solved.
> My clock device generates a data set with a reference > second pulse - synced to/by the DCF signal - and also provides the raw bit > information sent via DCF in 59 bits for the next minute (one bit per second > like the DCF77 signal does, but already filtered and converted to binary > data). > Is there a way to use anything from the libparse/ directory to let it decode > the DCF bit stream, but _not_ registering and using a serial device? You could extract that code. See libparse/clock_rawdcf.c. cvt_rawdcf() converts serial 50 baud data to 1/0 sequences - You solved that already. convert_rawdcf() converts the bit sequence to a time. > > Another question: How does the time flow works? I read > the "refclock_hopfpci.c" clock driver, as it also does not use a serial > device. It does something in "hopfpci_poll" (struct refclock.clock_poll). > But the comment of this function (and in all the other implementations I > found) is: "called by the transmit procedure". ????? Will this function be > called periodically (by ntp)? Or does the clock driver trigger something to > let it be called? See above for the asynchronous I/O model. > > Any hints are welcome. > Juergen Another way to do it, is to use the shm driver. Create a program that controls your device and does the timestamping. This program can feed ntpd via shared memory with the data. No need to mess with ntpd at all. See gpsd for an example of an implementation. Best regards, Frank _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
