パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Raspberry Pi 4、最近のリビジョンでUSB Type-Cの仕様違反を修正」記事へのコメント

  • 干渉するって話はどうなったんだろ
    https://gigazine.net/news/20191206-raspberry-pi-4-wifi-problem/ [gigazine.net]

    • by kei100 (5854) on 2020年02月25日 0時49分 (#3767859)

      干渉するって話はどうなったんだろ
      https://gigazine.net/news/20191206-raspberry-pi-4-wifi-problem/ [gigazine.net]

      2019年11月29日の4.19.86のアップデートで直ってます。 [github.com]

      firmware: hdmi: Use RB2 timing for 2560x1440@60 if pixel clock is 241.5 MHz

      原理的には解像度(1440/60p)由来の2415MHzのノイズ(下記詳細)なので当該解像度を避けるか、
      タイミングを変える(RB2=VESA CVTのReduced Blanking Timing Version 2の事か?)のが楽チン。

      以下技術的解説
      解像度の後にくっ付いてる数値はCVT-RB(無印)時の余分なピクセル
      (2560+160)x(1440+41)*60Hz=241,699,200(ピクセル/秒)
      0.25MHzの倍数で丸めて端数は切り捨てするので、ピクセルクロックは241.5MHz
      10倍の差異はおそらく、TMDS(10bit単位で転送)由来なので、10倍すると2415MHzのノイズになります。

      親コメント
      • by Anonymous Coward on 2020年02月25日 22時55分 (#3768416)

        その説明だと、ちょっと不正確かな。
        技術的に知りたい人はここらを見てください。
        http://www.hdmi-navi.com/tmds/ [hdmi-navi.com]
        https://www.synopsys.com/content/dam/synopsys/japan/whitepapers/hdmi_2... [synopsys.com]

        8bit RGBカラーの場合、TMDS変換前のデータで、
        (2560+160)x(1440+41)*8bit*60Hz = 1.933Gbps /ch

        DC除去のために8b10b変換するので、TMDS変換後のデータは、
        1.933Gbps *10/8 = 2.417Gbpsになる。

        TMDSではクロック周波数がデータレートの1/10なので、クロックが241.7MHz。
        データの周波数成分は最大で、2.417Gbps/2 = 1208MHzです。
        これらの高調波が、干渉してるのではないでしょうか。

        そもそもHDMIコネクタと基板の接合部をむき出しで、裸で使用することに問題がある気もする。
        接合部の不整合からの放射は完全には避けられないので。

        親コメント
        • 補足説明ありがとうございます。
          ノイズ系は不勉強なので勉強になりました。

          今回の件もですが、物理層って面倒ですね……

          親コメント
        • by Anonymous Coward

          不正確ではないだろ、bpsとHzを混ぜて書いててどちらかといえば不正確に見えるよ。
          たんに元コメは話を分かりやすく書いてるだけでしょ、あなたはどこかに書いてあったことそのまま書いてるのを正確というんだろう。

          • by Anonymous Coward

            ピクセルクロックと伝送路の周波数を混ぜてる#3767859の方が不正確に見えるけどな。

            • by Anonymous Coward

              #3767859の一番のツッコミどころは送るべきデータレートを丸めるにあたって切り上げではなく切り下げ(を含む丸め)を行っている事だと思う。
              どう送るんですかね………

              • 遅レスですが、色々端折ってたり、ノイズ系無知で不正確だったようですみません。
                気になるなら仕様 [vesa.org]を読んで下さい。
                CVT→CVT v1.2.pdfというファイル名の「VESA Coordinated Video Timings (CVT) Standard」に全て書いて有ります。

                #3767859の一番のツッコミどころは送るべきデータレートを丸めるにあたって切り上げではなく切り下げ(を含む丸め)を行っている事だと思う。

                仕様がそうなってます。

                13. Calculate Pixel Clock Frequency to nearest CLOCK_STEP MHz:
                ACT_PIXEL_FREQ = CLOCK_STEP * ROUNDDOWN((V_FIELD_RATE_RQD * TOTAL_V_LINES *
                TOTAL_PIXELS / 1000000* REFRESH_MULTIPLIER) / CLOCK_STEP,0)

                ※CLOCK_STEPはCVT-RB(無印/v1時)だと0.25MHz、v2だと0.001MHz
                V_FIELD_RATE_RQDは、今回60pなので60
                REFRESH_MULTIPLIERはv1だと1、v2時は1 or 1000/1001

                どう送るんですかね………

                当然送り切れないのでリフレッシュレートは低下します。
                その誤差が発生する事も仕様に記載されていて織り込み済みです。

                3.3.1 Determination of Vertical Refresh Rate Error
                Due to the finite clock precision detailed in Section 3.2, the vertical refresh rate will not exactly equal to the target refresh rates specified.

                親コメント

ソースを見ろ -- ある4桁UID

処理中...