Ok, I'll try to get that working then.
Sorry that I sent the mail to you directly instead of to the mailing list; =
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 <e.bachmann@...> wrote:
> 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
> > the
> > range 1/1000th second."
> > I am using this: http://www.geocities.com/SiliconValley/Lakes/7156/ , i=
> > 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 hav=
> > 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
> reliable with a TV remote or similar.
> Its missing the demodulation part (much higher CPU requirements) and the
> part (no reception with sunlight through the window, CRT or TV near the
> receiver, etc)
> "demodulation" in this context means: instead of outputting pulses with
> the TSOP17xx would output 5V for "40kHz signal detected" and 0V for "no
> signal detected"
> "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
> 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)
> > 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 thi=
> > 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
> > 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
> 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
> > also
> > need a kernel mode driver there to deal with the tight timing
> > and to get access to the interrupts."
> > Unfortunately, I am also not familiar with Windows driver model, or wit=
> > 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,
> > PIC
> > or the like), and do all the time critical stuff there, and just
> > the
> > measured data over your port.
> > Sure, you'll need to program a uC to do that, but compared with the wor=
> > 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,
> > 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 "=B5"=
> But if you're just starting with electronics, using a =B5C might be a bit
> for the beginning.
> Maybe look at the "homebrew parallel port receiver" on the lirc homepage,
> schematic looks a bit better, but would still require a quite
> > Again, thanks for your help. I really appreciate it you are putting som=
> > 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 directl=
> me. That way the next one with similar questions might find his answer in