Exact match. Not showing close matches.
PICList
Thread
'[pic]:CCP Capture mode'
2003\02\23@014948
by
Scott Dattalo
|
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
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\23@021104
by
Robert Rolf
|
Read the low register a second time? If it was different from the first
reading you had a 2nd capture during your vulnerable window and would repeat
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?
This same idea as read high, low, high is also a good idea when reading
timers to ensure that your high byte was not read after the low byte
overflowed.
Robert
Scott Dattalo wrote:
{Quote hidden}>
> 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
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\23@025331
by
Scott Dattalo
|
On Sun, 23 Feb 2003, Robert Rolf wrote:
> Read the low register a second time? If it was different from the first
> reading you had a 2nd capture during your vulnerable window and would repeat
That's exactly what I proposed in the option (b). (Go back and re-read
the original message paying special attention to the code).
> 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
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\23@040011
by
Jinx
> - 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
Can you make use of the prescaler in your application ? Are you
trying to measure individual pulses ?
This might sound a little off the wall (as I'm not sure what your
intention is or the nature of the pulses), but how about an
external flip-flop + SPDT to deflect the second pulse away from
the CCP pin (or maybe off to another PIC for its own CCP)
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\23@073549
by
Roman Black
|
Scott Dattalo wrote:
> Are there any other reasonable ways to avoid this?
1. Make use of the CCP interrupt, as soon as the capture
occurs you can handle the condition in int code.
2. Increase the capture prescaler to 2x pulse or 4x pulse,
giving you a lot more time to check and save the capture
before the next one happens.
3. If you don't want another interrupt try a called
(polled) function that checks the CCP flag and saves the
value. This only costs 1 inst (call x) which can be placed
throughout your other code.
All these rely on having enough time to keep on top of
things and handle the capture before the next one. If you
are risking a race condition it might be time for a
re-think of total timing allocation. :o)
-Roman
{Quote hidden}>
> 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.
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\23@083451
by
Olin Lathrop
Scott Dattalo wrote:
> 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.
What a coincidence. Right now I'm working on a project that interprets
four manchester encoded bit streams with one PIC, two of them coming from
RF receivers with 10KHz bit rate. These receivers also produce gibberish
when there is no RF to receive. This is common because the receiver
cranks up its gain and adjusts its detection threshold to the average
level, so it will always produce a digital signal that is high about half
the time.
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.
It is a good idea to analog filter the signal from the receiver to limit
the maximum frequency of the hash to avoid eating up too many processor
resources. A simple R-C or R-C-R-C is fine.
By the way, I'm not using the CCP module for this. I'm trying to cram all
this into a 18F1320 (or 18F1220 if I get lucky), which only has one CCP
module. The high/low priority interrupt structure of this part makes the
whole thing possible. These are nice little chips. Finally a small low
cost 18F with a decent peripheral set.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\23@090635
by
michael brown
|
Scott Dattalo wrote:
{Quote hidden}> 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
GIGO ;-) Maybe it's time to use a faster crystal? I'm guessing that
you are either monitoring an HF sideband signal, or an unsquelched FM
receiver. Maybe a DSP audio processor between the radio and the PIC
might help to clear things up? Another idea that comes to mind is to
immediately disable the Capture upon entry into your subroutine, this
should cut the critical area down to around 10 clocks max as opposed to
20. Maybe some more filtering on the input data to eliminate spikes?
Without knowing more about the signal you are trying to process, I'm
pretty much shooting in the dark, but hey it's the piclist. ;-)
Michael Brown
Instant Net Solutions
http://www.KillerPCs.net
"In the land of the blind, he who has one eye is king"
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\23@123040
by
Scott Dattalo
|
On Sun, 23 Feb 2003, Jinx wrote:
> > - 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
>
> Can you make use of the prescaler in your application ?
Sure.
> Are you
> trying to measure individual pulses ?
Yes.
Basically I'm measuring the pulses in a 10kHz pulse stream (100 uS period)
where a pulse 25uS wide is a zero and a pulse 75uS wide is a one. It's
relatively easy to do with the CCP module. But while writing the code, I
realized that there is this race condition that exists. To me it really
doesn't matter. It just means that occasionally I'll misread one pulse
width and get an error. The communication link is robust enough to recover
from this error (because, in general RF links can be noisy and need
adequate mechanism to recover against errors).
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
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\23@124423
by
Ned Konz
2003\02\23@124425
by
Dave Tweed
|
Olin Lathrop <spam_OUTolin_piclistTakeThisOuT
EMBEDINC.COM> wrote:
> What a coincidence. Right now I'm working on a project that interprets
> four manchester encoded bit streams with one PIC, two of them coming from
> RF receivers with 10KHz bit rate. These receivers also produce gibberish
> when there is no RF to receive. This is common because the receiver
> cranks up its gain and adjusts its detection threshold to the average
> level, so it will always produce a digital signal that is high about half
> the time.
>
> 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:
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.
-- Dave Tweed
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\23@125339
by
jim barchuk
|
Hi Scott!
> Basically I'm measuring the pulses in a 10kHz pulse stream (100 uS period)
> where a pulse 25uS wide is a zero and a pulse 75uS wide is a one. It's
> relatively easy to do with the CCP module. But while writing the code, I
> realized that there is this race condition that exists. To me it really
[snip]
> 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.
Oh, OK, pulse stream. In your first post you didn't mention if you were
sampling analog or digital data, but 'race condition' did imply digital.
If analog I would have mentioned Nyquist, which I thought about because
you also mentioned you were thinking about 'more than twice' the incoming
rate.
In any case this mentions your fix exactly:
http://www.circuitcellar.com/pastissues/articles/ball127/text.htm. That's
AVR but still spot on. (Nearer the bottom of the page.)
I didn't like the 'loop until no interupts' because if they came in too
fast for whatever reason you'd have no choice but to just sit there and
wait for them to settle. Or worse, they -don't- settle. 'Whatever' meaning
a problem elsewhere that causes things to run totally out of control. But
if they do, then...
> The communication link is robust enough to recover from this error
> (because, in general RF links can be noisy and need adequate mechanism
> to recover against errors).
...that will deal with it.
Have a :) day!
jb
--
jim barchuk
.....jbKILLspam
@spam@jbarchuk.com
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\23@133804
by
Olin Lathrop
{Quote hidden}> 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
signature altogether, and spent fewer bits using bit stuffing or whatever
to guarantee that more than a certain number of consecutive 1s never occur
in a valid packet. Then it would be easy to keep a counter at all times
and abort back to the start of the loop if more than that number of
consecutive 1s was ever received. But the spec is what it is, and is out
of my control.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\23@135223
by
Scott Dattalo
|
On Sun, 23 Feb 2003, Olin Lathrop wrote:
{Quote hidden}> > 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
This my situation exactly too. My bit stream is only 32 bits and prefaced
with a 14-bit preamble of 7 1's followed by 7 zeroes. The packets come
from many different sources simultaneously - collisions will happen. Each
source emits its packet over and over and uses a PRN generator determine
the time for the next transmission interval. Instead of CRC's though, I
use modified hamming codes. There's not much space in 32-bits for a CRC...
Scott
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\23@135847
by
Scott Dattalo
|
On Sun, 23 Feb 2003, Roman Black wrote:
> Scott Dattalo wrote:
>
> > Are there any other reasonable ways to avoid this?
>
> 1. Make use of the CCP interrupt, as soon as the capture
> occurs you can handle the condition in int code.
Yep. That's what I do already.
> 2. Increase the capture prescaler to 2x pulse or 4x pulse,
> giving you a lot more time to check and save the capture
> before the next one happens.
Yep. That's one of the solutions I proposed too. The only problem is that
a little bit of resolution is lost.
> 3. If you don't want another interrupt try a called
> (polled) function that checks the CCP flag and saves the
> value. This only costs 1 inst (call x) which can be placed
> throughout your other code.
I prefer the interrupts. (especially since there are a bazillion other
things happening).
> All these rely on having enough time to keep on top of
> things and handle the capture before the next one. If you
> are risking a race condition it might be time for a
> re-think of total timing allocation. :o)
Your's and everyone else's solutions are quite reasonable. The main
purpose for me posting the question was to determine if there was an
oversight on my part with regards to the behavior of the CCP modules. I
think now I can conclude that there is not an oversight, and that there is
a potential gotcha with CCP modules operating in capture mode.
Scott
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\23@150147
by
Peter L. Peres
|
One trick you can do is to use a FEC code and raise the correction bits
ratio until you get an acceptable error ratio for your application
(knowing that zero error rate is not an available option).
Wrt out of band signalling (as Dave Tweed has said), the easyest is to use
a break in the transmission between packets. A noise burst would have the
same effect however .... Another is to use start or sync pulses of
different duration then those in the normal data. These two methods are
the most used ones, usually in combination with FEC or CRC in the packets.
Once you understand that there is no way to get 100% error free data no
matter what you do, it's all a matter of tradeoff between what you can use
and what you can afford. The FEC code has the advantage that you do not
need a SQ control (the BER tells you that) and you can up the ratio of fec
bits as much as you want (or can afford). I used FEC 3/8 using a table and
breaks (actually the tx side worked only when keyed) followed by a short
sync burst to settle the simple comparator data slicer for carrier current
c. and it works fine.
Peter
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\23@150355
by
Dmitriy A. Kiryashov
|
Greetings Scott.
What if the first pulse you've captured is noise/wrong pulse?
You lock onto it and miss another one which is right.
Why not filtering approach or correlation ?
WBR Dmitry.
Scott Dattalo wrote:
{Quote hidden}> 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
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\23@170252
by
Igor Pokorny
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
{Original Message removed}
2003\02\23@180151
by
Peter L. Peres
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.
Peter
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\23@193954
by
Dale Botkin
|
Dave Tweed <pic
KILLspamDTWEED.COM> said:
> Olin Lathrop <.....olin_piclistKILLspam
.....EMBEDINC.COM> wrote:
> > What a coincidence. Right now I'm working on a project that interprets
> > four manchester encoded bit streams with one PIC, two of them coming from
> > RF receivers with 10KHz bit rate.
8<
{Quote hidden}> > 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:
8<
> 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.
I've been working with this for a while now... RF Manchester encoded packets
coming in at random times using a recevier that is not (and cannot be)
squelched.
I used a Microchip app note dealing with their Keeloq products (TB045,
http://www.microchip.com/1010/suppdoc/appnote/all/tb045/index.htm), and
translated that into C code for a state machine that runs from a timer
interrupt. The ISR executes at about 10x the data bit rate. I could go into
great detail, but the app note is really pretty good (and the code is for a
customer, so I can't share too much). Basically it watches for any glitch of
any sort - a missing transition when there shouldn't be one, or an extra
transition where none is expected. If anything whatsoever isn't right, the
state machine resets to the "watching for preamble" state.
So far the results have been excellent. Of course you might miss a packet;
this is a fact of life with any RF or IR protocol. If you need guaranteed
delivery of each packet, you will need to do it with transceivers at each end
and some sort of ACK from the receiving end. In my particular case I'm just
watching for beacon and command packets that are repeated regularly, so losing
a packet is not a big deal. Reliability would be another layer.
Dale
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\23@195914
by
Olin Lathrop
> I used a Microchip app note dealing with their Keeloq products (TB045,
> http://www.microchip.com/1010/suppdoc/appnote/all/tb045/index.htm), and
> translated that into C code for a state machine that runs from a timer
> interrupt. The ISR executes at about 10x the data bit rate. I could go
> into great detail, but the app note is really pretty good (and the code
> is for a customer, so I can't share too much). Basically it watches for
> any glitch of any sort - a missing transition when there shouldn't be
> one, or an extra transition where none is expected. If anything
> whatsoever isn't right, the state machine resets to the "watching for
> preamble" state.
>
> So far the results have been excellent. Of course you might miss a
> packet; this is a fact of life with any RF or IR protocol. If you need
> guaranteed delivery of each packet, you will need to do it with
> transceivers at each end and some sort of ACK from the receiving end. In
> my particular case I'm just watching for beacon and command packets that
> are repeated regularly, so losing a packet is not a big deal.
> Reliability would be another layer.
I'm attacking it a little differently. I've got two 10KHz and two 1KHz
manchester streams to decode simultaneously. I just can't sample at 100KHz
and still have any cycles left for the decoding and other logic. Instead I
use two of the INT interrupts of the 18F set to high priority to measure the
time between edges. Things are scaled so that the maximum valid time
between edges fits into 7 bits. The rising/falling edge indicator gets
stuffed into the 8th bit, and the byte gets pushed onto a FIFO for that
stream. The 1KHz edges get measured similarly by using low priority
interrupts. This keeps the measurement jitter for the high speed streams
down. Foreground code then decodes the 4 FIFO streams as it gets around to
it. This is done in one piece of code that has 4 pseudo-threads running in
it.
Worst case I have a little over 200 cycles average per edge, of which 45 are
used in the interrupt to capture and measure the edge. The remaining 155
cycles per edge average sounds like enough to do the decoding. I've worked
out most of that but am only about 1/3 done writing it. I should know in a
few days how well everything worked together.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\02\24@001728
by
Scott Dattalo
|
On Sun, 23 Feb 2003, Olin Lathrop wrote:
> I'm attacking it a little differently. I've got two 10KHz and two 1KHz
> manchester streams to decode simultaneously. I just can't sample at 100KHz
> and still have any cycles left for the decoding and other logic. Instead I
> use two of the INT interrupts of the 18F set to high priority to measure the
> time between edges. Things are scaled so that the maximum valid time
> between edges fits into 7 bits. The rising/falling edge indicator gets
> stuffed into the 8th bit, and the byte gets pushed onto a FIFO for that
> stream. The 1KHz edges get measured similarly by using low priority
> interrupts. This keeps the measurement jitter for the high speed streams
> down. Foreground code then decodes the 4 FIFO streams as it gets around to
> it. This is done in one piece of code that has 4 pseudo-threads running in
> it.
>
> Worst case I have a little over 200 cycles average per edge, of which 45 are
> used in the interrupt to capture and measure the edge. The remaining 155
> cycles per edge average sounds like enough to do the decoding. I've worked
> out most of that but am only about 1/3 done writing it. I should know in a
> few days how well everything worked together.
Interesting.
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. For Manchester encoding
at the same data rate, the narrowest pulse is only 50uS.
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.
Once the pulse time and pulse width are known, then it's trivial to
calculate 0's and 1's and validate the data. So far, the code takes about
20 cycles per edge. (But more code is still needed..)
Here's the portion that processes rising edges:
MOVFF CCPR1L,TC_CaptureLo ;Save the time when the last edge
MOVFF CCPR1H,TC_CaptureHi ;was captured
BTG CCP1CON,CCP1M0 ;Toggle the polarity we'll capture
next.
MOVF TC_LastRisingEdgeLo,W ;Compute the time since the last
SUBWF TC_CaptureLo,F ;rising edge
MOVF TC_LastRisingEdgeHi,W ;
SUBWFB TC_CaptureHi,F
;; Rising edge. Save the time for this rising edge.
MOVF TC_CaptureLo,W ;Save the time captured for this
ADDWF TC_LastRisingEdgeLo,F ;rising edge. if X = new - old
then
MOVF TC_CaptureHi,W ; old + X = old + (new- old) =
new.
ADDWFC TC_LastRisingEdgeHi,F ;
;; At this point, TC_CaptureHi:Lo = the Bit time
;; and TC_LastRisingEdgeHi:Lo = the capture time for the edge that
cause
;; this interrupt. Now we need to validate the Bit Time and the pulse
;; width.
That's 13 cycles, but there's a little more processing that is not ready
to be shown (i.e. it ain't done yet).
4osc cycles / instruction / (10MHz * 4[pll]) ==> 0.1uS per instruction. 20
instructions per edge corresponds to about 2uS or roughly 10% of the
narrowest pulse expected. Or for 32 pulses, which is 64 edges the percent
of time spend processing is 2us/edge*64edges / (100us/pulse * 32 pulses) =
2% of the CPU's time.
I've pretty much decided to not worry about the CCP Capture race condition
because in my case it just so happens if the CCP module is capturing a new
edge while I'm processing the last edge then it's noise. If I make a
mistake processing noise, then oh well, who cares? If the noise is
mistaken as data, then the alledgedly bad data bits still have to make it
through an error correction checker.
Scott
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUT
TakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body
2003\02\24@001736
by
Scott Dattalo
|
On Mon, 24 Feb 2003, Peter L. Peres wrote:
> 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.
See:
http://www.dattalo.com/technical/theory/dtmf.html
Here the pulse stream "decoded" is a 50% duty cycle square wave. In the
real code implementation, it's actually faster to perform sequences of:
BTFSC port,bit
INCF Fc
Instead of performing a sequence of XOR's
For frequency decoders, you really need quadrature sampling.
Fortunately, only 3/4'ths of the time is spent sampling and 1/4'th spent
processing. (Sampling all 8 DTMF freqeuncies simultaneously is
challenging!)
Scott
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv
spam_OUTmitvma.mit.edu with SET PICList DIGEST in the body
2003\02\24@032515
by
so-8859-1?Q?Ing_Igor_Pokorn=FD?=
|
Great site.
Thank you.
Igor
-----Original Message-----
From: pic microcontroller discussion list [@spam@PICLISTKILLspam
MITVMA.MIT.EDU]On
Behalf Of Scott Dattalo
Sent: Monday, February 24, 2003 6:09 AM
To: KILLspamPICLISTKILLspam
MITVMA.MIT.EDU
Subject: Re: [pic]:CCP Capture mode
On Mon, 24 Feb 2003, Peter L. Peres wrote:
{Quote hidden}> 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.
See:
http://www.dattalo.com/technical/theory/dtmf.html
Here the pulse stream "decoded" is a 50% duty cycle square wave. In the
real code implementation, it's actually faster to perform sequences of:
BTFSC port,bit
INCF Fc
Instead of performing a sequence of XOR's
For frequency decoders, you really need quadrature sampling.
Fortunately, only 3/4'ths of the time is spent sampling and 1/4'th spent
processing. (Sampling all 8 DTMF freqeuncies simultaneously is
challenging!)
Scott
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuT
mitvma.mit.edu with SET PICList DIGEST in the body
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGone
mitvma.mit.edu with SET PICList DIGEST in the body
2003\02\24@045535
by
Mike Singer
|
Scott Dattalo wrote:
> For frequency decoders, you really need quadrature sampling.
> Fortunately, only 3/4'ths of the time is spent sampling and
> 1/4'th spent processing. (Sampling all 8 DTMF freqeuncies
> simultaneously is challenging!)
...
> 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
Olin Lathrop wrote:
> I'm attacking it a little differently. I've got two 10KHz and two
> 1KHz manchester streams to decode simultaneously. I just
> can't sample at 100KHz and still have any cycles left for the
> decoding and other logic. Instead I use two of the INT interrupts
> of the 18F set to high priority to measure the time between edges.
Let me take part in the combat. I have a secret mortal weapon:
"Free-running counters".
Variation with external parts:
Let us assume that we have external clock 40 MHz and some
very simple circuit that passed this 40 MHz to Timer1 when
input (Manchester) line is low; and passed 40 MHz to Timer3
when input line is high.
Let the Timers be configured as asynchronous counters.
The code should poll counters (don't know if CCP Capture
interrupts wok in asynchronous mode).
Transitions from one state to another are those when value
of one counter corresponds to Manchester period (or two)
and value of another approaches one or two period values.
No interrupt's code overhead (saving context, disabling/enabling
interrupts etc), no interrupts fired by noise (noise is integrated).
Is this expected to beat 100KHz barrier?
Hope the idea is not stupid (or is stupid enough to be interesting).
Mike.
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseME
spam_OUTmitvma.mit.edu with SET PICList DIGEST in the body
2003\02\24@052649
by
erholm (QAC)
A bit of-topic, but...
Have you thought of that,
when using handheld remotes (for e.g. a TV set), and the
betteries are beginning to run low, most people begin to
press *harder* on the keys to get a connection...
Probably more of a behavioural science questions
then an electronic question :-)
Jan-Erik Soderholm.
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistserv
TakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body
2003\02\24@063326
by
Russell McMahon
> Have you thought of that,
> when using handheld remotes (for e.g. a TV set), and the
> betteries are beginning to run low, most people begin to
> press *harder* on the keys to get a connection...
>
> Probably more of a behavioural science questions
Also a reflection of 'what the market will bear" design. Such controllers
almost invariably use PCB pattern switches with a rubber membrane with
conductive material that is pressed onto the PCB to make contact. Real
switch failures may often in fact be addressed by pressing harder or
"working" the switch. So pressing harder when the battery is expiring is a
logical action. Adding a key click/beep would provide confidence for such
low cost switches. But probably costs too much :-).
RM
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseME
.....mitvma.mit.edu with SET PICList DIGEST in the body
2003\02\24@083022
by
Roman Black
|
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)
-Roman
Scott Dattalo wrote:
{Quote hidden}> 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.
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistserv
mitvma.mit.edu with SET PICList DIGEST in the body
2003\02\24@084856
by
Alan B. Pearce
>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.
Can you get into the receiver to clamp the AGC voltage at a level
that minimises the receiver sensitivity when the transmitter is off?
I am thinking that a simple diode arrangement onto the AGC line could hold
the AGC voltage at a level that minimised the noise pulses out of the
receiver, but still gave sufficient room for the AGC to follow the
transmitted signal when that is on. This would at least give a first
solution to the problem.
As to the business of ensuring the CCP value is correct, I am sure that I
have seen items about this on the PICList in the past, maybe time to check
the archives Scott ?? :)
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservEraseME
EraseMEmitvma.mit.edu with SET PICList DIGEST in the body
2003\02\24@085059
by
Mike Singer
Roman Black wrote:
> 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.
Mike.
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUT
KILLspammitvma.mit.edu with SET PICList DIGEST in the body
2003\02\24@085949
by
michael brown
Mike Singer wrote:
> Roman Black wrote:
>> 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.
michael brown
"In the land of the blind, he who has one eye is king"
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuT
spammitvma.mit.edu with SET PICList DIGEST in the body
2003\02\24@091201
by
Alan B. Pearce
>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.
I have a feeling that this is the sort of thing that HDLC/SDLC protocol does
by bit stuffing. The requirement is that within a valid message there can be
a maximum of 4 (IIRC) 0 or 1 in a row, and if that occurs then a bit of the
opposite state is "stuffed" into the message, irrespective of the state of
the next bit. However the preamble is deliberately set up to violate this
rule for the reasons given in the quote.
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam
spamBeGonemitvma.mit.edu with SET PICList DIGEST in the body
2003\02\24@100912
by
Mike Singer
Agreed.
Mike.
michael brown wrote:
{Quote hidden}> >> 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.
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservKILLspam
mitvma.mit.edu with SET PICList DIGEST in the body
2003\02\24@102124
by
Scott Dattalo
|
On Tue, 25 Feb 2003, Roman Black wrote:
> 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)
This is a good suggestion but it has two problems. First, there will be
some jitter between when the edge occurs and when the timer is started.
The CCP module records the value of the timer at the point when the event
occurs. The second problem is that it really isn't any faster. In fact, by
the time you get through initializing/unloading/reloading the counter
you'll have spent just as much time with the roll over arithmetic. Neither
of these issues really affect my application too much.
In my application, I'm actually measuring the width of two pulses
referenced to the same edge:
___--------------___________________________---------------
|<---- P1 --->|
|<-------------------- P2 -------------->|
^ ^ ^
+- start timer| |
+ read timer |
Read timer and restart timer +
The Read/Restart action happens at every rising edge. Instead of loading a
timer and monitoring the interrupt, I could envision code like this:
movff tmrxLo, RisingEdgeLo ; save the current time
movff tmrxHi, RisingEdgeHi ; save the current time
clrf tmrxLo ; Restart the timer
clrf tmrxHi
That's about twice as fast as reading the Captured time and using rollover
arithmetic. Well, okay it's not quite twice as fast since there is some
processing that I didn't show that takes advantage of the carry bits in
the arithmetic. But instead of loading the "count down" timer with a
16-bit value and waiting for the interrupt, I think it's faster to start
and restart the timer at the edges.
In the snippet of code I posted earlier, I didn't show the falling edge
processing. It's very similar to the rising edge processing, but takes
only 9 cycles instead of 13. But for grins, here it is:
process_falling_edge:
MOVFF CCPR1L,TC_PulseLo ;Save the time when the last edge
MOVFF CCPR1H,TC_PulseHi ;was captured
MOVF TC_LastRisingEdgeLo,W ;Compute the time since the last
SUBWF TC_PulseLo,F ;rising edge
MOVF TC_LastRisingEdgeHi,W ;
SUBWFB TC_PulseHi,F
Again, for the timer start/restart approach, the falling edge processing
is about twice as fast as this.
Scott
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservSTOPspam
spam_OUTmitvma.mit.edu with SET PICList DIGEST in the body
2003\02\24@165453
by
William Chops Westfield
> Have you thought of that,
> when using handheld remotes (for e.g. a TV set), and the
> betteries are beginning to run low, most people begin to
> press *harder* on the keys to get a connection...
Some remote-like devices are (were?) actually powered through the keypad.
V+ would get wired on one side of the switches, with the other connected
to controller inputs AND sorta "wired-or" to the circuits power. That
way the device only uses power when you push a button...
BillW
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservSTOPspam
EraseMEmitvma.mit.edu with SET PICList DIGEST in the body
2003\02\24@171120
by
Peter L. Peres
On Mon, 24 Feb 2003, Jan-erik Soderholm (QAC) wrote:
*>A bit of-topic, but...
*>
*>Have you thought of that,
*>when using handheld remotes (for e.g. a TV set), and the
*>betteries are beginning to run low, most people begin to
*>press *harder* on the keys to get a connection...
*>
*>Probably more of a behavioural science questions
*>then an electronic question :-)
Yes but it could be used to light (flash) a LED or a piezo to request
battery change. Conductive rubber contacts will have a different average
resistance when pressed down hard than when pressed lightly. A micro could
observe the last 100-200 presses and request the user to push easier
and/or suggest service using this data ;-) (alternate solution: remote
controller squeaks 'ouch! that hurt!')
Peter
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservspamBeGone
mitvma.mit.edu with SET PICList DIGEST in the body
2003\02\24@184712
by
Olin Lathrop
> Yes but it could be used to light (flash) a LED or a piezo to request
> battery change. Conductive rubber contacts will have a different average
> resistance when pressed down hard than when pressed lightly. A micro
> could observe the last 100-200 presses and request the user to push
> easier and/or suggest service using this data ;-) (alternate solution:
> remote controller squeaks 'ouch! that hurt!')
Or have the button squeeze a piezo to produce the power to send the IR
code. Then pushing harder really does make it go farther <g>.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistserv
EraseMEmitvma.mit.edu with SET PICList DIGEST in the body
2003\02\25@042527
by
Roman Black
Olin Lathrop wrote:
>
>Conductive rubber contacts will have a different average
> > resistance when pressed down hard than when pressed lightly. A micro
> > could observe the last 100-200 presses
>
> Or have the button squeeze a piezo to produce the power to send the IR
> code. Then pushing harder really does make it go farther <g>.
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)
-Roman
--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-request@spam@
spam_OUTmitvma.mit.edu
>
2003\02\25@062036
by
Alan B. Pearce
>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)
I hope you already have a version of the Black switch mode
regulator that gives 5V out from 10kV in :)))))))))))))
--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-request
KILLspammitvma.mit.edu
>
2003\02\26@020704
by
Dmitriy A. Kiryashov
|
That's binary correlation. Can be done many ways actually
counting/changing or not sign/msb bit. Really depends what
you want to get from it.
"Peter L. Peres" wrote:
{Quote hidden}>
> 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.
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2003\02\26@021343
by
Dmitriy A. Kiryashov
|
Hi Igor.
I've done work for PICs using correlation with fixed frequencies.
For PLL I was using hardware but it seems possible to do it in
software as well for low frequencies. ( the same ideas )
In your case highest frequency is 500 Hz which is 2 mSec
With 20 MHz PIC and (for say) 20% of PIC time used for PLL
software you'll have 2000 clocks per sine period.
Looks quite doable.
With what speed the primary frequency can change ? ( Hz/sec)
Do you need just to decode what is frequency/amplitude/phase
or you really need to do PLL on that ? The more details the better
WBR Dmitry.
Igor Pokorny wrote:
{Quote hidden}>
> 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
>
> {Original Message removed}
2003\02\26@143550
by
Peter L. Peres
|
On Tue, 25 Feb 2003, Roman Black wrote:
*>Olin Lathrop wrote:
*>>
*>>Conductive rubber contacts will have a different average
*>> > resistance when pressed down hard than when pressed lightly. A micro
*>> > could observe the last 100-200 presses
*>>
*>> Or have the button squeeze a piezo to produce the power to send the IR
*>> code. Then pushing harder really does make it go farther <g>.
*>
*>
*>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
;-)
Peter
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2003\02\26@164251
by
erholm (QAC)
And, if an PIC draws 1 mA, how often do you
have to "ignite" to keep the PIC running ?
:-)
Jan-Erik.
Peter L. Peres wrote : [.....plpspam_OUT
ACTCOM.CO.IL]
{Quote hidden}> *>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
> ;-)
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2003\02\28@041132
by
Peter L. Peres
|
Unfortunately I was off by a little. A piezo device requires 2kgf to push
down and travel is 1cm. This works out to 0.1mJ, 200 times less than what
I said, and not considering efficiency. The cap should be 200 times
smaller for the same voltage (10uF). With 1mA drain, C=10uF, start 5V and
end voltage 3V the PIC would work for about 20msec. Check my numbers.
Peter
On Wed, 26 Feb 2003, Jan-erik Soderholm (QAC) wrote:
*>And, if an PIC draws 1 mA, how often do you
*>have to "ignite" to keep the PIC running ?
*>:-)
*>Jan-Erik.
*>
*>Peter L. Peres wrote : [TakeThisOuTplp.....
TakeThisOuTACTCOM.CO.IL]
*>
*>> *>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
*>> ;-)
*>
*>--
*>http://www.piclist.com hint: PICList Posts must start with ONE topic:
*>[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
*>
*>
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
More... (looser matching)
- Last day of these posts
- In 2003
, 2004 only
- Today
- New search...