Better understanding PULSIN


Closed Thread
Results 1 to 13 of 13
  1. #1
    Join Date
    Feb 2007
    Posts
    37

    Default Better understanding PULSIN

    I would better understand how work PULSIN statement.

    I'm using PULSIN of PICBASIC PRO rel 4.47 on a 16F877 at 20 Mhz for decode IR from remote, using Sony format.

    In order to better understand, I would track the timing of PULSIN using one free output pin to view with a scope the beging/end of the PULSIN duration with the following statement:


    for BitCount= 1 to 12
    High SData: pauseus 1: low SData ' Before pulsin, generate a pulse wiewable with an oscilloscope.
    pulsin IR_Sensor,0,IRpuls_len(BitCount)
    High SData: pauseus 1: low SData ' Before pulsin, generate a pulse wiewable with an oscilloscope.

    if IRpuls_len(BitCount) < 580 then
    Packet.0[BitCount-1]=0
    Else
    Packet.0[BitCount-1]=1
    endif
    next BitCount

    In my mind, I immagine that first there are an ON pulse as a witness of the PULSIN begin, then after 2,4 or 1,2 or 0,6 mS I should see the second ON pulse.

    Running it, never I see the ON pulse in continuos phase, with begin/end of PULSIN, but in a random position. Take note that the "IRpuls_len(x)" contain the correct value of the pulse lenght, 2,4 mS, 1,2 mS and 0,6 mS.

    Also working with DEFINE PULSIN_MAX with different value do not help to view the second pulse in timing with the end of PULSIN duration.

    Any comment or consideration is welcome.

    Ciao

    Leo

  2. #2
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default

    The thing that might be giving you unexpected results is you are looking for the low state.
    Code:
    pulsin IR_Sensor,0,IRpuls_len(BitCount)
    Change the "0" to "1" to read the high pulse.
    Dave
    Always wear safety glasses while programming.

  3. #3
    Join Date
    Feb 2007
    Posts
    37


    Did you find this post helpful? Yes | No

    Default

    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

  4. #4
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default

    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?
    Dave
    Always wear safety glasses while programming.

  5. #5
    Join Date
    Feb 2007
    Posts
    37


    Did you find this post helpful? Yes | No

    Default

    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
    Attached Files Attached Files

  6. #6
    Join Date
    May 2004
    Location
    NW France
    Posts
    3,611


    Did you find this post helpful? Yes | No

    Wink A Solution to measure following levels ...

    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
    Last edited by Acetronics2; - 9th May 2008 at 13:47.
    ************************************************** ***********************
    Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
    ************************************************** ***********************
    IF there is the word "Problem" in your question ...
    certainly the answer is " RTFM " or " RTFDataSheet " !!!
    *****************************************

  7. #7
    Join Date
    Aug 2006
    Location
    SWITZERLAND (french speaking)
    Posts
    891


    Did you find this post helpful? Yes | No

    Default ... little more help needed

    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:
    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:
    Code:
    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?
    Attached Images Attached Images  
    Roger

  8. #8
    Join Date
    May 2004
    Location
    NW France
    Posts
    3,611


    Did you find this post helpful? Yes | No

    Wink ...

    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 :

    Code:
       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
    ************************************************** ***********************
    Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
    ************************************************** ***********************
    IF there is the word "Problem" in your question ...
    certainly the answer is " RTFM " or " RTFDataSheet " !!!
    *****************************************

  9. #9
    Join Date
    Aug 2006
    Location
    SWITZERLAND (french speaking)
    Posts
    891


    Did you find this post helpful? Yes | No

    Default

    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.
    Roger

  10. #10
    Join Date
    May 2004
    Location
    NW France
    Posts
    3,611


    Did you find this post helpful? Yes | No

    Wink

    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
    Last edited by Acetronics2; - 28th June 2008 at 20:46.
    ************************************************** ***********************
    Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
    ************************************************** ***********************
    IF there is the word "Problem" in your question ...
    certainly the answer is " RTFM " or " RTFDataSheet " !!!
    *****************************************

  11. #11
    Join Date
    Aug 2006
    Location
    SWITZERLAND (french speaking)
    Posts
    891


    Did you find this post helpful? Yes | No

    Default

    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)?
    Roger

  12. #12
    Join Date
    Aug 2006
    Location
    SWITZERLAND (french speaking)
    Posts
    891


    Did you find this post helpful? Yes | No

    Default Okay now

    Hi,

    To make PULSIN wait "forever" for an incoming signal, I added:
    Code:
    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!!!
    Roger

  13. #13
    Join Date
    May 2004
    Location
    NW France
    Posts
    3,611


    Did you find this post helpful? Yes | No

    Wink

    Quote Originally Posted by flotulopex View Post
    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
    ************************************************** ***********************
    Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
    ************************************************** ***********************
    IF there is the word "Problem" in your question ...
    certainly the answer is " RTFM " or " RTFDataSheet " !!!
    *****************************************

Similar Threads

  1. Replies: 17
    Last Post: - 12th April 2014, 03:17
  2. pulsin: how is it used
    By xnihilo in forum mel PIC BASIC Pro
    Replies: 14
    Last Post: - 8th October 2008, 01:11
  3. Funny PULSIN values: what is going on???
    By xnihilo in forum mel PIC BASIC Pro
    Replies: 5
    Last Post: - 30th April 2008, 09:02
  4. Pulsin 16F819 problem
    By rekcahlaer in forum mel PIC BASIC Pro
    Replies: 4
    Last Post: - 11th April 2007, 14:52
  5. PULSIN and RCTIME
    By Dwayne in forum mel PIC BASIC Pro
    Replies: 2
    Last Post: - 4th November 2004, 15:45

Members who have read this thread : 2

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts