こんにちは、
私たちは、SDIO経由でSDR50で動作するu-blox M2-JODY-W377に88W9098を使用しています。githubからlf-6.18.20_2.0.0のドライバ/ファームウェアバージョンがあります。2.4GHzチャネル6のアクセスポイントとして使っています。
ed_macを有効にする(wifi_mod_para.confで「init_hostcmd_cfg=nxp/ed_mac.bin」を使ったり、mlanutlをed_mac_ctrl_V3_909x.confで使用したり)すると、社内の適用テストの安定性やレイテンシが大幅に悪化する問題に直面しています:
ここで詳しくは説明できませんが、これは複数のマシンを使い、88W9098アクセスポイントを中央に配置して、特定の社内段階をエンドツーエンドでレイテンシ測定するものです。ed_macを使うと平均200〜250ms高い曲線もありますが、全体的にカゲが強く、ランダムな「レイテンシ」が増えることもあります。
オフセット「ed_ctrl_2g.offset」を調整してみました。そして「ed_ctrl_5g.offset」をデフォルトの0x8とは異なる値に設定しましたが、試したどの値もテストには影響しませんでした。影響を与える唯一の方法は、有効化(2g/5g)を0にするか、起動時にファイルを読み込まないことです。
他に試せることはある?
詳細な説明とテストデータをありがとうございました。ed_mac（エネルギー検出MAC）機能の設計上、実際に見られる動作は想定内ですが、いくつか確認して明確にしておくべき点があります。
なぜed_mac APモードでレイテンシが高くなるのか
ed_mac機能は、EU ETSI EN 300 328適応性適合性試験のために特別に設計されています。その基本的な仕組みは、ファームウェアがチャネル上のエネルギーを閾値以上に検知した場合に、送信を能動的に抑制することです。アクセスポイントのシナリオでは、無線機が周囲エネルギーを検知するとバッファリングされたダウンリンクパケットが直接遅延し、測定しているレイテンシスパイクや「バースト」が発生します。オフセットパラメータを調整すると閾値感度(無線機のトリガーのしやすさ)は変わりますが、抑制動作自体は消えません。だからこそ、オフセット値がエンドツーエンドのレイテンシテストに測定可能な影響を与えなかったのです。
設定ファイルの不一致
あなたはed_mac_ctrl_V3_909x.confを使用しているようですね。当社のアプリケーションノートAN13756によると、88W9098の正しい設定ファイルは ed_mac_ctrl_V2_909x.conf です(デフォルトはed_ctrl_2g.offset = 0x08、ed_ctrl_5g.offset = 0x08)。V3バージョンは、ed_ctrl_txq_lockフィールドの値が異なり、このデバイスの検証済み構成ではありません。ed_mac_ctrl_V2_909x.confを使って、レイテンシの影響が改善するか試してみてください。
重要な質問：貴社の展開において、EUの適応性に関する要件を満たす必要がありますか？
ETSI EN 300 328の適応性要件は、EU/EEA市場で運用され、最大RF出力が10 dBm EIRP以上と宣言されている機器にのみ適用されます。確認いただけますか:
- この機器はEU域内で展開されており、ETSI EN 300 328認証の対象となっていますか？
- あなたのモジュール(u-blox M2-JODY-W377)の宣言されたRF出力電力はどれくらいですか?
EU準拠があなたのユースケースに必要でない場合、正しい解決策は単純 にed_mac構成をロードしない ことです。すでに確認済みでレイテンシ問題は完全に解決されます。
コンプライアンスが必要な場合は、まずed_mac_ctrl_V2_909x.confに切り替えることをおすすめします。レイテンシの問題が続く場合は、APモードの挙動を改善するための新しいファームウェアバージョンがあるかどうか検討できます。
上記の質問への回答をお知らせください。それに応じて対応させていただきます。
よろしくお願いいたします。
維東
ウェイドンさん、ありがとう。はい、製品は確実に10dBm以上のEIRPを出力しており、EN 300 328準拠が必要です。
ed_mac_ctrl_V2_909x.conf ( https://github.com/u-blox/u-blox-sho-host-based/blob/main/JODY-W3/txpower_config/ed_mac_ctrl_V2_909x... ) を試してみましたが、動作に変化はありませんでした。
私たちが理解していないのは、このモジュールをDoodleLabs(QCA988Xベース)のものと交換し、同じ環境で同じテストを行うと、EN 300 328も認証される一方で、レイテンシの問題は全くないということです。だから、なぜ88W9098のed_mac実装がこのような問題を引き起こすのに、他のチップメーカーのものは起きないのか疑問に思っています。
バージョンlf-6.18.20_2.0.0の他に、hotfix/lf-6.12.49_2.2.0_hotfixも試しましたが、問題は依然として発生しています。
さらに詳しい情報はこちら：
* JODYのアクセスポイントには2つのステーションがあります。
* テスト中にステーションとJODYの間で使用される帯域幅は非常に低い（約6KiB/s）ですが、主にSTA→AP方向の小さなパケットが多数含まれています。
お客様のご依頼内容を社内チームに報告いたしました。専門家の回答を一緒に待ちましょう。何か新しい情報が入り次第、すぐに皆さんと共有します。
よろしくお願いいたします。
維東
内部チームがこの問題を分析中です。以下の情報を教えていただけますか?社内チームから以下のフィードバックを受けました。
======================================================
- ドライバーのロードパラメータと、問題を再現するために使われた完全なドライバーのロード/アンロードコマンドシーケンス。
- ed_mac_ctrl_V2_909x.conf 設定ファイル。
- ログ さらなる調査のために、問題を再現する際に取得した画像です。
- ホストの詳細（以下を含む）：
- ホストプラットフォーム
- カーネルバージョン
- ドライバーバージョン
- 使用されているインターフェース(PCIe/SDIO)
これらの詳細は、お客様のセットアップと社内テストを関連付け、分析を迅速化するのに役立ちます。
======================================================
ありがとうございます
よろしくお願いいたします。
維東
何か進展はありましたか？
よろしくお願いします！
よろしくお願いいたします。
維東
こんにちは、ウェイドンさん。現在you-bloxで問題のトラブルシューティングを行っているので、もしNXPにエスカレーションされた場合に備えて衝突を防ぐため、今は彼らとだけ相談するつもりです。助けてくれてありがとう。
はい、わかりました。
最新情報のご提供ありがとうございます。
よろしくお願いいたします。
維東
リリースSD9098---17.92.1.p149.159-MM6X17552.p22 (FP92)を使用したQA環境で問題を検証しましたが、問題は再現しませんでした。
観察されたpingレイテンシは 約1〜2秒でした。
テスト手順：
- ビルドをロードし、リリース構成フォルダにあるデフォルトのed_mac_ctrl_V2_909x.confを使用してEDMACを有効にしました。
- CH6でAPUTを起動しました。
- 2人の元STAをつなげた。
- 旧STAからAPUTへのpingテストを実施しました。
テストされたシナリオ：
- auto_ds=1、ps_mode=1
- auto_ds=2、ps_mode=2
- HT20およびHT40で構成されたAPUT
- セキュリティモード:OPENおよびWPA3
- 旧STA省電力モード：有効と無効
顧客が観察した問題を分析し再現するために、以下の情報も提供していただけませんか:
- お客様が使用するファイル/ビルドの詳細を読み込む
- 構成とテスト環境の詳細
- 顧客のセットアップで観察されたノイズ/干渉レベル
- 顧客側からの関連ログ
この情報を得れば、より深い分析を行い、問題の再現を試みることができます。
================================================
ありがとうございます。
よろしくお願いいたします。
維東