24 Jul 2016
The backend problem is work but mostly "solved". One can rely on something like Amazon IoT or creating a powerful infrastructure using many of the FOSS options for message routing, data storage, indexing and retrieval in C++. In this post I want to focus about the little detail of how data can go from the device to the backend.
To make this thought experiment a bit more real let's imagine we want to build a bicycle lock/tracker. Many of my colleagues ride their bicycle to work and bikes being stolen remains a big tragedy. So the primary focus of an IoT device would be to prevent theft (make other bikes a more easy target) or making selling a stolen bicycle more difficult (e.g. by easily checking if something has been stolen) and in case it has been stolen to make it more easy to find the current location.
ArchitectureLet's assume two different architectures. One possibility is to have the bicycle actively acquire the position and then try to push this information to a server ("active push"). Another approach is to have fixed installed scanning stations or users to scan/report bicycles ("passive pull"). Both lead to very different designs.
World wide usable
Pick two of three
Given these constraints it is time to explore some technologies. I will use the one already mentioned at the beginning of this section.
|Technology||Bands||Global coverage||Range||Battery needed||Scan Device needed||Cost of device||Arch.||Comment|
|Barcode/QR-Code||Optical||Yes||Centimeters||No||App scanning barcode required||extremely low||Pull||Sticker needs to be hard to remove and visible, maybe embedded to the frame|
|Play audio||Non human hearable audio||Yes||Centimeters||Yes||App recording audio||moderate||Pull||Button to play audio?|
|NFC||13.56 Mhz||Yes||Centimeters||No||Yes||extremely low||Pull||Privacy issues|
|RFID||Many||Yes, but not on single band||Centimeters to meters||Yes||Receiver required||low||Pull||Many bands, specific readers needed|
|Bluetooth LE||2.4 Ghz||Yes||Meters||Yes||Yes, but common||low||Pull/Push||Competes with Wifi for spectrum|
|ZigBee||Multiple||Yes, but not on single band||Meters||Yes||Yes||mid||Push||Not commonly deployed, software more involved|
|6LoWPAN||Like ZigBee||Like ZigBee||Meters||Yes||Yes||low||Push||Uses ZigBee physical layer and then IPv6. Requires 6LoWPAN to Internet translation|
|GSM||800/900, 1800/1900||Almost besides South Korea, Japan, some islands||Kilometers||Yes||No||moderate||Push||Almost global coverage, direct communication with backend possible|
|UMTS||Many||Less than GSM but South Korea, Japan||Meters to Kilometers depends on usage||Yes||No||high||Push||Higher power usage than GSM, higher device cost|
|LTE||Many||Less than GSM||Designed for kilometers||Yes||No||high||Push||Expensive, higher power consumption|
|NB-IOT (LTE)||Many||Not deployed||Kilometers||Yes||No||high||Push||Not deployed and coming in the future. Can embed GSM equally well into a LTE carrier|
24 Jul 2016 3:02pm GMT
23 Jul 2016
Harald "LaF0rge" Welte: python-inema: Python module implementing Deutsche Post 1C4A Internetmarke API
At sysmocom we maintain a webshop with various smaller items and accessories interesting to the Osmocom community as well as the wider community of people experimenting (aka 'playing') with cellular communications infrastructure. As this is primarily a service to the community and not our main business, I'm always interested in ways to reduce the amount of time our team has to use in order to operate the webshop.
In order to make the shipping process more efficient, I discovered that Deutsche Post is offering a Web API based on SOAP+WSDL which can be used to generate franking for the (registered) letters that we ship around the world with our products.
The most interesting part of this is that you can generate combined address + franking labels. As address labels need to be printed anyway, there is little impact on the shipping process beyond having to use this API to generate the right franking for the particular shipment.
Given the general usefulness of such an online franking process, I would have assumed that virtually anyone operating some kind of shop that regularly mails letters/products would use it and hence at least one of those users would have already written some free / open source software code fro it. To my big surprise, I could not find any FOSS implementation of this API.
If you know me, I'm the last person to know anything about web technology beyond HTML 4 which was the latest upcoming new thing when I last did anything web related ;)
Nevertheless, using the python-zeep module, it was fairly easy to interface the web service. The weirdest part is the custom signature algorithm that they use to generate some custom soap headers. I'm sure they have their reasons ;)
Today I hence present the python-inema project, a python module for accessing this Internetmarke API.
Please note while I'm fluent in Pascal, Perl, C and Erlang, programming in Python doesn't yet come natural to me. So if you have any comments/feedback/improvements, they're most welcome by e-mail, including any patches.
23 Jul 2016 2:00pm GMT
Based on some encouragement from friends as well as my desire to find more time again to hang out at community events, I decided to attend Electromagnetic Field 2016 held in Guildford, UK from August 5th through 7th.
As I typically don't like just attending an event without contributing to it in some form, I submitted a couple of talks / workshops, all of which were accepted:
- An overview talk about the Osmocom project
- A Workshop on running your own cellular network using OpenBSC and related Osmocom software
- A Workshop on tracing (U)SIM card communication using Osmocom SIMtrace
I believe the detailed schedule is still in the works, as I haven't yet been able to find any on the event website.
Looking forward to having a great time at EMF 2016. After attending Dutch and German hacker camps for almost 20 years, let's see how the Brits go about it!
23 Jul 2016 2:00pm GMT