JQ2RVNの無線ブログ

モービル　システム変更中

夏の旅行に向けて、モービルのアンテナ系を変更してます。
ってか、いままで「無線全般」的なカテゴリー作ってなかったのね。
よくもまあ、パケット系のネタで続けたもんだわ・・・hihi

まず、大きな変更点として・・・
な、なんとルーフキャリアをつけました！！

これで大きなアンテナでも運用できるってもんよ(^^

ってことで、HV5Sを取り付けてみました。
IC7000をもってながら、いままでHFとか活用してなかったもんなぁ～

でも、ここで大問題！！

SWRが下がらんって。。。OTL...
よりも深刻で、7MHzで送信しようとすると、IC7000の電源が落ちる

ま、すったもんだの挙句、バッテリーからの配線の問題でした(^^;;;

IC-7000の電源ケーブルって、ブレード型のヒューズが付いてるんやけど、
長年の振動(2年くらい?)のおかげで接触が悪くなっていたみたいです。

ちょこんと触ったら直ったので、根本的な解決はしてないけれど、
とりあえず、インシュロック使って、なるべく固定しておきました。

なお、この電源ケーブルを使って、無線関連の機器をつなげてますが、
TT3の暴走現象(1秒おき位に送信しまくる)も、ここが原因と判明。

出力を上げると症状が出るので、電波がまわりこんどるのかなとか
いろいろいたんですけれど、
もっと根本的なところでアウトだったわけです。

今では20Wでビーコン出しても、全然OKになりました。

ってことは何か？四国一周の旅（2008年1月）の長時間走行で
電源ラインがやられたってことなのか・・・

なお、HV5Sはまだ調整中です。
7MHzはおおよそ見当がついてるけど、21MHｚと50MHｚがなんともはや・・・
どこに同調してるかまーったく見えない。
旅行までには何とかしたいですね。

あーアンテナアナライザ。ほしくなってきた

なお、基台系統は、HF40FXでSWRが下がったのでOKっぽいです。

要求仕様

dsPICのTNCのコーディングがおおよそ進んで
使用メモリーの量がおおよそ把握できてきましたから、
この辺で要求仕様の決定をしておきたいと思います。

まずはKISS TNCの方
名称：dsKISS(仮)

RF側・・・
受信はクワドラチャ検波(中心周波数1700Hz)
DDS発信(1200Hz/2200Hz）
上位プロトコル　AX25

カッパーライン側(線でつながった方)・・・
UART KISSプロトコル(コマンド番号上位4ビットでアドレス指定)
または
I2C KISS改プロトコル(I2Cでアドレス指定・コマンド番号は無視)

アドレスは4ピン分つかって指定できるようにする

デジピータ・GPS制御の方
名称：Digi-On-KISS

TNCとの通信方法：I2C / KISS
PC/GPSとの通信方法：UART
コントローラとの通信方法：UART

機能　UIDIGI, Mic-E ,SmartBeaconなど

RMKS
なぜ、TNCでI2Cをサポートするか・・・
PIC24にはUARTは2chしかない。
よって、I2Cを使いたいところだけれども、通信距離を考えると
TNCとの通信でI2Cを使うのがよいと思われるので。

または、コントローラとの通信をソフトウェアで行って
TNCとの通信をUARTにすることも考慮。

コントローラを使うタイプと、使わないタイプで排他的にして
ファームウェアの書き換えで対応する方法も可能
(既存のTNCを利用して、デジができる）

KISSプロトコルとは・・・

KISSプロトコル。

少し前に発売されたTinyTrak4でもファームの入れ替えで
KISSプロトコルがサポートされるようになってます。

dsPICでTNCを作るとして、その出力をどうするか？
つまりデータリンク層のプロトコルを何にするかって考えたとき、
やはり既存のものと共通化しておくべきだでしょう。

ならば、もっともシンプルなものになると思うので
KISSプロトコルってことになるかな～って

実際にTNCをKISSモードにして確認したり、
Web上のドキュメントをみたりして調べた結果、
次のようなことがわかった。

データは0xC0で挟まれて流れてくる。
AX.25の0x7eに相当するものと考えて差し支えなし。

0xC0の次には、送信先(送信元も?)+コマンドが流れてくる。
これによって複数のTNCを区別したり、
TX DelayをKISS上から設定できたりするようだ。
基本は0x00で送られてくるっぽい。

そのあとに実際のデータが続く。
ただし、受信したデータがズラズラそのまんま。
つまり、アドレス(コールサインやらデジパスやら)のところも、
AX.25の規約のとおり、順番やら1ビットシフトも変えずに送られてくる。
(e.g.) アドレスの場合'J'=0x4a は 1ビット左シフトされた0x94で流れてくる。

CRCチェックはTNC側のお仕事。
受信した限りでは、CRCは付加されてこなかった。
Webドキュメントでは、CRC付きのものも解説されていたけれど、その区別は不明(要調査)

以上より、仕事の分担がわかりましたし、
非常にシンプルなフローでTNCを作れそうです。
したがって、これに沿ってTNCを製作していくつもりです

CRCの計算アルゴリズム

PICTNCのソースから、CRCアルゴリズムを解析しました。
わかりやすくするために16ビットの数値を8ビットで計算しているところなどは省略します。

以下、変数・定数
data: 受信 or 送信するデータ(8ビット)
CRC: CRCの値を格納(16ビット)
Poly: 生成多項式(16ビット定数)

PolyはAX.25では0x8408
CRCは計算前に0xFFFFで初期化します。

dataを右へ1ビットシフトします。このとき最下位のビットがCビットに出ます。
↓
C=1ならば、CRC xor 0x0001 -> CRC
↓
CRCを右1ビットシフト。同様に最下位ビットがCビットに出ます。
↓
C=0ならば、計算終了
C=1ならば、CRC xor Poly -> CRC

以上で計算は終了です。
アセンブラならおよそ10サイクルくらいで計算できると思います

クワドラチャ検波？

FM無線機のカタログなどで、よくクワドラチャ検波という言葉を見る。
パケット通信なんかで使っているFSKも、一種のFMなわけで
ならばこの方法が使えるのではないかと。。。

調べてみると、
90度位相をずらした信号を掛け合わせる
らしい・・・

なんともわかりずらい表現だなぁ～

大体、単に90度位相がずれたと書いてあるけれど、
何に対して90度なのか？何をずらすのか？がわからん。

ということで、FM検波用のICのデータシートを見てみた。
これがクワドラチャ検波なのか？と言われれば自信はない。
けど、うまくいったので使ってみようかと思います

やった方法は、入力信号をf(t)とし、中心周波数の周期をTcとすると
f( t ) * f( t - Tc/4 )を求めるということのようだ。

数学的な意味は・・・
f( t ) = sin ( ωt )とすると
f( t ) * f( t - Tc/4 ) = sin( ωt ) * sin ( ω(t - Tc/4 ))

ここで三角関数の積和の公式を利用すると、
1/2 ( cos A+B ) - 1/2 (cos A-B)
つまり、周波数2倍の波と、周波数0の波(つまり直流)が出てくる。

ここでLPFで2倍の信号をカットすると、直流のみがでてくる。

さて、その直流の値は・・・
cos( A-B ) = cos ( ω*Tc/4 )

ここで、ω = 2πf , Tc = 1 / fcだから、
=> cos ( π / 2 * f / fc )

もし、f = fcならば、cos( π/2 ) = 0
f < fc ならば、cos( ) > 0　　　　　(第Ⅰ象限)
2fc > f > fc ならば cos( )<0　　(第Ⅱ象限)
となる。

つまり、Bell202の場合だと中心周波数は1700Hz
スペース(1200Hz)が入力されているときは正。
マーク(2200Hz)が入力されているときは負。
となる。

MPLAB SIMで、シミュレートしてみた。
スペース1回→マーク1回→スペース2回→マーク2回の繰り返しです。
結果はdsPICworksで出しました。

簡単な移動平均フィルタで取り除いただけなので、高調波が出ています。
定常な状態なら、高調波は減衰しているのでゼロクロスできません。
遷移状態のとき、高調波はゼロクロスしてくる可能性はありますが、
チャタリング対策のときと同じように何回かチェックすればいいと思います

A/D変換でハマる

dsPICでADCのコーディングをしてて、ドつぼにはまった。

dsPICは結果を保存するバッファが16ある。
自動的に複数のチャンネルをスキャンしたり、
一定時間ごとに何点かの値が取得できて便利なんだけど・・・
データの入り方でハマった。

今回は4つサンプルを採って、それをFIR & Decimationしようとしていた。
ここで何も考えず、InputSignal[i]=ReadADC12(i);としてしまった。
FIRDecimate()関数に渡す配列は、添え字が大きい方が古いデータとなる。
つまり、InputSign[0]が最新で、InputSign[3]が最古である。
しかし、ADCのバッファは、ADCBUF0が最古でADCBUF3が最新。

したがって、上のように配列に転送すると、新旧が逆転する。
これじゃ、正常にデータが出てくるわけがない！

結局Cで作っても良かったが、アセンブラを組んで新旧がそろうようにした。

次のハマり。
MPLAB SIMで、ADCの入力をシミュレートしていた時の話・・・
Excelでデータを作ったが、ここが曲者である。

DSPとの親和性を考え、ADCの数値は固定小数点で入るように設定した。
そして、単純にExcelでも固定小数点に変換して出力した。
しかし、Excelから出した値と、ADCのバッファに入っている値が違っている。

ということで、気がついた。
入力する値は、ADCモジュールそのものが得た値でなければならないことを。

ADCが12ビットの場合、次のような流れで処理される。

ADCモジュール →4ビット左シフト → +0x8000 → ADCBUFｘ

たとえば、モジュールから1が出力されたら、
0x0001 → 0x0010 → 0x8010 と変換される。

なので用意するデータは・・・
=INT(2048*x+2048)
とExcelで行っておくだけでよい。

うまくいかなかったOTL...

DSPフィルタで信号の分離。
うまくいかなかった。。。。

連続信号ならうまくいくけど、
単発の信号だとフィルタをきれいに通ってくれない。

ということで、別方法で。
遅延検波というのがあるようです。

入ってきた信号と、180°だけ位相のずれた信号と掛け合わせる。
それを平均して、符号を調べると、その時のトーンがわかる。

Excelでシミュレートした限りではうまくいったので
これでやってみようかと思案中でございます

dsPIC Filter Design Tool導入

フィルタの設計は面倒な計算とかもあるので、
Microchip社製のdsPIC Filter Design Toolを購入しました。

かなり簡単な操作でフィルタの設計ができます。
しかも、そのままC30で利用できる形でエクスポート可能。

ただし、購入したのはLite版なので、FIRでは64タップ
IIRでは4セクションまでと制限があります。

上記のスクリーンショットは、
60kHzサンプリング
パスバンドが2400Hz、ストップバンドが6000Hz
通過帯リップル1db
阻止帯が-40dbというローパスフィルタです。
窓関数は方形。

上記の6つのパラメータを入力すれば、
タップ数も自動的に見積もってくれて、係数を計算できます。

ただし、64タップと少ないので、
いまいちキレるフィルタが作れないのが難点。

その辺はほかのツールで作っておいて、
ひな形だけFDに任せるのもいいかもしれません

FIRDecimate()関数 - dsPIC

MPLAB C30 の DSPライブラリについて・・・
あまり掲載記事のないFIRDecimate()関数の解析。

まずはデータシートの要約。

FIRDecimate()関数は、
サンプルされた値をフィルタしたのちR:1の割合で間引く関数。
オーバーサンプリングしたのち、LPFを通して間引きする時に有用。

プロトタイプは、
extern fractional* FIRDecimate (
    int numSamps,
    fractional* dstSamps,
    fractional* srcSamps,
    FIRStruct* filter,
    int rate
);

numSampsはサンプル数だけれども、この場合は出力の個数。
また、rateは間引き率。

(e.g.) 5つのサンプルを入力し、1つの出力をする場合。
numSamps=1, rate=5
と指定する。
さらにこの場合、srcSampsは5要素、dstSampsは1要素の配列とする。

(e.g.)10のサンプルを入力して、2つの出力をする場合。
numSamps=2, rate=5
secSampsは10要素、dstSampsは2要素の配列。

注意点：
フィルタのタップ数Mは、rateの整数倍でなければいけない。

次に、ソースの解析結果よりわかったこと。(firdecim.s)

遅延配列の値は移動させることによって最新値と書き換えている。
遅延配列をd[ ]とすると、MAC計算(畳み込み)前に、
d[ R+1 ] <- d[ 0 ]
d[ R+2 ] <- d[ 1 ]
.....
d[ M ] <- d[ M-R-1 ]
という風に、R+1個分大きな処に値をコピーする。
その上で、d[ 0 ] <- x[ 0 ] .... d[ R] <- x[R]と、コピーをする。

つまり通常のFIR()関数のように、FIRStruct構造体のdelayメンバを使った
モジュロアドレッシングによる計算をしていない。

したがって注意すべきことは、
FIR()関数とFIRDecimate()関数を切り替えて使えない
ということ。

FIR()で計算したときはd[ firStruct.delay ]からサンプルを入れるけどをするけれど、
FIRDecimate()のときはd[ 0 ]からサンプルを入れる。
また、畳み込みの計算開始位置も違う。
結果、計算がおかしくなってしまう。

この「切り替える」というのは1つのFIRStruct構造体に対してであって、
2つの構造体を、一方はFIR()で、一方はFIRDecimate()で、
という使い方をしても、問題はない。

普通は1つを切り替えるということはしないだろうから、
気にする必要はないと思われる。

FIRの使い方 - MPLAB C30

ただいま、MPLAB C30で、フィルタ作りに格闘中です。

大まかな流れは以下のとおり

FIR用構造体を作成
↓
FIR構造体の初期化
↓
FIRの実行

上2つは、書籍やホームページを参照しておけばOKだと思う。

最後のFIRの実行は、そのまんまの名前のFIR()関数を使用する。
FIR( numSamp , &outSamp , &inSamp , &Filter )
という形式。

ここで、numSampはサンプリングされた値の個数。
多くの場合は1でよいと思う。

inSampがサンプリングされた値。
FIR()関数が呼び出されると、遅延配列の最古の値がinSampで書き換えられる。

もしタップ数が5つだったとしたら
5 4 3 2 1
↓
4 3 2 1 inSamp
というように書き換えられる。

その上で、畳み込み計算がおこなわれて、結果がoutSampに出てくる。

遅延配列の書き換えは、dsPICの場合便利にできていて、
たとえば0から4の5つの番地に書き込もうとするとき、
dsPICに0と4を登録しておく。
そうすると、ポインタをインクリメントしていくと
通常だと、0 1 2 3 4 5 ・・・となるが、
dsPICだと、0 1 2 3 4 0 1 2・・・と自動的にポインタが戻ってくれる。

これを登録するのは、FIRStruct構造体に仕込まれていて
coeffsBase , coeffsEnd , delayBase , delayEnd
の4つの値になる。
(係数配列の先頭と終端、遅延配列の先頭と終端）

この機能があるおかげで、dsPICでの畳み込みは
REPEAT + MAC命令で、単純&高速にできる。
(レジスタはXMODSTAT , XMODEND , Y～～)

逆にいえば、これがなかったらPIC24と同じだなｗ
(ホントは40bitアキュムレータとか、ビット順序逆転とかもあるけど・・・）