« 2022年10月 | トップページ | 2022年12月 »

2022年11月

2022年11月29日 (火)

PICO TNCの製作

PICO TNC製作の記録。徐々に追記していく予定。>> このスレッドが長くなったので続きはPICO TNCの製作その2へ。

Img03051_hdr_small

PICO TNCの情報は以下GitHubから入手。
https://github.com/amedes/pico_tnc

当初はうまく動作しなかった。

反省点1:USB-Serialケーブル不良。RxDが動作しなかった。これがわかるのに半日消費。動作実績のないUSB-Serialケーブルは使わず、すCOMポートからのストレートケーブルが安心。

反省点2:Picoがイネーブルにしている入力端子はオープン状態にしないこと。ADC0(31ピン)をオープンのままにしていたらBeacon送信しなかった。これはADC0が入力有と判断して、入力処理を頻繁に繰り返していたためと思われる(要確認)。入力端子をプルアップ/プルダウンしたら問題は解消した。

動作確認中のブレッドボード。右がシリアルケーブル。デスクトップPCのCOMポートに接続(USB-Serialではない)。奥にある四角いケースがGPSセンサー。D-subコネクタ左側にあるチップユニットはRS232Cレベルコンバーター。Picoは3.3Vなので3.3V - RS232Cレベルに変換している。

Img03052_burst01_small

BeaconのPWM出力。PWM出力は波形テーブル(特定の出力周期でのPWM出力パターンテーブル)に従ってPWMレジスターにDMAで送られる。
Pwm

PWM出力幅が徐々に変化していく様子がわかる。
Pwm_20221129090601

このPWM出力をローパスフィルターで整形すると以下の波形になる(時間軸は異なる)。
Ds1z_quickprint1

ソフトウエア構造:

  • 送信フレームをsend_queue上に作り、その内容をsend()がPWMにDMAで送り込む。
  •  

main(){

   tty_write_str()  // opening msgをuart_queueにセット

   white(1){

      receive()   //Rig(SP)から受信したアナログ信号をADCにてデジタル化しDMAにて取り込み復調。
                //digipeatの場合はアドレス情報を生成
                      //受信データをuart_queueにセット(シリアルターミナル上に表示)

      send()      //送出フレームデータをRig(MIC)へPWMにてFSK信号を送信。
                     //send_start()がPTT ONしDMAトリガーオン、queue上のデータをPWMレジスターに転送開始
                     //DMAハンドラーがqueueデータを全部送出したらPTT OFF

      serial_input()    //uartとgpsからのシリアル・データ入力、unprotoでqueue上にフレームデータ作成

      serial_output()  //uart_queueの中身をuartへ出力

      beacon()  //send_unproto()でqueue上に送出フレームデータを生成

  }  

動作確認方法:

FSK変調済み送出データ(リグMIC入力)を受信データ(リグSP出力)にループバック接続して送出パケットを受信するとともにターミナル画面表示する。

GPSデータ:

GPSの出力データ:以下データを1秒ごとに出力している。GPS出力(RX)をターミナルのRxDに接続してターミナル画面上に出力した。

$GNGLL,3540.78870,N,13738.11970,E,065545.00,A,A*72
$GNRMC,065546.00,A,3540.78872,N,13738.11967,E,0.068,,291122,,,A*69
$GNVTG,,T,,M,0.068,N,0.126,K,A*36
$GNGGA,065546.00,3540.78872,N,13738.11967,E,1,12,0.82,511.8,M,36.5,M,,*44
$GNGSA,A,3,31,22,26,25,32,29,16,196,195,194,,,1.50,0.82,1.25*27
$GNGSA,A,3,73,70,71,82,83,,,,,,,,1.50,0.82,1.25*10
$GPGSV,4,1,13,02,04,103,,03,12,304,,12,01,051,10,16,14,237,25*79
$GPGSV,4,2,13,22,78,256,20,25,31,048,18,26,44,253,31,29,48,092,31*7D
$GPGSV,4,3,13,31,62,336,38,32,56,170,26,194,86,198,33,195,17,167,22*7E
$GPGSV,4,4,13,196,34,198,20*70
$GLGSV,2,1,08,70,42,205,15,71,53,289,24,72,16,331,,73,52,316,28*67
$GLGSV,2,2,08,74,19,273,,81,09,028,,82,24,074,25,83,17,120,20*6E

 

GPSデータが送出パケットのInformationフィールドに反映されない問題:

ソフトウエア構造を見る限り、送出フレームバッファはsend_unproto()が生成するフレームが唯一だと思う。

serial_input()でGPS_ENABLEの場合、gps_input()が呼ばれる。gps_input()は入力文字がLFの場合、GPSデータを送出フレームのInformationにセットするようsend_unproto()をコールする。これにより送出フレームができる。

しかし、この後にmain()でCallされるbeacon()によって送出フレームが上書きされる。

whileループが頭に戻り、send()がコールされるとパケットフレームがPWMで送出されるが、この時のパケットフレームはbeacon()にて生成されたもの。このフレームではInformationは事前設定されたbtextになる。

^^^この解釈は間違い^^^

gps_send()のsend_unproto()コールの後に必ずbeacon()のsend_unproto()がコールされるわけではない。これらの動作はそれぞれが設定されたインターバルで実行される。つまり、gps_send()は3分間隔、beacon()は1分間隔で独立して送出される。

beacon()はユーザー設定のインターバルでsend_unproto()がコールされる。

void beacon(void)
{
    if (!param.beacon) return;

    if (tnc_time() - beacon_time < param.beacon * 60 * 100) return; // convert minutes to 10 ms

    send_unproto(&tnc[BEACON_PORT], param.btext, strlen(param.btext));
    beacon_time = tnc_time();
}

gps_send()はコード内に設定されたGPS_INTERVAL (3 x 60 x 100 = 3min)でsend_unproto()がコールされる。

static void gps_send(uint8_t *buf, int len)
{
    static uint32_t gps_timer = 0;

    if (tnc_time() - gps_timer < GPS_INTERVAL) return;

    if ((param.gps == GPGGA && !strncmp("$GPGAA", buf, 6))
    || (param.gps == GPGLL && !strncmp("$GPGLL", buf, 6))
    || (param.gps == GPRMC && !strncmp("$GPRMC", buf, 6))) {

       send_unproto(&tnc[GPS_PORT], buf, len);
       gps_timer = tnc_time();
    }
}

問題は上記赤字部分。今回接続しているGPSはこのヘッダー文字列のデータ出力がないのが原因。。。。。

$GNGGA, $GNGLL, $GNRMCを追加した。結果、GPSデータが送出されるようになった。

JA0WBT>JA0WBT-1:<03><f0>make my day
JA0WBT>JA0WBT-1:<03><f0>$GNGGA,141400.00,3540.78609,N,13738.11321,E,1,12,0.90,522.8,M,36.5,M,,*49<0d><0a>
JA0WBT>JA0WBT-1:<03><f0>make my day
JA0WBT>JA0WBT-1:<03><f0>make my day
JA0WBT>JA0WBT-1:<03><f0>make my day
JA0WBT>JA0WBT-1:<03><f0>$GNGGA,141700.00,3540.78648,N,13738.11733,E,1,12,0.84,528.2,M,36.5,M,,*4D<0d><0a>
JA0WBT>JA0WBT-1:<03><f0>make my day
JA0WBT>JA0WBT-1:<03><f0>make my day

 

cmakeが出来ない件:

pico_sdk_import.cmakeに要修正箇所あり。以下赤字部分を削除。

LINE6 if ( DEFINED ENV{PICO_SDK_PATH} AND (NOT PICO_SDK_PATH))

この赤字部分が何処で定義されてるべきか不明。とりあえず、ここの部分を外さないとSDKのパスが設定できない。

なお環境変数は以下で設定している
 PICO_SDK_PATH=../../pico-sdk  

 

バグ情報:

バグを発見(赤字部分)。

void serial_init(void)
{
    queue_init(&uart_queue, sizeof(uint8_t), UART_QUEUE_LEN);
    assert(uart_queue != NULL);

    uint baud = uart_init(uart0, UART_BAUDRATE);

    //printf("UART0 baud rate = %u\n", baud);

    uart_set_fifo_enabled(uart0, true);

    gpio_set_function(0, GPIO_FUNC_UART);
    gpio_set_function(1, GPIO_FUNC_UART);

#ifdef GPS_ENABLE
    // GPS
baud = uart_init(uart1, GPS_BAUDRATE);

//printf("UART1 baud rate = %u\n", baud);

    uart_set_fifo_enabled(uart0, true);
    gpio_set_function(4, GPIO_FUNC_UART);
    gpio_set_function(5, GPIO_FUNC_UART);
#endif
}

しかしSDK Documentを見る限り、DefaultはEnableなので、バグは動作に影響しないようにも思える。
Uart_set_fifo_enabled

 

Buildエラーについて:

flash.cにて参照エラーが出てbuildができなかったがsdkを再インストールしてbuildが出来るようになった。

ただし、以下を修正した。

flash.c

修正前 Line8  //#inlcude "hardware/sync.h"   

修正後 Line8  #inlude "hardware/sync.h"

なぜこのinclude行がコメントアウトされていたかは不明。これがコメントアウトされると save_and_disable_interruptsとrestore_interruptsが外部参照エラーになる。

pico_tnc.uf2は/home/pi/pico/pico_tnc/build/pico_tncに作られていた。

 

GGAフォーマットについて:GT-902P

Ggaformat

2022年11月26日 (土)

APRSの軌跡取得実験ーその1

APRSの軌跡データをまとめていく。

2022/11/17 144.66MHZ/1200bps/5W/3分インターバル。登山口から伊勢山、自宅まで。登山口・伊勢山間は徒歩。登山口・自宅間は自動車移動。登山口から頂上までほぼ全域でビーコン受信あり。
22021117

 

2022/11/21 144.66MHZ/1200bps/5W/1分インターバル。自宅から阿寺渓谷キャンプ場までMTB移動。山の神と森林鉄道鉄橋跡の中間点あたりを最後にキャンプ場までビーコン受信はなし。
20221121

2022/11/24 144.66MHZ/1200bps/5W/1分インターバル。自宅から大桑殿地区と十二兼地区をMTBにて移動。かなり良好にビーコン受信した模様。
20221124

2022/11/25 144.66MHZ/1200bps/5W/1分インターバル。恋路峠から飯盛山山頂まで。登り始めと頂上付近以外はビーコン受信なし。
20221125

2022年11月27日 144.66MHz/1200bps/5W/1分インターバル 自宅から大島、橋場、伊奈川、須原、大桑村役場をMTB移動。大桑村役場にて送信中断後帰宅時に再開したため途中の記録がない。
20221127

2022年12月11日 144.66MHz/1200bps/5W/1分インターバル。自宅から、殿、大島、橋場、須原、満寿太橋、和村、右岸道路、和村橋、須原、橋場、大島、殿、自宅の準でマウンテンバイク走行。
20221211

2023年1月11日 Pico-TNC、FT-70D+標準ホイップ、5W.  川向-殿-伊奈川橋-大島-橋場-須原-クロネコヤマト須原営業所 の往復20230111picotncft70d

 

2022年11月24日 (木)

ARPS、UNPROTO、PMSって何?

APRSのベースになっている技術を学びたい。ネット上にあったISS,UNPROTOパケットの運用方法記事。2002年の日付、20年前。
http://www.asahi-net.or.jp/~ei7m-wkt/numbr312.htm
この記事を自分が覚えておきたいポイントで抜粋したのが以下。結局APRSって、ネット上に展開された単一のRound Tableなんだろうなって思った。

PMS:Personal Message System
PRS: Packet Radio System
ISSのパケット通信システムは以下の3つのモードをサポート:

  • PMS:Personal Message System
  • Round Table (デジピート交信のこと)
  • APRS:Automatic Packet Reporting System

ラウンドテーブル(Round Table, ディジピート)またはUNPROTO:
この "ラウンドテーブル" モードとは、キーボード対キーボードの通信の形式のことである。ラウンドテーブルは、短いメッセージをタイプすると、PRS を経由して中継(つまり、デジタル中継 あるいは短い言葉で デジ)され、円卓を囲むように多くの局が参加することができる。

パーソナルメッセージシステム(PMS):
パーソナルメッセージシステム(つまり、PMS あるいは メールボックス) は PRSシステムに 直接、個人の短いメッセージを載せることである。 一度メッセージが保存されれば、オペレータはそれを読むことができるし、そのメッセージに返信することもできる。

自動位置認識伝送システム(APRS):
 APRS モードは、地上の APRS ソフトウェアが 位置情報・地図対象物・使用者との短いメッセージを転送するための特殊なフォーマットに、メッセージ行をあらかじめフォーマットしている点を除いて、ラウンドテーブルのモードと違いはない。

Unprotoコマンド:
UnProto コマンドには二つの項目がある。
第一の項目は TOCALL で、CQ, ALL, APRS, QST など、他のほとんどのソフトウェアで認められている総称的なコールサインのうちの一つを付ける。
第二の項目は 文字 V または VIA
第三の項目は PATH である。ISS に対してはこれは ARISS であり、ISS に対するデジ中継の通称である。もし貴局のパケットが、ISS によってうまくデジ中継するならばそのダウンリンクのコピーは、 RS0ISS コールサインに置き換えられるだろう。PATH の部分は多重記載を含むが、初めの PATH にのみ ISS に対し使われ、貴局のグリッドスクェア または名前を二つの付加部分に挿入できる。

例えば 貴局の TNC で UNPROTO コマンドを構成する正しい例としては:
UNPROTO CQ VIA ARISS
CQ VIA ARISS, FRANK, FM19SX
CQ VIA RS0ISS, FRANK, FM19SX などである。
コンバースモード (cmd: プロンプトにおいて K を入力) に切り替えること。そうすれば、貴局が入力するものは全て UnProtoモードで送信されるだろう。

2022年11月23日 (水)

ThonnyでPicoのVersion upで SSL: CERTIFICATE_VERIFY_FAILED, certificate has expired にハマった件

ThonnyでRaspberry Pi Picoのversionを最新(1.19.1)にバージョンアップしようとしたら、SSL: CERTIFICATE_VERIFY_FAILED, certificate has expired と言われてエラーになった。この対策の備忘録。

現象から。Certification has expiredと言われる。
Thonnycertificationfailed

どこに有効期限が切れたCertificationがあるんだか分からないので、とりあえずThonnyを最新に更新してみた。更新前。
Thonnycurrentversion

ThonnyはここからWindows版をダウンロード。更新後。
Thonnynewversion

しかし現象は変わらず。
Thonnycertificationfailedonnewversion

この症状についてネット検索した結果、この問題のDiscussion Threadにたどり着いた。で、次の書き込みに注目!
I finally got it solved by installing https://letsencrypt.org/certs/lets-encrypt-r3.der 

この中の対応策にならって、このセキュリティ証明書をインポートした。以下、そのステップ記録。

「開く」をクリック。
Encryptr31

「証明書のインストール」をクリック。
Encryptr32

Thonnyを「すべてのユーザー」でインストールしたので、証明書もローカルコンピューターにインポート。
Encryptr33

「自動的に証明書ストアを選択する」を選択。
Encryptr34

「完了」をクリック。
Encryptr35

Encryptr36

これで証明書のインポートは完了。

さてさて、これでうまくいくのだろうかと。。。
Thonnypicoupdatesuccess

うまくいった。Certificationが更新されたということなんだろうけれど、インポートした証明書が一体なんだったのかはよく分からない。

でも、動くようになったので、めでたし、めでたし。

 

2022年11月22日 (火)

UI-VIEW32が表示するシンボルを更新する

UI-VIEW32のインストーラーに入っているSymbolsは古いようなので、これを新しいSymbolsに更新した。

Update ARPS Symbol SetsからAPRSシンボルをダウンロードする。

ダウンロードするシンボルZIPは以下:

Download --> UIview-MySymbols-RevH.zip  <-- Download

このZIPを展開すると以下のファイルが含まれている。

  • mysymb.bmp
  • mysymb2.BMP
  • mysymb.txt

既存のUI-VIEW32のシンボルファイルはUI-View32ディレクトリーの直下にある。

  • symbols.bmp
  • symbols2.BMP
  • symbols.txt

これらのファイルはリネームするか別フォルダーに退避しておく。

ZIPで展開したファイルを上記にリネームして、既存ファイルを置き換えるわけだ。

UI-VIEW32を再起動すれば新しいシンボルが表示されるようになる。

ちなみに古いシンボル表示はこれ:
Map2

新しいシンボル表示はこれ:
Newsymbol
青いシンボルが黒くなった。

UI-VIEW32のオリジナルマップの作製

UI-VIEW32にオリジナルマップを入れたので、その手順の備忘録。

大桑村部分を拡大したマップを入れてみた。JA0WBT-7を中心にした長方形エリアがそのマップ。マップを入れるとUI-VIEW32は入れられたマップの表示エリアを四角枠で表示する。
Map1

このマップはGoogle Mapのマップで自分が入れたいマップの部分をモニターに表示させてスクリーンコピーでJPEGファイルを作る。
Okuwavil

このJPEGファイルの表示領域の左上隅と右下隅の座標をGoogle Mapで取得する。なので、JPEG座標隅位置の座標を取得しやす目印を隅にするとよい。

JPEGファイルはUI-VIEW32¥MAPにokuwa-vil.jpgとして保存した。取得した座標はJPEGファイルと同じファイル名のINFファイル(okuwa-vil.inf)としてMAPディレクトリに保存する。

okuwa-vil.infの内容:

35.45.99N, 137.25.98E <- 左上隅の座標
35.35.21N, 137.52.23E <- 右下隅の座標
okuwa-vil <- マップの名前(マップリストに表示される)

これらのファイルを保存したらUI-VIEW32のMap -> Refresh Map Listを実行する。これでokuwa-vilでAPRS局をポイントできるようにる。

以下がokuwa-vilで表示した例。
Map2

なかなか面白い。

FT3DにおけるAPRSビーコン送信時の問題

FT3DのAPRSビーコン送信に問題があるので、その状況を記録。以降、ここに追記していく予定。

症状

FT3DにてAPRSビーコンを送信すると、FT3Dがハングアップする。ハングアップとしては無変調で電波送信しっぱなし。これはバッテリー駆動の場合に観察されている。外部電源での駆動の場合、どういう状態の場合かは条件出しができていないけれど、ARPS送信実行で100%ハングアップする条件がありそうだ。外部電源での駆動にすれば100%発生するとは限らない。しかし、発生し始めると100%発生するようになる。ハングアップすると電源スイッチによる電源オフしか復帰方法がないようだ。

ハングアップすると以下の画面で固まる。送信LEDは点灯のままだ。バッテリー駆動状態だと、当然のことながら直ぐにバッテリー切れになる。
Img029091_small

Yaesuホームページによるとファームウェアは2019年リリースの1.02が最新で、このFT3Dはそのバージョンが稼働している。

観察と考察

特に何か設定値を変えたわけではないが、外部電源で100%起きていたハングアップが今時点では発生していない。

TX Powerは特に関係ないようだ。

バッテリー駆動で発生するハングアップもパワーオンからの時間に関係しているか(バッテリー残容量との関係)は不明。

設定値のような固定的な条件ではなく、状態値のような変動する条件で発生するのか?

そもそも、APRSビーコン送信してから受信状態に戻れないというのはどういうことなのか。ビーコン送信はTXインターバル間隔でのタイマー駆動なのだろう。そこで、各送信時点でのパケットを送信し終わったら送信を止めるはずだ。これが止まらないということはパケット送信完了を認識できないということか。つまり、パケット内容に依存するのか?

追記 -------------------------------- 

2022/11/22: 本日外部電源、TX POWER=LOW1、TX Interval=3分にてBeacon送信設定して外出した。4時間後の帰宅時、送信状態のまま(送信LED点灯のまま)で固まっていた。Power OFF/ONにて復活。

2022/11/25: 本日APRSビーコン送信設定で山行に出たら1時間しない内に送信しっぱなし現象が発生。午後、YAESUサポートより電話あり。技術部門に確認したところ、そういう事例は今までなくガイドが出せない。まずはオールリセットを行って状況を確認してほしい。それでも再現する場合は当該リグをメーカーにて預かるとの事。この場合以下のコストが発生する。

  • 状況(再現性)確認:5,280円
  • 修理技術料:12,000~17,000円
  • 部品代:別途見積
  • 返送時費用(代引き手数料・梱包費など): 2,000円

期間としては3週間が目安とのこと。YAESUへの発送費用も必要となるので、3万円は必要だろう。修理依頼はネットから行うようだ。また修理代金はヤマト運輸の代引きでの支払い(現金のみ)となる。

オールリセットをしても問題は再現する。つまり修理依頼となる。当該FT3DはAPRS以外には不具合が認められない。さて、どうするか。。。。

 

2022年11月20日 (日)

APRSの山行実験 - 南木曽町伊勢山

ARPSの山行実験を行ったのでその記録。

  • 基地局:FT-7800 + 3段GP
  • 移動局:FT3D (5W) + 1/4ホイップ、Beacon TXインターバル3分

登山開始地点までは自動車にて移動。そこからは徒歩移動。基地局(I-Gate局)は登山開始地点から直線距離でおよそ7kmのところにある。

山行自体は4時間程かかっているので、ビーコン送信回数は80回程となるが、Google Map上のプロットが等間隔っぽく配置されているのでプロットは間引きされている(ビーコンが受信できなかったわけではない)と思われる。

Aprs2_20221120171001

山行におけるAPRSの軌跡がどのような感じになるか様子がつかめたので、次回は中央アルプス登山口あたりでデータ取りをおこなってみたい。

 

APRS用 リグのData端子とPCのCOMポート接続アダプター

APRS用にリグ(FT-7800)のDATA端子とPC(Lenovo ThinkCentre)のCOMポートとの接続アダプターを作ったのでその記録。なお、運用は1200bpsを想定している。

ユニバーサル基板上にMiniDINコネクター、D-Sub 9ピンコネクター、ステレオピンジャックコネクターx2を実装し、インターフェース間の変換回路を実装し、100均のプラスチックケースに収めた。

Img02889_small

電源はアマゾンで購入したUSB給電のDC-DCコンバータを使い、フタに結束バンドで固定している。USBはPC本体のUSBコネクターに接続するので、電源も含めてPC1台で完結させている。なお、USB延長ケーブルは100均で調達。
Img02893_small 

FT-7800のDATA端子仕様は以下の通り。Packet Data Input、Packet Data Outputとも10KΩとインピーダンスが高い。一方、今回使うPC Lenovo ThinkCentreはAudio LINE INとLINE OUTの端子を備えているので、Packet Data InputをLINE OUTに、Packet Data OutputをLINE INに直結した。ここで特記すべきことはPacket Data Inputの1200bpsの入力レベルが40mVp-pとやたら小さいことだ。9600bpsは2.0Vp-pとこっちはやけに大きい。その差50倍。なんでこうなってるんだろう???
Data

Windows 11のサウンド設定でLINE INをオーディオ入力ソースに設定する。LINE OUTに関する設定は無く、オーディオ出力設定上はスピーカーと同じRealtek High Definition Audio出力での設定となる。LINE OUTでもスピーカーのボリュームでレベル調整が反映される。また、LINE OUTにジャックが差さっていてもフロントパネル上のヘッドフォン端子からサウンドは出る。
Photo_20221120162601

LINE INはボリューム100で丁度良い感じ、というかFT-7800からのData Out値が小さいようだ。この設定状態でAGW SoundCard Tuning Aidで観察した波形が以下。
Photo_20221120163601

LINE OUTのオーディオレベルは6/100とした。可也絞ることになるが、この値でUI-WIEW32からのビーコン(Action -> Send Beacon)とMessage送信において、FT3Dとのコミュニケーションができた。まぁPacket Data Inputが40mVp-pなのでしょうがない。ちなみにPCのヘッドホン端子に接続するとオーディオレベルは50となる。これはインピーダンスの違いによるものと判断。
Soundproperty-2

UI-VIEW32がCOMポートに出すRTSをFT-7800のDATA端子のPTTに接続しているからFT-7800がこのピーピロピロを送信するわけだが、その接続回路は以下とした。ここではFT-7800のSQLをCOMポートのCDにも接続しているけれど、UI-VIEW32側でSQLを見ている訳ではないので、信号が入った(SQLが開いた)時にGREEN LEDが点灯するくらいの作りになっている。

Rs232cdatainterface

とりあえず、これでRF to InternetとInternet to RFの双方向の通信が出来る仕組みは完成した。

一点、今回のボード製作でD-Sub 9コネクターのピッチ変換ボード(DSUBコネクタDIP化基板(オス・メス兼用) AE-D-SUB-9P-DIP-A)を秋月電子から調達したのだけれど、これでちょっとハマってしまったので備忘録として記録。このピッチ変換ボードは取り付けるコネクターのタイプ(メスかオス)によって分かれているピン番号っぽいシルク印刷がある。これが曲者だった。このシルク印刷がピン番号を表していると思い込んで配線したけど動かない。実際にテスターで当たってみたら以下が正解だった。Img02896_small
そもそもDsub 9pinは5ピンと4ピンの2列ピン配列。この基板はよく見ると1から9まで入れ子無しピン配列が変換できるようなパターンレイアウトになっていない。だから、5ピン列と4ピン列でまとめパターンレイアウトになるわけだ。なんとも不親切というか落とし穴のようなシルク印刷だと思う。

まぁ、とりあえず動いたのでめでたし、めでたし。

 

2022年11月15日 (火)

APRS I-Gateの設置

APRS I-Gateサーバーを構成したので、その備忘録。

木曽谷はAPRS空白地帯。一方で中央アルプスへの登山道が何本もある。それらの登山道の多くのエリアが携帯圏外。ここでの遭難防止のためにAPRSを活用したいのだが、空白地帯故に役に立たない。これは新たに立ち上げるしかない。

で、とりあず実験システムの構成。

ヤフオク!でゲットしたFT-7800とメルカリでゲットしたThinkCentraで構成した。アンテナは軒先ホイップアンテナ。とりあえずFT7-7800の外部スピーカー端子をThinkCentraのマイク端子に直結した。

ThinkCentraはWindows 11、TNCはAWG Packet Engine、サーバーにはUI-VIEW32で接続した。全体の実験構成は以下。
Photo_20221116080201

今回の実験に使ったFT-7800
Img02642_small

I-Gateサーバーとして使っているLenovo ThinkCentre。FT-7800の外部スピーカー端子からマイク入力端子に直結している。ThinkCentraに外部スピーカーを取り付け、マイク入力をスピーカーモニターする構成にしてFT-7800からの音声入力をThinkCentraにてモニターしている。
Img02644_small

ビーコン発生機としてFT3Dを使用した。
Img02653_small

Software TNC、AGWPEをダウンロードする。この時AGW Monitorも一緒にダウンロードする。具体的な設定方法についてはソフトウエアTNCの解説を参考にした。AGW MonitorはAGW Monitorが実際にデコードできるかをチェックする。チェックの際、トランシーバーの音声出力レベルやPCのマイク入力レベルを調整することになる。

UI-VIEW32のインストールについては、いろいろなWEBページがあるが、どれも10年以上前とかなり古い。けれども、逆にそれ以降このアプリケーションは変更がなく、かつそれ以降あまりインストール事例報告がないともいえる。今回は、以下の3WEBページを参考にさせて頂いた。

細かなパラメータ設定は最初の2つに大変助けて頂いた。3つ目には命を救われたように思う。特に今回はWindows 11でのインストールだったのだけれど、アプリの互換性設定についてはめちゃくちゃ貴重な経験を共有いただいた(こころより感謝)。

以下、ちょっとハマったところの備忘録。

真っ先に行うComms Setupでつまづいた。そもそもこのCOMポート設定って何なんだろうってことになるわけだけれど、UI-VIEW32がデータを取得する元はTNCで、ハードウエアTNCの場合はRS-232CでPCと接続するのだろう(これに思い当たるのにちょっと時間がかかった)。であれば、ソフトウエアTNCを使っている場合はどうなるのか???先の3つのWEBページの2つ目に答えがあった、Host modeでAGWPEを選べばよいのだ。これで解決した。

Comms SetupでのHost mode設定。
Awgpe

Setup -> APRS Server Setupで接続先となるAPRSサーバーを指定する。ここでは先のWEBページのガイドに沿ってaprsjp.net:14579を設定した。しかし、いつまで経っても自分の存在がMap上に現れない。そこで、Option -> Show IGATE Trafficを選んでRF to Internet Trafficを見てみたが、Trafficがない。つまり、サーバーとの通信がないわけだ。そもそも、APRS Server Setupで設定したサーバーにどういタイミングでログインするのか???Server SetupダイアログでOkボタンをクリックしたらログインするのか???どうもそこの理解が正しくなかったようだ。Actionメニューを見るとAction -> Connect to APRS Serverとある。ここをクリックしてみた。何度かTimeoutが起きたけれど、数回のチャレンジのあと、無事APRS Serverに接続した。接続するとMap上に沢山のノードが表示され、IGATE TrafficのRF to the Internetにも、ビーコン受信に合わせてトラフィックがレポートされた。

APRS Serverに接続した後のAction Menu。
Aprsconnection

次にMap上のシンボル設定。ネットで公開されているシンボル設定に従ってシンボルを設定した。

No Diam’dでR(I-Gate単体でReceive Only)に設定した。
Symbol

さてさて、これでI-Gateサーバーが動くようになったので、FT3D(暫定的にTX Interval=1分に設定)を携帯して自動車にて近所を走ってみた。以下がその結果。
Arps

1分は自動車としては案外長い(移動する)。

とりあえず基礎実験が完了した。今後は以下のテーマで先に進むこととする。

  • 携帯圏外(中央アルプス登山道)でのARPS電波受信実験
  • パケット認識率向上のためのチューニング(現在は無線機とスピーカー出力とPCのマイク入力直結)
  • 双方向通信の為の環境構築
  • 9600bpsでの運用実験

まずはめでたし、めでたし。

2022年11月13日 (日)

PCIe dual serial port adapterドライバーCH38XDRV.ZIPのWindows11へのインストール

AmazonにてPCIe 2 serial port adapterを購入。ドライバーインストールで手間取ったので備忘録。

メルカリでLenovo ThinkCentreをゲット。COMポートを使うアプリケーションでの使用が目的だが、届いてみると、なんとCOMポートが実装されていない。しょうがないので、LOW HIGHTのPCIe Serial Port Adapterをアマゾンで購入した。2099円。余分な出費(COMポートの存在を確認していればこの出費はなし)。

届いたアダプター。
Img02608_small

早速実装した。
Img02575_small

DRIVER CD-ROMが付属していたがドライバーインストールファイルの日付が2018と古いのでネットからメーカーのドライバーをダウンロードした。このドライバーページは英語版。PUMPSETUP.EXEというインストールツールを使ってインストールしたがエラーが表示された。
Img02568_small
デバイスマネージャで見てもドライバーのインストールが無いといって黄色のビックリマークが表示される。どうもデバイスドライバーがWindows11に対応していないようだ。ダウンロードページの説明ではWindows11対応になっているのだが、、、

Googleで検索しなおすと同じメーカーの中国語ダウンロードページがあった。ドライバーをダウンロードして日付を見ると2021年になっている。これならWindows 11対応だろうと思い、先にインストールしたドライバーをアンインストールしてから、ここからダウンロードしたドライバーをインストールしてみた。インストール成功。デバイスマネージャでCOMポートが二つ表示された。

ということで、めでたし、めでたし。

2022年11月 8日 (火)

軽トラにモービル無線機と取り付け

我が家にFT-4700が引っ越してきた。

常設無線機の設置がない軽トラにこれを取り付ける。

まずは電源コネクタ。モービル機を持ち込みできるように軽トラではT型ハウジングコネクターでバッテリーから電源を引っ張りだしてる。FT-4700をここから給電するようにコネクターをアマゾンで調達(キタコ(KITACO) コネクターセット 250型/2極(オス/メス)/1セット 汎用 0900-755-02005)220円。
Img02086_burst01_small

本体ユニットは運転席と助手席のシート間に設置することにした。シート間にはサイドブレーキや4WD/2WD切替レバーがあるので、それらの上に本体ユニットを配置すべく、高床台座を作ってアルミ線で本体ユニットを固定した。
Img02100_small

高床式台座で本体ユニット取り付けた状態。台座は特に固定しておらず、サイドブレーキ等のハウジングを挟み込むようにしている。
Img02101_hdr_small

コントロールユニットは灰皿にゴムバンドで固定した。コントロール固定アングルと灰皿の間には滑り止めシートを入れてある。
Img02104_hdr_small

取り付けた状態を前から見るとこんな感じ。灰皿の上に取り付けられているって印象は薄いと思う。
Img02103_hdr_small

これで軽トラに無線機が常設されたので、行動パターンに広がりが出るかなって期待している。FT-4700を譲ってくれたSFF局に感謝!

« 2022年10月 | トップページ | 2022年12月 »