PDA

View Full Version : How to read IRDA data from cell phones ?



serandre
- 3rd April 2006, 15:24
Is there any code to get/send data from a cell phone (Nokia 6600) via a IR link ?

Thanks

Funky Gibbon
- 3rd April 2006, 18:25
Not off the top of my head, but have a look at the link below, there are many papers written on the subject

http://www.irda.org/

flotulopex
- 12th July 2008, 11:03
Hello,

I'm wondering if anyone already tried to use IrDA "OBEX" (OBject EXchange protocol) or "Point And Shoot" to send some data from a cellphone to a PIC.

I could find some interresting stuff, especially these documents:
http://www.irda.org/associations/2494/files/Publications/Physical%20Basics.pdf
http://www.irda.org/associations/2494/files/Publications/Protocol%20Basics.pdf.
http://netwinder.osuosl.org/pub/netwinder/docs/nw/irda/Point%20and%20Shoot%20v1p0.pdf

Amongst all IR protocols, OBEX and "Point And Shoot" look to be the ones to use for data transfer in this situation.

It may appear simple in the docs, but simple doesn't always mean easy.

So if anyone used this before and could share some info, it would be welcome.

NB: my goal is to find a way to update a PIC's program without having to connect it via wires nor using a particular programmer (thus my idea: use a cellphone).

gringobomba14
- 27th July 2008, 10:59
Roger (from the French part of Switzerland)

What PIC are you planning on using? How are you planning on getting the update in to your cellphone? MOST phones (including Nokia) don't like to receive file extensions they don't know about (for security) so generally receive them and hide them, or reject them. You COULD make a MASTER programmer which uses IrDA or RF or whatever, and then you won't have to worry about the complexities of having different chipsets trying to chat with eachother.

ALSO remember that if YOU can use a cellphone to upgrade a PIC using "point and shoot" (I assume you are looking for some kind of commercial application) then I can use a cellphone to rob your information, AND I can use a cellphone to sabotage YOUR product.

flotulopex
- 28th July 2008, 15:43
I'm not making money with my gadgets; I leave this up to far more qualified people than me ;)

Security is not an issue since my circuit is an ir-remote (only simple-minded people are willing to hack a TV or DVD remote signal, no?)

The remote has to "learn" the ir pattern from an original remote. Instead of having to learn it that way, I thought it would be interresting, if you'd have lost the original remote, still to be able to send the original pattern to my remote.

Grabbing around the web, I could find some interresting infos on this excellent site http://www.lirc.org/ with a lot of details about the different ir patterns used in today's remotes. I could use some of them and transmit them via a mobilephone to my remote.

I don't need any transmission protocol; I would like the phone to send the ir-pattern like a remote would do. I found some softwares and will test them shortly.

Btw, I'm using a 16F88.

gringobomba14
- 28th July 2008, 16:52
Actually sounds like a good project to me Roger. Let us know how you get on. How do you propose to write the data to the PIC once the IR data has been received?

skimask
- 28th July 2008, 18:40
Actually sounds like a good project to me Roger. Let us know how you get on. How do you propose to write the data to the PIC once the IR data has been received?
I tried to do a thing awhile back where I saved the data to an eeprom first, then re-wrote over myself while I was running, take extra special care to keep the region where my 'overwriting' code was located exactly the same between the old and new version of the firmware....but not over an IR link...
Never did get it to work right...

flotulopex
- 28th July 2008, 22:20
I've taken it the simple way.

According to the PIC's array capacity, I can store 2 arrays of 40 bits information coming from a teaching remote. Every incomming signal is then measured on a timed base and corresponds to a bit. The 40 bits limits is because I never saw an ir pattern sending more than 40 bits of information.

Fourty "HVar(n)" variables get the logic 1 signal and store for how long it stayed like this; then comes the next logic 0 signal ans there again, I measure the time it stays low and stores its result in fourty "LVar(n)". And so on for 39 (n) more variables.

The result is store in the program memory (its access is much faster than a data-eeprom one) with regard to the actual program space (avoid any conflict). I tried to do the same with a data-eeprom but the timing was far too slow.

To send the ir signal, I use a loop calling every eeprom position one-by-one back and pause (wich means the ir led is emitting) as long as needed and go to next bit and do the same.

The rest is just finalizing the ergonomy of the gadget which I'm working on currently.

My prototype works splendid. I could even make usage of it's internal 8MHz clock source and have still a good incoming signal sampling rate.

I schould get some PCB from a manufacturer next week so I'll have a good idea how this remote will work in hands of friends and colleagues.

Today, the remote looks like this:
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=2789&stc=1&d=1217279703">