Fully automated model train control

Santa visited our place this year as well, and brought a model railway to my son. How an earth the Santa got such a clever idea?

When watching the train running round and round the loop, I started to think about a full automatic control of model trains. Core of the problem is how to measure the exact position and speed of individual trains at any given time.

Little train engineer operating the new Christmas present and my old model train from the 80's.

When investigating the topic further, it look's like all the technology in use dates back to 80's. Digital Command and Control (DCC) is the most common digital control system of the day. DCC uses tracks to carry electrical signal, in form of pulse width modulation of alternating current provided to the locomotive. The technology makes it possible to instruct several individual trains running at the same track simultaneously. DCC is one-way only, thus control station can only instruct the locomotive - speed and direction - but does not get any feedback.

There are some hacks like Selectrix, which brings return channel, but that only enables identification of which locomotive is present at certain track section, not more. Recently, model train manufacturers have introduced entry-level battery powered train sets as well. As there is no galvanic contact through the tracks, such sets can use wireless control only. Earlier that was based on  Infra-Red, nowadays an RC of some sort. As the system is totally unaware where the train is going on, it's only up to the human operator to control each train - no chance for automation.

Traditionally control and signalling of trains - real ones - is based on fixed blocks of track, varying from kilometers to tens of kilometers in length. Only one train can occupy a block at a time, and one free block is required in between two occupied blocks. That's how it was 100 years ago, and that's how it is Today.

Moving block signalling is a newer system, which defines in real time a safe zone in front and back of a train, depending on the speed and location of the train. At the moment, the systems is use only in some subways and light rails, but no "real" railway uses it, much due to safety concerns, as the technology is not considered mature enough for trains traveling 200km/h or more.

Back to model trains. How the get the exact positions of a train? RFID is possibly the most obvious solution. It provides also identification of each train, and identification of each car also if necessary. However, that can recognize the location in certain spots only, and as such is only good for traditional style of reserved blocks type of signalling. Something more advanced is needed if moving block signalling is required.

Machine vision is one option to locate trains, and most likely it works well if all the tracks are running in the same level. However, in case of multi-layered rail systems with possible tunnels, it is very hard to arrange a proper configuration for vision systems to trace every train in real-time.

There is a solution. A model train can locate itself very easily by counting the sleepers (crosstie) it passes by. Fixed calibration points are needed of course, RFID can serve for that purpose. How to count the ties? It's rather easy with optical methods if there is enough contrast in between the tie and underlain material like ballast replica or plain plywood. If the top surface of the tie and the underlain surface are uneven, just a simple angle reflection detector is enough.

Well, it's not enough if the train by itself knows how many ties it has passed since previous calibration point (RFID). The train must somehow inform the control system as well, to let it know the overall situation. RF communication of some sort is needed to provide two-way communication. 2.4 GHz is a good choice. It is globally available frequency, and the RF characteristics are proper; the link length is adequate, and the data rate is well good enough for several trains to communicate simultaneously.

For the purpose, Zigbee, Wifi, Bluetooth and Bluetooh Low Energy are all equally good. Proprietary systems can work as well, but I'd prefer a standardized technology with several component vendors. The choice is only question of cost and energy consumption. Luckily, if trains are powered from tracks, the power consumption is not a major issue.

Now, it's all about the control software. All the existing model train control software, commercial or open source, are based on the traditional signalling system with reserved blocks of rail. Implementing a totally new control software with real-time location and speed control requires a group of talented people interested in the same topic, or someone seeing enough business potential on it. I really doubt the last one and count on only creating an open source community around the idea.

Anyone interested in the idea can contact me.

Procket in Youtube

Our first YouTube video:

http://www.youtube.com/watch?v=xOhChE4zQ4o

It's about our production test solution called Procket. I'm quite proud of it.

Boot to Qt, but how to install?

Digia released latest version 5.2 of Qt recently in December 2013. The Boot to Qt (Qt Enterprise Embedded) and Qt Mobile sounds interesting, thus I decided to check what's up, but that's not so easy.

Qt Development environment only supports 64-bit platform, however some dependency libraries requires 32-bit environment. First I considered using my Chromebook, but it has 32-bit ARM cpu, so it's out of the question. Then I decided to run virtual machine in my 64-bit Windows7 laptop. I installed Virtualbox and created a virtual machine running Ubuntu. However, for a reason unknown to me, it only accepted 32-bit version of Ubuntu and refused to install 64-bit version.

Finally I decided to make it safe and install native single-boot Linux into my old Intel CoreDuo 64-bit laptop. At the time I didn't had a proper Linux PC available, thus I had to use Windows application to create bootable USB memory stick. Ubuntu web page links to Universal USB Installer. The UUI tool has selection for multiple distributions. However, it does not ask for how many bits you have or wish to use.

By default, UUI installs 32-bit version of Ubuntu into the memory stick. I didn't noticed that, untill I had the OS up and running in my laptop and trying to install Qt. So, once more re-installing Ubuntu in order to have proper 64-bit variant. As Qt installation instructions says Ubuntu 12.04 LTS and later are supported, I selected the latest 13.10 version of desktop Ubuntu.

Here comes the tricky part, as I said at the beginning. Even if Qt development  environment supports only 64-bit host platform, it requires some libraries working only in 32-bit environment. In order to do that, there is library called ia32-libs in Linux, which is one of the prerequisite of Qt installer. However, that library is removed from the 13.10 release!

Here is a posting explaining the reason: "The ia32-libs package was a hack to get 32-bit packages installed on a 64-bit installation. Since Ubuntu version 11.10 (Oneiric), Multi Arch has been added. One of the objectives for it is removing the ia32-libs package. Instead, you have to install the 32-bit libraries of a package with: sudo apt-get install package-name:i386 "

So there is a way to install 32-bit libraries in 64-bit Linux, but the Qt installer just doesn't know how to do that! The installation crashes after an hour or so from the start. So, I end up re-installing Linux into my PC once again, this time the 64-bit Ubuntu 12.04 LTS, which appears to be the one and only supported platform. Let's hope better luck this time.

What is the lesson here? Claiming the PC world is 64-bit only is as reasonable as claiming the Internet is IPv6 only. Even if 64-bit and IPv6 are good goals, one can not decline the legacy 32-bit and IPv4 world still exists strongly. If ever Qt development environment would support 32-bit platforms in the first place, I wouldn't have had the hassle at all.

Edit Dec. 15:
Before re-installing Ubuntu, I tried to re-install Qt environment . This time the installation succeeded, thus looks like it was just a random fail at the first try. Awfully slow the Qt Creator is. Don't know yet why.

Wifi vs. Bluetooth in HMI connectivity

When designing a user interface for a building automation appliance, often there arise a question should I provide a local UI at all as majority of my target customers already have a tablet or smart phone of some sort which can be used for the purpose?

If you decide that a non-local mobile UI will be provided, as only or as a supplement, number of new questions arise.  If I select Apps approach, which platforms should I support, and how many Apps for different platforms can I support? At the topic of the posting; should I select Wifi of Bluetooth as the technology for the connectivity in between the appliance and the UI terminal?

Traditionally I have favored Wifi, but recently I have considered that perhaps Bluetooth is better in some cases, especially from usability point of view. I have a personal example here:

In my car, I have an OBD2-Bluetooth dongle and in my smartphone I have an OBD application installed. Whenever I'm sitting in my car, it is very convenient just to take the phone from my pocket and launch the App simply by tabbing the icon, and then I have instant access to measurements and diagnostics of the vehicle. Very easy to do. After initial bluetooth pairing I do not need to do any other configurations when using the function.

Recently, I purchased an Android/iPad controlled wifi RC-car with live video streaming. At local retailer it costs only 30€. The toy has Wifi access point embedded. Yes, Wifi has bandwidth enough for live video stream. But on the other hand, the usability is not that good.

Prior launching the App of the car, first I have to manually change the Wifi network in order to have connection to the car. That's doable, but more inconvenient is that whenever I'm having the toy car powered up, my phone tends spontaneously connect to its access point instead of my home wifi. So, when I'm then supposed to do some internet surfing, I find myself having connection only to the car. And once again changing the network manually.

Wifi Camera Buggy from BeeWi

If I'd have a direct wireless access to my air conditioning, ventilation, heating, etc device, I'd definitely prefer just simply launching an App, instead of struggling with the network configuration first. Of course, there areissues like location of the connection point, regarding to signal strength and link distance, etc. which are to be taken into account when doing design choices.

Why not to use the Wifi of the appliance in device mode and connect to the existing Wifi infrastructure of the home? Well, that's one possible way of thinking. However, configuring wireless network when having wireless network connectivity only sounds like a shooting your own leg. I could only imagine how vendor of such product sinks into the flood of customer support request: "I tried to configure the network, and now I have lost connection to my device altogether. What I'm suppose to do now?"

I claim that from usability point of view, Bluetooth can be better option that wifi. The downside is that in generic case, Web UI can not be provided over Bluetooth, but a specific App is needed instead.

Industrial Internet for Test systems

Last week at Nordic Test Forum in Tallinn, Espotel and Virinco released co-operation in providing remote management for production test systems. Press release (pdf).

Virinco has spent 10 years developing a world class tool software WATS for test results collection, data analysis and presentation, and remote maintenace of test stations. WATS is available as cloud service SkyWATS and  on-site installed service. Greatest added value of WATS is that brand owner sees what's going on in the production, in reality and real-time.

Espotel provides state of the art production test systems under Procket brand. Together with WATS remote management, Espotel can provide turn-key solutions for production testing. Together, we have several promises:

• Your product: Tested in production
• Your data: Analyzed in real-time
•  Your tester: Maintained

Why should product owner own the test system in the first place? Especially if production is outsourced to Electronics Manufacturing Service (EMS).

First of all, own tester gives flexibility and independence over EMS. Production is easy to transfer from one facility to another, and to multiply to several facilities administered by different EMS companies. And what's most important, quality of production is guaranteed, no matter where it happens.

Owned test system provides also possibility to have real-time visibility to production, and possibility to improve product design if necessary. Why does that matter if we pay to the EMS only for functional units delivered? Well, the customer pays for the discarded products as well, one way or another.  The better the yield the lower margin the EMS needs to maintain profitable business.