Re: get signals from parallel port

[Ernst B. <e.b...@xe...>]

On Wednesday 13 September 2006 16:10, you wrote:
> Hi,
>
> thanks for your quick reply. :)
>
> But I'm afraid I don't get much of what you said. I'll try to be as
> specific as possible in telling you what parts I don't understand.
>
> "Well, for one, the most homebrew receivers don't decode the 40kHz
> modulated signal, they use premade receiver modules (like the TSOP17xx
> series), which implement demodulation, Automatic Gain Control and
> conversion to TTL all in one chip.
>
> Therefore the resolution needed by the OS drivers is much lower, maybe in
> the
> range 1/1000th second."
> I am using this: http://www.geocities.com/SiliconValley/Lakes/7156/ , it
> also has a sender part, but I'm only using the receiver part.

> Then you say that they're using 'demodulation, AGC and TTL' , but I have =
no
> idea what these exactly mean, and therefore I also have no idea why the
> resolution needed by the drivers would be lower than the resolution in
> which the signals are transmitted.

The schematic available at the link above doesn't look like it will ever wo=
rk=20
reliable with a TV remote or similar.
Its missing the demodulation part (much higher CPU requirements) and the AG=
C=20
part (no reception with sunlight through the window, CRT or TV near the=20
receiver, etc)

"demodulation" in this context means: instead of outputting pulses with 40k=
Hz,=20
the TSOP17xx would output 5V for "40kHz signal detected" and 0V for "no=20
signal detected"

"AGC" means: the receiver module has an amplifier, and modifies its=20
sensitivity such that all the static noise is ignored, but the signal is=20
still amplified as much as possible. Hence you can receive at a much larger=
=20
distance, and it will even work near a window or CRT.=20


> "Then, the drivers use an IRQ Pin of the port, and have a (kernel mode)
> driver,
> doing the timing measurements in the interrupt service routine.
> (using polling to detect the falling edge)"
>
> How would I make such a driver? I ran into a few examples how to do this =
in
> C++ for a QNX real time system,
> http://psy.swansea.ac.uk/staff/Carter/QNX/tut_nto_parpoll.htm ,
> http://psy.swansea.ac.uk/staff/Carter/QNX/tut_nto_parintr.htm , and I can
> understand that code a bit, but not enough to convert that to a windows
> kind code.

No idea about windows driver development. Maybe start digging through the m=
sdn=20
knowledge base, or look for some windows open-source project using a own=20
driver.

> "I'm not that familiar with the Windows driver model, but you'll probably
> also
> need a kernel mode driver there to deal with the tight timing requirements
> and to get access to the interrupts."
>
> Unfortunately, I am also not familiar with Windows driver model, or with
> any driver model in general, sorry. But again, how would I make such a
> driver then and how could I get access to the interrupts?

Again, sorry. Can't help you here.

> "If you want an easy solution, use a small microcontroller (TinyAVR, small
> PIC
> or the like), and do all the time critical stuff there, and just transfer
> the
> measured data over your port.
>
> Sure, you'll need to program a uC to do that, but compared with the work
> needed on your windows device driver, it still seems like the easier
> solution."
>
> What's an uC? And another more easier solution would be to just install
> Linux and use Lirc, but since I'm more doing this as a 'fun' project, I'd
> rather use Windows for it. And by making my own I also learn a lot more
> from it than when I just use a program.

uC is short for "microcontroller", the "u" part should acually read "=C2=B5=
".
But if you're just starting with electronics, using a =C2=B5C might be a bi=
t tough=20
for the beginning.
Maybe look at the "homebrew parallel port receiver" on the lirc homepage, i=
ts=20
schematic looks a bit better, but would still require a quite time-critical
timer.


> Again, thanks for your help. I really appreciate it you are putting some =
of
> your time into helping me. But since I'm kinda new to hardware stuff, I
> need pretty detailed information before I really understand it, so I'm
> sorry I didn't understand everything in your mail.

No problem, but please send your replies to the mailing-list, not directly =
to=20
me. That way the next one with similar questions might find his answer in t=
he=20
archives.

/Ernst