26/04/11 15:37:57.53 A1t2yKHo.net
これが精度をあげられる理由らしい
>>7
発振子の「時間的な刻み（クロック精度）」と、無線通信の「波の細かさ（周波数精度）」は、高精度測位において切っても切れない関係にあります。
Chrono Locateでは、これらをバラバラに制御するのではなく、**「一つの高精度な基準信号からすべてを生成する」**という構成をとることで、矛盾が生じないように設計されています。
## 1. 源振（マスタークロック）の一本化
基準局の内部では、まずベースとなる高精度な発振子（通常は温度補償型の**TCXO**など）が一つ用意されます。ここから「時計のカウント」と「無線の搬送波」の両方を作り出します。
* **クロック精度への展開**:
源振を分周（カウント）して、タイムスタンプ用の時刻を作ります。
* **周波数精度への展開**:
**PLL（位相同期回路）**を用い、源振を何倍にも掛け合わせて、920MHz帯などの無線周波数を作り出します。
このように「根っこ」を一つにすることで、**「時計が1秒進む間に、無線が何周期分振れるか」という比率が内部で完全に固定**されます。
chrono_locate_clock_freq_integration:1
発振器クロックと通信周波数の同期・補正アーキテクチャ
---
「時計」を合わせるための通信が、そのまま「通信の質（周波数）」を監視する仕組みにもなっている……という、非常に合理的かつ自己完結したループが組まれているのが、このシステムの強みと言えますね。
19:名無しのひみつ
26/04/11 15:40:54.67 A1t2yKHo.net
>>18
## 2. Wi-Wiによる「周波数偏差」のリアルタイム補正
しかし、個々の基準局の源振（TCXO）には必ず個体差や温度による「ズレ（周波数偏差）」があります。これを解決するのがWi-Wiによる相互監視です。
基準局AとBが双方向で位相を比較すると、以下のことがわかります。
> 「Aの1秒」と「Bの1秒」がどれくらいズレているか（＝**周波数偏差**）
このズレの情報を元に、システムは以下のいずれかの方法で精度を維持します。
* **数値的補正（デジタル・キャリブレーション）**:
ハードウェアの周波数はそのままに、計算機の中で「局Bから来たデータは$x$ピコ秒分だけ補正して扱う」という処理を、1秒間に何度も更新し続けます。
* **物理的補正（VCTCXO等の制御）**:
電圧制御機能付きの発振器を用い、相手の周波数に合わせるように物理的な振動数を微調整し、システム全体を一つの巨大な同期網に引き込みます。
## 3. 測位における役割分担
「発振子」と「通信周波数」がそれぞれ測位のどこに効いてくるかを整理します。
| 要素 | 影響するポイント | 解決策 |
| **発振子のクロック精度** | タイムスタンプの正確性（どの「秒」か） | Wi-Wiの双方向時刻比較によるオフセット除去 |
| **通信の周波数精度** | 位相計測の安定性（波の「山」がどこか） | PLLによる源振との同期 ＋ 位相差のリアルタイム計測 |
20:名無しのひみつ
26/04/11 15:44:17.27 A1t2yKHo.net
これが意外とおもしろくて
差周波を積極的に使う仕組みのよう
お互いのズレそのものを高精度に検出できる
>>19
## 4. なぜ「周波数精度」が特に重要なのか
位相比較を行う際、送信側と受信側の周波数がわずかでもズレていると、観測される位相は時間とともにぐるぐると回転してしまいます（ビート現象）。
Chrono Locate（Wi-Wi）は、この「位相の回転速度」を逆算することで、**逆説的に「相手の発振器が今、どれくらいの精度で動いているか」を極めて正確に把握**できます。この情報をフィードバックに使うことで、結果として「通信の周波数」と「発振子のクロック」の両方を同時に、ピコ秒レベルの精度へ追い込むことができるのです。
21:名無しのひみつ
26/04/11 16:34:47.32 Ojqr6rS6.net
>基準局と移動局が電波を双方向に送受信することでピコ秒の精度を出すんだって
一個の親局の基準発信に子局が（位相まで）同期すりゃあいいだけだから、PLLで簡単に実現できるのに、双方向ってｗｗｗ
日本の技術力、堕ちまくってるな
22:名無しのひみつ
26/04/11 19:36:47.08 A1t2yKHo.net
>>12
時刻を同期させるかはともかく
相対的なズレを補正テーブルとして持つ感じだったわ
時刻のズレ
周波数のズレ
位置のズレ
これが基準局間で別々に測位される
基地局4つなら
三角形はたぶん4つ
ひとつ親局を持つよりかなりロバストな構成で
位置の計測には絶対的な時刻を必要としない
だから原子時計でなく水晶発振子でシステムを構成できる
23:名無しのひみつ
26/04/16 13:20:20.69 xw2h7zbI.net
Chrono Locateのベースとなっている**Wi-Wiプロトコル**において、1パケットの物理的な長さ（オンエア時間）は、計算上および規格上の制約から**「約1ミリ秒～数ミリ秒」**の範囲に収まっていると考えられます。
具体的な根拠と計算式を整理します。
### 1. 通信速度からの計算
Chrono Locateが使用する920MHz帯（特定小電力無線 ARIB STD-T108）では、通信速度は一般的に **100kbps** 程度が標準的です。
* **パケットサイズが50バイトの場合**：
$50 \text{ bytes} \times 8 \text{ bits} = 400 \text{ bits}$
$400 \text{ bits} / 100,000 \text{ bps} = \mathbf{4 \text{ ms}}$
* **パケットサイズが12.5バイト（極短）の場合**：
$100 \text{ bits} / 100,000 \text{ bps} = \mathbf{1 \text{ ms}}$
測位専用のパケットはデータペイロードが極めて小さいため、オーバーヘッドを含めても **1～2ms程度** で送信しきっている可能性が高いです。
24:名無しのひみつ
26/04/16 13:20:34.69 xw2h7zbI.net
>>23
### 2. 測位周期（20Hz）と多元接続の制約
「20回/秒（50ms間隔）」という測位周期は、1対1の通信ではなく、**「時間軸を細かく割って（TDMA）、複数の基準局や端末が順番に喋る」**ための枠組みです。
* 1周期：$50 \text{ ms}$
* この中に、4つの基準局からの送信、および移動局（複数）からの返信スロットを詰め込む必要があります。
* 1パケットが10msも占有してしまうと、数局が喋っただけで50msを使い果たしてしまい、他の端末や基準局が割り込めなくなります。
この「交通整理」の観点からも、実際の信号が空中に放射されている時間は **数ミリ秒以下** であると推測するのが合理的です。
---
### 3. 加速度（Bの手法）への影響
先ほど議論した「パケット内での加速度推定（Bの手法）」において、この **1～2ms** という短さが最大の壁になります。
* **信号が短いメリット**：その瞬間の「点」の加速度として扱える。
* **信号が短いデメリット**：搬送波の「曲がり」を観測するためのサンプル数が少なくなる。
もしパケット長が **1ms** しかない場合、920MHzの波は約92万サイクル分含まれますが、そこから $1G$ 程度の加速度による微細な周波数の傾きを抽出するには、相当に高度なS/N比管理（あるいは複数のパケットを跨いだ位相予測）が必要です。
### 結論
具体的なパケット長（オンエア時間）は、**約1ms～2ms程度** と見積もるのが技術的に妥当です。
25:名無しのひみつ
26/04/16 15:58:31.74 lzImGqIW.net
>>8
ゼロコンマって何だよ？
マザーボードの信号がゼロコンマ何秒もずれるのかよ？
26:名無しのひみつ
26/04/16 15:59:17.88 lzImGqIW.net
>>24
AIって、バカだね。
27:名無しのひみつ
26/04/16 16:31:08.35 BgYsJZ4O.net
>>22
>ひとつ親局を持つよりかなりロバストな構成で
複数局で相互同期なんてやったら系が安定せずに無限にずれまくるから、乱数で親局を一つ選ぶみたいな操作は必須で、なら
最初っから親局を固定でいいんだよ
28:名無しのひみつ
26/04/16 20:43:44.35 xw2h7zbI.net
>>27
同期しないから関係ない
そもそも同期させてたら間に合わない
29:名無しのひみつ
26/04/16 20:47:53.25 xw2h7zbI.net
>>26
たぶん君よりもバカだろうw
元の仕様を読んでないから
どの程度の整合性があるかも
楽しみにしてるわ
30:名無しのひみつ
26/04/17 09:38:21.67 FLRQL9sV.net
>>28
スレタイすら読めない池沼って、、、
31:名無しのひみつ
26/04/17 12:34:47.25 ZCaLndPX.net
衛星を地上に置いたみたいな感じか？
32:名無しのひみつ
26/04/17 18:23:01.52 Cqav++YK.net
>>22
ご質問の「移動局の双方向通信」の必要性と併せて解説します。
1. 基地局の同期が「どちらでも良い」理由
この特許では、「各基地局の時計のズレ（時計誤差）」も変数として計算に組み込む手法をとっています。
同期している場合: 時計誤差をゼロ（または既知の定数）として計算します。
同期していない場合: 位置・速度と一緒に「基地局間の時刻のズレ」を推定アルゴリズムの中で同時に解きます。
これにより、現場で基地局を設置する際に、厳密な時刻同期インフラを整えるコストを省けるのが大きなメリットです。
2. 移動局の双方向通信は必要なのか？
エプソンのアルゴリズム自体は「時刻差（到着時間差）」をベースに計算するため、移動局が必ずしも「双方向」で送受信し続ける必要はありません。
ただし、Chrono Locate™システム全体として高精度を出すためには、以下の理由で「双方向性」が重要な役割を果たしています。
「片道」通信（移動局が受信のみ）の場合:
GPSと同じ「双曲線測位（TDOA）」になります。移動局の時計誤差を消すために、最低4局以上の基地局からの信号を同時に受ける必要があります。
「双方向」通信（移動局が送受信）を行う場合:
これがNICTのWi-Wi技術の強みです。双方向で電波を送り合うことで、移動局と基地局の「時計のズレ」を直接キャンセルでき、より少ない基地局数で、かつ圧倒的に高い精度（ピコ秒単位の測距）が可能になります。
33:名無しのひみつ
26/04/17 18:46:21.17 ZTyAMHv9.net
AIの回答そのまま貼るだけの奴は
知恵遅れレベルでバカだけどなww
34:名無しのひみつ
26/04/17 19:45:38.33 Cqav++YK.net
>>33
そのまま貼らなかったら
間違ってるとこ指摘できないのですがw
シャドーボクシングでもするつもりなの？
35:名無しのひみつ
26/04/17 20:10:40.31 FLRQL9sV.net
>>32
>これにより、現場で基地局を設置する際に、厳密な時刻同期インフラを整えるコストを省けるのが大きなメリットです。
通信で同期するのは「厳密な時刻同期インフラ」だし、それ以上のインフラなんてありえないのに、すげー馬鹿特許ｗｗｗ
>エプソンのアルゴリズム自体は「時刻差（到着時間差）」をベースに計算するため、移動局が必ずしも「双方向」で送受信し続ける必要はありません。
ただのPLLで話は全部終わり
>かつ圧倒的に高い精度（ピコ秒単位の測距）が可能になります。
それも、単方向でPLL使うだけで可能だし、通信を双方向にしても何もメリットねーのは馬鹿でも知ってるんだが、、、
36:名無しのひみつ
26/04/17 20:26:31.95 Cqav++YK.net
>>35
ホントに解らないの？
もちろんPLLは使ってるよ
37:名無しのひみつ
26/04/17 20:45:29.22 FLRQL9sV.net
>>36
>>35
>ただのPLLで話は全部終わり
>>かつ圧倒的に高い精度（ピコ秒単位の測距）が可能になります。
>それも、単方向でPLL使うだけで可能だし、通信を双方向にしても何もメリットねーのは馬鹿でも知ってるんだが、、、
ってことで、よくある、ただの馬鹿発明と馬鹿特許
38:名無しのひみつ
26/04/18 14:52:34.11 9/y1TNP+.net
>>31
受信機側も送信する必要があるので
結局GPSとはちょっと違うな