The Abeeway 1WL development kit is dedicated to geolocation through various means such as GPS, GPS sniffing, WiFi sniffing, radio triangulation, BLE sniffing…, using the different components of the Murata LBEU5ZZ1 SiP module and Actility’s ThingPark geolocation platform, which gives meaning to the raw listening data. Abeeway is a key player in fleet tracking solutions, providing both a business platform and hardware solutions for this purpose.
Through Actility/Abeeway, I was able to obtain an evaluation kit whose main goal is to simplify access to these multiple geolocation technologies for the rapid development of customized tracking solutions.
Murata module LBEU5ZZ1WL (1WL-633)
The development kit is based on the Murata LBEU5ZZ1WL module (yet another simple name like the ABZ). There are two models in this range: the simpler one does not have its own GPS chip and relies on the sniffing capabilities of the LR1110, while the second, used in the KIT, the 1WL-633, includes an MT3333 GPS chip. Below is the general architecture of the module:
This module is not yet available on platforms like Mouser or Avnet, so I have no idea of its price. However, given the complexity of the components included, it is not expected to be a very low-cost solution. In small quantities, the STM32WL and the LR1110 each cost around $5, with the MT3333 at around $4, bringing the overall solution cost to about $15. This represents a significant chip cost but provides access to very advanced features that can lead to substantial gains in terms of design and certification. It’s important to consider the overall costs in this type of approach—make or buy, in this case, buy.
The module is composed by a STM32WB55, this ST Microelectronics MCU drives the solution and embed a Bluetooth stack. It’s a really low power MCU, perfect for long life logistics application, based on a cortex M4, it has 1MB of flash memory and 256KB of SRAM, allowing FUOTA (Firmware Update Over The Air).
The Semtech LR1110 component is a radio component that supports LoRa modulation as well as LR-FHSS (used notably for satellite communication) or Sigfox. It also enables listening on GPS and WiFi bands to perform geolocation, which will be calculated by a backend such as the one provided by Actility for GPS and databases like HERE or Google for WiFi, which are integrated into the Actility solution. These geolocation systems have the advantage of being energy-efficient (a simple listening of a few seconds without the need for prior synchronization data is sufficient). From a WiFi perspective, the indoor localization is quite good, usually within a few tens of meters, and can be improved with BLE support from the STM32WB. From a GPS perspective, simple listening is a good energy-saving compromise but generally results in an accuracy of several hundred meters.
For this reason, the module is complemented by an MT3333 GPS chip, which allows for complete GPS signal decoding and outdoor accuracy within about fifteen meters, at the cost of much higher energy consumption since GPS requires prior synchronization of ephemerides, which typically requires reception in good conditions for more than a minute. You can get more information about the geolocation technics in a previous blogpost “IoT – The tracking use-cases“
I have seen in other documents that the solution could integrate a secure element to protect keys and identities. The solution would also include two TCXOs, one for LoRa modulation and another for the STM32WL. These are necessary, but they do increase the cost slightly. It’s a bit regrettable that a small EEPROM wasn’t added, as it’s a missing feature in the STM32WB and STM32WL, which require simulating an EEPROM in flash to avoid rapid aging and premature failure of the components. It is also surprising not to find an accelerometer, which is widely used in tracking and inventory solutions to save energy.
As for the rest, we can identify the RF control circuitry that leads to three antennas: a 863-928MHz radio antenna used for LoRa communications, a 2.4GHz antenna that is shared between WiFi and BLE and therefore between the STM32WB and LR1110 components, and a GPS antenna with a SAW filter stage and a low-noise amplifier (LNA) shared between the LR1110 and the MT3333. Although the LR1110 has Bluetooth listening capabilities, it appears that only the STM32WB is used, which makes sense for both energy efficiency and functionality reasons, as the STM32WB also allows BLE transmission.
The solution operates at 3V, but there is currently no information available regarding its deep sleep power consumption in the technical documentation.
The Abeeway 1WL development kit
This development kit is therefore centered around the Murata module and provides easy access to its programming and I/O for developing a proof of concept for a tracking solution, for example. Abeeway provides a development kit (SDK) that allows for easy integration with their tracking solution and, more generally, with Actility’s platform (ThingPark), which transforms the raw data received by the hardware into a usable GPS position by making the most of GPS signal decoding and HERE databases.
From the User Manual, a synthetic view:
We can see the integrated ST-Link, useful for programming the embedded STM32WB directly without to connect plenty for wires. We also have 2 other USB connectors, 1 directly connected to UART so you don’t need to have an extra FTDI and the other connected to STM32WL USB if you implemented it like for firmware update or simply as an UART for the configuration.
We can see 4 leds and 2 switches accessible for applications, a buzzer and 2 sensors. The first one is a LIS2DW12, an accelerometer, covering the identified shortcoming within the main module. The second is a LPS22HB, a barometer mostly interesting for the plane transport applications, in includes temperature sensor w/o given accuracy. The board also has a 16Mb (2MB) SPI flash, supporting over 100K write / erase cycles, where to save GPS position history as an exemple.
The board includes a Li-ion/LiPo battery charger with a voltage reference of 4.2V, so it is possible to take the board into the field with batteries and either recharge them or harvest energy. Alternatively, the board can be powered through the USB2 or USB3 ports, which are used for the STM32WB and the ST-LINK, respectively. Care must be taken not to connect these two USB ports to different computers, as the 5V reference voltage might vary between them. The battery voltage can be measured through a voltage divider by two on VBAT_SENSE.
In general, I would criticize this board for having a silkscreen that is too thin, making it difficult to read the numerous references. I had to refer to the schematic multiple times to understand what is where. A minor detail, but in 2024, it would have been preferable to have USB-C ports.
Below the evkit board main features (from thingpark documentation hub)
The Abeeway firmware
Operating on the Murata module, Abeeway provides firmware that allows for quick use of the kit. Pre-installed on the evaluation boards, it is also easily configurable through a text-based user interface accessible via a serial terminal.
The USB port are used the following way:
- USB1 is a debug port, on my version it displays the GPS traces
- USB2 is the interface port where to type commands (57600bps / 8N1)
- USB3 is the ST-LINK port
One rather surprising aspect is that if you want to access the USB configuration interface, it is necessary to first connect USB3, which will provide the power, even though all the USB ports are capable of supplying the 5V power. I’m unclear why.
Once connected to the system (type enter to get the login command), identify yourself as an admin with the login/passcode 456 then we can setup a LoRaWan configuration ; you can obtain credential to Helium network on helium-iot.xyz as an exemple.
super> provis lora set nwkkey b3df398e939520bee432291xxxxxxxx
OK
super> provis lora set deveui 1c21efc43f45xxxx
OK
super> provis lora set joineui 94b9e716a5f0xxxx
OK
super> provis lora save
OK
super> lora open
Lora open done
OK
super> lora join
Joining lora...
OK
super> 0d,00:12:12.801. (LORA) Join success
I’m not fully sure but in my test, after changing the LoRaWan settings, I had to reboot the device to have it considered.
The CLI interface allows control of the subsystems, whether it’s WiFi or BLE sniffing, or LoRaWAN communication, as demonstrated above. This makes it fairly easy to showcase the capabilities of the devkit, but it does not allow for the creation of a no-code application (such as identifying a position every 5 minutes and sending it via the platforms provided by Abeeway and Actility). For that, coding and the CubeMX IDE will be necessary.
To be continued
I realize that this article has been waiting for publication for a while. I had planned to do more experimentation with the module, which is really great for tracking applications. Unfortunately, as I move from topic to topic, I haven’t found the time yet. So, I might as well share this analysis with you now, and I will probably revisit it a bit later.