Prev: Ocean County NJ Family-Law and Cyber-Law Lawyer Charles Novins Continues To Defend Against Net Abusers
Next: vibrators
From: Tony on 24 Apr 2010 08:26
We've been experiencing problem with a number of remote receivers over
the years using with RCMM standard in a TV type product. We started
with Vishay parts and through at least 3 cost reduction effort have
found that production parts are never the same as approval samples from
the lower priced competitors.

It seems the timing accuracy of output against optical input is a
significant variable, suppliers keep going on about increasing our
software limits so their parts will work but many are going past half
way points and they just seem to want all the tolerance for themselves.

So I need to define tolerances for each part of the system, like many
things much of these are not documented or specified anywhere. Any
opinion on the following would be useful.

1. Remote transmitter tolerance - what timing accuracy can I expect say
on burst length and cycle length. Remotes seem to use a 4Mhz resonator,
and pulse cycles are 444, 611, 777, 944us for each of the 4 levels in
RCMM. The remote supplier we are using now has copied an older remote
we had but done this inaccurately. So a sample I have measured is 2%
out from ideal, but seems fairly stable, but they do need to operate
from 0C to say 40C.

2. What tolerance on the remote receiver and how to specify? RCMM has a
varying tolerance that reduces from around 20% to 9% absolute maximum.
So should tolerance be specified as time or %. The main problem seems
to me to be jitter on the burst start detection, so is jitter a better
specification?

3. Receiving Processor/software limits- Current we operate a no-mans
land of 25us either side of the midway point. This account for
processor timing variations although I think the processsor can manage
better than 1us accuracy, so how close should one go?

At the moment I am thinking 3% for remote control 5% for receivers and
remainder for processor (+/- 2us no mans land minimum, probably 4us).

I have gotten the impression RCMM is a difficult protocol to meet and I
might try and move away from it eventually but we are stuck with it now.

--
Tony
From: Mike Harrison on 25 Apr 2010 06:28
On Sat, 24 Apr 2010 13:26:10 +0100, Tony <Nospam(a)nospam.com> wrote:

>We've been experiencing problem with a number of remote receivers over
>the years using with RCMM standard in a TV type product. We started
>with Vishay parts and through at least 3 cost reduction effort have
>found that production parts are never the same as approval samples from
>the lower priced competitors.
>
>It seems the timing accuracy of output against optical input is a
>significant variable, suppliers keep going on about increasing our
>software limits so their parts will work but many are going past half
>way points and they just seem to want all the tolerance for themselves.
>
>So I need to define tolerances for each part of the system, like many
>things much of these are not documented or specified anywhere. Any
>opinion on the following would be useful.
>
>1. Remote transmitter tolerance - what timing accuracy can I expect say
>on burst length and cycle length. Remotes seem to use a 4Mhz resonator,
>and pulse cycles are 444, 611, 777, 944us for each of the 4 levels in
>RCMM. The remote supplier we are using now has copied an older remote
>we had but done this inaccurately. So a sample I have measured is 2%
>out from ideal, but seems fairly stable, but they do need to operate
>from 0C to say 40C.
>
>2. What tolerance on the remote receiver and how to specify? RCMM has a
>varying tolerance that reduces from around 20% to 9% absolute maximum.
>So should tolerance be specified as time or %. The main problem seems
>to me to be jitter on the burst start detection, so is jitter a better
>specification?
>
>3. Receiving Processor/software limits- Current we operate a no-mans
>land of 25us either side of the midway point. This account for
>processor timing variations although I think the processsor can manage
>better than 1us accuracy, so how close should one go?

Accurate timing on the processor usually costs nothing to manufacture, just better software so it
would seem silly to squander budget here if other areas are marginal.

>At the moment I am thinking 3% for remote control 5% for receivers and
>remainder for processor (+/- 2us no mans land minimum, probably 4us).
>
>I have gotten the impression RCMM is a difficult protocol to meet and I
>might try and move away from it eventually but we are stuck with it now.

Having done quite a few IR implementations I'd never spec a system that used more than 2 pulse
lengths (except maybe a long pulse as start/sync marker) , as pulse length varies significantly with
link quality, ambient light etc. IR receiver performance is also dependent on the range of pulse
lengths.
I've never heard of RCMM, but all the common European consumer protocols I've encountered
(RC5,RC6,Sky) have essentially 2 pulse lengths, so this is what most IR receivers are designed to
work with.
I only use Vishay receivers, but this is mainly as my stuff is often very low-power and the Vishay
has a very fast and consistent power-up to 'ready' time and available in 3v versions.
From: Tony on 26 Apr 2010 05:08
Mike Harrison wrote:
> On Sat, 24 Apr 2010 13:26:10 +0100, Tony <Nospam(a)nospam.com> wrote:
>

>>
>> 3. Receiving Processor/software limits- Current we operate a no-mans
>> land of 25us either side of the midway point. This account for
>> processor timing variations although I think the processsor can manage
>> better than 1us accuracy, so how close should one go?
>
> Accurate timing on the processor usually costs nothing to manufacture, just better software so it
> would seem silly to squander budget here if other areas are marginal.
>

Yes that's what I thought, although it not so much better as more
tolerant. Mistaken are worse than non received ones IMO. It just I am
not 100% sure what the accuracy is, its a VCXO which varies for various
reasons, but the swing and clock accuracy have been included in the 1us.
Having said that the Vishay works fine with RCMM with the larger
no-mans land.

>> At the moment I am thinking 3% for remote control 5% for receivers and
>> remainder for processor (+/- 2us no mans land minimum, probably 4us).
>>
>> I have gotten the impression RCMM is a difficult protocol to meet and I
>> might try and move away from it eventually but we are stuck with it now.
>
> Having done quite a few IR implementations I'd never spec a system that used more than 2 pulse
> lengths (except maybe a long pulse as start/sync marker) , as pulse length varies significantly with
> link quality, ambient light etc. IR receiver performance is also dependent on the range of pulse
> lengths.

The IR burst length does vary in reception as you would expect (and
software has a large margin for this), but cycle should be more
accurate, however optical power is still a big variable for pulse
length. The software triggers on cycle, but since the receiver varies
so much on trigger time (or jitter on the start) with optical power it
can affect the pulse length.

> I've never heard of RCMM, but all the common European consumer protocols I've encountered
> (RC5,RC6,Sky) have essentially 2 pulse lengths, so this is what most IR receivers are designed to
> work with.
> I only use Vishay receivers, but this is mainly as my stuff is often very low-power and the Vishay
> has a very fast and consistent power-up to 'ready' time and available in 3v versions.

RCMM was designed for PC wireless stuff like keyboards and mice
according to SBprojects.coms, why we every chose it I do not know, its
not like we need the bandwidth.

The Vishay stuff is good, it also works better in sunlight, although in
my testing I have noticed the burst length does occasionally go outside
our software limits.

--
Tony
 | 
Pages: 1
Prev: Ocean County NJ Family-Law and Cyber-Law Lawyer Charles Novins Continues To Defend Against Net Abusers
Next: vibrators