Redpineプロトコルについて

どうもです。

最近はFPVの腕を磨くために毎日ドローンしてるshyachiです。

1カ月くらい前から

ドローンの腕めっちゃ落ちてるやんけ!

ってなりまして、改めてより高みを目指す所存でございます。

まあ、さぼってただけですけど(爆

さて、本題。

Redpineプロトコルについてお話ししたいと思います。

Redpineプロトコルとは?

すでに052.jpさんがばっちり基本情報をまとめていらっしゃいます。

【図解で簡単】超高速RCプロトコル Redpine 導入ガイド【Tinyレーサー必見】

https://052.jp/howto-redpine-protocol/

この後の考察を読む前にぜひ読んでいただきたいです。

非常にわかりやすくまとまっています。

ここから先は、私なりの考察とテスト結果を書きたいと思います。

テスト機材

プロポ:Jumper T12 Pro

Jumper T12 Pro

OpenTXバージョン : 2.3.11 (2021-01-08)

内蔵マルチモジュール : multi-stm-serial-aetr-v1.3.1.92.bin

※蛇足ですが、最初マルチモジュールがアップデートできず四苦八苦していたんです。そしたらファイル名が32文字以上は表示されない仕様らしく(!?)、ファイル名適当に短くしたらいけました。マニュアルはちゃんと読んだほうがよいですね。→ https://www.multi-module.org/using-the-module/firmware-updates

次に機体。

オリジナル65機体

オリジナル65mm Tinywhoop
オリジナルの65mm機体

機体構成は

フレームは絶賛発売中です。どうぞ良しなに…

ファームウェアは、

  • Betaflight 4.2.5
  • JESC 2.3 48kHz (RPMFilterあり)

です。

あとはサブでBetafpv Meteor75 (初期型ストック構成・Betaflight 4.2.5とJESC更新済み)も試しましたがほぼ同じ印象でした。

他のプロトコルとの比較

普段使ってるのはS-FHSSです。しかもプロポはFutaba T18SZでだいぶ構成が違います。

実はS-FHSS + T18SZとRedpine + T12 Proはほとんど違いが判りませんでした。

速くなってるのは感じるのですが、はっきりとは感じ取れません。

個人的な感覚だと次のような関係になってます。

個人的レスポンスの良さ

Frsky D16 < Frsky D8 = Futaba S-FHSS <= Redpine

右に行くほどレスポンスいい印象です。

D16に関しては明らかにレスポンス落ちます。

プロポにもよると思いますが、レスポンス向上のために普段はD16の代わりにD8を使ってます。

FutabaのS-FHSSは恐らく純正プロポである影響も大きいです。同じS-FHSSでもJumper T12よりFutaba T18SZのほうがレスポンスがよくなります。噂レベルですが32MZはさらに良いとか。

逆に言うと、今まで最高だった双葉純正プロポでS-FHSSと同等か、それ以上にRedpineは良いです。なので、現状OPENTXプロポでマルチモジュール使ってる人なら間違いなくお勧めです。

Jitterの話

先ほどまで「レスポンス」という言葉を使っていますが、実は2種類の意味の総合的な効果を体感で表したものです。

それがLatency(遅延時間)とJitter(Latencyの揺らぎ)です。

遅延時間は

プロポから送信されたデータがどれくらいの時間でモーターに出力されるか?

です。単位はミリ秒(msec)

ちなみにS-FHSSは13msec前後(らしい)で、FrskyはD16で18-37ms、Redpineは理想的には1-5msecで動きます。

FPSに直すと、13msecは75fps、1.5msecは666fps(!?)です。

そう、Redpineは圧倒的に速いのですが、ゲームで言う1フレームが16.6msecなので、そもそもS-FHSSでも超早いのです。FrskyのD16は2フレーム近くあるので、体感で分かる人いるかもしれません。

ではなにがレスポンスにより強く影響するかというと、Jitter(ジッター)、つまり遅延時間の揺らぎとかばらつきです。

これも噂レベルで申し訳ないのですが、Futabaはジッター管理が厳しく、Frskyよりはるかにばらつきが少ない信号を送るそうです。つまりドローン側からは常に一定の間隔で信号が送られてきてる状態。

一方、Redpineもプロトコルの規格上、高速でばらつきが少ないはずですが、いかんせんマルチモジュールのハードウェア的な使用に左右されるので、使うプロポやマルチモジュールによってかなり変わると予想されます。

つまり

T12 Proは Redpineで 3msec ± なんちゃらmsec

双葉プロポは S-FHSSで 13msec ± なんちゃらmsec

という表記が正しいと思います。

双葉プロポはこのあたり公開してないので憶測になっちゃいますね。

そもそも、ジッターがあるとどんな影響があるかというと、BetaflightでのRCスムージング処理に影響してきます。

RCスムージングとは:https://github.com/betaflight/betaflight/wiki/SBus-FPort-and-RC-Smoothing-when-using-OpenTX

つまるところ、

  • Betaflightにプロポからの信号が入ったとき、
  • そのままでは使わず、滑らかにする処理(RCスムージング処理)を行う
  • Betaflightは通常4000Hzか8000Hzで回ってるので、666Hzでもかなり遅い
  • なので滑らかにつなぐ処理が重要
  • この時重要なのが、どれだけばらついているか?
  • ばらつきが大きいとより滑らかにしなくてはいけないので遅延が大きくなる
  • なのでばらつきが少ないほうがレスポンスが良くなる

という認識だと思います。

実際の操作はせいぜい1-30Hzの範囲で行われますが、RCスムージング処理によりこの範囲ですら影響するほど遅延が付加されます。

しかも、最近のBetaflightはこのばらつきを自動で測定→RCスムージング処理のパラメーターを最適化するらしいです。

まとめましょう

Redpineは確かに速いが、プロポとマルチモジュールに依存する(はず)

上記までの話で、ジッターがRCスムージング処理のパラメーター決定にかかわってるとお伝えしました。

そして、RCスムージング処理は素のジッターやレイテンシーより大きな遅延を生み出します。ただしここで発生する遅延は、その構成において最適なはずなので、悪いものではないです。

そして、レイテンシー自体は大幅に劣るFutaba S-FHSSはジッターが少ない(はず)なので、このフィルター処理による遅延が最低限で済む。

Redpineはジッター的にはFutaba S-FHSSと同等か、ほとんど変わらないくらいの可能性が高い。

この辺、うまく数値化して調査できるとよいのですがBlackboxとSPIレシーバーがセットになってるFCがないです。。。誰か教えて。。。

ということでRedpineの個人的な見解を書いてみました。

まあ、いろいろ書きましたが、

OPENTXでマルチモジュールを使ってる人にとってはRedpineは最速です!

ただし双葉純正プロポでS-FHSSを使ってる人にとっては大きな差にならないかも?

これは間違いないと思います。フィーリングも良好だしね。

強いて言えば、3POSスイッチが2POSしか使えないのが若干不便かな。

引き続き調査しますし、「これは違うのでは?」「こっちのほうが正確な情報では?」といったご意見大募集します。

みんなで正確かつ良質な情報にしていきたいです。

ではまた。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です