アカウント名:
パスワード:
干渉するって話はどうなったんだろ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.5MHz10倍の差異はおそらく、TMDS(10bit単位で転送)由来なので、10倍すると2415MHzのノイズになります。
その説明だと、ちょっと不正確かな。技術的に知りたい人はここらを見てください。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コネクタと基板の接合部をむき出しで、裸で使用することに問題がある気もする。接合部の不整合からの放射は完全には避けられないので。
補足説明ありがとうございます。ノイズ系は不勉強なので勉強になりました。
今回の件もですが、物理層って面倒ですね……
不正確ではないだろ、bpsとHzを混ぜて書いててどちらかといえば不正確に見えるよ。たんに元コメは話を分かりやすく書いてるだけでしょ、あなたはどこかに書いてあったことそのまま書いてるのを正確というんだろう。
ピクセルクロックと伝送路の周波数を混ぜてる#3767859の方が不正確に見えるけどな。
#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.001MHzV_FIELD_RATE_RQDは、今回60pなので60REFRESH_MULTIPLIERはv1だと1、v2時は1 or 1000/1001
どう送るんですかね………
当然送り切れないのでリフレッシュレートは低下します。その誤差が発生する事も仕様に記載されていて織り込み済みです。
3.3.1 Determination of Vertical Refresh Rate ErrorDue to the finite clock precision detailed in Section 3.2, the vertical refresh rate will not exactly equal to the target refresh rates specified.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
WQHD (2560x1440) と Wi-Fi (2.4GHz) (スコア:0)
干渉するって話はどうなったんだろ
https://gigazine.net/news/20191206-raspberry-pi-4-wifi-problem/ [gigazine.net]
Re:WQHD (2560x1440) と Wi-Fi (2.4GHz) (スコア:5, 参考になる)
干渉するって話はどうなったんだろ
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のノイズになります。
Re:WQHD (2560x1440) と Wi-Fi (2.4GHz) (スコア:1)
その説明だと、ちょっと不正確かな。
技術的に知りたい人はここらを見てください。
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コネクタと基板の接合部をむき出しで、裸で使用することに問題がある気もする。
接合部の不整合からの放射は完全には避けられないので。
Re:WQHD (2560x1440) と Wi-Fi (2.4GHz) (スコア:1)
補足説明ありがとうございます。
ノイズ系は不勉強なので勉強になりました。
今回の件もですが、物理層って面倒ですね……
Re: (スコア:0)
不正確ではないだろ、bpsとHzを混ぜて書いててどちらかといえば不正確に見えるよ。
たんに元コメは話を分かりやすく書いてるだけでしょ、あなたはどこかに書いてあったことそのまま書いてるのを正確というんだろう。
Re: (スコア:0)
ピクセルクロックと伝送路の周波数を混ぜてる#3767859の方が不正確に見えるけどな。
Re: (スコア:0)
#3767859の一番のツッコミどころは送るべきデータレートを丸めるにあたって切り上げではなく切り下げ(を含む丸め)を行っている事だと思う。
どう送るんですかね………
Re:WQHD (2560x1440) と Wi-Fi (2.4GHz) (スコア:1)
遅レスですが、色々端折ってたり、ノイズ系無知で不正確だったようですみません。
気になるなら仕様 [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.