Gas station without pumps

2016 February 20

LED multiplexing

Filed under: freshman design seminar — gasstationwithoutpumps @ 12:04
Tags: , ,

In the freshman design class on Friday (2016 Feb 19), I did not cover any of the material I had queued up as things students might need.  Instead, I responded to a question from one of the students working on the LED cube project about how pin multiplexing worked.  I had covered this once before in the class, but in a rather hurried way, and the students did not appear to have investigated the designs on their own to figure it out. So I decided to take the time to go through the development of the idea from the initial problem to one of the many possible solutions.

The problem is fairly simple to state: in a 4×4×4 RGB LED cube, there are 192 LEDs that need to be separately controlled—we want to be able to have any combination of them be on or off (I’m not getting into PWM control for adjusting the brightness in this class, though the hardware is not really different).  The problem is that there are not 192 output pins on the Teensy boards, so they have to pack more functionality into fewer pins.

I started out with the idea of time-multiplexing.  We don’t really need every LED that is on to be on all the time—if we are willing to have the whole cube be dimmer, we can have each LED on only a fraction of the time.  For example, if we are willing to have each LED on for only 1/16th of the time, we can make 16 time slots, assign each LED to one time slot, and only need to control 12 LEDs in each time slot.  If we specify which time slot we are currently in with 4 pins (binary encoding of the 16 possible values), then we only need 12+4=16 pins to control the 192 LEDs.

I then drew a grid of 12 rows and 16 columns (actually, I only showed a couple of each, and used …) and put an LED in each grid position, connecting the row to the anode and the column to the cathode.  I then showed that if we had exactly one of the columns low, we could control all the LEDs in the column with a high voltages on the rows for the LEDs in the column that should be lit.

We then looked at current-limiting resistors, deciding that it made more sense to put them on the rows than on the columns, because the number of LEDs lit on each row is either 0 or 1 at a time, but anywhere from 0 to 12 may be lit on a column.  We can compute a resistor that provides the desired current for the row, but the column has very different current needs depending on the number of LEDs lit.  We also discussed that all the LEDs on a row should be the same color, since the forward voltage for the LEDs is different for different colors, and the needed resistor size depends on the forward voltage at the desired current. (I reviewed how to do the calculation of the current-limiting resistor.)  Note: choosing columns to have the cathodes and rows to have the anodes, combined with needing a single color on each row, puts a constraint on whether we use common-anode or common-cathode RGB LEDs.  If the wrong type of RGB LED is bought, then the columns would have to have the anodes and the rows the cathodes.

I suggested the use of a decoder or demultiplexer chip to decode 4 output lines into 16 column lines, with exactly one column being active. There is a 4-to-16 decoder chip available as a through-hole part (CD74HC4515EN), but it is a bit pricey, and students would be better off with a pair of 3-to-8 decoders (SN74HC138N), using the enable inputs to decode the remaining bit. Note: theSN74HC138N has an active-low output, with only one output low at a time (or 0, if the chip is not enabled).  The CD74HC238E has an active-high output, with only one output high at a time.  I did not talk about the different logic families and the logic levels needed for them. The HCT family, which needs a 5V power supply and uses traditional TTL signal levels is not a good choice for being driven from the Teensy outputs—the HC family is a better choice.

We then looked at another problem.  If we want 20mA in each LED, then we need up to 240mA for a column and 240mA combined from all the outputs.  The Teensy boards can’t deliver that much power from the output pins! Even the decoder chip is only designed for about 6mA on the output. So we can’t drive the rows and columns from the Teensy or decoder outputs.

For that matter, we can’t get 240mA from the 3.3V regulator for a Teensy LC or Teensy 3.1 (though the Teensy 3.2 is specified fairly conservatively to allow up to 250mA, which is barely enough).  I suggested that we might want to power the LEDs off of the USB 5V power, which can deliver 500mA—more than enough.

I then introduced field-effect transistors (specifically MOSFETs) as voltage-controlled switches. For the columns, we just need an nFET for each column, with a threshold voltage between 0V and 3.3V, so that it is off when the decoder output is low and on when the decoder output is high.  The gate of a MOSFET takes essentially no current, and even the cheapest nFETs can work in this application.  I showed the students how to use the DigiKey search page to find a through-hole nFET with a threshold voltage in a reasonable range and sort by price for buying 20.

We talked about including the on-resistance of the MOSFET as part of the current-limiting resistance. The 5LN01SP-AC had an on-resistance of 7.8Ω, which is a little high—it might be better to use a slightly better nFET with a lower on resistance, as the column current varies with the number of LEDs lit, and we don’t want the brightness to change much. For about 13¢ more per transistor,we can get NTD3055L104-1G, which have a 100mΩ resistance—though that is for a 5V Vgs, and we are planning a 3.3V Vgs, which appears to increase the on-resistance by about a factor of 5, based on the current-vs-Vgs curves on the data sheet.

We then looked at using a pFET to control the rows.  The gate voltage would be 0V for an on pFET, and 3.3V for an off pFET, so with the source at 5V, Vgs is -5V for off, and -1.7V for on.  We had a hard time finding many pFETs with a threshold guaranteed to be between -1.7V and -5V, so I added the idea of adding an inverter powered from the 5V supply, so that the gate voltage is 0V or 5V, and the threshold merely needs to between 0V and -5V, which is easy to meet (VP2106N3-G, for example, which has a 7Ω on-resistance for a 5V drive).  We discussed the need to include this on-resistance in the current-limiting resistance calculation, but there is no need to seek a very low resistance, as only one LED is drawing current through the pFET at any time.

So the final design that we came up with by the end of class looked something like this:


We didn’t discuss it, but the decoder should probably also be powered from the 5V USB power, so that it can turn the nFETs on more completely, giving a lower on-resistance for the columns.

2016 January 27

Student projects selected for Winter 2016

Filed under: freshman design seminar — gasstationwithoutpumps @ 21:46
Tags: , , ,

The students today selected their projects and teams.  We ended up with three different projects:

  • Ultrasonic rangefinder.  This involves building a rangefinder from transducers, not just hooking up an already designed rangefinder (though rangefinder modules from China are cheaper than the pair of transducers that they include). There are 3 students on this team. I ordered TCT40-16R/T 40kHz transceiver pairs from two different sources on e-bay, hoping that one of the packages will arrive within two weeks, and that they don’t both get caught in the Chinese New Year holiday.  If both come, I’ll have huge numbers of transceivers (16 pairs).
  • Pulse monitor. This is almost identical to the pulse monitor project in the applied electronics class, though I’m hoping that the students will have time to try to extract the pulse rate from the signal—doing some programming as well as the electronics. There are 2 students on this team.
  • LED cube and capacitive touch keyboard.  This is a “fun” project, with little direct applicability to bioengineering.  The hard parts are figuring out how to do the 3D soldering and getting individual control over all the LEDs with the limited pinout of the Teensy board. There are either two teams of three or three teams of two—I wasn’t entirely clear how the six students divided up.

Now I have to figure out what needs to be taught for each of these projects.  I’m pretty clear on the pulse monitor, as I’ve done that one before, but rangefinder and the LED cube are new.

The Teensy boards have capacitive touch inputs built-in, so the capacitive-touch keyboard will be fairly trivial using the touchRead() function of Teensyduino, which reports approximate capacitance in units of about 50pF. I’ll try making a 5-key keyboard this weekend and seeing how well it works.  I’ll try both a large-plate sensor, like I’ve used for the applied electronics lab and a design alternating sense wires and ground wires.  I suspect that the alternating wire design will be less sensitive to 60Hz pickup, but also a bit less sensitive to touch.

I’ll have to look at some of the RGB LED cube designs, to see how they are multiplexing the signals. I suspect that they use either Charlieplexing or a 1-of-n decoder.  A 4×4×4 cube has 64 LEDs (192 if RGB), which needs 9 pins (or 15 for RGB) if Charlieplexing, and 8 (or 16 for RGB) with a 1-of-16 decoder. The decoder makes for much simpler mapping and coding, which is important for programming color patterns. There aren’t enough PWM channels to do a good job of getting arbitrary colors at each LED, but PWM could be used for brightness (and some patterned color changes).

I think that the ultrasonic rangefinder will mainly be software, if we do all the pulse generation and detection digitally. The speed of sound is about 340 m/s (more precisely 331.5 m/s+0.6 T m/s/°C), so a resolution of 1mm requires 2.9µs resolution for time (typical cheap range finders have a 1cm or even 1″ resolution). If we sample the incoming sound every 2.5µs and store the waveform for processing, the 8k bytes of RAM on the Teensy LC can store enough data for the round trip for an object up to 3.48m away (if storing only one byte per sample).  The Teensy 3.2, with 64k bytes of RAM could store enough data for an 13.9 m range with 16-bit samples, but the echo would probably be much too quiet at that distance (I haven’t checked whether the analog-to-digital converter can do a 16-bit conversion every 2.5µs).

The common approach for many of ultrasonic range finders is to rely entirely on the resonant receiver to filter out the desired signal, and just amplify and threshold it to detect the first returning echo, which makes for fairly simple programming. If we record and do digital processing of the returned waveform, we should be able to detect multiple echoes, and it may even be advantageous to use a non-resonant microphone as a detector to get less ringing.

I checked to see if a non-resonant microphone would work, using a cheap electret microphone (probably CMA-4544PF-W), my microphone preamp for the applied electronics class, and the BitScope oscilloscope. I seem to be getting about a 1µA peak-to-peak signal from the microphone when listening to the Maxbotix LV-MaxSonar-EZ rangefinder for the direct signal close by, and about 0.1µA  peak-to-peak for a bounce from about 25cm away. The pulse from the Maxbotix lasts far longer than one might expect (almost 1ms), which indicates substantial ringing in the transmit transducer, and explains why the Maxbotix can’t detect distances less than about 6″.

It looks like a non-resonant microphone will be able to pick up the signal, though substantial amplification and some filtering will be required before digitizing, and I’m not sure how difficult it will be for the students to do the programming for high-speed analog-to-digital conversion, as the Teensyduino software probably doesn’t support 400kHz sampling rates.

It looks like all three projects are doable, but I’m not sure whether to steer the rangefinder group towards electronics or digital filtering solutions (and they will need steering, as they know neither electronics nor programming currently).

%d bloggers like this: