The ingredients you need, and also you can find on other commercial tracking devices:
- MCU, here we use a STM32F072 ( 64kb Flash, 16kB Ram )
- LoRa Module ( We use the RFM95W for Europe )
- GPS Module
As energy source you can use AAA lithium batteries ( 10440 type ) or you can use lithium packs that are normally used in drones. These come 5 pieces with charger for less than 20 bucks and offer 720mAh. The drawback is that you need to attach a connector, suitable for the battery. Molex types are most common to find ( 51005 Molex connector ) the counterpart is less often to find on warehouses starting with an “A”, but common cell on flight models as spare parts. So may have a look at a model shop nearby. If you get cells with JST connectors this makes it really easy as you can find more often the prebuild cables online. Also note that it can be beneficial to solder the wires on the top for later easy access to disconnect the cell form the main pcb
Next step will be the placement of the GPS module. This needs to be connected straight over the LoRa-Node pcb.
This will work well if you use the rechargeable batteries for drones. If you are going to use AAA lithium rechargeable batteries this will make it not fit inside the Hammond 1551 enclosure. You can use a Beitian BN-180 GPS module instead. This module must be placed in transparent heat shrink tape to avoid shorts on the batteries
If you squeeze everything in a box the result will look like this
This will be a tight fit for the components a be warned, even if the coil antenna looks nice and small, the radiated power is not as much as with a straight peace of wire. To give some figures, you will lose about 30dBm in this placement compared to a straight wire antenna. This will be a huge difference and reduce the range from 1km down to less than 10 meter. This means an external antenna is highly recommended to good transmission performance. The GPS antenna works decent and will get the job done. An active one with a 28db LNA integrated will help the module to acquire a position faster an can, even that it is using some power, lead to a longer runtime. If you intend to use an external antenna, the whole setup will look like this:
Power usage and estimated runtimeWhen it comes to power usage, you will often find the low µA values for standby. And while we get 150µAh for sleep, powering the mcu ram and have power losses across all components, this is not the worst part. With that we will get form a 720mAh cell, assuming we can get 600mAh out of it, about 4000 hours standby, in theory ( 166 days , so more than half a year). The worst part is the time while the GPS module is working, adding 55mAh to 60mAh to the power consumption. Also the MCU will take 2mAh to 3mAh as well as the short time where the LoRa module will take 100mAh max for transmit. While the transmitter is less than a second, the main amount of power is drawn from the GPS module.
As the lab has really poor reception conditions, a kind of worst case test, the receiver will take up to 10 minutes for a cold start and about 2 to 3 minutes for a hot start. Cold start means that the receiver has no valid information left in his memory about the GPS satellites needed for position calculation and a hot start means that some or even all information are still valid. This leads to an average of four minutes runtime for each position we need to get, and this is what will primarily affect the runtime.
Keeping that in mind the interval used to determine the position will heavy give the amount of runtime we can get out of the battery. There are some ways to get a bit extended runtime. One is the use of an active antenna, that will draw may 5-7mA additional but reduce the time for a position. Another option is to use a bigger enclosure and a battery that will give a higher capacity.
Inside the SoftwareThe software itself is done with the Arduino framework for the STM32. This allows to most of the Arduino libraries you already know for the STM32 and give use access to the TinyGPS++ and the LMIC for Arduino, two components that will be the main core for the software itself. Some other libraries are also included to get everything working. The main disadvantage of using the Arduino framework is the amount of code space used in the end. While having 64kB the firmware will eat up 89% of it, so the room for more features is limited with the current mcu if the Arduino framework is used. Besides this we will have a short look on what modules are inside the software:
We a basic super loop that moves data from the GPS UART to the TinyGPS++. From the TinyGPS++ the current GPS state i polled, and if a valid position is detected, send via the LMIC to the LoRaWAN.
If a certain amount of time has passed, the software will disable the GPS module and send a message with no valid GPS position. After one of these two events the STM will have the GPS disabled by cutting power and enter for a given time the sleepmode. So far this is very easy, but what dose the CLI and why have we no numbers here for the timespans used?
Well within the CLI, that can be access by a USB-Serial Converter, you can setup the parameter. This is the same connection that is used also for the firmware upload to the mcu.
So you can open a terminal software of your choice, like putty or the Arduino serial monitor and start configuring the device
So you can configure the device with the information you get from e.g. The Things Network. For an easy start use APB mode and enter the required credentials. These are the NWKSKEY, APPSKEY and DEVADDR. To set the Device into APB mode just use "set ACME APB". This is basically all it needs, the data rate will be as default SF7BW125, fastest mode, shortest range. You can change this with "set datarate SF9" to use SF9. The rates of SF12 and 11 are not supported as this will void the rules of the TTN for statically configured devices.
All transmissions here will be without any acknowledge form the LoRaWAN ( TTN ). Two things that will have influence of your battery runtime are the GPSTIMEOUT ( default 10 minutes ) , the time that the system will wait to get an valid GPS position, and the interval used to transmit the position ( default 15 minutes ).
The device will transmit the data as a set of bytes to the TTN, the payload has the following format:
The status currently only indicates if the position is valid or not. This format is not ideal but working, as we use fife bytes more than needed with a better data coding.
The setup is working now and if we are in range of a TTN Gateway new data should arrive.