Magnetometer info

A random collection of various articles about Magnetometer (and other MEMS) sensors. Please let me know any other interesting articles with recent updates on this subject.


  • IIS2MDC (from ST) ca. € 1.31 / 100 (similar to LIS2MDL but temp. compensated?)
  • LIS3MDL (from ST) ca. €  0.90 / 100
  • LIS2MDL (from ST) ca. € 0.984 / 100
  • LSM9DS1 (9DOF from ST) ca. €  3.77 / 100
    (LSM9DS0 seemed to be more accurate, but EOL)
  • MPU-9250 (9DOF from Invensys) ca. € 4.90 / 100



Random notes from reading blogs and articles (FWIW):

MPU9250 is good value for money
AK8963A is embedded in MPU9250
MPU6500 (accel/gyro in the MPU9250)
LSM9DS1 has the LIS3MDL embedded
LSM9DS1 has no advantage over MPU9250


HMC5883 very good (low noise) but EOL
many Chinese shops offer QMC5883 as a replacement, but it is mostly inferior to HMC5883
HMC5983 was the newer Honeywell offering (not available anymore)
LIS2MDL and LIS3MDL good Magnetometer from ST
LIS3MDL is replacement for LSM303C?
MAX21100 (no Magneto)
Bosch BMF055 not as good as MPU9250


Build Raspberry Pi Soundmonitor


This article describes how to build a simple soundmeter using a Raspberry Pi and a ‘simple’ microphone. In this case I used a somewhat more advanced microphone: The PS3 Eye Camera because it currently (2018) is a great 4 microphone array that is still readily available and can be bought on a budget  (also you get a camera with it for free :-).

I’m using the Python soundmeter package for this. Simply install it according to the instructions mentioned on the mentioned pypi page:

sudo apt-get install portaudio19-dev python-dev alsa-utils
pip install soundmeter pyaudio
sudo apt-get install ffmpeg

Change  2 lines in /usr/share/alsa/alsa.conf

defaults.ctl.card 0  ==> defaults.ctl.card 1
defaults.pcm.card 0  ==> defaults.pcm.card 1

This way the new microphone device becomes the default device on the system. This will cause alsa tools to use the new USB microphone as the default device.

Depending on the way how you installed pip you might need to add the pip bin path to your PATH variable, e.g by adding the following line to your ~/.profile file:


Now start the soundmeter:


You should see numbers on the screen that are refreshed (on the same line) every second like this:


These numbers represent the sound level captured by the microphone. Note that these numbers are not calibrated in any way, but it should be clear that the numbers actually relate to the sound level.

Because we would like to be able to correlate the soundlevel to the time it occurred we want to add a timestamp to the measurement, this can be done by changing a line in the file in the routine meter  like below:

def meter(self, rms):
    if not self._graceful:
        sys.stdout.write('\r%11d %10d ' % (time.time(),rms)) # <== This line was adjusted to include a timestamp

This way each sample is preceded by a timestamp in epoch time and you should see lines like below when you start soundmeter again:

 1520694811 123

Off course you should take care that the time on your Raspberry is synced to the actual time (e.g. using ntp or a GPS). This way we can store the data and later correlate it to certain point in time.

By default the interval in which measurements are done is 0.5 sec. This can be increased to another interval by using the –segment option, e.g. for a 2 second interval:

soundmeter --segment 2

Recording Sound

Besides monitoring the sound level you might also be interested to record some sounds using this great microphone. Because raw audio files tend to grow very quickly when using high sampling rates and 16 bits you might want to compress the data (e.g. suing MP3). This can be done with the ALSA arecord and the lame MP3 frontend:

sudo apt-get install lame

And record using:

arecord -f S16_LE -c2 -r8000 -t raw -D plughw:1,0 -d 10 | lame -r -s 8 -b 64 - sound-10secs.mp3


My First Camera Drone

Over the past years I have been following the developments with respect to so called “drones” with some interest. The first mass market player being the Parrot AR drone. Especially the combination of affordable drone with a camera that seemed easy to fly appealed to me. However looking at actual footage it became clear to me that it was a nice toy, but seemed not suitable for creating quality video.

Over the past few years this changed notably. Especially the DIJ Phantom seemed to bring quality video at an affordable price-point. I atarted investigating the drones that seem to be able to deliver quality video for an affordable price at this moment (summer 2015)

In this article I want to share my experiences selecting a “drone” that I want to use for creating nice video footage for personal use (e.g. holiday footage, outdoor activities, sports etc.). I will gradually extend this article during my quest for the “best” camera drone that fits my (not yet exactly defined) budget and requirements. If you are into this subject yourself you will probably get bored by this article quickly, when you find yourself in the same situation it might be of interest to you.

My First Shortlist

I started creating a shortlist so I don’t have to consider each drone in detail. At first I started out with only a rough idea about the requirements being: able so shoot “quality video footage” for an “affordable price” (e.g. < € 1500,) this for now resulted in the following list.

  • DIY Phantom 2 with add-on camera (e.g. GoPro)
  • DIY Phantom 2 Vision+
  • DIY Phantom 3
  • Yuneec Q500 Typhoon
  • 3DR Solo (not yet available in Europe?)

Detailing requirements

Off course when spending a serious amount of money the above mentioned requirements are not really suitable, so when diving further into the subject matter and comparing specifications and actual footage shot by the drones on the shortlist I became more aware of what I really needed.

Get a Gimbal

When comparing footage it became clear to me that to shoot any serious video using a drone you need a gimbal. The video that made me realize this can be found here.

Other requirements

  • GPS support
  • Video Link / FPV
  • (Affordable) Spare parts
  • Support by seller and supplier

First experiences with the Lua Nodemcu ESP8266 Based WIFI Network Development Board

Note: this article is still under construction! There is a new version (v2) of this board with pin-spacing that is more convenient for use with breadboards (also available from other suppliers).

For some time now I observed a buildup of the buzz around the ESP8266 IoT devices. I only recently started with exploring microprocessors (uP’s) in more depth (Arduino family, TI TM4C123G and MSP430 Launchpads). I first saw the ESP8266 mentioned as a Wifi add-on device to these uP’s, however last months more and more standalone applications for these great little devices popped up in various articles. So I decided to buy a few and start experimenting with them. So this article is written from a beginners perspective.

Because these devices are so cheap (less then $3 on sites like eBay) I decided to buy a few of them so I could build multiple devices and applications. Also because I like to start the easy way I decided to buy a few development boards also. These boards are suited for use on a breadboard and have more GPIO pin breakouts than the ‘standard’ ESP8266 devices.

While investigating the possible options for the different ESP8266 based boards I wrote an article explaining the different available form factors for these boards (still to be published)

Besides some standard ESP-01 form factor boards I also ordered an ESP-07, and ESP-12 with and I/O adapter plate, and 2 development boards:

  • Lua Nodemcu ESP8266 Based WIFI Network Development Board ($ 8,95 from eBay)
  • ESP8266 Wireless Wifi Module Develop Board 8266 SDK Development Chip with the cable ($15 from aliexpress)
NodeMCU devboard

NodeMCU devboard

I ordered with different sellers on eBay and AliExpress. I was used to waiting for several weeks when ordering from Chinese web-shops, however this time the goods from 2 eBay sellers arrived within 8 days!

As the development boards and boards with I/O adapter plate have pin’s spaced at 0.1 inch (2.54 mm) I expected them to be suitable for breadboard experiments. Unfortunately the ESP-07 and ESP-12 based ones did not come pre-soldered, so I had to solder the ESP-8266 and the headers onto the I/O adapter plates. Fortunately the Lua Nodemcu development board did come with the headers soldered on so I expected I could start immediately experimenting.

However it turned out that the spacing of the rows of the boards was at 1 inch, so the width of the boards would cover all available holes in the terminal strips of the breadboard. So I started off using jump wires to connect the boards to the breadboard and other components directly.

The development boards have a micro USB connection that can be used for direct communication with the device from a computer, so there is no need to have a USB-to-TTL dongle available separately. For a first prototype I decided to try to build a fairly standard DS18B20 based temperature sensor IoT device first.

The first hurdle when starting with such a board is getting a serial connection to the board. When I plugged in the board I saw in device manager the dreaded yellow exclamation mark indicating no suitable driver was found. It turns out the board uses a CH340G USB/UART converter chip. I downloaded the driver from arduined.

Schermafdruk 2015-04-26 21.32.10Once the driver is installed you can obtain the assigned serial COM port number via the device manager (available in the control panel). It should be possible to connect via this COM port to the LUA interpreter running on the ESP8266 using your favorite terminal emulator program. Most boards are configured for 9600 baud (1 startbit, 8 data bits, no parity). If you don’t get any prompt it might be that there is no firmware on the devboard, or the firmware uses a different baud rate. Just try some settings untill you get a response.

Schermafdruk 2015-04-26 21.41.39An easy way to communicate with the LUA interpreter on the ESP8266 is by using the ESP8266 LuaLoader. It allows you to perform simple tasks (like setting the SSID and password for your wireless router so it can connect to you network) via a GUI. You can also read out or set the status of its GPIO ports, obtain information like the IP address or the chipID, or upload files. However after some more experimenting I finally settled on ESPlorer which has a more contemporary user interface and has syntax highlighting on LUA code.


To be continued… (Sorry article is not yet ready)

Software used

The following software was used in realizing the wireless temperature sensor:

  • NodeMCU Flasher – for uploading the latest NodeMCU firmware to the ESP8266 devboard.
  • ESP8266 LuaLoader – for easy interaction with the NodeMCU commandline.


Determining the right frequency for ec3k

It turned out that to be very critical to tune your rtlsdr tuner to the right frequency when trying to receive data from the Conrad Enery count 3000 (aka Velleman NETBSEM4, aka LaCrosse Techology Remote Cost Control Monitor – RS3620). That’s why I investigated this a little further. The results can be found below.

Using ec3k with Raspberry Pi

The gnuradio based ec3k software allows you to receive data from the Voltcraft Energy Count 3000 sold by Conrad. This device is also sold under different brand names such as “Velleman NETBSEM4” and “La Crosse Techology Remote Cost Control Monitor – RS3620”.


These sets contain plugs and a little display device that looks a little like a remote control. The display device can be used to receive and display the data from the plugs. Each plug sends out a data packet each 5 seconds, the data that is sent contains the following information:

  • The unique ID for the plug (a 4 character hex number)
  • The current power usage (in Watts)
  • The maximum usage of the device (in Watts) since the start of the measurements
  • The total energy usage (in Wh) since start of the measurements
  • The time that the device was ‘on’
  • The total time since the start of the measurements

emoncmsReceiving this information using a computer allows you to plot nice graphs of your energy usage per device / plug, giving great insight in energy usage of different devices in your household.

Using the ec3k software on a regular x86 or x64 based Linux device is quite straightforward, however using it on an ARM processor based Linux device like the Raspberry Pi turned out to have some quirks. The main thing is that the Gnuradio software is not (yet) available as a package in the repositories of the Linux variants for the Raspberry and that there is an issue when compiling the Gnuradio sources as-is. That’s why I wrote this little blog to help out anyone who wants to use this setup.

As all software mentioned in this blog is still evolving always first have a look at the requirements as mentioned for ec3k at the github page or the pypi page.

The basic steps are

  • Download and install a Raspberry Pi image with Gnuradio pre-installed
  • Download and install the ec3k software
  • Fix the Gnuradio installation by downloading Gnuradio and compiling a small part of it
  • Start the ec3k software for testing
  • Adjust the ec3k_recv script
  • Write a script to send the data received to your favorite dashboard software

Please note that I am doing nothing new or special here, I’m just using software that others have kindly made available to the public.

Download a Raspberry Pi image with Gnuradio

Gareth Hayes created a Raspberry Pi image for Software Defined Radio which includes Gnuradio. It can be downloaded using the Torrent mentioned in his article. It’s a 3.75 Gb download so it can take some time depending on your Internet speed.

Install the Raspberry Pi image on an SD-card

After you have downloaded the Raspberry Pi image, you can install it on an SD-card using your favorite software, I used Win32 Disk Imager for this. Please use an SD-card of at least 8Gb so you will have some spare room for software and data. Put the SD-card in your PC, just start Win32 Disk Imager, choose the downloaded file as “Image File”, and the drive for your SD-card as “Device”. Then press “Write”.

If you don’t have a spare SD-card and you want to preserve the content of your current Raspberry Pi SD-card, then choose a backup location in “Image File” and press “Read” first. This will save your current SD-card image so you can restore it later.

Once the image is on the SD-card, boot your Pi with it. It is easiest if you connect the Ethernet port of your Raspberry to your home network (assuming a DHCP server is running locally). This way the Pi will automatically obtain an IP address. (you can determine it’s IP address by having a look at the DHCP administration of your local router (or other DHCP server), it will register with the name “raspberry”). You can login to the Pi via SSH using the username ‘pi’ and password ‘raspberry’.

Note that the installed image file does not have any free space left so we can’t add anything to it. We first have to extend the partition to the full size of the SD-card. You can do this using standard tools like fdisk and  resize2fs, Basically the steps are: throw away the Linux partition and create it again with the same “first sector numer”, but now let fdisk fill in the “last sector number” which defaults to the end of the disk / SD-card. Then use resize2fs to extend the filesystem within the larger partition. This goes like:

pi@raspberrypi% sudo fdisk /dev/mmcblk0

Command (m for help): p

Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes
4 heads, 16 sectors/track, 242560 cylinders, total 15523840 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b5098

 Device Boot Start End Blocks Id System
/dev/mmcblk0p1 8192 122879 57344 c W95 FAT32 (LBA)
/dev/mmcblk0p2 122880 7872511 3874816 83 Linux

Command (m for help): d
Partition number (1-4): 2

Command (m for help): p

Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes
4 heads, 16 sectors/track, 242560 cylinders, total 15523840 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b5098

 Device Boot Start End Blocks Id System
/dev/mmcblk0p1 8192 122879 57344 c W95 FAT32 (LBA)

Command (m for help): n
Partition type:
 p primary (1 primary, 0 extended, 3 free)
 e extended
Select (default p): p
Partition number (1-4, default 2): 2
First sector (2048-15523839, default 2048): 122880
Last sector, +sectors or +size{K,M,G} (122880-15523839, default 15523839): 
Using default value 15523839

Command (m for help): p

Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes
4 heads, 16 sectors/track, 242560 cylinders, total 15523840 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b5098

 Device Boot Start End Blocks Id System
/dev/mmcblk0p1 8192 122879 57344 c W95 FAT32 (LBA)
/dev/mmcblk0p2 122880 15523839 7700480 83 Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.

pi@raspberrypi% sudo shutdown -r 0
Broadcast message from root@raspberrypi (pts/0) (Tue Oct 28 09:43:20 2014): 
 The system is going down for reboot NOW!

Now login again and extend the filesystem

pi@raspberrypi% sudo resize2fs /dev/mmcblk0p2
resize2fs 1.42.5 (29-Jul-2012)
Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/mmcblk0p2 is now 1925120 blocks long.

Now we have a raspbian image with Gnuradio and some free space on it.

Download and install the ec3k software

Once logged in to the Pi and assuming you have Internet access you can download the ec3k software, unpack and install it. Please first have a look at and verify that you are downloading the most recent version (which was ec3k-1.1.1 at the time of writing, note that the original  ec3k-1.1.0 does not work together with Gnuradio 3.5.7).

tar xvzf ec3k-1.1.1.tar.gz
cd ec3k-1.1.1/
sudo python install
python test # this is optional

If everything was OK you should now be able to run the ec3k_recv script, so let’s try:

pi@raspberrypi ~ $ ec3k_recv
linux; GNU C++ version 4.6.3; Boost_104900; UHD_003.004.002-0-unknown

gr-osmosdr v0.1.3-4-g42c66fdd (0.1.4git) gnuradio 3.7.5git-0-g2bb2b314
built-in source types: file fcd rtl rtl_tcp uhd hackrf rfspace
Using device #0 Generic RTL2832U OEM
Using 16 buffers of size 262144.
usb_open error -3
Please fix the device permissions, e.g. by installing the udev rules file rtl-sdr.rules

FATAL: Failed to open rtlsdr device.

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.

Using Volk machine: generic
VOLK: Error allocating memory (posix_memalign: 22)
Segmentation fault

So not everything seems to be OK. There are still 2 issues to be solved:

  • Installing udev rules for rtl-sdr
  • Fix the Gnuradio VOLK memory allocation issue

Fixing the issues

For installing the udev rules, please follow these instructions on Please use the ID’s as found by lsusb for your rtl-sdr device. Use the command

sudo /etc/init.d/udev restart

to restart udev.

Fixing the Gnuradio VOLK memory allocation issue takes a little bit more time: First download and unpack the Gnuradio source:

tar xvzf

We have to apply the fix as mentioned here.

So obtain the patch, and apply it:

patch -p1 < *volk*.patch

Now build the volk part of Gnuradio and install it:

mkdir build
cd build
cmake -DENABLE_DEFAULT=Off -DENABLE_VOLK=True -Dhave_mfpu_neon=0 ..
sudo make install

Use it (and fix another issue…)

Now we should be able to use the ec3k_recv script. I however noticed that the ec3k_recv as installed indeed runs, shows output about Noise levels steadily increasing (with -dB numbers going from about -40 dB up to -16 db in my case (due to auto-gain), however it would never show any valid output.

If you experience the same, don’t despair: It turns out that the default frequency that is being used in the ec3k software (868.402 MHz) doesn’t work for my dongle. At first I fiddled around a little with the frequency and found 868.24 MHz to be working quite decently. However when using another almost identical dongle it again didn’t play well with that adjusted frequency. I got curious and wrote a little script to ‘scan’ several frequencies around 868.3 MHz, I put the results in a stacked bar-graph for my dongles. I found the results quite surprising, I expected to see some kind of “standard distribution”, however the results were quite different:


So it seems like there are 4 regions in the frequency spectrum around 868.3 MHz which are sensitive to receiving the ec3k data packets with gaps in between them where the dongle seems almost deaf to the signals. I’m not yet quite sure what causes this. It might be because of the used modulation (FSK), the way the decoding software is setup, the dongle/tuner/antenna used or any combination of these. Anyone who is more experienced with radio technology, DSP and/or SDR is welcome to comment on this phenomenon.

Anyhow: this clearly shows that setting the right frequency for your dongle is of utmost importance if you want to receive most data packages from these plugs. I will cleanup the code of the scanner script a little and try to have it incorporated in the ec3k software. I’m still having some doubts about the results of the test and finding the best frequency because of the effects of using auto-gain during the measurement.

Another way to find the right frequency is to hook-up your dongle to a Windows system, Install SDR# or another SDR package that can do a waterfall plot (a.k.a scrolling spectrum plot). It seems like the best frequencies are just besides the center frequency for the dongles (where there is no ‘red’ color, this also depends on the settings of SDR#).


You can fix the frequency in at line 275 (for version 1.1.1, this may be different for a new version of ec3k). If you write your own client program (like ec3k_recv) then it is best you also provide this frequency using an extra ‘freq=868.xxxe6’ parameter in the call to ec3k.EnergyCount3K. This way you can later update the ec3k software without having to modify its source code.

Just have a go at it and you will probably find a frequency that is suitable for your plugs.

Optimize it

Because the Raspberry Pi has a quite modest processor and ec3k uses Guradio in a quite powerful way, cascading several Gnuradio blocks together, CPU usage will be quite high. Even so high you will typically get so called overflows (the dreaded “OOOOO” lines from Gnuradio) which mean that the software can’t keep up with the data that is flowing in.

To alleviate things a little we can use an optimized capture program written in C instead of in Python, This will place a lesser burden on the CPU minimizing overflows. This can be done as follows:

tar xvzf am433-0.0.5.tar.gz
cd am433-0.0.5/am433/
sudo cp capture /usr/local/bin

Now ec3k_recv will use the C program capture instead of the somewhat less efficient program. You should see less O’s now 🙂

Feed the data to a dashboard

This will be handled in a next edition of this blog.

Relevant Links

Getting data from Voltcraft Energy Count 3000 on your computer

NOTE: this is not a yet a complete howto article, I just mention what can be achieved with this nice gadget and refer to some interesting information about this product.

Conrad sells a nice little gadget: the Voltcraft Energy Count 3000 that enables you to monitor the energy usage of up to 10 individual devices. The package contains 2 “power monitors” and a little remote receiver that enables you to “pair” with individual “power monitors”. You can also buy individual power monitors or a set of 3 extra power monitors. These devices are also sold under the brand name Velleman (type NETBESEM4) and “La Crosse Techology Remote Cost Control Monitor” (type RS3620).

After a power monitor is paired you can receive and display data from it. The data that is shown is:

  • The current power usage (in Watts)
  • The maximum usage of the device (in Watts) since the start of the measurements
  • The total cost since the start of the measurement
  • The cost per month based on the total power usage since the start of the measurements
  • The total energy usage (in Wh) since start of the measurements
  • The time that the device was ‘on’
  • The total time since the start of the measurements
  • The ID for each power monitor so that you can identify which power monitor belongs to what “channel”

For reliably determining the total cost you need to first set a “tariff”.

Besides reading out the data using the little remote receiver you can also use a  RTL-SDR supported radio receiver and the GNU Radio software defined radio framework for this. The following links refer to usefull information:

To use the software you first need to install the gnuradio framework and the gr-osmosdr package

  • TODO
  • sudo apt-get install gr-osmosdr

After all preconditions have been met you can install and test the software:

  • git clone git://
  • cd ec3k
  • sudo python install
  • python test

Installing gnuradio and gr-osmosdr using the default package installation for your release may result in issues. You may want to build gnuradio from source as described here.