Showing posts with label Linux. Show all posts
Showing posts with label Linux. Show all posts

LAN file transfer with netcat

Need to quickly transfer a file from one computer to another? They don't have AirDrop and you can't find a memory stick? No worries; netcat comes to the rescue. This tip works on Linux as well as OSX.

I'm going to suppose you're on the same LAN, and you want to transfer a file called photos.zip. First, open up a terminal on the receiving computer and type ifconfig|grep "inet " to find out its IP address:

$ ifconfig|grep "inet "
         inet 127.0.0.1 netmask 0xff000000
         inet 192.168.1.243 netmask 0xffffff00 broadcast 192.168.1.255
$ █

The IP address is 192.168.1.243. (We don't want 127.0.0.1, because that's a loopback address that only works locally.)

Then make netcat listen to a port by typing nc -l 12345 > photos.zip. On the sending side, type nc 192.168.1.243 12345 < photos.zip (or whatever the IP address and file name are). And magic happens!

RDS display on a Raspberry Pi

Earlier I modified my radio to output raw bits from its RDS decoder chip. The radio already displays a Programme Service name, but for FM DX purposes, it's fun to see more data. Also, the Programme Identification code can be decoded from very weak signals, identifying distant stations. And I can receive interesting traffic information messages by decrypting RDS-TMC with the encryption keys I've recovered. Now that I have a Raspberry Pi, it's time to make a dedicated little display.

First, I changed the radio connector from my previous modification. This one, salvaged from a mystery phone device I found at a flea market, doesn't come loose as easily as the Mini-DIN:

[Image: A corner of a radio labeled 'SANGEAN', with a hole cut in it and a phone connector in the hole. A phone connector is being held next to it.]

I bought a discount 2x16-character HD44780-compliant LCD at the local parts store and made a 4-pin connection to the Raspberry Pi GPIO header. I used another two GPIO pins to interface the Pi with my radio (one for data, one for clock). I then wrote a C program to read the 1187 bps RDS data, process it for error correction and synchronization, and output it to a Perl script for interpretation. The script then returns a text string to be displayed on the LCD. The bcm2835 library is used for GPIO interaction.

Turns out GPIO is not very good for data rates this high. The C program takes about 5 samples per RDS clock cycle, and uses 97 % of the CPU time. With the Perl script and LCD update running, the poor Pi can't keep up with realtime data, and lots of bits are lost. But after waiting patiently, I finally get a Programme Service name, Programme Identification code, and RadioText.

On the left, my radio. On the right, the RasPi in its doghouse:

[Image: The same radio as above, but now its LCD display and dozens of buttons are shown. On the display, the text '87.90 YLE YKSI', the time 18:41, and indicators 'FM', 'Stereo', 'RDS', 'HOME', 'Page 1'. A cable goes from the radio to a device on the right which is contained in a little thrash can of sorts. The device has a small LCD display that reads 'YLE YKSI 6201 Kultakuume'.]

Experimenting with lower sampling rates will hopefully alleviate the problems. But it kind of works already.

Update 2013-04-01: According to this benchmark, this very library should be able to handle GPIO speeds of several megahertz. So I tried running the program in strace to see what it's doing to burn so much CPU. Turns out it's sitting in a single nanosleep() call and never returning!

I experimented a bit and ended up replacing all calls to bcm2835_delayMicroseconds() (which uses nanosleep()) with calls to usleep(). And it works! CPU utilization is at 10% maximum, and a PS name appears lightning fast when changing stations. So, something was probably wrong with nanosleep() or bcm2835's implementation thereof.

SSTV reception on Linux

As a programmer writing obscure little FLOSS projects for fun, having someone actually read and fix my code is a compliment. Recently I got a pull request on slowrx, my somewhat stalled slow-scan television demodulator project, and was inspired to write more. (Note: slowrx is not maintained any more – I suggest you to check out QSSTV!)

The project started in 2007 when I was trying to find a SSTV receiver for Linux that could run in "webcam mode" and just save everything it receives. It would use modern stuff like ALSA instead of OSS and Gtk+2/3 instead of 1. Preferably it would work even if the receiver wasn't exactly tuned at the zero-beat frequency. Turned out existing software couldn't do this, so I accepted the challenge.

So here's how slowrx looks today:

slowrx screenshot

FM demodulation is done by a 1024-point Fast Fourier Transform and Gaussian spectrum interpolation. The windowing function adapts to SNR, so the resolution drops under noisy conditions but we get a clearer image (or the user may opt to use a narrow window regardless of noise). Sound card clock mismatch is calculated using a linear Hough transform on the sync channel and fixed by re-running the demodulation at the adjusted rate. The program will detect VIS headers at any in-band frequency and shifts the reception window accordingly. It can decode the FSK callsign after the picture. The program stays up for hours without a segfault. Yeah – it's written in C99!

Pictures I've received using slowrx:

Pictures received

I've noticed the 8- and 12-second black-and-white Robot modes are still in use today. I believe they were the "original" SSTV modes that used to be viewed on a green phosphor screen in a much more analogue environment. So I've been thinking about an optional phosphor filter for B/W modes:

Phosphor filter

How I made my Ubuntu usable again

Many fellow Ubuntu users have been protesting the recent developments in user interface design, call it Unity/Gnome 3/whatever. But what can a user do? Of course one could migrate [back] to Debian. But I happen to really like the way Ubuntu has done many other things. And I've found a way to restore its usability. I'll also share a few extra tips that I've found useful with Ubuntu.

Moving to Xfce

First, I replaced the default desktop environment with Xfce. It's a full-fledged, light-weight, easy-to-use desktop environment that by default has kind of an OSX-style look but is extremely customizable. It also comes with a simple compositor. Installing Xfce is simple:

$ sudo apt-get install xubuntu-desktop
$ sudo apt-get --purge remove ubuntu-desktop
$ █

This will also rebrand your distro as Xubuntu. Despite this superficial change, it will use the same repositories and, for the most part, will work exactly the same way as you're used to.

No more PulseAudio

Secondly, and less importantly, I eradicated PulseAudio which is another common source of mischief:

$ sudo apt-get --purge remove pulseaudio
Scan finger on UPEK TouchStrip Sensor-only
█


One of the most satisfying biometric sudo moments!

Cool little terminal

My terminal emulator of choice is rxvt-unicode, also known as urxvt. Living up to its name, it has great support for Unicode in addition to being fast and lightweight. It can be daemonized, which shortens the startup time of new windows even more. Needless to say, it's very customizable via Xresources. It also comes with a bunch of optional Perl extensions.

Keyboard tips

These keyboard tips work in Xubuntu and Xfce, but could be applied to other environments, too.

Some shortcuts

[Image: Keyboard settings window with the Application Shortcuts tab open.]

Keyboard shortcuts can be added in Application Menu → Settings → Keyboard → Application Shortcuts. For example, I've set the command urxvtcd to be executed when the section (§) key is pressed. This way you can map a seldom-used key to do something more useful, in this case open a new terminal window.

I've also made it easy to copy text from XA_PRIMARY (the "mouse cursor" clipboard) to XA_CLIPBOARD (the "Ctrl+C Ctrl+V" clipboard) by adding a shortcut key to launch the command /bin/sh -c "xclip -f -out | xclip -selection clipboard".

Compose key

The Compose key can also be useful. It lets you quickly input many special characters not directly present on the keymap, using simple mnemonics.

To map the Windows key to work as a Compose key, add keycode 133 = Multi_key to your ~/.Xmodmap:

$ echo keycode 133 = Multi_key >> ~/.Xmodmap
$ █

Also, make Xfce read the config at startup by adding xmodmap /home/username/.Xmodmap to your Settings → Session and Startup → Application Autostart:

[Image: Session and Startup settings window with the Application Autostart tab open and the popup Add application.]

Some compose key sequences and the characters they produce:

Cmp + S + O§
Cmp + O + C©
Cmp + A + Eæ
Cmp + + >

Unicode input

To input an arbitrary Unicode character that you know the code point of, press Ctrl+Shift+U, then the code point in hexadecimal, and commit it with Enter or Space. Like so:

Ctrl + Shift + U
21D2 space
221B space
5B97 space
2620 space

Over-enthusiastic Sticky keys

You can disable gdm's Sticky Keys and Slow Keys accessibility helpers by adding xkbset -a to the aforementioned Autostart list.

Done!

There you go! Make sure to choose Xfce or Xubuntu session from the greeter when you log in. And here's a screenshot of my Xubuntu session with root-tail, conky, rxvt-unicode, vim, and Firefox:

[Image: Full-desktop screenshot of Ubuntu.]

Google Earth on 64-bit Linux

Google Earth is a fun toy. But it's not always straightforward to get it to work on a 64-bit Linux (Ubuntu) system, since it's a 32-bit program, even when the .deb package says amd64. I wrote this post as a reminder for myself and others who run into similar problems.

* * *

Sometimes Google Earth wouldn't find a file called libGL.so.1:

  ./googleearth-bin: error while loading shared libraries: libGL.so.1:
  cannot open shared object file: No such file or directory

You can work around this by installing the 32-bit libraries and helping Google Earth find the file. Assuming your Earth installation is in ~/google-earth/:

$ sudo apt-get install ia32-libs
$ ln -s /usr/lib32/mesa/libGL.so.1 ~/google-earth/libGL.so.1

* * *

Sometimes this cryptic error message would also show up:

/usr/bin/google-earth: 43: ./googleearth-bin: not found

Luckily, fixing it is easy:

$ sudo apt-get --reinstall install lsb-core libc6:i386