v1.5.0

ubxlib v1.5.0

In the 1.5 release of ubxlib, we introduce exciting new features⚡, such as BLE bonding, support of the latest cellular modules including the R10 series , support of STM32U5, the latest power-saving microcontroller from ST, log export for uCenter and many others. Also we would like to inform you of the removal of two platforms and we also made a number of improvements; see below.

Support of new Cellular Modules 📶

In this release support of the LTE Cat-1 bis LEXI-R10 series as well as support of the LEXI-R422, LEXI-R520, SARA-R520 LTE-M/NB-IoT modules was added.

BLE bonding support ⛓️‍💥

Bonding and pairing support for BLE-capable short-range modules was added in the GAP layer of the BLE API

STM32U5 microcontroller support

Next to the STM32F4, support for the STM32U5 MCU was added for the Zephyr platform and the stm32cube platform for FreeRTOS support. Read more about the differences in support of STM32F4 and STM32U5 here

Adding Non-Nordic Zephyr Platforms

Zephyr platforms other than Nordic nRF52/nRF53 were added to the ubxlib test farm:

• STM32U5, Nucleo-U575ZI board
• STM32F7, Nucleo-F767ZI board

Chunked HTTP Client API

The HTTP Client API has been extended to permit the MCU to receive an HTTP file in chunks rather than all at once.

GNSS 🛰️

• added .ubx format log file export and live log reporting through a virtual com port into u-Center for debugging.
• added support for configuration item "CFG-SIGNAL-BDS_B1C_ENA" (BeiDou B1C signal).

Removal Of Arduino (non-PlatformIO Version) And nRF5SDK Platforms

The following platforms were removed from this repo in release 1.5:

• port/platform/arduino, i.e. the version of Arduino where we supply a Python script which copies the ubxlib files into a structure that Arduino understands,

• port/platform/nrf5sdk, i.e. the previous generation of Nordic SDK, which Nordic have put into maintenance mode.

We continue to support Arduino through port/platform/platformio; if you wish to continue to use ubxlib with Arduino, please move to the PlatformIO IDE.

We continue to support nRF52/nRF53 through what is now the Nordic standard nRF Connect SDK (i.e. Zephyr 3). If you use ubxlib with nRF52/nRF53 please move to nRF Connect.

Other

• GPIO interrupt support in uPort layer allowing interrupt callback to be configured.

• Added function to check number of cipher suites for TLS uCellSecTlsCipherSuiteMoreThanOne() to the Cell API.

• Many fixes for LENA-R8 module.

• Added ODIN-W2 module to test farm.

• PPP support for Linux platform.

• New set of cellular APIs are introduced to enable async connection mode for cellular modules: uCellNetConnectStart, uCellNetConnectStop

v1.4.0

ubxlib v1.4.0

In the 1.4 release of ubxlib, we introduce three highlights ⚡: Geofencing, LENA-R8 and NORA-W3 Support. Also we would like to inform you of the deprecation of two platforms and we also made a number of improvements; see below.

Geofencing Support

A common uGeofence API is added to the set of common APIs, enabling the creation of multiple geofences in circular or polygon shape. Geofence violation can be tested using uCellGeofence, uGnssGeofence or uWiFiGeofence, which were added to the respective GNSS, cell and WiFi APIs.

Add support for LENA-R8 LTE Cat 1bis modules

LENA-R8 is now supported. A few things to note:

• LENA-R8001M10 does not support access to the internal GNSS chip via CMUX; the older AT+UGUBX message interface must be used and hence streamed position cannot be supported. If you require streamed position, please access the internal GNSS chip over the USB interface instead (i.e. call uCellCfgSetGnssProfile() with the bit U_CELL_CFG_GNSS_PROFILE_USB_AUX_UART set, connect your MCU also to the USB interface of LENA-R8 and open the ubxlib GNSS device, separately, on that USB port).

• LENA-R8 does not support HTTP properly, hence HTTP support is disabled for LENA-R8.

• LENA-R8 does not support security on an MQTTSN connection.

• LENA-R8 does not support reading any of the LTE-related RF parameters (RSRP, RSRQ, EARFCN or physical cell ID), just the 2G-related RF parameters (RSSI, CSQ and logical cell ID, though not ARFCN).

• LENA-R8 does not support reading the DNS address set by the network or the APN currently in use.

GNSS 🛰️

Added auto baudrate support for GNSS.

Zephyr DTS fix for GNSS: correct default I2C address (thanks to djfurie for spotting this).

Fix for uGnssPosGetStreamedStart: return zero on success (thanks to Alon Bar-Lev).

Device change for GNSS only: remove device from global list when no power-off (b3aa942) (thanks to Alon Bar-Lev).

WiFi 🌐 & BLE

Add support for the latest u-connectXpress for NORA-W3 product (95f8347, updated in 7261fd7).

Fix for WiFi when the SSID is set to NULL.

Cellular 📶

Cellular API addition: support for multiple parameters with AT+UDCONF.

Fix to cellular MQTT client: capture truncated messages correctly (928ee28).

HTTP fixes for cellular: timeout cannot be zero (0bf07df) (thanks to jamal-mouline for highlighting this).

Cellular network API addition: read EMM reject cause (thanks to eeFLis for suggesting this).

Cellular API addition: SIM FPLMN list delete (thanks to eeFLis for suggesting this).

Port API addition and cellular feature for ESP-IDF/Zephyr: PPP-level integration (f3eb8bf).

Cellular change only: add support for LARA-R6xxx-01B (ecc3f98).

Cellular helper function to set RF bands (69fe155).

Cellular feature addition: allow AT command delay to be overridden

Cellular uCPU change only: increase maximum thread stack size.

Cellular change: APN username/password fields. (362dc2f)

Cellular socket improvement (c315b4f) read/write exit on remote closure (thanks to arnoutdekimo for pointing this out).

Platforms

Auto-read out of module type through support for Module type: any

If you don’t know (or don’t want to know) which module is connected to the host MCU you can use module type "any" (U_CELL_MODULE_TYPE_ANY for cellular, U_GNSS_MODULE_TYPE_ANY for GNSS, U_SHORT_RANGE_MODULE_TYPE_ANY for WiFi and BLE) and ubxlib will take care of reading out and setting the module type.

This is especially useful for Zephyr users: if no module type is set in the device tree file (.dts/.overlay) it will default to module type "any" in ubxlib. You still have the option to specify the exact module type for faster boot times and in scenarios where the code may not recognize the device type being used.

Zephyr: allow device and network configuration from the device tree

For Zephyr users, it is now possible to specify the device and network configuration structures in your device tree, see the README.md in the Zephyr directory for how to do this.

Deprecation of Arduino (non-PlatformIO Version) and nRF5SDK Platforms

The following platforms are deprecated from release 1.4:

port/platform/arduino, i.e. the version of Arduino where we supply a Python script which copies the ubxlib files into a structure that Arduino understands,

port/platform/nrf5sdk, i.e. the previous generation of Nordic SDK, which Nordic have put into maintenance mode.

We will continue to support Arduino through port/platform/platformio; if you wish to continue to use ubxlib with Arduino, please consider moving to the PlatformIO IDE.

We will continue to support nRF52/nRF53 through what is now the Nordic standard nRF Connect SDK (i.e. Zephyr 3). If you use ubxlib with nRF52/nRF53 please consider moving to nRF Connect.

Support for Arduino (non-PlatformIO Version) and nRF5SDK will be entirely removed at release 1.5, likely before the middle of 2024.

Other

• Fix for Zephyr platform: support I2C operations with STM32 series MCUs.

• Fix for STM32F4 platform: improved IO reliability.

• Device addition: add U_DEVICE_TRANSPORT_TYPE_UART_USB.

• Improvements around zephyr headers (thanks to Stephan Linz for this).

• Expand range/handling of GPIOs, UARTs and I2C ports to support non-Nordic MCUs.

v1.3.1

ubxlib v1.3.1

Release to add ubxlib as library in PlatformIO at this tag. Besides that several improvements were added:

• new GNSS API function is introduced: uGnssGetPortNumber()
• AT client improvement: timestamps on log prints
• HTTP client reliability improvement when no RTS flow control.
• Improved Wi-Fi captive portal reliability
• MQTT disconnect when there is no transport
• Cellular: physical vs logical cell ID reporting

Full Changelog: v1.3.0...v1.3.1

v1.3.0

ubxlib v1.3.0

In the 1.3 release of ubxlib, we introduce exciting new features and a number of improvements. Highlights are the support of native Linux as host platform as well as WiFi access point and WiFi positioning support. In addition we would like to inform you of the future deprecation of two platforms. Read more below.

As always, we welcome your feedback on the road-map of features/improvements to ubxlib: simply post something in the issues list of this repo and we will respond.

WiFi 🌐

Wifi Access Point / Captive Portal

Support is provided for using Wifi as an access point during provisioning. When connected-to by, for example, a mobile phone, the access point will scan for other Wifi access points, present a HTML page that allows the correct SSID to be selected and a password entered, before switching back to Wifi station mode in order to operate normally.

As part of this implementation the uSockBind(), uSockListen() and uSockAccept() APIs are supported for short range (i.e. Wifi) modules.

An example Connect to an access point or start the captive portal can be found [here] (https://github.com/u-blox/ubxlib_examples_xplr_iot/blob/master/examples/captive_portal/src/main.c)

Wifi Positioning

Support is added for positioning using the Google Maps, Skyhook or Here cloud services, which base their position on knowledge of local Wifi access points; a subscription to one or more of these services will be required.

This feature is supported only by u-blox Wifi/BLE modules NINA-W13 and NINA-W15 (with u-connectXpress version 5.0.0 or later).

Wifi HTTP Maximum Page Size

The maximum HTTP page size that can be retrieved over Wifi HTTP is increased from 512 bytes to 2 kbytes.

Positioning 🛰️

GNSS AssistNow support added

Support is provided for AssistNow: online, offline and autonomous, enabling faster time to first fix and reducing GNSS power consumption.

Support use of UART 2 in ZED-F9P added

The second UART of the ZED-F9P GNSS device may now be used (specify U_GNSS_TRANSPORT_UART_2 instead of U_GNSS_TRANSPORT_UART).

GNSS power save modes support added

Support is added in the uGnssPwr API for all of the GNSS power saving features. Note that these features are not supported by all GNSS devices: see details in the API itself.

Cellular 📶

Cellular CloudLocate support added

Support is added for version 2 CloudLocate, using the new compact RRLP message formats available in u-blox M10 GNSS modules and later, which give a significant improvement in transmission speed/cost.

CellTime support for SARA-R5 modules added

CellTime, the feature through which accurate hardware timing may be achieved through the cellular network and/or GNSS, is now supported: see u_cell_time.h and the uCellTime API. This feature is supported on SARA-R5 cellular modules only.

Cellular Timeouts

The timeouts for certain cellular operations are increased in order to match the times recommended in the AT command manuals:

• U_CELL_NET_UPSD_CONTEXT_ACTIVATION_TIME_SECONDS (only relevant for SARA-U201) is changed from 30 to 180 seconds.

• U_CELL_NET_SCAN_TIME_SECONDS, the time to wait for uCellNetScanGetFirst() to return, is changed from 180 to 1580 seconds.

• U_CELL_SOCK_CONNECT_TIMEOUT_SECONDS, the timeout when making a sockets connection over cellular, is changed from 30 to 332 seconds.

• U_CELL_SOCK_DNS_LOOKUP_TIME_SECONDS, the timeout on returning the domain name for a given IP address over cellular, is changed from 60 to 332 seconds.

• U_MQTT_CLIENT_RESPONSE_WAIT_SECONDS, the time to wait for a response from the MQTT server over cellular, is changed from 30 to 120 seconds.

Set time and read local time

It is now possible to set the time in the cellular module manually (uCellCfgSetTime()) and to read the local time and timezone (uCellInfoGetTime()).

Cellular PlatformIO ESP32 MQTT-SN Thingstream example

An example is added, showcasing how to connect a cellular module to the Thingstream MQTTSN broker with an ESP32.

Many thanks from the u-blox ubxlib team to Jan-OleGliebel for taking the time to contribute this.

SLIPPED TO ubxlib v1.4: LENA-R8 Support

Support for the LENA-R8 cellular module will now be added in release 1.4, not release 1.3.

Platforms 🖥

Native Linux support 🐧

Up to now it was only possible to run ubxlib on Linux with the Zephyr/Posix implementation. In this release we introduce native Linux as a ubxlib platform.

With this u-blox modules can be attached and be operated from a host processor running Linux. Modules can be attached via I2C, SPI or UART. GPIO is also supported. All native Linux testing has been carried out on a 64-bit Raspberry Pi 4.

ESP-IDF Version 5

Support is added for using ubxlib with ESP-IDF version 5 (5.0.1 to be exact); support for ESP-IDF version 4 will remain.

PlatformIO Registry

ubxlib is now listed in the PlatformIO registry

STM32

Support for the CMSIS v2 API is added.

Arduino (the non-PlatformIO one) and nRF5SDK Future Deprecation Notice

We would like to inform you of the future deprecation of two platforms:

• port/platform/arduino, i.e. the version of Arduino where we supply a Python script which copies the ubxlib files into a structure that Arduino understands,

• port/platform/nrf5sdk, i.e. the previous generation of Nordic SDK, which Nordic have put into maintenance mode.

We will continue to support Arduino through port/platform/platformio; if you wish to continue to use ubxlib with Arduino, please consider moving to the rather excellent PlatformIO IDE.

We will continue to support nRF52/nRF53 through what is now the Nordic standard nRF Connect SDK (i.e. Zephyr 3). If you use ubxlib with nRF52/nRF53 please consider moving to nRF Connect.

Nothing will actually happen at release 1.3: the deprecation clock will begin ticking. At release 1.4 we will formally deprecate these two platforms (i.e. they will still be supported but you may get some additional annoying prints) and, at release 1.5, support for the platforms will be removed; you likely have until the end of 2023 before support for these platforms disappears.

Test Change Only: ubxlib.redirectme.net -> ubxlib.com

The server used with the ubxlib tests and the test farm as a TCP/UDP/TLS/MQTT/MQTTSN/HTTP peer will move from ubxlib.redirectme.net to ubxlib.com.

v1.2.0

ubxlib v1.2.0

[See note for ESP32 platform users of the uHttpClient API at the bottom]

In this release we bring a number of new features and improvements. These are described below.

As always, we welcome your feedback on the roadmap of features and improvements to ubxlib: simply post something in the issues list of this repo and we will respond.

PlatformIO Integration

We added support for building ubxlib through PlatformIO. From now on ubxlib can be used as a library by PlatformIO. In this release Zephyr, ESP-IDF and Arduino[ESP-IDF only] platforms are supported. Since Zephyr provides support for a wide variety of chipsets this means that ubxlib can also be used on a wider variety of MCUs.

PlatformIO support is regression tested in the test farm on ESP-IDF and Arduino; In future releases we intend to add testing on other MCUs and will make the list of tested MCUs available at that time.

Check out how to get started with ubxlib and PlatformIO.

ubxlib will also be added to the PlatformIO registry.

HTTP Client

We added support for HTTP client operations (PUT, POST, GET, HEAD, DELETE). The ubxlib HTTP client works with WiFi and cellular modules.

Extended Bluetooth Support

In this release generic GAP/GATT support was added where it is possible to control the module to assume the Central/Client and Peripheral/Server roles. Multiple simultaneous connections are also supported. The number of connections is dependent on the module. This does not affect the current SPS (cable-replacement) feature already supported in ubxlib.

Also the NINA-B4 board (nRF52833 chipset) is now included in the test farm, instance 26.

Support of nRFConnect 2.3.0 and Zephyr 3.3

ubxlib prior to v1.2 already supported nRFConnect 2.1/Zephyr 3, as well as nRFConnect 1.6/Zephyr 2, but the .overlay and .dts files we provide were only for nRFConnect 1.6/Zephyr 2, which means that we only tested nRFConnect 1.6/Zephyr 2. From this release onwards the .overlay and .dts files are converted to nRFConnect 2.3/Zephyr 3 format and hence we test nRFConnect 2.3/Zephyr 3; support for nRFConnect 1.6/Zephyr 2 will be retained in the code but will no longer be tested.

Cellular 📶

CMUX Support

We added support for running multiple UARTs to a cellular module using the 3GPP 27.010 defined CMUX protocol. In particular, this will allow support of a UART connection to a GNSS chip that is inside (e.g. SARA-R510M8S) or connected via the cellular module, as opposed to the current AT-command based mechanism.

Improvements

• Spot dead sockets (bf09120). From now on ubxlib will flag an IO error if the AT command querying the amount of data pending on the socket fails.
• Report RAT-appropriate SNR equivalent where available (8305bbf)
• Reboot detection (c585e45)

Positioning 🛰️

GNSS Streamed Position

The current GNSS implementation is "polled", i.e. the MCU always requests position from the GNSS chip. With the addition of CMUX support, a "streamable" connection is now available to GNSS in all cases and hence we provide a location API which makes position available to the MCU at a periodicity of your choice.

Removal Of Deprecated GNSS Types

The deprecated types in uGnssTransportType_t (see u_gnss_type.h) will be removed; see that file for the replacement types, which were introduced in commit f107a, 27 August 2022.

Improvements

• set/get message rate for M8/M9 (00b3fb2).

General

Leaving Stuff Out

Previously you had to build all of cellular, short-range and GNSS, irrespective of whether you are only interested in one or two of these. From release 1.2 the UBXLIB_FEATURES switch, already defined in ubxlib.cmake and ubxlib.mk, will operate such that you may choose one or more of cell, short_range and gnss in order to leave out code from the cell, short_range, wifi, ble and gnss directories that you do not need at compile time.

Internal Change Only: Test System Re-Write

The test system that underlies ubxlib has been re-written to improve scalability; if you believe there are areas that deserve better test coverage please let us know as it may now be possible to address the gaps.

IMPORTANT NOTE for ESP32 users of the uHttpClient API

The mechanism employed for leaving out one or more of cell, GNSS or short-range [BLE and Wifi] from a build hit a bug in the Espressif linker which means that, if a file happens to contain functions which ALL have WEAK counterparts, the linker will entirely ignore the .c file and use the WEAK versions instead, resulting in some things returning "NOT SUPPORTED".

We thought we had worked around all instances of this problem but, post release, found another one in the cellular file system calls made internally by the uHttpClient API; this is now fixed: PLEASE USE AT LEAST COMMIT 80e76d4 to include the fix (irrespective of whether you're trying to leave GNSS or short-range out), otherwise you may find that your HTTP operations return U_ERROR_COMMON_NOT_SUPPORTED.

v1.1.0

ubxlib v1.1.0

In this release we add support for the M9 series of GNSS modules and the LARA-R6 LTE Cat-1 modules. In addition several features and improvements were added. Find further information below as well as in the commit log.

Positioning

u-blox M9 GNSS Module Support 🛰️

• Configuration messages VALSET/VALGET/VALDEL with NACK-awareness.

  GNSS modules from M9 onwards support a generic mechanism for setting/getting/deleting configuration values - the VALSET/VALGET/VALDEL ubx messages. This configuration mechanism is added in the uGnssCfg API. As part of this change the uGnssMsg API is now able to detect and report when a NACK is received for a ubx-format message that it has been asked to monitor: should this occur the error code U_GNSS_ERROR_NACK will be returned.

• Improved version API for GNSS

• SPARTN message utilities

  These SPARTN protocol message utilities can be used for validating SPARTN (https://www.spartnformat.org/) messages, e.g. as received from a u-blox L-band module, e.g. NEO-D9S. There is no requirement to do this, SPARTN messages can simply be forwarded to the GNSS module, where the module itself will decode them.

  Note that the body of the SPARTN message is not decrypted/authenticated or anything by this code, all of that is done inside the u-blox GNSS chip that the SPARTN message is forwarded to.

• BREAKING GNSS change to uGnssMsg API: new message parsing and ring-buffer enhancements.

  With this change parsing of messages from the GNSS device is improved, now being performed within the ring-buffer itself, losing a copy while dodging lots of mutex locks. Also, and this is the BREAKING aspect of this change, all messages are now fully FCS checked, i.e. for the UBX-format case the user no longer has to call uGnssMsgIsGood() and hence this function is removed; if you were previously using the gnss_cfgval_preview or development branches, where this function existed, you may need to remove any calls you made to it.

  Support for parsing RTCM-format messages is added to the uGnssMsg API, though note that this is not yet fully tested; tests will be along shortly.

  The uGnssMsg API also now permits return of messages it does not understand, i.e. unknown protocols, and return of any messages (all + unknown).

• GNSS-specific examples: uGnssMsg and uGnssCfgVal

  Examples are added for GNSS-specific scenarios, one for the GNSS messaging API and another for the GNSS CFGVALXXX API.

• new user message API and uGnssCfgGet/SetProtocolOut()

  A new uGnssMsg API is introduced, allowing you to send user-defined messages to and monitor responses from the GNSS chip: both blocking and multiple asynchronous receives are supported. As part of this the internals of GNSS message receive are re-written to use a ring buffer with an expanded version of the common utility ring buffer code; this has the twin advantages of allowing multiple readers of the incoming stream and allowing the application to read messages of arbitrary length, not limited by buffer sizes inside ubxlib.

• Improved version API for GNSS

Cellular 📶

• LARA-R6 Support. This module is different to the currently supported set of cellular modules since it has LTE (Cat 1) but does NOT have Cat-M1/NB1. It also supports EGPRS and UTRAN, so a tri-RAT device. Support of LARA-R6 power saving.

• SARA-R5 dual-RAT Support

• BEHAVIOUR CHANGE in cellular scan: U_CELL_NET_SCAN_TIME_SECONDS.

• User abort. A field pKeepGoingCallback is added to the network configuration for cellular, permitting the user to pass in their own keep-going callback function, therefore allowing the abortable connect and disconnect operations to be aborted directly by the user if required. If the user does NOT require this feature, nothing changes: the field in the cellular network configuration structure will be zeroed by the compiler (i.e. pKeepGoingCallback= NULL) and so is ignored, timeoutSeconds will be applied instead, as it always was.

• FOTA support

  Initial support for FOTA of cellular modules, i.e. firmware update over the air of the FW inside the cellular module. This is rudimentary support only: reading the status of the FW update process which is actually driven entirely by u-blox servers; the MCU has no control over the process whatsoever. Support is limited to the SARA-R5, LARA-R6, SARA-R422 and SARA-R41XM-02B-03 series modules.

• Fixes in the file system API. Re-entrant versions of the file list functions, uCellFileListFirst_r(), uCellFileListNext_r() and uCellFileListLast_r(), are added. These are required for the up-coming HTTP Client API.

• MNO profile database

  Some MNO profiles can cause a cellular module to behave in ways that do not currently work with ubxlib. For instance, the Verizon Wireless (VZW) profile, number 3, causes a cellular module to return a "not allowed" error to the command AT+CGDCONT.

  An "MNO profile database" is introduced in u_cell_mno_db.c/.h; we will use this to capture the specific behaviours that need special handling. The MNO profile is read when the cellular module boots, stored, and can be checked against this database later for such incompatibilities so that the ubxlib code can work with them. This is not intended to be a public API, just a way of ubxlib changing its own internal behaviour, versus MNO profile, dynamically.

• Set local port for IP sockets

  It is now possible to set the local port number that will be used when an IP socket is created. This is useful if, for instance, you need to maintain a DTLS connection across multiple IP connections; call uSockSetNextLocalPort() with the port number you wish to use before calling uSockCreate(). Once uSockCreate() has been called the local port reverts to being IP-stack-assigned once more.

WiFi 🌐

• Added WPA3 Personal configuration support for modules that support this feature.

General

• New functionality for uDevice API

  New function uDeviceGetConfig added. It can be used for convenient filling of all the uDevice settings to their defaults.

  Also added a possible injection hook to the uDevice functions

  This is declare weak by default and does nothing. Another source file, e.g. in a board specific context, can then override this and thereby get called whenever a device operation occurs.

• Improvements for using ubxlib as a Zephyr module: It is now possible to just add one include statement in the application Cmake configuration in order to get full access to Ubxlib and with suitable Kconfig settings.

• Fix for thread memory pool

• Updates for Zephyr version 3.x

• Log to RAM

  To aid debugging of detailed real-time issues a RAM logging facility is added. This is not intended for normal use, is not included in ubxlib.h, does not form a part of the normal ubxlib code, etc.; it is only used when required during development to debug those awkward, usually platform-related, real-time issues, the ones where break-pointing won't help.

• Device API, Port (I2C) API and GNSS fixes/API additions: uPortI2cAdopt() and set I2C address

  An new API is added to the I2C port layer: uPortI2cAdopt(). This does exactly the same as uPortI2cOpen() except that it does not modify any of the underlying HW when opening the I2C port. This may be used if you are already using the I2C port for other purposes (e.g. reading from a sensor) and would like ubxlib to use it as you have already configured it. Calling uPortClose() for an "adopted" I2C port will also not touch the underlying HW.

• A LARA-R6 module, along with another M9 module directly connected to a NINA-W1/ESP32 MCU via I2C, is now being tested on a new test instance in the test farm as instance 25: HPG Solution board.

• Various fixes and improvements

v1.0.0

ubxlib v1.0.0

🎉 Time has come. This is the first major release of ubxlib! 🎉

We made a number of changes that affect the API and its backward compatibility and we tried to squeeze these in so that we didn't have to make another major release anytime soon (we hope). We also saw a need to improve the documentation in order to get users out of the starting blocks faster. Also, some minor improvements and bugfixes were included. See below for more details.

For help with moving to this release, see How To Upgrade.

API Friendliness

Includes in headers

We changed the way we handle includes; now you can include one header instead of many and you do not have to consider the ordering of the includes as you did before.

New Device API and consequent changes to Network API

We have introduced a uDevice API which represents the physical module: cellular, GNSS or short-range (i.e. BLE and Wi-Fi) and its physical characteristics (pins, UART, etc.). You open a device and then you open a network (cellular, GNSS, BLE or Wi-Fi) on that device. This allows a single short-range device to support a BLE and a Wi-Fi network at the same time, and it allows a cellular module to support a GNSS network and a cellular network at the same time (for the case where the GNSS module is inside or attached via a cellular module).

Initialization of Wi-Fi

We moved generic init and deinit APIs to the wifi.h header file

BLE SPS

For BLE we renamed the SPS APIs from ble_data to ble_sps to better reflect what it is.

Short Range API

It is now possible to change the baudrate for short range modules.

Logging

It is now possible to enable and disable ubxlib logging at runtime.

Added MQTT-SN support for Cellular

The MQTT API is updated, in a backwards-compatible manner, to support MQTT-SN, basically introducing new publish/subscribe/unsubscribe/read APIs. Note that the only currently supported modules that include MQTT-SN are SARA-R5 and SARA-R422.

Improvements for Cellular 📶

For the cellular APIs and for the GNSS-via-cellular several improvements were implemented. Among others the following:

• GNSS as a network on a cellular device
• re-establish profile on return to coverage
• MQTT retry on failures due to radio conditions
• retry GNSS power-on
• updated quotes-check for MQTT messages
• DTR power saving pin now in cfg structure
• Arduino platform change only: add missing u_cell_gpio.c

Improvements for GNSS 🛰️

Support of M8 series GNSS modules

Changes in the Location/GNSS API: GNSS as a network on a cellular device.

With the new device/network split it is now possible to separate the GNSS device type from the GNSS network type, which means that we can use the same GNSS network type with a cellular device; this simplifies the customer-side of the code since there is no longer any need to copy handles around, the ubxlib code knows, internally, how to bring up a GNSS network on a cellular device.

Documentation & Examples 📚

Getting started guide improvement with step-by-step instructions on how to get started with ubxlib are now included in the main README.md.

v0.10.2

ubxlib v0.10.2

In this release Linux/Posix was added as platform beneath Zephyr.

Besides that numerous fixes and improvements were implemented. Among others the following.

• Fixed EDM deadlock which was found during the networkBle test
• Cellular/GNSS: new method for indicating pin inversion
• Updates in README.md
• Implement basic exception handlers for our test runner in stm32cube

v0.10.1

ubxlib v0.10.1

In this release numerous fixes and improvements were implemented. Among others the following.

• Added connection parameters to BLE data and GATT port for Zephyr
• UART power saving for cellular modules
• Better error messages in the Arduino socket example

v0.10.0

ubxlib v0.10.0

In this release the following features were added.

• The WiFI API was added with support for WiFi sockets. This allows running WiFi sockets from a host microcontroller connected to a u-connectXpress WiFi module. Sockets can be used with TLS security for both cellular and WiFi. If both WiFi and cell is available WiFi will be favored.

• The Arduino-ESP32 platform was added (ESP32 only) with a socket example for Arduino.

• The Security API has now ability to use device certificate.

• Added experimental Visual Studio Code workspace project to build and run all tests and examples on the test farm.

• STM32CubeIDE project being replaced with Makefile.

• Fixes and improvements on cellular, among these

  • support for GPIOs,
  • added factory reset to cell / pwr API,
  • fixed RSSI value representation.

• Fixes and improvements for the Zephyr port, among these

  • OpenOCD thread awareness support,
  • Add alloc fence for trapping buffer overflow,
  • Fix stack allocation issue.