During disassembly of some old CD/DVD drives, I stumbled across a pair of *really* beautiful laser diodes. Not much use for them right now, except practicing macro shooting – pretty hard to get good pictures of the structures inside and the dichroitic filter blue at the same time.
So…it’s been a while. Somehow I thought, I’d have finished the CNC writeup by now, as well as my plans for continuing work on my plasma-bar meter project. Things turned out different.
I got into my Bachelor’s thesis after completing the preceding seminars, which kept me busy since june ’13. The topic is centered around signal power based speech DOA estimation using directional microphones, very interesting stuff from the domain of signals processing. I had a very interesting time learning lots of new things, and somehow I also wanted to get hands-on with the matter since attending several advanced DSP courses during the last two terms.
While working on the thesis, I realized that microphone array systems are really nice things to have to play around with. I decided to make my own, which I did in my free time in parallel to the thesis. Let me at least show some pictures as long as I still don’t get around to working on other stuff.
Basically, the array consists of four Panasonic WM-61A electret capsules, which are known for their robustness under high sound pressure levels. The capsules are mounted on several 140mm long, 6mm dia. brass tube segments using aluminum sticky tape and heatshrink. The mounting method ensures no acoustical reflectors or flat faces in the near field of the microphones, which enhances the acoustical properties of the whole assembly. All sound ports are pointed upwards to keep the characteristic beam patterns of the microphones as similar as possible. According to the datasheet, this should be an omnidirectional pattern for each capsule, but the mounting causes some deformation. In this case, the bottom direction (sound coming from along the brass tubes) is somewhat sub-optimal.
To connect the capsules, I used 2-lead shielded microphone cable with a 3-pole headphone plug at the end. I applied the “Linkwitz mod” (http://www.linkwitzlab.com/sys_test.htm) to rewire the capsules for better preamplifier performance, using the described two-wire connection for the capsules. I didn’t connect the shield on the capsule side, but the capsule has a pretty good metallic connection to the brass tube, which means that the shaft is connected to microphone ground. For the meantime, this solution is sufficient, even though it would be better to connect the shaft to the shielding and keep the capsule isolated to prevent a ground loop. I will correct that at a later point since it is pretty hard to connect a wire to a brass tube from the inside, if you can’t solder for fear of the cable melting Well, I’ll figure that one out eventually. For now, humm and distortion is low enough for the purpose.
To keep the array together I cut a piece of layered wood (called “Multiplex” here) on the CNC mill, drilling holes for the brass holders in predefined distances that match the parameters of my DOA estimator project. The brass tubes are pushed tightly into the holes and the cables dangle out of the bottom. An extra hole in the middle allows the assembly to be attached to any kind of support with a 6mm screw.
The preamp is still breadboarded for now. Shielding is pretty bad (or in other words “not present”), but nevertheless it performs rather well. I get a little bit of hum from nearby power lines, but I can blank that out in software for the time being. The case (cast aluminum) is already in the making, and has also proven to be an adequate test for the CNC to demonstrate its ability to mill aluminum. Not perfect to the 0.001, but near enough. I will integrate the amplifier into its new home as soon as I get a little more free time to mill a pcb, which will be in another two weeks, when all the other stuff is finished.
For signal acquisition, I currently use an ESI MAYA 44 USB+ 4ch-in/4ch-out external soundcard, which has the nice benefit of being ASIO-capable and can be used with MATLAB and especially Simulink. The latency is not as rock-stable as with cards like the RME Fireface series used in the university labs, but with some MATLAB trickery, I can get more than acceptable results out of it.
The CNC mill got into a working state right before christmas eve. I know it’s not a present in that sense, but still! :3
Some parts of it are still fixed with a lot of glue and tape (or zip-ties ^^), but for now that’s perfectly sufficient. Right now. it can already mill hard wood and MDF, so I will be redoing some critical parts that lack in precision and/or quality before I write up the whole project as one. Unfortunately, I fear that the original plan about using an (older) EPIA 800 board as a controller can not be followed, EMC2 just refuses to start on that thing. Grrrr…
More pictures and text will follow in a few day’s time. Until then, enjoy the holidays and have a nice and safe start into the new year!
Oh, right, and two Stellaris Launchpad eval-kits from TI that I ordered back in September arrived JUST ON the 24th. How great of a timing is that? I don’t care about the wait, it was well worth it and I knew up front – but thanks again to the girls and guys of the TI support, for solving all the technical difficulties along the way
I picked up some unusual plasma displays from ebay some weeks ago, which I have been searching for quite some time now. The picture above shows an illuminated Burroughs PBG-12201 plasma bargraph display. They are pretty hard to get by now, and if available, prices are a real shocker. Some shops in the US that carry them ask for 230 USD and some even more. Sometimes they appear on ebay for about 50 USD, but you have to be real quick to get some. Best chances are with surplus stores that sell off leftover production stocks or disassembled devices that originally contained such tubes. A few very retro and very popular mixing consoles for audio applications used them as main VU meters (eg. made by Lexicon), as well as some current professional grade standalone meters (eg. RTW, one of those is where I first saw such a display and was absolutely fascinated by the deep orange hue). As they eventually get old and start flickering or burning in if not properly cared for, spare parts have become rare, and since Vishay – the most recent producer of these displays – has discontinued the product line in early 2012, I would expect the market to dry up even more.
Mine were obviously scavenged from some kind of device by a Hungarian ebay seller, he offered some 10+ pieces of the PBG-12201 type display for 8 Euros each – a real steal! I just couldn’t resist and got myself three of them, together with matching sockets. Thinking back, I don’t get why I ordered three instead of four…oh well, it’s done. The tubes show some signs of wear, like glass chipped off around the edges and burn marks on the cathode traces, but they all work fine.
Devices like these use an interesting driving technique (from a retro point of view, today it is more of an old hat) as they are linear dot scanning displays – and befitting, the trade name for them is “Self-Scan”. The basic structure resembles a nixie tube: An evacuated sandwich made out of a glass plate and a ceramic back plate is filled with neon gas that can be ionized by applying a high voltage between a transparent anode metal film on the backside of the glass front plate and some printed cathodes on the back plate. However, this is a linear display, so it doesn’t consist of numbers but instead of small lines that have been masked by some isolating grey lacquer applied on top of the conductive traces. The left-out spaces in the mask form the slightly brighter active areas where the neon glow will appear. All in all, the tube provides two independent bargraphs with 201 segments each.
There even was a cool circular type of this display, but I don’t think there is any recent production of those.
The port at one end of the tube features connections for:
- A pair of standby keepalive electrodes (Anode/Cathode) that are placed opposite of each other on the glass and ceramic plate. These are permanently lit up to keep a level of ionisation and never let the tube supply idle.
- Two independent anodes for the two bar strips.
- A reset electrode (actually the first strip in the bar)
- Three connections to an interleaved network of fine traces on the ceramic plate that are used to control the length of the bar. These cathodes are laid out to form three phases, meaning the 1st, 4th, 7th, etc. dots are connected to each other. As are all the dots shifted by one upwards, e.g. 2nd, 5th, 8th and so on. Finally, the same goes for the 3rd, 6th, 9th, etc.
To control the length of the bar, a rotating three-phase signal is applied to the three electrode combs. The comb corresponding to the currently next segment is switched to ground using a high voltage capable transistor (MPSA42 or comparable) and thereby “pulls” the glowing dot one step forward, then the connection is broken and the next comb in turn is switched to ground. When the end of the bar is reached, the phase signal is reset to the first phase and the reset electrode is pulled to ground for a fixed period of time. This extinguishes the glow and reignites it back at the first bar of the display. Only one electrode is glowing at a time, which gives the display a very precise scale and (in my opinion) makes it much more appealing to the eye than any continuous-glow linear nixie, like for example the IN-13.
Just to have covered the fundamentals: If you would slow down the scanning process of the display – which you actually can as the display is VERY tolerant of SLOW scanning times) – a single dot would travel the length of the bar. Persistence of vision (the slow recovery of the retina) makes this scanning process appear as a bar if the scanrate is high enough. Today, it is called multiplexing and used extensively in LED matrix displays. This also explains the missing-piece phenomenon in the second picture: Imagine the shutter of the camera opening while the dot wanders from 2/3rds of the bar to the end, wraps around and runs from the beginning up to 1/3rd.
A bar of varying length can be displayed by running the glowing dot up as many steps as needed, then resetting the display and starting again. There are specific minimum times that need to be maintained for phase on-time and reset on-time, so the display won’t start to flicker around erratically. One can achieve “frame rates” of up to 70 Hz for these displays according to the datasheet, which makes them flicker-free. My first attempts showed that there is some margin to the values, so experimentation is definately useful. Even more so if some of the dots should be of varying brightness. The way to achieve this is actually described at some point in one the datasheets if I remember correctly, but the principle is the same as when scanning LED displays: on-time control for each dot). In the pictures I have highlighted some random bars, this could certainly be used to make a scale. Unfortunately, the scale can only be visible in the lit-up area of the bar, because the display does not allow dark-scan to the point a scale mark is wanted at. Remember, the glow follows the grounded electrode – we can’t really make it jump across multiple bars, can we.
Also, there is some ghosting of the highlight marks because I drove the display with only about 180V dirty unfiltered DC with some serious ripple on it – probably as many as a few dozen Volts – where it typically needs about 250V pure DC to run. Well, it can’t be helped for now until I manage to find a matching ferrite for a step up supply in the depth of my boxes, so I used an old cheapo EL foil inverter I had lying around.
Maybe there is a possibility to scan the dark parts of the bar super-fast if the operating voltage is high enough, but I can try that only after I construct a proper supply.
I am currently driving the display from a simple breadboarded test circuit around an ATMEGA8 MCU while the high voltage side is handled by four MPSA42-transistors that I still had lying around from some recent audio power amp repair job. Note that I have not used base resistors, since the datasheet rates these transistors for Ib,max=100mA. While this is quite reckless to the chip and the transistors, it usually works for a crude test – a typical case of the “don’t want to walk to the basement and get some”-disease. Even so, it’s a no-no in proper designs. Collector resistors are not needed for the phase drivers because the current is limited by anode resistors already. The anode voltage is generated by said battery EL inverter which outputs about 150V of far-from-sinusoid AC, which I then one-way rectify using a single HV diode of a rectifier bridge to obtain about 180V DC. This is just sufficient to make the display ignite, but it causes severe troubles with stability. Misses a beefy cap.
EDIT: As usual, found a cap that I was looking for all over the place just when I had finished writing. Scavenged from a photo flash unit, 330V at 100 µF, plenty of charge. While the supply is still far from perfect, it does help to smooth the DC some. Enhances the risk of a painful encounter, too. This fixes most of the trouble with the bar for the moment, see the added a picture above. I will try for some daylight-comparable shots tomorrow.
In the link section below is a link to the official application note by Burroughs, which explains all the details of the drive circuit and also the possibility to drive the display using logic only. It’s nothing complicated really, but using a microcontroller brings all the advantages of being able to control precise on-times of each dot indepentently, so I guess that’s the way to go.
The next step will be to make a proper schematic and board for this with a proper supply and some analog or digital audio analysis circuitry and/or a digital control input. One of these would look great in the front of some big DIY amp, maybe behind a piece of smoke-colored acrylic or tinted glass
Some background info and other projects for this kind of display:
Work on the CNC continues…the end draws nearer. I am currently disassembling the whole thing as far as necessary to clean up all the edges and burrs and fix the positions of the parts relative to each other using hammered-in stainless steel pins. After that, it is just coupling the threaded rods to the moving parts and bring the stepper drivers alive.
A follow-up on the recent DNS-related stuff:
I figured out today that my router had a hand in those weird random connection problems. What made me especially nervous was the almost systematic way that DNS and other random UDP packets vanished from the ‘net during browsing or testing with various tools. The requests were shown to be sent in both the Wireshark protocols and the router packet capture, but an answer never arrived. As it turns out, Enterprise-class devices have their firewall preconfigured to block UDP flood from inside the local network.
The definition of “flood” used here is:
“20 simultaneous, active UDP connections from a single computer on the LAN”
Now, somehow my setup managed to step over that line, and from what I gather on the ‘net I am not the only one experiencing this. Sometimes the system will run clean for a few days, then bug in increasing frequency until I get fed up with it and kill the whole DNS process plus cache. Apparently, this fixes the problem for some time as a good reset almost always does, but it is no permanent solution.
To debug, first turn on the attack-related logging functions in the router and clear the logs. Then call up “nslookup” on Windows based systems and fire some random URL DNS requests in fast sequence. In my case, after four requests the firewall kicks in and UDP flood warnings appear in the log. Maybe Windows 7 just leaves the ports open a little too long, I don’t know and I haven’t checked. However, since this feature has been turned off in the firewall settings I had no further DNS problems, and the speed of browsing has increased a little. Hopefully that was all there was to it.
Another point of interest: Some Netgear devices have developed a habit of kicking lots of NBSTAT-packets on the LAN, one about every 5 seconds or so. Seems to belong to some type of NETBIOS detection mechanism, though the sense escapes me. The packets are of unicast-type and therefore disrupt everything one could possibly have in the way of wake-on-unicast, which linux supports to wakeup devices from standby if they are talked to directly. NETBIOS features are nowhere to be found in the configuration menu, so I guess at some point the checkbox for that must have gotten mislabeled. The one responsible is “ARP broadcast” found with the LAN settings. Turning it off quiets things down a lot.
I’ve been having some problems connecting to IRC through the miranda client on Win 7 lately.
Miranda features several “serverlists” for different IRC networks – QuakeNet in my case. Some of the lists work, some don’t, some work at some times. Now, upon clicking edit only one fixed web address shows up. The way this works is, the DNS server knows multiple IP subentries for those servers. You can check with some web-based lookup tools that show all of those entries. Windows’ own command (“nslookup <address>”) only shows the one delivered by the server, as it needs only one precise IP to communicate.
Multiple entries exist to balance load between servers, they are delivered round-robin. If you flush your dns cache locally (Win 7 wants you to do “ipconfig /flushdns” on the console in admin mode, for example) a new IP is acquired – and this one is ideally different from the one before. Now, because Windows does not clear the cache between requests for several logical reasons (it’s a cache, right?) the client program obviously also knows only one of the possible IPs. All the better if exactly that IP is down.
It took me quite some time to figure out where the problem was (all the while thinking there may be something wrong with the router or the net is just in a weird mood today). After checking the DNS entries sequentially using ping and a connection attempt through Miranda, I found to my surprise that while some lists work partially others are simply dead.
|irc.quakenet.org||1/8 working||Compilation of all subranges|
Remember that this data is momentary from the time I checked the servers. The status might be different now. Anyways, this is some russian roulette!
The lists may fluctuate though, I am pretty sure I got a connection using the german list at some time. It is also possible, that the lists are updated dynamically from time to time, but I haven’t seen it so far.
Fixing this mess is quite easy: just edit or add a list in Miranda for the corresponding network and enter the exact IP. You best find that one yourself by pinging, start with one of the shorter lists you are comfortable with. You will experience trouble if that server goes down, but at least then you will know what the heck is wrong right from the start. Saves time and nerves.
So much for the current status of the CNC milling machine. I have made some first experiments with L297/298 motor drivers and found out the hard way that these are quite overloaded with such strong motors. Burnt out in a matter of seconds. But, as BJT driver bridges are not state of the art anyways, and I want to take a lesson from this project, I decided to finally get myself some of those specialized ATMEL controllers (AT90PWM1) and try to design my own FET bridge driver.
I even have one in spare that I can use for experiments with a self-designed high intensity discharge lamp driver – I have attached an image of an early prototype to the gallery for your entertainment. Worked quite well for some time, but the driving was very crude – there are some logic gates on the bottom of that small pcb that generate half-bridge signals for the two FETs, but no care taken about anti-shoot-through and so on. VERY crude. I will report how well the new controllers work out, seeing that very few experiences are found
As for the CNC, I am quite confident that I will finish the mechanics part within the next holidays (around easter). Then, all that remains is the ‘intelligent’ part.
Last but not least, I notice that I still do not manage to describe my projects in my self-desired level of detail. Thus I will focus more on taking pictures during the process and explaining from now on.
Today, I want to write a few words about another of my older projects.
A while ago, I started building this DIY UV exposure box. The electrical part consists of a self-designed count-down timer based on an AVR Tiny2313 CPU, 4x8W PHILIPS UV tubes, ignition/driver circuits from cheap fluorescent bulbs, a multiplexed numeric LED display, a rotary encoder and some wiring. A piece of ~4mm aluminum serves as a faceplate, picture frame glass as the exposure surface. We’ll have a look inside in a moment.
When turned on, the controller presents the configuration menu first. All options are preset – or should I say ‘preprogrammed’ because the preset cannot be changed, as of yet – to the values I use most frequently. Configuration includes the time (up to 9min 59sec), a variable tube preheat time up to 59 seconds and a zone selection. The zone selection does nothing at the moment, but the pcb features a mounting spot for a second solid state relais which I have not yet installed. Which means, all four tubes are activated.
Press the selector one more time and the process starts. To stop again, either press the button again, switch off the mains or wait patiently until the time runs out.
Now, on to the inner values. After undoing 7 torx screws, the lid can be removed to access the elecronics compartment behind the front panel:
Inside the compartment is the four-fold ballast circuit, which consists of four board found in the sockets of fluorescent energy saving lights. These are pretty cheap compared to commercial electronic or inductive ballasts and they can be used right as they come. The only crucial number is the power rating – my tubes are rated for 8W while the ballasts came from 9W bulbs, which works just fine. Care has to be taken when opening the sockets, though. The bulbs should be left lying around for some time prior to “dissection” because they contain a pretty juicy capacitor. The circuit inside is basically a simple switchmode current supply. When that’s done, an easy way is to cut them open along the circumfence about in the middle of the socket’s height with a fine saw blade. Don’t cut too deep or you will damage the pcb. Once the casing is open, mark the pairs of wires coming from each end of the tube before cutting them. These pairs need to go to the ends of the UV tube, don’t mix them up or you’ll short out the circuit. How the two wires connect to the two pins of the tube on each side is completely up to your choice, though.
As always, remember the hazards involved when dealing with mains equipment, especially such that was never designed to be opened or even run in the open. Also, don’t go breaking any fluorescent tubes as they might contain traces of mercury.
The four ballasts are wired in parallel to the mains, with just a fuse, the power switch and a solid state relais in series. Fuse-wiring got a little complicated because I forgot to place separate fuse sockets for controller and drivers onto the pcb, but nothing dangerous here. A connection between faceplate and protective earth is also present for safety reasons, seeing that there is lots of live wiring very near. You may have noticed the absence of any cooling fan or holes – these are not necessary as the device is run for a few minutes at a time and never unobserved. The ballast circuits are designed for operation in a very tight unventilated space anyways, so no trouble to that end. After ~5 minutes of exposure the glass surface becomes just noticeably warm.
To the right is the control circuit, consisting of said ATTiny2313, a small 6VA transformer-powered 5V supply, the solid state relais (SHARP S202S02) and three npn transistors as segment drivers for the LED display. I still have some pictures from back when I made the pcb (about a year ago now):
I have used this exposure box several times now and am pretty content with the results. There still remains some creepage of light between the layout print and the photosensitive layer, resulting in fuzzy edges of traces and larger groundplanes sprinkled with small holes. This is partly thanks to an absolutely ridiculous laser printer made by HP (Color LaserJet 2600nse). No matter what settings are used (even in the expert options), the printer will never do dense black withing planes and very often blur traces on either the leading or trailing edge. Text works fine, though.
You may download the schematics in Eagle 6 format at your leisure. I do not guarantee correctness of the layout, though. There was a small problem in an earlier version (Pin 1 of ribbon cable connector was not connected to ground) which I have fixed now.
I do not take any responsibility for whatever happens to you. It’s up to you to decide if you want to and are able to build something like this.
* NOTE: Make sure that pin 1 of the front panel connector is really connected to ground, the traces were etched away in my case. The result is erratic behaviour of the rotary encoder.
Alright, time for another update linked to the CNC mill! I just finished the linear carriage for the X-direction. Still having some minor trouble getting a tight fit between the bearing-rollers and the rails, but I suspect this will be correctable later through adjustment. The whole thing needs to be carefully calibrated and aligned anyways before real milling action is anywhere near possible.
To be honest, I don’t think the alignment of the parts will keep up with vibration and forces for too long, which is why the most crucial parts will be remade with this mill while it works – that was the goal from the beginning.
The next step now is to connect the threaded rod to the carriage and to finish the drive system for the Y-direction, which will reside below the table and pull the whole portal sled through a rod that passed through the table. The table supports and Y-rails are still sitting in the workshop, waiting to be cleaned up.