Raw IR Issue

Hi, i'm developing an application for IPAQ HX2490 (Windows Mobile 5.0) that
communicates through raw IR with a IR controlled by a PIC microcontroller. In
the first three parts of the operation, i can receive data fine, but on the
last one the handheld just seems to ignore the data that is being received,
it doesn't receive anything. Is there something related to the data that is
being sent to the pocket PC? It is a byte array {0x10, 0x06, 0x16, 0x16}. I'm
using port 2 for the communication. But when i communicate with a desktop PC
with a serial Infrared running exactly the same application in the PIC,
everything works fine! I can't realize what's going on there. Any help would
be appreciated. Thanks.

mike
Thu Feb 28 15:46:18 CST 2008

Bruno wrote:
> Hi, i'm developing an application for IPAQ HX2490 (Windows Mobile 5.0) that
> communicates through raw IR with a IR controlled by a PIC microcontroller. In
> the first three parts of the operation, i can receive data fine, but on the
> last one the handheld just seems to ignore the data that is being received,
> it doesn't receive anything. Is there something related to the data that is
> being sent to the pocket PC? It is a byte array {0x10, 0x06, 0x16, 0x16}. I'm
> using port 2 for the communication. But when i communicate with a desktop PC
> with a serial Infrared running exactly the same application in the PIC,
> everything works fine! I can't realize what's going on there. Any help would
> be appreciated. Thanks.

Download pocketDAQ and see if that shows you anything interesting.
Have you checked the timing? Using the hardware UART in the PIC or
software implementation?
mike

--
Return address is VALID!

Bruno
Thu Feb 28 16:32:04 CST 2008



"mike" wrote:

> Bruno wrote:
> > Hi, i'm developing an application for IPAQ HX2490 (Windows Mobile 5.0) that
> > communicates through raw IR with a IR controlled by a PIC microcontroller. In
> > the first three parts of the operation, i can receive data fine, but on the
> > last one the handheld just seems to ignore the data that is being received,
> > it doesn't receive anything. Is there something related to the data that is
> > being sent to the pocket PC? It is a byte array {0x10, 0x06, 0x16, 0x16}. I'm
> > using port 2 for the communication. But when i communicate with a desktop PC
> > with a serial Infrared running exactly the same application in the PIC,
> > everything works fine! I can't realize what's going on there. Any help would
> > be appreciated. Thanks.
>
> Download pocketDAQ and see if that shows you anything interesting.
> Have you checked the timing? Using the hardware UART in the PIC or
> software implementation?
> mike
>
> --
> Return address is VALID!
>

Thanks for the answer mike. It was of great help.
I used pocketDAQ and realized that in fact the IPAQ isn't receiving data.
Now i'll try to debug on the PIC to see what's going on.
The only strange thing is that when i communicate with exactly the same
application that i'm using on the IPAQ with my desktop IR serial port, the
PIC answers!

---
Thu Feb 28 19:07:18 CST 2008

On Thu, 28 Feb 2008 14:32:04 -0800, =?Utf-8?B?QnJ1bm8=?=
<Bruno@discussions.microsoft.com> wrote:

>
>
>"mike" wrote:
>
>> Bruno wrote:
>> > Hi, i'm developing an application for IPAQ HX2490 (Windows Mobile 5.0) that
>> > communicates through raw IR with a IR controlled by a PIC microcontroller. In
>> > the first three parts of the operation, i can receive data fine, but on the
>> > last one the handheld just seems to ignore the data that is being received,
>> > it doesn't receive anything. Is there something related to the data that is
>> > being sent to the pocket PC? It is a byte array {0x10, 0x06, 0x16, 0x16}. I'm
>> > using port 2 for the communication. But when i communicate with a desktop PC
>> > with a serial Infrared running exactly the same application in the PIC,
>> > everything works fine! I can't realize what's going on there. Any help would
>> > be appreciated. Thanks.
>>
>> Download pocketDAQ and see if that shows you anything interesting.
>> Have you checked the timing? Using the hardware UART in the PIC or
>> software implementation?
>> mike
>>
>> --
>> Return address is VALID!
>>
>
>Thanks for the answer mike. It was of great help.
>I used pocketDAQ and realized that in fact the IPAQ isn't receiving data.
>Now i'll try to debug on the PIC to see what's going on.
>The only strange thing is that when i communicate with exactly the same
>application that i'm using on the IPAQ with my desktop IR serial port, the
>PIC answers!

I am curious as to what led you to believe initially that your iPAQ was
receiving IR data from the PIC in 3 out of 4 parts, but later you decided that
the iPAQ was never receiving anything from the PIC. I suggest breaking down the
problem into a primitive receive test where the hex values for all characters
recevied are displayed on the screen.

I also designed a PIC to iPAQ and iPAQ to PIC communication link using raw IR,
and it worked fine, but the IR sender and receiver connected to the PIC had to
be very close to the receiver and sender for the iPAQ.


Robert Scott
Ypsilanti, Michigan

mike
Fri Feb 29 06:16:49 CST 2008

Robert Scott wrote:
> On Thu, 28 Feb 2008 14:32:04 -0800, =?Utf-8?B?QnJ1bm8=?=
> <Bruno@discussions.microsoft.com> wrote:
>
>>
>> "mike" wrote:
>>
>>> Bruno wrote:
>>>> Hi, i'm developing an application for IPAQ HX2490 (Windows Mobile 5.0) that
>>>> communicates through raw IR with a IR controlled by a PIC microcontroller. In
>>>> the first three parts of the operation, i can receive data fine, but on the
>>>> last one the handheld just seems to ignore the data that is being received,
>>>> it doesn't receive anything. Is there something related to the data that is
>>>> being sent to the pocket PC? It is a byte array {0x10, 0x06, 0x16, 0x16}. I'm
>>>> using port 2 for the communication. But when i communicate with a desktop PC
>>>> with a serial Infrared running exactly the same application in the PIC,
>>>> everything works fine! I can't realize what's going on there. Any help would
>>>> be appreciated. Thanks.
>>> Download pocketDAQ and see if that shows you anything interesting.
>>> Have you checked the timing? Using the hardware UART in the PIC or
>>> software implementation?
>>> mike
>>>
>>> --
>>> Return address is VALID!
>>>
>> Thanks for the answer mike. It was of great help.
>> I used pocketDAQ and realized that in fact the IPAQ isn't receiving data.
>> Now i'll try to debug on the PIC to see what's going on.
>> The only strange thing is that when i communicate with exactly the same
>> application that i'm using on the IPAQ with my desktop IR serial port, the
>> PIC answers!
>
> I am curious as to what led you to believe initially that your iPAQ was
> receiving IR data from the PIC in 3 out of 4 parts, but later you decided that
> the iPAQ was never receiving anything from the PIC. I suggest breaking down the
> problem into a primitive receive test where the hex values for all characters
> recevied are displayed on the screen.
>
> I also designed a PIC to iPAQ and iPAQ to PIC communication link using raw IR,
> and it worked fine, but the IR sender and receiver connected to the PIC had to
> be very close to the receiver and sender for the iPAQ.
>
>
> Robert Scott
> Ypsilanti, Michigan

We should compare notes. I wanted basic debug.print functionality for
debugging pic projects. I ended up hacking pic basic pro to spit out sir
to drive a led.
Input is a bit harder because of the narrow sir pulse width. I never
got the energy to write the interrupt handler with sufficiently low
latency to work and still be able to get anything else done on the PIC.
I did a bunch of thought experiments about using the interrupt pin
to set a timer to hold itself "on" for a bit time to create NRZ RS232
from the RZ SIR. You should be able to tie that pin to the HW UART
input and make it work....maybe it only costs one pin.
mike

--
Return address is VALID!

---
Fri Feb 29 06:46:47 CST 2008

On Fri, 29 Feb 2008 12:16:49 GMT, mike <spamme9@gmail.com> wrote:
>... I wanted basic debug.print functionality for
>debugging pic projects. I ended up hacking pic basic pro to spit out sir
>to drive a led.
>Input is a bit harder because of the narrow sir pulse width. I never
>got the energy to write the interrupt handler with sufficiently low
>latency to work and still be able to get anything else done on the PIC.
>I did a bunch of thought experiments about using the interrupt pin
>to set a timer to hold itself "on" for a bit time to create NRZ RS232
>from the RZ SIR. You should be able to tie that pin to the HW UART
>input and make it work....maybe it only costs one pin.
>mike

Split the problem in the middle to determine if the problem is the sending end
or the receiving end. I used a scope to see if what my PIC was putting out was
what I expected. It is too big a jump to go all the way to trying to receive on
an iPAQ until you have verified that intermediate step.

Actually, I used 3 PICs to do the job. The main PIC sent and received normal
serial async using the built-in UART. Then I used two other simple 8-pin PICs
to transform those signals to and from IR using instruction timing (no UART or
timers needed). The IR pulses are short - about 10% of a bit cell time. But I
had to check out these IR-to-serial PICs with a scope before I could trust them
in the complete system. The two little helper PICs were necessary because I
could not afford the processor dedication in the main PIC due to other real-time
tasks that were being done there.


Robert Scott
Ypsilanti, Michigan

Bruno
Fri Feb 29 16:03:01 CST 2008



"Robert Scott" wrote:

> On Thu, 28 Feb 2008 14:32:04 -0800, =?Utf-8?B?QnJ1bm8=?=
> <Bruno@discussions.microsoft.com> wrote:
>
> >
> >
> >"mike" wrote:
> >
> >> Bruno wrote:
> >> > Hi, i'm developing an application for IPAQ HX2490 (Windows Mobile 5.0) that
> >> > communicates through raw IR with a IR controlled by a PIC microcontroller. In
> >> > the first three parts of the operation, i can receive data fine, but on the
> >> > last one the handheld just seems to ignore the data that is being received,
> >> > it doesn't receive anything. Is there something related to the data that is
> >> > being sent to the pocket PC? It is a byte array {0x10, 0x06, 0x16, 0x16}. I'm
> >> > using port 2 for the communication. But when i communicate with a desktop PC
> >> > with a serial Infrared running exactly the same application in the PIC,
> >> > everything works fine! I can't realize what's going on there. Any help would
> >> > be appreciated. Thanks.
> >>
> >> Download pocketDAQ and see if that shows you anything interesting.
> >> Have you checked the timing? Using the hardware UART in the PIC or
> >> software implementation?
> >> mike
> >>
> >> --
> >> Return address is VALID!
> >>
> >
> >Thanks for the answer mike. It was of great help.
> >I used pocketDAQ and realized that in fact the IPAQ isn't receiving data.
> >Now i'll try to debug on the PIC to see what's going on.
> >The only strange thing is that when i communicate with exactly the same
> >application that i'm using on the IPAQ with my desktop IR serial port, the
> >PIC answers!
>
> I am curious as to what led you to believe initially that your iPAQ was
> receiving IR data from the PIC in 3 out of 4 parts, but later you decided that
> the iPAQ was never receiving anything from the PIC. I suggest breaking down the
> problem into a primitive receive test where the hex values for all characters
> recevied are displayed on the screen.
>
> I also designed a PIC to iPAQ and iPAQ to PIC communication link using raw IR,
> and it worked fine, but the IR sender and receiver connected to the PIC had to
> be very close to the receiver and sender for the iPAQ.
>
>
> Robert Scott
> Ypsilanti, Michigan
>

When i run the application in a RZ1710 IPAQ everything runs fine, but when i
run it in a HX2490, by no manner of means, it receives the last response from
the PIC, which is a {0x10, 0x06, 0x16, 0x16} byte array.
When i said "I used pocketDAQ and realized that in fact the IPAQ isn't
receiving data. ", i meant this last response.
I'm doing this job to another company, they're successfuly using this PIC
for 2 years, using the RZ1710 to communicate with. The problem they had was
with HX2490, that acts like it doesn't receive this package. I just need to
realize why the damn data isn't arriving for the HX2490.
Thanks for the help.

Bruno Leite
Porto Alegre, RS - Brazil

mike
Fri Feb 29 22:51:03 CST 2008

Bruno wrote:
>
> "Robert Scott" wrote:
>
>> On Thu, 28 Feb 2008 14:32:04 -0800, =?Utf-8?B?QnJ1bm8=?=
>> <Bruno@discussions.microsoft.com> wrote:
>>
>>>
>>> "mike" wrote:
>>>
>>>> Bruno wrote:
>>>>> Hi, i'm developing an application for IPAQ HX2490 (Windows Mobile 5.0) that
>>>>> communicates through raw IR with a IR controlled by a PIC microcontroller. In
>>>>> the first three parts of the operation, i can receive data fine, but on the
>>>>> last one the handheld just seems to ignore the data that is being received,
>>>>> it doesn't receive anything. Is there something related to the data that is
>>>>> being sent to the pocket PC? It is a byte array {0x10, 0x06, 0x16, 0x16}. I'm
>>>>> using port 2 for the communication. But when i communicate with a desktop PC
>>>>> with a serial Infrared running exactly the same application in the PIC,
>>>>> everything works fine! I can't realize what's going on there. Any help would
>>>>> be appreciated. Thanks.
>>>> Download pocketDAQ and see if that shows you anything interesting.
>>>> Have you checked the timing? Using the hardware UART in the PIC or
>>>> software implementation?
>>>> mike
>>>>
>>>> --
>>>> Return address is VALID!
>>>>
>>> Thanks for the answer mike. It was of great help.
>>> I used pocketDAQ and realized that in fact the IPAQ isn't receiving data.
>>> Now i'll try to debug on the PIC to see what's going on.
>>> The only strange thing is that when i communicate with exactly the same
>>> application that i'm using on the IPAQ with my desktop IR serial port, the
>>> PIC answers!
>>
>> I am curious as to what led you to believe initially that your iPAQ was
>> receiving IR data from the PIC in 3 out of 4 parts, but later you decided that
>> the iPAQ was never receiving anything from the PIC. I suggest breaking down the
>> problem into a primitive receive test where the hex values for all characters
>> recevied are displayed on the screen.
>>
>> I also designed a PIC to iPAQ and iPAQ to PIC communication link using raw IR,
>> and it worked fine, but the IR sender and receiver connected to the PIC had to
>> be very close to the receiver and sender for the iPAQ.
>>
>>
>> Robert Scott
>> Ypsilanti, Michigan
>>
>
> When i run the application in a RZ1710 IPAQ everything runs fine, but when i
> run it in a HX2490, by no manner of means, it receives the last response from
> the PIC, which is a {0x10, 0x06, 0x16, 0x16} byte array.
> When i said "I used pocketDAQ and realized that in fact the IPAQ isn't
> receiving data. ", i meant this last response.
> I'm doing this job to another company, they're successfuly using this PIC
> for 2 years, using the RZ1710 to communicate with. The problem they had was
> with HX2490, that acts like it doesn't receive this package. I just need to
> realize why the damn data isn't arriving for the HX2490.
> Thanks for the help.
>
> Bruno Leite
> Porto Alegre, RS - Brazil
I assume you've tried the obvious...
PUt some delay before the last array?
put some delay in between the bytes.
Checked the timing. Doesn't have to be off by much to
miss the short pulses...depending on how the receiver does it.
Are you using EXACTLY the same routine, not just the same code in
a different routine to send all three groups?
What happens if you just send the first data set three times?
Make the IR pulse wider?
Are you using an IR interface module or trying to drive the ir led
directly from the pic? Risetime issues can take a lot of energy
out of a short pulse. As I recall, the module supplies a LOT more
current to the led than you can expect from a PIC.
mike

--
Return address is VALID!

taximania
Sun Mar 02 03:55:40 CST 2008


"Bruno" <Bruno@discussions.microsoft.com> wrote in message
news:79A4A3DC-7557-4B59-9E6C-2D53A16B8335@microsoft.com...
> Hi, i'm developing an application for IPAQ HX2490 (Windows Mobile 5.0)
> that
> communicates through raw IR with a IR controlled by a PIC microcontroller.
> In
> the first three parts of the operation, i can receive data fine, but on
> the
> last one the handheld just seems to ignore the data that is being
> received,
> it doesn't receive anything. Is there something related to the data that
> is
> being sent to the pocket PC? It is a byte array {0x10, 0x06, 0x16, 0x16}.
> I'm
> using port 2 for the communication. But when i communicate with a desktop
> PC
> with a serial Infrared running exactly the same application in the PIC,
> everything works fine! I can't realize what's going on there. Any help
> would
> be appreciated. Thanks.


Is this offering any help to you ..

http://myweb.tiscali.co.uk/taximania/pic3.html

Bruno
Fri Mar 28 20:29:00 CDT 2008



"mike" wrote:

> Bruno wrote:
> >
> > "Robert Scott" wrote:
> >
> >> On Thu, 28 Feb 2008 14:32:04 -0800, =?Utf-8?B?QnJ1bm8=?=
> >> <Bruno@discussions.microsoft.com> wrote:
> >>
> >>>
> >>> "mike" wrote:
> >>>
> >>>> Bruno wrote:
> >>>>> Hi, i'm developing an application for IPAQ HX2490 (Windows Mobile 5.0) that
> >>>>> communicates through raw IR with a IR controlled by a PIC microcontroller. In
> >>>>> the first three parts of the operation, i can receive data fine, but on the
> >>>>> last one the handheld just seems to ignore the data that is being received,
> >>>>> it doesn't receive anything. Is there something related to the data that is
> >>>>> being sent to the pocket PC? It is a byte array {0x10, 0x06, 0x16, 0x16}. I'm
> >>>>> using port 2 for the communication. But when i communicate with a desktop PC
> >>>>> with a serial Infrared running exactly the same application in the PIC,
> >>>>> everything works fine! I can't realize what's going on there. Any help would
> >>>>> be appreciated. Thanks.
> >>>> Download pocketDAQ and see if that shows you anything interesting.
> >>>> Have you checked the timing? Using the hardware UART in the PIC or
> >>>> software implementation?
> >>>> mike
> >>>>
> >>>> --
> >>>> Return address is VALID!
> >>>>
> >>> Thanks for the answer mike. It was of great help.
> >>> I used pocketDAQ and realized that in fact the IPAQ isn't receiving data.
> >>> Now i'll try to debug on the PIC to see what's going on.
> >>> The only strange thing is that when i communicate with exactly the same
> >>> application that i'm using on the IPAQ with my desktop IR serial port, the
> >>> PIC answers!
> >>
> >> I am curious as to what led you to believe initially that your iPAQ was
> >> receiving IR data from the PIC in 3 out of 4 parts, but later you decided that
> >> the iPAQ was never receiving anything from the PIC. I suggest breaking down the
> >> problem into a primitive receive test where the hex values for all characters
> >> recevied are displayed on the screen.
> >>
> >> I also designed a PIC to iPAQ and iPAQ to PIC communication link using raw IR,
> >> and it worked fine, but the IR sender and receiver connected to the PIC had to
> >> be very close to the receiver and sender for the iPAQ.
> >>
> >>
> >> Robert Scott
> >> Ypsilanti, Michigan
> >>
> >
> > When i run the application in a RZ1710 IPAQ everything runs fine, but when i
> > run it in a HX2490, by no manner of means, it receives the last response from
> > the PIC, which is a {0x10, 0x06, 0x16, 0x16} byte array.
> > When i said "I used pocketDAQ and realized that in fact the IPAQ isn't
> > receiving data. ", i meant this last response.
> > I'm doing this job to another company, they're successfuly using this PIC
> > for 2 years, using the RZ1710 to communicate with. The problem they had was
> > with HX2490, that acts like it doesn't receive this package. I just need to
> > realize why the damn data isn't arriving for the HX2490.
> > Thanks for the help.
> >
> > Bruno Leite
> > Porto Alegre, RS - Brazil
> I assume you've tried the obvious...
> PUt some delay before the last array?
> put some delay in between the bytes.
> Checked the timing. Doesn't have to be off by much to
> miss the short pulses...depending on how the receiver does it.
> Are you using EXACTLY the same routine, not just the same code in
> a different routine to send all three groups?
> What happens if you just send the first data set three times?
> Make the IR pulse wider?
> Are you using an IR interface module or trying to drive the ir led
> directly from the pic? Risetime issues can take a lot of energy
> out of a short pulse. As I recall, the module supplies a LOT more
> current to the led than you can expect from a PIC.
> mike
>
> --
> Return address is VALID!
>

ok, finally i solved it!!
using a scope i realized that the PIC was sending the data in 500us. so i
put some delay on the data and voila, with 10ms of delay it worked! I think
the IPAQ is half-duplex and 500us isn't enougth time for it to switch from
send to read. Maybe it is that.

Thanks guys, specially for mike, PocketDAQ helped me a lot.