Question on supported no-infrastructure transport options for MM8108-EKH05 in MM IoT SDK

Software
1

Hi,

I am working with MM8108-EKH05 on MM IoT SDK 2.10.4 and building a custom application that needs periodic exchange of small application-defined synchronization/control payloads between nodes.

Current setup

  • Board: MM8108-EKH05
  • Host interface: SPI
  • SDK: MM IoT SDK 2.10.4
  • Target platform: mm-mm8108-ekh05
  • 2 boards currently available for development

Current status
Basic bring-up is complete:

  • build / flash / serial working
  • config store programming working
  • custom template-based app running on both boards

In the public SDK/source tree I found:

  • AP-backed examples such as:
    • examples/udp_broadcast/src/udp_broadcast.c
  • beacon/vendor-IE related example:
    • examples/beacon_stuffing/src/beacon_stuffing.c
  • beacon monitor related APIs such as:
    • mmwlan_update_beacon_vendor_ie_filter(...)
    • mmagic_controller_wlan_beacon_monitor_enable(...)
    • mmagic_controller_register_wlan_beacon_rx_handler(...)

I also noticed configuration references for S1G non-AP station type in example config files:

  • wlan.station_type = sensor / non_sensor

What I am trying to determine
I am trying to understand the intended supported public SDK path for exchanging small custom application payloads between two MM8108 nodes when not relying on a normal infrastructure AP data path.

  1. In the public MM IoT SDK, what is the recommended/supported way to exchange small custom application-defined payloads between two MM8108 nodes without using the normal AP-backed IP transport path?
  2. Is there a supported public API for raw/custom frame TX/RX, or another lower-level application transport primitive for this?
  3. Is the beacon/vendor-IE path intended only for AP beacon stuffing and monitoring, or can it also be used in a supported way for node-to-node application signaling?
  4. Is wlan.station_type = sensor/non_sensor relevant to enabling this kind of transport, or is it unrelated to application-defined payload exchange?
  5. If the needed transport path is not part of the public SDK, is there another package / portal document / support guidance that describes the recommended integration approach?

The main goal here is to understand the correct supported transport primitive before we lock in the application-side integration.

Thanks.

2

Hi @user44

If my understanding of your question is correct, then you can configure one of the EKH05’s to be an AP, and connect them together. This way you can have them communicate directly with each other rather than relying on “normal infrastructure AP data path”.

3

Hi @cmistry,

Thanks, that helps. Just to confirm, for a two-EKH05 no-external-AP setup, is the recommended/supported public SDK path therefore:

  • configure one EKH05 as AP
  • configure the other EKH05 as STA
  • exchange the application synchronization/control payloads over the resulting IP link, for example UDP

And does that mean the public SDK does not currently expose a supported raw/custom 802.11 frame TX/RX API for application payloads?

I also want to confirm that the beacon/vendor-IE APIs are intended for AP beacon stuffing and STA-side beacon monitoring only, rather than as a general node-to-node application signaling transport.

Thanks!

4

Hi @user44

You are correct yes.
mmwlan accepts arbitrary 802.3 frames, through mmwlan_tx, which we convert to 802.11 and transmit.
There are no requirements on the format of data above the 802.3 layer.

I hope this helps :slight_smile:

5

Hi @cmistry ,

Thanks, that clarifies the TX side. :smiley:

A few integration details to clarify:

  1. In an SDK app that already uses lwIP, mmnetif appears to register the RX packet callback. Is there a supported way for an application to receive a custom Ethertype via mmwlan while leaving lwIP active, or is the 802.3-frame path intended to be used instead of lwIP?

  2. For AP/STA direct communication, should the destination address in the 802.3 frame be the peer VIF MAC address, with RA left for mmwlan to infer, or should the application explicitly set mmwlan_tx_metadata.ra?

  3. Is there a recommended Ethertype range/value for private application frames on this platform, for example experimental Ethertypes, or any Ethertype values we should avoid because the SDK/firmware handles them specially?

  4. Are mmwlan_tx() / RX callbacks valid in both AP and STA roles for this use case, including AP-to-associated-STA and STA-to-AP traffic?

  5. Does this path expose any RX metadata or timestamp closer to the driver/radio receive point than the lwIP UDP callback path, or should we still treat timestamps as host-side callback/processing time only?

Related to that last point, we noticed an internal driver timestamp in the SDK:

  • struct mmdrv_rx_metadata.read_timestamp_ms in framework/morselib/src/internal/mmdrv.h, described as “Timestamp at which the MPDU was read from the chip”
  • It appears to be populated in the chip read paths, for example mm8108/yaps.c and mm6108/pageset.c
  • The public struct mmwlan_rx_metadata exposed through the RX callback seems to include only vif, tid, and ta

Is read_timestamp_ms intended to be usable by applications, or is it strictly internal? If we need a packet-associated RX timestamp earlier than the lwIP UDP callback, would you recommend exposing this field through mmwlan_rx_metadata, using another supported hook, or avoiding this path?

We also noticed morse_skb_rx_status.rx_timestamp_us in skb_header.h, but could not find where it is propagated. Is that field valid/supported for application RX timing, and if so, what clock domain does it use?

Thanks!