2012/07/01〜

...................................................................................................................................

2012/06/28

ASCII.jp, 「IMES」建物内のどこにいるかまでわかる位置情報技術, 2012年6月20日

今のままじゃ、ちょっと普及しそうな感じしないよね、という書きぶり。別に否定しないけど...。

-------------------------------------

ついでなので、LEX short code生成のCコード。

#define LEX_LEN_SHORT 10230*2
static rcode_t *code_LEX_SHORT(int sat)
{
    rcode_t *rcode=NULL;
    
    /* initial shift register, IS-QZSS table 5.7.1-1 (PRN 193-197, in octal) */
    const int init_state[]={0255021,0327455,0531421,0615350,0635477};
    char R1[10],R2[20],C1,C2,CODE[LEN_LEX_SHORT/2];
    int i,j;
    
    if (sat<193||197<sat) return NULL;
    if (!(rcode=(rcode_t *)sdrmalloc(sizeof(rcode_t)))||
        !(rcode->code=(char *)sdrmalloc(sizeof(char)*LEN_LEX_SHORT))) {
        return NULL;
    }
    for (i=0;i<10;i++) R1[i]=1;
    for (i=0;i<20;i++) R2[i]=(init_state[sat-193]>>i)&1;
    for (i=0;i<LEN_LEX_SHORT/2;i++) {
        CODE[i]=R1[9]^R2[19];
        C1=R1[9]^R1[8]^R1[5]^R1[4]^R1[3]^R1[2];
        C2=R2[19]^R2[18]^R2[15]^R2[13];
        for (j= 9;j>0;j--) R1[j]=R1[j-1];
        for (j=19;j>0;j--) R2[j]=R2[j-1];
        R1[0]=C1; R2[0]=C2;
    }
    for (i=0;i<LEN_LEX_SHORT;i++) rcode->code[i]=i%2?0:(CODE[i/2]?1:-1);
    rcode->sat=sat;
    rcode->ctype=CTYPE_LEX_SHORT;
    rcode->modul=MODUL_BPSK;
    rcode->len=LEN_LEX_SHORT;
    rcode->crate=RATE_LEX_SHORT;
    rcode->srate=0;
    return rcode;
}

-------------------------------------

LEXのSDR実装が実際どれだけ簡単か、下のグラフ描くコードを公開。gencode()はMEX functionでIS QZSS通りコード生成してオーバーサンプリングしているだけ。(long codeが入るところは0埋め) なおこんなことを書いているのは、簡単だから誰かやりません、ということを言いたい訳だ。

function test_lex(ch,ts)
% LEX test by TTAKA
if nargin<1,ch=2;      end % channel (1:L1C/A,2:LEX)
if nargin<2,ts=0.8e-3; end % start of samples (s)

if ch==1 % L1 C/A
    file='../stereo_if_201206262032/l1rx_l1ca.dat';
    tau=4e-3; f_s=26.0e6; f_if=6.5e6; IQ=0; sat=193; ctype=0; crate=1.023e6;
else % LEX
    file='../stereo_if_201206262032/lbrx_lex.dat';
    tau=4e-3; f_s=26.0e6; f_if=0.0e6; IQ=1; sat=193; ctype=19; crate=5.115e6;
end
ns=f_s*tau; ss=f_s*ts;
if IQ, ns=ns*2; ss=ss*2; end
fp=fopen(file,'rb');
fseek(fp,ss,'bof');
data=fread(fp,ns,'int8=>int8')';
fclose(fp);

dopp=-8e3:10:8e3;
for i=1:length(dopp)
    P(i,:)=corr(data,IQ,f_s,f_if+dopp(i),sat,ctype,crate);
end
[Pmax,i]=max(max(P'));
[Pmax,j]=max(max(P));
CN0=10*log10(Pmax/mean(P(i,[1:j-20,j+20:end]))/tau);

figure('color','w');
fn='Times New Roman';
axes('position',[0.1 0.08 0.84 0.87],'fontname',fn); hold on; box on;
plot(P(i,:)/Pmax,'.-');
xlim([1,size(P,2)]); xlabel('Code Offset (chip)'); ylabel('Normalized Power');
text(0.02,0.98,sprintf('C/N0=%.1fdBHz Doppler=%.3fKHz CodeOff=%d CorrMax=%.5f',...
     CN0,dopp(i)/1000,j,Pmax),'fontname',fn,'units','normalized','horizontal',...
     'left','vertical','top');

% correlator -------------------------------------------------------------------
function P=corr(data,IQ,f_s,freq,sat,ctype,crate)
n=length(data); if IQ, n=n/2; end

code=gencode(sat,ctype,0,crate/f_s,n);

x=2*pi*(0:n-1)*freq/f_s;
if IQ
    I=cos(x).*double(data(1:2:end))/n;
    Q=cos(x).*double(data(2:2:end))/n;
else
    I=cos(x).*double(data)/n;
    Q=sin(x).*double(data)/n;
end
P=abs(ifft(conj(fft(code)).*fft(complex(I,Q)))).^2;

-------------------------------------

ホントはこんなことやってる暇ないのだけど、Antcom + NSL Stereoで、L1+LEXのDIFデータを取って貰ったので、せっかくなのでIS-QZSS読んでQZSS LEXショートコードを生成するコード書いて、ちゃんと相関が取れるかだけ確認してみた。サンプリングは26MHz、3bit。IF周波数は0MHz。FFTで相関を取りドップラはサーチしている。コードは以前書いたmatlab。4 ms切り出しのタイミングをずらしながら最も相関電力が高くなる点を探している。ドップラの値もL1C/Aと整合的なので、一応相関とれている様だ (ドップラ計算そのものにはミスがあると思う)。同時に取っているQZSS L1C/AのC/N0が47dBHz位なので、それに比較してSNが約6dB位落ちている。ちょっとこれは大きすぎる気がするので原因調査中。しかしとりあえず信号確認するだけなら、SDR実装簡単だなあ (まあ、リアルタイム化はそんなに易しくはない)。

...................................................................................................................................

2012/06/26

SDRの実装が簡単ということはH/W実装も簡単ということ。1CH LEX航法データ復調専用受信機であれば小ゲートのFPGAでも十分実装できるのではないか。L1C/A追尾してれば、QZSSのalmanacも復調できるので、複数衛星構成になってもalmanacから衛星位置求めて条件の良い衛星に切り替えれば良い。結局、機能を限定すれば、凄く安く実装できるということで、(LEXのサービス次第だけど) 十分ビジネスにもなるのではないか。これ、どこかやりません? (もしかすると誰かもうやってる?)

-------------------------------------

QZSS LEX SDRの検討してるのは、単純に現在QZSS LEXの実験するのに受信機の調達がネックになっているから。SDRであればアンテナ+RFフロントエンドが\15万位で手に入る。一方、(新しいLEX受信機がいくらか知らないけど) 某メーカ製のLEX受信機は、\XXXX万と聞いているので (アンテナもTrimbleのZephyr Geodetic 2だと\30万位?) 。とりあえず1CHのLEX航法データだけ復調できれば良くて、かつフレームを1%くらい落としても補正精度は殆ど落ちないはずなので、普通のユーザにとっては高性能受信機は必要ないのである。ただ、10%フレーム落とすとさすがに補正精度に影響するはずなので、SDRが実用になるのかは評価してみないと分からないのだけど。

いずれにして、頑張って価値の高い補正情報を放送しても、受けて使うユーザがいなければ宝の持ち腐れになってしまうので安価な受信機の研究開発も重要。あと受信機も自作できれば、とても複雑なGNSS補強システムのうち、END-TO-ENDのかなりの部分を「ひとりで作れる」と言えるわけで技術者として満足感が高いし (さすがに衛星とか衛星地上局をひとりで作るのは無理だけど)。

...................................................................................................................................

2012/06/25

昨日書いたQZSS LEX SDRの件。C/Aコード位相基準だとやっぱり色々な誤差が載って1チップ 391 nsずれてしまうのがちょっと気になるけど、これって良く考えたら±1チップずれも含めて全部並行してデータ復調して同期とって、その中から正しいのを選んでもそれほど計算量は増えない。とすると、技術的にはあとはFFTの実行時間が間に合うかだけ。ということで最新のCPUで実行時間測ってみたいのだけど、以前使ったプログラムどこやったっけ。

補足: 以前書いたコードが見つかったので測ってみた。

tau= 1ms: ns=  16384 time=  0.4ms rate=2562.4corr/s
tau= 2ms: ns=  32768 time=  0.7ms rate=1400.6corr/s
tau= 4ms: ns=  65536 time=  1.7ms rate= 572.1corr/s
tau= 8ms: ns= 131072 time=  4.9ms rate= 204.0corr/s
tau=16ms: ns= 262144 time= 10.4ms rate=  95.8corr/s

(Core i7 2600K, with FFTW-3.3.2, windows 7, single precision)

FFTWは配布されているWindows用コンパイル済みのDLLを使用。CPUメータは27%までしか上がらないのでシングルスレッドしか動いていないと思う。少し厳しいが、FFTW 3.3.2の文書読んでみるとマルチスレッドやAVXに対応している様なので自分でコンパイルすればもう少し高速化できるかも。サンプリング周波数を16MHzにできれば、今のままでも楽勝だけどかなりゲインが落ちちゃうだろうなあ。ちなみにFFT以外の部分はSSE2とSSSE3使って高速化したコードなのであまり削り代はない。(11:11追記)

再補足: FFTWを自分でコンパイルして実行してみた。オプションはconfigure --enable-avx --enable-float --enable-openmp --enable-threads。

tau= 1ms: ns=  16384 time= 0.3ms rate=3225.8corr/s
tau= 2ms: ns=  32768 time= 0.6ms rate=1818.2corr/s
tau= 4ms: ns=  65536 time= 1.1ms rate= 885.0corr/s
tau= 8ms: ns= 131072 time= 3.8ms rate= 263.9corr/s
tau=16ms: ns= 262144 time= 8.1ms rate= 123.3corr/s

少し速くなった。ただ、openmp有効にしてもマルチスレッドで動いてないみたいだなあ。ちなみに以上の処理内容はmatlabで書くと

P=abs(ifft(conj(fft(code)).*fft(data.*exp(2*pi*freq*t*i)))).^2

ただしコードのFFTは事前に1回行えば良いので実行時間に含まれていない。(17:25追記)

以上大ざっぱな検討の結果、少し速いノートPCだったら行けそうなので少しやる気になってきた。いずれにしても、LEXの前に普通のL1のリアルタイムSDRが必要になる (1chで良くて航法データデコードもいらないけど) ので、途中まで実装して放ってあるコードを基に作業を進める予定。とりあえず今年度中に動くところまで行ければ、来年度のLEX実験に使えるかも。あと忘れてたけどRSのデコーダ実装しなければいけないので、これは追加で調べる必要がある。(18:26追記)

...................................................................................................................................

2012/06/23

昨日はG空間エキスポにちょっと参加。あんまり新しい話は無かったのだけど、JAXAのLEX-PPPデモで見慣れない小型LEX受信機を発見。なんかJAXAの人に聞いたら、市販RFフロントエンドとSDRでLEX追尾しているらしい。これ、頑張れば自作もできるということで、来年度の実験用にちょっと作ってみたいなあ。
なお、QZSS LEX信号の構造はL1 C/Aとはずいぶん違ってかなり特殊。L2Cみたいなロングコードとショートコードの時分割多重で、ショートコードを航法データでCSK (Code Shift Keying) 変調かけている。ロングコード長が410 msと長いのと週替わり時にロングコードをリセットしなければいけないので、L1 C/Aを同時受信して疎捕捉と受信機の時刻同期に使うのが良いのではないかと思う (個人的にはLEXのみで時刻が取れないのは信号設計の不備だと思う)。 ということで、実装は結構大変そうなのだけど。

補足: 基本変調はBPSK(5)なのでメインローブの帯域幅10MHz。RFフロントエンドとしてはMAXIM 2112を使った、NSLのSTEREO使えるのではないか。L1/E6対応のアンテナはAntcomから全バンド対応の小型アンテナが出ているのでこれを使えばよい。(もしかするとJAXAの構成もこの構成と同じ?) (6/24追記)

再補足: LEXショートコードはCSK変調されているから位相は4ms毎にランダムに変わる。従って、普通に実装すると、LEXロングコードを捕捉・追尾してその位相とショートコードの位相差から航法データを復調する必要がある。ただ、L1 C/Aコードを同時追尾してC/AコードとLEXショートコードの位相差からデータを復調できれば、LEXロングコード自身を追尾する必要もなく、処理は非常に簡単になる。
ちょっとこれを検討してみよう。まず、IS-QZSSによれば衛星送信時のL1コードとLEXコードの位相は35 ns以内に同期している。次に電離層。最大L1電離層遅延を100 mとして、電離層によるL1-LEXコード位相差は100 m × (1-f1^2/f6^2) = -51.8 m = -173 ns。アンテナ・受信機の群遅延は事前に20 ns以内に校正できるとする。以上で受信機におけるL1C/A-LEX間の最大コード位相同期誤差228 ns。ショートコードのチップレートは2.5575 Mcpsで1サイクル391 ns。CSK変調のBERってどうだせば良いのか良く分からないのだけど、実際の電離層遅延は通常これより1桁は低いから、例えばフレームドロップレートを1%まで許容すれば、L1 C/Aコード追尾だけでLEXショートコード復調は可能となりそうだ。まとめると、まずL1 C/Aを追尾してC/Aコード位相を取りだす。C/A航法データを復調すれば4ms区切りも識別できる。次に4msに区切ったLEX DIF信号とLEXショートコードの相関をFFTで取って、そのコード位相から8bitワードを復調する。あとはプリアンブル検索してフレーム同期をとってRS復号すれば良い。サンプリング24MHzとして4msのサンプル数は96000。131072点のFFTによる並列相関時間は以前FFTWで測った結果では7.6 ms (i7 730 シングルスレッド) まあ最近の計算機で1CHであれば4 msでなんとか行けるかなあという感じ。GPU使えばもう少し速いかも。ということで不可能ではなさそうだけど、実際に実装してまだ色々と検証が必要。ただ、なんとなく行ける気がするので、これ誰かやりません。(6/24追記)

再々補足: 以上の検討はLEXの擬似距離いらないという前提。実際LEXの擬似距離も搬送波位相も普通には使い道ないので、航法データだけ復調できれば十分。(6/24追記)

再々々補足: 最低LEXのドップラは追いかけなければいけないけど、これはL1のドップラは追いかけているので、これから導出することができるはず。もちろんL1, LEX用フロントエンドの基準クロックを共通にしなければいけない。結局L1C/Aだけ捕捉・追尾できれば、LEX側は、捕捉もPLLもDLLも必要ないということで、処理は非常に簡単。ロングコード使わないから週替わり時のコード不連続問題も対応する必要ない。あとは、特に条件の悪い所でどれくらいのエラーレートになるか。信号レベルの低い状態で実用になるかは、実際に評価してみないと良く分からない。(6/24追記)

再々々々補足: G空間EXPOの3日間での来場者数約18,000人だった様。一昨年の来場者数が約37,000だったらしいので約半分。少し盛り上がりに欠けていたという感じ? (6/24追記)

...................................................................................................................................

2012/06/21

J.Wang et al., Reliability of partial ambiguity fixing with multiple GNSS constellations, Journal of Geodesy, 2012

Partial fixingネタということで反射的に買った。EUR 34.95也。詳しくは後から読む。

...................................................................................................................................

2012/06/20

産経, 「可能性すら予想できない」役に立たなかった地震研究 科学技術白書, 2012年6月19日

最近、地震学の研究者の方の知り合いも増えてきたのでコメントしずらいのだけど、「役に立たなかった」と書かれてしまうと立場ないよなあ、とは思う。例えば日本地震学会では、昨年の地震を受けて今までの反省と今後の方向を「地震学の今を問う」という提言集にまとめている。これ全部読んだ訳ではないのだけど、学術研究と社会との関係性の点で色々と考えさせられることが多かった。

...................................................................................................................................

2012/06/10

宮川, 次世代GEONETの2つの挑戦 - GNSS対応と津波予測支援, 第41回 国土地理院報告会, 2012年6月1日

とりあえず貼っておく。

「リアルタイムデータを即時解析することで、精度は劣る (10 cm) ものの ...」というところが気になるところ。条件の悪い観測点やmiss-fixも入れて全点平均すると10 cm位になってしまうのかもしれないけど、世界では皆、リアルタイム精度 1 cmに「挑戦」している訳で。

-------------------------------------

IGS Workshop 2012, July 23-27, 2012, Olsztyn, Poland

ということで、7月のポーランド オルシュテイン IGS WSに登録した。今のところ発表はなしの予定なので、色々な方とゆっくりとお話だけしてこよう。

...................................................................................................................................

2012/06/06

G.Shrock, Feature: After RTK - Part 1, Professional Surveyor Magazine, 2012

3月のフランクフルト PPP-RTKシンポジウムが、結構細かい記事になっている。Part 1ということはPart 2もあるのかな。

...................................................................................................................................

2012/06/05

M.Caissy et al., Innovation: Comming Soon, GPS World, June 1, 2012

IGS (RTWG, RTPP) が長らく開発を続いていた、リアルタイムデータ・プロダクトが IGS-RTS (IGS real-time service) として7月のIGS WSに正式にローンチするとして、その背景、技術内容、精度、今後の拡張等について述べている。現状これらをサポートするユーザクライアントS/Wとして、BKG BNCとともにRTKLIBが上げられている。

補足: 記事を良く読んだらローンチは2012年後半で、7月のIGS WGで正式日を決めるとのこと。(6/6追記)

-------------------------------------

JAXA, 準天頂衛星「みちびき」のルビジウム原子時計の冗長系切り替えと測位信号提供の一時中断について, 平成24年6月4日

一応貼っておく。逆に1機目のルビジウムが故障してないことが確認された訳で、これは良いニュース。

-------------------------------------

DataGrid Inc. GNSS Navigation Systems

地理院の報告書で知った米GNSS受信機ベンチャDataGrid社。報告書にはGPS受信機OEMボード価格$700-800と書いてあるけど、使い物になるのかな。興味が出てきたのでちょっと調べてみよう。

> DataGrid 社の受信機によって、商品を実現するためにカスタムASIC が必ずしも必要
> ではないことが証明されたことになり、資金は潤沢ではないが、技術力やアイデアが豊富
> にあるベンチャー企業や研究者にとって、市場参入も夢ではなくなりつつあることが実感
> できるのではないだろうか。

なんて書いてあるけど、FPGA + DSPで、ASICに対抗する性能が本当に出るのかはちょっと疑問。既存受信機メーカが時間と金と人をかけて蓄積してきたノウハウに追いつくのもそんなに易しくはない。ただ、2周波GNSS受信機価格が高止まりしている現状はビジネスチャンスとも言えるので、日本でも活きのいいベンチャが挑戦してくれることを望む。

-------------------------------------

u-blox, Introducing u-blox 7, the world's lowest-power multi-GNSS platform, June 4, 2012

u-blox 7 出たよ。GPS, GLONASS, QZSS対応、Galileo and Compass ready。これの-T版の10Hzモジュールが出れば、低価格マルチGNSS RTK用モジュールの本命だと思っているのだけど。データシート見ると航法解10Hzまで対応している様で期待大。LEA-5Hの最初の様にひそかにraw出たりしないだろうか。

-------------------------------------

国土地理院, 高度な国土管理のための複数の衛星測位システム (マルチGNSS) による高精度測位技術の開発

地理院 マルチGNSS総プロの昨年度報告書や委員会議事録が公開されているのを見付けた。これ凄いなあ。全部公開なんだ。マルチGNSS総プロとは何かは、第1回委員会の説明資料が分かりやすい。

補足: 「平成23年度マルチGNSS解析技術等の開発に向けたマルチGNSS解析システムの基本設計業務」基本設計書 の中身見るとなんか既視感のある記述が多い。別にパクッてってもよいのだけどできれば出典を入れて欲しい。なおこの資料の別紙1の9割以上はRTKLIB 2.4.1の中身を解析してフローチャートにまとめたものなので、RTKLIBの中身をいじりたい人には参考になるでしょう。RTKLIBじゃなくてBerneseでこれやってくれると私としては参考になるのだけど。(8:39追記)

...................................................................................................................................

2012/06/02

J-M. Sleewaegen, et al., Demystifying GLONASS Ineter-Frequency Carrier Phase Biases, InsideGNSS, 2012

GLONASS inter-frequency-carrier-phase biasの由来について説明している。これによるとRFアナログフィルタの周波数依存性は非常に小さく、その影響はmm以下で、バイアス差のほとんどは後段のデジタル (DSP) 処理で発生しているとのこと。従ってバイアス差の温度依存性や長期変動は考えなくてよいらしい。でもこれが本当なら、設計時に1回キャリブレーションしてF/Wで全受信機同一の値で補正すればいいだけのはずだけど、なんで各受信機メーカはやってないんだろう。またJAVADのspecial patent-pendeding-hardwareによるreal-time calibrationっていったい何やっているの? ということでこれ本当? という気もするんだけど、まあGLONASS IFBについては今色々な人が追試もしている様なのでその結果を待ちたい。えっ、自分でやらなきゃいけなくなるかもって...。

補足: Googleで検索してたらJAVADのpatent見つけた (goolge patent search)。昨年9月に既に特許は成立している様。図だけ見るとchannel-calibration moduleからダウンコンバータにフィードバックがかかっているので、この辺がspecial-hardwareなのだろう。ちょっと中身読む気にならないのだけど誰か読んで解説してくれないだろうか。(7:55追記)

...................................................................................................................................

2012/06/01

いつのまにか6月だあ。

...................................................................................................................................

〜2012/05/31