QR vs. RFID

Why to use QR code as RFID can do all the same and much more? That's true, but it does not mean QR code would be obsolete. There are couple of arguments pro QR.

First of all, number of devices capable of reading QR codes exceeds multi-fold the number of devices capable of reading RFID or do NFC. Potentially every smart phone, tablet, laptop and any device with camera can do QR reading. Only very limited number of mobiles or specific devices can do RFID/NFC communication.

QR code is also ultimately cheap. Even if RFID tags are inexpensive nowadays, I haven't seen any newspaper having RFIDs embedded on pages. But I have seen many magazines having QR codes printed on pages. Sticker with QR codes printed are and will be cheaper than stickers with RFID chip embedded.

QR code is static and one way. Thus there is and will be rationale for both technologies to exists side by side.

Uses of QR code

Everyone knows QR code, possibly most of often at the context of advertisements, a link that leads to a company web site for more information. QR code can do much more than that. In addition to URL, the code can store other information like visiting card, SMS of free text. There are couple of handy use cases in system design of embedded stuff.

URL of the blog. Try it with your smart phone.

Deployment
Let's  assume we need to install a number of sensors or actuators, wired or wireless, into a building or outdoor environment. We don't want to pair the nodes in advance, as then we must pay close attention in which unit to install where. All units are equal as long as they are in the box. Only at installation time they get the association to the place and possible role. How to do that in most convenient matter?

There may be a serial number printed in every unit. Then the installation guy must manually copy the serial number to paper or electronic device. Manual and error prone process. If we put a 1D bar code into each unit, then the process of identification can be automated, but a specific tool with laser bar code reader unit is needed.

Let's stick a QR code with a unique identifier into each unit. The installation person can then use his or her smart phone or tablet to read the code, and immediately associate the specific sensor into the installation location and deliver the info in the system database with help of the mobile data connection of the device. In case of outdoor environment, GPS data can be combined to create geospatial mapping of the installation.

Authorization
Let's consider building automation, for example some sort of equipment installed inside of a building, like heat pump, ventilation unit or A/C. Those are rather sophisticated devices nowadays, with capability to offer remote connectivity, possibly with help of cloud solution. Use of such remote user interface should be as easy as possible, simultaneously providing adequate security and confidentiality.

If a person has physical access next to the device, then we may assume he or she has right to access and control that equipment, at least in some extend - not a completely outsider. If there is a QR printed at the side of the device, that information may tell to the cloud or even to the device itself that the person operating the mobile terminal which delivered the code has access right to the device.

Encryption
In case of asymmetric cryptography, the QR code may contain the public key of the server side. If it is printed and mounted at the assembly line, it most probably is authentic and not altered. With help of the public key, terminal unit may then send it's own public key in encrypted format to the server, and then they can communicate in completely secured fashion, and no cryptographic credentials was ever exchanged in plain text format.

What makes Jolla so special?

Jolla rises from the ashes of Nokia Meego, having second pre-order round ongoing. Jolla differentiates itself from other brand mobile manufacturers in many ways.

First of all, Sailfish, the operating system based on Mer is 100% open source. No proprietary binary code included. If you doubt what the device do, you can always check it from the original source - the source code. That makes it difficult to hide any call-back-home or other nasty features among functionality of the software.

Secondly, as Jolla states they have no operations or servers physically located in the US, and as such they are not oblicated to disclose any user information to NSA. In the past, technical intelligence programs like Echelon were dedicated to listen to trunk networks. As all traffic is nowadays more or less encrypted, it's easier to access the data at  the end-point of communication, where the data is available in decrypted format, and that's where PRISM hits.

Third, Sailfish will provide superior compatibility with applications from different platforms with little or no modifications, including Meego, Android, Unix, Linux and HTML5. That's not only because Jolla-sailors think they can do it, but especially to gain the ecosystem fast. Jolla targets to 500K+ apps at the beginning.

There are many appealing aspects in the Sailfish concept, like support for many programming technologies including Qt, HTML5, Android and many more, and the unique software development and emulation environment, which makes it possible to develop and test Sailfish applications prior existence of the actual hardware, and in any host OS.

From the history we know that technical superiority by itself is not always defining the winning solution. The concept needs much more, like believable and creditable story, the ecosystem, and of course, paying customers. Jolla has still long way to go, but according to some analysts, Sailfish has good chance to beat the market share of Windows Phone. The growth is expected to happen especially in the China and other Asia, where Jolla provides a non-US alternative at the mobile market.

JavaScript for Embedded - Does it make sense?

Espruino - or JavaScript for Things, as they call it - just got its kickstarter funding collected. It's a JavaScript interpreter for MCUs, to be released as an open source SW/HW. First demonstrator already exists and now they are finalizing design and documentation, and to manufacture the board in volumes.

JavaScript interpreter for Embedded is what I have been waiting for. Don't have hands-on experiences with it yet, but it sounds pretty promising. For the Espruino HW board, STM32F103 Cortex-M3 MCU with 256k Flash and 48k RAM was selected. That's way below the bare minimum requirements of Java ME Embedded, that I discussed about in my previous posting.

Now we have three competing approaches for MCU systems:

1. Native compiled C/C++, like mbed for example
2. Java ME Embedded
3. JavaScript for Things, Espruino or similar

Interesting research question is comparisong of the different programming technology approaches from following perspectives (including, but not limited to):

• Overall performance and resource consumption
• Real-time behavior
• Energy efficiency
• Connectivity w/Internet and Cloud
• Reliability and security issues 
• Quality, including testing testing solutions, etc. 
• Productivity of software engineering 
• Ecosystem support

It's really fascinating to see that there is plenty of activity going on around embedded and MCU field. It's definitely not a dead zone.

Java for Embedded - Does it make sense?

Freescale and Oracle made a press release they will jointly push Java to IoT. This makes me interested, does it make sense to use Java in Embedded at all?

I have to admit I have always been suspicious about the usefulness of Java. Historically due to the performance reasons, and nowadays due to the fact that there exists other high-level programming languages that provide better productivity, like Python and JavaScript, just to mention a few.

In the past, Java processors executing bytecode native in hardware were expected to solve capacity and performance constraints in embedded systems. Even if number of such Java processors exists Today, that technology never really entered into the mainstream, and nowadays you seldom hear anyone talking about.

Java ME Embedded is optimized for ARM architecture. The datasheet says standard configuration requires 700KB RAM and 2000 KB ROM, and it is possible to tear it down to 130 KB RAM and 350 KB ROM. I'm not convinced. In MCU systems it is typically crucially important to have full control over time critical execution, and energy efficiency is usually an issue.

Both in super-scalar server systems and resource constrained embedded systems asynchronous programming is more efficient way of using the available resources. Strict object formalism just does not make sense. Loosening the object paradigm then ruins the fundamental idea behind Java.

For MCU systems, I'd choose something like mbed instead. And in case of CPU systems, perhaps JavaScript and Node.JS coud do the job. Actually, that is the architecture I selected for a trade fair and sales demonstrator which is under constructions. Our engineers surprised my by the productivity they gained, and they reported being happy with the technology by themselves too.

I'll discuss more about the demo in next postings.

Edit Oct. 15th:

This seems to be a hot topic in the community as well. First Dr.Dobbs published an article on Oct. 8th: If Java Is Dying, It Sure Looks Awfully Healthy
http://www.drdobbs.com/jvm/if-java-is-dying-it-sure-looks-awfully-h/240162390

Then they received tons of feedback, and wrote a response on Oct 15th: 1000 Responses to Java Is Not Dying
http://www.drdobbs.com/jvm/1000-responses-to-java-is-not-dying/240162680

Refressing to read such a discussion. There is one argument that I want to quote: "Java only appears to be dying because the cool kids prefer other languages". That's most probably true. But then back to my original topic. Terrance Bar from Oracle put's it this way:

""There are 9 Million Java developers in the world, compared to 300,000 embedded C developers. On top of that, more and more products are coming from small startups without specialised embedded knowledge. They do know Java though."

Possible not cool, but there is quite a lot of mass left still.

Mosh improvement

The mobile shell mosh is very convenient substitute to the traditional ssh. I have now test used it in Linux and Android (JuiceSSH) for a couple of weeks. There is one issue that I have noticed. If the client process dies while connection is broken - most common scenario that you run out of battery - the server process does not receive any notification and remains running forever, or until manually killed or system boots. Even if old mosh-servers are running, new mosh sessions will start new server processes at server side every time.

I have now number of such mosh-server processes idling for more than a week. Of course I can terminate them manually, but that is not a generic solution. Consider a general purpose server with hundreds or thousands of users, like a university terminal server. Then you may start getting troubles with all the mosh servers doing nothing but consume memory.

I have recognized two possible solution alternatives. First is the dirty one, implement a timeout at server side that will terminate the server after certain idle period. That's against the philosophy of mosh and SSP, but if you make it user configurable, as a command line argument for example, then it's possibly not such a big crime.

Second solution is more sophisticated, by enabling recovery of existing connection by a new client session. This approach requires security credentials of the session to be stored locally at the client side.  Management of old and new sessions might then cause headache, and I understand that the development team of the mosh didn't chosen this solution. After all, originally it was just a research project at MIT.

I'd accept the timeout approach. The old good screen program takes care of maintaining my persistent session at server, thus I don't see a problem starting a new mosh session after 48 or 96 hours of communication break. I'd would be easy to implement, and would not compromise the security architecture by any way.

Websocket and server-side scalability

Wireless Sensor Networks and Internet of Things are examples of application domains where even millions of end-points may be connected to the same server system simultaneously. If each of them are having a socket connection open all the time, either plain TCP socket or Websocket, it yields a server-side scalability problem.

Every now and then one may hear concerns of having high number of concurrent connections to the server. That's the major argument against use of Websocket that I have heard of. Opponents are typically suggesting polling-type of approach, which ruins the responsiveness of the system. That makes me study the topic further.

In general, any system implemented with any technology can easily handle up to 10k concurrent connections, but beyond that you may get troubles (C10k problem). TCP supports ~64'000 free ports per IP address. One workaround is to bind several IP addresses to the same computer. There are many service providers who claim to support millions of concurrent websocket connections. However, I don't think rely on proprietary solution of a single service is an approach generic enough. Anyway, advanced technologies like clustering is needed, which makes it more expensive for sure.

Let's take a look at the software architecture. Thread per connection approach is insane. Even an object instance per thread is overkill, in terms of memory consumption. Use of asynchronous methods is the only sensible approach for server implementation. But no matter how efficient your server implementation is, each open TCP socket connection consumes proportionally memory in the underlain operating system.

That makes me thinking use of UDP instead of TCP. It is unnecessary to consume the memory of the OS, if all connection-less connections are served through a single UDP port. But then we loose the beauty of identifying connections by IP and Port of each end. Some sort of application layer solution is needed instead.

State synchronization protocol (SSP)  is one possibility. It's based on UDP, and provides many advantages over TCP sockets, like client-side mobility (roaming), persistent connections over vague and temporary networks, and good response. At the moment of writing, the only known application that uses SSP is mosh, a replacement to the SSH terminal.

Mosh is available for many Unix/Linux variants and Mac OSX, but the SSP protocol is not published yet as a general purpose library. One can, of course, extract the protocol code from the open source implementation of mosh.

From embedded systems point of view, like WSN and IoT that I mentioned at the beginning, I think SSP kind of approach could be even better connection technology than Websocket. But as long as your system does not need to scale up to millions of concurrent connections, Websocket is still a good initial guess.