Questions for 150/400MHz beacon RX development


#1

Thank you for your kind help to my questions.
I am developing a satellite beacon receiver of
150/400MHz. Now I am receiving both signals by
using Basic RX (150MHz) and FLEX400 (400MHz) boards.
I am happy so far.

I have some more questions for further development.

(1) File format
I record signals into files. I want to read them
for analysis. What is the data format written/read
by file_sink() / file_source()? I am recording
complex signals in the files.

(2) “O” “U” “u” “a”
These characters appear on the screen when I run
my program. I understand they appear when data flow
from USRP to PC is stopped or something. I am curious
what are the meaning of these characters. Does faster
PC help reducing such data flow troubles?

(3) Signal coherence … (a)
I need to keep signal coherence between 150MHz and 400MHz.
I should run the FLEX400 board at the same timing to the
USRP main board. I found the following information URL
http://comsec.com/wiki?USRPClockingNotes
Is this instruction still valid? I am using USRP ver4.

(4) Signal coherence … (b)
I have one more question on the signal coherence. In my
program I keep the same sample speed and the same FIR filter
for both 150MHz and 400MHz. (Sure I am using a “deinterleaver”
to separate the signals.) Can you guarantee signal coherence
in the GNUradio data flow?

Regards,


Mamoru Y. removed_email_address@domain.invalid


#2

On Wed, Jan 10, 2007 at 02:52:54AM +0900, Mamoru Y. wrote:

for analysis. What is the data format written/read
by file_sink() / file_source()? I am recording
complex signals in the files.

They are binary files in “native endian”.
If you’re writing gr_complex, the file will contain interleaved
real, imaginary values where the real and imaginary components are
32-bit binary floats.

FYI, there’s code to read these files into Octave or Matlab in
gnuradio-core/src/utils/read_*_binary.m

(2) “O” “U” “u” “a”
These characters appear on the screen when I run
my program. I understand they appear when data flow
from USRP to PC is stopped or something. I am curious
what are the meaning of these characters. Does faster
PC help reducing such data flow troubles?

“u” = USRP
“a” = audio (sound card)
“O” = overrun (PC not keeping up with received data from usrp or audio
card)
“U” = underrun (PC not providing data quickly enough)

Yes, a faster machine will generally cure this problem. This assumes
that you’re not asking the USB to do something that it can’t. In our
best case, we sustain 32MB/s across the USB. I suggest avoiding intel
celeron or other “cache crippled” parts.

(3) Signal coherence … (a)
I need to keep signal coherence between 150MHz and 400MHz.
I should run the FLEX400 board at the same timing to the
USRP main board. I found the following information URL
http://comsec.com/wiki?USRPClockingNotes
Is this instruction still valid? I am using USRP ver4.

I believe this is still valid. Matt, can you confirm?

(4) Signal coherence … (b)
I have one more question on the signal coherence. In my
program I keep the same sample speed and the same FIR filter
for both 150MHz and 400MHz. (Sure I am using a “deinterleaver”
to separate the signals.) Can you guarantee signal coherence
in the GNUradio data flow?

Yes you can. The important thing to keep in mind is that if there are
different filters in the two paths downstream from the deinterleaver,
they should have the same group delay through them. In the common
case, you can ensure this by using the same number of taps in each.
It sounds like you are doing this, so you should be OK.

Good luck!
Eric


#3

The RFX400_MIMO_B will do what you want. You can find out what version
you have by running print-db in the usrp/host/apps directory. If you
have the plain RFX400, you can modify it to the MIMO_B version by moving
some resistors.

The early RFX400’s sold were the regular version, but all shipping
recently are the MIMO_B version.

Matt


#4

Matt,

Thank you for your reply. My USRP board is Serial No. 750 or something.
This I bought in June 2006, and would match the following, I suppose.

===
To modify these boards for coherent applications if you have USRP rev 4
boards:
Move R64 to R84, Move R142 to R153

usrp/host/apps/burn-db-eeprom -A -t flex_400_mimo_b --force

Is this correct? I would like to know where the “flex_400_mimo_b”
file exists in the LINUX. I tried to find it, but failed.
(I found “usrp/host/apps/burn-db-eeprom” itslef.)

Regards,

Mamoru Y.


#5

Mamoru Y. wrote:

===

Is this correct? I would like to know where the “flex_400_mimo_b”
file exists in the LINUX. I tried to find it, but failed.
(I found “usrp/host/apps/burn-db-eeprom” itslef.)

Yes, that is correct. The name of the daughterboard has changed to
“rfx400_mimo_b”, but everything else is still the same.

Matt