SheevaPlug nun auch in Europa

Das SheevaPlug ist einfach gesagt ein Linux-Computer im „Steckernetzteil-Format“. Im Inneren werkelt eine 1,2 GHz ARM CPU mit 512MB RAM, 512MB Flash, USB 2.0 Anschluss, Ethernet und einem SD-Kartenleser. Das Ganze gibt es nun für 99,95EUR bei PlugComputer.eu auch in Europa.

Ich hatte das Vergnügen, den SheevaPlug bereits beim Bausteln oder auf dem 26C3 in Aktion zu sehen. Das kleine Kästchen eignet sich eigentlich für alle Serveranwendungen, die auf einen Monitor verzichten können. Von vielen wird der SheevaPlug bereits als „NSLU-2 Killer“, also als Fileserver mit externer Festplatte, gehandelt.

Ein HA-Cluster aus SheevaPlugs wäre doch mal ein interessantes Projekt.

Eine erste deutschsprachige Seite mit Projekten  rund um den Stecker findet man übrigens unter sheevaplug.de.

 

Gumstix bestellt und schon fast da

Ich hatte ja bereits über die Gumstix Platform berichtet. Gestern nun habe ich ein Overo Air Board nebst IO-Board und Touch Display bestellt. Die Versnadkosten nach Deutschland beginnen bei $43. Für 50$ bekommt man die Super-High-Speed Variante. Da der Unterschied nicht so gewaltig ist, hab ich mich dafür entschieden. Es hat keine 15 Minuten gedauert und ich bekam die Versandbestätigung. Mittlerweile (nicht einmal einen Tag später und am Samstag!) ist die Lieferung bereits in Deutschland und vom Zoll freigegeben. Faszinierend, wie schnell so etwas gehen kann (auch wenn es bei UPS heisst: „Ausnahme – Pünktlich“).

Weiteres an dieser Stelle in Kürze…

 

Auf der Suche nach einem Grundsystem für die Open Capture Platform

Wenn man eine Plattform wie die von mir beschriebene Open Capture Platform schaffen möchte, benötigt man zunächst ein Grundsystem. Damit meine ich Prozessor, Speicher und was dazu gehört. Hier kann man entweder komplett bei Null beginnen oder schauen, ob es bereits fertige Komponenten gibt.

Zunächst stellt sich jedoch eine ganz andere Frage. Wie viel „Power“ braucht man? Was soll darauf laufen? Reicht es einen eigenen kleinen Kern zu schreiben oder nimmt man ein Vollständiges Betriebssystem wie Linux oder Windows CE/Embedded? Auch Android könnte eine interessante Alternative sein. Der Vorteil der Betriebssysteme ist, dass man schon vieles fertig bekommt. Möchte man später z.B. eine Datenbank auf dem Gerät am Laufen haben, bietet sich Linux an, für das es ja viele fertige Lösungen gibt.

Ich möchte zunächst ein fertiges System mit Linux oder vielleicht Android probieren. Es gibt mittlerweile viele fertigen Systeme, die auf der ARM-Platform basieren und mit Linux betrieben werden können. Warum sollte man also hier etwas neues kreieren? Schon vor Jahren habe ich ein wenig mit der Gumstix Plattform herumgespielt. Ich fand es damals schon faszinierend, wie man ein komplettes System auf einem so kleinen „Kaugummi“ unterbringen kann. Nun gibt es seit kurzer Zeit die neue Overo-Linie, die sogar schon WiFi und Bluetooth mitbringt. Die technischen Daten sind vielversprechend. Die Boards sind nicht grösser als eine AA Batterie. Darüber hinaus sind die Schaltpläne unter der CC Lizenz erhältlich. Es gibt bereits fertige Boards und ein nettes 4,3″ Display mit Touch-Unterstützung.

Was mich bei den neuen Overo-Boards am Meisten interessiert ist der Strombedarf mit Display, WiFi oder Bluetooth. Entsprechende Daten sind schwer zu finden. Um dieses herauszufinden und zu sehen, ob dies ein guter oder schlechter Kandidat für das Basissystem darstellt, werde ich mir so ein System bestellen und berichten.

 

Idea for an open platform for mobile ID capturing

Idea for an open platform for mobile ID capturing

In my dayjob I’m working a lot with identification and access control on events.

I’m using a lot of different technologies. Dependend on the budget and customer demands we are using 1D or 2D barcodes. In some cases we’ve also used RFID tags. In any case we are using mobile devices for capturing IDs.

In the last few years I’ve learned that the mobile capturing devices are the compontents that are responsible for the most problems that occur. Some common flaws are:

– Generally short battery life

– WiFi is consuming a lot of power

– Connection problems or short range of wireless links

– Restricted or proprietary software interfaces

– Small or no display

– Not enough indicators like LEDs or sound playback capabilities

– Slow bluetooth connection setup

– Unstable OS

– Ugly user interface/user experience

– Short range for contactless reading of tags (RFID)

– Bad resolution for barcode reading

I’m only looking at devices, that can be „freely“ customized by using some kind of software development kit (SDK).

Many of them do have interesting capabilities. Some devices are available with different captureing and communication modules. In most cases you have to choose these modules when getting the device and cannot change them afterward. A commonly used operating system is Windows Mobile/CE. Other devices have a proprietary or even no operating system. Very often the API for these devices is not well documented or functionality is missing. There is no way to implement it yourself.

Other problems occur when you try to integrate a mobile device into a bigger system. Some manufacturer offer server components that may not fit into your environment and the protocols that are used are not always documented.

Ein wesentlich schwerwiegender Faktor in meinen Augen ist jedoch, dass viele Geräte schlicht zu teuer sind, um sie in grossen Stückzahlen bei Projekten mit kleinen Budgets einzusetzen. Entweder der Funktionsumfang ist eingeschränkt oder man zahlt für ein Gerät deutlich über 1.000 Euro.

Schon längere Zeit stelle ich mir die Frage: Warum nicht selber machen?

Wie bereits erwähnt gibt es bereits eine Vielzahl von Herstellern und Geräten, die sich in diesem Markt tummeln und die ihrerseits Mannschaften von Entwicklern beschäftigen. Auch wenn ich schon (sehr gerne) mit embedded Systemen gearbeitet habe, ist meine Haupttätigkeit das Schreiben von Software. Deshalb ist eine kommerzielle Entwicklung nicht sinnvoll.

Allerdings gibt es bereits eine Vielzahl von interessanten „Open Platform“ Projekten. Als Beispiele möchte ich hier oBiCo nennen. Aber auch im Bereich der ID Erfassung gibt es interessante offene Projekte, die sich mit dem eigentliche Erfassen beschäftigen. Hier ist OpenPCD ein bekanntes Projekt.

Was könnten die Ziele einer offenen Plattform für die ID Erfassung sein?

Einige Überlegungen hierzu:

Frei zugängliche (dokumentierte) Hardwareplattform

Frei zugängliche Softwarekomponenten, die sowohl auf der Hardware, als auch auf Server- oder Desktop-Systemen laufen (sofern für das Projekt erforderlich)

Modularität bzw. gut dokumentierte Hardwareschnittstellen, so dass einzelne Komponenten ausgetauscht werden können (Lese- oder Kommunikationsmodule)

Es könnte so eine Plattform entstehen, die dazu genutzt werden kann, mit Techniken zur ID Erfassung „herumzuspielen“, Dinge auszuprobieren. So könnte man beispielsweise die Frage untersuchen, ob WLAN, Bluetooth, Zigbee oder irgend eine vollkommen andere Technologie in einem bestimmten Anwendungsfall geeignet ist. Es ist beispielsweise nicht festgeschrieben, dass eine solche Lösung nur lesen können muss. Auch ein „Kartenemulator“ wäre eine interessante Ergänzung.

Eine schwierige Frage ist, wie in allen „offenen“ Projekten, die Frage nach der Kommerzialisierung. Es kann interessant werden, Ergebnisse auch kommerziell zu verwenden. Oder es werden Konfigurationen für interessierte Bastler angeboten. Dies sollte ebenfalls möglich sein. Es ist jedoch noch viel zu früh, diese Frage anzugehen.

Ich werde in der nächsten Zeit ein paar Überlegungen anstellen, wie eine solche Plattform aussehen könnte.

Was ist eure Meinung zu diesem Thema?

In my day job I’m working with identification and access control on events.

I’m using a lot of different technologies. Dependent on the budget and customer demands we are using 1D or 2D barcodes. In some cases we’ve also used RFID tags. In most cases we are using mobile devices for capturing IDs.

In the last few years I’ve learned that mobile capturing devices are the components that are responsible for the most problems that occur. Some common flaws are:

• Generally short battery life
• WiFi is consuming a lot of power
• Connection problems or short range of wireless links
• Restricted or proprietary software interfaces
• Small or no display
• Not enough indicators like LEDs or sound playback capabilities
• Slow Bluetooth link setup
• Unstable OS
• Bad user interface/user experience
• Short range for contactless reading of tags (RFID)
• Bad resolution for barcode reading

I’m only looking at devices, that can be „freely“ customized by using some kind of software development kit (SDK).

Many Devices do have interesting capabilities. Some of them are available with different capturing and communication modules. In most cases you have to choose these modules when getting the device and cannot change the configuration later. A commonly used operating system is Windows Mobile/CE. Some devices have a proprietary or even no operating system. Very often the API for these devices is not well documented or functionality is missing. There is no way to implement missing functionality by yourself.

Other problems occur when you try to integrate a mobile device into a bigger system. Some manufacturer offer server components that may not fit into your environment and the protocols that are used are not always documented.

In my opinion a serious issue is the amount you have to pay for the devices and SDKs. Often it is too expensive to use a larger quantity of devices in a project with small budget. You have to pay more than 1,000 Euro for most mobile capturing devices.

For some time I’m asking myself: Why not build an own capturing device?

There are a lot of manufacturer that build these devices with a lot of engineers. Also I’ve already built some smaller embedded systems and liked it my focus is on developing software. So I will not be able to build a commercial product.

However there are already a lot of interesting „open platform“ projects. As an example I want to mention oBiCo or OpenPCD which already is an open platform for a RFID reader.

Possible objectives for an open platform of this kind could be:

• Free accessible and documented hardware platform
• Free accessible and documented software components that run on the hardware platform as well as on server and desktop systems (if a project need this functionality)
• Modularity of hardware components and well documented interfaces so components can be changed (e.g. capturing or communication module)

It would be possible to create a platform that could be used to evaluate technologies for capturing of IDs. For example you could examine if WiFi, Bluetooth, Zigbee or any other communication technology fits the needs of a certain project. Or it may be interesting to add an RFID tag emulator.

An important question like in any „open“ project is how to handle commercial usage of the results. It could be interesting to use the results in a commercial way or to offer parts and components for people who would like to concentrate on the software of the system. But at the moment it is much too early to think about this perspective in detail.

In the next time I will start to think about who to realize this idea.

What’s your opinion on this?

 

Idee für eine offene Plattform zur mobilen ID Erfassung

In meinem Beruf habe ich unter Anderem viel mit dem Erfassen und der Zutrittskontrolle von Personen auf Veranstaltungen zu tun.

Dabei kommen unterschiedliche Techniken zum Einsatz. Je nach Budget und Kundenwunsch werden 1D oder 2D Barcodes verwendet. In einigen Fällen kommen sogar RFID-Tags mit den entsprechenden Lesegeräten zum Einsatz.

In den letzten Jahren habe ich festgestellt, dass die mobilen Erfassungsgeräte die am meisten Probleme verursachende Komponente darstellen. Hier eine kleine Auswahl der Schwachstellen:

• Allgemein geringe Akkulaufzeit
• WLAN verbraucht unheimlich viel Strom
• Verbindungsprobleme bei drahtloser Kommunikation bzw. geringe Reichweiten
• Programmierschnittstellen eingeschränkt/Proprietär
• Kleines oder kein Display
• Zu wenig Indikatoren (LED, Sound)
• Langsame Bluetooth-Module
• Betriebssystem instabil
• Benutzerinterface (UI) sehr rudimentär
• Reichweite von Lese-Einheiten (besonders bei RFID)
• Auflösung von Lese-Einheiten (besonders bei Barcode)

Es gibt am Markt eine Vielzahl von Geräten, wobei ich nur diejenigen betrachte, die sich durch ein Software Development Kit (SDK) „frei“ Programmieren lassen.

Viele von ihnen besitzen interessante Fähigkeiten. Einige können mit unterschiedlichen Erfassungs und Kommunikationsmodulen ausgestattet werden teilweise auch nachträglich. Ein verbreitetes Betriebssystem ist Windows Mobile/CE. Andere Geräte besitzen ein proprietäres oder gar kein Betriebssystem. Hierbei ergibt sich oft das Problem, dass die vom Hersteller geschaffenen bzw. dokumentierten Schnittstellen hin und wieder nicht die Funktionalität erlauben, die in einem Projekt benötigt wird. Es besteht hier keine Möglichkeit, die Funktionalität selbst zu implementieren.

Weitere Probleme können sich ergeben, wenn man die mobilen Geräte in ein Gesamtsystem integrieren möchte. Von einigen Herstellern gibt es Serverkomponenten, die dann aber vielleicht gerade nicht in die eigene Architektur passen und die verwendeten Protokolle sind nicht immer dokumentiert.

Ein wesentlich schwerwiegender Faktor in meinen Augen ist jedoch, dass viele Geräte schlicht zu teuer sind, um sie in grossen Stückzahlen bei Projekten mit kleinen Budgets einzusetzen. Entweder der Funktionsumfang ist eingeschränkt oder man zahlt für ein Gerät deutlich über 1.000 Euro.

Schon längere Zeit stelle ich mir die Frage: Warum nicht selber machen?

Wie bereits erwähnt gibt es bereits eine Vielzahl von Herstellern und Geräten, die sich in diesem Markt tummeln und die ihrerseits Mannschaften von Entwicklern beschäftigen. Auch wenn ich schon (sehr gerne) mit embedded Systemen gearbeitet habe, ist meine Haupttätigkeit das Schreiben von Software. Deshalb ist eine kommerzielle Entwicklung nicht sinnvoll.

Allerdings gibt es bereits eine Vielzahl von interessanten „Open Platform“ Projekten. Als Beispiele möchte ich hier oBiCo nennen. Aber auch im Bereich der ID Erfassung gibt es interessante offene Projekte, die sich mit dem eigentliche Erfassen beschäftigen. Hier ist OpenPCD ein bekanntes Projekt.

Was könnten die Ziele einer offenen Plattform für die ID Erfassung sein?

Einige Überlegungen hierzu:

• Frei zugängliche (dokumentierte) Hardwareplattform
• Frei zugängliche Softwarekomponenten, die sowohl auf der Hardware, als auch auf Server- oder Desktop-Systemen laufen (sofern für das Projekt erforderlich)
• Modularität bzw. gut dokumentierte Hardwareschnittstellen, so dass einzelne Komponenten ausgetauscht werden können (Lese- oder Kommunikationsmodule)

Es könnte so eine Plattform entstehen, die dazu genutzt werden kann, mit Techniken zur ID Erfassung „herumzuspielen“, Dinge auszuprobieren. So könnte man beispielsweise die Frage untersuchen, ob WLAN, Bluetooth, Zigbee oder irgend eine vollkommen andere Technologie in einem bestimmten Anwendungsfall geeignet ist. Es ist beispielsweise nicht festgeschrieben, dass eine solche Lösung nur lesen können muss. Auch ein „Kartenemulator“ wäre eine interessante Ergänzung.

Eine schwierige Frage ist, wie in allen „offenen“ Projekten, die Frage nach der Kommerzialisierung. Es kann interessant werden, Ergebnisse auch kommerziell zu verwenden. Oder es werden Konfigurationen für interessierte Bastler angeboten. Dies sollte ebenfalls möglich sein. Es ist jedoch noch viel zu früh, diese Frage anzugehen.

Ich werde in der nächsten Zeit ein paar Überlegungen anstellen, wie eine solche Plattform aussehen könnte.

Was ist eure Meinung zu diesem Thema?

 

Es ist eine Weile her…

Es ist eine Weile her, dass ich meinen letzten Blog Eintrag verfasst habe. Dies hatte verschiedene Gründe. Es war viel zu tun und auch wenn ich durchaus der englischen Sprache etwas mächtig bin fällt es mir doch schwer, längere Texte zu verfassen.

Also habe ich beschlossen, mein Blog vorerst in deutscher Sprache weiterzuführen und vielleicht den einen oder anderen Artikel in Englisch zu verfassen. Daneben werde ich auch noch Beiträge mit aufnehmen, die nichts mit dem Ursprünglichen Themengebiet dieses Blogs zu tun haben.

Genug der Erklärungen. Ein paar interessante Dinge habe ich in den letzten Wochen (und Monaten) gemacht.

Hardhack

Ich war auf dem hardhack, der hier in Berlin stattgefunden hat. Bei dieser „Veranstaltung“ ging es um’s Basteln. Vornehmlich Basteln mit Elektronik.  Es scheint, als würde sich in der Do It Yourself (DIY) „Szene“ zur Zeit einiges bewegen. Dabei interessiert mich natürlich vor allem der Elektronik Zweig. Es entstehen immer mehr Platformen und Hilfsmittel, die es auch ohne tiefgehende Vorkenntnisse ermöglichen, in den Bereich des Steuern und Regelns oder „Physical Computings“ einzusteigen. Und ist die Neugier erst einmal geweckt, kommen die tollsten Dinge dabei heraus.

Sehr interessant finde ich das fritzing Projekt.

Fritzing

Fritzing ist ein Open Source Projekt, das den gesamten Prozess vom fliegenden Aufbau einer Schaltung bis zur fertigen Leiterplatte unterstützt. Dabei „malt“ man die Schaltung unter Zuhilfenahme von fertigen Komponenten (z.B. Arduino, Breadboard, LEDs, Transistoren etc.). Parallel dazu wird ein Schaltplan und eine Platine erzeugt. Mit der Hilfe eingebauter Tools kann man die Leiterbahnen der Platine dann noch verlegen (ein Autorouter ist vorhanden) und alle notwendigen Dokumente für die Herstellung der Leiterplatte generieren lassen.

News zu Atmel

Seit vielen Jahren zählen die AVR Mikrokontroller zu meinen Favoriten. Anfang Juni besuchte ich ein „Hands on Seminar“, das sich mit den neuen XMega Bausteinen beschäftigt. Darüber hinaus wurden auch noch aktuelle Neuerungen von Atmel vorgestellt und ein Überblick über die bestehenden Produktfamilien AVR8, AVR32 und ARM gegeben. Insbesondere die AVR32 Familie finde ich interessant.

Zur Zeit warte ich auf das STK-600 um einmal diesen Prozessor ausprobieren zu können. Wenn es so weit ist, gibt es hier neue Infos.

 

Switching Language

When I started this blog I wanted to reach a broad audience and so I decided to use english as the main language.

Unfortunately I’ve noticed that it is to difficult for me to write longer texts in english so that I cannot post as many and detailed texts as I would like to post.

For this reason I’ve decided to switch the main language of my blog to german which does not mean that there will be no more english texts.

 

Hands-on Workshop taskit Panel-Card

On thursday I went to a hands-on workshop held by taskit here in Berlin to learn more about the Panel-Card which is developed and sold by taskit. The Panel-Card is an embedded system that is a bit bigger than a 3,5″ LCD containing a complete embedded Linux system with 3,5″ TFT display, optional ethernet and touch panel.

It was the first workshop held by taskit. At the begining every participant got a virtual machine containing a ready-to-use Linux with devloper tools and examples. In addition everyone got an evaluation kit of the Panel-Card equiped with a touch panel and ethernet.

After we spend some time to make the virtual machine run on every notebook, we were able to implement our first example application. It was a typical embedded „Hello World“ by letting some LEDs blink. This application was implemented as a Linux application with memory mapping and direct access to the IO registers of the Atmel ARM chip. The IDE was based on eclipse which I’m using for my Java development since years. So I felt very comfortable right from the beginning. Source level debugging was also integrated into the IDE so the whole compile-deploy-debug cycle could be executed inside the IDE. By the way one delegate used a Netbook and execution speed of the virtual machine and development tools was very good.

In the second part we learned about how to build a custom kernel. In this case we added a driver for the touch screen mounted on the display of our Panel-Card. This was quite easy since all tools were already installed on the development system and on the target system so we only had to issue one or two commands.

The third part was a short introduction to Qt development with a practical exercise. We had our first application up in less than five minutes. Although it only consisted of an empty window I was excited how fast and easy this basic application worked including a mouse pointer that could be moved by using the touch screen.
A few minutes later we were able do turn the LEDs on the board on and off by tapping buttons on the screen.

The workshop was a bit problematic at the beginning but was at all very good. I’ve learnd a lot and will definitively look more into Qt on embedded systems. I had never expected that it is so easy to get started with UI based applications on an embedded platform.

 

Update to XBee Evaluation Kit Mess

A while ago I wrote about problems I got with the XBee evaluation kit I received during a seminar. In the meantime (acutally only a few days after the post) I got new XBee modules.

These modules are reacting as expected when connected to X-CTU. Unfortunately I didn’t have the time for a deeper look at the modules. Since these modules are running the ZigBee stack I expect them to need a bit more configuration than plain 802.15.4 XBee modules. For this reason I’m thinking about exchanging them with XBee 802.15.4 modules.

BTW… Is it only me that finds the XBee module naming very confusing? You have ZB, ZNet, DigiMesh etc. I have the feeling they changed the naming over time. So even looking at Digis documentation doesn’t help.

I will also take a more detailed look at the Rabbit boards that are also part of the evaluation kit. I’m a big fan of Atmel AVR processors and Arduino boards. I didn’t know about Rabbit processors until the end of last year. But the Dynamic-C environment and corresponding library that promisses to have ready to use routines for many core tasks (even a webserver) looks very interesting.

Since a few weeks you can get a board featuring a Rabbit processor, ZigBee and Ethernet. It allows you to visually handle a whole ZigBee network using a web browser over ethernet. I’ve only seen a short live demo at the seminar back in october which looked very promising. If you are interested in more information you can take a look at the BL4S200 product page. Maybe I will have a chance to get my hands on this board later this year.

 

Flex and Seam

Although this is not fitting into the mobile communication categories I’m a big fan of JBoss Seam framework. Since I’m an experienced Java EE developer it gives me everything I need for modern web based applications.

Recently I was looking int a way of integrating a (web)cam into my project as platform independend as possible. I’ve often seen Flash applications using the integrated camera of my MacBook Pro so I started looking in this direction. I learned that Flex which is in my understanding some kind of Flash extension for Application development makes it very easy to utilize a camera, display the videostream and take snapshoots. In fact you only need some lines of code after all ui elements are in place:


private var cam:Camera;

private function setUpCam():void {
  cam = flash.media.Camera.getCamera();
  cam.setMode(320, 240, 30);
  videoDisplay.attachCamera(cam);
}


It’s important that the camera resolution (setMode()) matches the size of the video display. Otherwise the videostream will conatin artifacts.

To get a snapshot just call the following function:


private function saveImage():void {
  var bitmapData:BitmapData = new BitmapData(vid.width, vid.height);
  bitmapData.draw(videoDisplay);
  var encode:JPGEncoder = new JPGEncoder();
  var imageData:ByteArray = encode.encode(bitmapData);
}


After accessing the camera was so easily done (up to this day I didn’t write a single line of Flex or ActionScript code) I looked further into integrating this application with my main seam application.

Two frameworks exists for this task. First there is Flamingo from Exadel. I looked at the documentation and examples but was not able to find a way to just call a method of a seam component and pass a byte array. I’m sure it will work somehow. Since the last release is from October 2008 I was uncertain if it would work with the current 2.1 release of Seam.

I then discovered Granite DS as an alternative. There has been a recent update and a separate version vor Seam 2.1 exists. Although more steps where needed to integrate the framework into my Seam Application. However I was finally able to pass Objects and values back and forth.

After this first success I will be looking into more details of Granite DS. I wonder if security and context propagation are working as promised.