From: Karl B. <ka...@tu...> - 2002-05-22 16:06:33
|
Hi IR fans, Heres some more of my notes. Hopefully it explains what I am trying to do with micros better. The neat thing about microprocessor based is that it has the capability to do a lot of things. It is flexible. Most users they would not want to mess with programming AVR's, but you don't need an external programmer and it costs virtually nothing to make it programmable from the serial port. AVR's need 3 control signals to program it, all available from the PC(DTR,RTS,CTS). I just think it would be a wonderful toy for the hardware/software hobbiest. You might as well bring these control lines over to the PC anyway. That's how I program AVR's is just hooking them right up to printer port lines(5 wires). Other people have done it on RS232 lines. There are existing IR-control micro designs that draw power from the serial port. This limits the things you can do with it same as the home-brew. USB has power, and this micro-implementation would make a full implementation of LIRC over USB possible. When I say full implementation, I mean it can "learn"(return the raw signal). This is in comparison to the pre-processed codes available from most commercial smart hardware. And it will be cheap. If we can get the protocol down to a small frame, then a $2.00 microprocessor can be used. The micro-implentation tries to formalize a compact protocol suitable for routing over simple communication pipes. Once it is implemented on a serial port it could be easily transferred to USB, Ethernet, Firewire, I2C, whatever. I want hardware that gives the "real" raw signals. I can go buy a smart Logitech unit with remote-control on Ebay for $10-$15. But, it gives me only pre-processed codes for that remote. That may be fine for a lot of people, but I really value the ability to record actual signals. Kernel driver not required. - This allows for a portable design. Without messy kernel stuff, it could be compiled on BSD/Solaris/Windows as easy as Linux. LIRC has this split personality. Half of it is kernel driver based, the other half is user-mode applications. Personally, I think it might be best to split the two up so that the average user does not have to know how to compile their kernel or the user mode stuff could be used on other platforms. If we every want the drivers to be accepted into the Linux kernel base then it should be arranged this way. The kernel base does not include all the user-mode stuff, but it does include drivers. Karl. |
From: Stephen D. <st...@da...> - 2002-05-22 19:14:57
|
Hi, You are aware of the Redrat, www.redrat.co.uk - an existing microcontroller-based IR receiver/transmitter? Steve On Wed, 22 May 2002, Karl Bongers wrote: > The neat thing about microprocessor based is that it has > the capability to do a lot of things. It is flexible. |
From: David N. <jud...@ad...> - 2002-05-23 16:27:38
|
Is the Redrat supported by LIRC? Are there any commercial transmitters supported? ----- Original Message ----- From: "Stephen Davies" <st...@da...> To: "Karl Bongers" <ka...@tu...> Cc: <lir...@li...> Sent: Wednesday, May 22, 2002 12:14 PM Subject: Re: Why I want to make microprocessor based protocol. > Hi, > > You are aware of the Redrat, www.redrat.co.uk - an existing > microcontroller-based IR receiver/transmitter? > > Steve > > On Wed, 22 May 2002, Karl Bongers wrote: > > > The neat thing about microprocessor based is that it has > > the capability to do a lot of things. It is flexible. > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > |
From: <col...@hi...> - 2002-05-25 19:06:35
|
Hi! David Norwood "jud...@ad..." wrote: > Is the Redrat supported by LIRC? No, but there is an other Linux package, that supports the Redrat. Christoph |
From: Karl B. <ka...@tu...> - 2002-05-23 13:26:03
|
I took a look, thanks for the link. It is interesting to see what other people are doing. Redrat device receives the raw unmodulated signal to avoid problems with different modulations. Their focus is on accurate IR learning and transmit control. I guess there is no way to get around the variety in implementation of this stuff. One size does not fit all. I did get some micro code to transmit last night. I used the same run-length encoding protocol used in the receive. The AVR2313 micro has 128 bytes of RAM, just barely enough to receive a full packet of typical IR with this encoding. I figure its a good start. Karl. On Wed, May 22, 2002 at 08:14:51PM +0100, Stephen Davies wrote: > Hi, > > You are aware of the Redrat, www.redrat.co.uk - an existing > microcontroller-based IR receiver/transmitter? > > Steve > > On Wed, 22 May 2002, Karl Bongers wrote: > > > The neat thing about microprocessor based is that it has > > the capability to do a lot of things. It is flexible. |
From: Bill P. <goa...@ya...> - 2002-05-23 21:01:08
|
Hey Karl, I think it's a great idea. RedRat is nice but no way in h*ll I'm payin $130 for an IR device. Much less one that may or may not work as a receiver across the room (it was intended to receive well enough to record your remotes... 2-3m I think it's specified as) As for what uC you go with, self-programming is the important part. It's a fine line between making a 10 minute project and building a programmer that costs $40. (that they'll use once) No instead of suggesting redrat, I'll suggest you check out van Gessel's UIRT for ideas... self-programming PIC implementation. (hey does lirc support? :-) B. ------- --- Karl Bongers <ka...@tu...> wrote: > I took a look, thanks for the link. It is > interesting to see > what other people are doing. Redrat device receives > the raw > unmodulated signal to avoid problems with different > modulations. > Their focus is on accurate IR learning and transmit > control. > > I guess there is no way to get around the variety in > implementation > of this stuff. One size does not fit all. > > I did get some micro code to transmit last night. I > used > the same run-length encoding protocol used in the > receive. > The AVR2313 micro has 128 bytes of RAM, just barely > enough to > receive a full packet of typical IR with this > encoding. > I figure its a good start. > > Karl. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
From: Bill P. <goa...@ya...> - 2002-05-23 21:04:02
|
Hey Karl, I think it's a great idea ALSO if I don't waste bandwidth embarassing myself by forgetting urls.. http://people.a2000.nl/rwvgesse/Uirt.htm B. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
From: Matthias R. <mat...@ak...> - 2002-05-23 15:23:29
|
Hello Karl, I really appreciate your effort of getting a mcu based ir control to run. In particular, I like the idea of having a protocol to help a USB version started ( I'm a happy mac user and serial ports are almost as expensive as a usb ir controller like the one from keyspan) I have some experience using microchips pics controllers (16F84, 876, 877). I also tried a national semiconductor usb controller but failed ( it was in the beginng ... ). It looks like the Philipps USB controller is used in most devices, e.g.Visor. I think Atmel even has some mcu with build-in USB. I spent some time compiling lirc on mac os x. I got it compiled, but I can't use it as none of the drivers are suitable for me. I don't think serial port control flags as i/o pins work over a USB-2-Serial adapter, the same is with USB-2-Parallel adapters. ( I didn't tried any of those two) I tried connecting the IR Receiver to my soundcard. So far, the data gathered there is good enough for evaluation and detecting the length of pulses and pauses. I just didn't continue the decoder. I hope I will soon. Something else, What is with the IrMan, that was on the lirc.org page. it used a simple mcu and was free to use. When I had a look at it, I missed the actual source code for the controller. Concerning the protocol. The assumption of redrat, that there are only a distinct number of different time lengths makes sense AFIK. So a packet format that specifies the ir burst frequency and a nr of timelength could reduce the nr of transmitted data significant. Then even a long command should fit into the mcu ram. (the pic 16f84 has 68 bytes.. ) Do you know, how much pulse/pause transitions the longest ir command has ? Other options, you could use hardware flow control and stick to the simple run-lenght encoding you used. This provides a wide flexibility. hardware flow control is available on almost any uart, works on USB ( I think the host has to pause somehow.. :( ) or whatever. Maybe you could reserver one code for transmission of control data like ir frequency. So I (morally) support the division between low-level drivers and high-level signal processing for detection. But I'm not going to build something in the next time. Matthias Ringwald |