Blech. You want to take a nice clean encoder signal and crap it up in the analog world just so you can crap it up more with an A to D conversion? Blech. I'd just get a bigger microprocessor.
The first pair of D flip-flops cleans up the signal (if you're clocking this fast then use a chain of two or three here). The second just delays it by one clock. Run the four signals into some combinatorial logic -- the idea here is to have the "up" line go high whenever the encoder advances, and the "~down" line go low whenever the encoder retreats. I am _not_ going to detail the combinatorial logic here -- just get out a pencil and paper, make some Karnaugh maps, and be happy. You'll end up using lots of xor gates.
Size the resistors and cap for your desired level of anti-aliasing, or put a real filter there, and have fun.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
I don't have anything against either analog or digital. It's just jumping from one to the other like a hyperactive dolphin that gives me the heebee jeebies.
-snip-
It's a cool little program, and free.
I've done similar before. Yes it would work, you'd have to be careful of transitional values and you'd have to sample faster than the encoder would ever go, but you'd keep the digital digital.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
I have a rotary encoder outputting a quadrature signal that I would like to convert to a voltage that indicates the encoders rotation direction and rotation rate. ie. when the rotary encoder is rotating one direction the voltage will be less than 2.5Volts and when rotating the other direction the voltage will be greater than 2.5Volts, and at rest the voltage should be close to 2.5Volts. Any ideas for a circuit that can do this? I am running out of microcontroller inputs, so I would like to use a single ADC channel instead of two digital inputs to decode the quadrature signal.
Ok, can't do ASCII art so I'll describe an alternative:
Replace the cap with a resistor, delete the digital stuff and run A and B directly into the two horizontal resistors but make these of different value. Now there will be four distinct voltage levels coming out. That allows to resolve from the ADC value the status of A as well as B at any time. Basically you now have a 2bit poor man's DAC that feeds the ADC input.
I have done that sometimes and it also gave the other (client's) engineers the heebee jeebies. But if the accuracy is good enough and it is cheaper, why not? Once a huge hotrod DSP became more or less unemployed in the wake of some anadigital mods. They decided to leave it on there anyway but from a MIPS point of view it could have been replaced by a 4bit Chinese uC.
Yes, I'll have to get it. Wish Eagle had a routine for converting a schematic to ASCII. Shouldn't be too tough but I am not good at writing these Eagle user language programs.
I hope Jamie forgives me but I was just waiting for the other shoe to drop. Like that he's also running a bit too tight on MIPS to do this or almost out of ROM space ;-)
Well, yes, but as Tim mentioned keep in mind that you have to run the corresponding ADC channel at a good enough clip. You don't have an interrupt capability from these signals like you would if there were enough uC pins. Maybe you could finagle something with the comparator but then it gets ugly. Plus Jamie doesn't seem to have that extra pin.
Here is a trick that may work. Build negative pulse detectors for the A and B outputs, and use an RS flipflop. Connect B to set, A to reset. Then, when the encoder is going forward, the duty cycle is long, whereas when the encoder is going backwards, the duty cycle is short. This way, you can use 'interrupt on change' and TIMER0 to determine the frequency and direction...
You probably know this, but a simple negative pulse detector is
If you want, you can also try using this program of mine to convert LTSpice schematics to ascii:
formatting link
Lets you use a decent schematic capture. However, it is pretty limited in the ASCII models I've hooked into it. Easily added to the library file with any editor, but then you still have to add them.
How about a few resistors making up an R-2R ladder from the quadrature signals (this assumes active outputs, both pulled up and pulled down - passive switches is only a little bit different), creating four discrete voltages for the four quadrature states, then the controller can do the quadrature decoding with the values from the ADC. You would want three comparison values, each halfway in between the adjacent voltages, for reliable operation. This of course requires more programming, but a little code space and a few resistors is cheaper than extra active components, isn't it? If I had to do EXACTLY what you asked, I would make the 'circuit' out of a small microcontroller that has two digital inputs for the quadrature device and one DAC output. I suspect any design to do it with "discrete" components (no micro, no FPGA) would cost more, and certainly would take more components.
I don't think there is an easy way, especially since you want frequency to voltage conversion. If you absolutely cannot spare another input pin then maybe its possible to add a 8 channel mux/demux,
Interesting. LTspice can actually read-in a PSpice Schematics. Now all I need to figure out is how to import my PSpice symbols into LTspice. I have tons that I've made up that don't exist in the standard libraries.
Any simple way to do that Mike?
...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC\'s and Discrete Systems | manus |
| Phoenix, Arizona Voice:(480)460-2350 | |
| E-mail Address at Website Fax:(480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food.
The one and only Supreme Mikey, creator of LTspice ;-)
...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC\'s and Discrete Systems | manus |
| Phoenix, Arizona Voice:(480)460-2350 | |
| E-mail Address at Website Fax:(480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food.
That is nice. I have not looked at the C, but it must use the location information in the .asc file, right?
Having an ascii schematic generator that works off of the netlist would be pretty cool, but placement would be hard. Having an ascii editor that does the rubber band connections would be even mo better.
However, what I would really like is for Andy's Ascii to work properly under linux wine (the fonts are wrong, and he appears to be drawing in a mode that screws up wine, so it leaves trash all over the screen). I used it all the time under XP until I switched over to using linux most of the time, so it's a pain to boot into windows to do a circuit for somebody.
Alternately, an emacs mode for drawing circuits would be a ueful hack.
--
Regards,
Bob Monsen
If a little knowledge is dangerous, where is the man who has
so much as to be out of danger?
Thomas Henry Huxley, 1877
No problem. It was more for my own use. I thought it may help some others who were already using LTSpice or could consider it for schematic capture, as it is free.
When I want to put out a schematic on a newsgroup, there is an advantage to doing it in ASCII since it is a light load on the web and will be archived for the long haul on google. I also tried to use Andy's program for a bit, but I really found myself not liking some aspects I couldn't customize and, more fundamentally, I just don't like editing and modifying schematics done in ASCII. I often go through several iterations and ASCII editing does NOT allow me to stretch wires and so on -- too little intelligence. I also prefer, because I'm a hobbyist and not a professional in this field, to do some measure of validation before I post. LTSpice helps me do some basic checks to help catch certain mistakes I may make or to point me to thinking more on an issue before I write about it.
So, for me, LTSpice provides a one-stop shop where I can quickly hack up an idea, verify I didn't completely get it wrong, modify and try out some different approaches (not necessarily simulating them, just putting down various concepts to see which might be easier for me to explain), and then to spin off an ASCII image from it (including the descriptions and equations used.)
That is great. Probably you should promote it some more or at least place a post with "LTSpice to ASCII schematic" or something in the subject line to a few NGs. I'd volunteer to post in the German NGs if you like. There are a lot of people who use LTSpice for schematics and they could really use your program but most likely just do not know about it.
Maybe Jon's program could also read PSpice schematics then. But even if you could translate it all to LTSpice I guess you'd be restricted to whatever symbols he's got in his conversion program or you would have to create new ones.
Yup. Just examines the graphics x,y locations and uses GCD to extract the minimum possible arrangement for ASCII positions. Nothing fancy.
That's a real pain, I think. If someone had come up with a good way of communicating schematics through an automated generation from netlists, it would have already been done. But there is a lot of art in communication and whether you should just stub off a voltage rail connection without actually showing the wire or otherwise show it can be, in some cases, a decision of style. I don't like it, myself, when schematics are laid out with all the supply wires criss-crossing around. I suppose for someone with a soldering iron in hand, or wire-wrapping the darned thing, it's nice to see the actual wiring. But in trying to understand a schematic, it distracts the heck out of me to see all that wire when it is the signal lines that really are important and are being hidden a but by busing voltage all over the place.
I've no idea how I'd go from netlist to a reasonable schematic for study purposes, except in highly trivial cases.
I'd like that. And that is probably the one thing that kept me from making use of Andy's program. I frequently just want to "get it down on paper" and then move things around, adjust, add, delete, and then re-position stuff so that it "looks right" for explanatory meaning. I wind up erasing everything and starting over with Andy's program, because I really can't stretch, shrink, grab and reverse or rotate, etc. with his ASCII editor. He really needs to handle the objects as objects and not only as ASCII text once it is placed. But that would bring it to a whole new level and I don't expect it.
The schematic editors, like what is in LTSpice, on the other hand,
*have* to do all that. It's essential. So those features are built in and handy. But then, it doesn't spit out ASCII. So that's the part I tried to add. This way, I get the typical features of a decent schematic entry program, complete with the concept of objects and wires, plus I get some built-in ability to validate things. And then, immediately upon some spice testing I can emit the ASCII directly from the schematic that was just verified. No possibility of transcription errors. Which is nice, too.
Well, that's another possibility. I think I'll probably stick with (and try and improve upon) the LTSpice-->ASCII method, though. LTSpice is free and it has a decent schematic entry and editing capability.
Even if you don't want to use the simulation feature (and there is no need for that, many times, because you know what you want to get down on paper and don't want to bother with exact values, at all), LTSpice remains a very quick way to slap down a conceptual idea in schematic form and get it quickly into a form that communicates well. So you can go directly from schematic entry to ASCII, this way. Just don't use the spice part. Or, if you want, spice is there, too. Doesn't get much slicker than that.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.