[opensuse] DCF77, USB <-> parallel adapter, any solution?
I was using a DCF77 Dongle on the parallel port on my older machine and got the DCF77 time information in Europe. This worked quite fine most of the time. My new machine has no parallel port. I tried several USB <-> Parallel adapters (like the DeLock USB910) but they all failed. Some people posted on the net that these are only printer adapters. Are there any USB <-> Parallel adapters that work with dongles, non printer devices like the Conrad DCF77 ( see http://man.sourcentral.org/SUSE101/4+pcfclock , picture: http://www.linum.com/typo3temp/GB/499b753382.jpg?file=uploads%2Fpics%2Ffunkuhr-conrad-lpt-540-20-20.jpg&md5=fdd0be05be243392bdb490c7925160d3e0e46f85¶meters[0]=YTo0OntzOjU6IndpZHRoIjtzOjM6IjgwMCI7czo2OiJoZWlnaHQiO3M6NDoiNjAw¶meters[1]=bSI7czo3OiJib2R5VGFnIjtzOjU4OiI8Ym9keSBzdHlsZT0iYmFja2dyb3VuZDoj¶meters[2]=RkZGOyBtYXJnaW46IDBweDsgcGFkZGluZzogMHB4OyI%2BIjtzOjQ6IndyYXAiO3M6¶meters[3]=Mzc6IjxhIGhyZWY9ImphdmFzY3JpcHQ6Y2xvc2UoKTsiPiB8IDwvYT4iO30%3D ) Any other solutions that have DCF77 or GPS time receiving functionality even if the machine is turned off? Thanks in advance -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Peter Maffter wrote:
I was using a DCF77 Dongle on the parallel port on my older machine and got the DCF77 time information in Europe. This worked quite fine most of the time.
My new machine has no parallel port. I tried several USB <-> Parallel adapters (like the DeLock USB910) but they all failed. Some people posted on the net that these are only printer adapters.
Are there any USB <-> Parallel adapters that work with dongles, non printer devices like the Conrad DCF77 ( see http://man.sourcentral.org/SUSE101/4+pcfclock ,
picture:
)
Any other solutions that have DCF77 or GPS time receiving functionality even if the machine is turned off?
Receiving is no problem, but if you want the time displayed like on your parallel thingie, I don't know. We use a Tobit serial DCF77 receiver. -- Per Jessen, Zürich (15.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 2012-08-28 at 07:36 +0200, Per Jessen wrote:
Tobit serial DCF77 receiver
OOC, how accurate are these? The signal has the resolution if one second. But I guess when that second is, is very accurate, since it is based on the German national atomic clock. There is a delay (3 milliseconds at 1000 km from Frankfurt). But other than that, any idea how accurate your PC clock is when using this to set the time? Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Tue, 2012-08-28 at 07:36 +0200, Per Jessen wrote:
Tobit serial DCF77 receiver
OOC, how accurate are these?
As accurate as the DCF77 signal :-)
The signal has the resolution if one second. But I guess when that second is, is very accurate, since it is based on the German national atomic clock.
Right.
There is a delay (3 milliseconds at 1000 km from Frankfurt). But other than that, any idea how accurate your PC clock is when using this to set the time?
NTP knows about transmission delays and all that - to be honest, I don't know how accurate it is, I have nothing to compare to. I am not concerned about milliseconds myself, but I suspect that is the level of accuracy achievable. -- Per Jessen, Zürich (19.7°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 2012-08-28 at 10:14 +0200, Per Jessen wrote:
NTP knows about transmission delays and all that - to be honest, I don't know how accurate it is, I have nothing to compare to. I am not concerned about milliseconds myself, but I suspect that is the level of accuracy achievable.
I have read that inexpensive receivers, like in consumer grade clocks, should be able to achieve 0.1 sec accuracy. Better receivers can do better. But, returning to the thread, would this be the case when a USB adapter is added? I know that such solutions do not work with serial port GPS that provide a PPS, resulting in far less accurate time synchronization. Maybe the parallel or serial port versions of these devices require access to a physical interrupt line that is not possible when USB is used? Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Tue, 2012-08-28 at 10:14 +0200, Per Jessen wrote:
NTP knows about transmission delays and all that - to be honest, I don't know how accurate it is, I have nothing to compare to. I am not concerned about milliseconds myself, but I suspect that is the level of accuracy achievable.
I have read that inexpensive receivers, like in consumer grade clocks, should be able to achieve 0.1 sec accuracy. Better receivers can do better.
I could be way off, but I don't think it is related to the receiver quality. After all, either you've got a signal or you don't. What is done with the data received is probably more important, and that's where NTP comes in.
But, returning to the thread, would this be the case when a USB adapter is added? I know that such solutions do not work with serial port GPS that provide a PPS, resulting in far less accurate time synchronization. Maybe the parallel or serial port versions of these devices require access to a physical interrupt line that is not possible when USB is used?
Using a PPS is a different solution, but I have also seen people having trouble with USB and PPS sources. -- Per Jessen, Zürich (24.7°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 2012-08-28 at 14:12 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
On Tue, 2012-08-28 at 10:14 +0200, Per Jessen wrote:
NTP knows about transmission delays and all that - to be honest, I don't know how accurate it is, I have nothing to compare to. I am not concerned about milliseconds myself, but I suspect that is the level of accuracy achievable.
I have read that inexpensive receivers, like in consumer grade clocks, should be able to achieve 0.1 sec accuracy. Better receivers can do better.
I could be way off, but I don't think it is related to the receiver quality. After all, either you've got a signal or you don't. What is done with the data received is probably more important, and that's where NTP comes in.
The DCF77 wikipedia entry (correctly?) states that inexpensive receivers typically have a 10 Hz bandwidth, and thus have this limitation. Not sure what that means. For this kind of sync, it is not the frequency of the update, but the accuracy of it when it arrives. This is a bit beyond my expertise.
But, returning to the thread, would this be the case when a USB adapter is added? I know that such solutions do not work with serial port GPS that provide a PPS, resulting in far less accurate time synchronization. Maybe the parallel or serial port versions of these devices require access to a physical interrupt line that is not possible when USB is used?
Using a PPS is a different solution, but I have also seen people having trouble with USB and PPS sources.
By 'Trouble' you mean it does not work. USB cannot propagate the PPS signal with the same accuracy as the serial port. Some don't even look at it. I checked the kernel drivers a while back to see what each USB serial adapter supported. They are geared more to tty control for things like modems. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Tue, 2012-08-28 at 14:12 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
On Tue, 2012-08-28 at 10:14 +0200, Per Jessen wrote:
NTP knows about transmission delays and all that - to be honest, I don't know how accurate it is, I have nothing to compare to. I am not concerned about milliseconds myself, but I suspect that is the level of accuracy achievable.
I have read that inexpensive receivers, like in consumer grade clocks, should be able to achieve 0.1 sec accuracy. Better receivers can do better.
I could be way off, but I don't think it is related to the receiver quality. After all, either you've got a signal or you don't. What is done with the data received is probably more important, and that's where NTP comes in.
The DCF77 wikipedia entry (correctly?) states that inexpensive receivers typically have a 10 Hz bandwidth, and thus have this limitation.
Did you leave out a 'k'? I'm sure the bandwidth is more like 10kHz, but I think that's only of important if you're using the carrier to generate a PPS. See below.
Not sure what that means. For this kind of sync, it is not the frequency of the update, but the accuracy of it when it arrives. This is a bit beyond my expertise.
The 77.5kHz longwave carrier is also highly accurate and can be used to generate a very good PPS signal.
Using a PPS is a different solution, but I have also seen people having trouble with USB and PPS sources.
By 'Trouble' you mean it does not work. USB cannot propagate the PPS signal with the same accuracy as the serial port.
Yup. -- Per Jessen, Zürich (24.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 2012-08-28 at 16:05 +0200, Per Jessen wrote:
The DCF77 wikipedia entry (correctly?) states that inexpensive receivers typically have a 10 Hz bandwidth, and thus have this limitation.
Did you leave out a 'k'? I'm sure the bandwidth is more like 10kHz, but I think that's only of important if you're using the carrier to generate a PPS. See below.
10 Hz is what the wikipedia article says. I also thought it must have been 10 kHz, One uses wikipedia at one's own risk. Gotta double check things.
Not sure what that means. For this kind of sync, it is not the frequency of the update, but the accuracy of it when it arrives. This is a bit beyond my expertise.
The 77.5kHz longwave carrier is also highly accurate and can be used to generate a very good PPS signal.
My question re the original post remains: do these devices use a hardware interrupt line to do a pps? Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Tue, 2012-08-28 at 16:05 +0200, Per Jessen wrote:
The DCF77 wikipedia entry (correctly?) states that inexpensive receivers typically have a 10 Hz bandwidth, and thus have this limitation.
Did you leave out a 'k'? I'm sure the bandwidth is more like 10kHz, but I think that's only of important if you're using the carrier to generate a PPS. See below.
10 Hz is what the wikipedia article says. I also thought it must have been 10 kHz, One uses wikipedia at one's own risk. Gotta double check things.
Not sure what that means. For this kind of sync, it is not the frequency of the update, but the accuracy of it when it arrives. This is a bit beyond my expertise.
The 77.5kHz longwave carrier is also highly accurate and can be used to generate a very good PPS signal.
My question re the original post remains: do these devices use a hardware interrupt line to do a pps?
Yes they do. (well, I don't see how else it would be done with any reasonable accuracy). -- Per Jessen, Zürich (22.3°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
My question re the original post remains: do these devices use a
hardware interrupt line to do a pps? Yes they do. (well, I don't see how else it would be done with any reasonable accuracy).
Same as NTP. Determine the average. Over the short term, accuracy can be very bad, but good when averaged over the long term. That even applies to electric wall clocks. The power line frequency can drift slightly in the short term, but long term it's very accurate. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
Per Jessen wrote:
My question re the original post remains: do these devices use a
hardware interrupt line to do a pps?
Yes they do. (well, I don't see how else it would be done with any reasonable accuracy).
Same as NTP. Determine the average. Over the short term, accuracy can be very bad, but good when averaged over the long term.
A PPS signal is always precise. If you can't read it in a deterministic way, the advantage of having it is gone. -- Per Jessen, Zürich (21.3°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
A PPS signal is always precise. If you can't read it in a deterministic way, the advantage of having it is gone.
Are you familiar with phase locked loops? They're often used to take an unstable signal and make it stable. The function includes LaPlace transforms and such, but does a good job of creating a stable signal. Stability is a function of lock time, so if you want a accurate interval, just give it plenty of time to stabilize. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
Per Jessen wrote:
A PPS signal is always precise. If you can't read it in a deterministic way, the advantage of having it is gone.
Are you familiar with phase locked loops? They're often used to take an unstable signal and make it stable.
Yes, I know what PLLs are.
The function includes LaPlace transforms and such, but does a good job of creating a stable signal. Stability is a function of lock time, so if you want a accurate interval, just give it plenty of time to stabilize.
Completely agree, but in a situation where you have a stable and very precise signal (the PPS), if you can't interface with it properly, there's no point in using it. -- Per Jessen, Zürich (20.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 2012-08-28 at 19:53 +0200, Per Jessen wrote:
James Knott wrote:
Per Jessen wrote:
A PPS signal is always precise. If you can't read it in a deterministic way, the advantage of having it is gone.
Are you familiar with phase locked loops? They're often used to take an unstable signal and make it stable.
Yes, I know what PLLs are.
The function includes LaPlace transforms and such, but does a good job of creating a stable signal. Stability is a function of lock time, so if you want a accurate interval, just give it plenty of time to stabilize.
Completely agree, but in a situation where you have a stable and very precise signal (the PPS), if you can't interface with it properly, there's no point in using it.
And, RE the original post, a USB adapter cannot correctly propagate the PPS signal. The most is that information about a line change is encoded in the driver's data and sent along in a USB packet. When this arrives at it's destination is very non-deterministic. Note that not all USB converters seem to do this. For example, the pl2303-driver does, while others do not. Seems all are not equal. So, perhaps the first step is to see which hardware is in the USB adapter. Then see if the kernel driver deals with the line providing the PPS signal. Which chipset is in the USB adapter?
-- Per Jessen, Zürich (20.4°C)
Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 28 Aug 2012 11:22:21 +0200, Roger Oberholtzer
But, returning to the thread, would this be the case when a USB adapter is added?
Forget USB! ntpd needs a clock that can trigger an interrupt which USB AFAIK does not have. That's why any USB device is useless, at least according to the ntpd developers. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 2012-08-31 at 02:09 +0200, Philipp Thomas wrote:
Forget USB! ntpd needs a clock that can trigger an interrupt which USB AFAIK does not have. That's why any USB device is useless, at least according to the ntpd developers.
+1 It is getting to be a less common finding serial ports on MBs :) Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
NTP knows about transmission delays and all that - to be honest, I don't know how accurate it is, I have nothing to compare to. I am not concerned about milliseconds myself, but I suspect that is the level of accuracy achievable.
Is NTP over the Internet not suitable? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
Per Jessen wrote:
NTP knows about transmission delays and all that - to be honest, I don't know how accurate it is, I have nothing to compare to. I am not concerned about milliseconds myself, but I suspect that is the level of accuracy achievable.
Is NTP over the Internet not suitable?
Yes, absolutely but as I had the DCF77 receiver anyway I went with that. I have in fact two internet stratum 2 peers configured too. -- Per Jessen, Zürich (24.8°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Yes, absolutely but as I had the DCF77 receiver anyway I went with that. I have in fact two internet stratum 2 peers configured too.
Well, if you still want to use that receiver, then I guess your only option is to get a parallel port card for your computer. I think I have one here for the old ISA bus. ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
Per Jessen wrote:
Yes, absolutely but as I had the DCF77 receiver anyway I went with that. I have in fact two internet stratum 2 peers configured too.
Well, if you still want to use that receiver, then I guess your only option is to get a parallel port card for your computer. I think I have one here for the old ISA bus. ;-)
The OP had a problem with a USB parallel port, my old fashioned serial setup is working fine :-) -- Per Jessen, Zürich (24.5°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Von: Per Jessen
An: opensuse@opensuse.org CC: Gesendet: 14:39 Dienstag, 28.August 2012 Betreff: Re: [opensuse] DCF77, USB <-> parallel adapter, any solution?
...
The OP had a problem with a USB parallel port, my old fashioned serial setup is working fine :-)
Actually it is a problem of hardware, drivers: the hardware seems to be geared to usb <-> parallel solutions for printer and therefore also the drivers seem to be missing the parts which are needed for the DCF77 Conrad Parallel clock. E.g. the DeLock adapter makes the following entry in the logfiles when attaching to USB: Aug 29 00:59:39 mymachine kernel: [13805.322787] usb 2-1.4.7: new full speed USB device number 6 using ehci_hcd Aug 29 00:59:39 mymachine kernel: [13805.408698] usb 2-1.4.7: New USB device found, idVendor=0fe6, idProduct=811e Aug 29 00:59:39 mymachine kernel: [13805.408703] usb 2-1.4.7: New USB device strings: Mfr=0, Product=2, SerialNumber=0 Aug 29 00:59:39 mymachine kernel: [13805.408706] usb 2-1.4.7: Product: IEEE-1284 Controller Aug 29 00:59:39 mymachine mtp-probe: checking bus 2, device 6: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.7" Aug 29 00:59:40 mymachine mtp-probe: bus: 2, device: 6 was not an MTP device Aug 29 00:59:40 mymachine udev-configure-printer: add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.7/2-1.4.7:1.0 Aug 29 00:59:40 mymachine udev-configure-printer: device devpath is /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.7 Aug 29 00:59:40 mymachine udev-configure-printer: Device vendor/product is 0FE6:811E Aug 29 00:59:40 mymachine kernel: [13805.497056] usbcore: registered new interface driver usblp But I do not know how I get the /dev/pcfclock0 /dev/pcfclock1 /dev/pcfclock2 working together with this. mknod -m 444 /dev/pcfclock0 c 181 0 mknod -m 444 /dev/pcfclock1 c 181 1 mknod -m 444 /dev/pcfclock2 c 181 2 was the way when using it with the older parallel plugin and the pcfclock program (which is currently pcfclock-0.44-250.1.2.x86_64.rpm). One suggested NTP - I know that already. ;-) But I want the former solution to work somehow. Other ways: more expensive hardware like e.g.: http://www.lindy.de/netzwerk-timeserver/20988.html -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Peter Maffter wrote:
Von: Per Jessen
An: opensuse@opensuse.org CC: Gesendet: 14:39 Dienstag, 28.August 2012 Betreff: Re: [opensuse] DCF77, USB <-> parallel adapter, any solution?
...
The OP had a problem with a USB parallel port, my old fashioned serial setup is working fine :-)
Actually it is a problem of hardware, drivers: the hardware seems to be geared to usb <-> parallel solutions for printer
Okay. This is clearly a problem.
and therefore also the drivers seem to be missing the parts which are needed for the DCF77 Conrad Parallel clock.
Typically such drivers are supplied by the NTP project, but if you're not using that, maybe you need kernel support. IIRC, the kernel does have a few drivers for weird and wonderful parallel port hardware. What software are you using?
Aug 29 00:59:39 mymachine kernel: [13805.322787] usb 2-1.4.7: new full speed USB device number 6 using ehci_hcd Aug 29 00:59:39 mymachine kernel: [13805.408698] usb 2-1.4.7: New USB device found, idVendor=0fe6, idProduct=811e Aug 29 00:59:39 mymachine kernel: [13805.408703] usb 2-1.4.7: New USB device strings: Mfr=0, Product=2, SerialNumber=0 Aug 29 00:59:39 mymachine kernel: [13805.408706] usb 2-1.4.7: Product: IEEE-1284 Controller
So, a printer controller.
Aug 29 00:59:39 mymachine mtp-probe: checking bus 2, device 6: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.7" Aug 29 00:59:40 mymachine mtp-probe: bus: 2, device: 6 was not an MTP device Aug 29 00:59:40 mymachine udev-configure-printer: add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.7/2-1.4.7:1.0 Aug 29 00:59:40 mymachine udev-configure-printer: device devpath is /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.7 Aug 29 00:59:40 mymachine udev-configure-printer: Device vendor/product is 0FE6:811E Aug 29 00:59:40 mymachine kernel: [13805.497056] usbcore: registered new interface driver usblp
I guess this isn't of much use to you as your Conrad clock doesn't speak IEEE-1284.
But I do not know how I get the /dev/pcfclock0 /dev/pcfclock1 /dev/pcfclock2 working together with this. mknod -m 444 /dev/pcfclock0 c 181 0 mknod -m 444 /dev/pcfclock1 c 181 1 mknod -m 444 /dev/pcfclock2 c 181 2 was the way when using it with the older parallel plugin and the pcfclock program (which is currently pcfclock-0.44-250.1.2.x86_64.rpm).
Have you loaded the pcfclock module? Try that and tell us what it says. I would unload any other module related to the parallel port.
One suggested NTP - I know that already. ;-) But I want the former solution to work somehow. Other ways: more expensive hardware like e.g.: http://www.lindy.de/netzwerk-timeserver/20988.html
If you have a DCF77 receiver that works with NTP, you can make that yourself. Much cheaper. -- Per Jessen, Zürich (21.7°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/27/2012 3:52 PM, Peter Maffter wrote:
My new machine has no parallel port. I tried several USB <-> Parallel adapters (like the DeLock USB910) but they all failed. Some people posted on the net that these are only printer adapters. Is an internal parallel card an option?
Damon Register -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Von: Damon Register
An: opensuse@opensuse.org CC: Gesendet: 12:12 Dienstag, 28.August 2012 Betreff: Re: EXTERNAL: [opensuse] DCF77, USB <-> parallel adapter, any solution?
On 8/27/2012 3:52 PM, Peter Maffter wrote:
My new machine has no parallel port. I tried several USB <-> Parallel adapters (like the DeLock USB910) but they all failed. Some people posted on the net that these are only printer adapters. Is an internal parallel card an option?
If all fails: yes. But the machine is quite "full" already with only one PCI slot free. Internal PCI Parallel card like: http://www.sunix.com.tw/product/par5008r.html or http://www.sunix.com.tw/product/par5008d.html ? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (6)
-
Damon Register -
James Knott -
Per Jessen -
Peter Maffter -
Philipp Thomas -
Roger Oberholtzer