Re: Spinner Replacement for Omega Race

> Basically, you can deglitch by simply filtering out the previous 3 or 4
> samples.

My present code is not bothering to debounce/deglitch at all but with the
Bourns EM14 series quadrature encoder, there's no need for it. Oversampling
and capturing #-in-a-row works too. I usually just use the first edge that
is detected (because it's usually going the right way) and then ignore the
input for a short time afterward.

> Just curious Bill, what is your resource utilization in the PLD? I see
> you're using a 72 macrocell device....I kind of think a 36 macrocell
> device would work here just to save you a few cents.

For the universal version of the program, the xc9572 was about 97% full.
For the Omega Race specific version, it's about 60% full. If I stripped out
the extra clock outputs, the direction output, and the input divider code,
I'm sure that it would be 40% or even less and then it would fit into the
xc9536 part. When I bought my first couple of tubes of chips, I just went
with the xc9572's because I wanted the highest capacity possible for
prototyping. Also, by purchasing more of the same part, the price break was
better. There's nothing worse than running out of resources when you are an
inch away from completing something that you want to get running. I'm never
going to sell thousands of these little things anyway so I don't need to
worry very much about the relatively minor cost difference between the two
parts.

> This is a dumb idea, but you can implement a simple sigma-delta DAC in a
> PLD/FPGA....I wonder how difficult it might be to make an optical solution
> for Star Wars / Spy Hunter controllers...I hate those pots.

I don't think that a CPLD is available that has a built-in analog output
peripheral but just as with microcontrollers, a CPLD could easily generate a
fast PWM output signal (i.e. 20 kHz or even faster) that can be RC-filtered
and op-amp buffered into a true analog signal.

I have never seen the inside of the Star Wars flight yoke but I've read
about the problems with the gears, springs, and calibration. My first
thought about your Star Wars question was that the Bourns EM14 series
optical encoder could easily replace the pot. Well, that's likely true
physically assuming that the pots have either a 1/8" or 1/4" diameter shaft.
You might even eliminate all of the gears and have the yoke directly turning
a couple of 256 ppr quadrature encoders (that would produce 1024 states in
one full turn). If the yoke moves 90 degrees during play, you'd get 256
states through that range of travel and that is probably good enough for the
game. However, there remains the problem that the Bourns quadrature encoder
is an incremental position sensor and a pot is an absolute position sensor.
The incremental optical encoders, or should I say the counter that generates
the analog output, would require some sort of position reference. I do not
think that assuming the yoke is properly centered during powerup is a
reliable way to go. It would be possible to program the CPLD board to
monitor the range of travel that the yoke goes through during play and it
could auto-calibrate and auto-center, but the player would not enjoy being
forced to put the yoke through its full range of travel to calibrate it,
even if it only had to be done once after powering up. Most people want to
turn on the machine and go. For Star Wars, an optical position sensor would
have to be an 'absolute' type. Such could be done using an 8 bit (or up to
10 bits) Gray encoder. I think this would be very expensive.

What would you say is I suggested using a completely different type of
sensor? There are certain programmable magnetic-resistor-bridge based
intelligent sensor chips that are available these days that can read the
angle of the field of a magnet (that's the angle of flux lines, not the
field intensity). In other words, throw out the gears and the pots, glue in
two magnets, install a couple of these tiny sensor chips and out comes your
absolute analog position. The sampling rate is 4 kHz, linearity is
excellent, output is 0 to 5V with 10-bit accuracy, and the maximum range of
travel is 180 degrees. The programmability of the sensor allows you to
choose the lower and upper voltage limits, the range in degrees, and a
offset angle. The only downside is that programming is not easy by any
stretch of the imagination. However, I designed and built a custom
programmer board for the sensor chip that makes setup very easy. If I had a
SW yoke in my hands, I could probably develop the little sensor boards and
program them for the nominal response expected by the game.

William Boucher

----- Original Message -----
From: "Ed Henciak" <ehenciak@yahoo.com>
To: <vectorlist@vectorlist.org>
Sent: Friday, August 01, 2008 3:15 AM
Subject: Re: VECTOR: Spinner Replacement for Omega Race

>
>> 3) functions, so based on my experience you might want to stick a 74HC14
>> on the inputs to the
>> 5) What's the crystal for?
> My guess is that 3 & 5 are related :-)!
> Basically, you can deglitch by simply filtering out the previous 3 or 4
> samples. If your past four samples are all '1's, you know you have a
> valid '1'....same with zeroes. Then, you stay in your one or zero state
> until you sense a deglitched 1 or 0. I made a Xilinx PLB peripheral with
> this and lots of other features for some robotics applications. The
> function is very lite in terms of logic utilization.
>
>
>> 4) A little MCU might be more flexible than the CPLD if you wanted to
>> support more input/output formats. With a ~12MHz AVR I can read four
>> channels of quadrature encoders and still have time to do light gun
>> sensing and other tasks and still get 1000's of times oversampling.
>> Can't outrun it with the shaft connected to a power drill. ;-) You don't
>> need pullup resistors either since the AVR has 'em built in and even the
>> smallest AVR could have multiple programs built in for different
>> input/output formats. Also allows you to get around input noise issues
>> in software too, so you save the 'HC14(s)...

> Oh you and your AVRs :-P !!! What fun is that :-P (just kidding). A
> microcontroller is going to give you a lot more flexibility....but the
> function seems so simple that a PLD would be so much straightforward in
> this case....I guess its designer preference :-)! Just curious Bill, what
> is your resource utilization in the PLD? I see you're using a 72
> macrocell device....I kind of think a 36 macrocell device would work here
> just to save you a few cents.
>
> This is a dumb idea, but you can implement a simple sigma-delta DAC in a
> PLD/FPGA....I wonder how difficult it might be to make an optical solution
> for Star Wars / Spy Hunter controllers...I hate those pots. Aren't they
> up to $15 a piece for those industrial ones? I understand that once you
> install them for home use, you'll never need them again, but I am sure
> those are going to be harder to source someday soon.
>
> Ed
>
> ---------------------------------------------------------------------------
> ** Unsubscribe, subscribe, or view the archives at
> http://www.vectorlist.org
> ** Please direct other questions, comments, or problems to
> chris@westnet.com
>

---------------------------------------------------------------------------
** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org
** Please direct other questions, comments, or problems to chris@westnet.com
Received on Fri Aug 1 15:52:30 2008