Need a better algorithm for my ADC

Let me describe what I'm trying to do. I have a perfectly working signed 7-bit register, so I can avoid all the problems with strictly using analog for things such as health bars. I also have a working analog to digital converter, so I can input values into my digital circuits using batteries. However, the algorithm I'm using puts sequencers in-line within the circuit. For each sequencer, I get one frame of latency. So for a 7-bit register, I am hit with 7 frames of latency everytime I want to convert from analog to digital.

I'm using a simple algorithm where I subtract the input from 64, if the result is positive I carry the original value onto the next bit test. If it is negative (or zero), I set the bit and carry the result onto the next bit test. So for the next bit, I do the same thing but using 32.

So this works perfectly, and I've tested it for all 100 possible inputs. The problem is, I need to support changing the inputs on the fly, and 7 frames of latency is not acceptable. Does anyone have a different algorithm for converting the analog to digital, that wouldn't put test dependencies on the sequencers (this puts them in-line)?

I'm only using 4 bit, so this may not be feasible for 7 bit.

What i did was make a single sequencer set to positional then spaced batteries across at the proper intervals to trigger the proper sequence for my binary numbers. This does add a single frame of latency, but that's better than the 1/5 of a second you are seeing.

I'm only doing numbers 0 through 9, so it may be more trouble than it's worth for 1 through 64.

Quote:

---

Originally Posted by Shanghaidilly

Let me describe what I'm trying to do. I have a perfectly working signed 7-bit register, so I can avoid all the problems with strictly using analog for things such as health bars. I also have a working analog to digital converter, so I can input values into my digital circuits using batteries. However, the algorithm I'm using puts sequencers in-line within the circuit. For each sequencer, I get one frame of latency. So for a 7-bit register, I am hit with 7 frames of latency everytime I want to convert from analog to digital.

I'm using a simple algorithm where I subtract the input from 64, if the result is positive I carry the original value onto the next bit test. If it is negative (or zero), I set the bit and carry the result onto the next bit test. So for the next bit, I do the same thing but using 32.

So this works perfectly, and I've tested it for all 100 possible inputs. The problem is, I need to support changing the inputs on the fly, and 7 frames of latency is not acceptable. Does anyone have a different algorithm for converting the analog to digital, that wouldn't put test dependencies on the sequencers (this puts them in-line)?

---

I think there's two ways to go about it:

First, you could set up your whole ADC as one single, big sequencer. (This is what I did for my 8-bit ADC) Lots of wiring and a very big sequencer, but the thing works with just one frame of latency for the sequencer itself.

Second, I think you could also set up a series of arithmetic with an approach similar to what you're using now, such that the next stage gets the desired answer ((x - 0.5) if x > 0.5, (x) otherwise) without using a sequencer... But at the moment I can't think of how to make that work nicely

For a 7-bit A-D, with analog input (x), it could be like this:
Direction-combine to get (x - 0.5), direction split to get (x - 0.5 if x > 0.5) on the positive terminal, (0.5 - x if x < 0.5) on the negative terminal.
Double the result of the negative terminal six times via adder circuits, so that any non-zero result out of that terminal that is relevant to your 7-bit A/D will result in a signal greater than 0.5.
Take the result of the doublers, combine it with the original input signal (x) via AND gates - the result of that AND gate is (x if x < 0.5, 0 otherwise).
Combine that result with the positive output of the direction splitter via OR gate. The result of this gate is (x - 0.5 if x > 0.5, (x) otherwise.)

It'd be preferable to just come up with a signal that's (x if (x < 0.5), 0 otherwise) - but I can't think of how to do that without a sequencer or some kind of delay-inducing feedback circuit.

Quote:

---

Originally Posted by tdarb

I'm only using 4 bit, so this may not be feasible for 7 bit.

What i did was make a single sequencer set to positional then spaced batteries across at the proper intervals to trigger the proper sequence for my binary numbers. This does add a single frame of latency, but that's better than the 1/5 of a second you are seeing.

I'm only doing numbers 0 through 9, so it may be more trouble than it's worth for 1 through 64.

---

Yeah, rtm did it that way, and I really don't relish the idea of that much wiring. Here's what the last third of rtm's sequencer looks like for a 7-bit ADC:

http://i600.photobucket.com/albums/t...g?t=1295871835

Quote:

---

Originally Posted by Shanghaidilly

Yeah, rtm did it that way, and I really don't relish the idea of that much wiring. Here's what the last third of rtm's sequencer looks like for a 7-bit ADC:

---

The wiring isn't so bad if you take care to organize it well. Keep the OR gates close to the batteries. Use multiple stages of OR gates (instead of one 64-input OR gate for the low-order bit, use 8-input OR gates, take 8 groups of 8...) Making a 7 or 8 bit ADC is still a bit rough on the layout engine but it's manageable if you approach it right.

this is just off the top of my head, so not sure how well it would do.

What if you made 7 sequencers (one for each bit)then spaced batteries across those at the intervals where the bit would be active. Connect those batteries to OR gates on the individual sequencers. Then connect the ORs to the corresponding bit.

You should then be able to input all 7 simultaneously with your analogue input and next frame they will update and set your bits.

I may try this on my 4 bit setup.

You can almost literally cut the wiring in half by using Gray Code on your sequencer outputs, then converting that back into binary. On a 4 bit ADC, gray code would require 8 batteries, 2 OR gates (4 and 2 input), and 3 XOR gates. I'll try to explain how to lay it out, but if you can't get it I can throw together a gray code based 4, 5, 6, 7 and 8 bit ADC, as well as a 4 bit BCD decoder (Binary output, but scaled 0-10) and 7 bit BCDish decoder (Binary output, but scaled 0-100)

This is how you would lay out a 4 bit gray code decoder. More than 4 bits just extends the same concept.

1. Pass the signal through a NOT gate, then into a sequencer.
2. Make the sequencer positional, 4 stripes wide, 4 lines tall.
3. On the first row, place a 1x width battery exactly in the middle of each stripe. (So of the 16 values, this covers 1-2, 5-6, 9-10, 13-14, leaving a quarter bar uncovered on each end)
4. On the second row, place a 2x width battery centered between each pair of batteries on the first row. (So of the 16 values, this covers 2-5 and 10-13, covering half of each stripe.)
5. On the third row, place a single 4x width battery centered between the two batteries on the second row. (So of the 16 values, this covers 4-11.)
6. On the fourth row, place a single 4.5x width battery overlapping the left end of the sequencer, and completely covering the first two stripes.
7. Use the 4 input OR gate to combine all the batteries on the first row, and the 2 input OR gate to combine all the batteries on the second row.

You now have a signal with 16 distinct values. However it isn't a true binary coded signal, it is gray coded. However, the conversion is easy. With the source being G0, G1, G2 and G3 for the bits (Corresponding to the first, second, third and fourth) and the binary representation being B0, B1, B2 and B3, the conversion is as follows...

B3 = G3
B2 = B3 XOR G2
B1 = B2 XOR G1
B0 = B1 XOR G0

Now you have a 4 bit binary ADC using 14 parts, vs 19 doing it the "normal" way. The savings are even more extreme as you add bits. A 5 bit ADC using gray coding uses 24 parts with gray coding, vs 38 parts without. 6 bit is 44 parts with gray coding, vs 75 without, and so on.

If my description didn't make much sense, here's a picture. It's worth a thousand words.

This is what I was describing for the 4 bit decoder.

http://i2.lbp.me/img/ft/662303930179...dedfb90553.jpg

For comparison, here is the exact same thing, but the traditional binary version of it. This does the exact same function, returns the exact same results, and is quite a bit more complex. (Okay, it doesn't return the EXACT same thing.In the case of a 100% signal, this one returns 0 where the other returns 15. Technically neither are right.)

http://i5.lbp.me/img/ft/865cd63f77f6...49b14cf2b5.jpg

As you can see, it's a simple pattern to extend. Rather than all being shoved to the left like traditional binary would be, it is all centered, except for the MSB. Then just cascade the outs from the sequencer into a series of XOR gates to convert it to traditional binary data. Extending this to a full 7 bit version...

http://i2.lbp.me/img/ft/fe2c4b146bab...074b71d871.jpg

Here is the entirety of a 7-bit ADC which produces values of 0-99, like what the sequencer from RTM shown above produces. (The other 7-bit one I showed produces values of 0-127.)

http://if.lbp.me/img/ft/fcf5c5576a4b...4e7aefef30.jpg

This question inspired me to write up a short tutorial on analog to digital converters.

http://www.lbpcentral.com/forums/ent...ing-Gray-Codes

Thank you Tygers. I was close to getting my own to work based on your earlier suggestion in this thread, but was having trouble wrapping my head around Gray's code and last night my ADC still had some problems. Your last post in combination with your tutorial has cleared it all up and I should have it working tonight. Thanks again.

I feel like a dunce for not thinking of using Gray code. I should know that sort of thing. :(