I’ve had a fairly varied early part of my career in the semiconductors business: a series of events caused me to jump disciplines a little bit, and after one such event, I landed in the test engineering department at Philips Semiconductors. I was tasked with a variety of oddball projects, supporting engineering work, fixing broken ATE equipment, and given a absolute ton of training: Good times! Here’s a story that comes straight off the oddball pile.
We needed to assemble a crack team of experts and high-tail it to deepest darkest Wales, and sort out an urgent production problem. The brief was that the wafer probe yield was disastrous and the correlation wafer was not giving the correct results. Getting to the punch line is going to require some IC fabrication background, but if you like stories about silicon, or red-bearded test engineers, it’s worth it. Continue reading “Hair Today Gone Tomorrow: Four Men Go To Fix A Wafer Prober”→
A lamp used to be simple thing: just stick a filament in a glass bulb, pass a current through it and behold! Let there be light. A bigger lamp meant a larger filament, taking more power and a larger envelope. Now we’ve moved on a bit, and it’s all about LEDs. There really isn’t such a thing as ‘just an LED,’ these are semiconductor devices, made from relatively exotic materials (OK, not just plain old silicon anyway) and there is quite a lot of variety to choose from, and a bit of complexity in selecting them.
For [Torque Test Channel] the efficiency of conversion from electrical power to radiant power (or flux) is the headline figure of interest, which prompted them to buy a bunch of lamps to compare. To do the job justice that requires what’s known in the business as an integrating sphere (aka an Ulbricht sphere), but being a specialist device, it’s a bit pricey for the home gamer. So naturally, they decided to build the thing themselves.
Coating the inside of the foam sphere took several attempts.
Firstly they did the sensible thing, and shipped off their test units to a metrology lab with the ‘proper’ equipment, to get a baseline to calibrate against. Next they set about using some fairly common materials to construct their sphere. The basic idea is quite simple; it has a uniform diffuse internal surface, which ensures that all photons emitted by a source can be measured at the appropriate measurement port, regardless of the angle they are emitted from the source. This way, the total radiated power can be determined, or at least estimated, since there will be a degree of absorption.
Anyway, after a couple of false starts with coating the internal surface, they came to the conclusion that mixing barium sulphate into the paint, and then a bit of a rub-down with sandpaper, gave the required pure white, diffuse surface.
The results from their testing, using a lux meter inserted into one of the other ports, showed a pretty good correspondence between their measured lux figure and the lab-determined lumens figure. Since one lux is defined as one lumen per square meter, they seemed to get lucky and found a consistent ten-to-one ratio between their observed value and the lab. This factor will be simply due to the physical setup of their contraption, but an encouraging result so far anyway. And what about the bottom line? Did those test units deliver their promised lumen output? It would seem that they pretty much did.
[Joe Wingbermuehle] has an interest in computers-of-old, and some past experience of building computers on perfboard from discrete transistors, so this next project, Q2, is a complete implementation of a PDP8-like microcomputer on a single PCB. Like the DEC PDP-8, this is a 12-bit machine, but instead of the diode-transistor logic of the DEC, the substantially smaller Q2 uses a simple NMOS approach. Also, the DEC has core memory, but the Q2 resorts to a pair of SRAM ICs, simply because who wants to make repetitive memory structures with discrete 2N7002 transistors anyway?
SMT components for easy machine placement
Like the PDP-8, this machine uses a bit-serial ALU, which allows the circuit to be much smaller than the more usual ALU structure, at the expense of needing a clock cycle per bit per operation, i.e. a single ALU operation will take 12 clock cycles. For this machine, the instruction cycle time is either 8 or 32 clocks anyway, and at a maximum speed of 80 kHz it’s not exactly fast (and significantly slower than a PDP-8) but it is very small. Small, and perfectly formed.
The machine is constructed from 1094 transistors, with logic in an NMOS configuration, using 10 K pullup resistors. This is not a fast way to build a circuit, but it is very compact. By looking at the logic fanout, [Joe] spotted areas with large fanouts, and reduced the pull-up resistors from 10 K to 1 K. This was done in order to keep the propagation delay within bounds for the cycle time without excessive power usage. Supply current was kept to below 500 mA, allowing the board to be powered from a USB connector. Smart!
Memory is courtesy of two battery-backed 6264 SRAMs, with the four 12-bit general purpose registers built from discrete transistors. An LCD screen on board is a nice touch, augmenting the ‘front panel’ switches used for program entry and user input. A 40-pin header was added, for programming via a Raspberry Pi in case the front panel programming switches are proving a bit tedious and error prone.
Discrete transistor D-type flip flop with indicator. Latest circuit switched to 2N7002 NMOS.
In terms of the project write-up, there is plenty to see, with a Verilog model available, a custom programming language [Joe] calls Q2L, complete with a compiler and assembler (written in Rust!) even an online Q2 simulator! Lots of cool demos, like snake. Game of Life and even Pong, add some really lovely touches. Great stuff!
Now, we know what some of you are going to say — “Oh man, not another programmatic CAD tool, what’s wrong with OpenSCAD?” — and you may be right, but maybe hold on a bit and take a look at this one, because we think that it’s now pretty awesome! OpenSCAD is great, we use it all the time round these parts, but it is a bit, you know, weird in places. Then along comes CadQuery, and blows it out of the water ease-of-use and functionality wise. Now, we’ve seen a few mentions of CadQuery over the years, and finally it’s become a full-blown toolset in its own right, complete with a graphical frontend/editor, CQ-editor. No odd dependencies on FreeCAD to be seen! That said, installing FreeCAD is not a bad thing either.
The goal is to have the CadQuery script that produces this object be as close as possible to the English phrase a human would use.
[Maurice-Michel Didelot] owns a Sonos smart speaker, and was lamenting the devices inability (or plain unwillingness) to stream music from online sources without using a subscription service. YouTube Music will work, but being a subscription product there is a monthly fee, which sucks since you can listen to plenty of content on YouTube for free. [Maurice] decided that the way forward was to dig into how the Sonos firmware accesses ‘web radio’ sources, and see if that could be leveraged to stream audio from YouTube via some kind of on-the-fly stream conversion process.
What? No MP4 support for web radio? Curses!
So let’s dig in to how [Maurice] chose to approach this. The smart speaker can be configured to add various streaming audio sources, and allows you add custom sources for those. The Sonos firmware supports a variety of audio codecs, besides MP3, but YouTube uses the MP4 format. Sonos won’t handle that from a web radio source, so what was there to do, but make a custom converter?
After a little digging, it was determined that Sonos supports AAC encoding (which is how MP4 encodes audio) but needs it wrapped in an ADTS (Audio Data Transport Stream) container. By building a reverse web-proxy application, in python using Flask, it was straightforward enough to grab the YouTube video ID from the web radio request, forward a request to YouTube using a modified version of pytube tweaked to not download the video, but stream it. Pytube enabled [Maurice] to extract the AAC audio ‘atoms’ from the MP4 container, and then wrap them up with ADTS and forward them onto the Sonos device, which happily thinks it’s just a plain old MP3 radio stream, even if it isn’t.
Some people like crossword puzzles, some are serious sudoku ninjas, but [Andrea Favero] likes to keep himself sharp, by learning coding and solving control problems, and that is something we can definitely relate to. When learning a new platform, it’s a very good idea to have a substantial project or goal in mind, and learn what is needed on the way there. [Andrea] chose to build an autonomous Rubik’s cube solver, and was kind enough to document exactly how how to do it, and we’re glad of it!
The result of the openCV processing chain
Working in python with OpenCV, [Andrea] uses the methodology by [Oussama Barkouki] to process each face image and convert it into a table of the colours of individual facelets. The basics of that, are first to convert the image to grayscale, then use a gaussian blur to denoise the image. Edges are identified using the canny algorithm, the result of which is then dilated and passed into a contour detector. The contours are sent into a cunning filter that identifies square contours, and those the wrong size are filtered off. What you’re left with are the outlines of the actual coloured facelets. Once you have a list of squares, these can be used to form image masks, and thence select the average colour from each square. The colour is then quantised and stored as a labelled colour from the standard Western Rubik’s cube colour scheme. Finally, once all face images are captured and facelets colours identified, the data are passed into a Rubik’s cube solving algorithm developed by [Hegbert Kociemba,] a guide to which is available on the speedsolving site. The result of the solving step is a sequence of descrambling moves, in the move notation developed by [David Singmaster]. Fascinating stuff, if you ask us! Continue reading “Forget Sudoku, Build Yourself A Minimalist Rubik’s Solver Robot”→
One custom, compliant heat exchanger, coming right up!
[Thane Hunt] needed to find a way to make a variety of different heat-seal patterns on a fluid heat exchanger made from polyolefin film, and didn’t want all the lead time and expense of a traditional sealing press machined from a steel plate. Pattern prototyping meant that the usual approach would not allow sufficient iteration speed and decided to take a CNC approach. Now, who can think of a common tool, capable of positioning in the X-Y plane, with a drivable Z axis and a controlled heat source? Of course, nowadays the answer is the common-or-garden FDM 3D printer. As luck would have it, [Thane] had an older machine to experiment with, so with a little bit of nozzle sanding, and a sheet of rubber on the bed, it was good to go!
Custom seal path made in Onshape
Now, heat sealing is usually done in a heated press, with a former tool, which holds the material in place and gives a flat, even seal. Obviously this CNC approach isn’t going to achieve perfect results, but for proof-of-concept, it is just fine. A sacrificial nozzle was located (but as [Thane] admits, a length of M6 would do, in a pinch) and sanded flat, and parallel to the bed, to give a 3mm diameter contact patch. A silicone rubber sheet was placed on the bed, and the polyolefin film on top. The silicone helped to hold the bottom sheet in place, and gives some Z-axis compliancy to prevent overloading the motor driver. Ideally, the printer would have been modified further to move this compliancy into the Z axis or the effector end, but that was more work. With some clever 3D modelling, Cura was manipulated to generate the desired g-code (a series of Z axis plunges along a path) and a custom heated indenter was born!
