+46 18 660 700
Would you like to be contacted?
Quarterly Bulletin
Carrier board development

Wireless COTS modules


The GPS module arrived in the mail and needed an instant test to verify proper operation. Designers had to make do with a GSM antenna. The Linux software gpsd was downloaded to handle communication between the GPS module and the computer board. When the antenna was placed on the window-ledge and the coordinates received were entered in Google Maps, the mark pointed at the correct end of Hectronic’s office building in Uppsala, Sweden.

The strategy for easiest possible testing also proved to be the fastest way for system integration in the project. Familiar communication interfaces, ready-made drivers and certified wireless modules is the way to go if you need wireless technology to gain competitiveness in your embedded system.   

The reasons to go with wireless modules are fairly similar to choosing a semi-custom strategy using a COM module on a custom-made carrier board. No detailed skills are needed to make wireless technology happen. Evaluation is fast. Scalability and modularity comes natural and the supplier can be trusted for module life cycle management. 
The choice of module is generally not about picking preferred properties from a datasheet with a list of functionalities, or about getting enough performance. It’s not about hosting the modules on high-end computer boards either. Low-end X86 processors and ARM is enough. Choosing the proper module and communication interface is instead your possibility to simplify system integration. 
Hectronic has recently developed a couple of embedded systems including wireless technology for use in automotive applications. This article is a summary of our experiences from those projects. The systems described in the text are slightly altered not to disclose sensitive customer related information.

Developing an Onboard Public Transportation Server

Let’s have a look at one of the projects developing an Onboard Public Transportation Vehicle Server. This application was intended for use in public transportation vehicles like buses and trams.
Block diagram - Automotive embedded system

Click to enlarge the picture


The picture shows the functional block diagram. Functions required include voice communication and logistic information updates between driver and central, passenger announcements controlled by vehicle position on the route and Internet connection to passenger laptops.

UMTS, GPS, Bluetooth and Wi-Fi were used in the application. Choosing wireless technologies to match the functional requirements was easy. Picking out suitable modules for the respective wireless functionality was part of the challenge.

Choosing wireless modules

Actually the communication interface was the main reason behind the module selection. The hard earned experience is that a preferable choice of interface is one that has been around for a while and is widely used. That’s an interface likely to have proven drivers available for a selection of operating systems. A suggestion is also to pick a familiar interface, one that you have prior experience with to ease the system integration.
COTS wireless modules - Interface and application comparison

 Click to enlarge the picture


Table of COTS modules for wireless technologies, their respective areas of use and the interfaces typically available to integrate the module in an embedded system.

Typically wireless modules are offered in different interface versions. Some have multiple interfaces integrated. Serial port using TTL logic levels and USB are the most common. Modules using SPI are out there, but be ware. Hectronic learned the hard way that SPI may be the more difficult to use, possibly since not many customers use them and the drivers are therefore not as mature as one would wish for. Hectronic evaluates all drivers used in our projects. So should you.

USB is fast enough for high-speed wireless data communication modules like 3G. UART for instance is not fast enough for UMTS at 7.2 Mbit/s. If the communication speed is to the lower side, as for GPS, a rudimentary interface is sufficient, for instance UART or I2C. USB generally is a favorable choice. It’s a common, well-known and widely spread interface. Integration is easy due to high-quality drivers and an easily routed single differential pair. If you are using a highly integrated small processor with UART, a serial TTL interface would be the best choice.

Make things easy for yourself and pick from the interfaces readily available. Avoid discrete UART to keep cost down. The future for UART in wireless modules is doubtful. GSM/GPRS modules often have UART, but that’s often not the case for 3G/UMTS.

Choosing communication interfaces

The system in the example below uses a Hectronic H6049 Qseven form factor module with the Intel® Atom™ processor. The H6049 module has numerous USB ports available for use. Choosing USB for the 3G/UMTS module was an easy pick since it’s fast and the most frequent interface used in existing 3G/UMTS modules.

USB and MiniPCIexpress was considered for the Wi-Fi/WLAN module. The system needed possibilities for future expansion and for that purpose a cable slot using PCIexpress was chosen, simply leaving USB also for the Wi-Fi module.

The picture below is a block diagram of the final implementation of the Onboard Public Transportation Server.
System implementation - Intel Atom based H6049 in vehicle server

 Click to enlarge the picture


System implementation of Onboard Public Transportation Vehicle Server.


Wi-Fi module operation below 0ºC

The customer in question had the strict temperature requirements always found in the automotive industry. The GPS and GPRS module proved to meet the temperature requirements, -40ºC to +85ºC. The Wi-Fi module was another story. Wi-Fi modules are typically for commercial use. Industrial grade options exist but were too expensive in this case.

The customer accepted to mitigate the requirements since it’s unlikely to find passengers in the need of an Internet connection in a bus where the inside temperature is below 0ºC. The system design avoided any problems from a module in operation outside its specified temperature limits by simply turning the Wi-Fi module off at low temperatures.

The datasheet from the supplier didn’t suggest how the module could be expected to behave in a disabled state. A series of tests in a climate chamber were needed to assured that the disabled Wi-Fi module didn’t interfere with communication on the other interfaces.

Socket and board-to-board - Designing for scalability

The Onboard Public Transportation Vehicle Server needed to be scalable in terms of the wireless technologies integrated. The objective was to be able to offer the customer different versions of the product. In this aspect the encapsulation and mounting of the modules plays a key role.

Wireless modules are mounted on the computer board either by soldering, in a socket or a contact board-to-board. Soldered modules are cheaper and in many ways the more robust choice. Socket or board-to-board mounting adds scalability and flexibility to the system. Suppliers often offer different types of modules mounted in the same type of socket.

Socket and board-to-board mounting add yet other advantages if the final product needs to be available in versions using a variation of wireless modules. Manufacturing and stock-keeping of one main hardware with sockets and contacts is cheaper than the case with numerous complete hardware versions. The different versions needed are simply realized during final assembly by adding the requested modules and downloading the relevant software to complete the product version.

The suppliers of wireless modules in this example also offered the drivers necessary for operation under Linux using USB. The integration was rather simple. The next example from Hectronic’s track record of embedded systems development including wireless technology turned out to be trickier.

Developing a Transportation Management Node

First thing’s first. Let’s take a look at the functional block diagram to familiarize ourselves with the concept.
Block diagram - Transportation management node

Click to enlarge the picture


Functional block diagram for a Transportation Management Node. A few examples from the list of requirements are battery enabled operation for at least two weeks, module enable/disable to save power and a system design adapted for future large volume production.

Strict demands for low power operation and yet the use of a Linux operating system was the basis for choosing the Hectronic H6042 CPU module based on an ARM9 processor from Atmel and a low-end Xilinx FPGA mounted on a custom carrier board.

At this stage the design strategy was semi-custom with a future option to go full custom for cost efficient large volume production. Hectronic has the technical control over the H6042 module enabling a smooth integration of the design in a full custom computer board. In a full custom version of the system an ASIC would replace FPGA.

Linux was part of the specification from the customer and added major advantages to the project.

Making use of ready-made Linux functions

Data communication between the wireless module and computer can definitely be developed in-house, from scratch. The downside when choosing the do-it-yourself path is an immediate risk to spend frustrating amounts of time in endless complications and debugging.

To developers not yet experienced with Linux or Windows development in embedded systems, the amount of integrated functionality and ready-made software already available on the Internet can be surprising.

The gpsd software is a neat example. gpsd handles the communication with the GPS module and supports NMEA 2000. NMEA 2000 is a standard for serial communication in marine electronics governed by the National Marine Electronics Associations. The majority of GPS modules on the market support the relevant parts in NMEA 2000.

gpsd saved lots of time in this case. The module was kick-started in no-time and started to deliver coordinates. The system integration was quick and easy.

Another advantage from using Linux was the ease of which data communication and connection to the GPRS network was accomplished. Using the PPP (Point-to-Point Protocol) in Linux together with a script and configuration parameters received from the operator, the Internet connection is easily established. Once the Internet connection is there, the actual communication is run over TCP/IP, using the BSD socket interface available in Linux.

That was a couple of examples showing the benefits from using for instance Linux. Now let’s take a look at the implementation of the Transportation Management Node.
System implementation - ARM based H6042 in Transportation management node

Click to enlarge the pictur


System implementation of Transportation Management Node.


Experiencing problems with SPI

The available interfaces were shared between the three wireless modules. SPI was the only interface available to use with the GPS module. The SPI driver available turned out not to be that easy to use. Complications arose. It’s our guess that SPI is the less used interface by designers implementing GPS and that therefore the drivers where less tested and debugged in practice.

The module supplier confirmed problems using SPI with the module. They are working to solve the problems and will do so in future generations of the product

The problems were solved by hardware and software engineering creativity but the time would be better off spent on other aspects of the design. So the lesson learned is to use only common interfaces and to thoroughly verify drivers in laboratory trials.

WLAN is used as a complement to GPRS for data communication. It’s favorable since it’s fast and it’s free, with no fees from a telephone operator. Why not avoid charges if possible?

Managing low power requirements

The Transportation Management Node had strict requirements for low power operation to work on batteries only, for at least two weeks. This called for a close investigation in power consumption in the various parts of the system. The power budget in the picture below was an important tool to get the full picture.
Power budget for Transportation Management Node

Click to enlarge the picture


Power budget for Transportation Management Node. The table includes an investigation of power consumption in different operational modes to ensure, for instance, the system requirement of two week system operation on battery power.

The table shows voltages, currents and power values for various operational modes. Separate voltages made it possible to evaluate power efficiency for the parts of the implementation individually. A challenging fact is that voltage regulators sometimes show major variations in efficiency depending on power consumption. One regulator may indicate favorable values at 2 A but be a disaster at 2 mA. An option to consider is to use a microcontroller to monitor basic functionality to save power by waking up the powerful CPU only when necessary.

GSM/GPRS modules are relatively power hungry. Peaks of 3-4 A come in clusters and challenge the power supply. High speed voltage regulators and major bulk capacitors are the solution to the problem. 500 µF may be needed to support the module with sufficient energy during short periods of time.
Wireless communication integrated in any system runs a risk of EMC complications. The straight forward strategy to deal with it is to choose wireless modules among the ones already certified according to the regulations for the application at hand. Regulations applicable are determined by the area of use, the particular wireless technology applied and in which countries the product will be used.

Hectronic has brought a number of automotive products through the e-marking process for automotive applications.


To conclude this, our sharing of experiences from implementation of wireless technology in embedded systems, there should be no doubt that wireless technology using modules should be considered an option. Wireless modules are the way to go for companies that need additional functionality and new areas of use in their products. The modules are advanced RF technology well-packaged and ready to use where needed. Merely put an effort into choosing the module and what interface to use, draw advantages from software already at hand and it’s likely that the system integration runs smoothly and without time-consuming and costly complications.

Market segments

Meeting requirements from industry sectors.
Learn more


Promoting a deeper understanding of technical possibilities at hand.
Learn more

Case studies

Development and production for industrial customers.
Learn more

Bits & Pieces bulletin

Technical articles, inspiring case studies product news and updates. B&P is distributed quarterly to registered users.


Enter your e-mail address and click subscribe.


Find us on
Hectronic AB | Phone: +46 18 660 700 | E-mail: info@hectronic.se | Sitemap | Cookies
© 2017 Hectronic