The Alfa Network’s AHPI7292S was claimed to be the world’s first IEEE 802.11ah sub 1 GHz WiFi Raspberry Pi HAT when it was introduced in 2021. It is based on the 1st generation Newracom NRC7292 SoC and is still readily available today from various distributors such as
The Newracom NRC7292 (and 2nd generation NRC7394) can operate in either host mode or standalone mode.
- Host Mode – Used as a slave 802.11ah WiFi radio when connected to a host such as the Raspberry Pi running Linux. Communication is via SPI.
- Standalone Mode – This mode allows the developer to run their own code on the embedded ARM Cortex-M3 – making it an ideal candidate for embedded IoT nodes.
While the NRC7394 2nd generation part has since been released, the easy availability of the AHPI7292S should make it a candidate for initial evaluation of the Newracom ecosystem – but with some caveats ahead (spoiler: lack of flash memory).
A PDF version of the AHPI7292S datasheet can be found here. The specifications indicate it supports both the 902-928 MHz and 863-870MHz bands.
During manufacture a dummy resistor is placed in R81 – R85 indicating what region the board supports. For example, the board I have (pictured below) supports the US frequency range.
Host Mode
For most people purchasing the AHPI7292S, I suspect they will use it in Host mode as a HaLow Sub GHz WiFi radio attached to a Raspberry Pi.
For details on this, check out Building an updated 802.11ah driver for the Alfa Network AHPI7292S
For those building (updating) their own Linux OS images, two challenges exist.
The first challenge is updating the kernel module source code. This requires building a kernel module (nrc.ko) targeted to the specific version of the Linux kernel you are running. The Newracom source code targets an early 5.x Linux kernel and a few changes in the API has occurred since.
The second challenge is the board data file…
Board Data Files
The board data file contains radio frequency compliance information – supported countries, supported channels, maximum transmission power etc. This information is dependent on the RF Front end. For example, the NRC7292 doesn’t have a power amplifier and ALFA has added a Qorvo RFFM6901 on the AHPI7292S. As such, the board data file is created and provided by the module manufacturer. Or in the rare case of chip on board like the AHPI7292S, the designer of the RF front end. In this case, ALFA Network is responsible for providing this.
For the AHPI7292S, there doesn’t appear to be any publicly available board data file available on their docs page.
ALFA provide an old Raspberry Pi image embedded with a 562 byte nrc7292_bd.dat file. However, when you try to load this board file, the kernel module will indicate it is not valid.
[ 231.405757] nrc80211 spi0.0: size of bd file is 562 [ 231.405790] nrc80211 spi0.0: Major 01 Minor 00 Total len 0222 Num_Data_Groups 0001 Checksum 25FE [ 231.405796] nrc80211 spi0.0: target version is matched(1 : 1) [ 231.405803] nrc80211 spi0.0: type 0001, len 021E, checksum 91EF target_ver 0001 [ 231.405808] nrc80211 spi0.0: BD file is invalid! Stop loading FW
Further debugging shows the kernel module is failing to load the supported channel list. Closer examination of the board file suggests the HW version field is missing and subsequent bytes are offset. i.e. the supported channel list for the US region is indeed present, but the kernel module is erroneously reading it as zero. I’m not sure if the file format has changed over the years, or is this an error in the board file.
The other disappointment is the smallish 562 byte file also only contains one region (data group) – the US.
I reached out to Alfa Network asking for an updated board data file, but never received a response.
The old driver on the Raspberry Pi image provided by ALFA appears to determine the board data file is missing (NULL) and continues.
Newer modules appear to be more pedantic about the board file and any errors. If it is not loaded correctly, it bombs out and the module fails to load. One option to circumvent this, is to comment out the CONFIG_SUPPORT_BD define in nrc-build-config.h, but is not really encouraged.
Eventually, I found this. In frustration, it appears Newracom has provided a board file, stressing:
The file contains 9 regions for US, JP, K1, TW, EU, CN, NZ, AU & K2.
Regulatory compliance is important. For example, in Australia the Low interference potential devices (LIPD) class licence permits operation within the 915–928 MHz band with a maximum EIRP of 30dBm (1 Watt). Optus (a mobile phone carrier) has licenses for most of the 902 to 915MHz band, so you don’t want to be configured for US, as you may be transmitting on licensed spectrum. Optus won’t be happy.
Australia
A note for Australian users: Halow Frequency channelisation has changed over the years. It would appear the SDK is using an old IEEE 802.11-2020 plan. If you are experiencing interoperability issues – i.e. can’t see the AP, you may have mismatched channel plans.
Standalone Mode
As a developer of IoT field devices, I see a lot of value in the standalone mode. This could potentially cost down the end-solution with a reduced chip count. Instead of having a separate radio module and MCU, everything is contained on the single SoC. This was where my interest lies.
The SDK is complete with PDF documentation and can be found on github at https://github.com/newracom/nrc7292_sdk (For the newer nrc7394, the link is https://github.com/newracom/nrc7394_sdk)
As all the source and libraries are contained within the SDK, getting started was a much better experience than the kernel module for a Linux host. Applications generally built successfully in the first attempt. As per the user guide, you will need to download the ARM embedded toolchain gcc-arm-none-eabi-10.3-2021.10
You will need to swap out the default board file with the one for the AHPI7292S, otherwise you are likely to get a BD file is invalid at run time. The board file lives in /package/standalone/bdf/nrc7292.
On the version of the AHPI7292S that I evaluated, there is a three way slide switch to set Standalone, Download and Host modes. As I understand it, earlier versions had a DIP switch. You can use the provided Firmware Flash Tool to download firmware over the UART (header J3) while in Download (Bootloader) Mode. Once downloaded, switch to Standalone mode to run.
There are two XIP Boot-loaders available. The normal nrc7292_boot_xip.bin will immediately boot your application, and require you to switch to bootloader mode to update the app. The nrc7292_boot_xip_5s_wait.bin will start the bootloader for 5 seconds at boot, allowing you to upload new firmware without having to switch back to bootloader mode.
The NRC7292 has an ARM Cortex-M3 for WiFi and applications with 752KB of SRAM. There is no flash on the silicon, hence the device needs an external flash. In the SDK package, there is a list of Supported Flash Memory devices for the NRC7292. From that list, the device appears to support up to 16MBytes using a Flash chip from Integrated Silicon Solutions Inc, however 2MBytes and 4MBytes is more common. Interestingly, it would look like for the NRC7394, they have standalised on 4MBytes only – or has found no need to qualify larger flash.
The Newracom Firmware Flash tool (shown below) can be used to upload the bootloader and applications.
To build an example application, use the following command where APP Name is one of the many sample applications in /package/standalone/sdk/apps
make select target=nrc7292.sdk.release APP_NAME=($APP NAME)
If you don’t specify the APP_NAME parameter, it will build a ‘test binary’ useful for performance evaluation and compatibility testing. This consists of a console/shell that allows configuring the STA, connecting to an AP and running ping or iperf.
For example, I used the following commands to connect to a Morse-Micro based Access Point
wpa set country AU wpa scan wpa scan_results wpa add_network wpa set_network 0 ssid "ekh01-7259" wpa set_network 0 key_mgmt NONE wpa enable_network 0 dhcp ifconfig ping 8.8.8.8
I tried WPA3-SAE mode as per the NRC7292 Evaluation Kit User Guide, but couldn’t get it to connect. It would return an unspecified failure (status_code 1).
WPA: CTRL-EVENT-AUTH-REJECT 9c:04:b6:46:07:b4 auth_type=3 auth_transaction=1 status_code=1
The version of the AHPI7292S board appears to be fitted with a 1MByte flash that limits the use of Standalone mode. When downloading larger application firmware, I would receive the error “XIP firmware size (x bytes) is too big. (max: 937984 bytes)
The Flash Chip is designated U5 and sits above the J3 UART header. I was unable to get the JEDEC ID, but the 80B would suggest it is in fact a 8 Mbit (1MByte) device:
I was tempted to remove the chip and replace it, however the board was on loan and not mine to modify.
In the end, I failed to get a network application such as sample_http (960,716) loaded due to size. I had a quick play with Makefiles and optimization however from the factory, the SDK was already set up with the gcc -Os optimise for size switch.
The other limitation of this board is the lack of any GPIO broken out. It would be difficult to target a sensor application with a serial bus such as I2C or SPI.
No schematics are available for the PCB, however Alfa has some technical information here to fill in the gaps.
Summary
As a Raspberry Pi based 802.11ah HaLow access point, the AHPI7292S is a little on the pricey side. While this well built board most likely represented value for money in 2022, more commercial options are available today. For a ready made device you might want to consider the HalowLink 2. If you do still want a Raspberry Pi solution, the Heltec Automation HT-HC01P or Seeed Studio wm6108 with OpenWRT might be a better choice.
Conceptually, the Newracom Standalone mode has a lot of potential for embedded sensor nodes. As for Standalone on the AHPI7292S, get your hot-air tools and a larger flash chip ready.
Be the first to comment