From: Martin T J. <ma...@br...> - 2011-12-02 17:34:29
|
On 22/11/11 14:27, vaton wrote: > But another problem here, this time with the parport layer. > If I compare results of the pulse-space timing measurements made using > lirc_audio driver > with results got using modified lirc_parallel driver, difference is > striking. While pulse-space measurements > made by lirc_audio differ are unbelievably precise (+/- 10us), measurements > based on the parport interrupt are almost unacceptable. See the following > example: > > Pulse widths recorded using audio driver: > > 458 458 479 458 458 458 458 458 479 458 458 458 458 > 458 458 479 458 458 458 458 458 458 479 458 458 458 458 > This is because the audio hardware samples the demodulated IR signal; Sample period at 48kHz is 20.8us, 479 - 458 = 21. The audio driver transfers the data which is buffered by the hardware so interrupt response time does not effect the timing measurements. > and recorded using parallel& lirc_dev driver (same remote and button, > sorted by value): > > 658 636 633 608 576 546 518 514 501 498 497 497 495 > 493 493 493 493 493 492 492 491 491 487 444 442 381 332 > > This makes decoding very unreliable. Without increasing eps and aeps in the > lirc.conf > almost all button presses fail. Even with eps=50 and aeps=150 many presses > fail. > > Would somebody help with this? > May be some tweak of the parport params will improve parport interrupt > jitter ?? > Or there is some way to bypass parport and use parallel port hardware > directly ?? > > If you plot your parallel port data you will see the most common values are just under 500us (493). The difference from the audio driver values suggests that the audio hardware is actually sampling at 44kHz and the driver is calculating times based on a 48kHz sample rate. The worst jitter in the samples above is +165us & -161us a substantial amount of processing time for a CPU running at a few GHz! This probably means the parallel port interrupt is being masked by a higher priority one is the problem worse when there is lots of disk or network activity for example. The only guaranteed method is to time the pulses using hardware and transfer the result on each interrupt. Martin |