Category Archives: hacks

rpi4 serial console

Let’s assume you somehow came into possession of a Raspberry Pi (rpi) 4 and want to configure it for something useful.
After writing the raspbian image you discover though that you have no suitable cables nor converters for the micro HDMI port.

If you do have a USB to serial TTL converter though, you can just configure rpi over the serial port.

In order to do that we first have to enable the first serial port on the rpi. To do that you have to mount the micro SD card with the raspbian image on your computer and add these lines to enable the serial console to config.txt:

sudo mkdir /mnt/tmp
sudo mount /dev/sdz1 /mnt/tmp
sudo echo "enable_uart=1" >> /mnt/tmp/config.txt
sudo umount /mnt/tmp

… where you have to replace sdz with actual device name of your SD card (you can find it from the output of dmesg for example).

Now connect the USB to serial cable like this:

  • ground -> pin 6 (GND)
  • rx -> pin 8 (TXD1)
  • tx -> pin 10 (RXD1)
  • +5V will remain unconnected

… which looks something like this:

You should be able to access the terminal using something like this:

picocom -b 115200 /dev/ttyUSB5

Where you have to replace ttyUSB5 with whatever device for the USB to serial converter on your system (which you can again find out from the output of dmesg).

and hardware is the easy part…

One of my hobbies is building robots. The largest one to date is this (me for scale):

I created it as a general large platform for outdoor experimentation that would be able to take on various practical tasks in a more or less autonomous manner.
What I didn’t anticipate is how hard it is to build such a platform in a way that is both economical and reliable.

While it does work in general, the Mean Time Between Failure has proven to be somewhere in the range of an hour or so.
When something major breaks, the robot goes back to the parking lot waiting for the next season while I contemplate if I want to spend more resources on fixing it. So the progress on this project has been rather slow to put it mildly…

Anyway the first idea was to use it as an autonomous lawnmower. I did get around to doing some mowing experiments with a single blade as you can see in this video:

As you can see the mowing part works, but it isn’t particularly impressive. Adding the second cutting motor would have helped a bit as would using a single large blade with a more powerful motor like the one that is used in commercial cordless mowers like Makita DLM380.
But in general this chassis seemed just too powerful and dangerous for an autonomous mowing operation in the garden. Nowadays Ardumower seems like a much better base for autonomous mower projects.

Personally I also lost interest in the specific problem of mowing several years ago since it isn’t a personal itch anymore — I have sheep nowadays to keep the grass at a reasonable height.

So anyway I decided to repurpose the robot for watering plants in the field.
It’s something that I potentially actually need, requires quite a bit of carrying capacity and the work happens out in the field where it can’t cause that serious damage when it goes out of control. It also tried the job of the sheepdog for a while 😛


The motors that I use are really old 24V wheelchair motors. These motors seemed a really good fit for my purpose because of the high torque and generally robust construction.
They are really hard to source though at a reasonable price (new ones go for min. 400+EUR/pair) and it’s hard to connect these to any wheels that are cheap and fit for agricultural purposes.

I managed to find a local wheelchair repairman who sold a pair of these for 25EUR but the downside is that these are old used ones are rather one-off and in unknown condition. You are lucky to get a matched pair and mine had an obscure shaft with a keyslot. If one motor fails you will probably have to find another pair which likely has a bit different dimensions, shaft length, -diameter and type which would require a bit of redesign.

The spiral spring holding one of the brushes in place on one of the motors rusted through. Finding a suitable replacement spiral brush spring seemed rather hopeless so I patched it with a random spring of completely different type. It kind of works but is somewhat unreliable — it sometimes loses contact and needs a tap on the back.

During the last couple of years brushless hub motors have been coming down in price and I think nowadays I would go with these instead. Finding ones that are wide enough with at least 14.5″ diam and shipping price that wouldn’t be half the price is still a challenge though.


I decided to use wheelbarrow wheels since there’s a wide selection available, there are rather wide ones with a large diameter that are suitable for rugged terrain and they are cheap.
Attaching these to the shaft is tricky though, since wheelbarrow wheels are generally built with the idea that you put a rod through them which rests on a bearing.

I decided to use an industrial taped bore and just drill matching holes through the wheelbarrow wheel rim. The best rim that I found was a bit conical though, which made it almost impossible to perfectly center the taper bore on it.

To attach it to the wheelbarrow wheels I had to find a shaft key, taperlock bush for that particular shaft and key size and a fitting taper bore.
These I had to order from different suppliers from the other side of the world which took quite a while. I didn’t actually find perfectly matching ones so I had to hammer and file it a bit and you can see on the picture that the taperlock bush has actually cracked:

Looking back at the effort spent, ordering a special made one from some local metalworks company would probably have been easier and maybe even cheaper.

The battery

The first generation used two Exide ES650 lead-acid deep cycle gel batteries in series. One of these failed though a bit after the end of the warranty. I only managed to use it for a couple of hours in total over these two years because chassis-motors-wheels took unexpectedly long to complete.
That battery failed after I used it to start a car with a dead battery once, which is kind of strange.
While deep cycle batteries aren’t certainly meant for that, I don’t think getting it damaged with using it for starting once is the expected result.

Anyway, having lost one battery I had a choice of either buying a new one for the pair or switching to some other battery chemistry completely.
While still having one usable battery would have made replacing just the other somewhat simpler and certainly cheaper proposition in the near term. In the long term this looked like a dead end though.
These batteries seem to have an expected lifetime of around 5 years and the functioning one was approaching that even though it has seen barely any actual use.
Also the energy density is obviously a lot lower than for many more modern chemistries.

I didn’t like to go with Li-Ion batteries based around 18650 cells that are otherwise rather popular with DIYers, since reading the forums of the communities shows just how fickle these can be and how much attention to the detail is needed.
Treating these batteries in just the right way for them to last more than a thousand or so cycles seems to be a science in itself and there’s a chance of them bursting to flames if you do something wrong.

I contemplated LiFePo batteries which are safer and should last a bit longer (~2-3k cycles) but then I found LTO cells (Lithium titanate) cells instead.

Lithium-Titanate cells seem to be so much better for my use for many reasons:

  • around 30k cycles or around 30 years of lifetime. I didn’t want to face losing the battery again before starting to seriously use it.
  • safe to handle. It seems right next to impossible to get them to burn with puncturing, cutting, overcharging etc. You can see how much abuse they can take here.
  • you can charge them fully in 10 minutes and discharge at 10C (400A in my case)
  • cold temperatures do not reduce performance nearly as much as they do for li-ion for example. Actually these are rated for operating down to -50C. I might want to drive the robot during the winter too and when the battery is not in use with the robot it will be used for energy storage system at the birdhouse where we have outdoor temperatures.
  • over draining or over charging these isn’t as much of a problem as with other Li battery chemistries. You can just pretty much use Lead-acid charger even without BMS if you do not care about getting 100% of capacity out of it. I guess you might also lose some of the theoretical lifetime that way but having such a nice direct lead-acid replacement might be worth it.

There are also downsides of course. Specific energy of the LTO pack is a lot lower than it would be with some other Li chemistries like NMC (73Wh/kg vs. 200Wh/kg) and the price is a bit higher (around 20% for the specific setups that I compared).

So anyway here’s the LTO battery pack I ended up building:

My pack consists of 12 * Yinlong 40Ah 26650 cells. The nominal voltage of these cells is 2.3V so for the pack it is 27.6V.
The busbars connecting the cells are cut from 4mm thick aluminium bar. I contemplated getting a copper bar for that but it’s harder to find and besides the threaded connectors on the cells are made of aluminium anyway.


I use Sabretooth 2x25A driver. This has worked flawlessly and has taken some serious abuse without any complaints. For example one year I forgot to remove it from the robot for the winter and I discovered it in the spring. Water had somehow gotten into the controller box and the board was frozen in ice.
Just melted it and dried… has worked without any problems.

update on RTK-GPS

Back in 2014 I wrote a post on RTK-GPS using Navspark NS-RAW boards. Back then I promised to write a follow-up once I have done some testing. I didn’t quite think it would take so long but the reason behind the delay is that I never quite got it working as well as I expected and tried various things over the years which took time, and I lost interest couple of times in between.

A couple of people have asked me how it worked, so finally I decided that enough is enough and I’ll just describe how far I got.

TLDR version: NS-RAW in seems to perform significantly worse than the u-blox of the same era. Even if it had performed at a similar level, single frequency GNSS in general just seems to be unsuitable for reliable ground based robot navigation. It might work at some times of the day where the satellite visibility and geometry happens to be just right and you are testing in a large open field, have good antennas etc. but for most realistic cases it will not be reliably usable.


Navspark has this to say about the required conditions to be met for a stable RTK FIX:

NS-HP or NS-HP-GL are single frequency RTK receivers. For reliable consistent single-frequency RTK operation, they require 12 or more usable satellite signals above 15 degree elevation angle with SNR no less than 38dB/Hz.

NS-RAW is single-constellation so I’m limited to only GPS. Looking at the GNSS radar tells me 5-9 GPS satellites would be visible from my location at different times of the day (with 15 degree elevation). So 12 satellites would be impossible here. Other sources say that you need 7 satellites min. to get a RTK FIX solution (and min. 5 to hold it). That would have been a bit more realistic requirement, and besides, an earlier u-blox LEA-6T test got a FIX solution just fine so I decided to go on with the test.

Here’s what my test ground looks like:

The plot has 20m high forest in the N & NE directions. Other sides have better visibility but all the sides have at least one row of 20-30m trees + some sporadic buildings and trees all over the place.

BS1 is the original base station that was described in the previous post on the topic. It uses Satmar FME marine active GPS antenna. I have added a 15cm wide ground plane below it (a paint can lid). The location of BS1 is somewhat unfortunate since it is basically surrounded by some trees from all the sides. When I originally chose the location for the base station I didn’t have good access to the roof of the main building so I chose a spot that was furthest away from the house, so that it wouldn’t block satellites from that side. Here’s the picture of the location:

BS2 is the new base station at the top of the roof. It’s about 8m higher than BS1 and hence has better satellite visibility. Tri-Band GPS/Galileo, Beidou, GLONASS Active Antenna is used. It looks like this:

“Rover” is me walking around with a laptop and NS-RAW with an antenna setup identical to BS1.
Everything is connected over WIFI.

Best case – localization between two base stations

Using BS2 as base station and BS1 as rover in the Kinetic mode should give us a good idea of what is the best that can be achieved with this hardware on my plot. Even though BS2 doesn’t have good sky visibility it’s better than a real rover will ever have since it’s located on a pole that is a couple of meters higher than the rover will ever be, and has less sky blocked by the house than a rover normally would.

I finally got RTK working rather well in this scenario and it has FIX most of the time. The location stays in a ~5 cm^2 area for the 8h session:

I was cheating a bit though – for localizing static points I use Integer Ambiquity Res mode FIX and hold. This mode takes past measurements more into account when calculating the current location than Instantaneous or Continuous would, which makes position mode stable but would also make it return the wrong position for longer if the rover was actually moving. I also used demo5 ver. of RTKLIB by rtklibexplorer which got more FIX solutions than the mainline RTKLIB.

Driveway test

Next I walked up and down the driveway as a rover a couple of times to see if I can get comparable results to my u-blox test at the same location in 2013.

The results were not bad but worse than the earlier u-blox LEA-6T test:

There were lots of slips, large residuals and ambiguity validation failures in the RTKLIB logs. Most of these errors are said to be commonly caused by not having clear enough view of the sky and the consequent multipath errors.
This seem likely since the rover certainly didn’t have a great view of the sky from 2 sides and things seemed to get worse with stronger winds (when trees had leaves and these were moving a lot).

With that said, the driveway basically has the best visibility in my yard that a real rover could ever have, so this is the most optimistic-realistic scenario. Even though the common satellite count is really low and we seem to be in FLOAT mode half of the time, the points are reasonably close (~20-30cm) and it would be usable for real navigation if this precision were repeatable 24/7 all year round. This test was done in January so no leaves on the trees which probably reduced errors a bit and made it even more of a best-case scenario.

Rover circle

Now for a more realistic test – walking in a circle with 20m diameter in the middle of the yard in mid-summer when trees have leaves.

This looks rather bad, only 2.1% of the points have FIX solution. The FLOAT solution was reasonably precise for 3 circles and then suddenly wandered through the circle. We see that most of these points have a lower confidence than FLOAT points on the actual circle so we could filter those out on that basis, but we also see a single FIX solution point in that path which is a couple of meters away from the actual location.
This test was done with integer ambiquity res. set to continuous.


What next?

I have put the navigation project on hold for now. I expect L5 capable chips to be much more common in the next 2 years which along with new Galileo satellite launches should considerably improve the precision of navigation at my location (NE Europe). L5 should be much less prone to multipath problems that seemed one of the main things throwing my rover signal off. Broadcom 47755 is the first mass consumer L1/L5 chip and others will surely follow.

Finally here’s a list of relatively cheap alternatives to NS-RAW that are available right now and would be rather interesting to try in similar situation but not interesting enough for me to actually buy the test hardware:

  • My original tests in 2013 seemed to get much better results with LEA-6T so u-blox LEA-8T that is available for ~75$ per module might give better results. You would also be able to try out various hacks and configuration tweaks described in the awesome rtklibexplorer blog.
  • Navspark NS-HP series (NS-HP-GL, NS-HP-BD) might also give somewhat better results than NS-RAW since these have multi-constellation support. Having the ability to use Glonass satellites in addition to GPS would almost double the average number of visible satellites in my location. These chips also do RTK on board so you don’t have to have a separate computer for running RTKLIB which will save you both weight and power. They also claim significant improvements in environments like mine in the newer firmware versions.
  • u-blox M8P based boards might also be interesting, these are multi constellation (GPS, BD, Glonass) L1 chips that do RTK calculations on board so you only have to provide a communication link. Such boards are for example Tiny RTK from Drotek (~215€) or the one from CSG (~239€).
  • Drone operators seem to like Emlid Reach. Under the hood it’s a combo of u-blox M8T + Intel Edison for processing and RTKLIB with much friendlier frontends than bare RTKLIB has. It seems that some of their customers are happy with the results and others seem to almost never get a FIX solution.

After having read lots of forums of users trying to use these cheap single frequency RTK solutions, my conclusion so far is that it seems to require intimate knowledge of almost endless GNSS related stuff, a very good sky visibility, living in a place where satellite geometry is just right for large part of the time, good antennas and specific weather conditions. In short it doesn’t seem to be feasible for generic rover navigation that requires constant precision in the dm range in all corners of the yard.

esp8266 relay

Just some quick notes on using 5V esp8266 relay module. Manufacturers page seems to be this even though terminal and pin positioning on the pictures is a bit different.

For just ~2.4€ it will give you the ability to switch electrical loads over Wi-Fi 🙂

There are actually 2 basic designs floating around on Aliexpress. The one that I’m talking about here is where esp8266 module plugs into the mainboard through 8 pin connector like this:

The other one integrates esp8266 on the relay board directly.

From the shipping perspective this modular design is a bit unfortunate since cheap/free shipping from Aliexpress will usually arrive in normal soft envelopes that just have 1 layer of bubble wrap as a padding.

As a result all 3 boards that I ordered arrived looking like this:

Nevertheless they actually worked fine. I was probably just lucky though and I kind of like modular things more in principle.

Interesting thing about this modular design though is that the relay is actually controlled by the STC 15f104W MCU on the main board which is programmed to turn the relay on when it sees “\xa0\x01\x01\xa2” on its UART port and off when it sees “\xa0\x01\x00\xa1“.
That UART is accessible either through the 4 PINs between the screw terminals or input from the esp8266. So you can actually run it without the esp8266 and control the relay directly over UART PINs or even reprogram the 15f104w.

ESP8266 board comes flashed with esp8266 AT firmware which allows esp8266 to be controlled using AT commands on the serial port.

By default the module comes in AP mode which means that it will show up as an Wifi access point that you can connect to. I wasn’t really interested in that so I reconfigured it to connect as a client to my main wifi network.
To reconfigure ESP8266 you have to connect UART over the 4 pins between the screw terminals using an USB to UART TTL cable like this:

I just happened to have the 5V power supply also connected but it’s not really required at this step, just for reconfiguring power from USB should be enough.

This can be done like this:

$picocom -b 115200 --omap crcrlf /dev/ttyUSB5

After this, communications will switch from 115200 to 9600 baud so you will lose the link and would need to switch picocom to 9600 baud to do anything further. But anything else isn’t really required anyway for our simple use case, so just disconnect picocom with CTRL+A CTRL+X.

AT+CIFSR command should have printed out what is the IP of the module. In my case it looked like this:


Now you can just create a TCP connection to that IP at port 8080 and send the relay commands that I mentioned before. ESP8266 will pass these to the STC 15f104W MCU which in turn will control the relay.

As an example here’s a trivial python script that will connect to the relay and turn the relay on and off in an endless loop in 4s intervals:

import sys
import time
import socket
IP = ""
PORT = 8080
RELAY_OPEN_CMD = "\xa0\x01\x01\xa2"
RELAY_CLOSE_CMD = "\xa0\x01\x00\xa1"
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((IP, PORT))
while 1:

And here’s how the result looks like:

fixing the temperature sensor

As mentioned in my last post about cheap Chinese wireless temperature/humidity sensors, one of the three devices that I ordered was broken. It did show correct values on the local screen but no messages were seen over the radio link.

I decided to open it up to see if there’s anything obviously wrong inside. Here’s how the internals looked like:
insides of the temperature sensors

The 2 working sensors both had the blue radio module shown on the left and the non-working sensor had the white module shown on the right. Since I had RTL-SDR I decided to see if the broken module sends out any signal at all. I found a very detailed blog post describing the steps for doing it.

Here’s what my signals looked like:
sensor signals

The topmost signal is from the broken radio module as measured ~30cm from the antenna. The next one is the signal from the replacement radio module from the same distance and the last 2 signals are from the two other sensors which were located much further from the antenna.

As we can see the broken signal is rather unstable and can’t hold stable high.
It looks even more interesting when zoomed in:
sensor signals zoomed

Here’s how the sensor looks with the replacement radio module:

The fixed sensor works rather well, the signal is clear from ~20m away through 2 concrete floors.

cheap temperature sensors

I was kind of missing the fun temperature charts that I had at my previous home so I decided to get some sensors for the new house too. Using 1-wire network like I did previously didn’t seem reasonable this time around since my current house has 3 floors and cabling it in a way that wouldn’t be ugly would have taken too much effort.

So instead I decided to find some cheap wireless temperature sensors. It turns out you can get a reasonably looking temperature+humidity sensor with a local display and 433 Mhz radio for just 7€ a piece (with free shipping). You can also buy these sensors in a cheap kit with a central screen that shows values from all the senors plus some additional stuff like clock and sunrise times.

I wasn’t really interested in the central screen, so I just bought 3 sensors.
433Mhz temperature sensors

These sensors display humidity and temperature values on the screen and send out these measurements once a minute. When the sensor sends the message it blinks the red led in the front panel which might be a bit annoying if you place it somewhere where you can see it at night. I would probably tape it over or solder it off under these circumstances.
A switch inside the battery compartment allows you to select the channel which makes it possible to differentiate one sensor from another. The switch has 3 positions so it seems that with the normal central screen you are probably limited to 3 sensors. Technically this channel just changes a value in the message so it’s not a radio channel or something like that.

From the protocol perspective there’s also a 8 bit field called random id(rid) which is initialized when the sensor starts. Using the rid field alone or in conjunction with the channel value allows you to use far more sensors than 3. Since rid isn’t under your direct control it might take a bit of fiddling to find a free ID with a larger number of sensors and at some point you will probably have too many collisions in the air but I imagine using 10-20 of these sensors wouldn’t be a problem.

Since I didn’t buy the central screen I still needed a way to actually listen for the measurements that these sensors broadcast. It turns out cheap RTLSDR compatible DVB-T receivers can be used for that purpose with the RTL 433 application.
So I bought the receiver USB dongle with an external antenna and remote from ebay for ~10€.
rtlsdr dongle with antenna

Once RTL 433 is installed all you need to do to listen for the measurements is to run the rtl_433 command:

# rtl_433 -R 3 -F json
{"time" : "2016-02-13 23:10:19", "model" : "Prologue sensor", "id" : 5, "rid" : 55, "channel" : 2, "battery" : "OK", "button" : 0, "temperature_C" : 10.000000, "humidity" : 52}
{"time" : "2016-02-13 23:10:24", "model" : "Prologue sensor", "id" : 5, "rid" : 170, "channel" : 3, "battery" : "OK", "button" : 0, "temperature_C" : 23.400000, "humidity" : 29}
{"time" : "2016-02-13 23:10:33", "model" : "Prologue sensor", "id" : 5, "rid" : 51, "channel" : 1, "battery" : "OK", "button" : 0, "temperature_C" : 19.800000, "humidity" : 39}

This output can be easily interfaced to whatever system you use for home automation. My graphs look like this:
temperature on floor 2

My receiver is located on the second floor and the furthest sensor is about 20 meters away through 2 concrete floors and there don’t seem to be any communication problems so far.

One of the sensors came with a faulty radio that I had to replace, but more on that in a separate posting later.

quick and cheap RFID with RPi and rc522

To my great surprise it turns out you can nowadays get an RFID reader with 2 tags for somewhere between 7$ and 10$. Better yet, interfacing these to Arduino is well documented and several libraries are available for that purpose.

My friend who bought a couple of these asked me to see if I can read the tags directly from a Linux based ARM board (for example Raspberry Pi). It turned out to be rather easy as long as you aren’t interested in anything but the ID of the card. This can be done using rpi-rc522 library (NOT written by me). It sadly currently lacks any documentation or a Makefile so here are my notes on how to get it running.

First you have to connect the rc522 and RPi over the SPI interface. It will look something like this:

Raspberry pi and rc522 RFID reader

Raspberry Pi and rc522 RFID reader

Then you have to install the bcm2835 library. Assuming that you have gcc and other essential development stuff already installed you can achieve it this way:

tar -zxf bcm2835-1.35.tar.gz
cd bcm2835-1.35
sudo make install

After that you can compile and run the rpi-rc522 with the following commands:

sudo apt-get install subversion
svn checkout rpi-rc522-read-only
cd rpi-rc522-read-only/rc522
gcc config.c rfid.c rc522.c main.c -o rc522_reader -lbcm2835
sudo cp RC522.conf /etc/
./rc522_reader -d

You should see tag IDs in the output of the program as they are read. You can put these into the /etc/RC522.conf file and map each ID to a specific command to run there.

measuring power usage

Today I discovered that the ethernet port on my beaglebone white that I used as a home automation controller had died. Luckily I had a new beaglebone black at hand. Since several people have asked about my automation stuff I decided to take a couple of pictures while replacing the controller.

In general my breaker box looks like this:
breaker box

The energy meter in the top left corner is mine so I could just connect beaglebone to its counter pins directly instead of reading it from the IR diode. Beaglebone black is the thing with blue leds in the bottom left side of the picture. The energy meter basically has a switch that “connects” the attached wires 1000 times for every kWh consumed. So measuring the energy usage is just a simple matter of configuring one of the beaglebone’s IO pins for input and poll()’ing for the changes.


The protoboard + arduino combo to the left of the beaglebone is used for listening in on my house alarm system bus (DSC 5010). I haven’t yet reconnected it. To the right of the beaglebone you can see the cable modem that I use to connect this thing to the router on the second floor. Wifi would have been easier but doesn’t work well in the basement, coaxial cables happened to be present and I got some old cable modems for free.

Beaglebone also serves a simple web frontend with statistics for all the sensor feeds that it records. For example the energy usage overview looks like this:
energy usage

I currently use PostgreSQL as my data store and I have been seriously impressed with its ability to run on such a weak hardware. When I was using beaglebone white that only had 256MB of RAM, with class 4 SD card I actually only used raw measurements table that stored data for all my datasources with 1 minute precision. This table had 2.5 million rows and still managed to answer complex aggregate queries for energy usage (N last days, group by day and each day by day and night) in about 5 seconds. Now that I have added hourly aggregated table it’s back to about 0.1s.

I also moved to a newer kernel (3.8.13) where the old omap_mux sysfs hierarchy is gone so it took me a bit of time to find how to configure the pins under the new world order.
It turns out to be rather logical (besides the pin numbering part :-P) so in order to configure pin 12 on P9 header as an input I had to do this:

echo 60 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio60/direction
echo falling > /sys/class/gpio/gpio60/edge

adding networking to your projects

If you want to add ethernet networking to your Arduino based project following are the conventional solutions:

One of the problems with these options is that they don’t support DHCP so you have to hardcode your IP address in the firmware. Besides they seem to cost too much – for this kind of money it would be cheaper to get wireless shields.

One alternative that I have come accros is to use self contained ethernet to serial bridges, while these might not be any cheaper from the previously mentioned options, they are more powerful.
These modules are not much larger than the RJ45 socket itself and are extremelly easy to interface to any controller. Support exists for TCP, UDP, DHCP, SNMP, AES encryption and you can actually configure it to send e-mail when IO pin is triggered so for some extremelly simple applications you might be able to avoid the controller alltogether. What I’m talking about is the XPort from Lantronix.

lantronix xport

I happen to have one laying around since we used this in one of the projects many years ago. Nowadays I think you should be able to get one for ~30€ if you search long enough. There’s also a newer generation available called XPort PRO that has full linux running inside of it which allows you to do far more but costs far too much for me (~60€).

There’s also a cheaper and very powerful alternative from Digi called Digi Connect ME 9210 with full Linux running inside it (39€). It has more pins and you should be able to do things like bridging 1-wire sensor network to ethernet without any external controller. I have no experiences with that device though and haven’t found any useful discussions about it so far.

So anyway to get the XPort up and running you first have to give it an IP address. There are basically 2 ways of doing this – either with DHCP (the easy method) or over serial.

Since I wanted to learn a bit about using my Bus Pirate I used it to communicate with the serial port and verify that I can actually enter the serial setup if I wanted to.

Here’s how I connected the XPort and Bus Pirate:

Bus Pirate XPort
+3.3V 2

Here’s how it looks like:
xport and bus pirate

To enter the serial setup you would have to do something like this:

$ picocom -b 115200 -p n -d 8 /dev/ttyUSB0
picocom v1.4
port is        : /dev/ttyUSB0
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
escape is      : C-a
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : ascii_xfr -s -v -l10
receive_cmd is : rz -vv
Terminal ready
Set serial port speed: (bps)
 1. 300
 2. 1200
 3. 2400
 4. 4800
 5. 9600
 6. 19200
 7. 38400
 8. 57600
 9. 115200
10. BRG raw value
Adjust your terminal
Space to continue
Thanks for using picocom
$ picocom -b 9600 -p n -d 8 /dev/ttyUSB0
picocom v1.4
port is        : /dev/ttyUSB0
flowcontrol    : none
baudrate is    : 9600
parity is      : none
databits are   : 8
escape is      : C-a
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : ascii_xfr -s -v -l10
receive_cmd is : rz -vv
Terminal ready
1. HiZ
2. 1-WIRE
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
9. DIO
x. exit(without change)
Set serial port speed: (bps)
 1. 300
 2. 1200
 3. 2400
 4. 4800
 5. 9600
 6. 19200
 7. 38400
 8. 57600
 9. 115200
10. BRG raw value
Data bits and parity:
 1. 8, NONE *default
 2. 8, EVEN
 3. 8, ODD
 4. 9, NONE
Stop bits:
 1. 1 *default
 2. 2
Receive polarity:
 1. Idle 1 *default
 2. Idle 0
Select output type:
 1. Open drain (H=Hi-Z, L=GND)
 2. Normal (H=3.3V, L=GND)
UART>W%:1000 0x78:100 %:100 0x0D 0x0A (2)
Power supplies ON
DELAY 1000ms
WRITE: 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78
DELAY 100ms
Raw UART input
Any key to exit
*** basic parameters
Hardware: Ethernet TPI
IP addr -, no gateway set
DHCP device name : not set
*** Security
SNMP is              enabled
SNMP Community Name: public
Telnet Setup is      enabled
TFTP Download is     enabled
Port 77FEh is        enabled
Web Server is        enabled
Web Setup is         enabled
ECHO is              disabled
Encryption is        disabled
Enhanced Password is disabled
Port 77F0h is        enabled
*** Channel 1
Baudrate 9600, I/F Mode 4C, Flow 00
Port 10001
Connect Mode : C0
Send '+++' in Modem Mode enabled
Auto increment source port disabled
Remote IP Adr: --- none ---, Port 00000
Disconn Mode : 00
Flush   Mode : 00
*** Expert
TCP Keepalive    : 45s
ARP cache timeout: 600s
High CPU performance: disabled
Monitor Mode @ bootup : enabled
HTTP Port Number : 80
SMTP Port Number : 25
MTU Size: 1400
Alternate MAC: disabled
Ethernet connection type: auto-negotiate
*** E-mail
Mail server:
Unit       :
Domain     :
Recipient 1:
Recipient 2: 
- Trigger 1
Serial trigger input: disabled
  Channel: 1
  Match: 00,00
Trigger input1: X
Trigger input2: X
Trigger input3: X
Message :
Priority: L
Min. notification interval: 1 s
Re-notification interval  : 0 s
- Trigger 2
Serial trigger input: disabled
  Channel: 1
  Match: 00,00
Trigger input1: X
Trigger input2: X
Trigger input3: X
Message :
Priority: L
Min. notification interval: 1 s
Re-notification interval  : 0 s
- Trigger 3
Serial trigger input: disabled
  Channel: 1
  Match: 00,00
Trigger input1: X
Trigger input2: X
Trigger input3: X
Message :
Priority: L
Min. notification interval: 1 s
Re-notification interval  : 0 s
Change Setup:
  0 Server
  1 Channel 1
  3 E-mail
  5 Expert
  6 Security
  7 Defaults
  8 Exit without save
  9 Save and exit            Your choice ?

At this point you could go on configuring the device over the serial connection but it’s a bit incovenient so I just gave it an IP with DHCP and used the web interface for configuring.

lantronics: channel connection

So with this configuration the XPort will connect to TCP port 12345 on right after restart and we can use this channel to talk over serial port.
To test it let’s bind netcat on the

$ nc -l 12345

And from the bus pirate shell we have to exit the monitor mode, reset the device and enter the serial bridge mode:

Power supplies OFF
Power supplies ON
UART bridge
Reset to exit
Are you sure? y

You should now see test on the netcat shell and anything that wou write into the netcat session should show up on the buspirate shell.

weather station

I’m slowly expanding my home automation systems and the latest addition to that is this weather station.


The large rectangular thing in the lowest position on the antenna pole is a WIFI panel antenna.

I decided to add the weather station primarily in order to measure wind speeds so that my scripts would be able to make better decisions about closing and opening the greenhouse windows. I’m not so much worried about keeping optimal temperature in there but rather about making sure that the windows won’t get ripped off on a windy day. Another good reason is that I just like to have a lot of data and nice graphs 🙂

I wanted a relatively cheap and open weather station that I could integrate into my setup without too much effort. The closest match seemed to be this one that is sold by Sparkfun. It has an anemometer, wind vane and rain gauge. Interfacing it with a microcontroller is very simple since the wind speed and rain gauge are just Reed switches and the wind vane changes resistance. The only external component that you need is a 10k ohm resistor for the wind vane and of course some kind of microcontroller to take the measurements.

I ordered mine for 60€ from Watterott electronics which is a German shop that sells a lot of Sparkfun stuff among other things.

I hooked it up to an Arduino Uno using a small library that I wrote and connected that in turn over a USB cable to a beagleboard that serves as a controller for my home automation stuff.


The small red board on this picture is a BMP085 barometric pressure sensor.

In general the weather station seems to work well enough. I’m not entirelly sure about the correctness of the measurements from the rain gauge since I see some rain measurements even though it has been constantly below -20 degs celcius here which obviously rules out rain. Here’s what the rain gauge looks like:


Inside you will find a seesaw with 2 buckets with a magnet in the pivot that triggers contact in the Reed switch every time the equilibrium position is changed.

While the design of the rain gauge is beautiful in its simplicity it doesn’t seem to be very precise. For example sometimes the other end will bounce right back after emptying and I have no theory yet about the reason behind the random small measurements that I currently get from it.

Anyway, here’s some real time wind information from my weather station through and pachube: