2023年1月26日 (木)

アンテナアナライザーAA-1500でのケーブルインピーダンス測定について

Facebook RigExpertグループに投稿した内容をこちらにまとめておく。

事の発端はローカル局のアンテナ調査。6m同軸ケーブルでSWR=1.9位になる件。同じアンテナで10mだとSWR=1.1。そこで、ケーブル・インピーダンスを計ろうと思ったことが事の始まり。

ケーブル端に50Ωのダミーロードを付けてケーブルSWRとR,Xを測定したが、SWR=1.45、R=72Ωと出た。ちょっと変なので、AA-1500に直接ダミーロードを付けて測定した。

Photo-1がダミーロードを取り付けているところ。Photo-4でDC抵抗が50Ωであることを確認。
Img03799_small Img03800_small

この状態でもSWR=1.44(Photo-2)、R=72.75Ω(Photo-3)。System Impedanceは50ohmとなっている(Photo-5)。何かがおかしい感じがするのでSelf testを実施したらLoad Testにて232エラーとなった。232エラーが何を意味するかわからないけれど、Self Testがエラーに終わったのはわかる。

Screens

この状況をRigExpertグループにて報告したら、ダミーロードが3GHzまで対応するアダプターなしのダミーロードでないのがいけないとのコメントをいただいた。いいかげんなダミーロード取り付けが原因でSelf Testがエラーになるという指摘は反論することができないが、この状態でR=72.75ohmというR,X Chartが出てくることは納得がいかない。50Ωのダミーロード直付けでR=72ってのはどう見ても変だ。

Self TestがちゃんとしたダミーロードならPassするのだろうか?これはちゃんとしたダミーロードを買って試してみるしかない。一方AA-1500にはCalibration機能がある。カジュアルな方法になるけれども手持ちのダミーロードでキャリブレーションしてみたくなった。そのうえでケーブルインピーダンスを計ろうと思う。

まず同軸ケーブルの等価回路から特性インピーダンスを求める計算式を設定する。測定はRG58/1.5mと5D2V/6mの2本で行った。Open、Short試験でのShortではM型メスコネクターにて芯線と外被線をショートさせた。

Cablezo1

それぞれのケーブルの特性インピーダンスはともに70Ω程度となった。50Ωのダミーロードを直結した状態とほぼ同じだ。なので、系としてはちゃんと動作している感じだが、インピーダンスが50Ωから随分と外れている。

Cablezo2

そこでCalibrationを実行。

Cablezo3

キャリブレーション後のケーブルインピーダンスはおよそ50Ωと算出された。こうならないとおかしい。

Cablezo4

実際のアンテナのSWRがCalibration適用有無でどう変化するかを確認した。

Cablezo5

SWRの変化の様相は周波数によって異なることがわかる。ただ、思いのほかCalibrationの影響が現れていない感じもする。周波数によってSWR値が変化する(10MHz)場合とSWR値はそれほど大きく変化しないが共振点が変化する(14MHz)場合があることがわかる。

よくよく考えてみるに、なぜCalibration機能があるのだろう?ここについてはもう少し考えてみたい。

2023年1月20日 (金)

XR2206 Function Generator ICでのFSKについて

XR2206を使ったFunction Generator kitを作った。このICはFSKをサポートするのでその動作について確認した。

Img03748_small
奥がKit、手前がFSK切替信号を発生させているPico。

このキットは中国製で、正弦波と三角波を生成するFunction Generator。少ない外付け部品で広範囲の周波数の信号を作ることができる。回路図は以下のとおり。キットの回路図にFSK実験用のR10とPICO接続端子、SINE出力のAC成分だけを取り出すようにC10を追加している。

Xr2206fsk

このXR2206はTC1・TC2間に接続されるコンデンサーCとTR1(P7)とTR2(P8)のそれぞれに接続される抵抗値R6,7,8とR10によってそれぞれ2つの周波数を生成する。この周波数のどちかを出力するかをFSKコントロール端子(P9)によって選択する。発生する周波数は以下のとおり。

F = 1/RC

Xr2206fsk2

キットの回路図にR10を接続し、FSK制御信号として、Picoから8msecインターバルの信号を入力した。その結果が以下のオシロスコープ出力結果になる。

Ds1z_quickprint1_20230120212301

周波数の切り替えはスムーズだ。全く同期がとれていない2つの発信波形を切り替えると、切替時点でレベルが大きく変化するが、XR2206は波形のレベルが引き継がれている。これってどうやって実現するんだろう??優れものだと思う。

2023年1月15日 (日)

NEO-7M GPSモジュールが中国から届いた

アマゾンでオーダーしたNEO-7M GPSモジュールが中国郵便ePacketで届いた。PICO-TNCのGPSモジュールとして使えるか確認する。

届いたのはモジュール基板とアンテナモジュール、ピンヘッダー。
Img03600_small

ピンヘッダーを半田付けして、RS232Cレベル変換モジュールを通してPCのコムポートに接続してGPSモジュールの出力を見てみた。
Img03622_small

GPSモジュールは以下のテキストデータを1秒間隔で出力し続けている。

$GPRMC,013837.00,A,3540.78920,N,13738.11534,E,0.134,,150123,,,A*76
$GPVTG,,T,,M,0.134,N,0.248,K,A*2B
$GPGGA,013837.00,3540.78920,N,13738.11534,E,1,06,1.91,540.5,M,36.5,M,,*53
$GPGSA,A,3,25,32,24,10,23,12,,,,,,,3.20,1.91,2.57*09
$GPGSV,3,1,09,10,47,226,29,12,51,054,26,22,29,312,10,23,26,190,12*7B
$GPGSV,3,2,09,24,22,071,09,25,79,103,30,29,12,146,08,31,26,273,26*77
$GPGSV,3,3,09,32,61,324,29*48
$GPGLL,3540.78920,N,13738.11534,E,013837.00,A,A*6D

この出力内容の内、$GPGGAはプロトタイプで使っていたGPSモジュールが出力していた$GNGGAとフォーマットが同じであることが確認できたので、この出力をそのままPICO-TNCのコードに読み取らせた。

結果は良好で、PICO-TNCはビーコンを発生することができた。なお、NEO-7Mモジュール基板はGPSデータ出力時にLEDを点灯する。よって、このLEDの点灯でGPSデータ受信が行われていることが分かる。
Img03644_small

NEO-7Mモジュールをプラケースにねじ止め固定した。
Img03647_small

蓋を閉じる前の様子はこんな感じ。ケース内のスペースにはまだ若干の余裕がある。
Img03646_small

蓋を閉じるとこんな感じになる。FT-70Dよりも一回りちょっと大きなケースとなるが、プロトタイプ1号機としてはまずまずの出来だと思う。
Img03648_small

PICO-TNCとFT-70Dで近所を軽トラ(超低速)で走ってみた。Beaconインターバルは1分。プロットはいずれも移動経路上にあり、GPSとしては使いそうと判断した。
20230115neo7mtracking

このNEO-7Mモジュール+アンテナモジュールはアマゾンで850円程。送料が800円かかる。とりあえず追加で3個をオーダーした。

追記

このGPSモジュールは捕捉できるGPS衛星の数が5から8個程度のようだ。秋月で購入したGPSモジュールは、みちびきも捕捉できるので12個だった。つまりこのGPSもジュールはそれなりの誤差があるということだ。

$GPGGA,013837.00,3540.78920,N,13738.11534,E,1,06,1.91,540.5,M,36.5,M,,*53
$GPGGA,202824.00,3540.79166,N,13738.11552,E,1,07,1.55,510.8,M,36.5,M,,*59
$GPGGA,221438.00,3540.78683,N,13738.11710,E,1,08,1.10,513.7,M,36.5,M,,*52

実験をしている作業場所をGoogle Mapでみてみると35.67982(3540.7892)、137.63527(13738.1162)とでてくる。標高も30メートルは前後する様子だ。

2023年1月 9日 (月)

TNCアプリにおけるDemoduatorの動作確認

PICO TNCのdemodulatorにおける信号処理を調べてみた。

demodulatorはADCデータを1バイト読み込み、ある値sumを出す。sumを算出するに当たってdemodulatorは以下の信号処理を行っている。

  • Bandpass Filter 入力:adc  出力:val
  • Digital Correlator (Delay) 入力:val  出力:m
  • Lowpass Filter  入力:m  出力:sum

それぞれの処理後の値をプロットしてみた。

まずは全体像。それぞれの値に大きな差があるため、わかりにくくなっているが、mとsumの関係はわかる。
Graphtotal

ADCデータ列
Graph1

Bandpass Filterの出力。通過周波数は900Hzから2500Hz。これによってOffset成分がなくなる。
Graph2

Delayの出力。DelayはMarkとSpaceのTone差を最大化することを目的としている。これにより、両Toneの分別がしやすくなる。ここでは446usのDelay値を積算することで1200Hzは正値、2200Hzは負値となるようにしている。一般的なDelayはDelay値を加算しているが、ここでは積算している。
  m=val[t] * val[t-446us]    なお、Sampling Rate =1200x11では6サンプル分遅延した値を積算している。
Graph3
6サンプリング前の値を取り出す方法として、6エレメント(6サンプル)のリングバッファを使っている。リングバッファの場合、現在のポインタをtとすると、t+1は現在よりも5サンプリング前のデータが格納されている。t+2は4サンプリング前、、、、といった具合。なのでtは今から6サンプリング前のデータ格納されている訳で、その値を取り出してから、tに新しくサンプリングしたデータを格納する。こうすることで、過去のサンプリング値を取り出したあと、そこに新しいサンプリングデータを格納し、ポインターを一つ進める、という動作を繰り返すことで常に6サンプリング前のデータを取り出すことができる。

Lowpass Filterの出力結果。カットオフ周波数は1200Hz。プラス部分がSpace(2200Hz)、マイナス部分がTone(1200Hz)となってる。逆に言えば、この波形を取得するためにDelayを使っている。
Graph4

レベル識別の閾値は以下のとおり

  • sum <  - 4096 : bit=1 (Mark)
  • sum >=  4096 : bit=0 (Space)

DIGITAL PLL

Ditigal PLLは11回で1 Time Domainを形成している。

  • PLL Counter Step = 390,451,572
  • PLL Counterは正値5回負値6回、または正値6回負値5回の合計11回で1 time domainとなる。
    • PLL Step 11回でbit decode
  • 入力bitに遷移が発生した時にPLL Counterを25%調整する。
    • PLL Counter値が負値の場合は25%加算し、正値の場合は25%減算する。

このPLL Counter値の正負で25%加算減算するのがミソで、bit遷移が発生した時点でのPLL Counter値からPLL Counter値自体を調整し、遷移点とTime Domainの位置関係を保っている。

実験結果

PICO_TNCが発生するAFSK信号をPCに取り込み、サンプルコードでDelay(積算)とLowpass Filterを通してみた。

Beacon Delay Lpf

Beaconデータ:ダウンロード - mice7mono.wav

Delayコード:ダウンロード - dd_psude_stereo2.c

Delay後データ:ダウンロード - mice7mono_output.wav

LPFコード:ダウンロード - dd_lpf2.c

LPF後データ:ダウンロード - mice7mono_output_output.wav

 

2023年1月 5日 (木)

wsappxの停止、スタートメニュー表示なし、検索不可に関する対応方法メモ

Windows 10における以下問題の対応と方針

  • wappxのシステムリソース消費大
  • スタートメニュー表示なし
  • 検索欄に入力できない

作業記録

gpeditにてwappxを未構成に設定。ターゲットPCは既に有効に設定してあった。有効設定でもwappxは可也のCPUとメモリーの両リソースを消費していた。

Regeditにてsvchostのwappxをclipsvc AppXSvcからNotFound AppXSvcに変更

以上でCPU使用率およびメモリー使用率はかなり低下した。

その他問題で実施したこと

スタートメニューが現れない件参照リンク

以下を試したが効果なし。

システムファイルの整合性等の確認

  • DISM.exe /Online /Cleanup-image /Restorehealth
  • sfc /scannow

システム必須アプリの再導入、PowerShellから以下を実行

  • Get-AppXPackage -AllUsers |Where-Object {$_.InstallLocation -like “*SystemApps*”} | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register “$($_.InstallLocation)\AppXManifest.xml” -Verbose}
    この実行は10時間以上時間がかかる。Powershellは途中でエラー終了してしまった。

検索入力が出来ない件参照リンク

以下を試したが効果なし。

  • ctfmon
  • コマンドプロンプト管理者権限で以下を実行
    REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v ctfmon /t REG_SZ /d CTFMON.EXE

復帰ポイント12月23日に戻す(Edgeのインストールがおこなわれていたようだ)-> 戻すことはできたが

スタートアップオプションからスタートアップ修復  -> スタートアップ修復するものがない

セーフモードからの回復、更新プログラム実施前に戻す -> 更新から10日以上経過していると戻せない

--------

上記いずれもNG。イベントビューアをみると以下のエラーが多発している。

障害が発生しているアプリケーション名 TextInputHost.exe
障害が発生しているモジュール名 KERNELBASE.DLL
TextInputHostに障害が発生すると日本語変換にも影響がでるらしい(参照リンク)。

このTextInputHostのエラーがスタートメニューや検索での問題を引き起こしている可能性が高いと判断。上記参照リンクではインプレースアップグレードによる修復でリカバリー成功している。

TextInputHostに関する修正がKB5019157にて昨年Windows11に適用されている。恐らくWindows10にも適用がされたのではないかと思うが記録なし。ターゲットPCでは12月15日更新プログラムが適用された記録があるので、この変更がエラーの引き金になっている可能性が高い。しかし、更新から10日以上経過していると更新前には戻せないようだ。

KERNELBASE.DLLが何でエラーを出し続けているかは不明。何かしら入力デバイス(タッチパッドなど)から異常な入力が頻発するとこうなるのだろうか?こうなるとインプレースアップグレードが視野に入ってくる。デバイスマネージャでタッチパッドをアンインストールしても状況は変わらず。次の再起動でドライバー再導入となったが状況変わらず。

KERNELBASE.DLLの修復に関する記述から、KERNELBASE.DLLの入れ替えが有効と思われる。しかし、この作業をマニュアルで行うことはリスクが高い。むしろインプレースアップグレードを行う方が安全・確実と判断できる。

Windows10のインプレースアップグレード

手順に従ってインプレースアップグレードを実行する。インプレースアップグレードとはシステム部分のみを上書き(アップグレード)するWindowsインストール手法。

この時点での結論

Windows10のインプレースアップグレードを実施する。一般的な修復作業では改善が見られず、手探りでWindows内部に手を入れようとするとWindowsのデスクトップが立ち上がらなくなるリスクを伴うので、インプレースアップグレードにより包括更新を行うのがベストな対応と判断される。

 

作業内容の詳細

Group Policy Editorによる修正

ストアの更新プログラムの自動ダウンロードおよび自動ダウンロードを未構成にする。

Wapp01 Wapp02 Wapp03

Registryの修正

Wapp04

Windows 10無印ではgpedit.mscが存在しないのでRegistryを直接編集する。
コンピューター\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost
既に何かがインストールされているとxxx AppXSvcとエントリーされているはず。ここをNotFound AppXSvcとModifyする。
なお、Registry変更の場合は必ず事前にエクスポートして変更前データを保全しておくこと。

wappxの自動更新の未構成設定とRegeditによるwappxプロパティの変更の前後でのパフォーマンスモニター改善

作業前:wappxがCPUをかなり消費している。
Img03454_20230108143901

修正後。wappxによるCPU消費は改善された
Img03456_20230108144101

System File Checker (sfc) によるシステムファイル確認

破損ファイルが見つかったが正常に修復された。Img03458

DISMコマンドによるScanHealthtとRestoreHealthの実行

その後のsfcで正常性を確認。
Img03461

上記作業後もスタートメニュー、検索とも改善無し。

Windows アプリ更新作業の実施(背景画面)22時から翌日7時まで実行後、途中でPowerShellが停止してしまった(前面に出ているファイルリストはイベントビューでエラーがログられているtextinputhost.exeの保存先)。この後の再起動でWindowsが立ち上がらなくなり(Explorer起動エラーと思われる)、タスクマネージャから再起動をかけたところWindowsが復旧した。このことから、真の原因が不明なまま大きなアクションを実行することはリスクが伴う判断する。
Img03475

イベントビューワーのApplicationのイベントログには3分間隔でTextInputHost.exeの障害がログられている。障害を発生しているモジュールはKERNELBASE.dllなので、仮に障害対応を実施するとなるとKERNELBASE.dllに対して行うことになる。
Img03476

TextInputHost.exeとの関係で入力デバイスの問題を仮定し、TouchpadをDisableしてみたが効果はなかた。
Img03478_20230108145501

念のため、スタートアップオプションで修復作業を試みたがいずれも効果は無かった。
Img03493

Img03477
回復オプションで、explorerのシステムエラーがレポートされた。今回の障害との関連は不明だが、何かしらの異常な(大量な?)入力が行われている事を示唆しているようにも感じる。

加えてとても気になるのが頻繁(2,3秒おき)に回転リングが表示されることだ。これとKERNELBASE.dllとの関係を疑ってみる。
Img03495

定期的にシステムリソースを消費しそうなアプリで、かつ年末にインストールされたものとしてAvast Antivirusが目に留まった。
Img03497

これをアンインストールしてみる。結果は効果は認められなかった。
Img03496

以上

追記

インプレースアップグレードによって今回の問題は解消!!!

やっぱりマニュアルでチマチマ作業するよりは一括で更新がリスクも少なく安全と実感した。ただし、Windows 10が最新バージョンに更新されることで戸惑うアプリもあるようだ。実際、更新後にAcrobat Readerが互換性問題を検出し、継続使用するか否かのユーザー選択を求めてきた。

手順はシンプルでWindows 10ダウンロードリンクにアクセスし、ツールを今すぐダウンロードをクリックする。後は表示される手順に沿って作業を進めるだけ。ただ、その前にセキュリティツールをアンイストールすることがRecommendされている。これはセキュリティツールがWindows インストールを阻害する(システムファイルへのWriteアクセスをさせない)場合があるため。インストールプロセスが途中で停止してしまい、システムが不定状態になると厄介なので、ここは確実にアンインストールする。実際の作業ではNorton 360をアンインストールしたが、このアンインストールに先立って、後の再インストールの為にユーザーアカウント情報を保存するか聞かれるので、保存するを選択する。これによってWindows 10インプレースアップグレード完了後にNorton 360をインストールすれば、アンインストール前の状態に戻せるはずだ。

Win10

Windows 10ライセンスを含めた個人情報が引き継がれると思うので、Windows 10の再インストール後も自分用にカスタマイズされたWindows 10環境はそのまま維持されるはずだ。

Img03692_small

Windows 10インストール自体は結構時間がかかる。
Img03693_small

Windows10本体のインストール後は更新プログラムのインストールが続く。この過程で何度か(5回くらいだったか)リブートする。
Img03696_small

一連のインストール/更新作業が完了すると、ログオン画面が現れ、ログオンするとWindows 10インストール前のデスクトップが維持された状態でWindowsが立ち上がる。

事前情報通り、個人情報とアプリ環境はそのままでWindows 10本体が最新バージョンにリフレッシュされたようだ。このリフレッシュにより、イベントログ上もKERNELBASE.DLLエラーが引き起こしていた一連の問題がシステムログに記録されることは無くなり、障害は解消されたことがわかる。

以上

2023年1月 4日 (水)

AFSKでの復調について

AFSKの復調について大変参考になる情報があったので、その要約も含めて備忘録。

 

復調における課題:

  • Low SNR
  • Hight Twist -  Mark信号とSpace信号の大きな振幅差
  • Phase distortion - Mark信号とSpace信号が符号境界に到達しない
  • Inter-Symbol interference - Mark信号とSpace信号がPhase Distortionにより重なる
  • Frequency Distortion - Tone周波数とData Rateとの大きな差
  • No error correction - 1ビットエラーで破棄

Hight Twist対策

Digital Correlator

Comb Filter(自らの遅延信号によりその信号自体を増幅する手法)の利用。

Comb

Delayを最適化することでMarkとSpaceのTone差を最大化することができる。
Zero Cross Detectorを使ってアナログ信号をデジタル変換し、同じDelayをComb Filterに適用する。

テストでの入力信号は以下。ジッターを発生させる低周波成分が含まれていてこのままではZero Cross Detectorにかけられない。
Wave1

1200Hz-2200Hzを通過させるBandpass Filterを通すと、低周波成分が除去できる、
Wave2

Bandpass Filterを通した波形をZero Cross Detectorにかける。

Wave3

Digital Comb Filterを適用する。Digital Comb Filterでは以下を実行する。

  1. Zero Cross Detector出力をDelayさせた信号とXORを取る
  2. 得られた信号に対してLow Pass Filterをかける。
  3. 得られた波形に対してZero Cross Detectorをかける。

XORを取った信号波形

Wave4

Cutoff 760HzでLowpass Filterをとおした波形

Wave5

Lowpass Filterを通した波形に対してZero Cross Detectorをかける。

Wave6

Clock Recovery

送信信号に対して、受信側のクロックを同期させる必要がある。そうしないと上記Bit Periodが得られない。

この為にTX Dlayがある。TX Delayで送られる信号でこのClock同期をとる。よってTX Delayはそれなりの長さが必要となる。

この過程においてCarrierシグナルからビット周期(パルス幅)を測定する。

Wave7

クロック同期をとるためにDigital PLLをつかう。Digital PLLはジッター量を計り、そのジッター量により、Data Carrierに同期しているかを判断する。

ここでは、シンボル周期をサンプリング数22で測定している。この範囲で上記矩形幅によってPLLを遅らせたり、進めたりする。

ロック状態と判断するには、ジッター幅が1.1サンプル以内になった時、アンロックと判断するのはジッター量が4.4サンプル以上となった時。

2023年1月 2日 (月)

APRSでのNRZIについて備忘録

APRSでのNRZI方式について備忘録

APRSはHDLCフレームをAX.25で転送するとの理解で考えると、APRSのTNCはNRZ-SpaceでEncode/Decodeしていると解釈される。

NRZ-Spaceはレベル遷移をゼロで行う。一般的なNRZIは1でレベル遷移実行となっているからここが大きな違いだ。

これについてはWikiwandに書かれている。以下がNRZ-Space部分の抜粋。

Non-return-to-zero space

Non-return-to-zero space
Encoder for NRZS, toggle on zero

"One" is represented by no change in physical level, while "zero" is represented by a change in physical level. In clock language, the level transitions on the trailing clock edge of the previous bit to represent a "zero".

This "change-on-zero" is used by High-Level Data Link Control and USB. They both avoid long periods of no transitions (even when the data contains long sequences of 1 bits) by using zero-bit insertion. HDLC transmitters insert a 0 bit after 5 contiguous 1 bits (except when transmitting the frame delimiter "01111110"). USB transmitters insert a 0 bit after 6 consecutive 1 bits. The receiver at the far end uses every transition — both from 0 bits in the data and these extra non-data 0 bits — to maintain clock synchronization. The receiver otherwise ignores these non-data 0 bits.

更に重要なのは赤字部分。1が5つ続いたら0を挿入すること。これを知らないとデコードが出来ない。

2022年12月31日 (土)

pico_tnc 2200Hz(Space)でPhaseをずらす件の備忘録

GitHubからダウンロードしたpico_tncのsend.cのsend_byte()についての考察記録

なぜ、mark_tabのサイズは121なのか,、そしてspace_tabのサイズは96なのか。

wave_table.h
#define PHASE_CYCLE 6
#define MARK_TAB_LEN 121 // 66 * 5/6 + 66
#define SPACE_TAB_LEN 96 // 36 * 5/6 + 66
mark_tab[MARK_TAB_LEN]={.....  1200Hz正弦波
space_tab[SPACE_TAB_LEN]={....     2200Hz正弦波
phase_tabは、spaceは6サンプリング周期ごと、markは11サンプリングごとに区切られ、6区画で1波形となる。
つまり、1波形を6等分したもの=60度分。
1200baudでは66サンプリングで1サイクル=360度となる。
static const uint32_t *phase_tab[2][PHASE_CYCLE] = {
{ &space_tab[0], &space_tab[6], &space_tab[12], &space_tab[18], &space_tab[24], &space_tab[30], },
{ &mark_tab[0], &mark_tab[11], &mark_tab[22], &mark_tab[33], &mark_tab[44], &mark_tab[55], },
};
phase_tabには1波形分のサンプリングを6等分(60度分)した数の波形データが入れられており、最終エントリーの先頭から66サンプリング分(360度=1DMA分)が設定されている。つまり、どのエントリーからDMAを始めても1DMA分のデータは揃っていることになる。
send.c
dma_handler()
....
データの1bit単位で波形を1サイクル分設定する
phase_tabから取り出すポインターから66サンプリング分(360度分)がdma_blockに格納される。
   tp->dma_blocks[next][idx++] = phase_tab[level][phase]; // 0: space, 1:mark
仮にlevel=1, phase=5の場合、phase_tab[1][5], つまり mark_tab[55](300度)から66サンプリング(6phase分=360度分)が取り出されることになる。
したがってサンプリングテーブル(mark_tab)はその長さ分(66x5/6=300度)が1波形分(66=360度)よりも余分に必要となる(合計 66x5/6 + 66=121)。
level=0, つまりspaceだったら次回の生成波形は60度(6サンプリング分)波形を前にずらす。
   if (!level) { // need adjust phase if space (2200Hz)
      if (--phase < 0) phase = PHASE_CYCLE - 1;
   }
減算する前のphaseが0、つまり先頭だったら最後尾にする。
なぜspace (2200Hz)だと1波形ごとに6サンプリング分前にずらすのか。
1200Hzで1サイクルが完結する時間スロットでは2200Hzでは2200/1200=11/6サイクル発生することになる。
つまり、サイクル完結に1/6(60度)足りない。仮にこの時間スロットの開始点で2200Nz波形を連続して生成する場合、その波形は前回の開始点波形にたいして1/6サイクル分(60度)後戻りした時点の波形から始まらないと連続性が保てない。
1200Hz波形は2200Hz波形を11/6倍だけ時間方向に引き伸ばしたものと考えることができる。よって2200Hzの後に1200Hz波形を同じタイムスロットで連続性を保って生成するには11サンプル分(60度)後戻りした時点の波形から始めると波形の連続性が保てることになる。
この様子を図示すると以下となる。Markが1サイクルする時間間隔ではSpaceは出力ゼロになるまで60度足りない。次の波形を連続させるには次の波形を―60度ポイントから波形生成を始める必要があるわけだ。
Photo_20221231131001
そもそも、1200Hzと2200Hzでのビット表現となるとどうしても波形は不連続になるが、その事は問題なのだろうか。
この波形不連続は、1200Hzと2200Hz以外の非常に多くの周波数成分を発生してしまうようだ。このノイズ成分により、信号復調率が落ちるのだろう(多分)。

2022年12月29日 (木)

PICOのPIOを使った指定周期DMAによるシリアラル信号出力プログラムについて

PICOのPIOを使ったPWM信号出力をDMAで動作させる方法について備忘録

注:PIOを使ったPICOのPWM機能をDMAで動作させる方法はいまいちわからなかった。(というか、PIOのTX FIFOにデータを送った場合、PIOはGPIOピンに0/1信号しか出せず、PWMレジスターに値を書き込めない。そもそもDMAには自己完結型のDREQインターバル設定ができるので、DMAでPWMレジスターに値を書き込むだけなら、PIOは特に必要ないかも。。。)

ここではPIOに32ビットデータを1ビットずつ設定した周期でGPIO出力させることでPWM信号を作る方法について備忘録する。

  • DMAはDREQによってDMA転送を1データ単位(32ビット)ごとに実行する。
  • DMAは自らのDMAインターバルによってDREQを自動発生することもできる。
    • channel_config_set_dreq(&pwm_dma_chan_config, DREQ_PWM_WRAP0 + led_pwm_slice_num)
  • DMA ch構成では、転送ソースアドレス、転送ターゲットアドレス、転送カウントを設定する。
    • dma_channel_configure(
        dma_chan,     // DMAチャネル
        &dma_chan_config,    // DMAチャネル構成情報
        &pio0_hw->txf[state_machine_id],  // PIOのTX FIFO
        // &pwm_hw->slice[led_pwm_slice_num].cc, // PWMレジスタの場合
        data_table,      // データ元
          256,                              // 転送カウント
        false                             // スタートタイミング(即時スタートの場合はtrue)
      );
  • DMAは設定した転送カウント分の転送が完了するとIRQを発生する。
  • このIRQを使って次回DMA転送するデータを設定する。

 

  • PIOはTX FIFOの1データ単位(32ビット)を取り出す。
  • 32ビットを1ビット取り出すにはshiftを使う
    • channel_config_set_transfer_data_size(&dma_chan_config, DMA_SIZE_32);
      新しくTX FIFOからデータを取り出すまで1ビットずつシフトし1ビットずつとりだす動作を32ビット行う
  • PIOのTX FIFOが空になるとDREQを発生させる。
    • channel_config_set_dreq(&pwm_dma_chan_config, DREQ_PIO0_TX0);
    • 上記と以下は等価
      channel_config_set_dreq(&pwm_dma_chan_config, pio_get_dreq(pio, state_machine_id, true));
  • 対象とするDMA chにこのDREQを紐付けることでTX FIFOが空になるごとにDMAを行うようにする

======= Program 1 DMAだけ、IRQなし =======

Main C Program

#include <stdio.h>
#include "pico/stdlib.h"
#include "hardware/dma.h"
#include "hardware/pio.h"
#include "hardware/clocks.h"
#include <hello.pio.h>

int main()
{
   PIO pio = pio0;
   uint state_machine_id = 0;
   uint offset = pio_add_program(pio, &pio_dac_program);
   pio_dac_program_init(pio, state_machine_id, offset, PICO_DEFAULT_LED_PIN, 2000.f);

   int pwm_dma_chan = dma_claim_unused_channel(true);

   dma_channel_config dma_chan_config = dma_channel_get_default_config(pwm_dma_chan);

   channel_config_set_transfer_data_size(&dma_chan_config, DMA_SIZE_32);
   channel_config_set_read_increment(&dma_chan_config, true);
   channel_config_set_write_increment(&dma_chan_config, false);
   channel_config_set_dreq(&dma_chan_config, pio_get_dreq(pio, state_machine_id, true)); // pio sm, TX

   dma_channel_configure(
      dma_chan,
      &dma_chan_config,
      &pio0_hw->txf[state_machine_id],
      data_table, 
      256, 
      false 
   );

   dma_channel_set_read_addr(dma_chan, mark_tab, true);   // DMAをスタートする

   while(true) {
      tight_loop_contents(); 
   }
}

PIO Program

.program pio_dac

.wrap_target
   out pins, 1
.wrap

% c-sdk {

static inline void pio_dac_program_init(PIO pio, uint sm, uint offset, uint pin, float fs) {
   pio_sm_config c = pio_dac_program_get_default_config(offset);

   sm_config_set_out_shift(&c, true, true, 32);
   sm_config_set_out_pins(&c, pin, 1);
   // sm_config_set_fifo_join(&c, PIO_FIFO_JOIN_TX); これはなくても動作は同じ
   sm_config_set_clkdiv(&c, (float)clock_get_hz(clk_sys) / fs);

   pio_gpio_init(pio, pin);

   pio_sm_set_consecutive_pindirs(pio, sm, pin, 1, true);
   pio_sm_init(pio, sm, offset, &c);
   pio_sm_set_enabled(pio, sm, true);
}
%}

======= Program 2  DMAとIRQの両方 =======

Main C Program

int dma_chan;
static bool mark_signal=true;
// DMA転送完了(指定データ数の転送完了)のIREQの度に送出するシグナルを交互に変える。
void dma_handler() {
//  指定されたデータテーブルのDMA転送を即時実行する。なのでDREQを待つことなしにDMAが開始される。
   if(mark_signal){
      dma_channel_set_read_addr(dma_chan, mark_tab, true);  // mark_tabの転送を即時実行
      mark_signal = false;
   }else{
      dma_channel_set_read_addr(dma_chan, space_tab, true);  // space_tabの転送を即時実行 
      mark_signal = true;
   }
   // IRQをクリア
   dma_hw->ints0 = 1u << dma_chan;
}

int main()
{
   PIO pio = pio0;
   uint state_machine_id = 0;
   uint offset = pio_add_program(pio, &pio_dac_program);
   pio_dac_program_init(pio, state_machine_id, offset, PICO_DEFAULT_LED_PIN, 2000.f);
   dma_chan = dma_claim_unused_channel(true);

   dma_channel_config dma_chan_config = dma_channel_get_default_config(dma_chan);

   channel_config_set_transfer_data_size(&dma_chan_config, DMA_SIZE_32);
   channel_config_set_read_increment(&dma_chan_config, true);
   channel_config_set_write_increment(&dma_chan_config, false);

   channel_config_set_dreq(&dma_chan_config, pio_get_dreq(pio, state_machine_id, true)); // pio sm, TX

   // Setup the channel and set it going
   dma_channel_configure(
      dma_chan,
      &dma_chan_config,
      &pio0_hw->txf[state_machine_id],
      mark_tab,    // 初期データテーブル
      66,                       // 転送データ(ワード)数
      false                     // トリガーされるまで待機
   );

   dma_channel_set_irq0_enabled(dma_chan, true);
   irq_set_exclusive_handler(DMA_IRQ_0, dma_handler);  // IRQハンドラーとしてdma_handlerを設定
   irq_set_enabled(DMA_IRQ_0, true);

   dma_handler(); // DMAを即時実行。DMA開始後はPIOが発生するDREQのペースでDMA転送される
   // 上記実行以降はDREQとIREQによってPIOの実行ペースでデータ転送が実行される。
   //  そのおかげでメインプログラムはデータ転送を気にすることなく他のタスクが実行可能となる
   while(true) {
      tight_loop_contents(); 
   }
}
SDKドキュメント。dma_channel_set_read_addr()の第三パラメータは即時実行指定。

◆ dma_channel_set_read_addr()




static void dma_channel_set_read_addr ( uint  channel,
    const volatile void *  read_addr,
    bool  trigger 
  )    
inlinestatic

Set the DMA initial read address.

Parameters
channel DMA channel
read_addr Initial read address of transfer.
trigger True to start the transfer immediately
ビルド環境
親DIR
   + led_fade (ソースコードDIR)
   + build (ビルドDIR)
親DIRのCMakeLists.txt

cmake_minimum_required(VERSION 3.16)    //使っている環境が3.16だからとりあえず3.16に設定

include($ENV{PICO_SDK_PATH}/external/pico_sdk_import.cmake)
project(led_fade C CXX ASM)
set(CMAKE_C_STANDARD 11)
set(CMAKE_CXX_STANDARD 17)
pico_sdk_init()
add_subdirectory(led_fade)

ソースコードDIRのCMakeLists.txt

add_executable(led_fade
   led_fade.c
)

pico_generate_pio_header(led_fade ${CMAKE_CURRENT_LIST_DIR}/hello.pio)

target_link_libraries(led_fade
   pico_stdlib
   hardware_pio
   hardware_dma
)

pico_add_extra_outputs(led_fade)

 

======= Program 3 文字列を波形出力する =======

送出する文字列に沿って波形を出してみたくなったので、その実験コードを書いてみた。
uint8_t xfer_data[] = "HIJKLMNO"; // 波形送出する文字列
int xfer_length;
const uint32_t *dma_signal[80];  // up to 10 data
int dma_signal_count, dma_count;

void dma_handler()
{
   if (dma_count >= dma_signal_count) // no more data to DMA
      dma_count = 0;              // repeater forever
   // DMAする順にWaveform Tableのポインターを取り出しDMAをキックする。
   dma_channel_set_read_addr(dma_chan, dma_signal[dma_count], true);

   // Clear the interrupt request.
   dma_hw->ints0 = 1u << dma_chan;

   dma_count++; // prepare for next DMA transfer
}
送り出すビットが1か0によって、DMA単位ごとのwaveform(1200Hz/2200Hz)を設定する
void data_set()
{  
   int i, j, k = 0;
   uint8_t dma_data;

   xfer_length = strlen(xfer_data);
   for (i = 0; i < xfer_length; i++){
      dma_data = xfer_data[i];   // 送出するCharactorを取り出す
      for (j = 0; j < 8; j++)    {      // LSBから順にWaveformを割り当てる
         if ((dma_data >> j) & 1)  //  BitごとにWaveform Tableポインターを設定する
            dma_signal[k] = mark_tab;  
         else
            dma_signal[k] = space_tab;
         k++;
      }
   }
   dma_signal_count = k;
   dma_count = 0;   
}
main()の中で、dma_handler()を呼ぶ前(DMAをキックする前)にdata_set()をコールする。
   data_set(); // set wave table to DMA
   dma_handler(); // trigger DMA

 

2022年12月28日 (水)

PICOのPWMをDMAで動作させる方法

Raspberry Pi PICOのPWMをDMAで動作させる方法について備忘録。
以下、動作検証を行ったサンプルプログラム。
#include <stdio.h>
#include "pico/stdlib.h"
#include "hardware/dma.h"
#include "hardware/pwm.h"
#include "hardware/clocks.h"
int main()
{
// オンボードLEDがつながっているPINをPWMに設定する
   gpio_set_function(PICO_DEFAULT_LED_PIN, GPIO_FUNC_PWM);

//  このPINのSlice番号を得る
   int led_pwm_slice_num = pwm_gpio_to_slice_num(PICO_DEFAULT_LED_PIN);
//  PWM構成情報を作成する
   pwm_config config = pwm_get_default_config();
//  PWM構成情報にデータ要求周期のクロック分割を設定する。
//  ここではLED点灯変化が目視できるようにクロック数を1/800に設定している。
//  なお、800.fのfはfloatを表している。
   pwm_config_set_clkdiv(&config, 800.f);
//  このPWM構成情報でPWMを初期化する
   pwm_init(led_pwm_slice_num, &config, true);

//   PWM用に、空いているDMAチャンネル番号を取得する
   int pwm_dma_chan = dma_claim_unused_channel(true);
//  取得したDMAチャンネルの構成情報を取得する
   dma_channel_config pwm_dma_chan_config = dma_channel_get_default_config(pwm_dma_chan);
//  DMA転送単位を32ビットに設定する
   channel_config_set_transfer_data_size(&pwm_dma_chan_config, DMA_SIZE_32);
//  DMA読み出し元(データテーブル)アドレスを自動インクリメント設定する
   channel_config_set_read_increment(&pwm_dma_chan_config, true);

//  DMA書き込み先(PWMレジスタ)アドレスは固定にする
   channel_config_set_write_increment(&pwm_dma_chan_config, false);
//  PWM(取得したスライス番号)のデータ要求によってDMA REQが発生するよう指定する
   channel_config_set_dreq(&pwm_dma_chan_config, DREQ_PWM_WRAP0 + led_pwm_slice_num);

//  DMAチャンネル構成情報を設定する
   dma_channel_configure(
      pwm_dma_chan,
      &pwm_dma_chan_config,
      &pwm_hw->slice[led_pwm_slice_num].cc, // 書き込み先PWM counter compare
      data_table,               // 読み出し元
      256,                                                              // データテーブルからの読み出しデータ数、これを読みだしたらDMA停止
      true                   // DMA即時開始
   );

   while(true) {
      tight_loop_contents();
   }
}
上記のコードはPWMの実行周期を設定し、その周期でDMA REQを発生させることで、data_tableからPWMレジスタにデータをDMA転送させている。
なお、data_tableはuint32_t data_table[256]で、0x00000000から0xFFFFFFFFまでの値でLED輝度変化が目視できるテーブルにする。

検証にあたってはこのブログを参考にした。

2022年12月27日 (火)

PICOのPIOについて

Raspberry Pi PicoのPIOについて調べてみたので備忘録。

Raspberry Pi Picoはメインプログラムとは別にアセンブラレベルコードを実行することができる。これはメインプログラムとは別に(並行して)動作するプログラムのようだ。基本アセンブラレベルのコードを書くことになる。これはかなり強力な機能で、メインプログラムでタイミングを意識することなく、決まったサイクルでオペレーションを実行できることになる。

その1からその2まで記録。。。

その1ーーー

開発手順

ここではオンボードLEDを点滅するPIOを書いてみる。

  1. hello.pioを書く。この中にアセンブラレベルのコードを書く。このhello.pioはCヘッダーファイルに変換され、Cプログラムから参照される。
  2. Cプログラムを書く。
  3. buildする。

hello.pioディレクトリに以下を配置
   + CMakeLists.txt
   + hello-pio 
          + hello.pio
          + hello-pio.c
          + CMakeLists.txt
   + build

buildディレクトリにて以下を実行してbuildする。
$ cmake ..
$ make

以下、実際に書いたコード。

参考になった情報1情報2。ただし、情報1の通りコードを書いてもLEDはブリンクしない(サイクルが短すぎて点灯しっぱなしに見える)。

hello.pio

.program hello
loop:
;.wrap_target 
   set pins, 1 [19] ; Turn LED on and wait another 19 cycles
   nop [19] ; Wait 20 cycles
   nop [19] ; Wait 20 cycles
   nop [19] ; Wait 20 cycles
   nop [19] ; Wait 20 cycles
   set pins, 0 [19] ; Turn LED off and wait another 19 cycles
   nop [19] ; Wait 20 cycles
   nop [19] ; Wait 20 cycles
   nop [19] ; Wait 20 cycles
   nop [19] ; Wait 20 cycles
;.wrap
jmp loop

//  上記loopのwrapも同じ結果になる

% c-sdk {
static inline void hello_program_init(PIO pio, uint sm, uint offset, uint pin) {
   //  Configオブジェクトを定義する 
   pio_sm_config config = hello_program_get_default_config(offset);
   //    Configオブジェクトにgpioピンpinを割り当てる
   pio_gpio_init(pio, pin);
   sm_config_set_set_pins(&config, pin, 1);  //  pinから1ピンを連続割当、ここでは1ピンのみの割当。
   //  pinから1ピンを出力に設定。ここでは1ピンのみを設定。
   pio_sm_set_consecutive_pindirs(pio, sm, pin, 1, true);

   // クロック分割数を決める。divの分だけsysclkがマスクされる。これをやらないとLED ON/OFFが早すぎてLED点灯しっぱなしに見える。
   static const float pio_freq = 2000;
   float div = (float)clock_get_hz(clk_sys) / pio_freq;
   sm_config_set_clkdiv(&config, div);

   // 初期化とイネーブ
   pio_sm_init(pio, sm, offset, &config);
   pio_sm_set_enabled(pio, sm, true);
}
%}

hello-pio.c

#include <stdio.h>
#include <stdbool.h>
#include <pico/stdlib.h>
#include <hardware/pio.h>
#include "hardware/clocks.h"  //  hello.pioでclk_sysを参照しているので必要
#include <hello.pio.h>     // hello.pioから生成されるヘッダーファイルをincludeする

#define LED_BUILTIN 25     // オンボードLEDのGPIO

int main() {

   stdio_init_all();

   PIO pio = pio0;
   uint state_machine_id = 0;
   // hello.pioで定義したhelloはhello_programと自動的に命名される。
   uint offset = pio_add_program(pio, &hello_program);
   hello_program_init(pio, state_machine_id, offset, LED_BUILTIN);
   while(1) {
      // Cプログラムで何かをやっていたとしても、これとは並行してpioが動作している
   }
}

CMakeLists.txt(hello.pioディレクトリ)

cmake_minimum_required(VERSION 3.12)

include(pico_sdk_import.cmake)

#project(pico_examples C CXX ASM)
project(hello-pio C CXX ASM)
set(CMAKE_C_STANDARD 11)
set(CMAKE_CXX_STANDARD 17)

pico_sdk_init()

add_subdirectory(hello-pio)

CMakeLists.txt(hello-pioディレクトリ) 

add_executable(hello-pio
   hello-pio.c
)
#  CMAKE_CURRENT_LIST_DIRはCMAKEによって自動設定される

pico_generate_pio_header(hello-pio ${CMAKE_CURRENT_LIST_DIR}/hello.pio)

target_link_libraries(hello-pio
   pico_stdlib
   hardware_pio
)
# hexファイルやuf2ファイルを生成する
pico_add_extra_outputs(hello-pio)

hello.pio.h

CMakeLists.txtのpico_generate_pio_header()によって以下のヘッダーファイルが生成される。

// -------------------------------------------------- //
// This file is autogenerated by pioasm; do not edit! //
// -------------------------------------------------- //

#pragma once

#if !PICO_NO_HARDWARE
#include "hardware/pio.h"
#endif

// ----- //
// hello //
// ----- //

#define hello_wrap_target 0
#define hello_wrap 10

static const uint16_t hello_program_instructions[] = {
// .wrap_target
   0xf301, // 0: set pins, 1 [19]
   0xb342, // 1: nop [19]
   0xb342, // 2: nop [19]
   0xb342, // 3: nop [19]
   0xb342, // 4: nop [19]
   0xf300, // 5: set pins, 0 [19]
   0xb342, // 6: nop [19]
   0xb342, // 7: nop [19]
   0xb342, // 8: nop [19]
   0xb342, // 9: nop [19]
   0x0000, // 10: jmp 0
// .wrap
};

#if !PICO_NO_HARDWARE
static const struct pio_program hello_program = {
   .instructions = hello_program_instructions,
   .length = 11,
   .origin = -1,
};

static inline pio_sm_config hello_program_get_default_config(uint offset) {
   pio_sm_config c = pio_get_default_sm_config();
   sm_config_set_wrap(&c, offset + hello_wrap_target, offset + hello_wrap);
   return c;
}

static inline void hello_program_init(PIO pio, uint sm, uint offset, uint pin) {

   pio_sm_config config = hello_program_get_default_config(offset);

   pio_gpio_init(pio, pin);
   sm_config_set_set_pins(&config, pin, 1);
   pio_sm_set_consecutive_pindirs(pio, sm, pin, 1, true);

   static const float pio_freq = 2000;
   float div = (float)clock_get_hz(clk_sys) / pio_freq;
   sm_config_set_clkdiv(&config, div);

   pio_sm_init(pio, sm, offset, &config);
   pio_sm_set_enabled(pio, sm, true);
}

#endif

その2ーーー

sm_config_set_out_shiftについて

.program hello

.wrap_target
   out pins, 1   ;  結果的に1ワード分のデータを右シフトで1ビットずつ出力される。
.wrap

% c-sdk {

static inline void hello1_program_init(PIO pio, uint sm, uint offset, uint pin, float fs) {
   pio_sm_config c = pio_dac_program_get_default_config(offset);

//  TX FIFOからデータをpullするまでのビットシフト実行指定、右向きに32ビットまでシフトする。
//  つまり32ビット全部をpinに順次送り出し、全て送り出したらTX FIFOから自動で新しいデータをpullする。
   sm_config_set_out_shift(&c, true, true, 32);

//  pinから1ピンをoutに設定する
   sm_config_set_out_pins(&c, pin, 1);

//  クロックマスク周期を設定する(動作速度を調整する)
   sm_config_set_clkdiv(&c, (float)clock_get_hz(clk_sys) / fs);

SDKドキュメントは以下のとおり。

◆ sm_config_set_out_shift()

static void sm_config_set_out_shift ( pio_sm_config  c,
    bool  shift_right,
    bool  autopull,
    uint  pull_threshold 
  )    
inlinestatic

Setup 'out' shifting parameters in a state machine configuration.

Parameters
c Pointer to the configuration structure to modify
shift_right true to shift OSR to right, false to shift OSR to left
autopull whether autopull is enabled
pull_threshold threshold in bits to shift out before auto/conditional re-pulling of the OSR

2022年12月19日 (月)

Google Driveへのパソコンフォルダーの同期方法

Google DriveにPC上の同期対象フォルダーの指定にちと手間取ったので備忘録。

スタートメニューにあるGoogle Driveを右クリックして、その他 -> 管理者として実行 を選択する。

Googledrive

するとGoogle Drive設定ダイヤログが表示されるので、そこでPC上の同期対象フォルダーを選べばよい。

 

2022年12月17日 (土)

PICO TNCno製作 その3

KENWOODハンディトランシーバー対応。トランシーバーはTH-K20、ちょっと(かなり)古い。

KENWOOD対応のヘッドセットのケーブル・ジャックを活用しようとして驚いた。ケーブルを切ったのはこのヘッドセット。
Img03220_small

まぁ、幾分細いワイヤーがはいっているんだろうと思ったら、、、なんと超極細エナメル線を編んだワイヤーが4本入っていた。これはどうしたものやら。とりあえずカッターナイフで極細エナメル線の被覆を削り落としてクリップを付けて配線を確認した。
Img03218_small

3芯ケーブルに半田付けし、熱収縮チューブでカバーした。
Img03222_small

KENWOOD ハンディのスピーカーマイク配線は以下のとおり。
Kenwoodpinlayout

つまりMICラインとPTTラインは分けないといけない。ここがYaesuと違う所。そこで、ビーコン発生機のジャック端子の真ん中(Ring)にPTT信号を割り当てる改造を実施。

35mmjack

この結果、ハンディのスピーカーマイク端子とビーコン発生機に差し込むジャックとの配線は以下のようになった。マイク信号線はマイク端子(Tip)へ、MIC/PTT共通信号線はPTT端子(Ring)へ、PTT/GND信号線はGND端子(Sleeve)へ接続した。
Kenwood

これでとりあえず動くようになった。

Img03228_small
しかし、トランシーバーから電波を出すとPicoが誤動作し、PTTが切れない。つまり電波が出っぱなしになる。この状態で今回作ったケーブルを手で覆い隠すと誤動作(PTTオン)が止まる。つまり、トランシーバーからの電波に対してビーコン発生機をシールドする必要がある。

Picoが誤動作している可能性があると思い、ケーブルのビーコン発生機ジャック根元部分にコアを入れてみたが効果なし。
Img03229_small

今度はトランシーバー側にコアを入れてみた。こちらは効果があり、安定的に動作するようになった。ちなみにコアはFT-114-43、バラン用に購入してあったもの。
Img03230_small

以上でKENWOOD Handy対応も目処がたった。

追加のノイズ対策

今回の誤動作はPTTがオンになりっ放しになるというもの。スピーカーマイクケーブルのトランシーバー側にコアを入れて改善したことから、このケーブルを介してノイズがビーコン発生機に入ってきていることが想像できる。そして、ビーコン発生機のPTT信号出力トランジスターを誤動作させているということだろうか。であれば、トランジスター自体にノイズ対策を施すことは効果がありそうだ。

それで以下の対策を施した。
Emitterreg
Q1のベース・エミッター間にR3 10KΩ抵抗を入れた。この抵抗がない状態ではベースに入ってきたノイズ電流によってQ1が誤動作する場合が有り得るが、そのノイズ電流をGNDに流す役割をするのがR3になる。仮に0.01mAのノイズ電流がベースに入ってきたしても、10KΩに流れたとして電圧は0.1Vとなりベース・エミッター間飽和電圧(大体0.8V)よりも十分小さいのでQ1を動作させることはないがノイズ電流はGNDに流すことができる。

試しにコアを取り外してみたが、やっぱりコアが無いとPTTがオンになったままになる。ということで、上記R3の追加は決定的な対策にはならないことが判明。

2022年12月12日 (月)

PICO TNCの製作 その2

PICO TNC製作の続編その2。

プロトタイプが完成した。
Img03140_small

事前設定したインターバルで、ハンディ―トランシーバーのマイク端子経由にてMic-EフォーマットでGPSデータを送信することができるようになった。

PICO TNC コマンドの使い方

  • mycall JA0WBT または JA0WBT-7  :  SSID有無どちらでもよい。mycallを設定しないとBeaconは出ない。
  • unproto JA0WBT V WIDE1-1   :  Vの前はDestination Addressだが、ソフトウエア内部でMic-E形式のDestinationに上書きするようにした。なのでどんな文字列でも構わない。Vの後はデジパス1でNewパラダイムに従ってWIDE1-1を指定する。
  • digi ON  : デジパスを指定しているのでONを指定する。
  • gps $GNGGA   : プロトタイプに接続しているGPSモジュールのGGAフォーマットは$GNGGAと頭に付けてくるのでそれを指定する。これ以外のフォーマットタイプは今はサポートしていない。
  • btext HelloWorld  : BeaconのInformationに付加する自由テキスト。
  • beacon every n  : Beacon発生インターバル。n=1で1/6秒。最大360=60分。
  • PERM  : パラメータを設定したら実行。これにより設定したパラメータ値がFlashメモリーに保存され、パワーサイクルでも消えない。

以下がdispコマンド実行結果。MYALIASは設定しなくてもよい。

disp

ECHO ON
TXDELAY 100
GPS $GNGGA
TRace OFF
MONitor ALL
DIGIpeater ON
BEACON On EVERY 6
UNPROTO SUTPW8 V WIDE1-1
MYCALL JA0WBT-7
MYALIAS JA0WBT
BTEXT HelloWorld

OK
cmd:

送信されるパケットデータ

PICOの出力(トランシーバーのマイク入力)を入力(トランシーバーのスピーカ出力)にループさせてPICO TNCにて自分の出力を自分でデコードさせた。さらに実際にトランシーバー(FT-70D)のマイク入力に接続し、電波送信してI-Gateにて受信した。その受信した結果が以下:

17:43:53R JA0WBT-7>SUTPW8,WIDE1-1 Port=1 <UI C Len=24>:
`AB'l l[/`"9L}HelloWorld
17:43:53R JA0WBT-7>SUTPW8,WIDE1-1 Port=2 <UI C Len=24>:
`AB'l l[/`"9L}HelloWorld
17:43:55R JA0WBT-7>SUTPW8,WIDE1-1* Port=1 <UI C Len=24>:
`AB'l l[/`"9L}HelloWorld
17:43:55R JA0WBT-7>SUTPW8,WIDE1-1* Port=2 <UI C Len=24>:
`AB'l l[/`"9L}HelloWorld

I-Gateは2ポート設定しているので(1ポートにする方法がわからん)、同じ電波信号をPort1とPort2で2回取り込んでいる。最初のペアがPICO TNCが生成したフレームで、次のペアがPICO TNC内でループバックして再送信した信号になる。ループバックした信号はデジピートしたことになるのでWIDE1-1の後ろに*が付加されている。

Digipeaterとしての機能

Digipeaterとしの機能を確認する。FT3Dからビーコンを送信し、それをFT-70Dで受信。FT-70DのSpeakerをPICO TNCの入力に接続し、MicをPICO TNCの出力に接続した。

Img03160_hdr_small

Beaconrepeat

結果は、FT3Dからのビーコン(上図①)はFT-70Dでビーコン再送(上図④)された。そのビーコンはFT3Dで受信することができた(以下写真)。一方、UI-VIEW32はFT3Dからのビーコン(上図①)は受信表示したが、FT-70Dからのビーコン再送(上図④)は受信表示されなかった。
Img03161_small

考察として、UI-VIEW32はオリジナル信号を受信した後に、そのデジピート信号を受信した場合、それは受信表示しないのではないかと思われる。もしそれを許したら、同じ信号をデジピートの分だけ何度もI-Gateしてしまうから。一方、FT3Dは自分が発信した信号のデジピートであっても自分以外の送信機からの信号なのでそのまま表示したのだと思う。

UI-VIEW32のTerminalで確認したところ、上記の通りと判断できる。以下がTerminalの表示内容。3つ目のWIDE1-1に*が付いているのでデジピートされた信号と判断される。デジピートしたのはPico TNCになるので、Pico TNCはちゃんとデジピートしているのだけれど、それをUI-VIEW32がInternetには送り出さなかったということだ。

19:34:21R JA0WBT-7>SUTPW7,WIDE1-1 Port=1 <UI R Len=17>:
`AB(l!m[/`"9l}_0
19:34:21R JA0WBT-7>SUTPW7,WIDE1-1 Port=2 <UI R Len=17>:
`AB(l!m[/`"9l}_0
19:34:22R JA0WBT-7>SUTPW7,WIDE1-1* Port=2 <UI R Len=17>:
`AB(l!m[/`"9l}_0

 

乾電池駆動について

この実験に際して、PICO TNCを単四乾電池2本で駆動した。5分インターバルで一晩ビーコンを出し、朝停波。その状態で実験を続けていたところ午後3時ころには電池がなくなった(Watchdog Timer Failure発生)。結構電力を消費している。

基板への実装とケースへの取り付け

ブレッドボードに作った回路を

Img03170_small

この回路をユニバーサル基板に配置する。

Img03163_hdr_small

実装が終わった状態。RS232CでPCでモニターする。
Img03175_small

乾電池(単三2本)での動作確認。
Img03171_small

ダイソーの3個100円のケースにいれる。RS232Cのボードもユニバーサル基板に実装した。
Img03228_small

完成した状態。
Img03187_small

この状態で持ち運んで軌跡確認を行った。
Img03210_small

実験結果はまずまず良好で、基本機能が動作することを確認できた。

DIAMOND GS-3000の修理の件

ヤフオク!で落としたDiamond GS-3000 13.8V MAX30A電源が届いた。

動作させたところ電圧は13.78V、しかし電流は4A程度で電流制限が働いで電源OFFになる。

Img03149_small

良くある故障モードとして可変抵抗器の劣化が考えられる。

GS-3000の故障に関する情報から、VR1が電流制限調整VRであることが判明した。

Img03152_small

VR1を拡大する。この写真では8時方向をむいているが、入手時点では12時方向を向いていた。
Img03152_smallzoom

とりあえず、VR1を何度か回してまずは、3時方向にセットし負荷を繋いでみた。4Aよりも小さな負荷で電流制限が発生。そこで8時方向まで回してみたところ、8Aの負荷でも電流制限は作動しなかった。30A負荷を与えることができればVR1の位置は追い込めるが、そのような負荷がないので、とりあえずこれで様子を見てみる。

考察:

この電源、カバーを外してみると結構きれいな感じだったが、基板の隅の方を見るとシルク印刷が隠れるほど埃がこびりついている。つまり、この電源の出品に当たって掃除をしたということだろうと思う。ひょっとしたらその際にVR1の位置が変わってしまったのかもしれない。いずれにせよVR1の調整だけで問題は解決したように見える。

考察のやり直し:

電流が出ないというか過電流保護が働いて出力電流制限されている理由が分かった。4つあるパワートランジスタの内3つのエミッターに繋がるワイヤーが断線していた。半田にクラックが入って取れたように見えた。VR1を変化させて制限電流値が増えたのは残っていた1つのパワートランジスターの最大電流(0.1Ω抵抗に流れる電流量)を増やしたため、ということのようだ。

断線していたワイヤー部分(黄丸)。
Img03192_small

エミッター端子の半田面が割れて剥がれたような半田断面にみえる。
Img031911
こちらも同様。
Img031912

本来は4個のパワートランジスターで出力しているところを1個のパワートランジスターで制御したため、過電流制御が働いてしまったようだ。エミッターへケーブルを半田付けしなおした(黄丸)。
Img03200_small

この結果、電流制御用のVRを元の位置に戻しても、問題なく動作するようになった。また、電流計は剥がれがケーブルの先に繋がっていたので当初は電流表示が出来なかったがケーブルを半田付けしなおすことで、電流計も動作するようになった。

考察

もうちょっとちゃんと構造を調べて見たくて、今一度理解を深めるためにJH7LUC局のブログなど先人の知恵を参考に自分で回路図を書いてみた。

Gs3000circuit

ダウンロード - gs3000.ce3

構成はダーリントン接続のトランジスターが3段になっていて、ツェナーダイオードで定電圧としている。リセットIC TA8505Pの入力にサーモスタットにかかる電圧を接続し、ある程度の抵抗値(温度)になったらリセットICがリセット信号を出力し、その信号によってファンモーターnの駆動制御を行っている。TA8505PはVCC=5Vを必要とするので三端子レギュレータTA78006PでVCCを作っている。過電圧(ツェナー電圧)となるとツェナー電流が流れリレーが働いてパワートランジスタへの入力をカットする。

定電圧の原理は以下の通りと理解した。Q2のエミッター電圧Veq2はZDのツェナー電圧Vzdで決まる。Q2のベース電圧は、ベース・エミッター間電圧をVbeq2とするとVzd+Vbeq2となる。この電圧はVout(R2/(R1+R2))であたえられるので、Vout=(Vzd+Vbeq2)((R1+R2)/R1)となるようにQ1が帰還制御される。

Photo_20221217143201

よくわからなかったのが過電流制御部分。ここは以下の通り解釈した。

Photo_20221217144001

VEQ5=VEQ3-R2xIOUT  : IOUTが大きくなるとR2による電圧降下が大きくなるのでVEQ5(Q5のエミッター電圧)は小さくなる。
VBQ5はVRの値によって変化する。
VBQ5-VEQ5>VBE となればQ5はONになる。つまりIOUTが大きくなるとQ5はONになる。その閾値はVRで変化する。

Q1のベース電圧からみると、Q3のエミッター電圧はQ1からQ3のベース・エミッター間電圧の合計分低いことになる。Q5がオンになるとその電圧差がなくなるので、Q1からQ3へのベース・エミッター間に電流が流れなくなる。

解釈が正しいかイマイチ不安な部分があるけれども、出力電流による0.1Ω抵抗の電圧降下とVR1の値のバランスでQ5がONされることには違いない。

2022年12月11日 (日)

トランシーバのマイクとPTTが一本の線にまとめられている件

FT-70DとかFT3Dとかのハンディトランシーバーではマイク端子とPTT端子が一つにまとめられている。

MICとPTTが一本の線にまとめられているってどういう事なんだろうってことで調べてみた。

Yaesu スピーカーマイクSSM-17Aのピンジャックの信号配列は以下のようになっているようだ。他の資料などを見るとSPとMIC/PTTの間の電極はDATA/Cloneとなっているが、このスピーカーマイクでは未使用だと思う。
Ssm17apin

MIC/PTTとGNDの間の抵抗値をテスターで測ってみた。PTTを押さない場合は絶縁状態、PTTを押すと633Ωとなった。
Img03143_burst01_small

いろいろな資料を見てみて、この仕組みを回路にまとめると以下のようだ。テスターで測定した633Ωは回路図のR01にあたる。つまり、PTTを押すとMICラインが633Ωで接地されるわけだ。トランシーバー側はこのMICラインがPNPトランジスタのベースに繋がっているようで、PTTが押されるとトランジスタがオンになる。これがトランシーバー内でSEND信号になるようだ。一方MICはコンデンサーCを介してAC成分だけがMIC信号として取り出される。ここでR01の抵抗値はトランシーバー内のR02との関係で適切な値に設定し、ベース電流が流れるようにしないといけない。実験ではR01が2KΩではPTTが効いたが、10KΩではPTTが効かなかった。
Micptt0

とりあえずR01はスピーカーマイクでの測定値に近い680Ω位に設定すれば安心なんだろうと思う。

スピーカーマイクの代わりにTNCを取り付けた場合、PTT信号を使って以下の回路を構成すればよい。この回路ではPTTオンがHIGHを前提としている。
Micptt2

実験の結果680Ωでこの回路でも動作を確認した。

2022年12月 5日 (月)

GPSトラックログデータをGoogle Mapに表示する

GPSトラックログファイル(GPXファイル)をGoogle Map上に表示する方法の備忘録。

GPSトラックログファイルはヤマレコの山行記録からダウンロードした。対象とする山行記録を選んでマップ昨日からGPXファイルをダウンロードを選ぶ。
Photo_20221205121401

ダウンロードされるGPXファイルはこんな感じになっている。

<?xml version="1.0" encoding="UTF-8"?>
<gpx xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/0" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd" creator="Yamareco Android 6.2.2 - www.yamareco.com">
<trk><name>track</name><number>1</number><trkseg>
<trkpt lat="35.5110116" lon="137.6645703"><ele>1040</ele><time>2022-11-17T23:46:07Z</time></trkpt>
<trkpt lat="35.5109365" lon="137.6644874"><ele>1041</ele><time>2022-11-17T23:46:17Z</time></trkpt>
<trkpt lat="35.5107415" lon="137.6643537"><ele>1045</ele><time>2022-11-17T23:46:30Z</time></trkpt>
<trkpt lat="35.5106972" lon="137.6642274"><ele>1048</ele><time>2022-11-17T23:47:24Z</time></trkpt>
<trkpt lat="35.5092595" lon="137.6552615"><ele>1284</ele><time>2022-11-18T00:28:01Z</time></trkpt>
<trkpt lat="35.509086" lon="137.6537141"><ele>1300</ele><time>2022-11-18T00:31:16Z</time></trkpt>

LatitudeとLongitudeがUTC付きで記録されている。

次にGoogle Mapを開き、自分のGoogleアカウントでログインする。その後メニューをだどって地図を作成を実行。
メニュー -> マイプレイス -> マイマップ -> 地図を作成

無題のレイヤのインポートを選択。
Gm1_20221205121401

ここにGPXファイルをドラッグ&ドロップする。
Gm2_20221205121401

すると、GPXファイルのエリアで軌跡が表示される。
Gm3

以上。

Yaesu FT3D APRSビーコン パケットデータの解析

FT3Dが送信しているAPRSパケットデータの解析をしたので、その記録。

以下がUI_VIEW32のTerminal出力に表示されたFT3DのAPRSビーコンデータ:

JA0WBT-7>SUTPW9,WIDE1-1 Port=1 <UI R Len=17>:`AB(l T[/`"9a}_0

FT3DはMic-E形式でAPRSパケットを送出している。FT3DのMic-EはDestination AddressとInformationにGPS座標情報(Latitude/Logitude)、高度情報(Altitude)、無線機形式(Radio Type code)で構成されている。

まずはDestination Address(以下の赤字部分)の分析から。ちなみにFT3DのGPS座標は北緯35度40.79分、東経137度38.12分。

JA0WBT-7>SUTPW9

Byte Latitude Msg A/B/C N/S Longitude offset E/W
S 3 A=1      
U 5 B=1      
T 4 C=1      
P 0   N    
W 7     +100  
9 9       E

SUTPW9は1バイト目からAPRSスペックの44ページに掲載される以下の表でデコードできる。1バイト目からこの表を見ながらその意味を解釈するとデータ並びのASCII Char順に以下となる。

  • S: Lat Digit Byte 1=3, Message A=1
  • U: Lat Digit Byte 2=5, Message B=1
  • T: Lat Digit Byte 3=4, Message C=1
  • P: Lat Digit Byte 4=0, N/S = North
  • W: Lat Digit Byte 5=7, Long Offset = +100
  • 9: Lat Digit Byte 6=9, W/E = East

Mice_destination_20221205081901

ちなみにMessage A/B/C = 111はスペックの45ページの表(以下)Off Duty(無線機の前に運用者は不在)という意味になる。

Msgtype
FT5DのマニュアルにあるMessageの解釈は以下の通り。

Micemessage

次にInformationに記載されたデータの解釈を行う。

`AB(l T[/`"9a}_0

結論を先に書くと、これは以下の3つのパート(青、赤、緑)で構成されている。

`AB(l T[/`"9a}_0

`AB(l T[/ : Logitude + Speed/Course + Symbol Code

Information Fieldのフォーマットはスペックの46ページに掲載されている。
Informationfield

この表に従ってデータを解釈する。

  • `  : Current GPS Data
  • A  : Ascii code=65, d+28 = 65 -> 137 (以下のMic-E Longitude Degree Encodingのd+28=65から値を引くが、先に解釈したDestination AddressのByte5でLong Offset=+100となっているので表の+100の欄の値を引く)。
  • B  : Ascii code=66, m+28 = 66 -> 38 (以下のMic-E Longitude Minutes Encodineのm+28=66から値を引く)
  • (  : Ascii code=40, h+28 =40  単純に40から28を引いた値がh。h=40-28=12
    以上よりLongitude=137度38.40分
  • l (small L) : Ascii code=108, SP+28=108 -> Speed Knot 0-9 (100の桁0、10の桁0、1の桁0~9
  • space  : Ascii code=32 , DC+28=32 -> Speed Knot 0 (1の桁0)、Couse 0-99 degree (100の桁0)
  • T  : Ascii code=84, SE+28=84 -> Couse 56 degree (10と1の桁)
    以上より、速度=0ノット、進路56度
  • [  : Symbol Lookup Table参照
  • /  : Symbol Lookup Table参照
    [/でRUNNERシンボル

LonitudedegreeLongitudeminutes

Speed and Course
Speedandcourse

SpeedencodingSpeedcourseencodingCourseencoding

 

`"9a} : Altitude

  • `  : Current GPS data
  • "  : Ascii code=34  34-33= 1       1*91*91=8,281
  • 9  : Ascii code=57  57-33=24          24*91=2,184
  • a  : Ascii code=97  97-33=64                   = 64        合計10,529   -> 海抜529m
  • }  : 終端記号

Altitudeは最も深い海の底(10,000メートル)からの標高で表現する。なので海抜に10,000メートルを加算する。この標高を基数91で表現する。例えば標高61メートルだと、10,061メートルとなるので、
   10,061 / (91*91) = 1  あまり1,780
          1,780 / 91 = 19, あまり51
つまり基数91表現で119あまり51となる。これに33を加算し3バイトで表現すると、Byte1=1+33=34、Byte2=19+33=42、Byte3=51+33=84となる。受信したビーコンはこの逆の方法で計算する。

_0 : Radio Type code

  • _0

Mic-E Type Codeによると_0はYaesu FT3Dのモデルコード。

 

Beacon Textについて

FT3DのBeacon ステータステキストにHello WorldをセットしてBeaconを送信してみた。以下、ピンクの所に挿入された。つまり。モデルコードの前。モデルコードがビーコン情報の最後に位置するようだ。言い換えるとAPRSスペック1.01に記載されているフォーマットに付加される形でモデルコードが追加されたことがわかる。

06:07:04R JA0WBT-7>SUTPW9,WIDE1-1 Port=1 <UI R Len=28>:`AB(l-=[/`"9N}Hello World_0

 

結果

以上より、FT3Dから発信されているビーコン情報は以下のとおりとなる。
北緯 35度40.79分
東経 137度38.12分
速度 0ノット
進路 56度
シンボル RUNNER
海抜 529m
無線機コード  Yaesu FT3D

以上

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局に感謝!

«渡渉用にソフト長靴を買ってみた

フォト
無料ブログはココログ
2023年1月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31