To produce a dvd out of a mpeg-ts file we need:

• Project-X: Cut and demux videos
• mplex from the MJPEG Tools: Remux videos
• dvdauthor: create a video-dvd file structure
• growisofs from the DVD+RW package: Create an iso image or burn directly to disk

In Ubuntu you can install them by typing:

sudo apt-get install project-x dvdauthor mjpegtools growisofs

Dvdauthor demands to know the video format, so type

echo "PAL" > ~/.config/video_format

(replace PAL with NTSC if living in the USA or another NTSC-country)

Now you should have everything you need. Copy the makefile to the same folder you downloaded the ts-file(assuming, for simplicity, it’s named sample.ts) to. Now, to just burn it to dvd, one title, no menu, conserving all audio tracks, do

make sample.burn

The advantage of using a Makefile is that you can do each step manually. You can for example cut and demux the files with project-x by hand, or just produce the .mpg files, then use dvdstyler to create a complex menu and burn the dvd.

all:$(patsubst %.ts,%.dvd,$(wildcard *.ts))

MPLEX=mplex
MPLEXFLAGS=-f 8
DVDAUTHOR=dvdauthor
PROJECTX=projectx

DREAMBOX_BASEURL=root:dreambox@192.168.178.22/hdd/movie
.PRECIOUS: %.m2v %.ts %.mpg %.dvd

%.ts:
	wget ftp://$(DREAMBOX_BASEURL)/$@

%_proc.m2v: %.ts
	$(PROJECTX) -out . -name $*_proc $<

%.mpg: %_proc.m2v
	-rm $*_proc*.txt
	$(MPLEX) $(MPLEXFLAGS) -o $@ $*_proc*
	-rm $*_proc*

%.xml: %.mpg
	echo "<dvdauthor><vmgm /><titleset><titles><pgc><vob file=\"$<\" /></pgc></titles></titleset></dvdauthor>" > $*.xml

%.dvd: %.xml
	$(DVDAUTHOR) -x $*.xml -o $@ 

%.burn: %.dvd
	growisofs -Z /dev/dvd -dvd-video -V $* $</

Makefile-movies

There were other problems: readesm was using custom Makefiles, which apparently made compiling the source difficult. I was amazed to discover this wiki entry for fahrlinx, which contained information on how to install the windows version of readesm using wine. As the windows version at that time was cross-compiled in linux and lacked some features, readesm was clearly too difficult to compile.

In readesm versions since march 2011, both problems are solved. Readesm now uses cmake for the build process, and Qt to display the generated html pages in a webkit browser.

Idea

The idea behind readesm is to show you exactly what is in the tachograph file.

Using readesm

Usually you will either associate readesm with a file extension, and have your file manager open readesm for you. Or you can open a file from readesm’s menu.
Alternatively you can use the command line:

readesm tachofile.ddd

will open the file in the gui, and

readesm tachofile.ddd tachofile.html

will convert the file into html format and save it as tachofile.html.

Screenshots

Free software toolchain for tachographs

With readesm, fahrlinx and loadvu, a linux laptop can now connect to vehicle units, read out driver cards and visualize the contents of the files.

To install all three programs in ubuntu:

sudo apt-add-repository ppa:k-2005
sudo apt-get update
sudo apt-get install readesm fahrlinx loadvu

It’s a bit more difficult in Windows, but should be possible nevertheless.

Download readesm

Download the latest files from the project page at sourceforge.

• Use the windows-installer (readesm-XX-win32.exe) to install. The latest version should also associate tachograph files with itself.
• If you cannot or do not want to install readesm, use readesm-XX-win32.zip
• Ubuntu users should either use my ppa or compile from source.
• Users of 64 bit windows might be able to run the 32 bit windows version. Unfortunately, I do not have access to a single 64 bit windows pc.
• For other operating systems, download one of the source packages and compile it yourself.

Without dedicated hardware, this was so far not easily possible in linux, but my python script should make it possible to download the data with a serial cable with the right connector.

Ubuntu package

Ubuntu packages are available in my ppa. You can add my ppa with

sudo apt-add-repository ppa:k-2005

and then install loadVu with

sudo apt-get install loadvu

Usage

Start the program with

./loadvu

The data will be saved to a file named after the vehicle and date.
If your serial connection is not /dev/ttyUSB0, you should specify it with the –serial parameter. A possible call would be

./loadvu --serial /dev/ttyUSB1

Extra transfer response parameters

While the commision regulation 1360/2002 defines TREPs 1 to 6

At least the digital tachographs from Siemens VDO return data on other requests, too. For example Daimler’s TCO-DKG program requests 17,19 and 20 and saves those to an .add file. The vu also returns data requesting trtp 18. To mimic the behaviour of tco-dkg, type

./loadvu --treps 2,3,4,5 -o mycar.esm
./loadvu --treps 17,19,20 -o mycar.add

Download of card data

It is possible to download the data stored in a driver card inserted into the vehicle unit. However, in the current version the script will add vehicle data to the file, so few programs will be able to read it. The current svn of readesm can, but the last release cannot.

./loadvu --treps 6 -o card.esm

Future versions might handle this with more elegance.

Download Speed

With a digital tachograph from 2007, loadvu tells:

$ ./loadvu
Sending 'Request Start Communication Request'
Got the expected response
Sending 'Request Diagnostic Session'
Got the expected response
Sending 'Request Request Byte rate 115200'
Got the expected response
[...]
Sending 'Request Stop Communication'
Got the expected response
data saved to UL-XX YYY 2010-11-09 to 2011-11-18 21.54 (CET).esm
Got 222772 Byte in 1789.75275612 seconds. (124.470823827 Byte/s)

It’s slow. Really slow. Considering how many trucks there are, also expensively slow. And it’s not just this script, it’s that slow with any program. Why? Hard to tell. The transfer is slowest when transferring daily activities, where many cryptographic signatures are transferred. However, there is no technical reason why these would have to be generated at every download, as the data really should not change once written.

Enjoy the script.

loadvu-2011.11.tar.gz

For these cases I found this little bash snippet useful:

ls -tr | tail -n 1 | xargs -I FILE kde-open "FILE"

Instead of kde-open, which opens any file with the associated program, you can use any program, gnome-users might want gnome-open, people with other window managers can use xdg-open from xdg-utils. Or you can just insert mplayer, if you are only interested in music and videos.

I prefer it installed somewhere in the path, and then one can add a command-line parameter, the number of files to be played:

#!/bin/sh
ls -tr | tail -n ${1:-1} | xargs -I FF kde-open "FF"

playlast

RC Servos are popular among modelling and robotics enthusiasts because of their simplicity. They take a pulsewidth-encoded input, and turn accordingly with relatively high torque. They have their disadvantages, for example one cannot tell if the servo was able to get where it was sent, but their low price and the fact that driver and gear box are integrated make up for that. Also, Conrad sells them for 3 € a piece, so I bought some.

My first idea was to control them with firmware-usb, however, the high load imposed on the controller by usb makes software-pwm erratic, and also, implementing the usb communicating device class is not possible for low-speed devices.

The servo controller prototype together with one regular sized RC servo, and one miniservo

The path I followed that resulted in the servo controller pictured above was, to use an FT232R usb-to-uart converter and an Attiny 2313a microcontroller to provide the software pwm. There are some other possibilities, like taking an at90usb or another microcontroller with usb, but FTDI has nice chips, good support, and one can get usb pids from them, and remans flexible. If 12 servos are not enough, the software should easily be portable to a bigger avr, the chips are widely avalable and low in cost: I got the attiny for about 1 € and the FT232RL for about 2.5 € at CSD.

The full schematic is available as pdf and in the kicad format, and so is the pcb layout. Feel free to rebuild it.

This was my first project using kicad and my first project using surface mounted technology, and surprisingly both made few problems. Even soldering the tqfp-sized FT232RL without solder resist worked well, though i needed lots of light and a good magnifying glass.

The copper side of the assembled pcb, showing the results of my subpar soldering skills

Hardware

You will need:

• One FT232RL USB-to-UART convertor
• One Attiny 2313a (or the older, nrfnd, attiny2313) avr microprocessor.
• An USB B-type connector
• A 6-pin connector for your AVR-ISP programmer.
• Connectors for the servos. I used simple multi-pin connectors and some colored insulating tape to mark plus, minus and signal.
• A connector for your power supply.
• An optional jumper to power the servos from usb. Since the device does not ask the usb host for more power, this is outside the usb specifications. however, with small miniservos it is convenient, as you do not need an extra power supply.
• One 4.7 µF electrolyte capacitor
• Three SMD 100 nF ceramic capacitors and two 10 kOhm resistors. The plan calls for size 0603, but the resistors I used were actually 0805, and fitted also well.
• A printed circuit board. With the right equipment, you can make this yourself. Or you can have one made for you at various companies

All the parts together cost about 5 € (with a self-made pcb).

Software

The software provides a rather minimalistic interface. To send commands, open the serial port at 9600 baud, using your favorite terminal program, I used gtkterm.

The available commands are:

• Typing v shows the device name, a link here, and the software version.
• Typing l lists the servo numbers and the corresponding pwm settings. The pwm settings are the number of cpu cycles the servo should get a high signal level.
• Typing d shows the softpwm table, a list of when which signals should go from high to low. This list is calculated from the pwm settings, it’s mainly there for debugging purposes.
• Typing s (servonumber) (new value) sets the pwm value for the selected servo. Be sure to send a newline character or other whitespace to execute the command.

Since RC servos typically want a 1 ms pulse (at 8 MHz this are 8000 cpu cycles) for one end, and a 2 ms pulse (similarly, at 8 MHz this are 16000 cpu cycles) for the other end, you would in linux do something like

stty -F /dev/ttyUSB0 9600
echo "s 11 8000 " > /dev/ttyUSB0
echo "s 10 16000 " > /dev/ttyUSB0

to send servo 11 to one end and servo 10 to the other. If you have other serial devices, the device might not be /dev/ttyUSB0, but /dev/ttyUSB1 or so. Should this be a problem, you can create a udev rule to create a symlink. Note that the actual pulse lengths required to go to the mechanical end of the servo differ widely between servo types, I do not know if there is some standard, if you do, please tell me.

A QT frontend to turn servos by turning dials

For some cases, like finding the end positions of the rc servos, it is convenient to have a graphical user interface, which is also available.

Usage with embedded linux devices

In most households, many devices run linux and have an usbport. however, without a modified firmware most cannot connect to serial usb devices. I tested a fritzbox 7270 (possible with alternative firmware freetz, not with the original firmware), a dreambox dm 7000(no success, and alternative firmwares are lost in the mists of time), and an Asus oplay hdp-r1(also no success, and alternative firmwares seem to be not yet available). So, unless you have a device that runs openwrt by default, chances are this won’t work without some work.

List of things still to do

• As seen on the pictures, the avr isp connector is slightly too large, so either a smaller one has to be used, or only 8 servo connectors have place. For testing purposes, this was enough, but a new hardware revsion is necessary.

usbservo_hardware.tar.gz

usbservo_software.tar.bz2

qusbservoc.tar.gz

usbservo_schematic.pdf

usbservo_pcb.pdf

ytplay wraps around youtube-dl.py, it searches for a video, orders youtube-dl to get it, and starts playing it in vlc.

Usage is simple:
> ytplay foobar
will search youtube for videos about foobar and play the first one found.

The code is still quite dirty, especially the subprocess part. However, it should work, have fun!

#!/usr/bin/python
# -*- coding: utf-8 -*-
#		parser.add_option('-P', '--play', action='store_true',
#				dest='play', help='play in vlc', default=False)

from optparse import OptionParser
from subprocess import Popen, PIPE
from urllib2 import urlopen 
from urllib import quote_plus
from re import search, match
from os import system

parser = OptionParser(version='2010.02.13')

parser.add_option('-p', '--player',
dest='player', metavar='PROGRAM', help='media player to use', default='vlc')

(opts, args) = parser.parse_args()

if match("http://",args[0]):
	videopageurl = args[0]
else:
	searchargs = '+'.join(args)
	searchurl = "http://www.youtube.com/results?search_type=&aq=f&oq=&search_query=" + quote_plus(searchargs)
	searchresult = urlopen(searchurl).read()
	p=search(r'(watch\?[^"]*)',searchresult)
	if p==None:
		print "No Videos found"
		exit()
	videopageurl="http://www.youtube.com/" + p.group(1)
	

print "Starting youtube-dl for " + videopageurl
ytdl = Popen("youtube-dl.py -t -b " + videopageurl,shell=True,stdout=PIPE)

while not ytdl.stdout.closed:
	line = ytdl.stdout.readline()
	print line,
	if line == '': exit()
	p = search(r'\[download\] Destination: (\S*)',line)
	if p != None:
		print "Starting player: " + opts.player + " " + p.group(1)
		system(opts.player + " " + p.group(1) + " &")

ytplay

And that is basically everything to say, enjoy the little applet.

Installation

Make sure gpsd is installed and set up properly. Also make sure the python bindings are installed.
In Ubuntu you would need to:

sudo apt-get install gpsd python-gps
sudo dpkg-reconfigure gpsd
sudo apt-get install python-plasma python-dev

After those are installed, you can proceed to install the plasmoid with plasmapkg -i.

Problems and TODOs

This is all rather dirty and bloated. The correct way to do it would probably be to write a data engine for plasma, which would provide the positional data. Maybe someone will do it, especially if Marble will one day be able to support overlays integrate GeoClue or something similar.

Right now the data travels from the GPS device to the PC in the form of NMEA sentences, gets then converted into gpsd’s own format, python-gps connects to gpsd over TCP port 2947, interprets the gpsd output, hands it over to the applet, which reformats the data yet again. For something so useless that just wastes too many CPU cycles. Interpreting GPS data entirely in python is not hard, but still a bit harder than with gpsd, especially if one wants to cover a lot of GPS devices. Don’t get me wrong, gpsd does its job quite well, it is just a bit overkill for this task.

Another improvement would be readable coordinates. Something like “10 km northwest of Zürich” or even “200 meters south of Sternen Oerlikon, Zürich” would really be much more useful.

Update February 2010: Version 0.16 now uses KDE’s geolocation data engine. This drops the (direct) dependency on gpsd, and allows for ip-based location – unfortunately i now can no longer get my gps to work with it, hoping for kubuntu lucid.

gps-plasmoid_0.16.plasmoid

gps-plasmoid_0.15.plasmoid

One solution, if you don’t have enough IO ports to spare, is to use another Display, like serial cellphone displays, which are cheap and color is a great thing to show off. Or you can expand the number of IO lines by using a shift register or TWI device. This is one such implementation using a 74hc164 shift register. It is based on an implementation by Peter Dannegger. If you prefer to use a 4094 cmos shift register, there are also schematics floating around the net.

The idea behind this implementation is to fill the shift register from the microcontroller using hard- or softspi, then toggle the hd44780′s enable pin. While toggling, the data pin determines the R/S state of the display.

The demo software will print a hello world message onto the display, it is written for AVR microcontrollers, it should work – after modifying the ports and pin numbers – on almost any AVR. Peter Daneggers original software is written for 8051 µCs, I don’t know of any code for PICs.

lcd.tar.bz2

lcdshift.pdf

lcdshift.sch

lcdshift.brd

Update, March 2011: There is a new release of readesm, The description provided here no longer applies, the new readesm uses Qt and cmake. You can get the new release at the sourceforge project page and read the documentation here.

For several years now, new trucks sold in the European union are equipped with digital tachographs, that record the driving times and replace the older chart-based mechanical tachographs.

For companies in road transport that means, although in theory they get nice data about their drivers and vehicles, in practice they have to pay a lot of money for the digital tachograph and the associated equipment, which is then used against them – the old fraud schemes no longer work, the machine cruelly gives every police officer the driving times of the last 28 days (and could give much more).

The usability of the devices I’m familiar with is also abysmal. It just takes forever to read out the data (9600 baud per default, 115000 baud maximal, but i guess the company’s software does just the former), and the drivers have to keep track of their times manually – just not up to par with 2009 technology.

The company also had just a very bad software for analyzing the data recorded by the card and the digital tachograph, so I was asked to write a simple visualization program.

Compiling

You can get the program files from this page, or from the development page at Sourceforge.
Since so far there is no binary distribution for the program, you will have to compile it yourself.
To do that, you need a c++ compiler, parts of the boost library (specifically program_options and shared_ptr) and the Gnu MP library, wich is used to check the various RSA signatures. Once all those are installed, typing make/make install should work fine. On Ubuntu systems, you will need to do something like:

svn co https://readesm.svn.sourceforge.net/svnroot/readesm readesm
sudo apt-get install libboost-program-options-dev libgmpxx4ldbl  libgmp3-dev
make
sudo make install

You can of course also use checkinstall instead of make install, or type make package, which invokes checkinstall.

Running the program

In most circumstances, you will run the program from the commandline like this:

readesm --infile foo.esm --outfile bar.html --format=html

Alternatively, if no output file is specified, stdout is used. For KDE users, i wrote a little wrapper script named readesm-wrap-kde.sh. It will get installed my typing make install

Security

It is a really pleasant surprise to see a nice security model in the digital tachographs, considering the rules for the security implementations were made by politicians. Both cards and vehicle units work with 1024-bit RSA keys, and each vehicle unit has its own key, with an certificate signed by the member state, which in turn is signed by an European master key. Data is hashed with SHA-1, subsequently padded and signed by the vehicle unit, and that signature appended to the readouts. The law even states that the companies have to store the data in this signed form, so there is little chance to tamper with the data, once recorded.

Since the most likely attacker – the evil manager who wants to exploit the drivers – has physical access to the card and vehicle unit, which contain the private keys, even 1024-bit RSA provides no absolute security. The manager could try a timing attack, or take a really close look at the storage, both times avoiding having to solve the RSA problem.

The connection from tachograph to sensor is also secured, using Triple-DES. The week point here is the sensor – a successful attack against the sensors some DAF trucks are equipped with is to disturb it using strong permanent magnets, thereby preventing it from recognizing the changing magnetic fields.

All possible attacks against the security system however face the problem of being unveiled by police checkpoints or a cross-correlation of the faked data with data from other sources, for example the toll systems recording every few highway kilometers in Germany.

error, cannot open image photos/screenshots/readesm/2011.11.

readesm.tar.bz2

What does it do? Nothing useful. You plug it in, and the various LEDs blink wildly, one letter at a time, two letters at a time, all on, all off.

I’m not particularly proud of this board. The matrix design is just painful to route on an one-sided PCB, so please don’t do it, especially if you plan on doing something similar with more than three letters. I’d like to use something like the AS 1110 for something similar, but there are just no distributors for those chips.

Nevertheless, if you know someone named Eva who likes to solder a bit or who just likes blinking things, this might be a nice present.

Things to take care of:

• Energy source: I used some old wall wart for this. The used 7805 is quite robust, but not very efficient. Use something between around 8 V to 15 V, and check the polarity, which is unfortunately not standardized.
• Since the LEDs are driven only 1/4th of the time, you can in theory use higher currents than if driven all the time.

blinking-eva/blinking-eva-board.pdf

blinking-eva/eagle-files.tar.bz2

blinking-eva/firmware.tar.bz2

blinking-eva/manual-german.pdf