Forum: GNU Radio RFX 2400 transmit-receive turnaround

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
62602f78a99b0dd9599cdae69c489417?d=identicon&s=25 Bob Vincent (Guest)
on 2006-05-11 16:06
(Received via mailing list)
We've been doing some testing on the RFX, and have found that delaying
between packets sometimes causes receive errors. I suspect it may have
to
do with the transmit/receive turnaround. Do you have any information on
the
design of the RFX that might help me diagnose the source of the problem?
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2006-05-11 17:39
(Received via mailing list)
On Thu, May 11, 2006 at 10:03:05AM -0400, Bob Vincent wrote:
> We've been doing some testing on the RFX, and have found that delaying
> between packets sometimes causes receive errors. I suspect it may have to
> do with the transmit/receive turnaround. Do you have any information on the
> design of the RFX that might help me diagnose the source of the problem?

Bob,

If you're not kludging up the padding to ensure that the output of the
sample stream for a given frame is a multiple of 128 complex samples
(512 byte USB packet), the tail of the frame may not be getting
across the USB.

Do you see this with the gmsk2 code and/or psk?  The gmsk code has the
proper alignment kludge.  [ We *really* do need that m-block stuff ;) ]

Can you reproduce the problem with benchmark_gmsk_{tx,rx}?
If you haven't already, please try the --discontinuous option to tx.

Eric
62602f78a99b0dd9599cdae69c489417?d=identicon&s=25 Bob Vincent (Guest)
on 2006-05-11 19:22
(Received via mailing list)
At 11:37 AM 5/11/2006, Eric Blossom wrote:
>sample stream for a given frame is a multiple of 128 complex samples
>(512 byte USB packet), the tail of the frame may not be getting
>across the USB.
>
>Do you see this with the gmsk2 code and/or psk?  The gmsk code has the
>proper alignment kludge.  [ We *really* do need that m-block stuff ;) ]

gmsk2 under the tunnel_ip_null_mac.py.

I haven't made much headway on psk yet, because the receive gets an
error
about 2 times in 3.
python: gri_mmse_fir_interpolator_cc.cc:66: gr_complex
gri_mmse_fir_interpolator_cc::interpolate(const gr_complex*, float):
Assertion `imu >= 0' failed.

If it runs for a while, it eventually gets :
python: gr_dd_mpsk_sync_cc.cc:191: virtual int
gr_dd_mpsk_sync_cc::general_work(int, gr_vector_int&,
gr_vector_const_void_star&, gr_vector_void_star&): Assertion `ii <=
ninput_items[0]' failed.

I think I may be parameterizing the interpolator (costas_gain, gain_mu)
incorrectly. I'm a little stumped by the effects of changing these right
now. If you could point me at a reference it might help.


>Can you reproduce the problem with benchmark_gmsk_{tx,rx}?
>If you haven't already, please try the --discontinuous option to tx.
>
>Eric
Yes. I'm running with around 40 dB of headroom, and I see some dropped
bits
on the first packet of the burst around 1 time in 5.
This topic is locked and can not be replied to.