Better understanding PULSIN

[flotulopex]

Hello Alain,

This is an example of a 13-bit IR pattern I measure on a TSOP4838 receiver module.
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=2701&stc=1&d=121464754 0">

At the start, my prog captures the incoming pattern sent continiously until it determines the starting-bit (first one after the pause between two patterns) and the number of bits (Bit-Count) in the pattern.

I try with this code:

for Ctr_A = 0 to bit_count
   rctime p_in, 0, h_Bit[Ctr_A]
   rctime p_in, 1, l_Bit[Ctr_A]
next Ctr_A

' Results are:
Bit 00  Low  :13795
    00  High :350
Bit 01  Low  :244
    01  High :1253
Bit 02  Low  :244
    02  High :349
Bit 03  Low  :243
    03  High :350
Bit 04  Low  :244
    04  High :350
Bit 05  Low  :244
    05  High :349
Bit 06  Low  :244
    06  High :349
Bit 07  Low  :243
    07  High :350
Bit 08  Low  :75
    08  High :1
Bit 09  Low  :244
    09  High :650
Bit 10  Low  :243
    10  High :350
Bit 11  Low  :244
    11  High :350
Bit 12  Low  :244
    12  High :349

This is the code (works fine) I use currently use @ 20MHz and the data I get with PULSIN is:

for Ctr_A = 0 to bit_count
   pulsin p_in, 0, L_Bit[Ctr_A]
next Ctr_A
for Ctr_A = 0 to bit_count
   pulsin p_in, 1, H_Bit[Ctr_A]
next Ctr_A

' Resuts are:
Bit 00  Low  :1258 'to be multiplied by 2µs (PULSIN res @ 20MHz)
    00  High :247
Bit 01  Low  :354
    01  High :247
Bit 02  Low  :354
    02  High :247
Bit 03  Low  :355
    03  High :247
Bit 04  Low  :354
    04  High :247
Bit 05  Low  :354
    05  High :247
Bit 06  Low  :354
    06  High :247
Bit 07  Low  :354
    07  High :247
Bit 08  Low  :655
    08  High :247
Bit 09  Low  :354
    09  High :247
Bit 10  Low  :355
    10  High :247
Bit 11  Low  :355
    11  High :247
Bit 12  Low  :354
    12  High :13797

According to your previous message, I might raise the timings accuracy with RCTIME instead of using PULSIN. Unfortunately, I can't get it to work using RCTIME.

What am I doing wrong, please?

[Acetronics2]

Hi, Roger

What I see is you should use 1 time Pulsin ( for the leading pulse) and RCTime for all other pulses ...

AND there's a gentle Mix between H_Bit ( 0 State ) and L_Bit ( 1 state ) ... but may be you did it to match the inverted signal ... ???


should be :

   PULSIN  p_in, 0, l_Bit[0]           ' measure neg leading pulse
   RCTIME p_in, 1, h_Bit[0]          ' measure time staying High

for Ctr_A = 1 to ( bit_count -1 )

   rctime p_in, 0, l_Bit[Ctr_A]        ' measure time staying Low
   rctime p_in, 1, h_Bit[Ctr_A]       ' measure time staying High

next Ctr_A

   RCTIME p_in, 0, l_bit[bit_count] ' measure time staying Low

"it's been a hard days night ... And I'm working like a dog ..." as told the Beatles !

Regards
Alain

[flotulopex]

Thanks Alain,

I saw the leading PULSIN command in your previous post and tried this already. The result is the same as without PUSLIN but bits are shifted (not important at that time since the bits are sorted lateron).

But why should the preference go for a PULSIN command first?

I notice while using RCTIME, the measurements give slightly lower results (i.e. PULSIN = 355, RCTIME = 349) which looks good.

Any idea why I get a result of 0 or 1 at bit 8 (sometimes bit 7)?

NB: thank you for noticing the variable mix - I corrected already.

[Acetronics2]

Hi,

But why should the preference go for a PULSIN command first?

... just to be sure to catch the first pulse ... RCTime is somewhat "out of normal use" for the leading pulse ... result is not guaranteed !!!

Any idea why I get a result of 0 or 1 at bit 8 (sometimes bit 7)?

your scoping looks strange ... just at bit 8 !!! ... try to raise the TSOP decoupling caps value and to place a ~ 50 - 100 pF as load to the TSOP output - that could catch possible ns glitches ...

Also take care to have neat 0-5 v levels : the pic Thresold is @ ~1.5 v for TTL inputs ... and Schmitt trigger needs "good" levels ...

Have a nice evening

Alain

[flotulopex]

Merci Alain,

I can't see any change with the decoupling cap and the power is ok. I'll go for some other values and check again.

PBP manual: PULSIN normally waits a maximum of 65535 counts before it determines there is no pulse.

It looks to be the same for RCTIME... but as you say, RCTIME has not the same behaviour as PULSIN.

I think, depending on the IR remote type and protocol, I miss the first bit of the pattern.

Is it possible to make PULSIN scan a pin without time limitation (=until a signal is detected)?

[flotulopex]

Hi,

To make PULSIN wait "forever" for an incoming signal, I added:

LOOP1:
PULSIN p_in, 0, l_Bit[Ctr_A]    ' measure neg leading pulse
if l_Bit[Ctr_A] = 0 then LOOP1:
led1 = 1
RCTIME p_in, 1, h_Bit[Ctr_A]    ' measure time staying High
for Ctr_A = 1 to (bit_count - 1)
   rctime p_in, 0, l_Bit[Ctr_A] ' measure time staying Low
   rctime p_in, 1, h_Bit[Ctr_A] ' measure time staying High
next Ctr_A
RCTIME p_in, 0, l_bit[bit_count]

Thanks again for the RCTIME info, Alain. Is there something you don't know about, hein???

Bon dimanche et bonnes salutations hélvètes!!!

[Acetronics2]

Is it possible to make PULSIN scan a pin without time limitation (=until a signal is detected)?

Hi, Roger ...

Of course :

place a waiting loop,

you detect the first pulse with an interrupt: Alain's interrupt is the best here for latency ... as there is nothing to save ! ( RCTime is to use at first here !!! ) and place your RCTime's "gang" in the interrupt stubb ...

( no RETFIE or GOTO needed ! )

then, your display routine ...

Then back to the waiting loop.



now, for better precision ...

you should use

PULSIN
RCTIME
RCTIME
RCTIME
...

instead of a FOR-NEXT Loop ...

Is there something you don't know about, hein???

Easy answer is ... WOMEN !!!

True answer is Biology, Medicine and such specialities ... more generally what do not accept a mathematical model !!! ( at least yet ...)

One exception : Horses !!!

Have a nice Sunday

Alain