I made a first round of experiments with adding LEDs to the ports of M1r4. Here are the pictures:
Front side: http://downloads.qi-hardware.com/people/werner/m1/leds/collage-front.jpg Audio/VGA side: http://downloads.qi-hardware.com/people/werner/m1/leds/collage-vga.jpg Power/Ether/Video in side: http://downloads.qi-hardware.com/people/werner/m1/leds/collage-dc.jpg MIDI/DMX side: http://downloads.qi-hardware.com/people/werner/m1/leds/collage-midi.jpg Some of the images may look a little weird. That's because they're composed of multiple shots with one red LED at time. There are also support elements, visible in collage-vga and collage-midi, that I've more or less successfully tried to remove from collage-front and collage-dc. The LED ------- The red LED I used is a LTST-C190KRKT (rated 54 mcd at 20 mA), driven at ~6.3 mA, pulsed with a duty cycle between 1% and 15%. The low duty cycle is to avoid overloading the camera's image sensor, as happens in collage-front.jpg with the green LEDs. In the real configuration, we'd have a maximum duty cycle of about 16% or 25%. (See below.) Here's the data sheet of the LED: http://optoelectronics.liteon.com/en-us/api/DwonloadFileHandler.ashx?txtSpecNo=DS-22-99-0151&txtPartNo=LTST-C190KRKT Issues found ------------ Now, this is just a first attempt. There are a few serious issues with the approach chosen there. The ones worrying me the most: - some of the LEDs are at hard to reach places, e.g., in small cavities under connectors, e.g., DMX, video in, - in some cases it's hard to tell which connector a LED belongs to e.g., the side with VGA, mic, and audio-in. Hard to reach LEDs would make it considerably harder to rework boards suffering trivial SMT problems (i.e., to fix a badly soldered LED you'd have to unsolder the messy through-hole connector covering it first) and may introduce assembly issues of its own. Going under ----------- Then we had the idea that, instead of these top-facing LEDs, we could use side-facing LEDs and mount them on the bottom of the PCB instead the top. This would elegantly solve the issues above: - basically all the connectors leave space at the bottom of the PCB: they have no mechanical structures there, and there's usually free space between through-hole pins and/or the pins and the board edge. Here's a virtual view of the PCB's bottom: http://downloads.qi-hardware.com/people/werner/m1/tmp/back.png - with free space at the center of the connectors, we can just place the LEDs exactly at the center of the corresponding connector, eliminating most ambiguities. Remaining issues ---------------- The only problem spot would be the USB connectors, where the center position is be occupied by contacts. But since we plan to move to stacked dual USB receptacles (the kind you find on most PCs) anyway, this problem will disappear. A more severe problem is that a dual USB connector would need two LEDs, which brings back the question of which LED corresponds to which port. While we could have one LED on the top of the PCB and the other on the bottom, the top LED would have to be placed on the side of the connector, bringing back the "is it the one on the left or the one on the right ?" ambiguity. Perhaps placing both LEDs on the bottom with a simple convention, e.g., that the one the left is for the top port, will be good enough. Maybe we could assist this by engraving little triangles in the acrylic wall. (The acrylic needs to be updated for M1r4 anyway.) Last but not least, a LED under the PCB could be more easily obscured by a connector than a LED on the side of the receptacle. Not sure if this would be a problem in practice. The side-facing LED ------------------- The choice for side-facing LEDs is a bit more limited than for top-facing LEDs, but still reasonable. The cheapest one at Digi-Key would be an exact equivalent of the top-facing one I used: http://media.digikey.com/pdf/Data%20Sheets/Lite-On%20PDFs/LTST-S270KRKT.pdf At a slightly higher price, there's also one that's considerably brighter: http://www.us.kingbright.com/images/catalog/SPEC/APA1606SURCK.pdf Wolfgang likes that one. It also makes sense to err on the bright side, since we can always dim a LED that's too bright, but it's hard to squeeze out more light from one that's too dim by design. The matrix ---------- This brings us to the duty cycle. In order to minimize the number of FPGA I/O pins we use, we should be able to arrange the LEDs in a matrix like this: http://downloads.qi-hardware.com/people/werner/m1/leds/mpx.pdf "A", "B", "1", and "2", would all be FPGA pins. The matrix would be lit one row at a time, with one phase for the X and one phase for the Y LEDs in the row. E.g., to light A1Y, one would drive row A = 0 row B = Z col 1 = 1 col 2 = Z One thing to consider would be the effect of sneak current paths in the matrix. E.g., in the above example, there would also be the path 1-B1Y-B2X-A2Y-A. Since this path involves three LEDs and the voltage between 1 and A is limited to roughly the LED's nominal Vf by R1 and A1Y, each of B1Y, B2Y, and A2Y should see only Vf/3 and thus stay dark. But this needs testing in real life. Since we'd have a 2x4x2, 3x3x2, or 3x4x2 matrix, the maximum duty cycle of each LED would be 1/rows/2 = either 25% or 16.7%. The maximum current would be determined by the FPGA's I/O drive strength, which is 24 mA, according to note 2 on table 9 on page 10 of http://www.xilinx.com/support/documentation/data_sheets/ds162.pdf In a 3x3x2 configuration, each LED in a row could be driven with 8 mA. In a 2x4x2 or 3x4x2 configuration, this would have to be lowered to 6 mA. I haven't been able to find total per bank sink/souce current limits for the FPGA. In case there is a problem with sinking/sourcing 3*24 mA = 72 mA for the LED matrix, the rows could also be switched with two transistors in a totem pole configuration: http://en.wikipedia.org/wiki/Totem_pole_output This would double the number of row control pins, though, and one could pick a unidirectional 6xNx1 configuration instead. To do ----- - make a sideways-facing LED and see how it looks, - make the test board in the ledm.* files under http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/m1/ledravaganza and see if the thing works as well in practice as it seems to in theory., and - determine the final LED count. - Werner _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode
