Nearly every embedded system I have ever built has required a graphical user interface (GUI) to monitor and display telemetry. Monitoring telemetry during development can help developers to visualize what the system is doing and play a critical role in verifying and debugging the system. Telemetry in this context is any health and wellness information that the system can transmit and may or may not be deployed with the final product. Developing a GUI today is dramatically changing. In this post, we will explore a few tips on how to modernize your GUI tools.

Tip #1 – Leave the Application Behind and use a Browser

GUI’s used to be standalone monolithic applications written in Visual C++ or even LabView. While there is not necessarily anything wrong with that, there are issues sometimes with cross compatibility between platforms. Today’s developers might want to collect data on Windows, Linux, Mac, iOS, Android or some other OS. Trying to support all these is a nightmare.

The solution is to use a server based back-end that can collect telemetry from the embedded system and then serve up a webpage to display and interact with the device. This has so many advantages over the old way of doing things such as:

• Compatible across any device with a web browser (with a network connection)
• Connecting and merging multiple data streams
• Multiple simultaneous data viewers
• Ability to host in the cloud (but can be local)
• Leverage open source scientific and engineering libraries

The browser is where is where it is at and it’s flexible, scalable and cross platform.

Tip #2 – Write the GUI using Python

Python has taken the programming world by storm. Interns, junior and senior level engineers all know it and use it. Using it to write a GUI only makes sense but it’s more than just who understands the language. Python offers developers a plethora of libraries and tools that can be used to write the backend, serve up web pages and integrate multiple data streams. I’ve also found that many companies also use Python to analyze the data that they collect, so using Python for the GUI can help minimize the additional programming languages that need to be known and the maintenance effort.

Tip #3 – Store Telemetry in a Database

The go to format for most developers is save their telemetry data into a CSV file. It’s simple and straight forward. Unfortunately, it’s not always the fastest and at times there can be potential issues such as throughput and read/write times. Connecting a database to the telemetry server can be a fast and flexible way to save data and then easily query, analyze and display that telemetry.

I know that embedded developers who are working with a GUI will often hesitate to go straight to a database, so it’s important that behind the scenes developers create an abstract interface for saving the data. Behind the interface, the initial saving method could be a CSV file and once the GUI is built out, a database can be put in place. Using the abstract interface will make it so that the GUI doesn’t care and is not dependent on the method used to store the data.

Tip #4 – Add Analysis Hooks

Earlier I eluded to the fact that using a server back-end has some really cool potential. With data being collected on the backend, it can not only have conversion factors applied to it, but the data can be served up for all kinds of analysis. Integrating an engineering library can allow the streaming data to be converted, averaged, filtered and so forth and then the results can be served up to the web browser to provide engineers and users with real-time telemetry data that they can use for debugging

These hooks can also serve up data to other analysis packages that allow the data to be plotted and reviewed after data collection. Typically, a GUI just displays the real-time data over some time period, analysis hooks can allow all kinds of interesting transformations to be performed on the data over longer periods that what is typically kept in a real-time grap

Tip #5 – Add Verification Hooks

One unique use case that I’ve used is to build in the ability to script commands that can be sent to the system in a sequence. This type of capability provides the developer with the ability to test the system and also put the system into potential boundary state conditions easily without having to write a bunch of custom firmware. In fact, the GUI can take on a second life as an assistant to the verification team who need to verify that the system functions as expected.

The verification hooks can also be used to detect faults, set faults and then test how the system recovers. This converts a software package that is typically used to display data only into a much more versatile tool with little added complexity and that can be compartmentalized.

Conclusions

Telemetry GUI’s are often required to monitor how an embedded system is functioning during development and sometimes even during production. The techniques that have been employed are rapidly changing, with a much greater emphasis being placed on portability and scalability. Leveraging a web browser and server backend for a telemetry GUI is a fantastic way to modernize your GUI’s and ensure that they will be flexible to handle upcoming needs for years to come.