作成日：2024/10/21　修正日：2024/10/22

注意 (2024/10/22追記)

本記事で扱っている LilyGo T-Halowの日本での運用パラメータに関しては、現在[2024/10/22]、LilyGo社、販売代理店でもほとんど明確にされていない状況です。
ボードに組込まれている、ESP32-S3, 802.11ahモジュールが技適を取っているという前提で実験を進めていますが、仕様を詳細に調べていくと、少なくとも(1)送信出力、(2)動作帯域幅、(3)Duty、に関して、不安要素の存在がわかってきました。
試用される場合は、上記3項目を含めた他の項目に対しても、ご自身で再三のご確認をされた上での運用をお願いします。
メーカーから推奨パラメータが提示され、ご自身で仕様の確証が得られるまでは、電波暗室、シールドルーム、ダミーアンテナ等の利用で、空中線電力を放出しない手段での評価をお勧めします。
特に、802.11ahのアピールポイントとして1kmの通信距離が確保できる類の実験においては特にご注意ください。

はじめに

前回の記事で、LilyGo T-Halowボードを動かす (ATコマンド確認・通信未確認)を投稿したが、その後、「ネットワーク・ブリッジ機能」 で有線Etherを伝送することができたので、記録として残しておく。

結果的には、Githubに公開されている情報をちゃんと理解して設定すれば、だいたい上手く行くということだったので、今回の設定で気になった点を中心に説明した。

但し、チャンネルの使い方やDuty制約の設定等、この設定で日本の802.11ah制限が正しく守られているのかどうかは不明なので、Duty制約に関わる運用をする場合は注意が必要。

前回の記事では、1台のT-HalowボードのUSB-Serialを使って表示、設定を行い、MorseMicro社ベースの802.11ah機器との連携を試みたが、暗号方式の違いもあり、上手くいかなかったため、正攻法で同じメーカーのボードでの接続を行う。

準備

今回は前回と同様のセットを2種類用意した(USB-Serial接続用PC + USB-C電源 + Ether接続用PC類)。
前回のT-Halowボードと同様に、VERSION2 MODE2 の設定にするために、付属のSPI-Flash-Memoryにあらかじめ入れ替えておく。

稼動

2台のT-HalowボードのMicro-USB端子にそれぞれUSB-SerialインターフェースができるPC(Mac)を接続し、2台のT-HalowボードのUSB-C端子を電源として起動する。
それぞれのシリアルコンソールに、各T-Halowボードのログ情報が5秒程おきに表示される。

PCに関わる設定項目の概要は以下の通り。

PC(Mac)にCH340K USB-Serial Driverのインストール
PC(Mac)でUSB-SerialのTTY名の確認 (Macだと "ls /dev/tty*" で表示される)
PC(Mac)でシリアルコンソールを立ち上げる (Macだと "screen /dev/tty.wchusbserial14120 115200")
T-HalowのEther(RJ45)に接続する2台のPC(Mac)のIPアドレスは手動で適当に設定しておく(例 10.42.0.101, 10.42.0.102)

設定について

T-Halowボードをブリッジとして稼動させるためには、シリアルコンソールでのATコマンドによる設定操作が必要である。以下に設定内容をリストアップした。
Githubの説明だと日本特有の設定に関しては特に記載が無かったため、思いついた項目は日本に合わせてみた。

一方をAP、他方をSTAとする
双方のボードの設定値は同一にしておく必要がある
双方のボードでペアリングの設定・完了操作が必要

設定手順

(1) 工場出荷時設定に戻す（双方）

以前、何らかの設定が残っているかもしれないため、双方のボードの設定値をあらかじめリセットしておく。

AT+LOADDEF=1

(2) 動作帯域幅を4MHzに設定する（双方）

今のところ特に4MHzのこだわりは無いが、MorseMicroの機器で4MHzの設定をしていたので、その値を継承した。
(注：8MHzの設定は利用可能な920.5〜928.1MHzを超えてしまうのでマズイかもしれない。[2024/10/22])

AT+BSS_BW=4

(3) 1個のボードをAP(アクセス・ポイント)にする（1個のみ）

ペアリングするためには1台はAPに設定する必要があるとのこと。

AT+MODE=AP

(4) 周波数帯域の設定（双方）

設定の意味があるのか不明だが、日本の周波数帯域の設定はしてみた。

T+FREQ_RANGE=9205,9281

(5) チャンネルリストの設定（双方）

日本の周波数帯域の真ん中の周波数1個をチャンネルとして設定。

AT+CHAN_LIST=9245

(6) ペアリング開始（双方）

双方のボードに下記のコマンドを設定しペアリングを開始する。

AT+PAIR=1

ログに "wnb: pairing success!" の文字列が現れたら、ペアリングは上手くいったとのこと。

(7) ペアリング完了（双方）

ペアリングが成功したら完了させないとコネクションできないようなので、ペアリング完了コマンドを送る。

AT+PAIR=0

(8) コネクションの確認（双方）

ペアリングを完了させ、接続が完了したかを確認する。

AT+CONN_STATE

接続ができている場合は、"+CONNECTED"と表示される。

(9) 設定パラメータの表示（双方）

AT+WNBCFG

(注：上記の設定だけだと、最大送信電力とDuty制約を違反する可能性があるので注意。[2024/10/22])

ペアリングできてコネクションできた時のログの例

周期的に表示されるログ例

[276344]
LMAC STATUS:
local: XX:XX:XX:XX:XX:XX AID= 0
freq= 924.5 bw=4 chn=3 bgr=-84 iq=87:50:41:252 dc=0:0(17:-10) tx=*5 dly=73:0:98 sif:rsp=0:0(0)
chn:  924.5 
bgr:    -85 
buf: free=78 tq=0 sq=0 ac=0:0:0:0 agg=0:0:0:0 statq=0 rxq=0:0 skb=-5:0 rxb=120K
irq: ac=378 bkn=12 bo(rts:frm)=182:363:0:0:15 to(rts:frm)=0:0 rx=575
tx : cnt=1410 dly=9:17ms mcast(bw:mcs)=2:0 agg=3(5967,681:0) data=1652KB(2203kbps) dur=1058ms cca=1878 per=0% est_rate=12557kbps fail=0 drop=0
rx : cnt=577 bus=0ms cts_bm=0:0 pks=17 data=1KB(1kbps) dur= 10ms err(phy:fcs)=0:0 ecode=0x0 rssie= 0:0 cache_rxq= 0:0
dbg: dtmd=0:0:0 stamap=0x2 sleepmap=0x0 flag=0x0 rxdp=0 kerr=0 mic=0 lerr=0 kick=0 csc=0 rst=0 ovf=0 nob=0 tsnr=52 rssi=-31 rxdut=1% txp=5 rxg=5    
cca: 4s st12= 0:0 mid1224= 0:0:0:0 ed1224= 0:0:0:0 ch_bz= 45
chip-temperature:50, vcc:3.30, vdd13b:1.32, vdd13c:1.31

STA1: XX:XX:XX:XX:XX:XX
tx1: mcs=*7 bw=4MHz snr=52 cnt=379 agg=3 data=1670KB(2200kbps) dur=1029ms dut=98% txq=0 cca=1883 ack=1670KB(1422) drop=0KB(0) per= 0%
rx1: mcs=4 bw=4MHz evm(avg:std)=-28:0 rssi=-26 agc=7731 cnt=17 agg=1 data=1KB(1kbps) dur=10ms dut=1% fcsErr=0, freqDev=848Hz adv_bw=0:0:0:0

"AT+WNBCFG"で表示される内容例

+WNBCFG (6) OPEN
    role:ap, bss_bw:4, encrypt:1, forward:1, key_set:0, mkey_set:0, join_group:0, bssid_set:0
    freq_range:9205~9281
    chan_list: 9245,
    ssid:, r_ssid:, addr:XX:XX:XX:XX:XX:XX
    max_sta:8, tx_mcs:255, acs_enable:1, acs_tmo:0, tx_bw:8
    country_region:, tx_power:20, pri_chan:3
    psconnect_period:60, psconnect_roundup:4
    wkio_mode:0, psmode:0, wait_psmode:0, auto_chsw:0, acktmo:0
    bss_max_idle:300, beacon_int:500, dtim_period:2
    group_aid:0, agg_cnt:0, aplost_time:10, roam_rssi_th:-60, roam_int:5, roam_rssidiff:12
    dhcpc_en:0, dhcp_host:, ack_tmo:0, reassoc_wkhost:0, mcast_filter:0
    STA0:[4a:06:59:81:a0:98, pair:1, encrypt:1, connect:1]
    auto_role:0, roaming:0, dupfilter:1, pa_pwrctrl_dis:0, pair_autostop:0, supper_pwr:1, mac_set:0
    not_auto_save:0, dcdc13:0, auto_pair:0, heartbeat_int:500, auto_sleep_time:0, wkup_io:0, wkio_edge:0
    ap_psmode:0, dis_1v1_m2u:0, psconnect_dis:0, ap_hide:0, roaming_samefreq:0, max_txcnt:7, repeater_level:1
    mcast_txmcs:0, mcast_txbw:0, mcast_clearch:0, mcast_dupcnt:0
    wkup_host_reason:2,3,4,9,11,8,7,12,14,

ネットワークの確認方法

ネットワークが通じているかを確認する方法はいくらかあるが、オーソドックスな方法を挙げてみる。

ping

ping ＜他方のPCのIPアドレス＞

iperf3

A: iperf3 -s
B: iperf3 -c ＜AのIPアドレス＞

GStreamer

テストパターンのランダムデータが常時画像を送っていることをあらわす。

送信側：

gst-launch-1.0 -e \
  videotestsrc is-live=true ! video/x-raw,width=640,height=480,framerate=30/1 \
! x264enc ! video/x-h264, profile=baseline \
! rtph264pay pt=96 \
! udpsink host=＜受信側のIPアドレス＞ port=5001 sync=false

受信側：

gst-launch-1.0 -e \
  udpsrc port=5001 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264" \
! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink

ここまでの結果

とりあえず普通にデータが伝送されていることがわかった。
また、ペアリングも含めて、再電源投入で、USB-Serialの表示、設定なしでも普通につながるため、ATコマンドでT-Halowに設定した設定値は、Flashメモリ領域に格納されている様だ。

詳細な仕様に関しては、LilyGo T-Halowのペアリング機能が、802.11ah(Wi-Fi HaLow™)の標準的な機能なのか、ATコマンドでの設定値が、日本制約に合致するのか、Duty制限・設定があるのか、暗号方式を含めて他社モジュールとの互換性、等、不明点がまだまだある。今後も調査予定。
(注：T-Halowのデフォルト設定は日本制約に合致しない可能性が高い。[2024/10/22])

今後の予定

現状のボードは、ほぼバラックで、特にアンテナの安定性とか悪いため、何らかのケースに入れ、アンテナもちゃんと自立するようにした状態で、遠距離確認を行うつもりだ。

参考

(1) Mode2: TX-AH network bridge https://github.com/Xinyuan-LilyGO/T-Halow/blob/master/docs/mode2_test.md