Ok, I'll try to get that working then.
Sorry that I sent the mail to you directly instead of to the mailing list; I just hit the reply button to your message and it replied to you instead of to the mailing list. I'll bear that in mind for future mails.
Thanks for your help :)
On 9/13/06, Ernst Bachmann <firstname.lastname@example.org> wrote:
On Wednesday 13 September 2006 16:10, you wrote:
> 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
> 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 work
reliable with a TV remote or similar.
Its missing the demodulation part (much higher CPU requirements) and the AGC
part (no reception with sunlight through the window, CRT or TV near the
"demodulation" in this context means: instead of outputting pulses with 40kHz,
the TSOP17xx would output 5V for "40kHz signal detected" and 0V for "no
"AGC" means: the receiver module has an amplifier, and modifies its
sensitivity such that all the static noise is ignored, but the signal is
still amplified as much as possible. Hence you can receive at a much larger
distance, and it will even work near a window or CRT.
> "Then, the drivers use an IRQ Pin of the port, and have a (kernel mode)
> 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_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 msdn
knowledge base, or look for some windows open-source project using a own
> "I'm not that familiar with the Windows driver model, but you'll probably
> 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
> or the like), and do all the time critical stuff there, and just transfer
> 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
> 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 "µ".
But if you're just starting with electronics, using a µC might be a bit tough
for the beginning.
Maybe look at the "homebrew parallel port receiver" on the lirc homepage, its
schematic looks a bit better, but would still require a quite time-critical
> 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
me. That way the next one with similar questions might find his answer in the