>
> AFICT, there's a race condition that exists in the CCP modules. Consider
> this:
>
>   - Event occurs and is captured in CCPR1L and CCPR1H
>   - The contents of CCPR1L are read.
>   - Another event occurs and is captured in CCPR1L and CCPR1H
>   - The contents of CCPR1H are read.
>
> In other words, while reading/processing a captured event, another event
> is captured. There's a two instruction cycle window of vulnerability. The
> only way to avoid this vulnerability is to:
>
>  a) Turn off the CCP module before reading CCPRxL and CCPRxH registers.
>  b) Program the clock source that's being captured to have a frequency
>     half the speed of the instruction execution frequency.
>
> In case (b), you could do something like this (with interrupts disabled)
>
> loop:
>         MOVF    CCPR1L,W                ;
>         MOVWF   TC_CaptureLo            ;Save the time when the last edge
>         MOVFF   CCPR1H,TC_CaptureHi     ;was captured
>         CPFSEQ  CCPR1L                  ;If an event occurred between
>          bra    loop                    ;reading Hi/Lo then try again
>
>     ; now we have a good 16-bit sample
>
> Are there any other reasonable ways to avoid this?
>
> Scott

>
> AFICT, there's a race condition that exists in the CCP modules. Consider
> this:
>
>   - Event occurs and is captured in CCPR1L and CCPR1H
>   - The contents of CCPR1L are read.
>   - Another event occurs and is captured in CCPR1L and CCPR1H
>   - The contents of CCPR1H are read.
>
> In other words, while reading/processing a captured event, another event
> is captured. There's a two instruction cycle window of vulnerability. The
> only way to avoid this vulnerability is to:
>
>  a) Turn off the CCP module before reading CCPRxL and CCPRxH registers.
>  b) Program the clock source that's being captured to have a frequency
>     half the speed of the instruction execution frequency.
>
> In case (b), you could do something like this (with interrupts disabled)
>
> loop:
>         MOVF    CCPR1L,W                ;
>         MOVWF   TC_CaptureLo            ;Save the time when the last edge
>         MOVFF   CCPR1H,TC_CaptureHi     ;was captured
>         CPFSEQ  CCPR1L                  ;If an event occurred between
>          bra    loop                    ;reading Hi/Lo then try again
>
>     ; now we have a good 16-bit sample
>
>
> Scott
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.

> On Sun, 23 Feb 2003, Robert Rolf wrote:

>> the process. If you are getting captures so quickly you don't have
>> time to read both low and high value, aren't you running too close
>> to the edge?
>
> I was mostly speaking hypothetically. My point was simply that *if*
> another unexpected event occurs, it will corrupt the reading. But
> speaking practically, it's not uncommon to get glitches right around
> the transition of an event. In addition, the time when the capture
> registers are read can be quite far away from the time the event
> actually occurred. The worst case scenario I suppose is when the
> event occurs while the code is currently in an interrupt routine. I
> could easily see 20 instruction cycles fly by between the event and
> the reading of the register.
>
> Now in my particular case, I'm reading pulses coming off of an RF
> receiver. It just so happens that when the RF transmitter (on the
> other end) is not transmitting the RF receiver begins hallucinating.
> The AGC circuit begins to push the low background noise up to where
> it can be seen. This causes erroneous short-lived glitches. When the
> RF transmitter is transmitting, there's plenty of signal and the
> pulses are nice and fat and easy to read.
>
> Scott

> There's a risk with this approach, depending on how distinctive your
> packet preamble is, that you'll lose legitimate packets because of
> noise. It works like this:
>
> A burst of noise that looks like a packet preamble comes along. This
> kicks off the packet assembly process, which proceeds to collect the
> packet data and checksum. During the data portion of this presumed
> packet, the preamble for a *real* packet occurs, but is treated as
> data. By the time the decoding process ends and discards the bad
> packet, most of the legitimate packet has already gone by, and you miss
> it.
>
> There are a couple of cures for this. If the protocol is such that the
> packet preamble cannot legitimately appear in the body of a packet (some
> kind of out-of-band signal), you can watch for it at all times and abort
> decoding a bad packet if another preamble comes along. Another approach
> is to buffer all of the incoming raw data and do a sliding-window
> search for valid packets (but this tends to be both memory- and
> CPU-intensive). A third approach would make use of any AGC or RSSI
> (receiver signal strength indicator) signal from the receiver to
> "qualify" the data for the packet decoding process.

> > There's a risk with this approach, depending on how distinctive your
> > packet preamble is, that you'll lose legitimate packets because of
> > noise. It works like this:
> >
> > A burst of noise that looks like a packet preamble comes along. This
> > kicks off the packet assembly process, which proceeds to collect the
> > packet data and checksum. During the data portion of this presumed
> > packet, the preamble for a *real* packet occurs, but is treated as
> > data. By the time the decoding process ends and discards the bad
> > packet, most of the legitimate packet has already gone by, and you miss
> > it.
> >
> > There are a couple of cures for this. If the protocol is such that the
> > packet preamble cannot legitimately appear in the body of a packet (some
> > kind of out-of-band signal), you can watch for it at all times and abort
> > decoding a bad packet if another preamble comes along. Another approach
> > is to buffer all of the incoming raw data and do a sliding-window
> > search for valid packets (but this tends to be both memory- and
> > CPU-intensive). A third approach would make use of any AGC or RSSI
> > (receiver signal strength indicator) signal from the receiver to
> > "qualify" the data for the packet decoding process.
>
> Yes, you're absolutely right.  But in this case each packet starts with a
> sufficiently long string of 1s such that at least 5 in a row are visible
> after the receiver AGC has settled.  This is followed by a special 16 bit
> signature that doesn't contain more than 2 1s in a row.  The chances of
> random noise looking like valid preamble and signature are low enough that
> it's quite acceptable to miss a valid packet in the very rare case it is
> preceeded by such noise.  Each packet also has a 16 bit CRC at the end, so
> the probability that random noise looks like a valid packet is vanishingly
> small.
>
> I didn't design the protocol.  If I had, I might have done away with the

> OTOH, if there's a potential error source that can be identified, then
> there may be a potential fix to remove it. I can't see any *simple* fix.
> I'm not going to add extra hardware, and I really don't care to add extra
> inefficient software like the looping solution I proposed. However,
> another simple solution could be to inhibit the CCP module:
>
>     MOVF    CCP1CON,W             ;Save the current CCP mode
>     CLRF    CCP1CON               ;Disable the CCP module so that
>                                   ;no new events are captured while
>                                   ;we're reading the last captured event
>     MOVFF   CCPR1L,TC_CaptureLo   ;Save the time for the last edge
>     MOVFF   CCPR1H,TC_CaptureHi   ;
>     MOVWF   CCP1CON               ;Restore the CCP mode
>     BCF     PIR1,CCP1IF           ;Clear any spurious interrupt.
>
> Has anyone tried something like this?
>
> Scott

> > I'm dealing with this by simply ignoring it.  Any RF protocol I've ever
> > seen has a preamble to let the receiver adjust its gain and center value.
> > The packet following then contains a checksum and maybe a signature.
> > These are intended to make is impossible (within acceptable probability)
> > for random noise to be interpreted as a valid packet.  So my interrupt
> > routine will continue to measure the hash, but the result won't make it
> > thru the packet detection and validation code.
>
> There's a risk with this approach, depending on how distinctive your packet
> preamble is, that you'll lose legitimate packets because of noise. It works
> like this:

> Correlation: A simple way is to XOR incoming data with data-to-be-tested
> and count the 1's in the result. The fewer 1's the better the correlation.
> XOR is modulo-2 multiply without carry out (or in) and one (the?)
> correlation function is Fc=SumOf|Ai*Bi|. XOR produces this result when Ai
> and Bi are binary bits, but the sum is zero for high correlation because
> the carry in the XOR multiply is lost. In this case Fc=0 means 'all bits
> caused carry' (which was lost). Otherwise one would use an analog
> multiplier to check for correlation with analog signals, and aim for high
> Fc (not zero). Notice that in a binary XOR correlator an all 1's result
> means input and reference are 180 degrees out of phase, or complementary.

> My bit stream is a little different. Instead of Manchester encoding, my
> stream is On/Off encoding. Manchester is better. As I said before, the
> pulse stream is ~10kHz. The width of the pulse dictates 0's and 1's. At
> 10kHz, the pulses are coming in at a rate of 1 every 100 uS. 25uS wide
> pulses are zeroes and  75uS wide ones are ones.

> I decided to use the CCP module instead of a polling interrupt. I first
> program the CCP module to capture every rising edge. When I capture a
> rising I subtract from that the time I captured for the last rising edge.
> This gives the time between rising edges and should be about 100uS. After
> a rising edge is captured, I reprogram the CCP module to capture every
> falling edge. When I capture one I subtract from it the time of the last
> captured rising edge. This gives the pulse width.

> >> What about detecting the / edge with the capture int,
> >> but don't bother time check/subtract etc.
> >> When you capture a / edge, simply load one of the timers
> >> to 50uS (between your 2 pulse widths) and when that timer
> >> int occurs all you need to do is check the input, which
> >> will give 0 for 25uS pulse and 1 for a 75uS pulse.
> >> You don't need to do any period measurement and it's
> >> very low in cycles. ;o)
> >
> > Noise sensitive, I suspect.
>
> I'm not saying that it isn't, but how would this method be any
> more noise sensitive than using the capture/compare module?
> It seems to me, that with oversampling, this would be far less
> susceptable to noise than using the capture feature.

>
> Correlation: A simple way is to XOR incoming data with data-to-be-tested
> and count the 1's in the result. The fewer 1's the better the correlation.
> XOR is modulo-2 multiply without carry out (or in) and one (the?)
> correlation function is Fc=SumOf|Ai*Bi|. XOR produces this result when Ai
> and Bi are binary bits, but the sum is zero for high correlation because
> the carry in the XOR multiply is lost. In this case Fc=0 means 'all bits
> caused carry' (which was lost). Otherwise one would use an analog
> multiplier to check for correlation with analog signals, and aim for high
> Fc (not zero). Notice that in a binary XOR correlator an all 1's result
> means input and reference are 180 degrees out of phase, or complementary.

>
> Hello Dmitry,
>
> you mentioned correlation. Do you know some methods how to do this with
> PICs.?  I would like to do PLL of the incoming signal very much (300 to 500
> Hz for about 100 to 300 miliseconds) but I am not able to find any algorithm
> that would be able to filter a signal and/or to synchronize ADC by a proper
> way.
>
> Igor
>

> *>Olin Lathrop wrote:
> *>Just to get eccentric with the idea, what about
> *>using a piezo gas-oven lighter as a remote control's
> *>power source? It might be hard to rectify and filter
> *>those 10kV+ spikes but it's a renewable power source
> *>you can buy for a couple of dollars and puts out some
> *>decent energy... ;o)
>
> You do not have 10kV if you put a capacitor across it. It produces about
> 20mJ. Using Wc=C*U^2/2 and wanting 5V C results:
>
> C=2*Wc/U^2=2*2*10^-2/25~=1500uF.
>
> Use two shottky diodes as rectifiers. And tell us if you zap yourself good
> ;-)