Posts Tagged ‘serial communications’

My Latest Big Project

16 April 2020
open side of pattern generator and serializer

I have been working on my latest project for about a week straight now. It’s finally in a usable form.

This project has several purposes behind it. First, I needed a pattern generator to test LED arrays that would output very ordinary patterns, nothing fancy, just so I could tell if the display was working. Second, I needed the output to be serialized to simplify connection of the display to the signal source. Third, I wanted to use as many old boards as I could, rather than junk them.

This project incorporates about a dozen old boards that were taken out of “dead” projects and gathering dust on my bench. They all had to be re-worked for this project. It also incorporates some older pattern generation circuits as a way of preserving a technology I have not been using recently.

Here is another shot of the project:

new project showing front panel

Here we can see the front panel which has four main knobs, DIN connectors for the serial signal output, and some other controls.

Added Control Systems

This was an ambitious project for me basically because of the additional front panel controls that I would not put on equipment unless it was being used to test other equipment.

Besides the four voltage-controlled oscillators (VCOs) that have been fairly standard in my eArt projects, there is a pattern selector that is implemented by a rotating “click” knob that I got off an old mobile radio. This gives me about 64 different possible combinations using just one knob.

The other thing I wanted to implement was the ability to isolate just one section of a pattern and show only that on the display. For this I used an old 4-bit binary rotary switch that I had laying around (making 16 possible choices) and some comparison logic using the infamous “XOR” (exclusive OR) gate, also known as a binary adder. This gate, basically, has one output (“0”) if the two inputs match and another output (“1”) if the two inputs are different. AND the outputs together (after inverting them), and you see if two binary numbers match for as many bits as you need or want.

As a geeky aside, I made use of the fact that binary AND and OR are complementary functions. Thus, you can accomplish a binary AND on the outputs of the XOR gates without inverting them first (to make a match = “1” instead of “0”) using an OR gate, which then gives you a “0” output only when there is a match (when all inputs are “0”). Invert that, and you get a “1” for a match. In my case I needed the “0” to show a match!

I also wanted to choose between the “legacy” patterns that I built into this project and the “simple” patterns used for test purposes. For this I used a 4-bit selector IC. One can make a “tree” of these ICs and select from as many different inputs as one wants.

I don’t build these sort of control circuits that much, so I had to do a bit of head-scratching along the way.

My bench and a few closeups

The project on my work bench

I don’t photograph my bench that often because it looks so messy. But here we see my current setup with the project and one of my displays on it.

To the left is a small oscilloscope and you can see its two test leads hanging down from little hooks. In the center is one of my numerous parts cabinets. Behind the project is a work light and a soldering iron. Above the light is a digital meter I bought used (highly recommended for an electronics bench) and above that a rack chassis full of power supplies. The supply with the panel lit up is the one I use the most.

my bench power supply

It produces four different voltages, 5, 7.5, 9 and 12. I use 5 volts the most. The panel had room for two meters (eBay specials!) so I can monitor more than one output at a time if I need to. Here it shows my five volt connection switched on and drawing 38 milliamps. With CMOS logic, most of the circuitry draws close to zero power. Most of this current draw is from the oscillators.

The 12 volt meter shows 18 mA current draw. This is from the panel meters themselves. It was easier to power them from one of the four supplies, rather than adding another just for them.

pattern generator set up in demonstration area

Here we see the pattern generator installed in its case and running the same display. This is in the “demonstration” area of my room.

closeup of the panel

There is room for another panel section above the one I used. You can also see the binary rotary switch set to “A” which is ten in hexadecimal.

8 spirals display

Here is “8 spirals,” one of my more colorful displays. All the lights should be lit in this pattern, but you can see that there are two lights having problems.

Electronic Art – Three Circles

29 March 2020

I thought I’d try to show the latest revision of one of my art projects in video form. At first I tried an old webcam (LifeCam VX-3000) with bad results. Then I decided to use my digital camera. With the current memory card it can record up to 5 minutes of video in Quick Time format. I added a pan and zoom effect using Windows Movie Maker (available in Win 8, not 10).

Latest project updates

In this rare view of some of my gear (doesn’t it look atrocious?) we see a military-green piece of equipment in the middle serving as a signal source to the display module (upper left). The gray cable carries the signal, a serial signal needing only 3 wires plus ground, with a fifth wire providing power to the display. The pattern generator creates an 7-or-8-bit-wide pattern which is monitored on its own local display, then serialized in the top part and sent through the five-wire cable. The pattern generator can also encode the 3 signals into 2 signals and send them out using four wires plus ground. This allows for very long cables.

I want to make this the standard for how my displays work, and this is the first time I have all the parts in the chain up and running.

The display looks cooler than the halting, grainy video conveys. And that’s only one set pattern. The possible variations are infinite. Now that I have all the basic pieces in place, I will be converting more of my older displays to work with a serial cable, and finding better ways to take videos of them so you can see how they really look.

Here’s another video I took after building some more pattern-making equipment.

In search of a better SerDes

17 October 2017

Oh no! Another dry technical article! True, true. Just pass it by if you’re not interested.

Serdes sounds like a Greek word, but it isn’t really. There are some people with the name Serdes, but it is uncommon. I learned it as an engineering acronym thus (lightly edited):

A Serializer/Deserializer (SerDes) – usually pronounced “sir-deez” – is a pair of functional blocks commonly used in high speed communications to compensate for limited input/output. These blocks convert data between serial data and parallel interfaces in each direction. The term “SerDes” generically refers to interfaces used in various technologies and applications. The primary use of a SerDes is to provide data transmission over a single/differential line in order to minimize the number of I/O pins and interconnects.

https://en.wikipedia.org/wiki/SerDes

Electronic Art

I am trying to work out some cool things to do with LED arrays that would respond to environmental or observer inputs. There are many pieces to such a system. This includes the possibility that the display itself may be some distance from the electronics that collects the input signals and decides what the display should do. The same way a computer monitor can be separate from the computer. And in this case, the two are connected with a cable.

Some of us remember the old printer cables. They were thick, had up to 25 separate wires in them, and couldn’t be much longer than 15 feet. I could probably use such a cable in my projects. But that’s a lot of bulk, and it comes with many limitations. Those cables connected a parallel port on the computer to a parallel port on the printer. There were usually 8 data lines plus a bunch of handshaking signals to make it so the computer would not send data faster than the printer could print it out. If you wanted to get a lot of data back from the printer, you could add another 8 data lines going in the opposite direction.

8 bits can encode into 256 different numbers (0 to 255). That’s enough for an alphabet – both upper and lower case – and a bunch of other symbols. Each symbol has a number “code” that stands for that symbol. Both ends of the line have to use the same code system.

An 8 bit parallel system could go pretty fast; millions of symbols per second. But try pushing parallel data through a long cable that fast and you will quickly run into problems. You would need to shield the cable so external signals won’t interfere with it, and so it won’t radiate signals into external equipment. And the wires in the cable, when they get quite long, resist fast signals going through them in at least three different ways (resistance, inductance and capacitance). So if you want to send data fast through a long cable, you have a whole hardware design challenge on your hands.

SerDes concept

Illustration of the SerDes concept. Original graphic by GrĂ©goire Surrel – Own work, CC BY-SA 4.0

The solutions to these problems usually involve reducing the number of wires carrying signals (ideally just one pair would be enough) and creating special hardware interfaces that alter the signals so that they will make it through the cable successfully, even though the cable presents various barriers to proper transmission.

A standard solution for many years was the “RS-232” serial cable. In this system the signal is amplified to make it more resistant to interference and cable attenuation. And the signal is “serialized” so it only has to use one pair of wires. That means each symbol of 7 or 8 bits would be transmitted as a sequence of bits that would have to be reassembled into 7 or 8 parallel bits at the receiving end. That was an early SerDes system. But we didn’t call it that in the old days. The acronym only came into wide use after the internet and its various forms of information exchange came into wide use. The term commonly refers to high speed data transmissions, but the basic concepts are the same regardless of data rate. My projects use quite low data rates just to make sure I don’t run into too many design problems and can use cheap parts.

The RS-232 standard could probably work for me, but I wanted to try another more modern data transmission standard, TIA-485. (RS = Recommended Standard, as published by the EIA, Electronics Industries Alliance, but now taken over by the TIA, Telecommunications Industry Association). This standard uses two wires for each signal plus a third wire used as a ground (zero volts) reference. The signal is transmitted in an attenuated form, differentially. That means a “zero” would be transmitted by putting maybe 3-1/2 volts on one wire and 1 volt on the other. And a “one” would be transmitted by reversing those. Smaller signals in a cable create less external interference and are easier to pass through longer cable lengths.

I have a connector that is used for MIDI (Musical Instrument Digital Interface) that has five pins, which means it can carry two differential serial signals (or 4 RS-232 signals) plus a ground reference wire. I wanted to use this connector and a 5-wire cable, but there was one problem:

SerDes Timing

Just as in the old parallel printer cables, where handshaking signals were necessary to tell the printer when a symbol to print was put onto the connecting cable, and tell the computer when the printer was busy, serial systems also need a way of at least telling the receiver when the transmitted data is good, how fast it is going, and when an entire symbol has been sent. This requires, minimum, clock and end-of-symbol signals for data rate and data synchronization. In the RS-232 system, the data rate had to be set at both ends in advance. And the end-of-symbol signal was coded into the data stream. It takes a computer to figure out how to decode this data stream, but if you send all three signals separately, you don’t need any computing at the receiving end. Deserialization can be done with one piece of hardware called a shift register.

But I can’t transmit three signals over a five-wire TIA-485 cable, only two. So I thought I’d figure out how to combine the three signals into two so that my system could work with the hardware I have. I devised a rather simple system to do this, and built an initial working system several years ago for my “Christmas” project (Christmas because it used strings of holiday lights for the visual display). Recently I have built two more systems that use this method.

Glitches

I like to re-design systems each time I build them. This is partly because I might not have the same parts available that I used in an earlier design. Or it might be just to explore different ways the problem could be solved. All the heavy work in my SerDes system is on the transmitting site. The receiver is very easy to make. And for this transmitter design I wanted to use counters to run ICs (integrated circuits, now often known as “chips”) called multiplexers. You put parallel data on the 8 inputs of a multiplexer, then tell it which input to put on the output using a counter. And if the counter repeats a regular pattern (as most do) then the parallel data at the inputs will come out of the output in a predictable serial sequence. And so you have achieved serialization.

In my first design I was getting “glitches” at the outputs of some of my multiplexers. This is because I was using “ripple” counters. In this type of counter, the counting outputs don’t all change at exactly the same time. They might be a little off (usually much less than a microsecond, but that’s enough time to cause trouble). In other words, when changing from count 1 to count 2 for instance, the ones bit has to change from one to zero, while the twos bit has to change from zero to one. If the twos bit lagged a little, both outputs might be zero for a split second, telling the multiplexer to go to the wrong input. Such glitches can be filtered out, which is what I did in the first design. But in the second design I decided to try a different counting scheme, where only one counting bit would change at any one time. This should make counting glitches impossible (it does). But it means the count is no longer in number sequence. In other words to do this with a 4-count pattern, you have to use the pattern 0-2-3-1 (or 0-1-3-2) to get a glitchless count. This different sequence is not a problem when using a multiplexer, though it is more confusing to design if you are used to using ripple counters that count 0-1-2-3 (etc.).

I looked at the waveforms associated with this kind of counting, and they were just two square waves offset by one count. I found a PDF online that describes how to implement this kind of counter. It’s called a “quadrature” counter, and it’s pretty simple to do. Getting a similar sequence of 8 is a little more tricky, but basically just interleaves a quadrature signal with a square wave. I built my second system this way and it works fine (though I had to scratch my head a bit to get the input sequence right, as it is sensitive to the place value given to the various counting signals).

quadrature waveform illustration

A four-count pattern implemented using a quadrature counter.

What form should the data take?

So I now have a hardware system that can be used with either 2 TIA-485 signals over quite long distances (if the cables are made well) or with 4 RS-232 signals (but not the RS-232 encoding system). The RS-232 version is much easier to build, but does have distance and speed limitations compared to the TIA-485 system.

The original intention of the system was to enable transmission of 8-bit-wide signals that would be used to control an array of LEDs. But it could also be used to transmit serial control streams of any bit length. This means a wide variety of displays could be controlled, as long as they didn’t have to change at a very fast rate. In other words, we’re not talking about full-motion video, like TV, but that’s not the sort of display I’m working with. My average display contains less than 100 LEDs, while a modern TV screen contains millions.

I have also tried transmitting analog data using digital serial techniques by using pulse-width encoding, which is very simple to implement in hardware. This gives me the option of using digital data transmission instead of long analog signal lines. This may come in handy in some of my projects.

MIDI

2 February 2014

MIDI controller

Musical Instrument Digital Interface

Interface: “…a means of interaction between two systems…” (Webster’s)

The term is used broadly and sometimes confusingly in electronics, computers, computer science and programming as well as less technical subjects.

This word – and many of these articles – embrace a topic which I call digital control. A simple form of digital control is when you walk up to a light switch in your house and turn it on or off. One huge use for computing machines is to use this basic action for controlling all sorts of things. Huge electrical machines, power generation and distribution systems, lighting systems in buildings and for entertainment, manufacturing tools, and all sorts of other devices.

Any control system has 3 basic components:

  1. A controller;
  2. the thing to be controlled;
  3. some sort of feedback mechanism to tell the controller if it was successful.

In MIDI and several other simpler digital control systems, the only feedback channel is through the human senses. In other words, when a musician hits a key on a MIDI controller, the only way he knows that doing that worked the way he wanted it to is by listening to what comes out of the speakers.

I will bring out the book I have in my library: The MIDI Companion by Jeffrey Rona (1994) as my resource for this little introductory article.

MIDI was introduced in 1983 by the growing electronic musical instrument industry as a standard way for controllers to talk to synthesizers. As the name implies, is was digital. In fact, it totally depends on microcontrollers to work at all.

I define a microcontroller as any electronic control device built into a piece of equipment that requires software (or firmware – embedded software) to make it work. The actual technical definition is maybe a little narrower than this.

Thus, MIDI has two main technical aspects to it:

  1. The technology of making musical sounds using electronics, which heavily uses the terminologies of acoustics, the science of sound.
  2. The technology of digital communications, which uses the terminologies of computer systems and computer science.

Advanced users of MIDI must learn both technologies and the various terminologies involved. A “casual” user of MIDI only needs to learn the basic acoustical terminologies, along with having some knowledge of music, of course.

The controller

The photo at the top of this article is my controller. It has an ordinary musical keyboard to play notes, and quite a few control knobs, sliders and switches that tell the synthesizer more about the acoustical properties of each note.

Controller hardware can have a wide variety of capabilities built into it. But what it must do is send instructions to the synthesizer that will result in musical sounds coming out.

The synthesizer

The synthesizer is the device being controlled. It’s job is to make sounds by responding correctly to the control messages sent to it over its MIDI connection from the controller. Most synths also have some stand-alone sound production capability, so they can be tested without a full controller attached.

MIDI synthesizer

I have recently acquired a synth, which is the main reason for this article. Before, I only had “software” synths, which operate on a computer and play through the computer’s sound system. That adds a layer of complexity that I didn’t want to have to address in writing about MIDI. So with the use of this synth, that complexity is eliminated.

Future articles will explore this technology in more depth.