Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: N210 w/ UBX Bursting Issue (Dave NotTelling)
----------------------------------------------------------------------
Message: 1
Date: Sat, 23 Apr 2016 20:11:40 -0400
From: Dave NotTelling <[email protected]>
To: Nate Temple <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] N210 w/ UBX Bursting Issue
Message-ID:
<CAK6GVuNedU6tn2KS7hc6ema-OXWK=uswtnd8yvo1peeod9h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Nate,
I will attempt to get them to you tomorrow. I don't currently have
access to the system with all the testing code. Thank you for the reply!
-Dave
On Fri, Apr 22, 2016 at 8:06 PM, Nate Temple <[email protected]> wrote:
> Hi Dave,
>
> Could you please send me the flowgraphs and any OOTs / modules / frame
> synchronizer / code for this issue? Could you also send any instructions
> you can put together on the process of running them to recreate this issue?
> (Gains, freq, etc?)
>
> I will be at the office this next week and will have access to a N series
> + UBX-40, and X310 + UBX-160, and I will test them to try and recreate this
> issue.
>
> - Nate
>
>
>
> > On Apr 21, 2016, at 6:51 PM, Dave NotTelling via USRP-users <
> [email protected]> wrote:
> >
> > I am working on creating an app that transmits very short bursts (< 100
> bytes) very rapidly over a range of frequencies (FHSS). In order to
> accomplish the bursting I am using tx_time and tx_freq. The SOB and EOB
> values are being calculated automatically by the UHD library since I have a
> length tag. What I am seeing is that after a period of time (varies
> heavily) the data frame being sent will not correlate with the frequency.
> If 0x123456 was to be transmitted on freq1 and 0x789012 to be transmittedon
> freq2 then what I will see is 0x123456 on freq2.
> >
> > I have an example attached to this message. The file (when unzipped)
> contains binary data. It is the output of the demodulator piped through a
> frame synchronizer I wrote. Two signals are transmitted at 5 MHz apart.
> The actual space between them is something around 3 MHz. I have a low pass
> filter that selects just the 1 MHz of spectrum I need to capture one of the
> signals for demodulation. One signal is transmitting: [0x00, 0xff, 0xaa,
> 0xaa, 0x00, 0x00, 0x7e, 0x7e, 121, 239, 87, 19, 23, 101, 69, 9, 187, 6, 18,
> 222, 173, 191, 180, 11, 232, 135, 250, 159, 167, 212, 215, 138, 76, 12] and
> the other is transmitting [0x00, 0xff, 0xaa, 0xaa, 0xff, 0xff, 105, 42,
> 121, 239, 87, 19, 23, 101, 69, 9, 187, 6, 18, 222, 173, 191, 180, 11, 232,
> 135, 250, 159, 167, 212, 215, 138, 76, 12]. The last 8 bytes of both are
> actually replaced with the current time in microseconds in order to
> synchronize both signals. The attached file contains just one of those
> signals (the first one). Both patterns are almost identical except for the
> 4-7th (0-based) bytes. This was intentional so that it would be easy to
> see that the demod is working correctly and that the issue is not with the
> actual demod steps.
> >
> > Anywho, the file starts off well with the correct bit pattern showing up
> (000000001111111110101010101010100000000000000000011111100111111001111001111011110101011100010011000101110110010101000101000010011011101100000110000100101101111010101101101111111011010000001011111010001000011100000000000001010011000100001000010101110010000011100101101000)
> remembering that the last 64 bits are a timestamp and change on each
> frame. If it's of any use, the time stamps should be something on the
> order of 5 milliseconds apart. At frame number 8614 you can see that the
> pattern has changed to what the other channel is sending
> (000000001111111110101010101010101111111111111111011010010010101001111001111011110101011100010011000101110110010101000101000010011011101100000110000100101101111010101101101111111011010000001011111010001000011100000000000001010011000100001000010111010000101000010110111010).
> This happens again at 9745, 11619, 16219, 16376, 19266, 28360, and lots
> more.
> >
> > The farther you get in the file the worse things get. But, it's no
> longer an issue of the other channels data getting through, but now the
> bits are getting cut off. You'll notice that around line 39670 things
> start to get cut off bad. There are lots of ones because I am using a
> squelch to only let the bursts through which yields a much better demod.
> By around line 61583 things have seriously deteriorated. It gets worse
> from there until line 81697 where I restarted the modulation graph. Now
> things look peachy again. But, you can see that right off the bat the data
> from the other channel is now in this channel.
> >
> > At the end of the file I was stopping and starting the modulator just to
> see if I always got data from the other channel when the modulator was
> starting.
> >
> > At no point in this file did I get any errors. No underflows,
> overflows, lates, etc.
> >
> > So, it appears as though either the tx_freq tag or the vector is getting
> munged somewhere before making it out of the transmitter.
> >
> > I discovered this oddity when my receiver was suddenly losing sync even
> though I was still transmitting. For a test I pointed my demod to a FIFO
> and ran it through the frame sync tool to see the bits live and found that
> the data on channel X was the data that should be on channel Y. Sometimes
> it takes several minutes to swap over. It's really inconsistent.
> >
> > If anyone from Ettus would like the flow graph and custom modules I'd be
> happy to send them. They are not in a way that I'd like to publicly
> release them at the moment though.
> >
> > Oh, and I have had this issue with 3.9.2 and 3.10 (what's in the Git
> repo as of today). 3.9.3 has issues with my X310 not doing simultaneous RX
> and TX. I am using an N210 with the UBX-40 for transmission and the X310
> with UBX-160 for reception. I have tried connecting the two directly
> together with 60 dB worth of attenuators and just over the air with the
> antennas inches apart. The X310 is hooked up to an Intel X710 10Gb NIC
> using 10Gb direct attach copper cables. The N210 is hooked up to my
> motherboard's 1 Gb NIC. The CPU load was stable at around 1/8th total
> capacity. Nothing else was going on while the test was running.
> >
> > My GNU Radio version is 885b5a75 (fresh install from Git this morning)
> >
> > Thank you!
> >
> > (I've included the actual file as well as a link to my Google Drive
> account in case the attachment gets stripped)
> >
> > ?
> > uhd_error.txt.gz
> > ?
> > <uhd_error.txt.gz>_______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160423/b5181e5b/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 68, Issue 25
******************************************
