Help with tuning RFX2400 MIMO_b, weird RX results

Hi all,

First, I’m sorry if my actions are shunned upon (C++ daughterboard code
outside the mainstream repository), but I could sincerely use help with
a deadline approaching next week.

I am trying to use code that Per started for tuning a MIMO_b RFX card in
C++. Using the base code he gave me, I was able to get the transmitter
working bot not receiver.

I am trying to receive a GMSK transmission.

Here is a normal reception after tuning the card in python:
http://cyprus.cmcl.cs.cmu.edu/tmp/flex_graphs/gmsk_regular.jpg
http://cyprus.cmcl.cs.cmu.edu/tmp/flex_graphs/gmsk_regular_rvi.jpg

… we get a nice clean circular transmission.

When I attempt to receive using the C++ RX code, that I modified to set
the RX gain, I get the following square-like transmission:
http://cyprus.cmcl.cs.cmu.edu/tmp/flex_graphs/gmsk_flex.jpg
http://cyprus.cmcl.cs.cmu.edu/tmp/flex_graphs/gmsk_flex_rvi.jpg

Based on these results, does anyone have any insight in to what I may be
tuning incorrectly? I thought it might be the gain setting, but I
mimiced the set_gain() method exactly with the python code and ensure
the write_aux_dac() and set_pga() values are the same:
https://moo.cmcl.cs.cmu.edu/trac/cmu_sdrg/browser/dboard_code/db_flexrf_mimo.cc#L193

To tune the cards, I am using:
db_flexrf_mimo dboards(d_urx, d_utx, 0);
dboards.configure(d_rf_freq, 45, 0);
dboards.configure(d_rf_freq, 0, 1);
dboards.select_tx();

I followed through almost every function call and I can’t seem to find
the different in tuning between my code and the python.

I’d greatly appreciate any insight.

Thanks!
George

On Tue, Apr 29, 2008 at 01:55:33AM -0400, George N. wrote:

Hi all,

First, I’m sorry if my actions are shunned upon (C++ daughterboard code
outside the mainstream repository), but I could sincerely use help with a
deadline approaching next week.

You’re not being shunned :slight_smile:

Stating the obvious, it would be great to have 1 complete
implementation of the C++ daughterboard code, rather than N partial
implementations.

Eric

You’re not being shunned :slight_smile:

Stating the obvious, it would be great to have 1 complete
implementation of the C++ daughterboard code, rather than N partial
implementations.

Hopefully once I get passed my May madness I can work with Michael on
this.

Does it look like I am clipping? I am not changing the transmitter
between the two dumps. I figured the rx gain was too high but it seems
to be being set correctly.

  • George

I’m getting a little closer…
http://cyprus.cmcl.cs.cmu.edu/tmp/flex_graphs/closer.jpg

it looks like I’m clipping a little bit, and is that “wide circle”
effect a result of DC offset?

  • George

Yeah, looks better but still some offset on the I rail. The wideness of
the ring could be ISI(whats your BT?) in concert with carrier mismatch
spin if you are using two boards. The only reason I say this is that
the width does not look to be very noise like. Just a guess of course.
:slight_smile:

-Jeff

So, I am finally able to decode something after setting the correct RX
mux… I suppose it was incorrect for this daughterboard.

Does the RX2 port need to be enabled for the RX/TX port on the card to
receive properly?

If I setup the RX as follows…
d_rx->_write_oe(d_side,POWER_UP|RX2_RX1N|ENABLE,0xffff);
d_rx->write_io(d_side,(~POWER_UP)|RX2_RX1N|ENABLE,POWER_UP|RX2_RX1N|ENABLE);
d_rx->write_io(d_side,0,RX2_RX1N);
d_tx->write_io(d_side,~RX_TXN,RX_TXN);

…what I receive looks like this:
http://cyprus.cmcl.cs.cmu.edu/tmp/flex_graphs/flex_rx2dis.jpg

If I enable RX port 2 also, such that I only add this line…
d_rx->write_io(d_side,RX2_RX1N,RX2_RX1N);

… what I receive looks like this:
http://cyprus.cmcl.cs.cmu.edu/tmp/flex_graphs/flex_rx2en.jpg

… and I am now able to get pretty accurate decoding.

But, I was simply wondering if someone can provide insight in to why
this is. Does RX2 need to be enabled?

Thanks,
George

Kind of looks like it is clipping to me and possibly some DC offset
problems.

-Jeff

George:

The flattened ellipsoid is in the eye of the beholder. ;-). It isn’t
really. It is the aspect ratio of your gnuplot. You are clipped and it
appears there is a slight DC bias on the I channel to plus DC (pushed
slightly to the right).

Bob

George N. wrote:

Kind of looks like it is clipping to me and possibly some DC offset
RX results
on this.
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

9999

Hi Bob!

Right, when I side “wide circle”, i didn’t mean flat, i meant that the
circle seemed thick… as if there is a large variation in amplitude.

my newest graph seems a little better:
http://cyprus.cmcl.cs.cmu.edu/tmp/flex_graphs/flex_rx2en.jpg

Thanks,
George

And finally, here we have it:
http://cyprus.cmcl.cs.cmu.edu/tmp/new_flex/success.jpg

I didn’t completely understand the 2 stages of tuning… I had the first
stage down pat, but didn’t understand the second, hence everything kind
of breaking once i tried it, and things not working until i got it right
:slight_smile:

Thanks for all the help! I certainly learned a bit about tuning the
boards.

  • George

OK, this is my last cry for help… I’m hoping you have an idea of what
I’m tuning wrong, Matt.

I have added print statements for every single _write_fpga_reg, pga_set,
_write_spi, _write_io, _write_oe, etc… and I compare the function
calls by a standard python RFX2400 MIMO_b tune with my C++ tuning code.

Everything that I see is mimicked exactly… but that doesn’t
necessarily mean I see everything :wink:

The only thing that doesn’t match up, that I cannot understand, is that
when I call d_rx->set_rx/tx_freq(0, -4e6) (which is what the python
code does) … everything goes down hill. After calling set_tx_freq()
my transmitter breaks (which works otherwise).

After calling set_rx_freq(), my receiver becomes even more broken and my
incoming signal looks like this:
http://cyprus.cmcl.cs.cmu.edu/tmp/new_flex/set_rx_freq.jpg

If I do not call set_rx_freq(), my incoming signal looks like this:
http://cyprus.cmcl.cs.cmu.edu/tmp/new_flex/no_set_rx_freq.jpg

I’ve dug into these function calls and the values are set the same in
both cases.

If I enable RX2, I see this on my RX/TX:
http://cyprus.cmcl.cs.cmu.edu/tmp/new_flex/gmsk_ivq_flex.jpg

Using a python tuned board, I see this:
http://cyprus.cmcl.cs.cmu.edu/tmp/new_flex/gmsk_ivq_regular.jpg

Major difference.

I’d sincerely appreciate any feedback.

Thanks!
George

George N. wrote:

And finally, here we have it:
http://cyprus.cmcl.cs.cmu.edu/tmp/new_flex/success.jpg

I didn’t completely understand the 2 stages of tuning… I had the first
stage down pat, but didn’t understand the second, hence everything kind
of breaking once i tried it, and things not working until i got it right :slight_smile:

Thanks for all the help! I certainly learned a bit about tuning the
boards.

George,

Please post a summary of the problem and its solution to the list
so others can benefit from your experience.

@(^.^)@ Ed

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs