ACTE UK > Services > Knowledge Base > EHS6T Network Scanner

Using a gemalto EHS6T Terminal to make an network scanner

The latest range of Industrial family wireless modules from Gemalto include new 'AT' commands to support greater flexibility and wider usability across various networks. One of these requests the module to perform an "Informal Network Scan".

This is a useful feature to implement and use during product commissioning. Most modules in the Industrial Family range also include an embedded Java Platform allowing designers to run their own applications on the device. The EHS6T Terminal is based upon one of those devices, so with this in mind we decided to make up a little project for ourselves - a kind of 'weekend project' if you wish. Here's where we got too...

To start off, along with the EHS6T 3G Terminal, we needed an antenna with SMA connector, USB cable, and power-supply. Apart from a PC to develop the software application, nothing else is required as no SIM card needs to be inserted for this application.
During the software development stage we used our standard mains PSU. However we knew that for field testing and any use thereafter we'd need to find something more suitable to power the Terminal from our PC. Finding a suitable DC to DC converter to generate 12V (or at least between 8 and 30V) from a USB socket turned out to be the hardest part of the project!
All on-board..

As mentioned above, the EHS6T supports embedded Java applications, and it's this capability we will use for the network monitor application. To keep the overall project simple our intention was that the 3G Terminal would just 'fire out' the network scan results for viewing on the PC with any terminal-emulator application.
For the 3G Terminal to PC comms link we prefer a USB cable, as once the device drivers are installed on the PC this is easier to implement physically than using the RS232 Serial and adaptor cable.
AT Commands and Java Applets

"INS" AT command and response


Processed results from Java Application

The SDK for the EHSx devices is supplied with the Com.Cinterion.IO library which includes an AT command Class and Listener interface to access the modules AT command interpreter. Together these allow us to execute the AT command(s) we require and receive the response(s).

The application initially confirms that the wireless module is neither registered or trying to register onto a wireless network as the Informal Network Scan can only be performed if the module is not registered onto a network. After confirming this the application passes to the section where it performs the INS and outputs the results a couple of times. Repeating the scan normally shows only slight variation in results however we repeat the process several times in case a user wishes to reposition the antenna and easily re-test.

The application sends the required command to start the INS: AT^SNMON="INS",2  Examples supplied with the SDK show how this is done. To the left you can see what happens when the command is requested over the normal AT Command interface (say, via a COM port). Each network that is found has a single line entry in the response.

The command takes a while to complete (several minutes if there are a lot of networks available) and the response is received in several 'chunks'. This means we that in this instance we need to use an asynchronous method to capture the complete response to the command. So the ATCommandResponseListener rather than the ATCommandListener method like in the examples provided with the SDK.

As soon as we know the INS command has completed and the full response captured (the response is terminated with 'OK' like most other AT commands) the response can be processed into something more readable.

Each network listed in the response includes an identifier as to its frequency band, we thought it would be good to include this in the processed results. However we still wanted to display a list of 2G and 3G networks in their respective order of signal strengths, and with each 2G / 3G type occupying two frequency bands the process of parsing results took a little bit of thought.



In reality this was a simple application and apart from catching some possible exceptions we haven't done a lot of tidying up of the code. It runs, it terminates and the user can pull the plug.

What this does demonstrate though is how easy it is too extend the capabilities of an existing product design using Java-enabled wireless modules. With the large memory and processor resources on hand, the application could have been much larger or the processing and/or memory requirements far greater. Even though it may never have been envisaged to utilise the Java capability in an original design, adding this level of capability in the module could be far easier that in a host micro-processor.

We could have taken the application further of course, adding more results or methods to display them or making the application interactive. For now though carrying out accurate testing is a good start. And while a smartphone / app and crowd-sourced results may be useful, this is the real advantage..... the hardware and antenna here are closely representative to that of an embedded module design, and can be positioned very close to the target location (an external antenna with cable can be easily be used).

First outdoor testing with the DC-DC converter. That conifer looks like it needs a little TLC next.


<- Back to Knowledge Base

© 2018 ACTE