Export to PDF

yrekazzyzxamuckInternet και Εφαρμογές Web

4 Δεκ 2013 (πριν από 4 χρόνια και 7 μήνες)

581 εμφανίσεις

This is the home page for Dobrica PavlinuÅ¡iÄ?'s random unstructured stuff.
Welcome to my new unsorted stuff site. If you are here to learn about rot13 this might not be the
right place.
If you are, however looking latest and/or unsorted snippets which didn't made to my homepage or
blog you might be on right place.
cell=0x9417550 [0,0]t=0x9417650
cell=0x9417708 [0,0]
Search for category: projects

Hauppauge Nova-T

Eee PC•
cell=0x9418cf8 [0,1]t=0x9418de8
cell=0x9418ea0 [0,0]
Search for category: howto
Huawei E220•
Hitchhikers Guide to RFID•
SocialText Open Wiki Install•
https using stunnel•
Cisco VPN•
Sysadmin testing•
ATI r500 driver•
Extracting part of subversion

cell=0x941bc60 [0,2]t=0x941bd50
cell=0x941be08 [0,0]
What's New

Altera FPGA•

Dobrica PavlinuÅ¡iÄ?'s Weblog / Blog
Touch screen configuration using xinput
When you are trying to configure touch screen on Linux machine, internet offers examples
Xorg.conf configuration but without explanation were numbers in it came from. If you have
different touch screen you might be out of luck or guess what to do. In this post, I will try to
explain how to examine your device using evtest and try out settings using xinput
without restarting X server or installing any drivers other than built-in evdev.

We have a couple of 3M MicroTouch M150 touch screens which are VGA monitors
(1024*768 resolution) with USB touchscreen interface which is reported as:
dpavlin@t42:~$ lsusb -d 0596:0001
Bus 002 Device 002: ID 0596:0001 MicroTouch Systems, Inc. Touchscreen
A bit of googling later, I found out that there are two different drivers for microtouch devices,
but both of them support serial devices only. Not giving up that easily I decided to see what
xinput reports about it (without any additional drivers installed!):
dpavlin@t42:~$ xinput list
â?¡ Virtual core pointer id=2 [master pointer (3)]
â?? â?³ Virtual core XTEST pointer id=4 [slave pointer (2)]
â?? â?³ 3M 3M USB Touchscreen - EX II id=9 [slave pointer (2)]
â?? â?³ SynPS/2 Synaptics TouchPad id=11 [slave pointer (2)]
â?? â?³ TPPS/2 IBM TrackPoint id=12 [slave pointer (2)]
â?£ Virtual core keyboard id=3 [master keyboard (2)]
â?³ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
â?³ Power Button id=6 [slave keyboard (3)]
â?³ Video Bus id=7 [slave keyboard (3)]
â?³ Sleep Button id=8 [slave keyboard (3)]
â?³ AT Translated Set 2 keyboard id=10 [slave keyboard (3)]
â?³ ThinkPad Extra Buttons id=13 [slave keyboard (3)]
This seems like a good news, but when I tried to use it, it seemed that cursor would move
only in middle of screen (with X axis swapped) so I wasn't very happy about it. Examining
properties of device in more detail revealed that it has property to swap axes and calibrate
them, but what to write into those values?
dpavlin@t42:~$ xinput list-props 9
Device '3M 3M USB Touchscreen - EX II':
Device Enabled (139): 1
Coordinate Transformation Matrix (141): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
Device Accel Profile (263): 0
Device Accel Constant Deceleration (264): 1.000000
Device Accel Adaptive Deceleration (265): 1.000000
Device Accel Velocity Scaling (266): 10.000000
Device Product ID (257): 1430, 1
Device Node (258): "/dev/input/event7"
Evdev Axis Inversion (267): 0, 0
Evdev Axis Calibration (268): <no items>
Evdev Axes Swap (269): 0
Axis Labels (270): "Abs X" (261), "Abs Y" (262)
Button Labels (271): "Button Unknown" (260), "Button Unknown" (260), "Button Unknown" (260), "Button Wheel Up" (145), "Button Wheel Down" (146)
Evdev Middle Button Emulation (272): 0
Evdev Middle Button Timeout (273): 50
Evdev Third Button Emulation (274): 0
Evdev Third Button Emulation Timeout (275): 1000
Evdev Third Button Emulation Button (276): 3
Evdev Third Button Emulation Threshold (277): 20
Evdev Wheel Emulation (278): 0
Evdev Wheel Emulation Axes (279): 0, 0, 4, 5
Evdev Wheel Emulation Inertia (280): 10
Evdev Wheel Emulation Timeout (281): 200
Evdev Wheel Emulation Button (282): 4
Evdev Drag Lock Buttons (283): 0
First task was was to flip x axes to make it move left-right instead of right-left. This can be
acomplised using following command:
dpavlin@t42:~$ xinput set-prop 9 267 1 0
Parameters are device id, property id, X axis swap and Y axis swap. If you don't know how
many parameters property takes, just put one, try it out and if it returns errors, keep adding
parameters until it suceeds.
Next, I needed to calibrate screen to track my finger moving over surface. This is where
evtest comes into play. It's low level utility which enables you to see input events before
they are passwd to Xorg server. You will have to run it as root as follows:
dpavlin@t42:~$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: AT Translated Set 2 keyboard
/dev/input/event1: Lid Switch
/dev/input/event2: Sleep Button
/dev/input/event3: Power Button
/dev/input/event4: ThinkPad Extra Buttons
/dev/input/event5: Video Bus
/dev/input/event6: PC Speaker
/dev/input/event7: 3M 3M USB Touchscreen - EX II
/dev/input/event8: SynPS/2 Synaptics TouchPad
/dev/input/event9: TPPS/2 IBM TrackPoint
Select the device event number [0-9]: 7
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x596 product 0x1 version 0x410
Input device name: "3M 3M USB Touchscreen - EX II"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 330 (BTN_TOUCH)
Event type 3 (EV_ABS)
Event code 0 (ABS_X)
Value 7353
Min 0
Max 16384
Event code 1 (ABS_Y)
Value 4717
Min 0
Max 16384
Testing ... (interrupt to exit)
Immidiatly we can see minimum and maximum values for both axes and putting figer on
top-left corner of screen produced (a lot of) output like this:
Event: time 1386078786.506710, -------------- SYN_REPORT ------------
Event: time 1386078786.510712, type 3 (EV_ABS), code 0 (ABS_X), value 13919
Event: time 1386078786.510712, type 3 (EV_ABS), code 1 (ABS_Y), value 2782
After a few touches I had coordinates which where something like this:
cell=0x942b6f0 [0,0]
cell=0x942b780 [0,1]cell=0x942b7c0 [0,2]
cell=0x942b890 [1,0]cell=0x942b8d0 [1,1]
cell=0x942b960 [1,2]
cell=0x942b9e0 [2,0]
cell=0x942ba70 [2,1]cell=0x942bab0 [2,2]
cell=(nil) [3,0]
Strangly it seems that origin is top-right corner, but we shouldn't care much about it beacuse
we can specify them using following command (after rounding them a bit):
dpavlin@t42:~$ xinput set-prop 9 268 2380 14000 2800 13500
Trying it out on screen proved that it now works as expected. Let's call this success and
remember that current Xorg knows a lot of tricks itself (recognising USB touch devices is
one of them).
As a side note you don't really need to use evtest to get device position. Using xinput
list id syntax displays you more-or-less same information, including last point which you
touched on device as seen below:
dpavlin@t42:~$ xinput list 9
3M 3M USB Touchscreen - EX II id=9 [slave pointer (2)]
Reporting 3 classes:
Class originated from: 9. Type: XIButtonClass
Buttons supported: 5
Button labels: "Button Unknown" "Button Unknown" "Button Unknown" "Button Wheel Up" "Button Wheel Down"
Button state:
Class originated from: 9. Type: XIValuatorClass
Detail for Valuator 0:
Label: Abs X
Range: 0.000000 - 16384.000000
Resolution: 0 units/m
Mode: absolute
Current value: 13889.000000
Class originated from: 9. Type: XIValuatorClass
Detail for Valuator 1:
Label: Abs Y
Range: 0.000000 - 16384.000000
Resolution: 0 units/m
Mode: absolute
Current value: 2832.000000
However evtest will run in loop until you stop it with Ctrl+C so I find it a little bit easier to
use than re-running xinput list id.
CUC 2013 - ZFS (on Linux) - use your disks in best possible ways
Last week I had workshop on CARNet User Conference on topic of ZFS on Linux. In it, I
tried to describe my experience with it, from zfs-fuse days up until today. There are quite a
few useful bits in this presentation, covering everything from history and basic ZFS concepts
up to smart hints and some downsides. I hope it was useful to people who attended it and
that you, dear reader, will find something useful in presentation which is embedded below.

433 MHz power sockets with rc-switch, Arduino or Raspberry Pi
One of simplest home automation projects is to control power sockets. Back in the old days,
this involved relays and parallel port, but nowadays you can buy ready made power sockets
with remote control which work on 433 MHz IMS band. So next logical step is to replace

remote control with computer controlled 433 MHz module. In this post, I will explain how to
do it using Arduino or Raspberry Pi.
Power sockets with 433 MHz remote control
For this project I decided to try out two different types of power sockets available at our local
hardware shop.
As you can see they are quite different, but any of then will work fine. On the other hand, big
bulky square ones have much more useful indicator on then which lights up then they are
enabled, while smaller round ones have light which just denotes that they are plugged into
electricity but doesn't show status of relay inside of them.
433 MHz modules
If you want to communicate with these devices you will need some kind of radio modems.
For this project, I decided to use cheap 433 MHz radio modules which come in pair: one of
them is sender while another is receiver. On picture you can see modules with attached
I can't stress enough need for antenna. Although modules will work without it, they will have
a really poor range of just few centimeters. Antenna should be 172 mm (1/4 of wavelength),
and according to my friend who knows something about this things, it's equally bad to have
longer or shorter antenna than that. I added 3 mm more for solder joint and it did improve
reception and sending range dramatically. You can use any wire for antenna, in my case, I
used wire used for wrapping power cords which was long enough to make two antennas.
As a first step, I decided to hook them to Arduino Uno to see some waveforms and test
rc-switch library. Sure enough it worked on first try. I added project to my
~/Arduino/libraries/RCSwitch directory and used ReceiveDemo_Advanced
example to capture signals. Another example, SendDemo enabled me to send signals back
to power sockets and turn them on or off. Success on the first try.
With a little bit of tweaking I created RF433_Sockets.ino which allows receiving signals,
turning sockets on or off or sending raw binary data to test protocols.
As you can see on picture, I also connected cheap logic analyzer clone to see signals and
Bus pirate to monitor signal levels using Bus Pirate oscilloscope python script to make sure
that I can connect it to 3.3V level device in next step and I got signals like this on receive pin:
Raspberry Pi
Having verified that signal receiver is generating 3.3V signals (up to 3.6V is OK and mine is
3.46V - electronics isn't exact it seems :-), I decided to hook it up to Raspberry Pi so I will
have Internet connected control over my power sockets.
Following link on rc-switch site to port for Raspberry Pi didn't end up all that well. This
version of code doesn't support receiving of data, and sending code generates segfaults.
However, after a little bit of searching I found blog post about Adding 433 to your Raspberry
Pi from NinjaBlocks which inclues link to github repository with code which works fine.
Both versions of code use WiringPi library which is nice way to port Arduino code to
Raspberry Pi. When sending signals to 5V devices 3.3V Raspberry Pi GPIO will be usually
fine, but when receiving singals, make sure that they are 3.3V or you will fry your Raspberry
Less than $10 and few hours of work...
Having said all that, it's really easy to create your own home automation system. So I don't
see a reason not to do so...
Parts list: (assuming you already have Arduino or Raspberry Pi)
2 sets 433Mhz RF transmitter and receiver kit for Arduino US $2.77♦
40PCS Dupont Wire Color Jumper Cabl 2.54mm 1P-1P Male to Female 20cm US
$2.57 (for Arduino)

40PCS Dupont wire 20cm cable Line color 1p-1p pin connector US $2.68 (for
Raspberry Pi)

fsec 2013 - GoodFET ported to Arduino UNO•
It's again this time of year when security
researchers (and me) gather in Varaždin for fsec, vendor-neutral technical security
symposium, hosted by Faculty of Organization and Informatics. This year, I deiced to re-visit
my question about security wireless keyboards, so I ported Travis Goodspeed's GoodFET to
Arduino UNO. Goal was to use cheap nRF24L01 modules from ebay to see if my Chicony
KG-0609 keyboard is sniffable. And it is...
You can find the presentation in which I also tried to cover my experience with hardware
hacking below.
I hope it was interesting to people who attended it, although I suspect that I crammed too
much content into 30 minute slot which I had. If you are interested in my changes, they are
available in Arduino_Uno branch in goodfet project at git.rot13.org.
This event has special place in my calender since I'm alumni and it's always nice to meet
again friends and professors and visit again place where I started my Unix administration
back in 1995. Thanks to everybody for nice three days in beautiful Varaždin.
Debian with btrfs on Igel for home gateway
A few weeks ago my WRT54GL decided to die. This was quite fortunate because I wanted
to upgrade my always on machine to something more powerful and install Debian on it. I had
ADSL modem with wifi, so I didn't need wifi in my new box. Fortunately, I got a Igel 3/4 thin
client with VIA Eden chipset, 256Mb of RAM and 128 Mb of CF storage so I decided to move
by main gateway functions to it.
I had following requirements:
pppoe to connect to by ISP♦
dnsmasq to provide DHCP for my LAN♦
iptables will provide NAT♦
openvpn and n2n to provide VPN♦
motion so I can see what my dog is doing when I'm not home♦

As a first installation I started with Thinkpad T22 (since Igel was still on the way). All went
quite well (after figuring out that I can't boot T22 from USB) but it took 2GB of disk space.
That won't fit on 128MB CF card, so I acquired 2GB CF card. Still, even with it, the storage
will be tight, so I decided to use btrfs with compression. And this is where the real story
As a first step, I plugged 2GB CF card into USB adapter on my desktop (Igel can't boot from
USB), created btrfs filesystem and mounted it using compress=zlib,ssd. After coping
files over size of installation dropped from 1.9GB to just 840MB. This card will be adequate
choice for my gateway. I was also toying with idea of moving my apt-cache-ng to this
machine, so I wanted more space, and decided to also plug additional 8GB USB keychain
for swap and cache storage. But, since I have two devices wouldn't it be better to create
btrfs raid1 on it so I can survive failure of CF or USB (ignoring cache and swap)?
Next I plugged CF and USB into Igel and booted it. First boot was slow, but what can you
expect from 600 MHz VIA Eden? Here is hdparm speed of CF (sda) and USB (sdb):
root@igel:~# hdparm -tT /dev/sd{a,b}
Timing cached reads: 310 MB in 2.02 seconds = 153.76 MB/sec
Timing buffered disk reads: 38 MB in 3.11 seconds = 12.22 MB/sec
Timing cached reads: 302 MB in 2.00 seconds = 150.92 MB/sec
Timing buffered disk reads: 56 MB in 3.07 seconds = 18.26 MB/sec
It's interesting that USB is faster than CF. So, let's try to move my single drive btrfs
filesystem to RAID1 configuration using:
btrfs device add /dev/sdb1 /
btrfs balance start -dconvert=raid1 -mconvert=raid1 /
This is where the problems started. I was running Debian wheezy with 3.2 kernel and
rebalance filters are introduced in kernel 3.3. So I upgraded to sid with 3.10 kernel to see
weather it will fix at least some btrfs issues. As we will see it really didn't. I got reports about
corrupt blocks and after a while I decided to unplug CF and USB, move then over to desktop
and create mirror filesystem there.
This worked (and didn't report any errors after scrubing) so I was somewhat confident that
my data is safe. This time around, I decided to use
noatime,compress=lzo,ssd_spread mount options to gain some speed. Filesystem
did grow to 1.2GB (50% increase since I was using lzo instead of zlib for compression) but it
was still acceptable. Next, I returned storage to Igel and tried to boot it. Another surprise: it
couldn't mount root file system. When I got initrd shell, I could indeed see that I don't have
/dev/disk/by-uuid/ nodes for root mostly because it wasn't mounted. However, manual
mount from /dev/sda1 didn't work either. However, manual mount from /dev/sdb1 did
work. After searching a web for reason it seems that Debian's initrd doesn't issue btrfs
device scan on boot so multi-device btrfs filesystems don't get correctly recognized. Why
does it work from second disk in mirror is still a mystery to me. I enabled
GRUB_DISABLE_LINUX_UUID=true in /etc/default/grub and moved on...
However, my problems weren't over just yet. After running update-grub on booted
filesystem Igel was again unbootable. It was reporting strange errors in part because
grub-probe got both devices:
root@igel:~# grub-probe --target=device /
This was easy to fix. I modified /usr/sbin/grub-mkconfig to report just /dev/sdb1 so
it will be bootable:
GRUB_DEVICE="`${grub_probe} --target=device / | tail -1`"
The story would end here if I didn't try again to run btrfs balance start /. This time
around, it didn't report any corrupt blocks, but it did oops kernel with out of memory
backtrace. Lesson learned, 256MB RAM is too small for 2GB btrfs filesystem balance. Live
and learn. Problem now was that balance restarted when I booted system. So as solution, I
unplugged USB which dropped me into initrd shell where I could issue btrfs balance
pause / followed by btrfs balance cancel / (cancel alone wouldn't do the trick).
So, what can I conclude about current state of btrfs? It does work (with some hand-holding)
but it also has rough edges. But, if you really have flash based storage and need
compression it is a valid choice.
Monitoring room temperature using Arduino
For a last few months, I have been playing around with Arduino and collecting useful parts
for my first real project. Last week we purchased Mitsubishi air condition with super-invertor
and I wasn't totally happy with the way it operated so I took several afternoons and tried to
understand how temperature in my room was varying depending on it's settings. To do that, I
built simple temperature monitor using Arduino Nano, two temperature sensors and Nokia
5110 screen. This post tries to document my journey...
Arduino Nano bootloader flashing
When I started buying Arduino parts, I decided I'm cheap bastard and bought Arduino Nano
without boot loader flashed, so as first step, I had crash course into ISP programming. As
you can see on picture, my board doesn't even have ISP header soldered on it (although it
came with one) which might explain why it wasn't pre-flashed. Fortunately, I do have Bus
Pirate v3b clone from Sand Box Electronics (essential tool for any micro-controller work in
my option) which can also work as ISP programmer for Arduino. On first try, I flashed wrong
boot loader (holding ISP header with my finger since it wasn't soldered and using Bus Pirate
cables), but I soon learned that Arduino software has helpful boards.txt file from which
you can lookup correct boot loader using something like:
dpavlin@blue:~$ grep nano328 /usr/share/arduino/hardware/arduino/boards.txt | grep bootloader.file

So, I learned that chap Chinese Arduino clones will give you opportunity to learn something
new. I could have used another Arduino for that also, but at the time I didn't have any.
Lesson learned, always buy two of each components in hope that one of them will work.
Temperature sensors, display and parts
Having Arduino alone isn't really useful, so I decided to try different on-line shops and collect
various parts needed for this project:
Solderless Breadboard with 400 Tie-Point♦
Breadboard Jumper Wires♦
Breadboard Jumper Wire Set♦
DHT11 1-Wire Single Pin Thermometer/Hygrometer Module♦
DS18B20 Programmable Resolution 1-Wire Digital Thermometer♦
Arduino Compatible 1.6" Nokia 5110 LCD Module with Blue Backlit♦
You might be wondering why I have two sets of jumper wires. As you can see on picture, I
used both of them, since it's much easier and neater to route power and ground around
breadboard using pre-made wires which come in various different sizes and sit nicely on top
of breadboard and connect everything else using longer jumper wires with plastic handles.
I also have two temperature sensors. I started with DHT11 (mounted on small board with
useless red power led - I wouldn't recommend that for next project) which is nice and
provides temperature and humidity reading, but I don't get any decimal places in it's output.
It's left temperature reading on display. Than I remembered that I have couple of DS18B20
sitting in drawer so I added a 4.7K resistor and hooked it up. This is where things become
much more interesting - it's much more accurate that DHT11 so I decided to use that value
to draw graph (and display right temperature reading with two decimal places). I also noticed
that temperature readings differ by 1 degree or so between sensors.
And a little bit of software
One of main reasons why I'm excited about Arduino is it's software support. While it's a
shame that there isn't anything like central repository of software libraries (no, wiki pages at
Arduino site doesn't count as one) it's really nice that you can find libraries for everything you
might need. This does introduce another problem: now to track all those libraries and your
I decided to use git and track everything in my ~/Arduino directory. Initially I was hoping
that every library will have upstream git repository so I could use git modules to track them,
but some of them don't so I just add them to my repo. This works quite well (if I remember to
save sketch before trying to commit it). I started with DHT11 library example and continue
adding other parts of code to it. Then I added Arduino Library for Dallas Temperature ICs
which in turn uses OneWire to support DS18B20 which doesn't really speak normal i2c
protocol. With that working (and reporting temperature back through serial port) it seemed
like some kind of local display is in order. So I took Nokia 5110 display I had handy (which I
really prefer to other solutions - it's cheap and can display graphic) and took Adafruit driver
for PC8544 which in turn again needed Adafruit GFX graphics core library. It seems like
mess by now, but it's quite workable and easy to hook together. Only thing that I had to take
care is that name of directory within ~/Arduino/libraries should be same as library
name itself, which isn't same as name of upstream repository. Oh, well...
This is where (some) form of real development kicked in. I decided to make small circular
buffer for DS18B20 readings and draw that as scrolling graph, RRD style. As last step I also
added PWM driven back-light to display which is off if value didn't change, half-dimmed if
current temperature is lower than previous one or full brightness if it's higher (warning,
warning: melting in progress :-) If can take a look at source of DHT11 DS18B20 temperature
monitor sketch in all it's 5k glory if you wish. I will probably add average of last three
readings for back-light brightness and reduce serial output to format which is better usable
for real RRD graphs, but so far this has been useful and fun project. I also understand my air
condition operation a little better now :-)
Finally, I used Fritzing to capture schematic output of this project so I don't have to write
down pin mappings somewhere. It's somewhat unstable, especially if you try to edit custom
parts (I replaced red LCD breakout board with the one which I have) but overall it's a great
way to produce structured info about your breadboard view. Having ability to copy/paste
elements from other drawing (DHT11 in this case) saved me from defining another custom
For some reason, I'm not getting correct schematic view for DS18B20. I might have defined
something wrong for it or I just don't know how to correctly use Fritzing yet.
Is Arduino API new standard for embedded development?
For last few months i have been playing around with Arduino. I came to conclusion that this
platform is probably only one which I can recommend and develop for. Let me try to explain
how I arrived to that conclusion...
It's easy to use for novices
This is especially important for me, since I'm mostly software kind of person. I don't solder
and probably never will. But using just a few wires and so many good tutorials on the web
together with availability of sub-$10 sensors and peripherals on Chinese sites or ebay it
seems that we are currently in situation where anyone can get into hardware. And everyone
should, at least to know what is possible. Arduino was design with teaching in mind in the
first place.

There are lot of good examples
This basically boils down to: It's googlable. I'm aware this is not real verb, but what I mean
by it is: there are enough info about every single peace of hardware you might buy if you just
enter it's designation and arduino in google. That's a huge benefit and only other embedded
platform which comes close to it is probably Raspberry Pi.
There is support for different architectures
This is probably point which is not obvious at first, but makes me most excited about
Arduino. Let me try to list just some of them (this is somewhat random selection, not
exhaustive comparison of characteristics of all the Arduino boards):
Arduino Uno - ATmega328, probably best one to get started♦
Arduino Mega - ATmega2560, as the name implies, it's probably second board you
will buy when Uno becomes too small for your project

Arduino Due - Atmel SAM3X8E ARM Cortex-M3 CPU, first official Arduino board
which isn't AVR. This makes my point about different architectures clear, but read

Pinguino - PIC18 8-bit or PIC32 32-bit CPUs, so if you dislike AVR you don't have to
use it :-)

The Maple - STM32F103RB 72MHz ARM Cortex M3, exists longer than Due and
included here to show that Arduino wasn't driver for multi-platform CPU support

Energia - MSP430 16MHz board for under $10♦
pcDuino - A10 1GHz ARM Cortex A8, this is full-fledged Linux machine with Arduino
IDE support (it can also run Android, but we are not interested in that).

Papilio FPGA - Spartan 3 or Spartan 6 FPGA boards with support for Arduino IDE. If
your design does signal processing, this is right path forward with your code, but you
will have to learn VHDL and/or Verilog also! It supports two different CPUs
implemented in FPGA: AVR8 - Clone of the AtMega103 chip with standard AVR
peripherals and ZPUino - Arduino on steroids: 100Mhz, 32-bit, 96Mhz, up to 8MB
code space.

While some of this boards are also compatible with Arduino shields, there are also others
which don't use Arduino IDE, but can use Arduino shields. I don't care much about shields
because I like my wires to be all over the place :-)
Open hardware respects your freedoms
Having all this CPUs and boards available (and in open hardware fashion which means with
full documentation) makes me confident that I'm not wasting my time implementing
something today. You will have to read schematics and examine data-sheets anyway, so
having all documentation (and files required to produce your own boards) is very beneficial.
DORS/CLUC 2013 conference•
Last week we had another annual
conference about Free Software and Open Source DORS/CLUC 2013. For a last year, I was
playing with various hardware, so this year, I was part of Internet of things panel (talking
about ARM based machines), and I had lecture about GNU/Linux on ARM devices for
I also submitted hardware workshop for program which got accepted, so I quickly realized
that I'm really no hardware expert and that I could use some help to make interesting
workshop. Fortunately I have a few good friends who know more about hardware that I ever
will, so I summoned Lovro and Dalibor to help me cover hardware and antenna design. Few
weeks ago I was at NSND Belgrade 2013 where I had good fortune to meet Filip who is
working for Dangerous Prototypes. I couldn't really believe my good luck since I wanted to
talk about Bus Pirate a great multi-purpose tool which got me into hardware in the first place.
So, in the end, I had three very skillful people to back me up in this workshop which was
hopefully useful and interesting to people attending it. For future reference, I will include a
few links below about topics we convered:
Filip started with Bus Pirate including it's supported protocols I2C, SPI, 1-wire, UART,
JTAG (and others) and example of using it to communicate with I2C EEPROM

Dalibor make great presentation about antenna design, including practical examples
for ADS-B and 443.92 antenna (simple one from coax cable and one with RF filter for
PiHAT) while I tried to explain why RTL-SDR DVB-T sticks made it possible to listen
to various your IMS sensors using rtl_443.

Next, Filip again took stage to speak about Open Hardware and possibilities to
manufacture and sell such devices based on expirience of Dangerous Prototypes
cooperation with Seeed Studio.

In last part of our workshop we played with blinkm, took questions and discussed
other Dangerous Prototypes projects which we had with us which included USB
Infrared Toy, Bus Blaster and Open Bench Logic Sniffer but we also talked and
showed Arduino and Mojo FPGA board which we had us also to ZPUino which is
interesting combination of Papilio FPGA and Arduino IDE. Lovro did a nice overview
of FPGAs and how are they different from software programming.

As you can see from notes above, workshop was a mix of different projects but hopefully it
managed to convey my excitement about current moment in time where you can hack
hardware even without taking soldering iron (and burning your fingers). If you do take
soldering iron, please make your project Open Source Hardware...
USB IR Toy - PIC 18F2550 fw_update under Linux
I'm in the process of setting up my HTPC, so I ordered USB IR Toy to be able to turn TV on
without using remote control.

When I got it, I was unable to make it work. Fortunately, there is V command which returns
current version of firmware, and on my device it was V212 which means Hardware V2 and
firmware V12. Since latest firmware is V22, I decided to upgrade firmware. In the process I
bricked it (using wrong fw_update program which doesn't flash whole device, but just first 2K
of application). Fortunately, this PIC has Diolan bootloader which is accessible using jumper
(small blue peace of wire on picture) even if you flashed just part of application on it (as I
Result it fw_update for PIC 18F2550 which IR Toy uses , updated wiki page about IR Toy
firmware update on Linux and comment on bug tracker. Hopefully, this will help someone
else instead of learning all this stuff, which was fun in itself :-)
Next step was to try SUMP logic analyzer mode which can produce nice graph of IR
communication. I used Debian sump-logicanalyzer package to produce following
Now that I was sure that it works and can communicate with my LG TV remote, I decided to
give one of sample programs, IRToyRecPlay a try. It doesn't come with Makefile, so I
compiled it using:
gcc *.c -o IRToy
Unfortunatly, it doesn't seem to work for me (can you see pattern here?). So, I decided to try
fork of IRToyRecPlay on github which works better under Linux (after PIC fw_update
problems I didn't really spent any time investigating why - I suspect that upstream
Dangerous Prototypes source works well under Windows).
First, I recorded power button from remote using
./IRToy -d /dev/ttyACM0 -f lgtv -r
This created lgtv_000.bin file which I could reply to get TV turn on:
./IRToy -d /dev/ttyACM0 -f lgtv -p
I noticed that I can't just reply same sequence again to turn TV off, so more works needs to
be done... But that's only software problem, so I did my first clash with PIC hardware
somewhat well :-)
Update: I had problem with play of IR codes which would die after few tries. It seems that
firmware V2x doesn't support USB suspend correctly, so easiest solution is to use
powertop to turn off auto-suspend for whole usb bus (including host controller!) on which IR
Toy is connected. This will change a bunch of values in grep .
/sys/bus/usb/devices/*/power/control from auto to on. But you will have to
re-plug you IR Toy after that so better solution is echo "options usbcore
autosuspend=-1" > /etc/modprobe.d/irtoy.conf and this will turn autosuspend
for all usb devices.
NSND 2013 Osijek : RTL-SDR software defined radio
For a long time, doing anything with various devices which use radio waves proved to be
almost impossible for software geeks like me. Fortunately with RTL DVB-T sticks all this is
about to change, and at our last meeting NiÅ¡ta se neÄ?e dogoditi in Osijek I tried to show
some of possibilities using them.
For a start you need compatible Realtek RTL2832U DVB-T tuner. Just go over to rtl-sdr
osmocomSDR and examine supported tuner list. Choice of DVB-T sticks in Croatia isn't so
good. They are about 170 kn and come with FC001[23] tuners: Hama 53176 has FC0013
tuner and TV LV5TDLX has FC0012 tuner. I did some research and ordered this $13 DVB-T
from dealextreme which has R820T tuner:
dpavlin@blue:~$ sudo rtl_test -t
Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Rafael Micro R820T tuner
It's a good choice, shipping is free (but takes few weeks), and it works well with ADS-B
which was first interesting application which I wanted to try.
I also ordered E4000+2832U USB DVB-T TV Receiver Stick for $16.50 but it hasn't arrived
yet so I don't have any experience with it.
I also have a good fortune that my friend is very skillful in radio communications, so he
created variant of Coaxial Collinear Antenna for ADS-B Receiver. This one is more sensitive
to static electricity which means it's not suitable for top of skyscraper scenarios, but in works
very nicely. Under construction is filter which would cut everything expect interesting part of
RF spectrum which would also solve problem of static electricity.

On the picture, you can see part of it together with output in browser created using
dump1090. It's important to note that normal DVB-T antena without any modification will
work with R820T tuner since it's most sensitive so far, but range will be much smaller.
We also had good luck with getting data about keypresses from power-socket controlling
device using rtl_433 from github with just a peace of wire as antenna for short range tests.
libvirt vnc console without virt-manager
We have all been in this situation. We need quick access to hardware console of machine to
debug nasty hang (kernel oops in my example). But now-days, we are all in the cloud, and
that machine is libvirt's kvm. I just need access to VNC console, and installing whole
virt-manager seems like overkill. So, let's see if we can make it somewhat easier and
First ssh into your host machine (garak in this example, tunneling some VNC ports along
the way:
dpavlin@x200:~$ ssh $(seq 5900 5904 | awk '{ print "-L "$1":localhost:"$1 }') garak
If you have more than 4 vms running on this machine, increase 5904 above.
Then, using virtsh list all domains, and examine vnc port:
virsh # list
Id Name State
1 stargate running
2 treca running
15 hroug running
16 close running
virsh # vncdisplay close
Now, back on laptop, in another terminal start vnc viewer:
dpavlin@x200:~$ vncviewer :2
Since close didn't respond to reboot, reset or shutdown commands in virsh, I opted to
kill kvm process and start it again with start close. Quick alternative to virt-manager

Is wireless keyboard safe for your passwords?•
I recently got big screen TV (big for my living
room at least). It came with few HDMI ports and VGA, so next logical step was to connect
computer to it. And of course, then I noticed that it would be really handy to have wireless
keyboard and mouse to complete this nice setup. However, I also wanted to ssh over that
networks, so I started examining how secure wireless keyboards are. tl;dr; summary: they
are not secure.
First I asked for suggestions which wireless keyboard to buy. I have quite big fingers, so mini
models just doesn't do it for me. I got suggestion to take a look at Logitech K400 and sure
enough it seemed like good choice. One of first things that I noticed is that it supports 128-bit
AES encryption. I started to have a good feeling about it, but I wanted to know more, so I
hoped to Logitech Advanced 2.4 GHz Technology pdf and discovered that not all keys are
encrypted.To quote documentation:
The encryption applies to all standard keyboard keys (a, s, d, f...) and
modifiers (Shift, Ctrl, Alt...). The multimedia keys (Play, Pause, Mute...) that
may be implemented in some keyboards are transmitted in clear text.
How can I trust keyboard which doesn't encrypt all traffic? This got me thinking. Can I
somehow verify that keys are encrypted? Is this wide-spread problem? Can I make mistake
and broadcast my keystrokes to whole world?
Sure I can. For older 27Mhz keyboards there is KeyKeriki v1.0 - 27MHz project which
implement sniffer for it (video DeepSec 2009: Keykeriki: Universal Wireless Keyboard
Sniffing For The Masses). But, Logitech is 2.4Ghz, so it's secure, right? Well, there is
KeyKeriki v2.0 - 2.4GHz which does same for 2.4Ghz (video Keykeriki V2 - Practical
Exploitation of Modern Wireless Devices [SIGINT10]). OK, Logitech does some kind of AES
on top of that, but since it does transfer some keys unencrypted, and it's proprietary
technology I can't really check that.
I also got suggestion to use bluetooth keyboard because it's secure. Well, quick search
revealed Ubertooth One which basically defeats bluetooth protection with a bit of sniffing and
a little brute force.
By this point, I was puzzled. Is there secure wireless keyboard with touchpad which I can
buy? Something I can be sure that it encrypts all traffic as opposed to only some keys? Or is
usb extension cable only real solution for me?
Printrbot experience - 3D printers are not for everyone
Allmost a year ago, me and three other friends decided it's a very good idea to support
Printrbot kickstarter project and get our-selfs 3D printer. We didn't have any particular use
for it (other than printing Raspberry Pi case when it arrives) but it seemed like the right thing
to do. This post will try to explain how far did we manage to get with it and why we where
If you examine original Kickstarter page you will see following description:

A desktop 3D printer you can build in a couple hours. Print plastic parts you
design or download - even parts for another printer.
Our experience can't be further from that statement. For a start, Brook Drumm (to whom I'm
ethereally grateful for his efforts to make 3D printers commonplace) got his campaign
funded with 1,808 backers who spent $830,827 instead of just $25,000 goal he envisioned.
This was both good and bad. Good part was that after funding we knew that we will have 3D
printer (I'm carefully not mentioning printing anything), but the bad part was logistics: there
was simply no way he would be able to print 1808 versions of original design on 3D printers
themselves (idea of RapRap-like printers, which Printrbot was one iteration, was always to
make them self-replicating). So, he decided to change design and move toward wooden
laster-cut parts for most of construction, and print just parts which where necessary.
This also introduced significant delay in printer shipment, but when you are funding
Kickstarter project, you should be prepared for it, so I'm not complaining. When it finally
arrived this summer (10 months after end of Kickstarter campaign), it was significantly bigger
than I expected:
To be honest, we did upgrade to bigger Printrbot PLUS so I guess we should expect a lot of
parts. As we are mostly software geeks, we did only reasonable thing to do: check if all parts
are present comparing it with bill of materials which we got printed out.
This is the point where our problems started. We had missing one bag of parts which
included termistor and switches. We contacted Printrbot HQ and they sent us missing parts.
We started assembling following Printrbot Building Instructions by Brook Drumm and it took
us more than 50 hours to get to our first blob.
Of course, it didn't work perfectly on first run. We where trying to print 5mm Calibration Cube
Steps is ABS plastic which we received with our Printrbot (we even got additional 450g of
ABS plastic as replacement for power supply which wasn't part of international shipments).
Actually, it still doesn't work well as you can
see in video below, but we are hopeful. In the meantime we figure out that best source of
information is Printrbot Talk forum and wiki. Forum is somewhat depressive since most
users have some kind of problems with their built, just as we do.
To be honest, we didn't expect smooth ride. However, as I mentioned before we are not
really hardware hackers, and my only conclusion is that home-made 3D printers are really
for people who already have enough experience to make their own 3D printer, and not for
software guys like us. However, we won't give up, and I fully expect to have working printer
(after we get replacement barrings from Printrbot HQ because our are sticky). We are
collecting useful add-on models and instructions on our Printrbot wiki page but I didn't expect
that we will have to contact Printrbot HQ twice for missing and replacement parts. But
eventually we will be able to print Raspberry Pi box, I hope :-)
mdadm - how to tune your md software RAID
We had software RAID in form of md devices on Linux for a long time. Here are few useful
hints how to make it work better...
Scrub your array to check data consistency
I will assume that you are already monitoring your disks using smart, but from time to time
it's useful to force full re-scan of your array to make sure that all data is still there and
consistent. Some filesystems provide this option to scrub data on it's own (zfs and btrfs
comes to mind) but if your filesystem is located on md array you can always force it using
echo check > /sys/block/md0/md/sync_action
I would suggest to do this from cron, hopefully during weekend or some other time when
your load is lower.
Adding write-intent bitmap to speed up recovery
If you installed your md array a long time ago, you probably didn't turn on write-intent bitmap.
It's very useful when you have to recover because bitmap will track changes and this will
prevent long re-sync times when disks have to read and compare every block. To turn it on
mdadm --grow --bitmap=internal /dev/md0

Mirror between two devices of same speed
Recently, one of my 500Gb disks in RAID1 (mirror) failed. I decided to replace it with 1Gb
drive which was unfortunately green drive (which basically means slow). Adding two drives
of different speed in mirror will reduce performance to single slower drive which is a shame.
Since I wasn't able to add additional disk and wasn't prepared to give up redundancy of data
I started searching around and found that I can specify one disk as write-mostly using:
mdadm --add /dev/md0 --write-mostly /dev/sdb1
Same trick will work on combination of hard drive and SSD, but in that case, you will slow
down writes to speed of your hard drive.
X11 running on Nook Color without Android stack
I have been toying around with idea of
having real Linux stack (X11 and friends) on Nook Color. While this seems like a silly thing
to do, it does allow me to use x2x and transfer keyboard and mouse from my laptop to tablet
which is handy. If also allows me to run X11 applications on tablet screen using
DISPLAY=nook.lan:0. I was fortunate enough to find blog post how to run Linux
framebuffer X server on Android but I wanted to use touchscreen so I decided to write my
own xorg.conf (this brings back memories...).
To get full-blown Debian-based distribution on your Android take a look at BotBrew Basil. It's
Emdebian based distribution which will setup mount points and various other stuff so you
don't have to do that manually. Since it's Debian based, you are not limited to Emdebian
packages -- you can (and will have to) add normal sid:
(BotBrew)root@localhost:/# cat /etc/apt/sources.list.d/sid.list
deb [arch=armel] http://ftp.debian.org/debian sid main contrib non-free
If you want to know more about Emdebian hop over to DebConf 12: Integrating Emdebian
into Debian [video].

With all this prepared, we are ready to shut down Android stack:
adb shell setprop ctl.stop media
adb shell setprop ctl.stop zygote
adb shell setprop ctl.stop surfaceflinger
adb shell setprop ctl.stop drm
Next step is installation of required packages:
dpavlin@t61p:~$ adb shell
root@android:/ # TERM=xterm chroot /data/botbrew-basil/ /bin/bash --login
(BotBrew)root@localhost:/# apt-get install xserver-xorg-video-fbdev xserver-xorg-input-evdev \
xserver-xorg-input-multitouch x11-xserver-utils xinit \
matchbox matchbox-keyboard xterm
I decided to use matchbox, mostly becuase it's only window manager which comes with
on-screen keyboard which is useful on touch screen device.
After installation you will need to setup X symlink and create .xinitrc:
root@android:/ # ln -s /usr/bin/Xorg /usr/bin/X
root@android:/ # cat ~/.xinitrc
( sleep 1 ; matchbox-keyboard -o portrait ) &
Finally, you need to create xorg.conf:
Section "ServerLayout"
Identifier "Layout0"
Screen "Screen0"
InputDevice "cyttsp-i2c" "CorePointer"
InputDevice "gpio-keys" "CoreKeyboard"
InputDevice "twl4030-keypad" "CoreKeyboard"
Section "InputDevice"
Identifier "gpio-keys"
Driver "evdev"
Option "Device" "/dev/input/event0"
# code 102 (KEY_HOME)
# code 116 (KEY_POWER)
Section "InputDevice"
Identifier "twl4030-keypad"
Driver "evdev"
Option "Device" "/dev/input/event1"
# code 114 (KEY_VOLUMEDOWN)
# code 115 (KEY_VOLUMEUP)
Section "InputDevice"
Identifier "cyttsp-i2c"
Driver "multitouch"
Option "Device" "/dev/input/event2"
# mouse should move as fast as finger and not faster
Option "AccelerationScheme" "none"
# evdev has it, multitouch doesn't so it behaves like touchpad
# Option "IgnoreRelativeAxes" "True"
Section "Device"
Identifier "Card0"
Driver "fbdev"
Option "fbdev" "/dev/graphics/fb0"
# rotate screen to be in sync with touchpad orientation
Option "Rotate" "CCW" # CW=90 UD=180 CCW=270
Section "Screen"
Identifier "Screen0"
Device "Card0"
This will map all hardware keys and use mutitouch driver for screen. To make it work, I used
evtest package which allows you to see events from input devices so you will know which
device produce keyboard events and which produce multitouch events. To be honest, this
solution isn't prefect, because screen behaves like touchpad, so you can't just point to
screen and expect your cursor to just to that position.
Following video shows X server in action.
This is simple unaccelerated frame buffer. This makes performance less then desirable.
There are a few implementations of OMAP xorg server:
xf86-video-omapfb uses DSS kernel support which seems to be part of CM kernel,
so this might be good next thing to try out

xf86-video-omap is newer implementation, but this requires 3.3 kernel and is not yet

Having accelerated OMAP X server and fixed touchscreen issues would make Nook
somewhat nice Linux tablet, if only it isn't so heavy for day-to-day use :-)