ついに1対1のCDMAが動いた。。

「ついに1対1のCDMAが動いた。。」の編集履歴(バックアップ)一覧はこちら

ついに1対1のCDMAが動いた。。」(2011/11/26 (土) 08:41:42) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

*動いた。。 -なぜ動いたか GNURadio4.Xでアップデートされたクロックリカバリー回路を用いたらBERがほぼ0に(全ビットが反転してしまう場合を除く)。 -マルチユーザはだめ? やった!これで論文書ける!と意気込み さて次はマルチユーザだ!とすぐさまやったが、うまく動かない。 信号が衝突してしまうせいか、全然同期がとれない。→無線で試したがやはりだめ。。 *マルチユーザへの挑戦 -なぜ動かないのか? 以下はoscilloscopeでキャプチャした画像だが、キャリア周波数がベースバンドよりもなぜか小さく(?)、 マルチユーザにしたときに減衰部分がかき消されてしまう。→検討違い。 #image(cdma_t2_195khz.png,width=400,height=315,title=ベースバンド信号の減水,left) このキャプチャによると、キャリアらしきものは1kHzくらい。 CDMAチップレートは97.5kchip/sec(=195sample/sec÷2sample/symbol)くらい。(つまり帯域幅は100kHzくらい) つまり、サンプル数/sec(97.5kが限界?)を小さく、1シンボルあたりのサンプル数を大きくすればいい!? →samples/symbolが8以上だと上手く複合できない。 もっとよく調べてみたら、USRPによって受信した信号の波形が異なることが分かった。 ↓1つ目のUSRPから受信した信号。 #image(ch1power_usrp1.png,width=400,height=315,title=USRPその1からの受信波形,left) ↓2つ目のUSRPから受信した信号。 #image(ch1power_usrp2.png,width=400,height=315,title=USRPその2からの受信波形,left) ↓両方のUSRPから受信した信号。 #image(ch1power_usrp1+2.png,width=400,height=315,title=USRPその1と2からの受信波形,left) 上2枚は同じスケールだが、波形が異なっていて、3枚目の図においては一方のUSRPの波形しか見えない。 シングルユーザの場合はいずれもBERはほぼないかが、上図のようなマルチユーザの場合はなぜか2番目のUSRP からの信号しか複合できない。しかもこの場合は1チップの誤りもない。 USRPやdaughterboardを入れ替えて色々と試した結果、USRPのマザボが上図に示したような波形の違いに影響を与えていることがわかった。 -USRPの構造 こんなことを言っている人がいる。 [[I read that the RF frontend down-scales to the ADC.>http://osdir.com/ml/discuss-gnuradio-gnu/2011-05/msg00519.html]] USRPの構造をわかりやすく説明した[[文献>http://www.snowymtn.ca/gnuradio/gnuradiodoc-4.pdf]]があった。以下要約。 ・daughterboard→amp→ADC→MUX→DDC(×NCO→CIC(Decimator))→Giga Ether→Host ・NCO([[参考>http://www.google.co.jp/url?sa=t&rct=j&q=nco%2B%25E7%2584%25A1%25E7%25B7%259A&source=web&cd=1&ved=0CCQQFjAA&url=http%3A%2F%2Fwww.cqpub.co.jp%2Fdwm%2Fcontents%2F0116%2Fdwm011600710.pdf&ei=scizTpyWEsLImAXitfX2Aw&usg=AFQjCNF_eboYsNfYyg2Op9jcN2Mu2ZfH7w]])はIFからベースバンドに変換するのに用いられる。 ・最終的にホストに送られるのはIチャンネルとQチャンネルのベースバンド信号(16-bit×2×25Msample/sec = 800Mbit/sec < 1Gbit/sec)。 ・つまり、伝送路ではちゃんと2.45GHzの信号でmixされている。 やっぱり、USRPのマザーが受け取るのはIF帯。100MspsでADCが動いているからね。[[GNURadioより>http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html]] そしてそのADCを通った後はソフトウェアの世界。やっぱりDDCでIFからBasebandにしているから、そこをいじれるかが勝負!! そしてさっき挙げた文献にこんなことが↓ We can set the IF frequency of the DDC using usrp.set_rx_freq() method and set the decimation factor using usrp.set_decim_rate() method in Python. The decimation rate must be in [1, 256]. (でもuhd_usrp_source.hにはそんな関数はなかたよ。。) これらの情報は全部DDC(受信側)の話だけどおそらく問題なのはDUC(送信側)だと思う。(USRPによって送信波形が異なるから) そこを固定できるかが今後の課題だっぺ。 だがしかし。。 Two digital upconverters (DUCs) interpolate baseband signals to 100 MS/s before translating them to the selected output frequency. (EttusのUSRPN200シリーズのデータシートより) DUCは100Ms/sに固定っぽいことが書いてあるよ。。でもそれと同時にDigital upconverters with programmable interpolation ratesって右のFeatureに書いてある。ということは、そういうこと? [[DUCに関するWiki>http://gnuradio.org/redmine/projects/gnuradio/wiki/UsrpFAQDUC]] -DDCのgainを上げたら上の問題は解決 USRPのgainを99にしたら、どちらかが打ち消されるという問題は解決した。(今まではなんとgain=0になっていた。) python uhd_cdma_rx2.py -f 2.45G -c 1 -g 99 (-g でgainをいじれる) #image(osci_gain99.png,width=400,height=315,title=USRPその1と2からの受信波形,left) #image(osci_gain50.png,width=400,height=315,title=USRPその1と2からの受信波形,center) 上がgain=99の場合で下がgain=50の場合、上の方が歪んでいる幅が小さいのが分かる。 -daughter board問題 以下、2端末からの混合信号を受信した際のオシロスコープの画面。 #image(osci_usrp_1+2.png,width=400,height=315,title=USRPその1と2からの受信波形,center) 値が1or-1でおかしい。daughter boardではどんな変調を行っているのか? GNURadioのFAQで、受信側にはオフセット周波数が発生してしまうこと、実際の受信電圧を測ることはできないことがわかった。 ・Why is there always a frequency offset when transmitting from one USRP to another? It's the law of physics. There is no way to eliminate this. Digital receivers must be able to cope with this kind of error. ・How do I know the exact voltage/power of my received input signal? This is extremely difficult. Remember that the USRP (or whatever device you're using) has several analog stages (AGC, amplifiers etc.) which all affect the power before it is passed to the A/D converter. Once you're in the digital domain, all you have is numbers . The only way to get the exact received power is by calibrating your signal manually. ----
*動いた。。 -なぜ動いたか GNURadio4.Xでアップデートされたクロックリカバリー回路を用いたらBERがほぼ0に(全ビットが反転してしまう場合を除く)。 -マルチユーザはだめ? やった!これで論文書ける!と意気込み さて次はマルチユーザだ!とすぐさまやったが、うまく動かない。 信号が衝突してしまうせいか、全然同期がとれない。→無線で試したがやはりだめ。。 *マルチユーザへの挑戦 -なぜ動かないのか? 以下はoscilloscopeでキャプチャした画像だが、キャリア周波数がベースバンドよりもなぜか小さく(?)、 マルチユーザにしたときに減衰部分がかき消されてしまう。→検討違い。 #image(cdma_t2_195khz.png,width=400,height=315,title=ベースバンド信号の減水,left) このキャプチャによると、キャリアらしきものは1kHzくらい。 CDMAチップレートは97.5kchip/sec(=195sample/sec÷2sample/symbol)くらい。(つまり帯域幅は100kHzくらい) つまり、サンプル数/sec(97.5kが限界?)を小さく、1シンボルあたりのサンプル数を大きくすればいい!? →samples/symbolが8以上だと上手く複合できない。 もっとよく調べてみたら、USRPによって受信した信号の波形が異なることが分かった。 ↓1つ目のUSRPから受信した信号。 #image(ch1power_usrp1.png,width=400,height=315,title=USRPその1からの受信波形,left) ↓2つ目のUSRPから受信した信号。 #image(ch1power_usrp2.png,width=400,height=315,title=USRPその2からの受信波形,left) ↓両方のUSRPから受信した信号。 #image(ch1power_usrp1+2.png,width=400,height=315,title=USRPその1と2からの受信波形,left) 上2枚は同じスケールだが、波形が異なっていて、3枚目の図においては一方のUSRPの波形しか見えない。 シングルユーザの場合はいずれもBERはほぼないかが、上図のようなマルチユーザの場合はなぜか2番目のUSRP からの信号しか複合できない。しかもこの場合は1チップの誤りもない。 USRPやdaughterboardを入れ替えて色々と試した結果、USRPのマザボが上図に示したような波形の違いに影響を与えていることがわかった。 -USRPの構造 こんなことを言っている人がいる。 [[I read that the RF frontend down-scales to the ADC.>http://osdir.com/ml/discuss-gnuradio-gnu/2011-05/msg00519.html]] USRPの構造をわかりやすく説明した[[文献>http://www.snowymtn.ca/gnuradio/gnuradiodoc-4.pdf]]があった。以下要約。 ・daughterboard→amp→ADC→MUX→DDC(×NCO→CIC(Decimator))→Giga Ether→Host ・NCO([[参考>http://www.google.co.jp/url?sa=t&rct=j&q=nco%2B%25E7%2584%25A1%25E7%25B7%259A&source=web&cd=1&ved=0CCQQFjAA&url=http%3A%2F%2Fwww.cqpub.co.jp%2Fdwm%2Fcontents%2F0116%2Fdwm011600710.pdf&ei=scizTpyWEsLImAXitfX2Aw&usg=AFQjCNF_eboYsNfYyg2Op9jcN2Mu2ZfH7w]])はIFからベースバンドに変換するのに用いられる。 ・最終的にホストに送られるのはIチャンネルとQチャンネルのベースバンド信号(16-bit×2×25Msample/sec = 800Mbit/sec < 1Gbit/sec)。 ・つまり、伝送路ではちゃんと2.45GHzの信号でmixされている。 やっぱり、USRPのマザーが受け取るのはIF帯。100MspsでADCが動いているからね。[[GNURadioより>http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html]] そしてそのADCを通った後はソフトウェアの世界。やっぱりDDCでIFからBasebandにしているから、そこをいじれるかが勝負!! そしてさっき挙げた文献にこんなことが↓ We can set the IF frequency of the DDC using usrp.set_rx_freq() method and set the decimation factor using usrp.set_decim_rate() method in Python. The decimation rate must be in [1, 256]. (でもuhd_usrp_source.hにはそんな関数はなかたよ。。) これらの情報は全部DDC(受信側)の話だけどおそらく問題なのはDUC(送信側)だと思う。(USRPによって送信波形が異なるから) そこを固定できるかが今後の課題だっぺ。 だがしかし。。 Two digital upconverters (DUCs) interpolate baseband signals to 100 MS/s before translating them to the selected output frequency. (EttusのUSRPN200シリーズのデータシートより) DUCは100Ms/sに固定っぽいことが書いてあるよ。。でもそれと同時にDigital upconverters with programmable interpolation ratesって右のFeatureに書いてある。ということは、そういうこと? [[DUCに関するWiki>http://gnuradio.org/redmine/projects/gnuradio/wiki/UsrpFAQDUC]] -DDCのgainを上げたら上の問題は解決 USRPのgainを99にしたら、どちらかが打ち消されるという問題は解決した。(今まではなんとgain=0になっていた。) python uhd_cdma_rx2.py -f 2.45G -c 1 -g 99 (-g でgainをいじれる) #image(osci_gain99.png,width=400,height=315,title=USRPその1と2からの受信波形,left) #image(osci_gain50.png,width=400,height=315,title=USRPその1と2からの受信波形,center) 上がgain=99の場合で下がgain=50の場合、上の方が歪んでいる幅が小さいのが分かる。 -daughter board問題 以下、2端末からの混合信号を受信した際のオシロスコープの画面。 #image(osci_usrp_1+2.png,width=400,height=315,title=USRPその1と2からの受信波形,center) 値が1or-1でおかしい。daughter boardではどんな変調を行っているのか? GNURadioのFAQで、受信側にはオフセット周波数が発生してしまうこと、実際の受信電圧を測ることはできないことがわかった。 ・Why is there always a frequency offset when transmitting from one USRP to another? It's the law of physics. There is no way to eliminate this. Digital receivers must be able to cope with this kind of error. ・How do I know the exact voltage/power of my received input signal? This is extremely difficult. Remember that the USRP (or whatever device you're using) has several analog stages (AGC, amplifiers etc.) which all affect the power before it is passed to the A/D converter. Once you're in the digital domain, all you have is numbers . The only way to get the exact received power is by calibrating your signal manually. こんなのも見つけた![[GNURadioのbasebandについて>http://www.ruby-forum.com/topic/177739]] ----

表示オプション

横に並べて表示:
変化行の前後のみ表示: