「JT65/JT9/FT8」カテゴリーアーカイブ

DX, HamRadio, JT65/JT9/FT8

作戦勝ち (?) – A32DX

コメントする

トンガ A3 はそれなりにペディションはあるが、昨年 A35GC もやっと 10m だけ QSO を増やせた。それで 17/12m の WARC だけが残っていた。その時期は日中は仕事していたから。

07/26 A32DX がニュー・プリフィックスの色付けで 21MHz にデコードされた。

07/27 取り敢えず WARC 優先と 24MHz。バンド・ニュー・エンティティーで色付けデコード。
ニュー・プリフィックスであるから改めて 10m も 40m も QSO。
07/28 A32DX どのバンド？と思って、見たら昨日と一緒　12/15m。

フツーなら A32DX QSY 17M って送るところを “A32DX KED 17M” と 12m で送った。「いつ 17m やるの？」のつもりで。英語の WHEN 17M では「字余り」になるので、op 母語と思しきスロヴァキア語で。
三分後 17m で ＣＱ が出た。

斯くして私の 5 BAND (20/30m 抜き) が完成した。
就寝前に OQRS チェックしてたら全バンド出てたので、8 € ドネーションを加えてリクエストを出した。
そして “KED 17M” 送ったのは私ですとメールで明かしておいた。
07/29 朝 OM2DX からの返信に “I was wondering who was sending that KED 17M message :)))” とあった。

App, HamRadio, JT65/JT9/FT8, ubuntu

ACCESS VIOLENCE – CQRLOG

コメントする

こないだ 8/13 だったか、起動しようとするとコレが出た。 とりあえず隠しフォルダをリネームして、データ・インポート。翌日も同じ。
恐らく OS アップデートの影響か。
8/18 起動オプション –debug=1 指定でエラーは出なかったが、terminal で叩くと

rig_open: error = rig_settings_load_all: opened /home/NAME/.config/hamlib_settings
rig_open: cwd=/usr/bin
rig_open: reading settings from /usr/bin/hamlib_settings
rig_open: async_data_enable=1, async_data_supported=1
create_sync_data_pipe: created data pipe for synchronous transactions
serial_open: /dev/ttyS0
serial_setup: tcgetattr
serial_setup: cfmakeraw
serial_setup: cfsetispeed=19200,0x000e
serial_setup: cfsetospeed=19200,0x000e
serial_setup: data_bits=8
serial_setup: parity=0
serial_setup: Handshake=None
serial_setup: tcsetattr TCSANOW
serial_setup: tcsetattr failed: Input/output error
port_open: serial_open(/dev/ttyS0) status=-2, err=Bad file descriptor
rig_open: rs->comm_state==0?=0
 1:rig.c(1023):rig_open returning(-2) Invalid configuration

なぜか /dev/ttyS0 を開こうとしている。

hamlib ver.4.5.5 で問題はないはず。 CAT に ICT-18 を使っているんで、残るは FTDI 周りか・・・・
最初は libftdi1 だけでもいいかと思ったが、一往 -dev, -doc くらいインストールしておくかで済ませた。 ずっとソレで問題なかった。

synaptic で検索すると他に libftdi1-dbg というのがあると知った。「これで解決できればいいが」という程度の期待。
正しくソレだった。synaptic で依存インストールしてくれればいいのに・・・

$ cqrlog

(cqrlog:14164): IBUS-WARNING **: 14:59:15.125: cqrlog has no capability of surrounding-text feature

Cqrlog Ver:alpha_(130)_Gtk2 Date:2024-08-18
**** DEBUG LEVEL 0 ****
**** CHANGE WITH --debug=NR PARAMETER ****
*** Parameter -h or --help for details ***

OS:
Linux version 6.8.0-40-generic (buildd@lcy02-amd64-075) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.2.0-23ubuntu4) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #40-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul  5 10:34:03 UTC 2024
/usr/bin/mysqld
DX, HamRadio, JT65/JT9/FT8

N5J JARVIS ISLAND – SF/H

コメントする

七月までに N5J が SF/H モードで出ることがわかっていた、そして K8R が N5J の予行演習を兼ねて SF/H でやることも知っていた。
7/14 14:43UTC 15m コールバックなし。
翌朝 23:26 コール再開。20 回目コールバック。感触が掴めた。 Verified も表示。

八月に入った。K8R からの出港が遅れてしまったらしい。早ければ 8/07 QRV とのこと。
8/07 01:10UTC 17m ワッチするも肝心の N5J 入感せず。 ロケーション差か。
そこそこデコードされるようになったのが 02:38UTC。
10 回ほどコールすると、「送信許可」が切れてキイロになる。
決して強い信号とは言えない -13 でのデコード。

K1JT も「Fox 側信号は理論上 -15dB がボトム」と言うらしい。
だから距離的に近い W より遠い JA のコールバックが少ないのかも。
それでもコールし続ける（途中 30 ~ 40 分抜ける）。
03:03UTC から都合 306 回送信後、06:16UTC やっとコールバック。

07:54UTC 40m に QSY。 こちらも信号が落ち着かず。
08:49UTC からコール、09:27UTC やっとコールバック。
ところが RR73 帰らず。 09:41UTC 再びコール。
やっと RR73 にありつけた。

翌日 12m。
01:28UTC 7 コールでコールバック。
しかし 10/15m は CW/SSB のようだ。

8/10 15m やっと出てきた。 00:03UTC からコールして 8 コール目でコールバック。

8/11 私のフルバンドの最後 10m が出てきた。
しかしいつもとチガウ気がする。 JA だけでなく N5J からのレポートが軒並み -16 ~ -18 だ。
結局一時間余りかかってやっと QSO できた。

しかし SF/H は「海賊排除」の目的もあるというが、海賊が送信すると真っ当な N5J もデコードされなくなると言う。
K8R にも海賊はいたという。
20m で（ワッチのみ）
240809_161845 14.090 Rx FT8_SH -13 0.5 2768 DEMENTE QSY
のようなメッセージはソレを物語っているのであろう。

結局ペディション側はノーマル・F/H・SF/H の選択をすることができるが、SF/H は事前に Fox としてのコードが必要になる。
今回は Clublog Wanted #18 というペディションであったからこそ成功と言えるであろう。
となると、今後のペディションがどのような運用形態を採るのか見守りたい。

また SF/H に出てきた非ペディション局を呼びたい場合もあるだろうが、双方が SF/H OFF でなければ QSO できない。
一介のハウンドとしてはこの辺はストレスかも。