投稿

ThetisをminiPC (Beelink U59)で走らせる

イメージ
  １．はじめに SDRソフトの代表であるOpenHPSDRは多機能でそれなりのCPUパワーが必要と思い当局もi7-8700のCPUを搭載したメインのPCを３年以上使ってきた。このメインPCにはWSJT-XとかLOG4OM2とかハムの運用に必要なソフトが同時に走るため過負荷で同期が外れるのに気を使うことも多くなってきた。それに加えてブラウザー・メールの汎用ソフトも使うしソフトの開発修正等でWindowsとLinuxのDual環境となって冷蔵庫状態になってしまっている。 そろそろPCの分散を考える時に来たと感じていて、横目でRadioBerryとかHL2を見ているがこのRasberryPiではThetisに慣れてしまった自分にはどうせLinHPSDR程度ではすぐに飽いてしまうし半導体不足で基板単体で２万円台に跳ね上がった昨今ではと悩んでいると、 Amazon Japanに Beelink U59 ミニ Pc Windows 11 Pro、8GB DDR4 256GB SSD Intel 第11世代プロセッサ N5095 4C 4T Up to 2.9Ghz、2HDMI / typc 3.0 4K@60Hzつの出力ギガビットイーサネット2.4 g / 5 gのWi - Fi BT - 4.0 の謡文句で２万７千円台で売られているのを見て７５歳の誕生日のプレゼントとして６月末に入手してしまった。最悪Thetisで動かなくってもLinuxマシンとしてLinHPSDRを動かせばきれいな箱入りの完成品は基板むき出しのRPよりはましかと思って。 ２．Thetisを入れてマイク・ヘッドフォーンをつないでみると Thetisの立ち上げに２０秒かかるのはご愛嬌としてThetisの受信時のCPU利用率はDiversityを入れても35%台でメモリは２00MBである。KT USB Audioと認識されるフォーンジャックはThetisではWindows WSM-KS　Driverとして認識されてサンプル率4800bps、バッファーサイズ512Bで遅延も少なく受信できる。送信時に試しにPuresignalを試して見たがフィードバックも正常にかかるしCPU利用率も４５％ぐらいに収まってくれている。あっさりと正常動作ですぐに既存のRedPitayaを使ってオンエアー可能であった。 ３．タッチスクリ
コメントを投稿
続きを読む

JT AlertのMessaging Windowでのチャットの勧めー新しいWSJTの楽しみ方ー

イメージ
  １．はじめに この機能は数年前から提供されていて新しい話題ではないが最近はSMS風の画面で言語も日本語も含めて国際化している。 OLIVIAから非難されているように、WSJTはラバースタンプの最小限のQSOに限定しているのでラグチュー用のコミュニケーションツールとしては面白くない。そのため最近はあまりQRVしなくなったが、ハイバンドのコンデションが上昇して２４MHｚと２８ＭＨｚのDXCCが残っているので久しぶりにWSJTに参戦した。 ところがハイバンドではオープンが起きると3つ以上の大陸間で起きるので遠近入り混じって５０局以上がデコードされるのは珍しくない。そのためQRMは信じがたいほど激しくなり中心の１．５ｋHzあたりにいるDX局へのCALLはなかなか取ってくれないしDX局の信号そのものも近隣の局にマスクされてしまいQSOシーケンスはなかなか完了しない。 そのため５００Hz以下か２５００Hz以上でCALLすることにしているが、気づいてもらうためにJTALERT利用者を示す星印のついているDX局にはこの機能で自分のCallの周波数を伝達して注意を喚起してみた。添付のスクリーンコピーは昨日の28MHzのニューカントリSV9COL、A61FJ,　CT1AGSとのやり取りである。 ２．わかったこと １）スプリットで呼ぶときの周波数はなるべくQRMが少ない周波数を選ぶべきだけれども余りにも離れた周波数で呼ぶのに危険を感じるときにこの機能は有効であること。（SV9COL,　A61FJ　参照） ２)特に１．５ｋHzにいるDX局は自分の信号が激しいQRMを受けていることを案外認識していない。そのためにQRMの少ない５００Hz以下か２５００Hz以上に移ってもらうのを促すとJAからのCallが増えて感謝される。（CT1AGS　参照） 3）WSJTのラバースタンプQSOが思いもしないようなラグチュー的なQSOに変身していまう。PHONEでの第２言語でリアルタイムQSOには怖気てしまう日本人でもCWよりも敷居は低いし国際化のための訓練として役立つと思う。やり取りは第３者に覗かれていないと思うので失敗しても周りを気にしなくてすむ。（SV9COL、A61FJ、CT1AGS　参照） （２０２２年３月３１日記）
コメントを投稿
続きを読む

７０４１問題はOLIVIAの電波戦争とIARUへの対案

イメージ
提案があります。IARUへの対案を先取りして 、３．５MHｚと７ＭＨｚのＦＴ８の国内周波数での運用はやめて、３．５ＭＨｚではＦＴ４の３．５７５ＭＨｚで７ＭＨｚではＦＴ４で７．０４０ＭＨｚで運用を即開始して、（あまり言いたくはないが）世界最大のJAユーザーの意見を公平に聞かずに事を進めるＡＲＲＬとＩＡＲＵへの抗議とIARUへの対案を採用要求の２つの意思を示しませんか？ 昼は7.040MHzで夜は3.575MHzでCQを出しています。 ７．０４０MHｚは下の２００Hz以下がWSPRで上の１３００Hz以上はFT8で使っているのでTXを２００Hzから１２００HzでWSPRとFT8と共存しています。 QSOの最後のTX5に "FT4 QRG 7040"を入れてアピールしています。3.5MHzでは"QSY FT4 3575" です。 (２月１５日）） ２日ほど1,200Hz付近でCQ運用してみてQSOが３０分に一局程度に留まっているのは、大多数のFT8の局にとって200Hz付近でバンドスコープに写るのがFT4の運用であることを知らないだけであることが判った。存在を知ってCQに応答してくれればアッという間でQSO終了です。JTDXで運用しているがFT8の信号の存在でソフト上問題は起きない。FT8-＞FT4の移行も大きな混乱なく行えると確信した。 IARUへの対案とは切り離して、 wsjt-devel への３ｋHzの帯域内でFT4を近距離通信にFT8を遠距離通信に振り分ける現実的なQRM解消提案として使えるし細分化して無駄に周波数を増やす現行バンドプランを廃止する提案（MONITOR時はFT4・FT8・WSPRマルチデコード機能も良いかも）とアイデアは広がっていく。（２月１７日） 3.5MHzのFT4の運用周波数はWSJT JTDX共にRegion "ALL"  では3.575　Region "3"では3.568となっていることに気づきました。これはFT4の導入が3.575~3.580MHz開放以前の2019年夏だったためと思います。近々に3.568の削除を申し出ましょう。(2月１８日） 以下は小生のQRZ.COMのページに書いておいた提案の要約です。JA9HWDさんの粘り強いCQで今朝から7040での
コメントを投稿
続きを読む

「自己確認」制度を適用すべきとデジタル変革時代の電波政策懇談会 へ意見提出

  １．はじめに アマチュア無線においても簡易な免許手続きとして「自己確認」制度を適用すべきとの意見を７月１４日に提出した。 ２．提出意見 項目 章 第３章デジタル変革時代の電波有効利用方策 項 1. デジタル変革時代に必要とされる無線システムの導入・普及 （６）デジタル変革時代に求められるワイヤレス人材 ② アマチュア無線を活用したワイヤレス人材の育成   ご意見   原案 （イ）主な意見＜事業者等からの主な意見＞   ・技術者の人材育成や無線技術の実験・研究開発の促進を見据えた、アマチュア 無線局の制度緩和が必要。   （追加）意見：   （ウ）パブコメによるアマチュア無線家からの意見 報告書で指摘されている制度緩和に関して、現状の免許手続き制度は先進諸外国と異なり簡易な免許手続きにおいて最上位の無線技術士資格者に対しても無線設備規則への自己確認技量を一切認めず第三者の保証認定または技適証明を求めことにある。よって他の無線業務の小電力無線機器に対して制度化されている技術証明を求めない「自己確認」制度の適用を検討すべきである。（例えば送信電力５W以下の）小電力無線機器は「特別特定無線設備」とし、第３者による保証認定または技適証明を必要としないアマチュア無線の有資格の申請者自身が「自己確認」する無線局免許手続規則第十五条の五第一項第二号の規定の簡易な免許手続きを行うことができる制度の適用検討を希望する。 同時にアマチュア業務への「自己確認」制度の導入方法にあたっての適用基準は他の業務のように小電力ではなくクラスで認められた操作範囲の送信電力とし自己確認制度の適用は上級クラスに限定する実現方法も検討願いたい。理由は無線設備規則への合致の確認はデジタル技術の発展でPCによるシミュレーションによる定量的な評価は常態化し、半導体技術の進歩でデジタルフィードバックでPCのソフトウエアで帯域内漏洩電力の低減を確認しながら運用することは日常化し、以前は高性能な測定機器の価格が１万円以下で入手可能となったことであり、この合致の確認作業のための機器操作は上級クラスが要求する技術能力に一致しておりまた報告書の「ワイアレス人材および従事者制度の見直し」への期待とも一致していると考えている。なお、この提案は英国のOfcomが既に実施していると理解している。   その他留意点： 上記指摘
コメントを投稿
続きを読む

－新スプリアス規格への移行期限の延長―への意見書を提出

６月０９日付で意見募集結果が公表された。小生の意見の採番は８６番。 総務省の回答は予想通り「本件意見募集案に対する賛同意見として承ります。 なお、スプリアス規格値に対するご意見については、 今後の施策の参考とさせていただきます」と扱い評価の低い「参考」であった。 ただし普段の意見募集と異なり「意見提出を踏えた改正案の修正の有無」の欄に「有」は一件も無く「今後の施策の参考とさせていただます」は提出意見１３２件対して１２件もある異常なパブコメ結果であった。そして、JARDの期限を限定しない延長への反対意見には「今後、新型コロナウィルス感染症の収束や社会経済 状況等の回復を踏まえつつ、移行期限について総合的に検討するとともに、それまでの間については、早期に 新スプリアス規格へ移行が図られるよう各免許人の状 況に応じて対応していくこととしております」との答えである。これは「各免許人の状況に応じて対処」するのが今後の施策でありこの「状況」は参考として受け取ったご意見そのものであることがわかる。ということで今回の参考とされるご意見は普通のパブコメのような評価の低い扱いにはできないと思われる。  移行にあたっての多くの反対意見は使用期限を設けるハードランデングな電波政策である。これに対して小生の提案はよりソフトな「クリーンな新スプリアス機器への移行した免許人が最も利益を享受できる各種のインセンティブ政策」に転換である。この具体的な政策は免許手続きの簡素化を挙げた。一般社団法人日本ローバンド拡大促進協会（４１番）からは「技適機を使用する２００Wを超える局の免許手続きの簡素化」の要望が出されているがこれは小生のインセンティブ政策提案（１項）と同じである。２００Wを超える局の免許手続きの簡素化は一丁目一番地であることに疑いはない。また、小電力機器に対して規定と免許手続きの緩和を望む意見が多く出されているがこれは小生の提案の２項に相当するものである。 以上から今回アマチュア側から出された建設的な意見は今後の施策の方向性を指し示すものであり、小生の提案内容は今回の意見の方向性に合致したものと理解している。また、制定から１５年後に免許人の示唆に富んだ多くの意見を聞いて当時の制度設計がいかに空論であったかを総務省および電監審自身が確認できたことは不幸中の幸いでありパブリックコメント制度の存在意
コメントを投稿
続きを読む

Thetisを使ってみてーThetis料理手帳ー

  １．はじめに Thetisをインストールして従来のmRXPSと較べてみるとバンドスコープ画面は流れるようで帯域フィルターの切れもよく魅力的である。しかしながらやはりhoney trapはある。慎重に原因を探りながらの忍耐運用が続く。PCのCPUはIntel　i7-8700@3.2GHzでグラボなしである。 ２．送信時の音声の途切れ 送信音声に数秒ごとに途切れが発生する。途切れはMONでも確認できるしDUPで画面でも一瞬帯域が広がるのでこれを確認できる。AUDIO CODEC使用時でも発生するがＶＡＣ利用時のほうがはるかに発生頻度が高くなる。特にPURESIGNALを利用すると発生頻度が高くなる。同じ設定でmRXPSの場合は発生しないためThetis固有の問題である。 発生理由の原因はThetisはProtocol2を前提に設計しておりProtocol1を処理するためにコンバージェンスレイヤーを設けてプロトコル変換していることをPavelに教えてもらったのを思い出した。このレイヤーの実現はnetworkprotol1.cである。プログラムのソースを見るとvoid twistである。このひねりでパイプは詰まらないの？である。 当面の対策としてタスクマネージャーでThetisの優先度を高（H)にしたら発生は少なくなった。原因も対処法もだいたいわかったが、HPSDRの機能を表示のみに限定し変復調機能をPCからFPGA側に持って行ったFlexRadioのエンジニアの高笑いが聞こえるようだ。金欠のアマチュアとしてはここで踏ん張らなくてはと思うが、トホホである。 Windowsで優先度の設定は「https://itpc.blog.fc2.com/blog-entry-186.html」が役立つ。 今回は/HIGHと/ABOVEBORMALを試してみた。 任意の場所(デスクトップ等)に優先度を変更したいアプリのショートカットを作成。 作成したショートカットを右クリックしてプロパティを選択。 「リンク先」の先頭に  cmd /c start "" /BELOWNORMAL  を追加。 入力例  cmd /c start "" /BELOWNORMAL "C:\Program Files\foo\bar.exe" オプショ
コメントを投稿
続きを読む

Protocol1とProtocol2について

  １．はじめに TAPRで標準化されているHPSDRに関してのプロトコル規定に関してプロトコル１とプロトコル２がある。SDRソフトのPOWERSDRはプロトコル１を前提に開発されてきたが最近開発されて使われ始めたSDRソフトのThetisがプロトコル２を採用したために両者の違いについての理解が必要になってくるので以下に記してみた。書いているうちにああそうだったのとのことも多い。 ２．プロトコル規定からの違い ２つの規定は以下にまとめられている。 OpenHPSDR-Firmware/Protocol 1 at master · TAPR/OpenHPSDR-Firmware (github.com) OpenHPSDR-Firmware/Protocol 2 at master · TAPR/OpenHPSDR-Firmware (github.com) プロトコル２は規定が整備されていて最新はV3.8である。 OpenHPSDR-Firmware/openHPSDR Ethernet Protocol v3.8.pdf at master · TAPR/OpenHPSDR-Firmware (github.com) プロトコル１に関しては以下に規定されている。 OpenHPSDR-Firmware/Metis- How it works_V1.33.pdf at master · TAPR/OpenHPSDR-Firmware (github.com) と思いきや両者の規定にはProtocol 1とProtocol 2の用語が載っていない。どうやら２０１５年以前にVK6APHがイーサインターフェース基板である Metis に実装した機能をまとめた「MetisーHow it works」をProtocol1と呼んでいるようである。一方VK6PHが２０１５年以降に特定のハードに依存せずにプロトコル規定としてまとめたものをProtocol2と呼んでいるようである。 ３．実装ハードウエアからの違い Protocol1はUSBとEthernetの２つのメディアを利用できるがProtocol2はEthernetのみである。 Ethernetの場合プロトコルともUDPを利用するがProtocol1の場合のPORTは１０２４のみである。これはUSBとの共用を考慮したものである。
コメントを投稿
続きを読む