Searching \ for '[PIC] generating different pseudo random sequence' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/math/index.htm?key=random
Search entire site for: 'generating different pseudo random sequence'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] generating different pseudo random sequence'
2005\06\26@201603 by Chen Xiao Fan

face
flavicon
face
Sorry to change the subject again but the thread is too
long to follow and quite some of them are not pertaining
to my problem.

Take note that my read need is to generate different
sequence for different sensors using the same firmware.

Serialization could be the solution here but it is a
problem with the production. We decide against using
ICSP for the mass production since last year for new
design due to the fact there is no production quality
ICSP programmer out there and the complexity of using
ICSP (our board is too small to allow big test pads
and this cause problem as well). The gang programmer
we use may not have the capability to serialize the
programming and in the past we have to generate quite
some hex files for the programmer and cause confusions
for the operator. That is the reason not to use
serialization.

Therefore it comes the problem, what is the proper
method to generate different sequence for different
sensors using the same firmware? Now I think it is
actually better to use kind of look-up table. The
limitation here is also the relative low speed MCU
here and relative fast response time required.


Regards,
Xiaofan

{Original Message removed}

2005\06\26@211619 by Timothy J. Weber

face
flavicon
face
Chen Xiao Fan wrote:
>
> Take note that my read need is to generate different
> sequence for different sensors using the same firmware.

Could you program a unique serial number with a one-time setup mode,
where you have an operator power it on, then ground some pin that's
normally pulled high, then count instruction cycles until the operator
lifts the pin again, then write that count into an EEPROM location?  You
say test pads are hard to put in, so maybe this still wouldn't be any
easier than ICSP.

Or, what about using the length of the first series of "output 1's"
produced, and storing that as your random seed?

Or you could fold the last N pulse values into the algorithm along with
your pseudorandom value; might be tricky to model the behavior of
multiple sensors and ensure you're not biasing the detection in some way
though.
--
Timothy J. Weber                 http://www.lightlink.com/tjweber
spam_OUTtjweberTakeThisOuTspamlightlink.com

2005\06\26@215246 by Chen Xiao Fan

face
flavicon
face
The MCU is now using off-line programming. The production
people like this. Then the MCU is the same as the other
SMT components.

The suggestion to use EEPROM to store the seed is feasible.
I have a test pin on the MCU. This will be done during the
IAT (in array testing). The problem with ICSP is that it
uses more test pins and takes longer time. It jams the IAT
and thus jams the whole production process. This should be
better than ICSP. But it would be better to reduce the testing
time and forgo this extra process.

What do you mean by "the length of the first series of
output 1's produced"? I do not quite catch you.

Regards,
Xiaofan

{Original Message removed}

2005\06\26@231127 by Chen Xiao Fan

face
flavicon
face
Sorry but how to do that? I am using PIC12F629
which has a 16 bit timer Timer 1.

Regards,
Xiaofan

{Original Message removed}

2005\06\26@232451 by Chen Xiao Fan

face
flavicon
face
Looks very interesting and this is maybe what I need. I still
need to generate a different starting seed for different sensors
though.

Regards,
Xiaofan

{Original Message removed}

2005\06\27@003527 by William Chops Westfield

face picon face
On Jun 26, 2005, at 8:24 PM, Chen Xiao Fan wrote:

> need to generate a different starting seed for different sensors
>
I don't think you can guarantee different self-picked numbers without
either manual intervention, or some sort of negotiation scheme.

BillW

2005\06\27@030324 by Jinx

face picon face
>> I'd try to work WDT in there somewhere

> Sorry but how to do that? I am using PIC12F629
> which has a 16 bit timer Timer 1

Off the top of my head -

1) Enable TMR1osc, using anything up to a 200kHz xtal. Put the
PIC to SLEEP, with WDT wake-up. TMR1 will continue to run
during SLEEP, so you can use it as a counter between these WDT
wake-ups

2) a simple external transistor oscillator feeding T1CKI, as an
alternative to a xtal

3) any timer's contents TMR1 are unchanged on WDT reset, if you
choose to go this way rather than SLEEP. See Section 14.4, Table
14.4. This would have the advantage of using the 628's Fosc as
the incrementer, which would give much higher resolution than a
relatively slow xtal on T1osc, and more chance of randomness in
the LSBs

2005\06\27@032103 by Jesse Lackey

flavicon
face
I now do a trick for any design that needs random #s.  I just need a
good seed value for rand():

On power-up I either add the contents of RAM as a 32-bit value, or if I
have more codespace and need a better random # I do a CRC32 of the
contents of RAM.  Either way this value is printf-ed so I can get the
same sequence later if need be for debugging.

So this becomes the call to srand().

Of course this is for C, but if using assembler the same trick applies.

J


William Chops Westfield wrote:

> On Jun 26, 2005, at 8:24 PM, Chen Xiao Fan wrote:
>
>> need to generate a different starting seed for different sensors
>>
> I don't think you can guarantee different self-picked numbers without
> either manual intervention, or some sort of negotiation scheme.
>
> BillW

2005\06\27@034627 by William Chops Westfield

face picon face

> I now do a trick for any design that needs random #s...

Yeah, but if you need a UNIQUE random number (to differentiate between
multiple sensors, as the OP requires), that's different.  "random" and
"unique" are sort contadictory...

BillW

2005\06\27@034759 by Scott Dattalo

face
flavicon
face
On Mon, 2005-06-27 at 08:15 +0800, Chen Xiao Fan wrote:

> Sorry to change the subject again but the thread is too
> long to follow and quite some of them are not pertaining
> to my problem.

I don't have a solution for yet another PRNG (Andrew's and Nikolai's I'm
sure are just fine). But, I could suggest stepping back and looking at the
problem from a slightly different angle. I recall from an earlier post
something about 4uS wide pulses. I don't recall if the processors are
running from RC or XTAL. Nor do I recall how the processors are awakened.
But how likely is that when you "start up the system" that the processors
remain perfectly synchronized such that 4uS pulses collide? In fact, how
can you even ensure that the processors start at the same time? I bet if
your problem was reversed and you wanted the processors to be synchronized
that it'd be impossible to do without resorting to some exotic technique
(like running them off of the same clock or phase locking to some control
signal).

Also, I don't recall any discussion about what it is the sensors are
sensing. Presumably the sensor data varies from sensor to sensor, so why
not use that as a "random seed". In fact, you may even be able to infer
something from the collisions (like two or more sensors are reading the
same data if there is a collision).

Finally, even if you have a perfectly designed PRNG to randomize your
collection of perfectly synchronized PICs, there is *still* a chance that
collisions will occur.

Scott

2005\06\27@043537 by Alan B. Pearce

face picon face
>Serialization could be the solution here but it is a
>problem with the production. We decide against using
>ICSP for the mass production since last year for new
>design due to the fact there is no production quality
>ICSP programmer out there and the complexity of using
>ICSP (our board is too small to allow big test pads
>and this cause problem as well). The gang programmer
>we use may not have the capability to serialize the
>programming and in the past we have to generate quite
>some hex files for the programmer and cause confusions
>for the operator. That is the reason not to use
>serialization.

Why not get Microchip to supply pre-programmed chips? They will serialise
them for you as part of the programming sequence.

2005\06\27@043817 by Chen Xiao Fan

face
flavicon
face
What I need is not really "unique" and "random". For side
by side sensor mountings, normally you only need to
make sure that the adjacent sensors do not see each other
(by way of optics and firmware). It can not be 100%
error proof. The major limitation is from the settling
time of the front end trans-impedance amplifier. The
firmware will help to achieve as good as possible
result but will not be 100% correct.


Regards,
Xiaofan

{Original Message removed}

2005\06\27@044215 by Chen Xiao Fan

face
flavicon
face
That is the problem with long thread. :(
Let me repeat what I have said.

I mentioned that it is an optic proximity switch and
it senses light (visible red light in this case, can
be infrared as well). It is a 12F629 with 4Mhz internal
oscillator.

In one version, the emitter LED emits 4us pulse with an
average period of about 100us (random pulse period).
The trans-impedance amplifier amplifies the received
signal from the PIN diode and feeds it to the PIC
comparator input. The MCU compares the signal with the
pre-set threshold and decide the output (transistor
output).

The digital filter is very simple. If the signal is above
the threshold, it will add 1 to the filter counter and minus
1 if below the threshold. Once the filter counter reach 0,
the output will be switched off. Once the filter counter reach 0,
the output will be switched off. With a filter depth of 8,
I can achieve 1ms response time in the worst case (with
no strong noise).

The PIC never goes to sleep (wake-up is too slow). The
sensors are not synchronized. They can be power up
at any time. They do not have communication between
them.

For side by side sensor mountings, normally you only need to
make sure that the adjacent sensors do not see each other
(by way of optics and firmware). The solution is to
pulsing the sensors at a random sequence so that it
does not see the adjacent sensors' emitted light.
It is okay for the sensors occasionally sees the
adjacent sensor but it should not overcome the digital
filter.

You are correct that it can not be 100% error proof. The
major limitation is from the settling time of the front
end trans-impedance amplifier. The firmware will help to
achieve as good as possible result but will not be 100%
correct.

In this case, the emitter and the receive are in the
same unit so the MCU knows when to sense the light.

In the through-beam sensors, the emitter unit and
the receiver (which has the MCU) unit are not in
the same sensor, it is much more difficult to achieve
any good results because of asynchronous detection.
Therefore the only solution is to using different
pulsing frequency.

Regards,
Xiaofan

{Original Message removed}

2005\06\27@045142 by Chen Xiao Fan

face
flavicon
face
I can do that only after the firmware gets stable and
the volume goes up but I doubt it will even happen.

This is my first assembly based PIC firmware and the
initial order quantity will not be that high for
Microchip to supply SQTP parts to us. They need to
have 25k per order for SQTP.

My first project (a simple software using PICC C compiler)
is using SQTP but it is after the product was launched
for two years. It is cheaper than in-house programming.
And the quantity is much higher (more than 100k per year).
It also has gone through extensive reviews.


Regards,
Xiaofan

-----Original Message-----
From: Alan B. Pearce [.....A.B.PearceKILLspamspam@spam@rl.ac.uk]
Sent: Monday, June 27, 2005 4:36 PM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] generating different pseudo random sequence using the
same firmware

Why not get Microchip to supply pre-programmed chips? They will serialise
them for you as part of the programming sequence.

2005\06\27@075515 by olin piclist

face picon face
Chen Xiao Fan wrote:
> Looks very interesting and this is maybe what I need. I still
> need to generate a different starting seed for different sensors
> though.

These things are analog sensors, right?  Why not use the measured analog
value to perturb a simple digital pseudo random number generator
occasionally.  Or, compute a CRC (very easy to do in firmware) from
successive low bits of the A/D.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\06\27@085109 by Timothy J. Weber

face
flavicon
face
Chen Xiao Fan wrote:
> What do you mean by "the length of the first series of
> output 1's produced"? I do not quite catch you.

I was talking about something similar to what Olin just suggested.  You
could do it just once, or continuously, but generally using either the
A/D data or its timing (e.g., how long between events or how long an
event lasts) as a seed.
--
Timothy J. Weber                 http://www.lightlink.com/tjweber
tjweberspamKILLspamlightlink.com

2005\06\27@101756 by Scott Dattalo

face
flavicon
face
On Mon, 2005-06-27 at 16:42 +0800, Chen Xiao Fan wrote:

> That is the problem with long thread. :(
> Let me repeat what I have said.

Sorry to have to make you repeat...

So far Olin, Timothy and I have made a similar suggestion that I think is
worth repeating: use your data as a source of random noise.

But I don't even think you need a random noise source. Here's even another
suggestion. The problem as I understand it, is one unit emits a 4us pulse
of light every 100us and you want to make sure that other units are not
affected. Right?

Well, suppose you capitalize on this parasitic coupling to control your
timing? In other words, you know when the 4uS pulse is transmitted and you
should be able to estimate the delay to know when it is received. One way
of estimating the delay is to measure and filter it. Now, if you receive a
pulse and it happens to not be in your acceptable time-reception window,
reject it and adjust your next transmitted pulse in a direction away from
the interference. With this scheme, interfering sensors will servo away
from one another and non-interfering sensors will do nothing (since
they're not affected by neighboring sensors).

Scott

2005\06\27@104852 by Scott Dattalo

face
flavicon
face
On Mon, 2005-06-27 at 07:17 -0700, Scott Dattalo wrote:
On Mon, 2005-06-27 at 16:42 +0800, Chen Xiao Fan wrote:
>
> > That is the problem with long thread. :(
> > Let me repeat what I have said.
>
> Sorry to have to make you repeat...
>
And before you have to repeat yourself again, here's a solution that
addresses the separate transmitter and receiver. In this system, you have
one unit that transmits a pulse and another unit that receives. There's no
feedback between the two so you can't use the servo scheme I (and perhaps
others) suggested.

However, what you can do is encode your transmitted pulses. In such a way
it's obvious when there's collision. For example, suppose instead of
transmitting a single 4uS pulse, you transmitted two of them separated by
a fixed gap of say 10uS. Then the receiver knows that when a pulse is
received, 10uS later there will be another one coming. If this 10uS gap is
violated then you know two transmitters are interfering and that you
should reject the pulses. Meanwhile, adjust the frequency in a fixed
pattern such that you know when the next pair of pulses is to occur. In
other words, instead of a fixed 100uS period, vary the period like 90, 94,
98, 102, 106, 110, 106, 102, and so. By measuring the period, a receiver
can anticipate when the pulses are to come in. Also, you're counting on
the natural system slop in such a way that two coincidentally synchronized
transmitters will eventually drift apart.


Now I'll ask the obvious question. If two through-beam sensors are really
interfering, then how can the system possibly ever work? I mean, if a
receiver is receiving pulses how can it correlate those with its
designated transmitter? Or, is it case that the interfering sensor is
*only* a factor whenever it just so happens to transmit a pulse that
directly overlaps a validly transmitted pulse? And this overlap perturbs
the comparator?

Scott

2005\06\27@195009 by Chen Xiao Fan

face
flavicon
face
Oh if I used 12F675, then I will probably get an AD value from the
received signal. But I am using a 12F629 with internal comparator
and comparator reference. I will change the comparator reference
depends on the sensor status (to generate hysteresis so that sensor
output does not jitter).

I only get a binary value from it. The incoming signal is a negative
going signal. If it is below the threshold, I got the comparator
interrupt flag changed. I detect this flag after sending out the
pulse for 3us (due to the delay of the amplifier).

Regards,
Xiaofan

{Original Message removed}

2005\06\27@201217 by Chen Xiao Fan

face
flavicon
face
Thanks for the answer and you understand the issues very
clearly.

In the case of retro-reflective sensor (the light will be
reflected by a reflector if no object is blocking the light) and
diffusive sensor (the object's diffusive surface reflect the light
to the sensor receiver), the emitter and the receiver are in the
same unit and we know when exactly the light will come back (the
response time of the photo diode/photo transistor and the trans-
impedance amplifier).

What you suggested is exactly what we do in the higher-end sensors.
You check the time when the interference occurs and calculate
when to send the next pulse. The aim is avoiding overlap of pulse.
You need a fast MCU with relative fast ADC or comparator to
get better result.

There is a catch though, you still need to fulfill the response
time requirement and ultimately you still need to send out the
pulse.

For my low end sensor, I do not have the time to do this kind
of trick. However I still do one thing, before I send out the
pulse, I check if there is an interference, delay my pulse
if detected. I do it for 2 times since I can not afford more.
This scheme and the random pulse together can already achieve
relative good result to reject mutual interference (same
family of sensors or similar fixed pulse frequency emitters
from other sensors).

There is two more types of interference. Firstly low frequency
50Hz/60Hz ambient light, that is normally filtered out by design
of the amplifier, the optics and the digital filtering.

Secondly, the HF light (those energy saving fluorescent lamp)
which can emit light of 10K-100Khz. That is a big problem and
so far there are no 100% error proof solution. The requirement
for the sensors in the presence of the HF light is that the
output should not to jitter.


Regards,
Xiaofan

{Original Message removed}

2005\06\27@213911 by olin piclist

face picon face
Chen Xiao Fan wrote:
> Oh if I used 12F675, then I will probably get an AD value from the
> received signal. But I am using a 12F629 with internal comparator
> and comparator reference. I will change the comparator reference
> depends on the sensor status (to generate hysteresis so that sensor
> output does not jitter).

Still, you have an external event not correlated to the PIC oscillator.
Even the snapshot of a free runnning timer 0 when the external edge is
detected is enough to influence identical random number generators in
different PICs to emit different sequences.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\06\27@220907 by Chen Xiao Fan

face
flavicon
face
Oh yes I have a free running Timer 1. So you mean I can take a
snapshot of the Timer 1 (say TMR1L) when signal is detected
and feed it to the random number generator. Good idea.

Before sending out the pulse, the firmware also check if there
is an interference and delay the pulse. This scheme and the
random pulse together can already achieve relative good result
to reject mutual interference (same family of sensors or
similar fixed pulse frequency emitters from other sensors).

It seems that there are a lot of tricks that I can do and
I learn quite a lot (still digesting) from the list. Thanks
a lot!

Regards,
Xiaofan

{Original Message removed}

2005\06\27@221728 by Chen Xiao Fan

face
flavicon
face
Another related issue is the digital filter methods.
Right now I have two choice. I am using a simple +1/-1
method now. The filter counter will be increased by
1 (up to 8) or decreased by 1 (down to 0). The output
will be triggered when the counter reaches 8 (or 6 and then
promoted to 8) or 0. Another slightly different scheme
is to trigger the output when the counter reaches
6 (then promote it to 8) or 2 (then downgrade it to
0).

The other idea is to use a shift register, every time
when the MCU detected the signal, it shifts a 1 into the
shift register. Only 8 consecutive detected signal (or
undetected signal) will trigger the output. It will reject
the noise better but then it will slow the response time
significantly even in the low noise situation.

Any better solutions?

Regards,
Xiaofan

2005\06\27@223200 by olin piclist

face picon face
Chen Xiao Fan wrote:
> Another related issue is the digital filter methods.
> Right now I have two choice. I am using a simple +1/-1
> method now. The filter counter will be increased by
> 1 (up to 8) or decreased by 1 (down to 0). The output
> will be triggered when the counter reaches 8 (or 6 and then
> promoted to 8) or 0. Another slightly different scheme
> is to trigger the output when the counter reaches
> 6 (then promote it to 8) or 2 (then downgrade it to
> 0).
>
> The other idea is to use a shift register, every time
> when the MCU detected the signal, it shifts a 1 into the
> shift register. Only 8 consecutive detected signal (or
> undetected signal) will trigger the output. It will reject
> the noise better but then it will slow the response time
> significantly even in the low noise situation.
>
> Any better solutions?

The more you taylor the detection algorithm to the expected pulse the
better.  You have a minimum and maximum valid pulse duration, so it's
probably a good idea to use that.  You could also send specially coded pulse
sequences so that it's virtually impossible for random noise look like a
real signal.

Even just sending the "pulse" as a burst of a known frequency will help a
great deal with signal to noise ratio.  If you can send a burst of 10 cycles
at 35-50 KHz, then you can use a standard IR remote detector like is built
into VCRs, TVs, and lots of other things.  These do all the IR receiving,
gain adjustments, and carrier detection for you.  You give them +5V and GND,
and they return a digital signal indicating presence of carrier.  They
usually require minimum bursts of 10 carrier cycles.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\06\27@230903 by Chen Xiao Fan

face
flavicon
face
Interesting idea. The remote control is probably much cheaper
than our sensors but most likely it is too big for us to use.
We are using as small as possible components here. For example,
we are using tiny QFN parts more and more. In case of
inductive sensors, the sensor is often smaller than the
cable connectors. In case of optic sensors, it is still not
that bad but the trend is getting smaller.

I have not measured the pulsing current of these remote controls,
I guess that they are not high enough to fully utilize the
IR emitters. We are pulsing them at the limit in order to
achieve longer sensing distance yet keep the current consumption
low. If the emitter is allowing 750mA then we will probably
pulse them at 700mA (a bit of safety margin). Therefore
we may not be able to send two pulse with too small pause.
The sensing distance of an optic sensor ranges from several
millimeter to 10s of meters (visible light or infrared) or even
higher (using laser diode). The other thing is the relative
fast switching frequency required (the higher the better).

Anyway I see your point and will consider it in future
applications. This is also applicable to all kinds of
sensors: level sensors, capacitive sensors, ultrasonic
sensors, etc.


Regards,
Xiaofan

{Original Message removed}

2005\06\28@103526 by Scott Dattalo

face
flavicon
face

Chen,

Here's a technique for generating pulses and capturing pulses that I use
on resource constrained PIC's like the ones you describe in your sensors.
The technique is 'isochronous coding', isochronous means 'equal time' and
when applied to coding means that all paths through the software take the
same time. Sometimes this can be challenging (see for example:
http://www.dattalo.com/technical/software/pic/pwm256.txt) or it could be a
simple loop. But the basic idea is that the rate at which the processor
excutes instructions sets the timing for the system. This statement at
face value seems obvious, but usually it's much easier to use hardware
peripherals and interrupts to set the system timing.

For your pulse generator, the basic flow is thus:

int delay_dither=0;          // amount we'll dither led driving
const int TotalDelay = ...   // total delay time in loop
const int DitherMask=0xf;    // there are 16 dither states.

Loop:

  Delay(TotalDelay/2 - delay_dither);

  LED_Pulse();

  Delay(TotalDelay/2 + delay_dither);

  delay_dither = (delay_dither+1) & DITHER_MASK;

  goto Loop


In this psuedo code, the LED is pulsed once per loop iteration. The total
time for the loop is constant. However, the time the LED is actually
pulsed is dithered over 16 states.

The LED_Pulse() is a macro. Since there is only one thing being done here,
it's useful to define the total loop delay in the macro. In your case this
snippet of code is:

LED_Pulse macro

const int TotalDelay = 100us - time_to_pulse_LED

  LED_out = high;
  Delay(4us)
  LED_out = low;

endm

However keeping it as a macro, you could also write it like this:

LED_Pulse macro

const int TotalDelay = 100us - 2*time_to_pulse_LED - 10uS

  LED_out = high;
  Delay(4us)
  LED_out = low;

  Delay(10uS)

  LED_out = high;
  Delay(4us)
  LED_out = low;

endm

Anyway, what I'm trying to illustrate here is a technique that allows you
to write isochronous code in such a way that you can vary the behavior
without affecting the timing. This is not too unlike Olin's recent
suggestion of deriving all timing based parameters from a single constant.


The pulse detector is a little trickier since there are essentially three
things that have to be accomplished. First, the pulse has to be detected.
Next, there has to be some determination as to whether the pulse is valid.
Finally, it has to be filtered. I assume in your system the pulse is
received both through the comparator and through an I/O pin (otherwise,
how do you differentiate a small pulse from no pulse?).

Loop:

  CommunicateWithOutsideWorld();

  WaitForPulse();

  ValidatePulseSequence();

  FilterPulse();

  goto Loop

Again, keeping everything as a macro enables you to separate distinct
parts. The first macro conveys the state of the firmware to something. I
have no idea what that is in your case. The pulse detection can look like:


WaitForPulse macro

L_WaitForPulseLoop:
  waiting = 0

  if (No Pulse)
     waiting++;
     if (waiting < WAITED_TOO_LONG)
       goto L_WaitForPulseLoop;
     else
       goto Loop;  // haven't seen a pulse in a long time.

  // okay we've detected a pulse. Validate the arrival time

  if (!isValidArrivalTime(waiting))
     goto Loop
 endm

A subtle point is that the 'isValidArrivalTime()' macro can either check
that waiting is less than some constant or less than a variable. The
variable can be a servo'd one that is designed to track the dither pulse
transmitter.

The ValidatePulseSequence in your case just checks to make sure that the
pulse is narrower than some threshold of say 6uS. This way, noise induced
by florescent lights or whatever can get rejected. Or if you wish, it can
be designed to detect the 2-pulse modulation.

ValidatePulseSequence macro

   BTFSS  PULSE_PORT,PULSE_BIT
    SKIP
   BTFSS  PULSE_PORT,PULSE_BIT
    SKIP
   BTFSS  PULSE_PORT,PULSE_BIT
    goto  L_ValidPulse
   goto   Loop       ; Oops, this pulse is too long

L_ValidPulse:

 endm

SKIP is a macro that consists of ' goto $+2 '. I realize you can shorten
this code by changing the polarity of the tests, but as written it can be
extended for arbitrary lengths.

Finally, the last macro 'FilterPulse' is the subject of another message.

Scott

2005\06\28@235642 by Chen Xiao Fan

face
flavicon
face
Thanks a lot for the detailed explanation and your code is
always excellent.  

I got to know 'isochronous coding' in my through-beam version
(asynchronous detection) software just recently. It is such
a simple software yet I have spent such a long time to develop
it. I am now counting instructions for the version. Even without
those advanced features, this "simple" 0.3k program proves to be
more difficult than expected. :(

For the synchronous detection version, I think your idea is great.
I am using a timer for the loop timing. The pulse photo current
(normally 0.1uA and up) is amplified by a band-pass trans-impedance
amplifier (typically 10~50 MegOhm trans-impedance). The amplified
voltage is then feed to the MCU (mostly comparator input pin or
ADC input pin). The dynamic range is a problem for the amplifier.
LOG amplifier is actually better because the signal is normally
proportional to 1/(x^2) or 1/(x^4) with x being the distance.

Your pseudo loop is what exactly happens here in both the synchronous
detection and asynchronous detection cases.

CommunicateWithOutsideWorld() is normally send out the output and
set the status of indicator LEDs. It can be more complicated as well.

WaitForPulse() is normally combined with CommunicateWithOutsideWorld().
isValidArrivalTime() is a bit difficult using the low end MCUs.

The ValidatePulseSequence() is more difficult. The pulse is normally
shorter than the pulse time of the emitter. However it can be longer
if the amplifier is saturated. The settling time of the amplifier
plays a big part as well. So in the higher end sensor, we can
dynamically adjust the gain but it is still hard to guarantee
that no saturation can happen.

Noise generated by HF light can be very short pulse and is not
so easily rejected by ValidatePulseSequence() alone.

The 2-pulse modulation is interesting and actually some vendors
do that in their ASICs.

Looking forward to see your post on the FilterPulse(). Thanks really
a lot for your detailed explanation.

Regards,
Xiaofan

{Original Message removed}

2005\06\29@104804 by Scott Dattalo

face
flavicon
face
On Wed, 2005-06-29 at 11:56 +0800, Chen Xiao Fan wrote:

> Looking forward to see your post on the FilterPulse(). Thanks really
> a lot for your detailed explanation.

Well, I was hoping that others would've chimed in by now in the other
thread you started on how to filter your pulses. But the reason they
probably haven't is because without more information about your system,
there's no way to design a filter. So stating the obvious, a filter must
separate the noise from the signal. This means you have to know the
characteristics of each.

You've briefly alluded to a few noise sources: fluorescent lights, 50/60
Hz stuff, and neighboring sensors. You really haven't described the signal
other than to say that it consist of pulses and that you'd like to detect
them fast as possible. I can infer from your earlier posts that a 1 mS
signal detection time is acceptable, but that you really want something
like 400 or 500 uS. I have no idea what your detectors are attempting to
detect. I mean, I know they're proximity detectors, but are you wanting to
detect bullets coming from the muzzle of a rifle or count Furbies on a
conveyor belt? These two 'signals' have distinctly different
characteristics, and I'm sure your marketing department wants you to be
able to detect both! :)

Before pretending that I can propose a filter, I think you'll find that
the two techniques of pulse rejection mention so far (varying the pulse
timing and measuring the pulse width) can go a long way in rejecting
noise. While you agree in principle that these are good ideas, you've
suggested that amplifier-introduced distortions limit their usefulness.
I'd suggest fixing the amplifier! For example, have you ever investigated
a cascading logarithmic amplifier? I think you could construct a 3 stage
transistor amplifier following a simple preamp. The output of each stage
can be monitored with PIC I/O pins. This essential becomes a 3-bit
logarithmic ADC with a dynamic range of something like G^3 where G is the
gain of each stage:

signal --> preamp --> LinAmp --+--> LinAmp --+--> LinAmp --+--> ...
                               |             |             |
                             I/O 0         I/O 1         I/O 2

The 'LinAmp' is a transistor-based linear amplifier that is *designed* to
saturate. I won't elaborate much more because a) I'm not expert in this
area and b) I'm sure there are other physical constraints in your system.
I can say that a single BJT, 4 resistors, and 2 capacitors can make a
decent single stage. Also, another subtle feature is that the I/O pins can
also be controlled outputs from the PIC. This could be used to create some
form of active noise cancellation (e.g. 50/60 Hz noise could be rejected
by adding an active source that's out of phase).

But sticking with the amplifier you have already, the filter you proposed
before seems reasonable enough. Here's  a variation that is fast:

   MOVLW   1
   BTFSS   PULSE_PORT,PULSE_PIN
    MOVLW  -1
   ADDWF   FilteredPulse,W
   BTFSC   FilteredPulse,3
    COMF   FilteredPulse,W
   ANDLW   0b00000111
   MOVWF   FilteredPulse

Here's the C-version that may be easier to follow:

   if (bPulse) {
     // Pulse is high
     if (++FilteredPulse > 8)
       FilteredPulse = 7;
   } else {
     // Pulse is low
     if (--FilteredPulse < 0)
       FilteredPulse = 0;
   }

The filtered signal can be bit 2 of the filtered pulse:

   BCF   Signal,0
   BTFSC FilteredPulse,2
    BSF  Signal,0

Scott

2005\06\30@000044 by Chen Xiao Fan

face
flavicon
face
part 1 4299 bytes content-type:text/plain; (decoded quoted-printable)


Okay, let me elaborate how a optic proximity switch works.

An optic proximity switch contains the housing, the lens
(typical a pair: emitter and receiver lens),
the sensor electronics and the cable/plug connectors.

The typical sensor electronics contains the following part.
 Supply Input Stage : normally 10~30V DC -> 5V and 7V DC
  For ACDC sensors, typically 12V~240V DC and 24V~240V AC
 Emitting Stage: LED driving (constant pulse current)
 Receiving Stage: Photo diode or Photo transistor amplifier
 Amplification Stage: OPAMP or discrete based amplification
 Optional Sample & Hold Stage: to sample the signal .  signal evaluation stage: typical  an ASIC or a MCU with
  comparators or ADCs
 Output Stage: normally transistor output (PNP/NPN/Push-Pull)
  for the DC versions (higher switching frequency) and relay    for the ACDC versions (lower switching frequency)

The leading vendors are SICK (http://www.sick.de), OMRON
(http://www.omron.com), Banner Engineering (http://www.bannerengineering.com/) and Visolux (http://www.pepperl-fuchs.com, part of Pepperl+Fuchs group) and others. Some of the typical application is Door-Gate-Lift (like the elevators) and Packaging industry (eg. conveyor belt,
to detect the various object on the conveyor belt). The target
can be a person entering or leaving the door, a bottle
of beer in the conveyor belt, bonding wire of a wire-bonding
machine, ...

The standard benchmark target is the 90% Kodak white card and
15% gray card. The sensing distance is greatly depending on the
target just like what you mentioned. So sometimes the sensor has a sensitivity adjustment element  like a potentiometer which adjust the gain or the emitter current or the threshold to adjust the sensing distance. There are some higher-end sensor (background
suppression sensors) which can achieve similar sensing distance for different target by using multiple receivers.

The cheapest pre-amplifier looks like the attached amplifier.jpg. It will typically followed by another two stages of post-amplifier. Overall they form a trans-impedances amplifier with around 30 Meg Ohm of trans-impedance. If the receiver has a 50nA photo current, the amplified signal will be about 1.5V. A typical waveform will be like the attached signal.jpg. When the signal got saturated, the bottom will be flat out and looks like the attached signal_sat.jpg.
Normally we only detect the signal at the falling edge of the pulse
(after some delay if the amplifier is slower). In the waveforms, the top channel 2 is the emitter LED pulsing current and the bottom is the final amplified signal being fed to the MCU analog input pin.

Normally the response time requirement is 500us (1kHz switching
frequency) or 1ms (500Hz). If we have a loop time of 100us, we can use digital filter depth of 4 or 8 (with 20% safety margins).

Regards,
Xiaofan



{Original Message removed}
part 2 9792 bytes content-type:image/jpeg; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\06\30@000428 by Chen Xiao Fan

face
flavicon
face
part 1 1045 bytes content-type:text/plain;signal.jpg
signal_sat.jpg is similar but the bottom is flat and longer.

-----Original Message-----
From: Chen Xiao Fan
Sent: Thursday, June 30, 2005 11:46 AM
To: 'Microcontroller discussion list - Public.'
Subject: RE: [PIC] generating different pseudo random sequence using the
same firmware

The cheapest pre-amplifier looks like the attached amplifier.jpg.
It will typically followed by another two stages of post-amplifier.
Overall they form a trans-impedances amplifier with around 30 Meg
Ohm of trans-impedance. If the receiver has a 50nA photo current,
the amplified signal will be about 1.5V. A typical waveform will be
like the attached signal.jpg. When the signal got saturated, the
bottom will be flat out and looks like the attached signal_sat.jpg.
Normally we only detect the signal at the falling edge of the pulse
(after some delay if the amplifier is slower). In the waveforms,
the top channel 2 is the emitter LED pulsing current and the bottom
is the final amplified signal being fed to the MCU analog input pin.





part 2 30683 bytes content-type:image/jpeg; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\06\30@010409 by Scott Dattalo

face
flavicon
face
On Thu, 2005-06-30 at 12:00 +0800, Chen Xiao Fan wrote:

> Okay, let me elaborate how a optic proximity switch works.

Thanks for the detailed explanation of your system and the references to
the proximity sensor. From what I've read, I think the list has provided
you more than enough info to go off and design a sensor. The only way we
could help more is by sitting at your lab bench and helping solder! If I
were you, I'd pay special attention to the modulation/demodulation
technique. I think this is the most vital part of the system after the
analog signal conditioning. Also, please recognize that the
modulator/demodulator is more than just an oscillator and comparator;
there's the implicit servoing/pulse validation too. If done correctly,
then the constraints on the filter can be greatly relaxed. You'll only
need a filter to filter relatively low frequency disturbances.

The only other suggestion I have is that you can dynamically tweak your
the threshold in the digital filter based on the 50Hz/60Hz noise you
measure. For example, you can use the techniques described:

http://www.dattalo.com/technical/theory/dtmf.html

to do single frequency detection.

For example, here's what you get when you use this algorithm to detect
60Hz while sampling it with Ts=100uS:

http://www.dattalo.com/technical/td-60Hz.pdf

This currently measures only the magnitude and so will tell you if the
noise is present or not. While I haven't tried it, I suspect that the
algorithm can measure phase too. The reason is because it's basically a
DFT with square waves.

But once you know how the 60Hz noise is affecting you, then you compensate
your digital filter accordingly. For example, here's a filter:

   if (bPulse) {
     // Pulse is high
     if (++FilteredPulse > 8)
       FilteredPulse = 7;
   } else {
     // Pulse is low
     if (--FilteredPulse < 0)
       FilteredPulse = 0;
   }

Without any compensation, you might be inclined to say a pulse is present
if the FilteredPulse value is greater than 3. But what I'm trying to
suggest is an alternative where you write:

 int bHavePulse()
 {
    return FilteredPulse > dynamicThreshold;
 }

Where dynamicThreshold is adjusted based on the amount of tonal noise you
see. If you suspect 60Hz is present, then dynamicThreshold should be
adjusted higher.

Another thing you may wish to attempt is to create behavioral models of
all components of your system. This will take a while to do properly, but
once done you'll be able to parameterize and control a virtual experiment.
In fact, you could even write behavioral models for gpsim and run your
system 10 or 20 times faster than real time!

Scott


2005\06\30@020718 by Chen Xiao Fan

face
flavicon
face
Thanks for offer to help but I am quite okay at soldering. :)
Actually I have my first designed sensor prototypes up and
running with all the basic functions. But my firmware needs quite
some more works in order to implement better noise rejections.

What your suggestion on the modulation and demodulation is similar
to Olin's suggestion to look into remote control. I think it is
an interesting idea and I will look it in the future. Actually
quite some ultrasonic sensors is doing this. There are more problems
to modulate and demodulate light using cheap components and simple
lens systems.

As for the idea of dynamically tweak the threshold in the digital
filter, that is a good idea. I will look into the ideas.

To create behavioral models may be a bit difficult. We use Oslo
or Zemax to simulate the lens, PSpice to simulate the analog circuit,
MPLAB to simulate the firmware. There was even some attempt to
create in-house application to simulate the optic system using
ray-tracing techniques but was not so successful. Optic sensors
are simple yet quite complicate systems (optics, mechanical
parts, electronics, programming). I wish there is something
which can combine all of them. I have not used gpsim yet
but will definitely look into it.

All in all, I think this list is really helpful. Your insight
into the firmware is great, thanks.

Regards,
Xiaofan


{Original Message removed}

2005\06\30@023626 by Chen Xiao Fan

face
flavicon
face
part 1 205 bytes content-type:text/plain;Sorry to those who are not interested that I attach
quite some big files (especially to those who subscribe
to the digest version).

Anyway, some people are interested so I attach the
signal_sat.jpg.




part 2 30397 bytes content-type:image/jpeg; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\06\30@024207 by Chen Xiao Fan

face
flavicon
face
part 1 440 bytes content-type:text/plain;Sorry but another two files. One is the cheapest trans-impedance
amplifier. The second is a high gain but very cheap
trans-impedance amplifier.

-----Original Message-----
From: xxxx
Sent: Thursday, June 30, 2005 2:18 PM
To: Chen Xiao Fan
Subject: Re: [PIC] generating different pseudo random sequence using the
same firmware

> The cheapest pre-amplifier looks like the attached amplifier.jpg.

Appears not to have been attached :-(



part 2 9792 bytes content-type:image/jpeg; (decode)


part 3 11803 bytes content-type:image/jpeg; (decode)


part 4 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...