QSLへの相手局運用QTHの記載について2022年11月22日 12時28分59秒

紙製のカード、hQSLで相手のコールサインの後に相手のQTHを表記している方が沢山いらっしゃると思います。
PhoneでのQSOやCW/RTTY/FT8等で相手が自局QTHをアナウンスした場合は「正しい相手QTH」を表記できると思います。

しかし相手のQTHを確認できない交信の場合はどうでしょうか?
以下のようなケースが考えられます。

1.同じコールサインで複数免許を持っていてそれぞれがQTHが異なる。
 移動局と固定局でQTHが違う場合は多々あり、どちらから出ているか確認できない
 場合。(FT8等で違うQTHでも同じグリッドロケーターだった場合は判別不能)

2.コンテストの非常に短いQSOで相手がQTHをアナウンスしていない。(コンテストナンバ        ーがQTHを指す場合は除く)

3.過去には法的要件だったが、現在はその要件が外れている移動局の「/エリアナンバ   ー」付加をしていない局。

4.Turbo HAMLOGの環境設定で「過去のQSOからQTHをコピー」が有効になっている
  場合で、転居したのに過去のQTHが反映されてしまう。

その他のケースもあるかもしれませんが。

そもそも自局が発行するQSLは、自局がある局とQSOしたことを証明するものであり、「相手の運用地を証明するものではない」ので、本来はQSLに記載する必須条件ではありません。相手がどこで運用したのかが「確実に判明している場合」を除き、「誤った情報を記載してしまう可能性がある」という事を頭の隅においておかねばならないと思います。

受け取ったQSLには私のQTHを記載しているものとされていないものがあります。 たまたま私は移動局免許も固定局免許も同じQTHで受けていますので一緒です。しかし先にも書きましたように違うQTHで免許されている局もいます。 注意が必要だと思います。

hQSLの定義 その22022年09月13日 11時15分45秒

先日の記事では日付とデジタルモード時の項目について書きました。



今回気づいたことがあり定義を見直しました。 RTTYでQSOした局へのhQSLがレポートが RST ではなく RS になっていたのを見つけたのです

もともとのオリジナル定義では、デジタルとCWとフォーンの区別だけでした。

そこで今回 RTTY PSK31 SSTV も定義に付け加えました。

例えば横長の電子QSL定義をこの様に。

? nData7 "!$$D"
#Mov $$A = "!$$A SNR !HRdB ," ; デジタル
#Goto *456
? End

? nData7 "CW"
#Mov $$A = "!$$A RST:!HR ,"
#Goto *456
? End

? nData7 "RTTY"
#Mov $$A = "!$$A RST:!HR ,"
#Goto *456
? End

? nData7 "PSK31"
#Mov $$A = "!$$A RST:!HR ,"
#Goto *456
? End

? nData7 "SSTV"
#Mov $$A = "!$$A RSV:!HR ,"
#Goto *456
? End
#Mov $$A = "!$$A RS:!HR ," ; フォーン

またFT8,FT4,JT65以外のデジタルモードで SNR でやり取りするモードを個人的に追加しました。

#Mov $$D="FT8,FT4,JT65,Q65,MSK144,JT9,T10"

hQSLの定義2022年09月05日 11時08分08秒

hQSLの標準的な定義だとDate&Timeがyyyy/mm/ddになっています。またデジタルでは項目が dBです。それを dd mmm. yyyy として 信号レポートのタイトルを SNR にしてレポート+dBとするには.....


? UTC!
? Data2 "/05/"
#Mov $$A = "Date&Time: !DD MAY !DY, !TH:!TM JST ,"
? Data2! "/05/"
#Mov $$A = "Date&Time: !DD !DJ. !DY, !TH:!TM JST , "
? nData7 "!$$D"
#Mov $$A = "!$$A SNR !HRdB ,"; デジタル
#Goto *456
? End


これで


こんな感じが


こんな感じになります。

受け取ったhQSLで気になるもの2022年08月11日 09時31分11秒

Turbo Hamlog 使用者で使われているhQSL。時々気になることも。JstではなくてJSTではないのかなぁ・・・ とか。


タイムゾーンの記載がないものも。


タイムゾーンがJのものも。これは誤り。 解説は https://jp1lrt.asablo.jp/blog/2016/02/03/8007807


RSTの項目にコンテストナンバーを記載しているもの。厳密に言えばRS(T)とコンテストナンバーは別物。ナンバーを書くのであればRmksに入れたら良いのになぁ・・・ と思います。



大変細かい話 QSLについて2021年09月13日 15時18分11秒

一個人が何かを「発行する」って機会はあまりないと思いますが、我々アマチュア無線家は「QSLを発行する機会」があり、その発行数も人により差はありますがかなりの数になります。拘りのある方ない方様々だと思います。表のデザインに凝る方、データ面のレイアウトに凝る方。

私のこだわりはどちらかといえばデータ面。先日も「大変細かい話」と称し数点の注意事項をツイートしました。QSLは自分だけが見て理解できれば良いものではなく、送り先の相手を含めて全ての人が誤解の無いように正しく発行しなければならないと思うのです。
不正確であったり不具合があれば「いい加減だなぁ」と思われてしまう可能性もあります。しかし正確であれば余計な事は思われないと思うし、きちんとしているという見方にすらつながるかと思います。
自らが責任を持って発行するものなので、正確すぎて困るものではないと私は思います。私も過去には誤りのあるQSLを発行していたことがありました。気が付かないままに。しかし気がついたあと、他の方からお教えいただいたあとには細かいことまで注意をするようにしています。日本国内だけでなく海外局にも発行しますので、海外の方が見ても不具合がないように気をつけています。細かい って思われでしまうかもしれないですが、相手に届いた時に ???? って思われたら悲しいですし、せっかく発行したのに  「使えねーー」 とか言われてポイされたらもっと悲しいです。
自分のブログで私がダウンロード可能にしている Turbo Hamlog QSL印刷定義です。間違いがあるかもしれません。お気づきの点があればお教えいただけると幸いです。全てのファイルをまとめてzipファイルにしてあります。デジタルモード、日英自動対応です。



以下そのツイートの内容です。一部追加しました。


大変細かい話 QSLについて 
その1
交信年
20  と2桁の数字だけのカードが散見される。
西暦4桁を2桁に省略する際は数字の前に 「'」を付加するのが国際的な慣例です。省略しないで4桁にするか「'20」 のような記述にお願いいたします。
その2
交信月
月を3文字に省略する際は終わりに「.」を付加しますが、無い方もいます。5月「MAY」はそもそも3文字なので「.」は必要ありません。Turbo Hamlog の定義で簡単に直すとができます。 例えば ? Data2 "/05/" #Print x,y,"May" ;5月は付けない ? Data2! "/05/" #Print x,y,"!DJ." ; Jan.など
その3
QSO日時が21/11/10のようになっている
この並び具合だけでは2021年11月10日なのか、2010年11月21日なのか判別は不可能です。どうしてもこのような形式にしたい場合は注釈で yy/mm/dd のような記載をすべきでしょう。やはり月は3文字略、例えば Sep. のように書くと間違いがありません。

その4
交信周波数
項目が「BAND」「FREQ」 となっている場合で、例えば 50 とのみ記載されている場合では「単位」がありません。項目が「BAND」「FREQ」 となっている場合は単位は必須事項です。 この場合 「MHz」を付記する必要があります。10と書いてあるだけだった場合には「10MHz」なのか「10m band」なのかわかりません。「14M」のようにHzを省略している方もたまにいらっしゃいますが、単位は省略すべきではありません。「10M」と記載されていると混乱が深まります。項目が「MHz」であれば数字、例えば 50 だけで大丈夫です。項目が「BAND」の場合は「波長」でもOKなので、その際は「6m」「40m」「10m」のように記載します。

その5
時刻のあとに「J」と一文字だけ記載されている。
これは明らかな間違いです。JSTは省略してはなません。一文字の「Z」があるではないか。はいありますが、「J」というタイムゾーンは存在しません。日本はタイムゾーン「I」(アイ)に位置しています。過去の記事をご参照ください。

その6
これはより良い方向へと言うお願いです。
データ面での貴局コールサインの表示が小さい 、もしくは記載がない。表面を最初に見ればのコールサインがひと目で分かりますが、データ面を見た場合にコールサインが何処にあるか探してしまいます。データ面でのコールサインのアピールもぜひお願いします。 (^^)
その7
あとこれはまだ多くの方のQSLに見られることですが、RS/RST等のレポート欄の項目、デジタルモードのQSOでもSNRではなくてRS or RST になっている方が数多くいらっしゃいます。dBの単位もない方も。将来的にはぜひこれも直してください。


繰り返しになりますが、発行されたQSLを見て誰もが誤解なく正しく内容を理解するような記載にしなければならないと思います。正確すぎて困るものではないのです。

QSL発行漏れ2021年02月22日 10時22分07秒

QSLの発行処理は間違いなくこなしていたと思っていました。

なにげに2020年のログを見直してみると・・・  なんと発行マークが入っていない交信データがあるではないですか・・・

焦って点検すると200件以上も。

直ちに発行作業に入りました。トータルで300枚近くありました。

私は5種類のカードを振り分けて印刷しています。交信時にどのカードを出すか決定してTurbo HamlogのRmksに入力するのですが、どのカードも振り当てられていなかったものがあったようです。
今後は一通り印刷した後に、カード種類を指定しないで印刷コマンドを実行しも発行漏れの無いようにすることとしました。

2019年以前でも同様のことがあるかもしれません。今後随時点検していきます。
QSL未着の方がいらっしゃいましたらば @jarl.com までメールにてご連絡くださいますようお願いいたします。



QSLは正確に2021年01月24日 06時44分46秒

非常に恥ずかしい気持ちになりました。
私の台湾の友人、BV3UF Yangさんが2m でJAとQSOして送られてきたQSLカードを嬉しそうにFaceBookのご自身のタイムラインに写真を並べていらっしゃいます。

しかし・・・  なんとと不備の多いことか。

1.BAND表記なのに144としか書いていない。その単位は必須です。この場合は MHz。

2.QSOモードに2wayまたは 2x という記載がない。

3.QSO時刻にどこの時間か表記がない。(海外局との交信なのにJSTなカードが沢山。)

4.SSBの交信なのにレポートが599

5.何よりも一番恥ずかしいのはBV3UFのコールサインを間違えて書いてある。

不備ではないけど外国局宛のQSLなのに日本語オンリー。住所の市をsityと書いてある。3.にも書いたけど時刻がJST。

自分が発行するQSLの正確性に無頓着なのだろうか・・・ 喜んでいる彼にとても申し訳ない気持ちになってしまいました。


Hamlog QSL 定義2020年10月16日 12時32分47秒

私のブログ、つまりここで配布している「Hamlog QSL 定義」の更新をしました。

右側のリンクからダウンロードして、Turbo HAMLOG で表示させてみてください。

細かい変更なので大した差はありませんが、New MODE FST4に対応させたのと、月の表示を May以外は略の後にピリオドを付けるようにしました。

今回横用を一つ追加と、コンテスト用6QSOまで印字できるものを追加しました。

お役に立てれば幸いです。  記事内にもリンク貼っておきます。

JA宛には日本語、DX宛には英語、デジタルのレポートはSNR、SSB/CWはRS/RST
RTTY/SSTVは RST/RSV に自動的に変わります。


縦1 



縦2 




縦3 



縦4 



縦5 


縦6 



横1 



横2 



横3 









QSLカードを発注2020年05月14日 14時51分31秒


昨日プリントパック社にQSLカード4種類12000枚をオーダーしたのですが、7営業日の一番安いやつなのに翌日である今日、先程配達されました。

きっとどの会社も今仕事無いんだと思います。

QSLカードをオーダーして印刷会社を支援、ってなわけではありませんが、今発注するとどの会社でもきっと早いと思います。

eQSL 仕様変更?2020年04月03日 12時03分43秒

私はFT8にJTDXを使用しています。JTDXはQSOの直後にデータをeQSLに送信する機能があります。
コメントも付けられます。このコメントはeQSLにちゃんと反映されます。


交信はデジタルだけでないので、アナログとかもHamlogに記録をつけ、その後Hamlogの機能としてADIFを出すことができるので、それをeQSLにアップロードしています。今まではJTDXが自動的にアップロードしたものは既に登録済みとされてDupe扱いで記録が書き換えられることはありませんでした。その結果JTDXからのデータに付けられたコメントもちゃんと残ったままになっていたのですが、先程そのコメントが消えていることに気が付きました。

おかしいと思い、JTDXからデータ送信直後にチェックするとちゃんと残っています。その後Hamlogから出されたデータを試しに送るとデータは上書きされてコメントがなくなってしまいました。

これは新しい「仕様」なのでしょうかね・・・

先月は問題なくDupeで弾いてくれたので、コメントは残っていたのですが。使いづらくなったきがします。