Designing a Low Power LoRaWAN based GPS Tracker

In this post I will explain about the new LORA WAN GPS tracking device we designed for a client in Switzerland. This device is based on the same old VALTRACK-V2 GPS tracker design with a few changes.

Why we selected the Murata CMWX1ZZABZ LoRaWAN module?

This GPS tracker was supposed to use the MURATA CMWX1ZZABZ series LoRaWAN module because it was recommended by a LoRaWAN network provider in Switzerland called SWISSCOM. SWISSCOM recommended this module to our client for proper operation on their network.

Which GPS module is used and why ?

We designed this board with the same GPS module SIMCOM SIM39EA which is used in the VALTRACK-V2 GPS tracker. The SIM39EA has proved itself to be a good performer at a cheaper price.

Found a cheaper drop in replacement for SIM39EA :

I found a alternative for SIM39EA, the Mobiletek N39 GPS module, which is 100% compatible with the SIM39EA module and it’s also slightly cheaper.

This Mobiletek company is started by the founders of SIMCOM and they have foot print compatible modules and functionally compatible modules for the very popular modules of SIMCOM like SIM800C, SIM39EA, SIM800 etc.

Where to get MobileTek modules ?

Mobiletek modules are being sold by

RK Electro Components, Bangalore
DTDS Pvt Ltd, Bangalore

VALTRACK-LoRa Power requirements :

The power input specification for the device was that, it was supposed to work for a very long time running on a non-rechargeable ER26500 3.6V C-size Lithium Battery with a capacity of 9000mAH. There is a onboard 3V LDO regulator which regulates the voltage coming from battery to safe operating levels of the circuit.

Hardware features :

Board size constraints :

There was no size constraints on this board so we made it small enough to hold a C-size battery holder.

Inbuilt Processor :
The device has no extra MCU on board because MURATA module we used is having an internal inbuilt STM32L0 series MCU in which we can write our own firmware which runs along with embedded LoRaWAN stack.

Power/Battery connections :
To accommodate a C-Size battery on board, we made provision for a Keystone made C-size of battery holder on the bottom side of the PCB.

On board Temperature sensor:
We added a LM75 temperature sensor in a TSSOP package on the I2C bus to sense the ambient temperature.

FRAM/EEPROM Support :
A SOIC-8 package Cypress FRAM or a footprint compatible EEPROM can be supported by the device for storing logs or configuration data.

Power control MOSFETs :
Similar to other VALTRACK devices we added a power MOSFET for controlling power to GPS module. This will help in switching off the GPS module to save power when location tracking is not needed.

Slide switch to Connect/Disconnect battery :
A slide switch is provided to connect or disconnect the battery to the circuit. If it was directly connected, it would keep drawing small current when device is not being used.

Micro USB interface :
A micro USB connector is provided which connects to the STM32 USB port and can be used for future development purposes.

Programming interface :
For programming/flashing the MCU, we provided a 2.54mm pitch header connector. The SWD lines of the STM32 MCU on the module are routed to this connector. You can use standard STLINK or JLINK for flashing.

Antennas supported:
U.FL connector is provided for LoRaWAN signal transmission/reception and can be used to connect a flex antenna.
We can also use a U.FL to SMA converter to connect a Whip/Aerial antenna.

Auxiliary Debug connector :
The second free UART port of MCU was routed to a header to print Debug data and it has turned out to be very useful during development phase.

Software development support :
ST provides ready to use libraries and LoRaWAN code examples for End-node and ping pong applications based on their CUBEMX platform which is quite easy to use and configure. All we had to do was to configure this code to interface the peripherals on UART and I2C.

Board bring-up :

Boards worked straight away without any modifications and we were able to run the PEER to PEER firmware and END node firmware provided by ST without any problems.

PEER to PEER ping pong test :

For PEER to PEER application, we got 2 modules programmed with ping-pong firmware provided by ST and took out for testing. They worked quite well and gave range of 1km LOS (Line of sight) with FLEX antenna’s on both side. The GPS accuracy was quite good both for the SIM39EA and N39 this map shows on the testing route we took and the pings that were received.

LoRaWAN End-Node test :

For LoRaWAN END node testing we approached TATA Communications LoRaWAN department since they have already deployed the LoRaWAN network in majority of the cities, we were lucky that they had the network established in Dharwad.
TCL gave a END device specification document which says about the certifications the device should have to use their network.

LoRa Alliance certification :

First one is LORA Alliance certification which MURATA module already has. It’s necessary to be a LORA Alliance member to have LORA certification for your device.
If you and me take a STM32 and SX1276 and build a LoRaWAN module, we still have to go and become LORA alliance member and pay a large amount to get the device as LORA certified, which is disappointing for startups because we will not have that much money to spend on certifications.

WPC ETA (Equipment Type Approval ) certification :

The next certification is the WPC ETA (Equipment Type Approval ) certification which costs about 50K INR in India which is a hurdle for startups.

Unique DevEUI numbers :

The device need to have a unique DEVEUI number which are bought by module makers from IEEE so that each device is unique on a given network, but strangely MURATA didn’t do it and we did not have the DEVEUI numbers for each device to use TCL network. But TATA was kind enough to give us a couple of DEVEUI for testing purpose.

TCL LoRaWAN IOT platform testing :

We got up and running on the TATA LoRaWAN network after programming the keys into the firmware. The devices started sending the data and it arrived on TATA backend. The data arrived BASE64 encoded in JSON format. We need to forward this to our server endpoint and save it there because TATA doesn’t save it in their server, it gets flushed out at regular intervals.

TCL backend gives us an option in dashboard to add a link to our server API to which the incoming LoRaWAN data can be pushed by HTTP post requests. I created a HTTP API on dream factory backend and linked TCL backend to my server. The LoRaWAN packets started arriving on my backend in JSON format in no time. Below is except of data that comes to our server.


 "m2m:sgn": {
 "nev": {
 "rep": "{"m2m: cin":{"ty":4,"ri":"HPE_IoT/1234565/default/54545","pi":"HPE_IoT/4564564512/default","ct":"20190312T111109,
 293000","lt":"20190312T111109,
 293000","lbl":[],"rn":"8541252","et":"20190411T111109,
 293000","at":[],"aa":[],"st":1,"cr":"8845-54534","cnf":"application/json","cs":388,"con":"{
 "userid": "valetronsystems",
 "payloads_ul": {
 "id": 845212,
 "deveui": "1234565",
 "timestamp": "2019-03-12T11:11:09.268Z",
 "devaddr": 123456,
 "live": true,
 "dataFrame": "ezE1LjQ1NTkzOCw3NS4wMjA2ODl9",
 "fcnt": 377,
 "port": 2,
 "rssi": -98,
 "snr": 6,
 "freq": 865985000,
 "sf_used": 7,
 "dr_used": "SF7BW125",
 "cr_used": "4/5",
 "device_redundancy": 1,
 "time_on_air_ms": 77.056,
 "gtw_info": null,
 "decrypted": true
 }
 }"}}",
 "om": {
 "op": null,
 "org": "/CSE1000"
 },
 "net": 3
 },
 "vrq": false,
 "sur": "HPE_IoT/1234565/default/684655",
 "cr": "151545-724fed84"
 }
}

TCL Network performance :

The data arrives at TCL server in real time and the signal coverage is also quite good at our office even though it is on the outskirts of the city.

Why or when to switch to LoRaWAN devices?

The LORA devices are looking quite attractive due to their low power operation and low latency compared to cellular modules. The LORA devices don’t need to connect and register on network like cellular modules (which takes about 15 to 20 seconds) which helps the saving power in low power applications.

Note on MELANGE LoRaWAN modules :

TCL recommends Melange modules since they provides DEVEUI numbers and their modules are approved by TCL to be used on TATA LoRaWAN network.
Looking at Melange device specs, they are bigger and I don’t think they have a built in programmable MCU for user code. I hate to have a bigger module and an extra MCU on board taking up more space.

Pricing difference :
The price of MELANGE module is cheaper or at least 50% compare to the MURATA modules. The MELANGE modules come at about Rs.650/- each and they do not have LoRaWAN certification. When I checked with them, they said they will be doing certification on client requests at an extra charge.

The MURATA LoRaWAN module on the other hand is quite expensive at about Rs.1,500/- which is twice the price of the MELANGE module. But they have an internal MCU which is very useful and they are quite smaller in size too.
Only problem with MURATA is they don’t have a DEVEUI number.

VALTRACK-LORA Pricing :

VALTRACK-LORA is available for purchase on our store – Link to Store

Designing a Low Power LoRaWAN based GPS Tracker – Long Battery Life