HaLowLink2 compatibility with TXW8301

Hardware
1

Dear Support Team,

I recently purchased your product, and I am currently attempting to establish a connection between the Halow Link2 (AU) (configured as an Access Point) and a third-party TXW8301-based module (configured as a Station/Client). Unfortunately, I have been unsuccessful in getting the two devices to associate with each other despite multiple attempts.

I would like to ask:

  1. Are there any specific configuration steps, AT commands, or firmware settings required on the Halow Link2 (AU) to ensure compatibility with non-proprietary TXW8301 STA modules?

  2. If direct interoperability is not officially supported, could you recommend an alternative approach or a workaround to achieve a stable link between these devices?

  3. Is there any documentation, reference design, or community-tested method that you can share to facilitate this type of cross-vendor HaLow connection?

Any guidance, recommended settings, or debug steps you can provide would be greatly appreciated.

Thank you for your support.

Best regards,

802.11s support on HaLowLink hardware
2

Subject: Critical Issue: MM6108 (AP) + SAMD21 Arduino Zero TXW8301 (STA) Cross-Vendor Wi-Fi HaLow Interoperability Failure

Hello HaLow Community,

I’m facing a critical interoperability issue when trying to establish Wi-Fi HaLow communication between Morse Micro MM6108 as AP and SAMD21-based Arduino Zero Wi-Fi HaLow board (TXW8301 chipset) as STA. Despite extensive testing, these two devices from different vendors cannot connect to each other.

Test Environment

  • AP: MM6108 (AzureWave AW-HM593 module) - ESP32-S3 based, Morse Micro SDK v2.10.4
  • STA: SAMD21 Duino Zero Wi-Fi HaLow - TXW8301 chipset based

Problem Description

When I configure the MM6108 in AP mode with a specific SSID and PSK, the SAMD21-based TXW8301 STA either cannot scan the SSID or the connection attempt is rejected.

Observed Behavior:

  1. MM6108 AP:
    • Operates in standard AP mode.
    • SSID broadcasting works correctly.
    • Beacon frames are transmitted and verified.
  2. SAMD21 TXW8301 STA (Arduino Zero Wi-Fi HaLow):
    • Appears to use a proprietary “PAIR mode” for authentication.
    • SSID is not broadcasted (Hidden SSID).
    • STA must go through a registration and dynamic key exchange process with the AP before data communication is enabled.
    • Cannot be configured to use standard static PSK mode, or the capability is heavily limited.

Critical Questions

  1. Can MM6108 AP support TXW8301 STA’s PAIR mode?
    • Does Morse Micro SDK implement or support proprietary PAIR protocols?
    • If yes, what AT commands or APIs should be used?
  2. Can SAMD21-based TXW8301 STA be switched to standard mode?
    • Is it possible to modify the Arduino Zero Wi-Fi HaLow board firmware to operate in standard static PSK mode?
    • If possible, what AT command sequence should be used?
  3. Is there a standard method for cross-vendor interoperability?
    • Are there interoperability guidelines defined by the Wi-Fi HaLow Alliance or IEEE 802.11ah standard?
    • Are there any success stories of connecting chipsets from different vendors?

Test Results Summary

  • :white_check_mark: Same vendor: MM6108 ↔ MM6108 (successful), TXW8301 ↔ TXW8301 (successful)
  • :cross_mark: Cross-vendor: MM6108 (AP) + SAMD21 TXW8301 (STA) = Connection impossible

The fundamental issue appears to be protocol-level incompatibility: MM6108 uses standard AP mode with static PSK, while the SAMD21 TXW8301 (Arduino Zero Wi-Fi HaLow) uses a proprietary PAIR mode with dynamic key exchange.

I would greatly appreciate any insights, workarounds, or documentation you could share regarding this cross-vendor interoperability challenge.

Thank you!

3

I’m not the right person to talk about this, and this is not an official Morse communication, but my understanding is that no product using a Taixin chip has been WFA certified. i.e. they are not proven to implement Wi-Fi HaLow in a compatible way.

See: Product Finder | Wi-Fi Alliance

EDIT: This is not correct. As pointed out below, it looks a TXW8301 module has been certified in 1MHz and 2MHz which I missed (i.e. not 4MHz or 8MHz). My apologies!

Newracom and Morse chips are known to interoperate, though there are some caveats (search this forum for details), and notably Newracom do not support 8MHz.

In terms of pairing, Morse products support DPP/Wi-Fi EasyConnect (again the standard).

1 Like
4

Hi @yuhan,

Our MCU based AP mode implementation is not mature, particularly back in 2.10!
We have marked the AP mode feature as ALPHA to reflect this.

As such, it’s not surprising that there are interoperability issues, although it sounds like the issue is TaiXin is using proprietary protocols.

STA either cannot scan the SSID or the connection attempt is rejected

If you can capture a sniffer trace of the association attempt we can take a quick look and help point to where the issue is.

To answer some of your questions directly:

Are there interoperability guidelines defined by the Wi-Fi HaLow Alliance or IEEE 802.11ah standard?

Yes, the 802.11 spec defined the protocol which, from your description, the TXW8301 chip is not using

Are there any success stories of connecting chipsets from different vendors?

Yes, as @james.haggerty mentioned, WFA certified systems such as NRC can interop, although I will flag that we have not tested any interop with our MCU based AP implementation, just the Linux based.

Can SAMD21-based TXW8301 STA be switched to standard mode?

That’s a question for TaiXin.

Can MM6108 AP support TXW8301 STA’s PAIR mode?

  • Does Morse Micro SDK implement or support proprietary PAIR protocols?

No, we don’t support proprietary protocols in MCU AP mode.

1 Like
5

hank you very much for your previous response and the valuable information you provided.

Regarding your suggestion: “If you can capture a sniffer trace of the association attempt we can take a quick look and help point to where the issue is.” – we would greatly appreciate it if you could provide us with detailed instructions on how to capture the sniffer trace properly.

Specifically, we would like to know:

  1. Recommended hardware and software tools – Which sniffer, Wi-Fi analyzer, or spectrum analyzer do you recommend for capturing 802.11ah (HaLow) traffic? (e.g., specific Wireshark-compatible adapters, Morse Micro evaluation kits, or other dedicated sniffers)

  2. Capture configuration – What settings should we use (e.g., channel, frequency, bandwidth, filter conditions) to ensure we capture only the relevant association attempt frames?

  3. Placement and environment – Are there any specific requirements regarding the physical distance between the AP and STA, or any environmental considerations during the capture?

  4. Procedure steps – Could you outline the step-by-step procedure, from starting the capture to reproducing the issue (e.g., when to start sniffing, when to initiate the connection attempt, when to stop)?

  5. Output format – What file format do you prefer for the captured data? (e.g., pcap, pcapng, or proprietary format)

Once we have your guidance, we will proceed with the capture and send you the trace data for your analysis.

We look forward to your reply and appreciate your continued support.

6

Thank you so much for your response. I truly appreciate your help.

If I need any further assistance, I will not hesitate to reach out again.

Once again, thank you for your time and support.

7

I would like to clarify and correct a misunderstanding in one of our previous responses.

The configuration we are considering is as follows:

  • AP (Access Point) : Based on MM6108 or MM8108 chipset

  • STA (Station) : Based on TXW8301 chipset

With this in mind, I would like to revise our previous answer to Question #3:

3. Can the SAMD21-based TXW8301 STA be switched to standard mode?

→ In our intended setup, the STA is the TXW8301, and the TXW8301 supports both AP mode and STA mode. Therefore, it is possible to configure it in STA mode and proceed with testing.

However, for detailed information on whether the TXW8301 is currently operating in a proprietary mode and whether it can be switched to standard mode, we recommend that you contact TaiXin directly for an accurate answer.

4. Can the MM6108 AP support the TXW8301 STA’s PAIR mode?

→ This remains the same as our previous response. Morse Micro’s MCU-based AP implementation does not support TaiXin’s proprietary PAIR protocol.

We apologize for any confusion caused by the earlier misunderstanding.

Please feel free to reach out if you have any further questions.

Thank you.

8

You can use a HalowLink2 or one of our other linux based evaluation kit such as the EKH01

For details on how to set up a sniffer capture, see the following app note:

You’ll want to configure the sniffer to the same channel configuration as the AP. No need to apply any filters.

Generally it is recommended to place HaLow nodes a minimum distance of 2m apart to prevent issues with signal strength being too high.

Start the capture, then trigger the STA to connect. It should scan (probe request), then attempt to connect (association request). A capture of 30 sec should be more than enough

Either pcap or pcapng is fine.

2 Likes
9

Here is the analysis written in English:

Is the Statement Correct?

“Yes, the 802.11 spec defined the protocol which, from your description, the TXW8301 chip is not using”

Conclusion: This statement is not entirely accurate. According to available documentation, the TXW8301 is Wi-Fi HaLow certified and is designed to comply with the IEEE 802.11ah standard. While the claim that TaiXin may use proprietary protocols in certain situations cannot be entirely ruled out, there is no direct evidence to support the assertion that the chip does not use the standard at all.

Analysis & Supporting Evidence

1. TXW8301 Wi-Fi HaLow Certification Status

TaiXin Semiconductor’s TXW8301 chip received Wi-Fi CERTIFIED HaLow™ certification from the Wi-Fi Alliance on April 26, 2024.

Item Details
Certification ID WFA130865
Product Name “IEEE802.11ah Halow Wireless Module”
Significance Wi-Fi CERTIFIED HaLow™ certification officially proves that the product has passed the interoperability tests defined by the Wi-Fi Alliance based on the IEEE 802.11ah standard. This confirms that the TXW8301 is designed to comply with the standard and to be interoperable with other certified HaLow devices.
TaiXin’s Statement TaiXin described this certification as “国内首个Wi-Fi CERTIFIED HaLow™认证证书” (China’s first Wi-Fi CERTIFIED HaLow™ certification).

2. The IEEE 802.11ah Standard Exists

IEEE 802.11ah is the international standard that forms the foundation of Wi-Fi HaLow.

Item Details
Standard Approval Originally approved in 2017
Wi-Fi Alliance Program The Wi-Fi Alliance operates the Wi-Fi CERTIFIED HaLow™ certification program based on this standard to ensure interoperability between products from different vendors

3. Issues with the Original Statement

Issue Explanation
“TXW8301 chip is not using [the 802.11 spec]” The fact that TXW8301 has received Wi-Fi CERTIFIED HaLow™ certification strongly indicates that the chip does use the 802.11ah standard, as certification presupposes standard compliance.
“Proprietary protocols” Morse Micro’s response mentioned that TaiXin may be using “proprietary protocols.” This does not necessarily mean the chip does not use the standard at all. Rather, it suggests that TaiXin may have implemented additional proprietary protocols on top of the standard.
Possible Scenario For example, TaiXin’s proprietary PAIR mode or special features may have been implemented independently within the 802.11ah standard framework. In this case, the issue would not be that the standard itself is not being used, but rather that non-standard behavior based on the standard is causing interoperability issues with MM6108.
Lack of Evidence However, concrete evidence regarding the existence of such “proprietary protocols” and whether they are the direct cause of the interoperability issue has not been provided in the available information.

Summary

Item Summary
TXW8301 Standard Compliance Officially confirmed through Wi-Fi CERTIFIED HaLow™ certification, proving compliance with the IEEE 802.11ah standard.
Morse Micro’s Claim Suggested that TaiXin may be using proprietary protocols, but this is not equivalent to not using the standard at all.
Accuracy of the Statement The claim that TXW8301 does not use the 802.11ah standard is inaccurate, as it contradicts the certification facts. However, the interoperability issue may still stem from additional proprietary protocol implementations.

Final Verdict

Question Answer
Is the statement correct? No, it is not entirely accurate.
Does TXW8301 use the 802.11ah standard? Yes, as confirmed by its Wi-Fi CERTIFIED HaLow™ certification.
Could proprietary protocols cause issues? Possibly – TaiXin may have implemented additional proprietary features on top of the standard, which could lead to interoperability problems with MM6108. However, this remains unconfirmed without further evidence.

In conclusion, while interoperability issues between MM6108 and TXW8301 are real, it is difficult to conclude that the root cause is the TXW8301 failing to follow the standard. The certification evidence suggests otherwise, and the actual cause may lie in additional proprietary implementations or other factors.

WFA130865 (TXW8301).pdf (74.3 KB)

10

Hi @yuhan

I don’t know what you want me to do with your AI bot analysis?

But to clarify, in your original messaging you stated that the TaiXin chip was using a proprietary protocol:

Which is what I based my answer on:

As mentioned earlier in the thread, if you can share a sniffer capture of the behaviour, we can help identify if the issue is in the Morse Micro AP side, or if it is an issue with the TaiXin chip using a proprietary protocol.

Regards,
Luke

1 Like
11

Thank you for your response.

I will proceed with capturing the sniffer trace using the HaLowLink 2.

However, I would like to kindly ask for your understanding in advance, as this will be my first time performing a sniffer capture. There may be some mistakes or oversights on my part.

I will do my best to obtain and share the capture data with you as soon as possible.

If there are any specific precautions, recommended settings, or best practices I should follow during the capture process, please let me know. Your guidance would be greatly appreciated.

Thank you.

12

image
image1386×1098 144 KB

HaLowLink 2 Configuration Screen – Request for Verification

Hello Luke,

I hope this message finds you well.

I have attempted to set up the sniffer capture on my HaLowLink 2 as per your guidance. However, I have noticed that the configuration screen on my device appears to be different from what was described in the documentation you provided.

For your reference, I have attached a screenshot of my current configuration screen and have also transcribed the key settings below:

Device Configuration
Item Value
Mode Monitor
SSID (Not applicable – Monitor mode)
BSSID 50:2E:91:D2:C4:C9
Encryption - (None)
Channel 28 (916.0 MHz)
Tx-Power 30 dBm
Signal 0 dBm
Noise 0 dBm
Bitrate 0.0 Mbit/s
Country AU
Wireless network is enabled

Country Code: AU (This device is locked to this country)

Maximum transmit power: driver default (Current power: 30 dBm)

Operating Frequency Settings
Item Value
Channelization IEEE 802.11-2024
Width 1 MHz
Channel 44 (924 MHz)
Prim.Width 1 MHz
Prim.Index 0
Interface Configuration
Item Value
Mode Monitor
Network lan: 1
Observations & Questions
Channel Mismatch: I noticed that the main status shows Channel 28 (916.0 MHz), while the operating frequency section shows Channel 44 (924 MHz). Could you please clarify which channel is actually being used for sniffing?

Country Code: The device is locked to AU (Australia). Should I change this, or is it acceptable for the capture?

Monitor Mode Confirmation: The Mode is set to “Monitor,” which appears to be correct. However, I would like to confirm that no additional settings are required.

Signal/Noise Levels: Both Signal and Noise are showing as 0 dBm. Is this normal in Monitor mode, or does it indicate that the radio is not properly capturing packets?

Missing Settings: The documentation mentions some settings that do not appear on my screen (e.g., certain Advanced Settings options). Could there be a firmware version difference?

Request
Could you please review the configuration above and let me know:

If the current settings are correct for capturing the association attempt between the MM6108 AP and the TXW8301 STA.

Any adjustments I should make to ensure a successful capture.

Which channel I should be using (28 or 44) for the sniffing.

I would be happy to provide any additional information you may need.

Thank you for your support.

Best regards,