Silhouette
This thing does not serve any particular purpose. It is just playing with the silhouette of my wive cut out of wood and a candle for illumination.
I call it “art”
Replacement knob for microwave
I somehow lost the knob for selecting the power of my microwave. It took several iterations but I finally made a new one. It is not winning any prices for beauty, but it works.
It is made out of two parts: The thing that acually plugs into the microwave and a round knob. That way I can replace them idependently when one breaks.
Microwave knob (back side)
Microwave knob (front side)
G-code from svg files
Again I spent some time searching for free tools to improve my cnc toolchain. I stumbled upon two simple but helpful flash programs for handling g-code files:
- Makercam (http://www.makercam.com/)
This tool loads svg files and generates g-code toolpaths from it. I can create programs for drilling, pockets, outlines and follow path operations. There are only two things to keep in mind when using it:- The svg file may only contain a single path. However this is not a big problem, because you can create such svg files easily using inkscape. Just combine all paths and then save it.
- Makercam assumes a resolution of 72 dpi when importing a svg file. Inkscape produces files, that have 90 dpi. To fix this open the preferences of Makercam and replace 72 by 90 dpi before loading any svg.
- G-code viewer (http://www.buildlog.net/gview/index.html)
This tool offers a quick way to inspect your g-code files before sending them to a cnc mill. Just drag the g-code file onto the browser window. All rendering is done locally without transferring your file to a server.
Measuring execution times in .NET
C#
var watch = Stopwatch.StartNew(); // the code that you want to measure comes here watch.Stop(); var elapsedMs = watch.ElapsedMilliseconds;
Taken from: http://stackoverflow.com/questions/14019510/calculate-the-execution-time-of-a-method
Getting started with Software Defined Radio (SDR), bladeRF, GnuRadio, Osmocom, GQRX
Strategy
Many tutorials already exist, that cover building bladeRF drivers, Gnuradio, Osmocom and GQRX from source. The main difference here is, that I will NOT install the built packages into my system directories or modify system files. Instead I will keep them separately in a folder in my home directory and use a startup script, that temporarily sets up the environment using the software. That way I can just delete the folder, reboot and I have a “clean” system again.
Why should I go this way? Well, I like to experiment a lot, sometimes I’m working on several projects in parallel. That also includes messing up stuff. The described strategy offers the easiest way to clean up and start over again without reinstalling the operating system.
Let’s get started
I’m starting off with a fresh Ubuntu 13.10 (beta) here. First we install several packages that set up the build environment.
sudo apt-get install git g++ cmake cmake-curses-gui libboost-all-dev libfftw3-dev libcppunit-dev python swig python-numpy doxygen python-cheetah python-gtk2-dev libgsl0-dev qt-sdk libqwt-dev python-qt4-dev python-qwt5-qt4 jackd qjackctl libsdl1.2-dev liblog4cpp5-dev phonon-backend-gstreamer phonon-backend-vlc libusb-1.0-0-dev libtecla1-dev python-wxgtk2.8 wx2.8-headers libjack-jackd2-dev
Let’s build stuff. Run these steps without superuser priviledges and change the pathnames according to your system. You will notice, that I use ccmake instead of cmake. This is a convenient tool to inspect and edit the available build settings. You could also go with cmake using the apropriate command parameters.
Building gnuradio
git clone http://git.gnuradio.org/git/gnuradio.git cd gnuradio mkdir build cd build/ ccmake ../
Edit CMAKE_INSTALL_PREFIX: /home/matthias/downloads/sdr/installed
make make install
Building bladeRF libraries
git clone https://github.com/Nuand/bladeRF.git cd bladeRF/host mkdir build cd build/ ccmake ../
Edit CMAKE_INSTALL_PREFIX: /home/matthias/downloads/sdr/installed
Set INSTALL_UDEV_RULES to OFF
make make install
There might be errors about not beeing able to install some rules to a system directory. Ignore this for now.
Build RTL-SDR
git clone git://git.osmocom.org/rtl-sdr.git cd rtl-sdr mkdir build cd build/ ccmake ../
Edit CMAKE_INSTALL_PREFIX: /home/matthias/downloads/sdr/installed
Edit Gnuradio_DIR: /home/matthias/downloads/sdr/installed/lib/cmake/gnuradio
make make install
Build OsmocomSDR GnuRadio block
git clone git://git.osmocom.org/gr-osmosdr cd gr-osmosdr mkdir build cd build/ ccmake ../
Edit CMAKE_INSTALL_PREFIX: /home/matthias/downloads/sdr/installed
make make install
Building gqrx
git clone https://github.com/csete/gqrx mkdir build cd build PKG_CONFIG_PATH=/home/matthias/downloads/sdr/installed/lib/pkgconfig/ qmake-qt4 PREFIX=/home/matthias/downloads/sdr/installed ../ LD_LIBRARY_PATH=/home/matthias/downloads/sdr/installed/lib make make install
Finally
Ok, we are done compiling. If you examined the commands, then you propably guessed how to run the programs. However it is painfull to enter these long commands each time when you start the programs, so we create some nice scripts to ease the pain.
G-code from CAD files
I spent several hours searching the internet for a CAM program, that can generate g-code from my CAD drawings. There is a lot of partially functional programs or some for very specific purposes, but nothing really pleasing. Finally I found HeeksCNC (http://code.google.com/p/heekscnc/downloads/list). It has some issues as well, but I like the general concept.The g-code is generated semi-automatic where the user has to define the shapes the machine should process.
If you import models from FreeCAD for example, then the workflow is:
- Import the model
- Move the imported model to the correct position in the coordinate system. The displayed xyz coordinate system is the origin of the CNC machine.
- Select a face of the imported model that defines the outline of a pocket (hole) or a contour of the object.
- Apply a pocket or outline CNC operation to each of the sketches you just created from the imported model.
- Generate the g-code
- Review the machine paths carefully. You have a lot of control on the total machining operations, but you also have to check for plausibility.
Plastic extruder
Note to myself: One day I will transform my CNC mill to a rapid prototyping machine that prints parts using plastic filament. There exist many different designs and ready to use extruders. The one I want to try is called “Multex” from www.multec.de
Milling PCBs
I built a CNC machine recently and one of the first things to do is of course to improve it. I used fritzing (http://fritzing.org/) to draw my circuit. When I was done I realized that I had no software at hand, that could make g-code from the exported gerber files. After some research I found:
- visolate (http://sourceforge.net/projects/visolate/) for milling the traces
- drill2gcode (http://fablabamersfoort.nl/drill2gcode/) for drilling the hole
I managed to produce a one layered pcb that now drives my CNC machine.
Parallella – a cheap and powerful many-core processor board
The company Adapteva designed a massive parallel processor called Epiphany. Some weeks ago they started a kickstarter campaign to start massproducing a cheap development board for only $99. I’m very excited about it and am looking forward to next year, when they will release the software development kit and sell the development board to the public.
http://parallella.org/
Reverse engineering the USB transfers of the Tascam US-1641 – Part 1
Prequel
I am doing audio recordings as one of my hobbies. Part of my equipment is the Tascam US-1641 external USB soundcard. When I set the device up for the first time, I was angry that the software, that came with it (some Cubase light edition) forced me to do a long and painful registration. Of course there is no linux driver (which I could have checked before I bougth the device) and besides audacity (which isn’t a digital audio workstation) and other expensive software I couldn’t find software for Windows I liked. So I finally registrated the software to be able to use my new soundcard.
I have been using linux only for a long time. Now I had to boot into a Windows installation only for doing recordings. The audio editing I always do with Audacity and Ardour anyways. So this was all in all a very invonvenient solution. I contacted the customer support and asked for linux drivers. Tascam only pointed me to some other devices with linux support. These weren’t official driver by Tascam, but instead some linux enthusiast wrote ALSA drivers for the devices he owned.
I looked into these drivers to find hints what to do with my US-1641. Sadly I couldn’t figure out how they work and I also failed to understand the concepts behind ALSA driver development. I finally gave up and decided to take a different approach.
I need the device for recording audio. I don’t want to listen to audio with it and I have no need for realtime and low latency. So I decided to directly grab the data from the device without using ALSA or JACK. This way I could concentrate on the USB communication and I could skip the time-critical complexity of the linux audio systems.
Step 1: Exploring USB communication
I read some theory about USB communication (http://www.beyondlogic.org/usbnutshell/usb1.shtml, http://en.wikipedia.org/wiki/Universal_Serial_Bus) and quickly stumbled upon the libusb project and its documentation (http://libusb.sourceforge.net/api-1.0/). The libusb is great and it is my choice for doing the low level USB communication. Of course I didn’t want to (and am not skilled enough to) reimplement the whole USB stack. The libusb makes sending and receiving data from a USB device very convenient. Now I “only” needed to figure out what to send and what to read. That is of course the trickiest part, because there is no specification publicly available which describes the communication protocol between the Tascam US-1641 device and the Windows driver.
Step 2: Probing the device
The USB protocol itself enforces, that a device provides basic descriptors about its capabilities. This data can be displayed using the linux tool “lsusb”.
Even without any driver a USB device registers to the system. It shows the vendor ID (0x0644) and the device ID (0x8017). These are used to identify the device later. Currently it is connected to Bus 2 and has the number 3, but these might change when the system reboots or if you plug it into another USB socket. But lsusb can do more. Run “lsusb —v”. You get a long list with details about every USB device connected to the system. Have a look at this textfile to see the whole output lsusb.txt
What I learned from this data
- It helped me to understand the whole concept behind the USB data transfer. The terms “configurations”, “interfaces”, “interface settings” and “endpoints” started to make sense to me.
- I found 1 configuration containing 2 interface descriptors. Each interface descriptor has 2 different settings, where only the second setting contains actual endpoints for data transfer. At this time I couldn’t figure out what that means. Later I found out, that when the device boots up, it starts using the first interface settings that don’t contain endpoints. Therefore no data is transmitted until the alternate settings are magically activated.
- Somewhere on the internet you can find specifications for “Standard USB Audio Devices”. These devices can be adressed by a generic usb audio driver. These devices have special values for “interface class”, “interface sub class” and “interface protocol”. My soundcard returns the values (255,0,0) for these descriptors. This basically means everything about the device protocol is marked as vendor specific. They didn’t follow USB audio standards or at least not totally. So I couldn’t expect that standard audio drivers would work.
- The descriptors told me what kind of data transfers the soundcard supports. I know from the specefication that it transfers audio to the pc with at least 16 mono channels, and 4 mono channels transmit (at least) to the soundcards. The soundcard also has midi in/out. The list of endpoints follows below but for now there is no hint which endpoints are used for audio transfers.
- Endpoint 1: Isochronous In
- Endpoint 2: Isochronous Out
- Endpoint 3: Bulk In
- Endpoint 4: Bulk Out
- Endpoint 6: Bulk In
Step 3: Spying on the original driver
So what next? I learned a lot, but still didn’t know how to use the soundcard. I suspected that it had to be initialized by some magic, but how to find out? First I used USBSnoop running on my Windows where I also had the original soundcard drivers. I wasn’t happy with the software so I installed VirtualBox on my linux machine. I installed Windows in a virtual machine, setup direct access on the USB port and installed the soundcard drivers. What is the difference to the previous approach? I could use Wireshark which not only understands networking protocols, but also USB. I started logging with wireshark, powered on my soundcard and watched the data flow to my virtual Windows machine. I noticed that the USB connection between Windows and the soundcard wasn’t very stable. I wasn’t able to really play sounds on the virtual machine, but nevertheless I got a lot of useful information.
First I had to filter out all USB messages that were not for my soundcard. I was surprised to see how much traffic there is even when I do not use any devices. The lsusb command shown above gave me the current device number (here it is 6) so I could filter for all messages for this device.
I inspected these messages and found that these messages contain the information that is also output by lsusb. So nothing exciting going on here. But then there was something special:
The parts marked as “1a” and “1b” show a control transfer going on. This transfer contains a version number “V1.00”. The same number was shown in the the Windows driver. This is nothing really useful, but it showed me that there was something going on that I could understand.
Section “2” activates the alternate settings of the interfaces. These inferface settings I already spotted in the lsusb data. Directly after activating these settings, wild isochronous transfers begin (“3”).
I switched the soundcard off and on several times and quickly assembled a list of control transfers that take place only when the device is initialized. After that data was transmitted to the soundcard using isochronous transfers. I also found a lot of big bulk transfers from the soundcard to the pc. I also noticed, that the data packets all looked very similar.
Based on my observations I decided to write a small programm that just replays all control transfers I found. Most of the transfers contained values I did not understand. Others were obvious (like the version number). The program continuously reads bulk data packets from the soundcard and sends packets containing only zeros. You can get the simplified source code here:
Don’t expect too much from this program. It doesn’t do anything useful yet. It plays silence and discards all data it reads from the soundcard. It shows you what I did to communicate with the device and you might use it as an example of how to use the libusb. I will extend this program to actually do something in another post.
Conclusion
My approach was successful. The dataflow started and inspecting it with Wireshark showed similar behaviour to the original driver. I successfully transmitted data to the soundcard and read data from the soundcard. I didn’t need to take care of any timing. Sending and receiving data as fast as possible works because the soundcard refuses to recieve data as long as the previous packet wasn’t processed. Receiving data from the soundcard only works when a complete data packet is available. Once it has been transmitted the soundcard refuses to send data until a complete new packet is assembled.
The biggest problem still was unsolved: I didn’t have any idea what data the packets contained. This is discussed in a different blog post.