 |  | |
 |
|
RFワールド読者の掲示板Ⅱ
無線と高周波に関することを中心に、それ以外の話題も含めて、何でも書き込みOKの掲示板です。初めての方もネチケットを守って、お気軽にご参加下さい(^^)／
|
富井里一 - 19/3/8(金) 21:51 - |
Windows10 は, 大型アップデートすると ziVNAu / DZV-1 ドライバが認識しなくなります. USBドライバの再インストールが必要ですが, いつものやり方だと Windows上からデバイス(ziVNAu / DZV-1)が見つからない時があります.
このような時, 添付PDFのやり方を試してください.
このような時, 添付PDFのやり方を試してください.
![[添付]](./brd/RFW2/image/clip_icon.gif){kind=icon}
705 hits
|
editor - 19/3/5(火) 12:19 - |
Hiroyuki Naitoさん,
小誌「RFワールド」ご愛読ありがとうございます．
▼Hiroyuki Naitoさん：
>首記の図には四つの「モジュール名:ORゲート」がありますが、記号はANDが使われています。bdfファイルではOR記号が使われていましたので間違いだと思われますが、ご確認ください。
ご指摘ありがとうございます．作図ミスの校正漏れでございます．
正しくは添付の図の通りOR記号です．
不手際をお詫び申し上げます．
【630_rfw41p055f6-3-2.png : 50.7KB】
小誌「RFワールド」ご愛読ありがとうございます．
▼Hiroyuki Naitoさん：
>首記の図には四つの「モジュール名:ORゲート」がありますが、記号はANDが使われています。bdfファイルではOR記号が使われていましたので間違いだと思われますが、ご確認ください。
ご指摘ありがとうございます．作図ミスの校正漏れでございます．
正しくは添付の図の通りOR記号です．
不手際をお詫び申し上げます．
【630_rfw41p055f6-3-2.png : 50.7KB】
609 hits
|
Hiroyuki Naito - 19/3/5(火) 11:47 - |
お世話になります。
首記の図には四つの「モジュール名:ORゲート」がありますが、記号はANDが使われています。bdfファイルではOR記号が使われていましたので間違いだと思われますが、ご確認ください。
首記の図には四つの「モジュール名:ORゲート」がありますが、記号はANDが使われています。bdfファイルではOR記号が使われていましたので間違いだと思われますが、ご確認ください。
542 hits
|
富井里一 - 19/3/1(金) 15:27 - |
RFワールドNo.35で紹介の簡易VNA ziVNAu で, BitLockerの回復キーを必要とする場合の USBドライバのインストール手順です.
私が購入したPC(Inspiron 13 5000シリーズ, DELL製) は, BIOSでセキュアブートを無効にしても, USBドライバのインストール操作中に BitLockerの回復キーが必要になりました. しかし, 画面のメッセージの通りに操作をして無事にインストール成功しました. その操作手順のご紹介になります.
BIOSのセキュアブートは有効に戻してから添付する PDF の手順を実施しました.
私が購入したPC(Inspiron 13 5000シリーズ, DELL製) は, BIOSでセキュアブートを無効にしても, USBドライバのインストール操作中に BitLockerの回復キーが必要になりました. しかし, 画面のメッセージの通りに操作をして無事にインストール成功しました. その操作手順のご紹介になります.
BIOSのセキュアブートは有効に戻してから添付する PDF の手順を実施しました.
790 hits
|
小池清之
- 19/2/26(火) 0:40 -
|
▼Hiroyuki Naitoさん：
いつも詳細なご検討のご報告，誠にありがとうございます．
>このような工夫が具体的にどんなメリットをもたらすのかはまだ想像できませんが、二つの信号のタイミングを決して一致させたくない場面はありそうな気はします。
この２系統のクロックに対する工夫は，実はこの回路ではあまり役に立っていません．これはサンプルレート変換用のクロックです．サンプルレート変換は，RFW23で紹介した回路の前段階に別の検討をしておりましてその名残りとなっています．先に検討していた方式は次のようなものでした．
その方法とは，2.4MHzで流れてくる位相情報を変換後の1.92MHzに変換する際，1.92MHzのクロック立ち上がりが，2.4MHzクロック立ち上がり間のどの位置にあるかで，位相の重み付け加算を行うものでした．言葉だとわかりづらいので，添付の図をご覧ください．
このm,nの組み合わせを指定しやすくするため，このようなクロック生成方式にしました．2.4MHzと1.92MHzのもとになっている19.2MHzクロックの，80クロック周期の中の状態として指定できるというわけです．
この方式は頭の中で考えている間はとても良い方式に思えましたが，実際に作ってみると回路規模の割に性能改善はわずかでした．そこでRFW23のような回路に落ち着いたというわけなのです．
【626_重み付け加算式サンプルレート変換.gif : 45.1KB】
いつも詳細なご検討のご報告，誠にありがとうございます．
>このような工夫が具体的にどんなメリットをもたらすのかはまだ想像できませんが、二つの信号のタイミングを決して一致させたくない場面はありそうな気はします。
この２系統のクロックに対する工夫は，実はこの回路ではあまり役に立っていません．これはサンプルレート変換用のクロックです．サンプルレート変換は，RFW23で紹介した回路の前段階に別の検討をしておりましてその名残りとなっています．先に検討していた方式は次のようなものでした．
その方法とは，2.4MHzで流れてくる位相情報を変換後の1.92MHzに変換する際，1.92MHzのクロック立ち上がりが，2.4MHzクロック立ち上がり間のどの位置にあるかで，位相の重み付け加算を行うものでした．言葉だとわかりづらいので，添付の図をご覧ください．
このm,nの組み合わせを指定しやすくするため，このようなクロック生成方式にしました．2.4MHzと1.92MHzのもとになっている19.2MHzクロックの，80クロック周期の中の状態として指定できるというわけです．
この方式は頭の中で考えている間はとても良い方式に思えましたが，実際に作ってみると回路規模の割に性能改善はわずかでした．そこでRFW23のような回路に落ち着いたというわけなのです．
【626_重み付け加算式サンプルレート変換.gif : 45.1KB】
797 hits
|
editor - 19/2/24(日) 22:48 - |
Hiroyuki Naitoさん、小誌「RFワールド」ご愛読ならびに書き込みありがとうございます。
▼Hiroyuki Naitoさん：
>いま図6.6と図6.8の首記のシミュレーション回路を、検証するための入力信号の準備に悩みながら作成していましたら、図6.6の7ビットあるべき出力が6ビット(Y0がオープンになっている)しかないことに気づきましたのでご確認ください。
小池先生からのご回答を転記いたします。
－－－ここから
ここで紹介した回路では図6.6の出力はAVG7のY6～Y1しか取り出していません．その為Y0はオープンとしています．
ディジタル復調器としては，この遅延検波出力はY6,Y5しか使いませんので，Y4～Y1も本来は必要ありません．
Y6,Y5はDP5,DP4を経由して図6.21のデータ識別回路のXin, Yinに渡し，ディジタルデータに変換します．(図6.25もご参照ください)
それではなぜ，Y6～Y1を出力しているかと言うと，遅延検波波形をモニターするためです．
モニター出力は遅延検波出力をD/A変換することで得るのですが，当初そのDACにビデオ用の6bit DAC ICを用いていました．
ところがこのICが執筆時点では入手できないものだったことがわかり，図6.23のR-2RラダーのDACに置き換えました．
R-2Rラダーなら7ビットにしても良かったのですが，この回路はタイミング再生回路の出力モニターにも使うので，そのビット数6に合わせて共通化しました．
以上のような経緯でY0はNCとなっています．
－－－ここまで
以上です。
▼Hiroyuki Naitoさん：
>いま図6.6と図6.8の首記のシミュレーション回路を、検証するための入力信号の準備に悩みながら作成していましたら、図6.6の7ビットあるべき出力が6ビット(Y0がオープンになっている)しかないことに気づきましたのでご確認ください。
小池先生からのご回答を転記いたします。
－－－ここから
ここで紹介した回路では図6.6の出力はAVG7のY6～Y1しか取り出していません．その為Y0はオープンとしています．
ディジタル復調器としては，この遅延検波出力はY6,Y5しか使いませんので，Y4～Y1も本来は必要ありません．
Y6,Y5はDP5,DP4を経由して図6.21のデータ識別回路のXin, Yinに渡し，ディジタルデータに変換します．(図6.25もご参照ください)
それではなぜ，Y6～Y1を出力しているかと言うと，遅延検波波形をモニターするためです．
モニター出力は遅延検波出力をD/A変換することで得るのですが，当初そのDACにビデオ用の6bit DAC ICを用いていました．
ところがこのICが執筆時点では入手できないものだったことがわかり，図6.23のR-2RラダーのDACに置き換えました．
R-2Rラダーなら7ビットにしても良かったのですが，この回路はタイミング再生回路の出力モニターにも使うので，そのビット数6に合わせて共通化しました．
以上のような経緯でY0はNCとなっています．
－－－ここまで
以上です。
571 hits
|
Hiroyuki Naito - 19/2/24(日) 14:39 - |
お世話になります。
いま図6.6と図6.8の首記のシミュレーション回路を、検証するための入力信号の準備に悩みながら作成していましたら、図6.6の7ビットあるべき出力が6ビット(Y0がオープンになっている)しかないことに気づきましたのでご確認ください。
いま図6.6と図6.8の首記のシミュレーション回路を、検証するための入力信号の準備に悩みながら作成していましたら、図6.6の7ビットあるべき出力が6ビット(Y0がオープンになっている)しかないことに気づきましたのでご確認ください。
530 hits
|
森榮 - 19/2/23(土) 11:01 - |
▼Hiroyuki Naitoさん：
>お世話になります。
>
>53頁の図6_2(添付参照)のサブキャリアのI波形を生成するのに、サブキャリアのCOSとSIN波形がなぜ必要なのかすぐにはピンときませんでしたが、67頁のベースバンドI波形の式(6.1)を見つけて以下のように解釈しました。
>
> I(t)=cos{2π(f2)t+(π/2)N} …(6.1)
>
> f2はサブキャリア(0～15)のいずれかの周波数。
> NはQPSK変調の2ビット入力データ(0～3の整数)。
>
>N=0の場合 I(t)=cos(2π(f2)t+0) → COS
>N=1の場合 I(t)=cos(2π(f2)t+90°) →-SIN
>N=2の場合 I(t)=cos(2π(f2)t+180°)→-COS
>N=3の場合 I(t)=cos(2π(f2)T+270°)→ SIN
>
>となり表6.4と一致しました。サブキャリアのI波形生成は、入力データによって符号付きのCOS、SIN波形を択一していく操作になると思われますが、間違っていないでしょうか。
お世話になります。
Naito様がおっしゃいますとおり、本記事のQPSKサブキャリアの生成は、
SIN,COSいずれかを選び出して、正符号もしくは負符号をつけることで、
実現しております。FPGAのVerilogソースコードにつきましても、このコンセプトをもとに実装されております。
余談でございますが、16QAM、256QAMなど、変調が複雑になってきますと、
もう少し演算操作が複雑になってきます。
サブキャリア生成の際に、SIN,COSに振幅の重みを持たせて、足し合わせる必要があります。
>お世話になります。
>
>53頁の図6_2(添付参照)のサブキャリアのI波形を生成するのに、サブキャリアのCOSとSIN波形がなぜ必要なのかすぐにはピンときませんでしたが、67頁のベースバンドI波形の式(6.1)を見つけて以下のように解釈しました。
>
> I(t)=cos{2π(f2)t+(π/2)N} …(6.1)
>
> f2はサブキャリア(0～15)のいずれかの周波数。
> NはQPSK変調の2ビット入力データ(0～3の整数)。
>
>N=0の場合 I(t)=cos(2π(f2)t+0) → COS
>N=1の場合 I(t)=cos(2π(f2)t+90°) →-SIN
>N=2の場合 I(t)=cos(2π(f2)t+180°)→-COS
>N=3の場合 I(t)=cos(2π(f2)T+270°)→ SIN
>
>となり表6.4と一致しました。サブキャリアのI波形生成は、入力データによって符号付きのCOS、SIN波形を択一していく操作になると思われますが、間違っていないでしょうか。
お世話になります。
Naito様がおっしゃいますとおり、本記事のQPSKサブキャリアの生成は、
SIN,COSいずれかを選び出して、正符号もしくは負符号をつけることで、
実現しております。FPGAのVerilogソースコードにつきましても、このコンセプトをもとに実装されております。
余談でございますが、16QAM、256QAMなど、変調が複雑になってきますと、
もう少し演算操作が複雑になってきます。
サブキャリア生成の際に、SIN,COSに振幅の重みを持たせて、足し合わせる必要があります。
601 hits
|
田中仁之
- 19/2/20(水) 15:30 -
|
Dear OM Joe.
早々のご丁重なご回答をありがとうございました。
非常に曖昧なトラブルを、お尋ねし申し訳なく思っておりました。
熟読いたしました。
次の順序で、（正攻法で）で行くのがBestのようですね。
(1) CPUのUp grade
(2) Ubuntu の Live環境でのInstall
(3) GRC の Flow graph のCheck
(4) Hard(HackRFOne) のCheck
浅学の私には時間が掛かりそうです。
遅くなると思いますが、改ためてご連絡いたします。
この度は大変お手数をおかけ致しました。
重ねてお礼申し上げます。
田中仁之
早々のご丁重なご回答をありがとうございました。
非常に曖昧なトラブルを、お尋ねし申し訳なく思っておりました。
熟読いたしました。
次の順序で、（正攻法で）で行くのがBestのようですね。
(1) CPUのUp grade
(2) Ubuntu の Live環境でのInstall
(3) GRC の Flow graph のCheck
(4) Hard(HackRFOne) のCheck
浅学の私には時間が掛かりそうです。
遅くなると思いますが、改ためてご連絡いたします。
この度は大変お手数をおかけ致しました。
重ねてお礼申し上げます。
田中仁之
1,689 hits
|
joe - 19/2/20(水) 9:09 - |
▼田中仁之さん：
> HD-SDR を立ち上げますとそのHackRFoneでFM放送は完璧に受信できます。
HDSDRでFM放送を受信できるのなら，とりあえず受信系は壊れていないように思われます．ただし，FM放送の特性上，たとえ受信感度が少し劣化していても，ある程度以上の電界が得られれば，きれいに復調できてしまいます．このため受信のプリアンプ(MGA81563)が劣化している可能性やT/Rスイッチの通過損失が増している可能性は否定できないと思います．
HackRFoneは，RFワールドNo.44のp.12にある図1.1に記載されているような構成です．すなわち受信周波数範囲のすべてはTRスイッチを通った後，プリアンプ(MGA81563)で増幅されてから，受信周波数範囲に応じて三つ（2.4GHz以下，2.4～2.7GHz，2.7GHz以上)の経路で処理されます．ここから考えると，受信系は壊れていないように思われます．
また，HD-SDRで正常にFM放送を受信できるのなら，制御系も正常だと思います．
>・Ubuntu のUpdate
> GNUradioの再Install
> CQ出版社の提供プログラム（フローグラフ）の再Install
> 「RFワールドNo44」をまねての再打ち込み
> 等々は全て効果が有りませんでした。
別のPCを使い，UbuntuのLive環境をインストールしたUSBメモリで始動し，HackRFoneを動作させた場合はいかがでしょうか？
>・TXに関しては
> Narrow band FMはOKですが、AmとSSBがNGになりました。
HackRFoneの構成から考えて，NBFMがOKなのにAM/SSBがNGというのは，ハードウェア故障ではなくて，ソフトウェア(GRC/Pythonスクリプト)が原因だろうと思います．
つまりHackRFoneの送信系も無事であるように思います．
> その時、ATTの1/4[W] の抵抗が損傷いたしました。
ATTを挿入していたのは不幸中の幸いでしたね．
> もし、それでHackRFone のHard がダメージを受けたのであるならば、
> HD-SDRでは動作しなくなると思うのですが、如何なものでしょうか。
上述のように，HackRFoneのハードウェアは，送受信とも致命的な
ダメージを受けていないと思います．
以上，横から失礼いたしました．
> HD-SDR を立ち上げますとそのHackRFoneでFM放送は完璧に受信できます。
HDSDRでFM放送を受信できるのなら，とりあえず受信系は壊れていないように思われます．ただし，FM放送の特性上，たとえ受信感度が少し劣化していても，ある程度以上の電界が得られれば，きれいに復調できてしまいます．このため受信のプリアンプ(MGA81563)が劣化している可能性やT/Rスイッチの通過損失が増している可能性は否定できないと思います．
HackRFoneは，RFワールドNo.44のp.12にある図1.1に記載されているような構成です．すなわち受信周波数範囲のすべてはTRスイッチを通った後，プリアンプ(MGA81563)で増幅されてから，受信周波数範囲に応じて三つ（2.4GHz以下，2.4～2.7GHz，2.7GHz以上)の経路で処理されます．ここから考えると，受信系は壊れていないように思われます．
また，HD-SDRで正常にFM放送を受信できるのなら，制御系も正常だと思います．
>・Ubuntu のUpdate
> GNUradioの再Install
> CQ出版社の提供プログラム（フローグラフ）の再Install
> 「RFワールドNo44」をまねての再打ち込み
> 等々は全て効果が有りませんでした。
別のPCを使い，UbuntuのLive環境をインストールしたUSBメモリで始動し，HackRFoneを動作させた場合はいかがでしょうか？
>・TXに関しては
> Narrow band FMはOKですが、AmとSSBがNGになりました。
HackRFoneの構成から考えて，NBFMがOKなのにAM/SSBがNGというのは，ハードウェア故障ではなくて，ソフトウェア(GRC/Pythonスクリプト)が原因だろうと思います．
つまりHackRFoneの送信系も無事であるように思います．
> その時、ATTの1/4[W] の抵抗が損傷いたしました。
ATTを挿入していたのは不幸中の幸いでしたね．
> もし、それでHackRFone のHard がダメージを受けたのであるならば、
> HD-SDRでは動作しなくなると思うのですが、如何なものでしょうか。
上述のように，HackRFoneのハードウェアは，送受信とも致命的な
ダメージを受けていないと思います．
以上，横から失礼いたしました．
1,661 hits
|
Hiroyuki Naito - 19/2/19(火) 20:00 - |
お世話になります。
53頁の図6_2(添付参照)のサブキャリアのI波形を生成するのに、サブキャリアのCOSとSIN波形がなぜ必要なのかすぐにはピンときませんでしたが、67頁のベースバンドI波形の式(6.1)を見つけて以下のように解釈しました。
I(t)=cos{2π(f2)t+(π/2)N} …(6.1)
f2はサブキャリア(0～15)のいずれかの周波数。
NはQPSK変調の2ビット入力データ(0～3の整数)。
N=0の場合 I(t)=cos(2π(f2)t+0) → COS
N=1の場合 I(t)=cos(2π(f2)t+90°) →-SIN
N=2の場合 I(t)=cos(2π(f2)t+180°)→-COS
N=3の場合 I(t)=cos(2π(f2)T+270°)→ SIN
となり表6.4と一致しました。サブキャリアのI波形生成は、入力データによって符号付きのCOS、SIN波形を択一していく操作になると思われますが、間違っていないでしょうか。
53頁の図6_2(添付参照)のサブキャリアのI波形を生成するのに、サブキャリアのCOSとSIN波形がなぜ必要なのかすぐにはピンときませんでしたが、67頁のベースバンドI波形の式(6.1)を見つけて以下のように解釈しました。
I(t)=cos{2π(f2)t+(π/2)N} …(6.1)
f2はサブキャリア(0～15)のいずれかの周波数。
NはQPSK変調の2ビット入力データ(0～3の整数)。
N=0の場合 I(t)=cos(2π(f2)t+0) → COS
N=1の場合 I(t)=cos(2π(f2)t+90°) →-SIN
N=2の場合 I(t)=cos(2π(f2)t+180°)→-COS
N=3の場合 I(t)=cos(2π(f2)T+270°)→ SIN
となり表6.4と一致しました。サブキャリアのI波形生成は、入力データによって符号付きのCOS、SIN波形を択一していく操作になると思われますが、間違っていないでしょうか。
572 hits
|
田中仁之
- 19/2/19(火) 12:55 -
|
HackRFone と GNUradio でTRXを構築する前に
次のトラブルが発生してしまいました。
・FM(wide band)-RX が全く動作しなくなりました。
FM(narrow band)-RXは試しておりません。
・UbuntuがInstall されている同じHDD にWindows 10 が入っており
HD-SDR がInstall されております。
Antenna その他全てのHard は全くそのままで、
Key board の操作だけで、
HD-SDR を立ち上げますとそのHackRFoneでFM放送は完璧に受信できます。
・Ubuntu のUpdate
GNUradioの再Install
CQ出版社の提供プログラム（フローグラフ）の再Install
「RFワールドNo44」をまねての再打ち込み
等々は全て効果が有りませんでした。
・RXに関しては
AMはOKですが、SSBがNGになりました。
・TXに関しては
Narrow band FMはOKですが、AmとSSBがNGになりました。
・使用しているPCのCPUは結構古いDuo Core2です。
・HackRFone の信号をTranciever（受信）でチェックする為に
HackRFone → ATT → Tranciever
と接続しました。
Tranciever の立ち上げ時、一瞬ですがPTTが動作し、
送信状態になります。
その時、ATTの1/4[W] の抵抗が損傷いたしました。
もし、それでHackRFone のHard がダメージを受けたのであるならば、
HD-SDRでは動作しなくなると思うのですが、如何なものでしょうか。
全くのお手上げ状態です。
何卒宜しくお願い致します。
--------------------------------------
>Dear OM Joe
>
>早々の的確なご回答をありがとうございました。
>「言葉足らず」で失礼いたしました。
>まさに探していたのは「PTT機能」でした。
>100％理解致しました。
次のトラブルが発生してしまいました。
・FM(wide band)-RX が全く動作しなくなりました。
FM(narrow band)-RXは試しておりません。
・UbuntuがInstall されている同じHDD にWindows 10 が入っており
HD-SDR がInstall されております。
Antenna その他全てのHard は全くそのままで、
Key board の操作だけで、
HD-SDR を立ち上げますとそのHackRFoneでFM放送は完璧に受信できます。
・Ubuntu のUpdate
GNUradioの再Install
CQ出版社の提供プログラム（フローグラフ）の再Install
「RFワールドNo44」をまねての再打ち込み
等々は全て効果が有りませんでした。
・RXに関しては
AMはOKですが、SSBがNGになりました。
・TXに関しては
Narrow band FMはOKですが、AmとSSBがNGになりました。
・使用しているPCのCPUは結構古いDuo Core2です。
・HackRFone の信号をTranciever（受信）でチェックする為に
HackRFone → ATT → Tranciever
と接続しました。
Tranciever の立ち上げ時、一瞬ですがPTTが動作し、
送信状態になります。
その時、ATTの1/4[W] の抵抗が損傷いたしました。
もし、それでHackRFone のHard がダメージを受けたのであるならば、
HD-SDRでは動作しなくなると思うのですが、如何なものでしょうか。
全くのお手上げ状態です。
何卒宜しくお願い致します。
--------------------------------------
>Dear OM Joe
>
>早々の的確なご回答をありがとうございました。
>「言葉足らず」で失礼いたしました。
>まさに探していたのは「PTT機能」でした。
>100％理解致しました。
1,657 hits
|
Hiroyuki Naito - 19/2/15(金) 16:29 - |
▼editorさん、小池先生:
いつも丁寧なご回答をありがとうございます。
図6.3のシフトクロック回路の～(SYNC CLR)信号を、図5.14の4bitフリーランカウンタの～(SYNC CLR)に接続して、図6.5の二つのシフトクロック:CK1R92MとCK2R4Mの立上りエッジが一致しないことを確認できました。
添付のタイムチャートの下から3番目…CK1R92M
添付のタイムチャートの下から2番目…～(SYNC CLR)
添付のタイムチャートの一番下…CK2R4M
このような工夫が具体的にどんなメリットをもたらすのかはまだ想像できませんが、二つの信号のタイミングを決して一致させたくない場面はありそうな気はします。
【618_図6_5二つのシフトクロックの立上りエッジ.png : 260.3KB】
いつも丁寧なご回答をありがとうございます。
図6.3のシフトクロック回路の～(SYNC CLR)信号を、図5.14の4bitフリーランカウンタの～(SYNC CLR)に接続して、図6.5の二つのシフトクロック:CK1R92MとCK2R4Mの立上りエッジが一致しないことを確認できました。
添付のタイムチャートの下から3番目…CK1R92M
添付のタイムチャートの下から2番目…～(SYNC CLR)
添付のタイムチャートの一番下…CK2R4M
このような工夫が具体的にどんなメリットをもたらすのかはまだ想像できませんが、二つの信号のタイミングを決して一致させたくない場面はありそうな気はします。
【618_図6_5二つのシフトクロックの立上りエッジ.png : 260.3KB】
747 hits
|
editor - 19/2/14(木) 22:48 - |
Hiroyuki Naitoさん
小誌「RFワールド」ご愛読ならびに書き込みありがとうございます．
▼Hiroyuki Naitoさん：
>図6.4の～(SYNC CLR)の信号の極性は間違っていないでしょうか。
筆者の小池先生に確認していただいたところ図が間違っているようでございます．
小池先生は期末試験の採点などでご多忙とのことなので，ご回答を下記に転記いたします．
－－－ここから
ご質問の内容は，内藤様のご指摘の通りで，SYNC_CLRバーなのに反転し忘れていたようです．
バーを取れば合いますが，そのような信号は回路上にはないので，波形を上下反転した正誤表を出す必要がありそうです．
上記の通りだとは思っていますが，何か見落としがあるかもしれず，じっくり考えたいのですが，現状それができません．
考えるより，実機があるので波形を見ておこうということで，添付ファイルのように確認いたしました．
例の学生が作った復調器の卒業研究論文の回路図と基板のシルク図，プローブをあてた基板の写真等を載せています．
卒業研究論文の回路図はNo23の図6.3と同じものであることが確認できると思います．
IC7の8番ピンがSYNC_CLRバー，比較のためIC2の2番ピンのQ0にもプローブをあて，取り込んだ画像が
Q0-nSYNC_CLR.gif
です．
CH1がQ0，CH2がSYNC_CLRバーです．ご指摘の通り反転した波形です．
クリアは一瞬なのでほとんど"H"で時折"L"という画像の姿が正しいということになります．
No23の図6.4のSYNC_CLRをつないだら，カウンタがクリアされっぱなしになってしまいます．
－－－ここまで
【617_Q0-nSYNC_CLR.gif : 95.8KB】
【617_システム.JPG : 251.3KB】
【617_プリント基板.JPG : 220.2KB】
【617_回路図.jpg : 222.1KB】
【617_部品配置.jpg : 166.6KB】
小誌「RFワールド」ご愛読ならびに書き込みありがとうございます．
▼Hiroyuki Naitoさん：
>図6.4の～(SYNC CLR)の信号の極性は間違っていないでしょうか。
筆者の小池先生に確認していただいたところ図が間違っているようでございます．
小池先生は期末試験の採点などでご多忙とのことなので，ご回答を下記に転記いたします．
－－－ここから
ご質問の内容は，内藤様のご指摘の通りで，SYNC_CLRバーなのに反転し忘れていたようです．
バーを取れば合いますが，そのような信号は回路上にはないので，波形を上下反転した正誤表を出す必要がありそうです．
上記の通りだとは思っていますが，何か見落としがあるかもしれず，じっくり考えたいのですが，現状それができません．
考えるより，実機があるので波形を見ておこうということで，添付ファイルのように確認いたしました．
例の学生が作った復調器の卒業研究論文の回路図と基板のシルク図，プローブをあてた基板の写真等を載せています．
卒業研究論文の回路図はNo23の図6.3と同じものであることが確認できると思います．
IC7の8番ピンがSYNC_CLRバー，比較のためIC2の2番ピンのQ0にもプローブをあて，取り込んだ画像が
Q0-nSYNC_CLR.gif
です．
CH1がQ0，CH2がSYNC_CLRバーです．ご指摘の通り反転した波形です．
クリアは一瞬なのでほとんど"H"で時折"L"という画像の姿が正しいということになります．
No23の図6.4のSYNC_CLRをつないだら，カウンタがクリアされっぱなしになってしまいます．
－－－ここまで
【617_Q0-nSYNC_CLR.gif : 95.8KB】
【617_システム.JPG : 251.3KB】
【617_プリント基板.JPG : 220.2KB】
【617_回路図.jpg : 222.1KB】
【617_部品配置.jpg : 166.6KB】
672 hits
|
Hiroyuki Naito - 19/2/12(火) 17:19 - |
お世話になります。
図6.3の回路をシミュレーションしてみましたが、添付のタイムチャートの
～(SYNC CLR)信号(添付のタイムチャートの一番下の信号)のように、P66の
図6.4の～(SYNC CLR)信号の極性を反転したものが得られました。
図6.4の～(SYNC CLR)の信号の極性は間違っていないでしょうか。
【616_図6_4シフトクロック発生回路のタイムチャート.png : 242.3KB】
図6.3の回路をシミュレーションしてみましたが、添付のタイムチャートの
～(SYNC CLR)信号(添付のタイムチャートの一番下の信号)のように、P66の
図6.4の～(SYNC CLR)信号の極性を反転したものが得られました。
図6.4の～(SYNC CLR)の信号の極性は間違っていないでしょうか。
【616_図6_4シフトクロック発生回路のタイムチャート.png : 242.3KB】
625 hits
|
Taka - 19/2/7(木) 16:21 - |
▼Joeさん：
ありがとうございます。
もう少し調べてみます。
ありがとうございます。
もう少し調べてみます。
884 hits
|
Joe - 19/2/7(木) 10:55 - |
▼Takaさん：
>１．dotted lineの件
> 我が家のWindows版の接続線は線の引き方によって点線になったり実線になったりするようです。
動作がおかしいようですね．接続線は必ず実線(solid line)のはずです．
> 他のフローでは、それで問題なく動作している様に見えます。
> solid lineとdotted lineでは意味が違うのでしょうか？
(根拠を示して断言はできないのですが)ネットで調べた範囲だと，
dotted lineとかdashed lineと呼ばれるものはmessage passingを表すためのもので接続線とは違うようです．
>２．コンソールのエラーメッセージの件
> ValueError: port number 1 exceeds max of 0
> となっています。 出力ポート1個なら良いけど、2個は多すぎると言う事なんでしょうかね？
ポート番号1は最大値0を超えているという意味に受け取れます．このエラーメッセージがすでにおかしいように思います．
>GNU radioがLinuxベースで開発が行われているのは理解していますが、Windows版が正式にリリースされているので、Windowsで育ってきた私としては、Windows版が使えるのならWindows版でやりたい気持ちです。
残念ながら現時点では，Windows版の完成度は低い状態だと思います．
>１．dotted lineの件
> 我が家のWindows版の接続線は線の引き方によって点線になったり実線になったりするようです。
動作がおかしいようですね．接続線は必ず実線(solid line)のはずです．
> 他のフローでは、それで問題なく動作している様に見えます。
> solid lineとdotted lineでは意味が違うのでしょうか？
(根拠を示して断言はできないのですが)ネットで調べた範囲だと，
dotted lineとかdashed lineと呼ばれるものはmessage passingを表すためのもので接続線とは違うようです．
>２．コンソールのエラーメッセージの件
> ValueError: port number 1 exceeds max of 0
> となっています。 出力ポート1個なら良いけど、2個は多すぎると言う事なんでしょうかね？
ポート番号1は最大値0を超えているという意味に受け取れます．このエラーメッセージがすでにおかしいように思います．
>GNU radioがLinuxベースで開発が行われているのは理解していますが、Windows版が正式にリリースされているので、Windowsで育ってきた私としては、Windows版が使えるのならWindows版でやりたい気持ちです。
残念ながら現時点では，Windows版の完成度は低い状態だと思います．
816 hits
|
Taka - 19/2/6(水) 1:01 - |
▼Joeさん：
コメントありがとうございます。
今日は出掛けていてお返事が遅くなりました。
早速、調べてみましたが、何せ、分らない事ばかりなので時間が掛かります。
今までに分った事は以下の通りです。
１．dotted lineの件
我が家のWindows版の接続線は線の引き方によって点線になったり実線になったりするようです。
他のフローでは、それで問題なく動作している様に見えます。
solid lineとdotted lineでは意味が違うのでしょうか？
２．コンソールのエラーメッセージの件
ValueError: port number 1 exceeds max of 0
となっています。 出力ポート1個なら良いけど、2個は多すぎると言う事なんでしょうかね？
あと、エラーが発生しているのはruntime_swig.pyと言うモジュールの中みたいです。
名前から見るとランタイムのライブラリの中でしょうかね？
３．生成されたPythonスクリプトの件
top_block.pyの事でしょうか？
Windows版で生成された物と、Linux版で生成された物を、テキストエディタで比較して見ましたが、違う点は以下の2点のみで他は全く同じでした。
・_icon_pathの値（パス）が違う
・途中の空白行が1行と2行の違いがある所がある
今のところ、ざっと、こんな所です。
ライブラリの中見るのは、これからやってみようかと思ってますが、私で分るかどうかと言うのが心配です。
GNU radioがLinuxベースで開発が行われているのは理解していますが、Windows版が正式にリリースされているので、Windowsで育ってきた私としては、Windows版が使えるのならWindows版でやりたい気持ちです。
コメントありがとうございます。
今日は出掛けていてお返事が遅くなりました。
早速、調べてみましたが、何せ、分らない事ばかりなので時間が掛かります。
今までに分った事は以下の通りです。
１．dotted lineの件
我が家のWindows版の接続線は線の引き方によって点線になったり実線になったりするようです。
他のフローでは、それで問題なく動作している様に見えます。
solid lineとdotted lineでは意味が違うのでしょうか？
２．コンソールのエラーメッセージの件
ValueError: port number 1 exceeds max of 0
となっています。 出力ポート1個なら良いけど、2個は多すぎると言う事なんでしょうかね？
あと、エラーが発生しているのはruntime_swig.pyと言うモジュールの中みたいです。
名前から見るとランタイムのライブラリの中でしょうかね？
３．生成されたPythonスクリプトの件
top_block.pyの事でしょうか？
Windows版で生成された物と、Linux版で生成された物を、テキストエディタで比較して見ましたが、違う点は以下の2点のみで他は全く同じでした。
・_icon_pathの値（パス）が違う
・途中の空白行が1行と2行の違いがある所がある
今のところ、ざっと、こんな所です。
ライブラリの中見るのは、これからやってみようかと思ってますが、私で分るかどうかと言うのが心配です。
GNU radioがLinuxベースで開発が行われているのは理解していますが、Windows版が正式にリリースされているので、Windowsで育ってきた私としては、Windows版が使えるのならWindows版でやりたい気持ちです。
790 hits
|
Joe - 19/2/5(火) 10:56 - |
横から失礼いたします．
私は初心者なので的を外しているかもしれませんが，
コメントです．
▼Takaさん：
>Windows版のAudioSource出力2chではエラーで動作しません。
> 添付画像の190203_03_AudioSource2chOnWindows.jpg
動作しないフローダイヤグラムではSourceからSinkへの
接続線がsolid lineでなく，dotted lineになっているように
見えますが，いかがでしょうか？
左下ペーンのメッセージにどこがエラーになっているかが表示されているので，まずはそこから追っていくと原因がわかるかもしれません．
また，.grcで生成されたPythonスクリプトがあると思います．Linuxで正常に動作するスクリプトと，Windowsで動作しないスクリプトを比較してみるのはいかがでしょうか？
－…－
基本的にGNU radioはLinuxベースで開発が行われているので，Windowsとの互換性が十分に配慮されているとはいいがたいようです．
Linuxのライブラリにはファイル名の大文字小文字で機能が異なるものがあったりして，Windowsではそれを区別できないので，コンパイルに失敗していることがあります．
また連続時間で動作するはずのスクリプトなのに，Windows上で動作させると周期的に瞬断するような症状がつきまとうという不具合もあります．
なので，(仮想OSではなく)リアルなLinux上で動作させるのが，おすすめのようでございます．
私は初心者なので的を外しているかもしれませんが，
コメントです．
▼Takaさん：
>Windows版のAudioSource出力2chではエラーで動作しません。
> 添付画像の190203_03_AudioSource2chOnWindows.jpg
動作しないフローダイヤグラムではSourceからSinkへの
接続線がsolid lineでなく，dotted lineになっているように
見えますが，いかがでしょうか？
左下ペーンのメッセージにどこがエラーになっているかが表示されているので，まずはそこから追っていくと原因がわかるかもしれません．
また，.grcで生成されたPythonスクリプトがあると思います．Linuxで正常に動作するスクリプトと，Windowsで動作しないスクリプトを比較してみるのはいかがでしょうか？
－…－
基本的にGNU radioはLinuxベースで開発が行われているので，Windowsとの互換性が十分に配慮されているとはいいがたいようです．
Linuxのライブラリにはファイル名の大文字小文字で機能が異なるものがあったりして，Windowsではそれを区別できないので，コンパイルに失敗していることがあります．
また連続時間で動作するはずのスクリプトなのに，Windows上で動作させると周期的に瞬断するような症状がつきまとうという不具合もあります．
なので，(仮想OSではなく)リアルなLinux上で動作させるのが，おすすめのようでございます．
680 hits
|
Taka - 19/2/3(日) 22:49 - |
Windows版GNU Radio CompanionのAudioSourceで困っています。
Linux版ではAudioSource出力2chで問題なく動作しているフローです。
添付画像の190203_01_AudioSource2chOnLinux.jpg
Windows版のAudioSource出力1chでは問題なく動作しています。
添付画像の190203_02_AudioSource1chOnWindows.jpg
Windows版のAudioSource出力2chではエラーで動作しません。
添付画像の190203_03_AudioSource2chOnWindows.jpg
何か解決策をご存じでしたら、ご教授お願いいたします。
【611_190203_01_AudioSource2chOnLinux.jpg : 189.7KB】
【611_190203_02_AudioSource1chOnWindows.jpg : 161.0KB】
【611_190203_03_AudioSource2chOnWindows.jpg : 148.0KB】
Linux版ではAudioSource出力2chで問題なく動作しているフローです。
添付画像の190203_01_AudioSource2chOnLinux.jpg
Windows版のAudioSource出力1chでは問題なく動作しています。
添付画像の190203_02_AudioSource1chOnWindows.jpg
Windows版のAudioSource出力2chではエラーで動作しません。
添付画像の190203_03_AudioSource2chOnWindows.jpg
何か解決策をご存じでしたら、ご教授お願いいたします。
【611_190203_01_AudioSource2chOnLinux.jpg : 189.7KB】
【611_190203_02_AudioSource1chOnWindows.jpg : 161.0KB】
【611_190203_03_AudioSource2chOnWindows.jpg : 148.0KB】
702 hits
61,066