Remote Presenter

Having discussions on presentation slides via phone? Having round-table meetings where everybody wants to show his one own slide? Then you might know some of the following scenarios:

  • „How can I show you the slides“ – „Oh, send them by mail.“ – „Have they arrived yet?“ – „Which slide are you viewing right now?“ – „Page 23 or Slide 23? Or the one labelled ’23‘?“
  • „Could you pass me the VGA cable for the projector?“ – „How do I make this computer show the image?“ – „Maybe I can show my slide first?“ – „Why doesn’t it work with my adapter? Is the projector broken?“

I wrote a tiny tool that can handle these situations – A webpage where you can upload your PDF or images, and everybody connected sees the same slides, can select slides for a ‚private‘ view, select slides to show to everybody else. Works with ‚any‘ web browser, no special tools required on the users‘ end. E.g. open the website on the main presentation PC, and all people in the meeting can control slides using their mobile devices.

As usual, the code can be found on github: https://github.com/mueschel/RemotePresenter. Just 15 kByte of code that might save a lot of time during meetings.

LCD Lib portiert für Arduino

Meine LCD-Library ist nun auch kompatibel mit Arduino und lässt sich einfach in jedem Arduino-Sketch benutzen.

Warum das? Damit lassen sich Displays jetzt auch mit einem ESP8266-Modul betreiben und mit den vorhandenen Arduino-Code-Beispielen einfach mit WLAN verheiraten, z.B. mit einem kleinen Telnet-Server ließe sich das Display so remote mit Daten füttern.

Der Code findet sich wie üblich auf github: https://github.com/mueschel/lcdlib-arduino

Guideposts and Destination Signs in OSM

A typical hiking guidepost in the Austrian Alps and its node in the OSM database

How a guidepost can be mapped and which level of detail is desired has been the topic of a thread in the German forum and a dedicated poll (not available any more). The outcome of both discussions was that people have very different opinion on how mapping should be done. Fortunately, there is no conflict between the different options, they merely represent different levels of complexity.

Besides the personal interests of each mapper, the location and type of the sign plays a role when deciding on a mapping scheme. Some guidepost just point to the next locality along a path which is already fully mapped—the additional information by adding these destinations to OSM is marginal at best and can be skipped. The same holds for guideposts along an existing hiking route. In this case, the guidepost itself can be added to the OSM relation and it’s content doesn’t need to be mapped. In other regions, the pure existence of a mapped guidepost is valuable information—e.g. if ways have not been fully traced, the map user could be told to take a way that doesn’t even exist on his map yet.

These considerations led to a three-leveled recommendation how to map guideposts:

Level 1—The Guidepost

Each and every guidepost found should exist in OSM as a node tagged tourism=information and information=guidepost. Following additional tags that can be used:

  • hiking=yes / bicycle=yes — is the guidepost designated to a specific group of users?
  • operator=* — the organization responsible for the guidepost
  • ref=* — some operators use reference numbers on their signs
  • material=* — the material the guidepost is made of, e.g. wood or metal
  • colour=* — the color of the guidepost

If someone does not want to map destinations, the content of the signs might be made visible to other mappers or map users by either adding a url tag pointing to the image taken or the text of the signpost can be put into a note:destination or inscription tag.
In case the guidepost is part of an existing hiking route relation, it should be added to it. Further mapping of destinations is not required in this case.

Level 2—Destinations as Keys on a Way

On most highways destinations are mapped using the destination=* and its sub-keys including the :forward/:backward suffixes. This scheme can be used on hiking routes as well. The tags are put on a way in OSM starting or ending near the actual guidepost. Useful keys are

  • destination=* — Give the destinations as a list, separated by semicolon.
  • destination:symbol=* — in case a symbol is shown (usually for amenities like restaurants)
  • destination:ref=* — the reference number of another way the guidepost points to
  • destination:lang:XX=* — some destinations might be posted in several languages. Use the common language keys in place of „XX“

Please note that the addition of :forward or :backward is necessary in most cases – the destination given is only valid when travelling the way in one direction but not in the other. The suffix is always added to the very end of the key.

Level 3—Destinations as Relations

The most precise though time consuming option is to use relations of type destination_sign. A destination sign relation has three members. The guidepost (using role sign), the intersection node on the way (role intersection) and the way the sign points to (to). Besides its type, the relation takes the keys mentioned above and in addition:

  • distance=* — the distance to the listed destination as shown on the sign. Default unit are kilometers, others can be used but need to be specified (e.g. 6.5 miles, 550 m)
  • time=* — The time to destination indicated on the sign. The format is „HH:MM“, giving both hours and minutes.
  • colour:back=*, colour:text=*, colour:arrow=* — the colors used on the sign

Remarks

Some general remarks about tagging: Always choose the most appropriate scheme—none is better or worse. Keep the tagging as simple as possible without losing too much information. Trivial information does not need to be mapped.

[This text also appeared on http://www.weeklyosm.eu/archives/4504 in 2015, thanks to Nakaner and Manfred for proof-reading]

TMC-Decoder: Rundfunk-Verkehrsnachrichten

Schon ein wenig veraltet, aber trotzdem noch überall im Einsatz: TMC, Vekehrsnachrichten, die per Radio digital verbreitet werden und dann z.B. dem Navi zur Verfügung stehen. Dafür gibt es Tabellen mit 45.000 Verkehrsknotenpunkten, 1500 Ereignissen und so weiter, die dann kodiert übertragen werden.

So sieht eine Beispielmeldung dann aus, zuerst die empfangenen Codes, und dann die dekodierte Nachricht:

Ev  859 	LC 11402	Dir pos	Exten 2	(6)Suppl 91	
A45 Hagen -> Gießen zwischen AS Ehringshausen und AK Wetzlarer Kreuz: 
unbeleuchtetes Fahrzeug auf der Fahrbahn, Gefahr

Bei manchen Navis lässt sich so ein Empfäger extern nachrüsten und kommuniziert dann über eine serielle Schnittstelle mit dem Navi – was liegt also näher als so einen Empfänger an den Computer anzuschließen und selbst die Daten zu lesen? Hier findet ihr ein kleines Tool dazu: https://github.com/mueschel/TmcDecoder
Die Tabellen mit Ereignissen und Orten sind nicht enthalten, aber diese lassen sich kostenlos vom BaSt beziehen.

LCD Lib: Jetzt auch mit Farb-TFT

Nachdem es inzwischen extrem günstige 2-3 Zoll große farbige TFT Displays zu kaufen gibt, mussten diese natürlich auch von meiner LCD-Lib unterstützt werden. Es stehen wie gewohnt alle Funktionen zur Verfügung, mit dem Zusatz, dass eine Vorder- und eine Hintergrundfarbe gesetzt werden kann. Selbstverständlich lässt sich diese Farbe für jeden Zugriff einzeln setzen. Vollfarbige Bilder werden allerdings nicht unterstützt – dafür wäre der verfügbare Speicherplatz im AVR in der Regel auch viel zu klein.

Unterstützt werden zur Zeit Displays mit Controller ILI9341, allerdings scheint z.B. ein ST7735 auch kompatibel zu sein.

Viel Spaß damit, der Code liegt auf github: https://github.com/mueschel/lcdlib und eine Diskussionsmöglichkeit gibt es hier: https://www.mikrocontroller.net/topic/144500