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?
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
At 11:37 AM 5/11/2006, Eric B. 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.