IR wireless presenter

[Rohit de Sa]

Hey all,

I was thinking of making a simple and cheap infrared wireless presenter to control slide shows on my laptop. I have the following in mind:

(Cheap Sony IR remote) --> (TSOP1738) --> (PIC18F2550) --> (USB HID keyboard/mouse device) --> (Control powerpoint slides)

Here in India I can build the whole thing for less than INR250 (USD5). Everything including the IR remote and the PIC are included in this cost.

Now I've got the remote to work with the TSOP and a 12F675 decoding the IR data, so it won't be too difficult to port this to a '2550. Separately, I've got the HID keyboard/mouse demo program included with CCS to work fine. So its a matter of combining these two.

I've got a rough idea of what I want my code to look like, but I needed help on something: would it be smart to put an ASM 'pop' statement in the code? This greatly reduces my work, and also seems to make the code run faster, but will it interfere with USB communications? (USB interrupts?)

My basic problem is that I would like to return to a specified address after the timer1 interrupt. Is this advisable with USB running onboard?

Sorry if the question sounds vague; here's some pseudo code to help:

[Rohit de Sa]

I've managed to build the presenter, and it seems to be working ok.....well almost ok. I'm having problems with the USB keyboard part. I'll just give you a bit of a quick overview of what works and what doesn't. The timer and IR parts work perfect, no problems at all. The USB enumerates fine and sends the character. The problem crops up here. I would like that when I press a key on the remote once, only one character is transmitted. I get an unending string of characters (I'm using Notepad to see the output). When I press a different key on the remote the character changes, but again, a never-ending string. Only when I press the power button on the remote (I've set this to give me a USB keyboard char of 0x00) does the string stop.

Any suggestions on how I can output just one character per button press?

I guess the problem is in function send_usb().

I'm using an 18F2550 with the Microchip PICDEM FSUSB bootloader. CCS compiler is 4.068, used in MPLABv8.14 . USB code lifted from ex_usb_kbmouse2. The descriptor file remains unmodified.

[Rohit de Sa]

Oh, some of the code is newbie-style code Suggestions to improve it, please? Thanks.

Another thing, I'm actually directly messing with the hardware stack, as can be seen in the timer1 ISR. Is this 'good code', or can I avoid doing this? I haven't encountered problems by doing this, and I don't (more like can't ) foresee any trouble. Comments?

Rohit

[Rohit de Sa]

I think I have a possible solution, but I'm at work and hence can't try it out. Will do so when I go home.

Right after I do a send_usb() I think I need to add another usb_put_packet() after a short delay, say 5ms. The first send_usb() sends out a 'make' (in PS/2 terms), so I would need to send the USB equivalent of a PS/2 'break'. This 'break' happens to be a 0x00.

Is this reasoning correct?

Rohit

[Rohit de Sa]

It was exactly what I had thought! I needed to send a 'break' signal after each key. So the way to send a single character is:
(send hex value)
(wait)
(send 0x00, no event)

The modification is concerned with the last part of the code:

[kd5uzz_home]

I love the documentation. I'm glad you got it to work. I hope to use what I've learned from you in an upcomming project. Just letting you know someone IS watching/reading what you write!

[Rohit de Sa]

Hey thanks! For a while I was thinking that I was out here on my own! Glad to know that my code will be of help to you. I'm still making a few changes to the code, trying to see if modifying this, and adjusting that works. You are free to use the code or any part of it without permission (naturally, since I've posted it on an open forum! ). But an acknowledgment in the form of details or a link to your project would be nice. All the best with your project!

Rohit

[Rohit de Sa]

Here is the full code, working properly. Please feel free to use, modify and redistribute the code. It would be nice if you can give my name a mention , but no compulsions. A word of caution - I will not be responsible if you mess up your PC or anything else in the process of making this project, though I doubt strongly that this will happen, since my PC is working fine.

As of now, only the keyboard part of it has been implemented. Since my project uses ex_kbmouse2.c as the reference, future plans are to remove the redundant mouse descriptors that tag along with the project. This may create a more compact project.

Another modification is to keep the mouse descriptors and add mouse support to the IR remote. This will be a nice touch.

Finally, I will be porting this whole project from IR to RF. This will require extensive code and hardware modification. For this, I'm thinking of using the RX/TX433 pair and maybe an accelerometer for mouse functionality. But these are long term plans.

So, the code:
edit
(for some reason BB code never accepts TABs, so all my comments are messed up and on different lines; here's a link to the text file which has slightly better formatting http://docs.google.com/Doc?id=dfq25rp8_46wkr88g5g The next update will be a pdf print from MPLAB ).
edit

[kd5uzz_work`]

lynx has some very good 433mhz modules ~$30 for a pair, IIRC. Although not as compact another option would be XBee modules, ~$20 each. Lynx uses one chip for TX, another for RX. XBee uses one chip for both.

WindowsXP also has an option for (I think..) serialkeys. It allows the OS to accept keyboard/mouse input from the serial port (I think a USB HID device is the better option, just throwing it out there).

[Rohit de Sa]

[Rohit de Sa]

Andrew, who mailed me, had the following doubt, which I'm posting for the benefit of others:

[Andrew83]

Hello Rohit !

I have another question about your code.
I am trying to decode a REC80 IR protocol. The transmission consists of a header and 32 individual bits.
Now ... I've managed to succesfully detect the header of the transmission but for some reason I am unable to decode the entire code.

So ... I am using pic18f452, 4.4MHz clock, CCS C version 4.057 and a TSOP1738 IR receiver module.

From http://www.vishay.com/docs/80071/dataform.pdf I've got the following information :
- header : 9 ms-high and 4,5 ms low
- representation of a "1" :2,25 ms high
- representation of a "0" :1,125 ms low

Here is my variant of the code you so generously posted (I'm posting just the detection part of the code):

[Rohit de Sa]

Andrew,

The pdf link you posted has no description of the REC80 protocol. From my googling I've come to realize that this is a very old protocol. http://www.sbprojects.com/knowledge/ir/recs80.htm has a good description of the protocol specifics, but the funny thing is that they differ from your timing values. I just wanted to confirm the protocol that you are using - is it the RECS-80 protocol, or the NEC protocol?

According to the link I posted above, there may be one or two toggle bits in the pulse train to perform key debouncing. This may be the reason why the code works without the header. I'm not at all familiar with the RECS-80 protocol, so maybe if you have a logic analyzer or oscilloscope you could post a picture of the IR data waveform.

According to the timing specifications you have given me, the protocol looks like the NEC protocol. But as per this protocol, a bit1 is 560us high followed by 1690us low (2.25ms in total), and a bit0 is 560us high followed by 560us low (1.12ms in total). The header is, as you mentioned 9ms high followed by 4.5ms low ( http://www.sbprojects.com/knowledge/ir/nec.htm ).

You mentioned that you would be decoding 32 bits of data. The NEC code has 8 address bits (transmitted LSB first) twice, followed by 8 data bits (also transmitted LSB first) twice. The double transmission give data reliability, but more importantly, 8+8+8+8 bits = 32 bits. So it seems to me like you are using the NEC protocol. There is also the extended NEC protocol, which you can go through on the link.

Remember, the TSOP data output will be inverted. When the IR LED is not transmitting, the TSOP output will idle HIGH. You would like to start decoding the IR signal the instant and IR pulse is received. An IR signal will cause the TSOP to pull low. That is why to detect the header you will ask the PIC to stay in the while((input(tsop))); until the output swings low. The PIC will jump out of this instruction and then continue processing.

If you confirm the protocol you are using, I'll have a detailed look at the code.

Rohit

[Andrew83]

I think i have a possible solution for my problem.....i think that if i use a "if-then" instead of the "for" i might catch the pulses in time. But this solution poses another challenge for me: assembler code.

So...i will try this solution...and hopefully detect does nice bits !

[Andrew83]

Ok ! Sorry for the mixup Rohit ! I am using the NEC protocol ! When i've written the post, i was looking in a book about IR commnunications and i've made a mistake.
The protocol is definately NEC! Sorry ! My bad...these things are kind'a new to me!

Thank you again !!!