デジモードの為の手続き(2020年編)

相変わらず私のブログで1番アクセスがあるのが変更手続きのページです。しかしながら、2014〜2015年あたりに、自分がデジタルモードの運用を開始するために諸OMがまとめられていた内容を調べてまとめ、当時の事情で書いた物ですので、今年に入っての手続きの簡素化の恩恵を受けられる内容にはなっていません。

私の場合には既にデジモードの届け出等が済んでいるため、今年の簡素化の恩恵であまり新たな変更届をせずに済むようになりました。そのため、これから新たに手続きされる方向けには「こうやったら通った」という情報を、体験から書くことが出来なくなってしまいましたが、今、私が理解している範囲で「こうやれば良いはず」という内容をご参考までに記します。

もし勘違いや、これではだめで、こうしなければならなかった、と言う部分があれば修正しますのでコメント等いただければと思います。

“デジモードの為の手続き(2020年編)” の続きを読む

移動しない局、変更手続終了

10/14に出した、移動しない局のFT8(GFSK)、FT4、および、先日追加の無線機への附属装置接続の審査が終了しました。

今回は2週間だったので、先日より短かったです。

続いてですが、今度のリグはリモートアクセス用の純正ソフトがあるのですが、とりあえず宅内リモート用にリモートアクセスの届を出しておくか検討中。

総通に質問しました:JA局は8J1RL(南極)と7074 FT8で交信して良い?

先日、Twitterで雑談してたら掲題の様な話題になりました。

7メガに話を絞ると、JARLのバンドプランの配布物では7045〜7100は電話の帯域ですが「外国のアマチュア局とのデータ通信にも使用することができる」と但し書きがついています。

アマチュア無線的にはDXとなら交信してO.K.と言うことかとは思いますが、日本の免許を持つ局が、南極やら公海上から運用している場合に日本国内の局が交信して良いのか?という疑問で、そのような日本の免許を持つ局は、上記の「外国のアマチュア局」にあたるのかどうか?

“総通に質問しました:JA局は8J1RL(南極)と7074 FT8で交信して良い?” の続きを読む

QSL発行状況

2019/5/6までの交信分は、リプライ分も含め発行し、5/8にビューローに送付しました。

またLotWやeQSLも交信分は、すべてADIFファイルのアップロード済みです。

5/7以降になって、対応するeQSLをお受け取りでない場合や、LotWでcfmになっていない方は、尻切れなどで交信成立と見なさなかったケースがありますのでご確認ください。

そして1点、半分笑い話ですが…

最近はかなり早めにeQSLを送ってくださる方も少なくなく、嬉しい限りです。この発行の仕方もいくつかあると思いますが、私はログアプリ(DX keeper)から直接アップしています。もう3年以上このやり方で特に時刻ずれなどの問題もないのです。

先日、令和の初日の夕方にリジェクトのメッセージが来て相手のカードを確認しました。まず、ログによるとスタートタイムがJSTの5/1 08:59、つまり交信の当日にもらったのですが、そのログをなぜかUCTの5/1 23:59に変換してアップされたようで…

その結果、インボックスでは一致する物がないと表示されますよね。

それであちらは自信満々でリジェクトし、「日時をご確認ください」とわざわざメッセージくれました。

確認したら上記のように5/1 1800JSTころに、「5/1 2359GMT」にしたという交信のeQSLが来たわけで、未来からのeQSLが…

多分ハムログからログ作成したか、ウェブインタフェースから入れたかなのでしょうが、リジェクトする前に、まず自分のデータが間違っていないか確認して欲しかったですね…

結局こちらからあちらのカードをリジェクトしその時のメッセージに上記の日時の指摘を入れておきました。

皆様におかれましても、リジェクトされる前に、まず、自分のデータの誤り(まれに9時間のずれのものを受け取ることがあります)をチェックしてくださいね。

年末年始(中間報告)

本日は1/4ですが、今年は私は1/8から仕事始めとなりますのであと数日8エリアでのんびりしております。(もっとも今日知人からの頼まれで少し仕事しますが)

 

年末年始のこれまでの出来事他です。

トライアングルアンテナ(中波用)

40年位前、BCLブーム華やかなりし頃、ラジオの製作に高田OM(JA1AMH)が執筆された記事で、1辺1mの正三角形の枠に6ターン+真空管ラジオ用の二連バリコン並列で共振させて使う「謎のトライアングルアンテナ」という記事が載っていました。当時ラジオの製作をお読みの方はおぼえてらっしゃるかもしれません。

私個人はちょうどアマチュア無線の免許を取った頃でラジオをローカル局以外は聞かなくなっていた頃でしたので、当時製作しませんでしたが、このところBCLラジオっぽいものをいくつか購入したので、夏頃から材料だけちょっと仕込んでいました。が問題はバリコンです。

多分当時の真空管用のエアバリコンだと400pFクラスのものを2つだったのだろうと思います。ポリバリコンではQはどうかなとも思います…

が先日買ったPL365というラジオはどうやら同調していないインダクタで良い様です。必要なインダクタンスは50-400uHくらいらしいのです。上記のトライアングルアンテナは100~150uHくらいと思われますのでそのサイズのまま単線のインターホン配線用の平行電線を割いて使ってみました。

FA-VA5で測定すると1MHzで140uHほど。1.5mのミニステレオ線をカットして差し込んだら、tecsun AN200よりも、またPL365の付属の外付けバーアンテナよりも良い結果が出るようです。ただしトラッキングがうまくいかないので、受信したい辺りで一度電源をオンオフしてそこで無理矢理トラッキングさせる必要があるようです。100kHzくらい動かしたらまたそこでトラッキングです。付属のバーアンテナとくらべて信号強度/SNRで3~5dB程度は強いようです。また北海道のこの辺からだと本州向けは1方向になりますから天井から吊らせば十分。向きを変える必要もありませんでした。

[追記 2019/01/07]

巻き数をましてインダクタンスを増やしてやれば400pFクラスのバリコン一つで…とも考えて、10ターン巻いてみた物も作りました。が使ったコードガイドが1cmちょいの幅で、被覆分を込みにすると6ターンでも最後のターンが少し重なる程度の幅。そこに7ターン以上巻くと、線間の容量のためにループアンテナが自己共振し、その周波数が中波放送の帯域に落ちます。10Tで800kHzあたり、7Tで1450kHzあたりで共振し、その周波数より上では容量性になりますのでループアンテナとしてはキャパシタンスでの同調ができなくなります。PL365はどうも起動時に受信信号の最大点を探すようなキャリブレをしているようですが、それが取れなくなります。(まあたPL365は、電源を入れた時の中波周波数から大きく動かしたときは一度電源をオンオフした方が受信結果が良いようですね)

 

今回のアンテナ

今回はローバンド向けに水平部20m、全長26mほどの逆Lを展開しました。40m/80mはこれで運用していますが、80mのFT8でアメリカ西部が結構できたのでそれなりに満足です。

リグ故障

1/3にFT450Dで送信すると無信号でALCが少し振れるようになり、信号を入れるとあっという間にALCがフルスケール。ALC周りか、その検出周りで何か問題のようで、1/3より使用不可となりました(新年早々・・・)

NYPはノルマこなしたあとだったのでそれが救いでしょうか。

 

KX3でFT8運用中

ケーブルキットを年末に購入していましたので、手持ちの適当なオーディオインタフェースにphones/mic/RX IQをつないでセットアップしてみました。インタフェースがあのSoundblasterで色々と使いづらいのですがなんとか設定完了。受信音があまり大きくならないのが困りものですが・・・

KX3でいくつか嫌らしいところがありまして、起動時にシリアルをつないでネゴシエートさせないとシリアルがつながらないっぽい、とか、筐体10度くらいで送信すると出力があがらず、ファイナルが20度を超えた辺りから出力が増加する(ようは温度に関してポジティブフィードバック)という困った仕様など。

サウンドブラスターは2バスミキサーのため、I/Qでつないでいると何か送信時に回り込むかフィードバックっぽいようなことになって、I/Qはオーディオ出さないで使わざるを得ない(FT8)とか。それでもウォーターフォール面白いので192kHzサンプリングができる安いA/Dを揃えようと思っています。

FT8+、JS8callで変更手続きは必要か?

JS8callはまだ普及度が低いそうなので運用・手続きするかどうか私はまだ決めかねてます。

それはともかくとして、検討段階で、新しいFT8プロトコルをFT8+と呼んでいたそうで、そのためこれについての変更手続きが必要かどうかと言う議論があるそうです。

私はペイロードの中身にまで言及記載した諸元表を付けてないので、符号構成が変わるかどうかが必要性の判断ポイントかと思います。CRCやペイロードサイズが変わっても諸元表上は同一なので変更したとは言いがたいと思っています。

そしてJS8callというソフトですが、知人がFT8と同一として変更届を関東総通に出したところ、変更にあたるので諸元表で別の欄を追加するよう補正依頼が来たとかです。

諸元の内、異なるとすると符号構成の所くらいかと思いますが、確かにJS8callのサイトの情報では、使用できる文字セットが拡張されており、FT8の変調方式を借りて新しい文字セットに対応したエンコードをして送っているらしいと読めます。

だとすると、これは確かに符号構成の点で諸元が異なることになりますので、JS8callに関しては符号構成をJS8callに対応したものに変えて申請する必要がありそうです。

まだ電子申請での手続きから4週経っても北海道総通で受付処理中のKX3、次はデジタルモードの手続きをするつもりですが、その時にJS8callだけは上記のように手続きに含めようと考え中です。

WSJT-X 2.0RC1

つい先日WSJT-X 2.0 RC1が公開されました。

人柱情報を探すのも面倒でとりあえず自分で入れてみました。デフォルトでのデコード文字色が変わってるので少し慣れが必要かな。

TX<–>RXのオフセットの設定ボタンが文字ではなく▲▼になってるのですが直感的なのか分かりづらいのかなんとも言えません。これも慣れでしょうか。

JTlinkerは、まだ連携を試せていません(QSOがまだ出来ていない)

JTalert 2.12.5は無事に連携できているようです。キャプチャ

追記

77bitのpayloadに拡張されることになっているWSJT-X 2.0のFT8ですが、どうもすでに現状のFT8とは互換性がないメッセージが生成されることがあるようです。

CQに応答があったのですがJH8JNF/1形式のコールを使っていると拡張されたpayloadになっているのか相手にデコードしてもらえませんでした。

キャプチャ

リリースノートを読んでみたところ、<>付きの部分はハッシュコードを使っての送信となっており、その前の受信で相手がコールをコピー出来ていれば再現されるとのこと。ただしこれはWSJT-X 2.0のfeatureなので、後方互換はない内容らしいです。

・・・参ったねー、こりゃ。しばらくJTDXの方を使った方が良さそうです。

WSJT-XでのFT8 QSOで、CQに応答する方へお願い・・・

WSJT-Xとロギングソフト(ターボハムログとかDX keeperとか)を連携して、WSJT-Xの[LOG QSO]ボタンでログを取る方は少なく無いと思います。

WSJT-XでのFT8モードの運用ではauto seqを使う方がほとんどと思います。フルに定型の送受信をすると、こんな流れかと思います。

1 CQ JH8JNF QN23

2 JH8JNF JAxABC PM95

3 JAxABC JH8JNF -01

4 JH8JNF JAxABC R-15

5 JAxABC JH8JNF RRR

6 JH8JNF JAxABC 73

7 JAxABC JH8JNF 73

JTDXを使っていると5のところが RR73 になったり、あるいはグリッドを送らずにいきなりレポートを送る運用もあるようですが・・・

さて、上の例では 6 のところで、応答局がファイナルで JH8JNF JAxABC 73と送っていますが、ここで(気を利かせて)R JCC100122 73などと送ったとしましょう。

LOG QSOボタンを押すタイミングは人により多少ずれるかもしれませんが、自分の場合、5の再送が発生することがあるので、CQを出している時は7の送信中などにログボタンをクリックします。一度押してしまうと相手局のコールがクリアされてしまうので、再送が面倒になるのです。

ここで、WSJT-Xの振る舞いなのですが、6のタイミングでR JCC100122 73と送るとですね・・・この二つ目の区切りの文字列「JCC100122」が、CQ局の相手局コールに設定されてしまうのです。そのため、そこでログを取ると、ハムログにもDX keeperにも JCC100122 が相手コールとして入力されてしまいます。

ハムログならコールだけ修正で済むかもですが、DX keeperとかJTalertをclublogやらeQSLやらに連携させていて、自動アップロードさせている場合、このゴミがアップロードされてしまいます。直すの意外に面倒なんです。

ですので、お願いですから、6のタイミングでは定型の JH8JNF JAxABC 73 だけ送ってください

WSJT-X 1.9 RC3にて

今日は結構7041で国内がよく飛んでまして、JT65とFT8でQSOを楽しみました。

そうしたところ不具合が…

FT8でオートシーケンス、自分のコールはJH8JNF/1と設定、私からのCQでの交信スタート。

CQ JH8JNF/1

JH8JNF/1 JxXxxxx

JxXxxxx JH8JNF -05

JH8JNF JxXxxxx R-15

JxXxxxx JH8JNF RRR

/1 JCC1xxx TU73

R 110306 TU73

こんな流れでした。この相手からの/1で始まる行を受けた後でLog QSOをクリックしたところ、なんと相手コールがJCC1xxxになってるじゃないですか。

この/1で始まるのが僕のコール設定とマッチしたのかもしれませんが、焦りましたね。ClublogとeQSLは普段はログに入れてすぐに自動アップロードなので、クラブログをすぐに見に行ったところリジェクトされていたようで一安心。eQSLは手動で削除し、ハムログとDX keeperのログを修正し、eQSLは再アップ。一手間かかりました。1.8などでこんな目にあった事は無かったのでRC3のバグかなあと思います。

さて、それはさておき、たまに上記のように、最後の送信だけ”/1 GxxxxxA 73″の様な”/”を送信される方がいらっしゃいますね。この送信、解釈に困るのです。

まず移動してるってことだけならこちらではあまり気にしてないので、送ってもらうのは不要です。となると、こちらのログで相手コールの最後に”/x”をつけてくれってことなのかもしれませんが、正直言って「無理」です。

といいますか、相手にそこまで期待しない方が良いです。もし、なんらかの都合で”/x”をつけてeqsl/lotwにあげてほしいということなら、交信の最中に、一度でも良いので”/”付きのコールを送ってください。(私も最初の頃、交信では”/1″をつけず、eqslだけ/1つけてたのですが、交信中に使ってないと、相手には直してくれとは言い難いです。海外局に怒られたこともあります)

またはっきりとした意図が不明であるため、こちらではログは直しづらいです。

ところで最近7041でも、新規の方がずいぶん増えて凄い賑わいですね。時々道の駅?とか湖沼?とか送られてしまいますが…定着するのかなあ?

私はJCC/JCGくらいで止めておきたいと思います。

JTDX 18.1.0.7xの”/”付きコールのバグ

この週末、久しぶりにJT65/FT8を運用しました。お相手いただいた皆さん、ありがとうございました。

さて、クライアントソフトは昨年からほぼJTDXを使って来ています。JT65/9でデコード率がWSJT-Xよりも高いことが多いので、もっぱらこればかりになってしまいました。

ただし、このソフトは不安定な点が少なからずあり、使い続ける上で多少の忍耐を必要とします。昨年末から今年の頭くらいはauto seqをオフにしていても勝手に送信内容が書き換えられたり、FT8で局をピックアップするのが間に合わなかったりと、結構辛かったです。

1月中頃にかなり改善されていましたが、今回久々に使ってみましたら、以下の症状に出くわしました。

  • CQへの応答をダブルクリックしたら、いきなりR-xxのレポートを送ってしまう
  • Log QSOをクリックすると開始時刻がズレることがある

自局のコールは”JH8JNF/1″という設定でしたので、CQ JH8JNF/1とグリッドのメイデンヘッドが無い状態です。

これに対する応答はクライアントソフトによるのでしょうが2パターンあります。

  • JH8JNF/1 JxXxxx
  • JH8JNF JxXxxx PMxx

多分前者はWSJT-Xでは無いかと思います(FT8でもこれを受けるので)。

この前者の形式の応答を受けると、JTDXでは、auto seqでの応答先の選択が間に合わずにダブルクリックせざるを得ず、結果として先に書いたようないきなりR-xxのレポートを送ったり、QSOの開始時刻を読み取る際に始まりのテキストを見つけられずにLog QSOをクリックした時刻が開始時刻に設定されてしまうようです。

後者のパターンでは問題ないですし、また、WSJT-Xでは1.9RC2でも問題なく開始時刻などを拾えるようです。

JT65なら修正する時間があるのでなんとかできますが、FT8ではちとキツイです。当面はFT8ではWSJT-Xを使う方がよさそうです。