I used to run VMware products since they exist (well, shortly later). Back when there was VMware Workstation 1.0 in 1999. We use it at work in shape of ESX 3.5. Great stuff. Solid. Useful at home too with VMware Server (free) or for Mac, use Fusion (cheap).

That is, all was well until I updated to Kubuntu 9.10. Then things broke. Badly. VMware server kernel modules could not compile (see here and here and here). Despite the helpful fixes (not from VMware if I may comment), it was simply unstable. The web console would suddenly stop working (the VMs were fine), and maybe the console could be restarted, or maybe not. And if not, then there was nothing in the world I could do to fix this beside rebooting. Very annoying.

I waited some months(!) for a fix from VMware, but I guess when it comes to support, the free VMware Server cannot compete with the (quite expensive) ESX.

Fair enough. The kernel of (K)Ubuntu 9.10 is not supported in VMware Server 2.02 after all. Time to move on as I did not want to move back to an older kernel. I rather move to a more recent kernel.

Enter KVM. I used qemu some time ago for fun. Mostly for emulating non-x86 architectures (e.g. ARM) to run their binaries for no other reason than because I could. It’s fun to use an arm cross compiler (my NAS runs on a Marvell 88F5182 AKA Orion), and run the very same binary on an AMD Athlon Linux box via qemu. KVM, the native Linux virtualization has a lot in common with qemu. E.g. it uses the same network infrastructure, same file format, same BIOS from Bochs. KVM expects a CPU to offer hardware assisted virtualization. I had that, so I tried to make KVM work.

And what shall I say: It’s working as expected! Even has a graphical interface to setup VMs (but all can be scripted too) via libvirt. Great for the first initial creation of a VM. The graphical interface is not even close to the polished interface the Virtual Infrastructure client software ESX offers, but good enough. And it works. USB pass-through works too after a bit of Google (AppArmor, which I did not even know was enabled until then, was in my way but the fix was here). PCI pass-through would probably work, as well as live migration (AKA VMWare’s vmotion or Citrix‘ Xen live motion). I lack the equipment to do this though.

I have to admit I like virtualization in general. It’s great for consolidations, not only at work. At home it’s very useful to be able to have USB and PCI pass-through (see here for a Xen virtual server to capture video signals for MythTV). You can have one computer instead of one Linux, one Windows, or one computer booting either Linux or Windows.

With KVM I’m a happy user again. And I can even think about upgrading to the latest Linux kernel…

After playing a bit in the transparent (AKA AT) mode, it became apparent that it’s quite limited if you plan to do more than just using 2 XBee’s as a wireless serial connection. E.g. it’s not possible to receive the state of the digital and analog inputs from a remote XBee endpoint. The biggest drawback of the API mode is that it’s quite difficult to interactively use it. It’s made for programs to use, not for humans.

After looking for a usable API library, I found this blog which not only pointed me to the right direction, but also to a Python library which is easy enough to use. Easy enough for me who’s not used to Python.

Here a short program included in the library and meant as a sample, which I I slightly modified to make D4 of the endpoint blink, and it sends back the status of D1 and D2 once in 0xf000ms. That part does not work though. I always seem to get the same values back regardless of the I/O status.


from xbee_api import *

#set led status
led=not led
if led:
api.sendRemoteAT(device["EP1"],"D4",[0x04])
else:
api.sendRemoteAT(device["EP1"],"D4",[0x05])
time.sleep(0.5)


One day I figure out how to keep the white spaces…until then, please imagine the spaces where they belong to.

Several things I learned while using those XBee radios:

1. When flashing new firmware on the XBee using the X-CTU program, keep 9600 baud. It makes your life easier as it will always default back to 9600 which is when you will lose your connection to it again and again. When everything is set and working, change baud rate to what you like.
2. Digi’s documentation is not bad, but more examples would make life easier. Luckily those XBees are popular enough that there are lots of examples in the wild.
3. I still have no idea what the firmwares for digital and analog endpoints do. The endpoint with API interface seems to be able to handle everything.
4. Watch out for sleep mode. For endpoints, you cannot turn off sleep mode. Instead use Pin 9 and set it to GND to disable sleep (and SM=1).
5. Connect the RSSI and Associate pin to LEDs. Helps a lot while debugging.
6. Have the Commission pin connected. It turns the radio on for 30s so sleep mode is not an issue for 30 seconds.

I’ve got those XBee Series 2 modules for quite some time, and I finally managed to make two talk to each other. That was more complicated than I expected, but in the end it was not difficult at all, if you know what to change and how to configure them.

I use the XBee Series 2.5 (AKA ZB) models. There is a lot of documentation about the older Series 1 models. They are easier to use and need no configuration to make 2 talk to each other. The ZB models are a bit more complicated.

1. Program one via X-CTU as a ZIGBEE COORDINATOR AT (that’ll allow transparent use)
2. Configure a PAN ID (actually this is optional), configure a Node Identifier (”CO3″ in my case), and the Destination High and Low address is the serial number of the end device XBee. Unless you do this, no characters will go around.
3. Program the other XBee as ZIGBEE END DEVICE AT”
4. Configure PAN ID to the same one as before, configure a Node Identifier (”EP1″). Leave Destination High and Low to 0, which is the Coordinator.

That’s it.

What you will see then is:

1. On the Funnel I/O board there are 3 LEDs. CHG for Charge (when USB is connected and the LiPo battery is charged), ON which blinks about twice per second, and RSSI which is green when you send characters via the Coordinator via the X-CTU Terminal.
2. On the X-CTU Terminal connected to the Coordinator, when you enter command mode (+++), and ATDB, you’ll get a number back which is the direct dB value in hex. The more, the weaker the signal. 0 means that no character ever was received.

Here the link which gave me the “Ah! Got it!” effect. It’s one of the few ones which write about the 2.5 firmware (which is similar to the ZB one I use).

Sharp built a LED based lamp with a remote control named DL-L60AV in Japan. As the name implies, it’s supposed to be comparable bright to a 60W incandescent light bulb. That alone is quite impressive for a LED lamp.

I bought one of those for my wife. Since  you cannot only control the brightness but you can also control the color temperature it did look really nice to have.

It did not take long that it occurred to me that the IR remote control ability means that by using an computer connected IR sender, any computer can control a 100V lamp. No need to twiddle with 100V electronics, no need to use any power electronics like triacs. Being hit by a charged elko once (that was back in Germany, so it was probably 325V)  I have a lot of respect for 100V.

Kuroutoshikou has such an IR controller/sender named KURO-RS. I am tempted to buy one, but I unlikely will have time to play with this.

When you have one of those routers like the Planex (AKA PCi) MZK-W04NU, the first thing to do if to upgrade the firmware to an ‘open’ version, so it does what you want it to do, not what the manufacturer had in mind.

In the case of the above router it has WiFi 802.11n, a 4 port switch and one more NIC and one USB port. That’s enough to make it do a lot of things: router, wireless router, or bridge, or firewall, or media server, or NFS/CIFS server, or print server. You are limited by the CPU (MIPS 4k@400MHz) and RAM (32 MByte).

Step one is to update the firmware to something else, e.g. OpenWRT.

In the end you will have one way or another a “webui” file which you can use to update the firmware via the firmware update link in the web interface.

Once you have OpenWRT installed, it’s easier: you need a “bin” file (about 7.5MB in size), and upload it via:

mtd -r write openwrt-ar71xx-mzk-w04nu-squashfs.bin firmware

Then wait (it takes about 3min), it will reboot, and there you go: a new firmware.

For those lucky ones living in Japan and liking sweets (I count me double lucky in this case), here an interesting blog to read.

For those able to read German, here here a web page to read about how companies use basically false advertising. Not breaking any laws, but clearly misleading. Examples:  Philadephia Cream Cheese with Tomato and Pesto. Lots of pictures of tomatoes on the package. However it contains a full 0.4% dried tomatos. And Basil-processed-cheese-paste, no pesto. Or Bertolli Pesto Verde, which is supposed to be made from Basil, olive oil, Parmesan cheese, pine seeds, garlic and salt. All those are in there, but in small amounts (in case of olive oil and pine seeds 2-2.5%). A traditional recipe I found contains 50g pine seeds, 100g cheese, 180ml olive oil, and basil leaves and salt. The one from Bertolli contains cheaper substitutes: plain plant oil and cashew nuts. Lactic acid is added to make it possible to add no further preservatives, thus stating “without preservatives” as lactic acid does not count in a legal sense as such. Fun and educational to read about how marketing and advertising exaggerate and leave out unpopular facts.

Stuff I’ve never seen (or in this case: heard) before. Hatsune Miku  (初音ミク), which is actually a voice synthesizer software which can sing. And with another voice of Megurine Luka. And more. And different. And here an original video from Loituma:  and here acapella.

That song is now stuck in my head for a while…

And here something different: “Die Kleine Fuge in G-Minor” from J.S. Bach: Hatsune Miku singing and more traditional for comparison.

Squarely fits into “odd but fun” juts like this.

Found here: how to convert music files for SH906i (and similar phones).
Put those MMFxxxx.M4A files into private/docomo/mmfile/mud001/
You can create more mudxxx directories.


#!/bin/bash

IFS=’\\’
cd $1
i=0
ls|while read f
do
echo Encoding: $f
#len=`expr length $f`
#len=`expr $len – 4`
#ren=`expr substr $f 1 $len`

# 名前をつけるMMF0001〜
i=`expr $i + 1`
name=`printf %04d $i`
name=”MMF$name”

lame –decode $f $name.wav
faac -w $name.wav
rm $name.wav
echo Encoded: $name.m4a
done

To play on the phone, go to databox/music/i-mode/mud001.
As it is, it works, but you ‘fly blind’ unless you remember what number is what song. But in this state it’s good enough to play music and thus it saves me to buy a separate music player.

PS: I found out that the limit is 400 songs per directory.

Roland has a nifty little thing named “RMP-5″. It’s called a ‘rhythm trainer’ and I like it a lot. It’s something different from the usual stuff I do. And it’s fun.

Less fun is the power supply which is completely missing in the box. While you can use a (supplied) 9V battery, the unit draws about 30mA which lasts only about 6h. The RPM-5 can be powered by a 9V DC power supply, but the one from Roland is kind’a expensive compared with what’s available (e.g.) here.

So of course I looked at the power supply plug at the RPM-5 and it looked like a plain vanilla 5.5mm barrel jack. So I went out, bought a 9V DC unit, connected it, and…nothing happened.

Roland thought it’s more fun to change the polarity. Instead of minus being outside (and thus +9V inside) as usual, they swapped that.

Now the good news is, that the RPM-5 does not break if you try to plug in a ‘wrong’ PSU. It just does not turn on.

The fix is to swap the cables and thus polarity. Et voila, works as expected.

While browsing the web page of my favourite electronics shop in Akihabara Akizukidenshi (秋月電子) I saw this small USB module. Originally to connect things like FPGAs, microcontroller etc. which cannot use serial ports, it also has a bit-bang mode where it simply outputs on 8 data ports whatever you like. There’s a simple to use library available libftdi which can make those chip and its port directly accessible in Linux (and more).

The data sheet for that chip is at best spotty, but the chip works as advertised.

Some highlights of the FTDI 245RL and the above module in particular:

• 8 data ports
• I/O can be 3.3V or 5V
• each I/O pin can be set to input or output independantly
• Has a 3.3V step-down converter already built in
• Can output 1MByte/second
• Has an unique ID burnt into the chip
• Can source and sink 2mA normally, or 3 resp. 8mA when in high-drive mode
• 1 kb EEPROM is built in too

Quite versatile. Combine with a small Linux host (like this which I happen to have) and for many applications which need network and some I/O, this is an easier way to get things done compared with a stand-along microcontroller. As long as weight/power consumption and lack of low-latency (millisecond range or faster) is no issue, it’s at least easier to get started and you can use all the amenities of Linux (free choice of programming language, Internet connectivity, a clock, daemons for cron and at etc).