Better understanding PULSIN

[mackrackit]

The thing that might be giving you unexpected results is you are looking for the low state.

pulsin IR_Sensor,0,IRpuls_len(BitCount)

Change the "0" to "1" to read the high pulse.

[Wirecut]

Hi mackrackit,

the statement is correct, I read the "down" time of the signal, ad the value returned by PULSIN is correct and into the value that I aspect.

I do not see the pulse in phase with PULSIN generate by this statement

SData var PORTB.7 ' RB7 output pin for measurement pulse duration
.....
High SData: pauseus 1: low SDatapulse
.....

SData is aspected lengh one microsecond, and when is show have correct lenght, but non in phase with begin/end of PULSIN.

Ciao

Leo

[mackrackit]

I am not quite getting it.

You are talking about another VAR or CON (SDatapulse) that we do not know how it relates to everything else.

Can you post all of your code?

[Wirecut]

Sorry for delay to upload the code.

Also I have upload tree screenshot of a digital oscilloscope to better explain what happens.

Channel B show the incomin IR signal and channel A should show with the pulse of SData/PORTB.1 the begin/end of PULSIN.

You can see some missing SData/PORTB.1 pulse on the uploaded images, but belive me the IR code is correctly recognized of the incaming IR pulse duration and the array IRpuls_len(x) contain the correct pulse lenght.

The uploaded program 16F877_IR_pulsin.zip works correctly, but leave me unsatisfied about the use of PULSIN.

I will expect one pulse of SData/PORTB.1 at the begin of PULSIN and another pulse of SData/PORTB.1 at the end of the PULSIN statement, yust before the execution of the next statement, and no SData/PORTB.1 missing as you can see per attached images.

Ciao

Leo

[Acetronics2]

Hi, Wirecut

Pulsin is a command that MUST wait for the leading edge ...

so, if you want to measure, say a PWM signal, you're tempted to Write :

PULSIN Input, 1, Hilev1
PULSIN Input, 0, Lolev1
...

... Am I right ???

But using Pulsin twice will do the Following :

READ correctly the High level ...
RESET it's detection mechanism ( some µs necessary !!! )
WAIT for an incoming falling edge
READ the Low level pulse
RESET it's detection mechanism ( some µs necessary !!! )
WAIT for an incoming rising edge
READ the High level pulse


then it doesn't see the falling edge for the 1st following Low level ( has happend some µs ago !!! )

THEN it will wait for the NEXT falling edge ... wich is the SECOND low level state ...

so, let's resume ...

you read hi state 1, lo state 2, hi state 3, lo state 4

INSTEAD of : hi state 1 , lo state 1, hi state 2, lo state 2 .... etc, etc

TURNAROUND ...

PULSIN Input, 1, Hilev1
RCTIME Input, 0, Lolev1
RCTIME Input, 1, Hilev2
RCTIME Input, 0, Lolev2
...

if using a 4Mhz clock, add 1 unit correction to RCTIME measured values

if using a 20 Mhz clock, add 4 units to RCTIME Measured values

And now, you'll get your values right !!! ... or very, very, very, very close, to be honest !!!

Alain

[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