「ついに1対1のCDMAが動いた。。」の編集履歴（バックアップ）一覧はこちら
ついに1対1のCDMAが動いた。。 - (2011/11/21 (月) 19:52:39) の１つ前との変更点
追加された行は緑色になります。
削除された行は赤色になります。
*動いた。。
-なぜ動いたか
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を上げたら上の問題は解決
----
*動いた。。
-なぜ動いたか
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)
上図はgain=99の場合、
----
