I recently bought a (comparatively) cheap K40 laser engravercutter and am slowly getting to know it, whilst also getting ready to heavily mod it. I have plans to improve (slightly) the cutting area, to add air assist, to replace the controller board and upgrade the bed (pretty much all the usual stuff) and I plan to blog about it as I go.
However here at the very beginning of the journey my machine is freshly calibrated and almost, but not quite stock. The bed was causing a few problems, not least that, when cutting large sheet material, the lip of the clamp brought the material too close to the laser. That was easily remedied by unscrewing the clamp and dropping it into the bottom of the machine (its metal, it will be quite safe down there). However the means the cut pieces drop to the bottom of the machine where they are at risk of damage from the laser working overhead… and small pieces can be hard to find because some idiot left a big metal clamp down there.
The solution turned out be a very cheap anti-splater guard for a frying pan. It cost me £1 (since Brexit that’s dropped to about $1.20) from a local discount store and for now I’ve just gaffer taped it to the underside of the existing bed. Since it’s working so well I’m thinking of driving a couple of self tapping screws into a couple of cable clips to hold the frame in place without any sticky residue.
This is working great for small items, catching any components that are cut from the middle of the bed and with absolutely no signs of backscatter. Amoung other things I’ve used this simple bed to build a case for my Carbon board (a 96Boards IoT edition micro-controller board) and the results are, I think, pretty awesome.
So a very, very simple mod but more than enough to allow the whole family to have a bit of fun with our new toy. Whilst its not quite as much fun just to watch I would still invite you to watch the video below showing the cutter creating the case for the Carbon. I find it oddly hypnotic!
I have amassed a modest collection of 96Boards. They come as plain circuit boards with nothing to keep them safe from damage during handling. Its not just static discharge we have to worry about! Many of the boards have fairly large components on the underside and these can be knocked off by careless handling (I admit that I’m tempted to say “Hi” to a colleague at this point, but I won’t). Since, I’m at least as careless about handling as the next software engineer so I decided a case was needed.
I’m not aware of anyone selling cases for the 96Boards Consumer Edition so I decided to get my own laser cut. As it happens between ordering the boards and writing this post I have started to come across a couple of other folks at Linaro who are experimenting with cases but nevertheless I think I’m still the first to blog about it!
There is a hackspace in Bristol, UK where I live which could be a great place to get involved in laser cutting but it’s right on the other side of the city and I’ve not really found the time to get very involved there. Instead I decided to try out the Seeed Studio online laser cutting service: 100mm x 100mm, cut to your own design for $6 for five (plus postage).
Having something of a plan the only remaining problem is that I know absolutely nothing about CAD/CAM. The only information on the Seeed Studio website about file formats is that I must send in .zip or .rar files and the only blog posts I could dig up wanted me to use the Google Sketchup which is non-free and partially discontinued.
In the end I just asked myself, “How hard can it be?” and fired up LibreCAD. After working through a couple of tutorials I learned how to round off corners and how to add dimension information. Armed with this, and the 96Boards CE Specification which has very clear diagrams of the physical layout of the board, I draw a basic top/bottom plate. I wasn’t happy with the 35mm of “wasted” material due to the minimum panel size of the manufacturer so I added a half-top component as well. The half-top should work very nicely with the 96Boards UART board.
Influenced by this blog post I decided to export from LibreCAD as an SVG. This turned out not to be such a great idea. The resulting SVG uses curves that are quantized to pixelish boundaries. The friendly folk at Seeed Studio declined to use it and askeld me for DXF files instead. Since DXF is the native file format for LibreCAD this was not much of a hardship.
And that’s it… I got a bunch of cases made in a couple of colours. The glowing neon green in the photo above is sooooo my favourite. I’ve hurled my design files at github and, because I’ve had so much fun with this, I’ve given the project a nice generic name. Maybe there are more cases to come. If that happens, you’ll read about it here first!
This is an old project that I’ve been meaning to blog about for some time and, over a year later, am finally finding the time to write up. The project is a USB controlled (and powered) bank of relays assembled from cheap boards that can be purchased from ebay. The total cost a controller board and a bank of eight relays is about £6.50 (or $10 USD if you prefer to count like that).
The controller board is an STM32F103C8T6 breakout board which provides the USB hardware and an ARM Cortex M3 CPU combined with enough FLASH and on-board RAM to make writing software fairly easy. These terrific little boards can be found on eBay for a whisker over £3 and are just perfect for hacking together all kinds of USB toys and tools (some of which may be the subject to further blog posts).
The only other components needed is the relay board and a bunch of jumper wires. Relay boards can be bought on eBay in single, dual, quad or octo configurations depending the complexity of your projects.
I use this project to automate things on my rather modest pool of development boards but definitely need all eight relays (and then some). My relays control power delivery and, for some boards, they are also used to automate changes to jumper configuration. The HiSilicon HiKey board (from 96Boards.org) is especially needy in this department. To automatically test its debrick/recovery process requires three relays. One for power control and a further two to manipulate the jumper configuration.
The completed system is fully USB powered with the relay board taking a 5V feed from the controller. Eight relays can be pretty hungry when they are all energised at once but we do just about manage to sneak in below the 500mA USB current limit.
So… the hardware in this build is very simple and can be assembled even by someone with no electronics knowledge. What about the software?
There is a complete firmware for the device which can be FLASHed to the controller board without much fuss. The firmware contains a simple command interpreter which is present to the host as a CDC/ADM class compliant device. This allows the device to operate without drivers on more or less any operating system.
Usage: relay1 on|off|toggle|pulse
> relay1 on
> relay1 off
Like any command interpreter the firmware can be automatically driven using an expect-like system. However on GNU/Linux (and I suspect any other Unix-like OS) it is sufficient just to hurl commands at the device node using shell scripts:
echo relay1 on > /dev/ttyACM0
The firmware has a couple of extra bits of polish to make it more practical. In particular the unique serial number embedded into all STM32 devices during manufacturing is extracted and persented as the USB serial number. This allows udev to be configured to recognise specific devices and give them stable device names regardless of any rearrangements of the USB bus topology. This allows a single host PC to (reliably) support a very large number of relays. Also included in the firmware package is a tiny shell scripted called targetctl which allows individual relays to be named, even across multiple usb-relay devices.
The firmware consists of a bootloader and the main image. The bootloader can be downloaded either using the UART bootloader included in the ROM of almost all STM32 devices. However I prefer to hook up an ST-Link (these are also easily found on eBay) to the controller boards JTAG pins to FLASH to bootloader. Once the bootloader is in place its easy to install the main image using a DFU programmer such as dfu-util. After the main image has been installed the device reboot and enumerate as a CDC/ACM device and is ready to use. With the main image installed the board will launch into it automatically. However pressing the reset button will force the device back into DFU mode ready for a firmware update.
Finally to finish up I would really like to thank all the folks who work on libopencm3. The USB code in usb-relay comes from libopencm3 and without it then usb-relay probably wouldn’t exist in its current form.
The recent release of patchfield for Android made me wonder whether Android’s audio system has developed sufficiently over the last three years to be suitable for real time signal processing. There have been a couple of developers at google working hard to reduce the output latency but their work does not yet encompass input latency.
However since patchfield allows the speaker to be digitally connected to the microphone it is easy to use patchfield itself to measure input to output latency of an Android system.
The following picture shows the test set up I used to measure it.
On the left is my 2012 Nexus 7. This is connected to the earphones sitting in top of the (red) sound card. Using earphones prevents feedback between the mic and speaker. Finally a microphone rests on top of the earphones. Critically the microphone picks up both the environment and the output of the earphones.
If you are particularly eagle eyed you might have notices a few missing cables in the above picture. Specifically the earphones are not actually plugged into the Nexus and the microphone is not plugged into the soundcard! I haven”t faked the photo however I only decided to blog about it after I had starting taking things apart again. In may haste to get a picture of it I forgot to plug it all back together.
Latency is measured simply by knocking in the table surface. This creates a short burst of noise that is captured both by the microphone in the picture and by the Nexus’ internal microphone. Patchfield captures the sound and replays it to the earphone which the microphone also picks up. The latency can then by calculated by looking at the waveform of the signals picked up by the microphone.
And the results are… 132ms from input to output. Just to put this number into perspective a piano, which is one of the highest latency musical instruments, takes about 25ms from the start of a keypress to the hammer striking a string. Another way to express it is that it is way too much for any musical application. The brain doesn’t just hear it as an echo… it hears it as a LOOONNNGG echo!
I repeated the same test on my Nexus 4 and that was better but not by enough to make much difference. That “only” took 124ms.
I guess there remains lots of very good reasons by iRig is not available for Android. There is one remaining ray of hope: the latest Samsung Mobile SDK includes a professional audio API based on jack and dedicated to handling low latency. It looks like Samsung really do want to take the fight to apple.
For some time now I’ve been playing with constructing my own digital modeller.
By and large I’ve deliberately kept the scope of the project to be a make a practice tool (rather than a studio effect) in order to try an keep things achievable. The ultimate aim is to make a device that you use like an amPlug (or iRig for iPhone) to practice with. More exactly it is a battery operated “thing” that allows you practice without any wires except those joining the guitar to your ears.
I’m working in phases of very limited scope so that I can lose interest in the project whilst still having achieved something and there’s still a long way to go before I can call it a modeller. Nevertheless since Christmas I’ve been able to move from playing with software in the PC to playing with something real.
The above is my recently acquired STM32F4-Discovery board running tintdrum, a fixed function groove machine designed to use like a metronome but with a stronger groove. The idea is that this type of drum machine is a vital component of a digital practice tool so tintamp will definitely have to have one when its finished. However it is actually useful enough to be a separate thing in its own right. Something I can put in a box and call “done”
The board above is running my own drum machine software. You can tell can’t you? Until last week all it was able to do was plug in and it started playing drums via the headphone socket at the bottom… it played a really basic 4/4, kick, snare, kick, snare beat (plus hi-hat)… at exactly 100 beats per minutes… and that’s it.
This week however I’ve been able to extend it to flash an LED on the beat (a vital feature in a practice tool) and also been able to rig up a tap tempo button. This means its starting to feel real. That said I still need to implement controls to change the groove and volume. I’d also like to extend the drum machine code to include humanization to stop is sounding quite so start.
Nevertheless the journey from PC to real hardware has begun. Bon voyage.
This post is an introduction to tintamp, the integer amplifier. The goal of the tintamp project is to build a free software guitar modeller for low resource computers such as digital music players or modern high performance microcontrollers. The focus on low resource devices defines much of the character of the project from its choice of implementation language to the relatively simplistic, and therefore CPU-friendly, DSP engine. These devices also mandate unusual features such as the no malloc() mode and the use of purely integer arithmetic operations (a.k.a. fixed point) from which the project gets its name.
To provide even more focus and to make it easier to ‘complete’ the project I have picked two platforms to be reference devices. These are the first devices I expect to port tintamp to. Both devices require a little hardware hacking as well as the tintamp software so there will be a substantial element of learning as I go.
Target 1 – Sansa Clip Zip
From a hardware perspective this is a simple mini-project to convert an off-the-shelf digital music player into a headphone practice amplifier. The digital music player in question is the Sanza Clip Zip made by Sandisk.
From the point of view of this project it has good many things going for it. In particular it has audio inputs that can be tapped into by de-soldering either the built in microphone or FM radio chip. It also has a colour display, a 250MHz ARM9 CPU and,crucially, a mature Rockbox port. The Rockbox port means I can concentrate on the signal processing code without having to work very hard getting the rest of the hardware to work. Even better, these devices are really cheap, so much so that I’m seriously contemplating buying a second one to keep and use for its original purpose.
The only problem with the device is the noise floor. The microphone is probably too noisy too use at all and even with the FM radio’s line in things are only 12dB better. Still, when finished this device will be a headphone practice amp so there’s little need for studio quality effects. It just has to be playable.
The most significant technical limitation of this platform is the absence of FPU making this device is the main motivation for (optionally) using fixed point arithmetic.
Target 2 – STM32F4-Discovery
This time around the mini project it to take a demo board based around a very powerful modern micro controller, combine it with a good quality codec chip and build a digital effects pedal.
The discovery board from STMicroelectronics brings most of the pins of ST’s STM32F4 controller and brings them out to header connectors. This includes the I2S (digital audio) in/out needed to interface it to a codec chip. Alternatively the board has built-in audio output together with a USB on-the-go controller that allows a USB audio device to be connected up.
The STM32F4 is based around a 168MHz ARM Cortex M4 which, although restricted to only the Thumb2 instruction set, does have a floating point unit. Here the big restriction is that being a micro controller there is only 192k of RAM. This will have to be very carefully managed. On the other hand what memory there is should be very fast compared to the CPU so no performance will be wasted with cache misses.
In the interests of full disclosure I should probably mention that I work for STMicroelectronics. However I don’t work in the microcontroller group and I didn’t pick the Discovery board because it was made by ST. I picked it because the board is fast, cheap and has I2S pins. Likewise, however much I ask my manager, I don’t get the board for free; I have to pay for it like anyone else. While disclaiming things I should also add that nothing in this blog comes from my employer. I’m not authorized to speak on their behalf and all opinions expressed here are purely my own.