Einige Fragen, die ich mir anfangs stellte, waren:

• Wie groß ist die Reichweite von den eingebauten Bluetooth-LE Chips?
• Wie zuverlässig funktioniert es, die App im Hintergrund laufen zu lassen, also nichts weiter tun zu müssen?
• Wie genau und stabil funktioniert das Ganze?

Erste Überlegungen

Meine erste Idee bestand darin, das von Apple spezifizierte iBeacon-Protokoll zu verwenden, da es ja eine Art Positionserkennung innerhalb von Gebäuden ermöglicht. Apple baut dabei auf dem Bluetooth-LE Protokoll auf, verwendet aber nicht, wie sonst üblich, die darin spezifizierten Services und Characteristics, sondern nur die Advertisement-Nachricht. Für genauere Infos siehe http://stackoverflow.com/questions/18906988/what-is-the-ibeacon-bluetooth-profile.

Spezifiziert ist das iBeacon-Protokoll für die Annäherungserkennug, die sog. Proximity. Anstatt einer genauen Position erhält man nur den ungefähren Abstand zu iBeacon. Dies wird dadurch ermöglicht, dass das iBeacon diejenige Signalstärke mitsendet, mit der es in 1m Abstand empfangen wird. Kombiniert mit der tatsächlichen Signalstärke des empfangenen Signal lässt sich so der Abstand näherungsweise ermitteln.

In iOS7 ist das iBeacon-Protokoll als CoreLocation implementiert und wird über CLLocationManager und CLBeaconRegion verwendet. Es sind sogenannte Regions definierbar mit einer eindeutigen UUID, die das Beacon aussendet. Weiters sind zusätzlich zum ungefähren Abstand die States Inside/Outside bzw. Near/Far vorgesehen.

Tests:

• Eine Variante ist, das iPhone als iBeacon einzusetzen und der Raspberry erkennt die Annäherung desselben.

• Die zweite Variante wäre, den Raspberry als iBeacon aufzusetzen und das iPhone erkennt, wenn es in der Nähe ist.

Erkenntnisse:

Die erste Möglichkeit fällt leider weg, da das iPhone ständig advertisen müsste, das Advertisen im Background aber leider vom System nicht erlaubt wird. Die App müsste also immer im Vordergrund sein und das iPhone nicht gelockt.

Die zweite Möglichkeit habe ich mit der NodeJS-Library node-bleacon umzusetzen versucht, bin dabei aber auf folgende Restriktionen gestoßen:

• Zum einen erfolgt die Erkennung, dass das iPhone in Reichweite eines iBeacons ist, wenn das iPhone gelockt ist, teilweise sehr spät (bis zu 15 min.),
• zum anderen weiß zwar dann das iPhone, dass es in der Nähe des Beacons ist, aber wie erfährt das der Raspberry? Dazu müsste ein zweiter Kommunikationsweg (3G, WLAN) verwendet werden, was das Ganze wieder umständlich macht.

Ergebnis:

Die iBeacon-Variante ist also nicht brauchbar!

Zweite Idee

Die zweite Idee bestand darin, das System als Kombination von Bluetooth LE Central und Peripheral umzusetzen, so wie das Protokoll eigentlich gedacht ist. Dabei verbindet sich ein Gerät zu einem zweiten und kann so von ihm Daten abfragen bzw. zu ihm senden. Realisiert wird das über sogenannte Services und Characteristics.

Diese Funktion ist in iOS7 in CoreBluetooth umgesetzt und als CBCentralManager bzw. CBPeripheralManager verwendet (siehe http://www.raywenderlich.com/52080/introduction-core-bluetooth-building-heart-rate-monitor).

Es gibt wieder 2 Varianten für die Umsetzung:

• Das iPhone wird als Peripheral eingesetzt, welches seine UUID advertised, der Raspberry Pi scannt danach und loggt dessen Anwesenheit.

• Der Raspberry Pi wird als Peripheral aufgesetzt und advertised seine UUID, das iPhone scannt danach und connected. Anschließend folgt ein zyklisches Schreiben eines Wertes (1 sec), um seine Anwesenheit kundzutun.

Erkenntnisse:

In der ersten Variante muss das iPhone seine UUID ständig advertisen, was zwar mittels CoreBluetooth im Background möglich ist (siehe: Apple Developer Guidelines), aber dauerhaft Strom benötigt und somit den Akku des iPhones innerhalb kürzester Zeit entleert. Die Raspberry Pi-Tests habe ich mit der NodeJS-Library noble gemacht.

Die zweite Variante habe ich als die Beste angesehen. Das iPhone muss zwar ständig nach der UUID des Raspberry scannen, was aber ein passiver Vorgang ist, also nicht sonderlich viel Strom braucht. Zudem wird es im Background-Modus vom Betriebssystem übernommen. Für den Peripheral-Modus auf dem Raspberry habe ich die NodeJS-Library bleno verwendet. Zum loggen der Anwesenheit habe ich das Projekt eines anderen Entwicklers genommen und etwas abgeändert (PiThermServer). Meine Sourcecodes habe ich auf GitHub zur Verfügung gestellt:

• PiPresenceServer für das Raspberry Pi Peripheral, das die Anwesenheit loggt.
• iOSBLEPresence, die zugehörige App, die sich zum Peripheral verbindet und zyklisch einen Wert schreibt (1 Sekunde).

Beobachtungen/Probleme:

• Ein Problem, das mir sehr viel Kopfweh verursacht und viel Zeit gekostet hat, war: iOS cached UUIDs und Namen von Peripherals anhand der Bluetooth-ID. Wenn man sich also schon mal mit einem iPhone zu einem Peripheral verbunden hat und das Peripheral dann seine UUID oder seinen Namen ändert, wird es unter iOS immer noch unter dem alten Namen und mit der alten UUID angezeigt. Da hilft leider nur ein Zurücksetzen auf Werkseinstellungen des iPhones.
• Ein Manko des Systems ist die sehr geringe Reichweite von Bluetooth LE. Das ganze funktioniert nur, wenn Raspberry Pi und das iPhone im selben Zimmer sind. Sobald man sich aus dem Zimmer hinausbewegt, wird die Verbindung verloren. Ich habe dabei aber leider noch nicht herausgefunden, ob es an einer geringen Signalstärke des Bluetooth-USB Dongles am Raspberry liegt oder an der geringen Signalstärke des iPhones, das den Update-Wert nicht mehr schreiben kann.
• Ein weiterer Nachteil des Testsetups ist, dass der Akku des iPhones, selbst wenn es nur gelockt herumliegt, nicht länger als 24 Stunden hält. Das liegt wohl an der relativ kurzen Update-Zeit, in der das iPhone einen Wert an den Raspberry schickt.

Mögliche Verbesserungen:

• Die geringe Reichweite von Bluetooth LE ließe sich durch Zusammenschalten mehrerer Raspberry Pi überbrücken, die miteinander über LAN kommunizieren und die Anwesenheit von Centrals austauschen.
• Um die Akkuzeit zu verbessern, wäre die einfachste Möglichkeit, die Update-Zeit zu vergrößern. Dadurch würde sich aber gleichzeitig die Zeit wie schnell erkannt wird, dass das Smartphone sich aus der Reichweite bewegt hat, verschlechtern.

Offene Fragen:

• Eine Frage, die bisher ungelöst blieb ist: Wie verhält sich das System nach einer App-Termination durch zu wenig freien Speicher am iPhone? Wird die App automatisch neu gestartet und die Verbindung wieder hergestellt, oder muss ich die App manuell neu starten?
• Ein ähnliches Problem entsteht, wenn der Akku des iPhones leer ist und das Gerät neu startet. Die App wird leider nicht automatisch gestartet und man muss dies manuell tun. Irgendwo hab ich zwar mal gelesen, dass das funktionieren sollte, zusammengebracht hab ich’s allerdings noch nicht.

The post Bluetooth LE Presence Awareness mit iOS und Raspberry Pi appeared first on Mobile USTP MKL.

In diesem Paper wird das Konzept und ein Prototyp eines Step-by-Step basierten Inhouse-Navigationssystems vorgestellt, welches aus technischen und finanziellen Gründen auf eine kontinuierliche Positionserkennung verzichtet und mit vergleichsweise geringem Aufwand an neuen Orten eingeführt werden kann. Im Vorfeld wurden in einer intensiven Recherche bestehende Systeme zur Positionsbestimmung in Gebäuden analysiert und auf ihre Zuverlässigkeit und Flexibilität untersucht. Diese Parameter führten zur Entscheidung, die Positionsbestimmung auf der Basis von künstlich angebrachten, visuellen Landmarks in Form von QR (Quick Response)-Codes zu realisieren. Eine mögliche Erweiterung durch Echtzeit-Lokalisierungssysteme wird jedoch nicht ausgeschlossen. Die Routingberechnung basiert auf dem Setzen von Knoten an Start-, Endpunkten und Abzweigungen sowie Kanten, die diese Knoten verbinden. Jeder Kante wird dabei nach Länge und Art eine Gewichtung zugeordnet, aufgrund derer mit Hilfe des Dijkstra-Algorithmus der kürzeste Weg zwischen zwei Knoten berechnet wird. Weitere Parameter bieten die Möglichkeit, auf die Routenberechnung einzuwirken und ermöglichen so eine Prioritätensetzung und im Bedarfsfall Barrierefreiheit bei der Navigation. Mit Hilfe eines einfachen Backends für die Erstellung eines Routing-Netzwerkes für ein neues Gebäude, können die Einrichtungskosten auf einem Minimum gehalten werden. Durch Klicken in einer Karte des Gebäudegrundrisses können schnell Wegzüge erstellt und durch Auswahl aus vordefinierten Knoten- und Kantenkategorien einfach parametrisiert werden. Um die Navigation anhand der berechneten Route für Smartphone-BenutzerInnen verständlich zu machen, wird die Route in kleinen, übersichtlichen Schritten (Steps) dargestellt, die sowohl auf einer maßstabsgetreuen Karte, wie auch als dynamisch generierter Text angezeigt werden. Die Zielsuche wird dabei durch eine Auswahlliste anhand von Knotenkategorien (Büro, Seminarraum, WC, …) erheblich erleichtert. Anhand eines Sets von Usabilitytests wird gezeigt, dass das System, bestehend aus den QR-Codes zur Positionsfindung und einer Smartphone-Anwendung zur Navigation, von BenutzerInnen ad hoc verstanden wird und zur Navigation innerhalb von den BenutzerInnen unbekannten Gebäuden eingesetzt werden kann.

Publikation und Präsentation stehen zum Download bereit:

Paper Forum Medientechnik 2013

Präsentation Forum Medientechnik 2013

Autoren

Ewald Wieser, Tomas Kasanicky, Florian Schiesterl, Bernhard Griessler, Christoph Fabritz, Kerstin Blumenstein, Grischa Schmiedl

Zitieren als

Wieser, E., Kasanicky, K., Schiesterl F., Grießler, B., Fabritz C., Blumenstein K. & Schmiedl, G., 2013. Smartphonebasierte Step-by-Step Indoor-Navigationslösung ohne kontinuierliche Positionserkennung. In Forum Medientechnik – Next Generation, New Ideas. St. Pölten: Fachhochschule St. Pölten.

The post Smartphonebasierte Step-by-Step Indoor-Navigationslösung ohne kontinuierliche Positionserkennung appeared first on Mobile USTP MKL.

Hier geht’s zum Download der Seminararbeit: Smart Devices

The post Smart Devices appeared first on Mobile USTP MKL.

Die Grundlagen dafür wurden uns von Jakob Doppler in einem Workshop für Android-Entwicklung beigebracht. Inspiriert dazu wurde ich von einem Vortrag auf der Mobile Developer Conference 2012 in Stuttgart, mit dem Thema “Hardwareerweiterungen für Android”, wo uns der USB-On-The-Go (USB-OTG) Modus neuerer Android-Smartphones vorgestellt wurde, durch den es möglich ist, mittels eines speziellen Kabels (Amazon), das Smartphone in den USB-Host Modus zu bringen, um externe Geräte ansteuern zu können. In meinem Fall wollte ich damit direkt auf den Arduino-basierten JeeLink USB-Funkadapter (http://jeelabs.com/products/jeelink) zugreifen, um die Steuersignale zum ArduBot zu senden.

Das Funkprotokoll und die notwendige Software für den Arduino-Controller waren bereits entwickelt, es ging also nur darum, die USB-Schnittstelle auf dem Android-Phone zu implementieren und das Userinterface entsprechend zu gestalten. Glücklicherweise gibt es bereits eine fertige Library für Android, um über die USB-Schnittstelle mit Arduino-Boards zu kommunizieren (https://code.google.com/p/usb-serial-for-android/). Etwas schwieriger gestaltete sich das Userinterface, das ich ähnlich der iPhone-WebApp (Link siehe PA2), mit einem kleinen Touch-Joystick implementieren wollte. Aber auch hier fand ich einige Inspiration im weltweiten Netz und auf dem Blog von Alex Trost (http://blog.trostalex.com/?p=114) eine einigermaßen brauchbare Vorlage.

Trotz allem waren ca. 20 Stunden an Arbeit notwendig, um die vielen Teile zusammenzustoppeln, einen netten Splash-Screen einzubauen, und die notwendigen Berechnungen durchzuführen, um aus der Joystickposition die Daten zur Übertragung über die Funkschnittstelle zu bekommen.

Das Ergebnis könnt ihr hier beobachten und auch gleich downloaden: ArduBotRC-Control.

Einige Verbesserungen sind sicherlich noch möglich: Zum einen springt der Joystick ab und zu unkontrolliert hin- und her. Die Ursache dafür habe ich noch nicht ermitteln können. Zum anderen werden Touches ab und zu nicht richtig erkannt und keine Daten über die Funkschnittstelle gesendet. Dem könnte man durch einen automatischen Refresh-Timeout von z.B. 1 Sekunde abhelfen, bei dem die Daten automatisch, ohne Änderung gesendet werden. Zu guter letzt ist auch das Userinterface noch verbesserungswürdig. Man könnte auf der großen, weißen Fläche z.B. den ArduBot schemenhaft anzeigen und über einen Rückkanal der Funkschnittstelle den Zustand der Sensoren anzeigen.

The post ArduBot RC-Control for Android appeared first on Mobile USTP MKL.

USB-Verbindung 

• Arduino als Host
  Hierfür ist entweder ein spezielles Arduinoboard notwendig, das bereits über eine USB-Host-Schnittstelle verfügt (Google ADK, …), oder ein USB-Host-Shield, das auf das bestehende Arduinoboard aufgesteckt wird und ca. € 45,- kostet.
  Die Verbindung funktioniert über ein normales USB-Kabel und ist mit jedem Android Smartphone möglich.
• Android als Host
  Bei dieser Variante ist ein spezielle USB-Kabel notwendig (USB-OTG), welches das Android Smartphone in den Hostmodus versetzt und ca. € 5,- kostet. Es kann mit jedem Arduinoboard verwendet werden, funktioniert aber nur mit Androidphones, die den Hostmodus unterstützen (Samsung Galaxy Nexus, Google Nexus 4, …).

Bluetooth-Verbindung

So gut wie alle modernen Smartphones haben eine Bluetooth-Schnittstelle schon standardmäßig eingebaut. Auf der Seite des Arduino gibt es entweder schon fertige Boards mit Bluetooth-Schnittstelle , die ca. € 100,- kosten oder ein Bluetooth-Shield, das auf das bestehende Arduinoboard aufgesteckt wird und ca. € 23,- kostet. Der Vorteil dieser Verbindung ist, das kein Kabel zwischen Smartphone und Androidboard benötigt wird.

Für mein Projekt habe ich mich für den Android-Hostmodus entschieden, da so die wenigsten Kosten und entstanden und keinerlei Umbauten in der Soft- oder Hardware notwendig waren. Für die Verwendung der Schnittstelle in Java gibt es außerdem eine kleine Library, die einfach eingebunden wird und die sich um die Kopplung kümmert (http://code.google.com/p/usb-serial-for-android/).

The post Android <---> Arduino appeared first on Mobile USTP MKL.

Googles Chrome Browser ist seit Version 10 in der Lage, diese Schnittstelle zu benutzen, wenn auch nur mit dem -webkit Vendor-Prefix. Es wurden auch schon zahlreiche, teils auch sehr gelungene Anwendungen dafür entwickelt, wie zum Beispiel das jam-with-chrome Experiment (http://www.jamwithchrome.com/). Hier können Leute gemeinsam im Browser musizieren. Jeder auf seinem eigenen Rechner und jeder ein anderes Musikinstrument. Die Soundausgabe funktioniert auf allen Rechnern gleichzeitig und die Bedienung ist sehr einfach und gut gelungen.

Seit iOS6 wird WebAudio auch von mobileSafari unterstützt und andere Browserhersteller werden mit Sicherheit nachziehen (http://caniuse.com/audio-api). Mozilla setzt indessen auf die Audio Data API, die ähnlich funktioniert, aber tiefgreifendere Funktionen zulässt.

Eine einfache Demo-Webseite (http://html5audio.org/examples/simple-embedded-audio/) zeigt, wie sich mit nur 10 Codezeilen die gesamte Audioausgabe bewerkstelligen lässt (die restlichen 10 Zeilen sind für die Base64-Dekodierung…). Die gesamte API ist ziemlich umfangreich und ist nicht nur für die reine Ausgabe von Audio gedacht, sondern auch für die Live-Generierung mittels Oszillatoren und -Bearbeitung mit Filtern und Mixern mit sehr geringen Latenzzeiten.

Ich freue mich schon darauf, wenn dieses Feature auch auf mobilen Webseiten auftaucht und ringsum die stummen Smartphones beginnen, zu neuem Leben zu erwachen.

The post Rückkehr der Hintergrundmusik? appeared first on Mobile USTP MKL.

Ideen

Meine Ideen reichten von einer QR-Code Marketing-Kampagne für eine Band, wo der Nutzer durch Scannen des QR-Codes den neuesten Song der Band downloaden kann, über eine Rezepte App, bei der man täglich einen neuen Rezeptvorschlag bekommt, bis hin zu einem kleinen Online Spiel, wo man den Träger des T-Shirts herausfordern kann und versucht dessen Bestzeit zu schlagen.

Design

Nach längerem Brainstorming und einigen Handskizzen mit möglichen Designs entschied ich mich aber für eine weniger aufwändige Anwendung, die die Nutzer durch ein witziges Design ansprechen soll. Nach Einscannen des QR-Codes auf meinem T-Shirt wird der Nutzer auf eine Webseite weitergeleitet, die ihm, im selben Design wie das T-Shirt, die noch verbleibenden Tage bis Weihnachten anzeigt.

Umsetzung

Die Umsetzung erfolgte mit einer einfachen mobilen Webseite mit 2 Grafiken und einem kleinen Javascript, das die noch verbleibenden Tage bis Weihnachten zählt und als Text ausgibt. Als Wiedererkennungswert habe ich die selben beiden Grafiken, wie auf dem T-Shirt verwendet (Mütze und Schriftzug). Nur anstatt des QR-Codes wird auf der Webseite die Zahl der noch verbleibenden Tage bis Weihnachten angezeigt. Ein kleiner roter Rand und ein paar Schatten sollten das Ganze noch etwas freundlicher und plastischer gestalten.

Datenerhebung

Zusätzlich platzierte ich auf der Webseite noch eine kleine Umfrage mit ein paar Fragen an den/die BesucherIn. Die ersten drei Fragen gaben ein paar einfache Antworten zum Ankreuzen vor und die letzte Frage hatte ein paar Links zu Amazon-Geschenkelisten zur Auswahl.

Die Felder zum Ankreuzen sind einfache Radiobuttons, die mit ein paar CSS3-Befehlen umgestyled wurden.

Um die Anzahl der Besucher und deren Antworten auf meine Fragen einfach nachverfolgen zu können, inkludierte ich Google Analytics auf der Webseite und hängte mittels JavaScript an jeden Radiobutton bzw. Link einen OnClick-Listener, der eine Event-Nachricht an Google Analytics sendet. Dort können dann einfach umfangreiche Auswertungen gemacht werden.

Erwartungen

Ich denke, dass ich mit dem ansprechenden Design des T-Shirts doch einige Leute dazu bringen kann, den QR-Code zu scannen. Da ich das T-Shirt wohl am häufigsten an der FH tragen werde, wird der Großteil der Scanner Studenten sein. Da ja jetzt die kalte Jahreszeit kommt, werde ich im Freien wahrscheinlich eine Jacke über dem Shirt tragen, somit werden auf meinem täglichen Weg von und zu der FH nur wenige das T-Shirt zu sehen bekommen.

Über die Beantwortung der Fragen kann ich keine wirklichen Vorhersagen treffen, außer, dass sich vielleicht nicht alle, die auf die Seite kommen, auch Zeit nehmen, um die Fragen auch zu beantworten.

Auswertung

Google Analytics bietet einen einfachen Überblick über Anzahl und Herkunft der Besucher, ebenso wie die benutzten Systeme und Browser.

Durch die Click-Events ist es möglich, den Weg der Benutzer auf der Webseite zu verfolgen und ihre Antworten zu analysieren.

Ich habe mir vorgenommen, das T-Shirt zumindest einmal pro Woche an der FH zu tragen, um entsprechend Publikum zu erreichen, ebenso auf privaten Veranstaltungen.

In der Zeit von 20. Oktober bis 24. Dezember 2012 hatte ich das T-Shirt insgesamt 12 Mal an und erreichte dabei 16 eindeutige Besucher. Insgesamt waren es 22 Besuche, von denen also einige mehrmals auf meine Seite kamen. Ob das allerdings durch erneutes Scannen meines QR-Codes, also bewusst geschah, oder nur durch neuerliches Laden eines offengelassenen Tabs im Browser, kann ich leider nicht unterscheiden.

Interessant ist auch, dass von den 22 Besuchen 3 von einem Desktop-Computer kamen. Ich kann mir aber nicht vorstellen, dass meinen QR-Code jemand mit der WebCam auf seinem Computer gescannt hat. Vielleicht hab ich mir da aber selbst ein Ei gelegt und hatte die Seite noch in einem meiner Browser-Tabs auf dem Rechner geladen und dieses wurde unabsichtlich refresht.

Anhand des Ereignisflusses lässt sich erkennen, dass nur 10 der 16 Besucher meine Fragen beantwortet haben. Eventuell war der Bildausschnitt ungeschickt gewählt und die Besucher erkannten nicht, dass unter den angezeigten, verbleibenden Tagen die Fragen auf eine Beantwortung warteten, oder die Leute waren einfach nicht bereit auf diese doch etwas persönlichen Fragen zu antworten.

Auffällig ist außerdem noch, dass nur die ersten drei Fragen jeweils beantwortet wurden. Die vierte Frage mit den Links zu Amazon Geschenksvorschlagslisten wurden anscheinend nie geklickt. Entweder waren die Links zu unscheinbar gemacht, oder die Leute hatten schon alle Geschenke für Weihnachten beisammen…

Die Realisierung des Eventtrackings mittels einzelner Click-Events stellte sich im Nachhinein als nicht so günstig dar, da, wenn ein Besucher eine Antwort revidiert und nochmal klickt, ein neuer Event geloggt wird und ich so, obwohl es nur 4 Fragen waren, bei manchen Besuchern bis zu 6 Clicks registriert habe. Von zwei Besuchern wurde ich außerdem darauf hingewiesen, dass sie am Ende den altbewährten “Absenden”-Button vermisst haben.

Konklusio

Alles in allem war es auf jeden Fall ein interessantes Projekt, einmal eine T-Shirt Kampagne von vorne bis hinten durchzuziehen. Man kann sicher einiges aus den Erfahrungen lernen. Als richtig erfolgreiche Kampagne würde ich meine allerdings angesichts der geringen Besucherzahl nicht bezeichnen, dafür müsste man sie wohl noch etwas professioneller aufziehen. Aber es sind sicher einige Dinge daraus für spätere Kampagnen brauchbar.

Vielen Dank an alle, die mitgemacht haben!

The post How many days till X-mas? appeared first on Mobile USTP MKL.