2021年2月21日日曜日

FT8 Digital mode の投稿から ”Oliviaのスプラッターが出ていたと。。。”

FT8 Digital mode の投稿から ”Oliviaのスプラッターが出ていたと。。。”

Why, oh why Olivia??? In the middle of FT8 band with splatters all around!


しかしFT8が出てきたときPSK,Olivia,MFSK16,,,Hellなどの周波数と衝突してしまった。

14MhzはではOlivia等の使用エリア、18MhzはPSKと他のモード衝突。。

21MhzはOlivia,Contsai,Hellとか。。。

Oliviaのスプラッターはブチ切れたのかと思います。

元々は以下のコメントが正しい。

Traditionally, PSK31 has been from .070 to .073 -- Olivia, Contestia, and FeldHell operated from .073 to .076. (15, 20, and 40). Right now, Olivia and Contestia are still scrabbling to establish new calling frequencies and watering holes after FT8 came along. That's why I'm amused when FT8 users complain about Olivia stepping on them. In reality, it's really the other way around.


以前はPSKQSO中にOliviaにモード変更要求あり1KupとかでQSOしていました。

共存していたのです。コンデションが上がればチャットモードが多くなると思います。

2021年2月12日金曜日

WSJTX 2.3.0 & WSJTX2.4.0rc1 64bit/32bit JTDX2.2.0-rc155 32bit をRaspberry pi4 B で試す。

 

64bit WSJTX2.4.0rc1とFlrig,CQRlogの組み合わせで問題なく動く。



左は32bitで動かす、Grigtracker,CQRlog ,Flrigの組み合わせ。

 32bit WSJTX2.3.0とJTDX2.2.0rc155 Pi4用を同時に動かす。デコード数が少なければ問題ない。

多くなるとJTDXのデコード完了時間が長くなり次のサイクへ。。。

JTDXのRaspberry Pi4用及びArm版はCPU使用率が平均で70%~100%になります この状態になると極端にデコード完了時間がかかり次のデーコード間に合わないか??

WSJTXとJTDXの作りに違い:
FT8でwsjtxはデコードにかかる時間を長くしない、JTDXはCPUパワーを使いデコード解析に時間を使うのでデコード率はいい。。。
JTDXはバンドが混雑してQRMになるとデコード落とす傾向にある、WSJTXはQRMに強い。。
WSJTXはできるだけCPUパワーに依存しないようにし コストがかからないようにしてある。
それでRaspberry pi4の64bit, 32bitの両方を同時リリースしているようです。64bitはそれなりに早くCQRlog、Flrigと連携もいい。