備忘録など

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月 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月12日 (月)

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月 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

以上。

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年10月 4日 (火)

Intel スマートサウンドテクノロジーとオーディオデバイス検出の相性

WIRES-Xでちょっとした問題に遭遇。考察結果を備忘録として以下に記録。

某AcerのノートPCにWIRES-Xをインストールしたところ、オーディオデバイスが接続されていないってことで起動できない。この状態で、マイクスピーカーコンボジャック(4端子ジャック)にピンジャックを差し込むとこの問題が解消されてWIRES-Xが起動できる。

ピンジャックを差し込む前は、ピンジャックを担当するオーディオデバイスとしてのRealTekマイクデバイスが未接続となっている。ピンジャックを差し込むと接続済みになる。

どうやらWIRES-XはRealTekマイクデバイスが未接続状態で「オーディオデバイスの接続が無い」と言ってきて、RealTekマイクデバイスが接続状態で「オーディオデバイスの接続が有る」と判断するようだ。

一方、このノートPCにはIntelスマートサウンドテクノロジーデバイス、つまり専用DSPが実装されていて、PC内蔵マイクや内蔵スピーカーはそのデバイスに繋がっている(ようだ)。オーディオデバイスドライバーを使う限り、アプリ的にはスマートサウンドテクノロジーを介しているか否かは透過的になっているはずなので、WIRES-Xのサウンドもスマートサウンドテクノロジーで動作するはずだ。

どうやら問題はWIRES-Xがこのスマートサウンドテクノロジーデバイスをオーディオデバイスとして認識(判別)することが出来ないことらしい。なので、何でも良いのでWIRES-Xが認識(識別)できるオーディオデバイスを接続状態にしてあげれば良いということだ。これを行うにはノートPCのマイクスピーカーコンボジャックにピンジャックを差し込んで(実際に外部マイクや外部スピーカーを接続する必要はない)RealTekオーディオデバイスを活性化すればよい。少なくともこのノートPCではピンジャックを差し込むだけでRealTekは活性化する。

仮にこのスマートサウンドテクノロジーをアンイストールしたとしたら、PC内蔵マイクとスピーカーが使えなくなるので嬉しくはない、というか結局は外付けマイクとスピーカーを繋がないといけないことになるので、上記ピンジャック接続作業より負担が増える。これらから、ピンジャック差し込み以外に対応方法はないのかもしれない。

今後のWIRES-Xのバージョンアップに期待したい。

2022年7月19日 (火)

キューちゃんレシピ

キュウリ消費作戦としてキューちゃんを作ったので備忘録

基本的なレシピはCookpadから頂いた。

  • キュウリ:1Kg(大4本)
  • 醤油:400㏄
  • 砂糖:250g
  • みりん:50cc
  • 酢:50cc
  1. キュウリは5mm程度にカット。生姜は小さく短冊切り。
  2. キュウリを塩でもんで、30分放置。水気を切る。
  3. 調味料全部を鍋にいれて煮立たせる
  4. 火を止めてキュウリを投入。約6時間放置。
  5. キュウリを取り出して、再沸騰。
  6. キュウリを再投入。
  7. 6時間以上放置して、出来上がり。

 

出来上がったキューちゃん。生姜多めで結構イケる。
Img01505_small

投入から6時間後。ここで取り出して、汁を再沸騰。
Img01502_small

キューちゃんを取り出した煮汁。さて、これをどう再利用するか、、、
Img01504_small

 

 

2022年4月23日 (土)

Google Searchクローラーの呼び込み

ホームページを開設したけれどもGoogle検索に出てこない。Googleにインデックスを作ってもらう必要があるようだ。そこでGoogle Search Consoleでインデックス作成(クロール実行)リクエストを出したのでその備忘録。

今回新たに作成したホームページのURLを最上段のURL入力欄にいれてみると、「URLがGoogleに登録されていません」と出てきた。つまりクロール対象になっていないからGoogle検索にヒットしないわけだ。そこで「インデックス登録をリクエスト」をクリックする。すると登録可能かテストする旨のダイアログが表示さて1分ほど待たされた。
20220423-2

この後、URLがクロールキューに入った旨のメッセージダイアログが表示された。
20220423-3

これでクロールされるはずなので、暫くするとGoogle検索にひっかかってくるはずだ。

2022年4月17日 (日)

EchoLinkでのHAMSTIRの動き

EchoLinkでHAMSTIR STとHAMSTIR Xを使っている。HAMSTIR XはWIRES-Xとの相互接続のために使用。今回の構成でEchoLink側のみ、おかしな動作をするので、まずは現状の記録から。

システムの全体構成図は以下のとおり。
Photo_20220417080401

ここでの「おかしな動き」とは以下の通り。

  1. EchoLinkのUserノードからSysOpノードであるJA0WBT-Lに接続し、Transmitする。SysOpノードはRXモードになり、Userノードからの音声はHAMSTIR ST→HAMSTIR X→FTM-100Dと送られ、FTM-100Dより送信される。またHAMSTIR X→HRI-200を経由してWIRES-Xノードが接続しているWIRES-X Roomにも転送される。ここまでは想定通り。
  2. EchoLinkのUserノードがTransmitを終了すると、EchoLink SysOpノードはアイドル状態になり、FTM-100DおよびHRI-200を通した送信は停止する。ここまでも想定通り。
  3. この後(SysOpノードがアイドル状態になって1秒未満)、SysOpノードはTXモードになりUserノードに信号を(勝手に)送る。UserノードはRXモードになり、Transmitができなくなる。ここがおかしな動き。この状態では、SysOpノードはTXモードになるがWIRES-X側は送信状態にはならない。つまりEchoLink側だけが勝手にTX状態になる。なお、この現象はFTM-100Dの電源がONになっている場合にのみ発生する。

上記動作をイラストで表すと以下のとおり。

1. 
Echolinktransmit

2. 
Echolinkidle

3.
Echolinktx

この現象をEchoLink SysOp画面で見ると以下となる。
Echolinkgui

この現象の観察を通して、現時点で以下の結論に到達している。

  • 本現象(勝手にTXがONになる)はFTM-100Dの電源が入っている場合にのみ起きる。仮にFTM-100Dが変な動きをしている(電波を受信していないのに受信データをHAMSTIR Xに送っている)とすると、EchoLinkとWIRES-Xの両方が送信するはずだ。よってFTM-100Dの動作が異常だとは言えない(FTM-100DはEchoLinkだけにおかしな信号を送ることはできない)。
  • FTM-100Dの電源が入っていない状態では、EchoLinkとWIRES-X間の相互通信は問題なく実行され、本現象も発生しない。よって、HAMSTIR STに問題があるとは思えない。
  • 以上より、FTM-100Dの電源状態(信号状態)を認識することができ、EchoLink側だけにおかしな信号を送ることが出来る(EchoLinkとWIRES-Xに対して別々のインターフェースを持っている)HAMSTIR Xの動作があやしい。

要追加調査。。。。。

解決!!

HAMSTIRの開発元であるOneChipDesignより大変貴重な情報を頂く事ができ、無事問題が解消したので以下にその情報を転記(一部編集)。

問題のポイントは、送信時スケルチ出力の設定です。
[TX]: ON(初期値)にすると、送信時 Hレベルの信号が出力するようで、
受信に戻った時の Lレベルに戻るタイミングのバラツキで、
EchoLinkの方が受信信号有りと判断してしまい誤動作になるようです。

・FTM-100の設定例 (WIRES-Xノード局モードにはしない)
 設定画面に入るには、[DISP SETUP]ボタンを長押しします。
 [DATA] =>[1.COM PORT SETTING] =>[COM OUTPUT] : PACKET
 [DATA] =>[2.DATA SPEED] : DATA 1200 bps
 [DATA] =>[3.DATA SQUELCH] : 2 TX OFF

・FTM-400の設定例
 設定画面に入るには、[DISP]ボタンを長押しします。(HRI-200制御モードにはしない)
 [TX/RX] =>[AUDIO] =>[MIC GAIN] : NORMAL
 [DATA] =>[COM PORT SETTING] =>[OUTPUT] : OFF(camera)
 [DATA] =>[DATA BAND SELECT] =>[DATA] : MAIN BAND
 [DATA] =>[DATA] : 1200bps
 [DATA] =>[DATA SQUELCH] =>[DATA] : TX/RX BAND
 [DATA] =>[DATA SQUELCH] =>[TX] : OFF

 

いやぁ、FTM-100Dのマニュアルは見たつもりが、DATA SQUELCHなる設定がある事には気が付かなった。スケルチ設定のところはいろいろと設定してみたものの、それは実際の電波受信時のスケルチ設定のところどまりだった。

やはり技術力のある会社さんの製品はこういったテクニカルサポートもすごく魅力的なところだ。深々と感謝!!!

フォト
無料ブログはココログ
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