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: Is there a file converter available for FC32 to SC16
conversion? (Paul Garver)
2. Re: SDR for atomic clock and oscillator metrology (Matt Ettus)
3. Re: How to set the number output on rfnoc_splitstream block?
(Luong Tan Phong)
4. Re: How to set the number output on rfnoc_splitstream block?
(Sylvain Munaut)
5. Re: gr-ettus RFNoC 1024 Bin FFT Limit? (Dave NotTelling)
----------------------------------------------------------------------
Message: 1
Date: Fri, 3 Jun 2016 11:26:58 -0500
From: Paul Garver <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Is there a file converter available for FC32
to SC16 conversion?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Craig,
Alternatively, you may find gr_fileman in gr-analysis useful for this.
Internally it does just what Marcus suggests but also preserves metadata and
you can also select a subset of the data by sample index or time
(w/interpolated timestamps).
https://github.com/garverp/gr-analysis <https://github.com/garverp/gr-analysis>
PWG
>
>
> From: "Swanson, Craig" <[email protected]
> <mailto:[email protected]>>
> Subject: Re: [USRP-users] Is there a file converter available for FC32 to
> SC16 conversion?
> Date: June 3, 2016 at 9:47:03 AM CDT
> To: Marcus M?ller <[email protected] <mailto:[email protected]>>
> Cc: Martin Braun <[email protected] <mailto:[email protected]>>,
> Jonathon Pendlum <[email protected]
> <mailto:[email protected]>>, "[email protected]
> <mailto:[email protected]>" <[email protected]
> <mailto:[email protected]>>
>
>
> Marcus,
> This flowgraph I am attaching to this email shows that I am adding a Multiply
> Const block with a value of 32767 (7FFF) and this works for my Modelsim
> simulation.
> Craig
> <image001.png>
>
> Craig F. Swanson
> Research Engineer II
> Information and Communications Laboratory
> Communications, Systems, and Spectrum Division
> Georgia Tech Research Institute
> Room 560
> 250 14th Street NW
> Atlanta, GA 30318
> Cell: 770-298-9156
> http://www.gtri.gatech.edu <http://www.gtri.gatech.edu/>
>
> From: Marcus M?ller [mailto:[email protected]
> <mailto:[email protected]>]
> Sent: Friday, June 03, 2016 10:26 AM
> To: Swanson, Craig <[email protected]
> <mailto:[email protected]>>
> Cc: Martin Braun <[email protected] <mailto:[email protected]>>;
> Jonathon Pendlum <[email protected]
> <mailto:[email protected]>>; [email protected]
> <mailto:[email protected]>
> Subject: Re: Is there a file converter available for FC32 to SC16 conversion?
>
> Did you use the float to short, or the complex to ishort block?
> The float to short block has a scaling factor (as said, use 2**15 there), the
> complex to ishort one doesn't have one (you've probably noticed).
> Two potential solutions:
>
> 1. just add a multiply_const before the complex to ishort
> 2. use the short to complex block with a vector size of 2 (complexes are
> really just pairs of floats... To be honest, I'm not 100% sure why the
> complex-to-ishort still exists, when I think about it. the float_to_short
> block does everything right, has a scaling factor, and should be measurably
> faster thanks to VOLK)
>
> Best regards,
> Marcus
>
> On 03.06.2016 15:38, Swanson, Craig wrote:
> Marcus,
> I generated a square wave and when I compared the FC32 verses SC16, I am
> getting a scaling issue.
> It oscillates between
> 0: FC32 is 00000000 and SC16 is 0000
> 1: FC32 is 3F800000 and SC16 is 0001
>
> I was expecting
> 0: FC32 is 00000000 and SC16 is 0000
> 1: FC32 is 3F800000 and SC16 is 7FFF? <----
>
> Craig
>
>
>
> Craig F. Swanson
> Research Engineer II
> Information and Communications Laboratory
> Communications, Systems, and Spectrum Division
> Georgia Tech Research Institute
> Room 560
> 250 14th St NW
> Atlanta, GA 30318
> Cell: 770.298.9156
> http://www.gtri.gatech.edu <http://www.gtri.gatech.edu/>
>
> From: Marcus M?ller <[email protected]>
> <mailto:[email protected]>
> Sent: Thursday, June 2, 2016 3:04 PM
> To: Swanson, Craig; Martin Braun
> Cc: Jonathon Pendlum; [email protected]
> <mailto:[email protected]>
> Subject: Re: Is there a file converter available for FC32 to SC16 conversion?
>
> Blue is complex, so use Complex To IShort instead of Float to Short.
>
> On 02.06.2016 21:03, Swanson, Craig wrote:
> ?Marcus,
> I want to send the complex SC16 data onto the i_tdata bus in my noc_block for
> simulation in Modelsim using a python cocotb testbench I have written.
>
> How do I merge that in with my flowgraph? I am trying to work through the
> CPU to Over the Wire translation issue for RFNoC simulations.
> <image002.png>
> Craig
>
>
> Craig F. Swanson
> Research Engineer II
> Information and Communications Laboratory
> Communications, Systems, and Spectrum Division
> Georgia Tech Research Institute
> Room 560
> 250 14th St NW
> Atlanta, GA 30318
> Cell: 770.298.9156
> http://www.gtri.gatech.edu <http://www.gtri.gatech.edu/>
>
> From: Marcus M?ller <[email protected]>
> <mailto:[email protected]>
> Sent: Thursday, June 2, 2016 2:53 PM
> To: Swanson, Craig; Martin Braun
> Cc: Jonathon Pendlum; [email protected]
> <mailto:[email protected]>
> Subject: Re: Is there a file converter available for FC32 to SC16 conversion?
>
> Hi Craig,
> for the sake of simplicity, I'd just use GNU Radio itself:
>
> <image003.png>
>
> You could of course also just insert the Float To Short block (or if you've
> got complex data, Complex To IShort) in your original GNU Radio application
> befor that writes things to a file.
>
> Best regards,
> Marcus
>
> On 02.06.2016 20:47, Swanson, Craig wrote:
> Martin and Marcus,
> In referencing http://files.ettus.com/manual/page_converters.html
> <http://files.ettus.com/manual/page_converters.html>, I believe I need a
> sc16_item32_le converter.
> I want to take a data file that is generated by gnuradio in FC32 format and
> generate an SC16 format file for simulation in Modelsim.
> Craig
>
> Craig F. Swanson
> Research Engineer II
> Information and Communications Laboratory
> Communications, Systems, and Spectrum Division
> Georgia Tech Research Institute
> Room 560
> 250 14th St NW
> Atlanta, GA 30318
> Cell: 770.298.9156
> http://www.gtri.gatech.edu <http://www.gtri.gatech.edu/>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160603/991230a3/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 3 Jun 2016 10:59:41 -0700
From: Matt Ettus <[email protected]>
To: "Sherman, Jeffrey A. (Fed)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] SDR for atomic clock and oscillator
metrology
Message-ID:
<CAN=1kn_fTu9V5BmzVDjzCunoANrgk=OU8OizZz=7v92ehkl...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Jeff,
Thanks for posting this. I am always proud to see people doing real science
with USRPs. If you haven't already posted it there, I think there would be
a lot of interest in this on the time-nuts mailing list:
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Thanks,
Matt
On Tue, May 24, 2016 at 9:54 AM, Sherman, Jeffrey A. (Fed) via USRP-users <
[email protected]> wrote:
> Hello,
>
> A paper has just been published which may be of interest to the SDR and
> USRP communities. We studied how well an unmodified USRP device/firmware
> could serve as an ultra-high precision measurement device, suitable for
> comparing high-performance oscillators and atomic clocks.
>
> I understand that for one month, the journal allows for free electronic
> downloads of the manuscript at:
> http://scitation.aip.org/content/aip/journal/rsi/87/5/10.1063/1.4950898
> (Review of Scientific Instruments 87, 054711 (2016))
>
> Afterwards, a preprint will remain available at:
> http://arxiv.org/abs/1605.03505
>
> Our use-case differs somewhat from typical SDR applications; I'll
> summarize the situation briefly here. We must measure waveforms at a few,
> relatively low frequencies common among commercial atomic clocks: 5 MHz, 10
> MHz, 100 MHz. Phase measurement at the few-microradian level is equivalent
> to a "clock time resolution" of order 0.1 ps, an adequate target for
> conventional microwave clocks. Measurement of optical atomic clocks will
> typically require sampling within a larger continuous range, ~1 MHz to 500
> MHz, though we can suffer a much worse absolute phase measurement because
> much of the optical frequency is first subtracted by a heterodyne
> interferometer technique (the femtosecond laser frequency comb).
>
> We rely utterly on an SDR's filter- and frequency-accuracy, and instrument
> stability. Clock comparisons can last many thousands of seconds, so
> white-noise sources (like quantization noise) are easily averaged away, but
> we remain sensitive to things like environmental coupling and systematic
> errors. This aspect means we are likely to prefer SDR schemes with direct
> input sampling by an ADC, that is, without a "mixer front-end" or
> complicated coupling method. Additional design attention might be
> worthwhile for the input signal traces, board and component temperature
> stability, and PCB material. Also, there is a tremendous advantage in
> simultaneously-sampled multi-channel ADC chips: the "aperture jitter" is a
> non-stationary noise source that appears to be highly common-mode between
> channels, therefore canceling in subtraction.
>
> Finally, many thanks to this USRP discussion list, the archive of which
> helped me, a total SDR novice, to solve technical problems while getting
> the experiments running.
>
> Best wishes,
> Jeff Sherman, Ph.D.
> --------------------------------------------------------------------
> National Institute of Standards & Technology
> Time and Frequency Division (688)
> 325 Broadway / Boulder, CO 80305 / 303-497-3511 <%20303-497-3511>
>
>
> _______________________________________________
> 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/20160603/c26172cf/attachment-0001.html>
------------------------------
Message: 3
Date: Sat, 4 Jun 2016 09:35:59 +0700
From: Luong Tan Phong <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] How to set the number output on
rfnoc_splitstream block?
Message-ID:
<CAA8YXsqiv5ufu92mCpunr=md_zmar_pv6opexrni0s52y96...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Jonathon,
I've tried to adding 2 outputs into
"host/include/uhd/rfnoc/blocks/splitstream.xml" file, build, install and
run but the result are the same.
thread[thread-per-block[0]: <block uhd_rfnoc_SplitStream (1)>]:
LookupError: IndexError: multi_usrp: RX channel 2 out of range for
configured RX frontends
Could you help me, please?
Phong
On Fri, Jun 3, 2016 at 9:27 PM, Jonathon Pendlum <[email protected]
> wrote:
> Hi,
>
> Try adding the additional source ports to the block's NoC Script file at
> "host/include/uhd/rfnoc/blocks/splitstream.xml". By default it is
> configured for two source ports whereas you need four.
>
>
>
> Jonathon
>
> On Wed, Jun 1, 2016 at 10:14 PM, Luong Tan Phong via USRP-users <
> [email protected]> wrote:
>
>> Dear List,
>>
>> I've modify the noc_block_split_stream.v with 4 outputs and write grc
>> block for it. I?ve tested on X310 but it didn't work with error:
>>
>> thread[thread-per-block[0]: <block uhd_rfnoc_SplitStream (1)>]:
>> LookupError: IndexError: multi_usrp: RX channel 2 out of range for
>> configured RX frontends
>>
>> Look for on console, I found that it only have 2 set_direction commands:
>>
>> [0/SplitStream_0] sr_write(128, 0001000E, 0)
>>
>> [0/SplitStream_0] sr_write(129, 0001000F, 0)
>>
>>
>> Could you help me, please?
>>
>> Thanks in advance.
>>
>> Best regards,
>>
>> LTP
>>
>> _______________________________________________
>> 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/20160604/97e1a9b6/attachment-0001.html>
------------------------------
Message: 4
Date: Sat, 4 Jun 2016 08:00:43 +0200
From: Sylvain Munaut <[email protected]>
To: Luong Tan Phong <[email protected]>
Cc: Jonathon Pendlum <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] How to set the number output on
rfnoc_splitstream block?
Message-ID:
<cahl+j08dmxfzhakvd6qh7jwtn84kgpxr2abud54my3406z9...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
> thread[thread-per-block[0]: <block uhd_rfnoc_SplitStream (1)>]: LookupError:
> IndexError: multi_usrp: RX channel 2 out of range for configured RX
> frontends
That looks exactly like the error Jason Matusiak had when trying to
make a block with 3 outputs.
Not sure if he ever solved it ... but tbh it might just be a bug in
the framework itself, there is no other blocks with > 2 outputs AFAIK.
(at least in rfnoc-devel, not sure about radio-redo)
Cheers,
Sylvain
------------------------------
Message: 5
Date: Sat, 4 Jun 2016 11:56:31 -0400
From: Dave NotTelling <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] gr-ettus RFNoC 1024 Bin FFT Limit?
Message-ID:
<cak6gvuo+a0foq+f5yh9smmzyzx6agc5jp03ltp2t5wj7+ol...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Marcus,
Does the FFT size limit also apply to PCIe?
-Dave
On Mon, May 9, 2016 at 12:18 AM, Dave NotTelling <[email protected]>
wrote:
> Ahh, that makes perfect sense. Thank you!
> On May 9, 2016 12:09 AM, "Marcus D. Leech via USRP-users" <
> [email protected]> wrote:
>
>> On 05/08/2016 11:28 PM, Dave NotTelling via USRP-users wrote:
>>
>>> Is the RFNoC FFT block limited to 1024 points? The drop down shows up
>>> to 4096, but the block errors out in GNU Radio if put over 1024. Is that
>>> intentional? If so, is there a specific reason why the FFT block is
>>> limited that low?
>>>
>>> Thank you!
>>>
>>> -Dave
>>>
>>> FFT outputs are done as single UDP frames in RFNoC, so you're limited to
>> whatever your Ethernet NIC can give you. For 1024-bin FFTs, that
>> requires a minimum of 4096bytes, without considering required VITA
>> overhead, etc. So, your NIC needs to be programmed for about 4500
>> bytes MTU. Most 1GiGe NICs won't go a whole lot over that, although
>> 10GiGe NICs will allow and MTU of 9000, allowing 2048-bin FFTs.
>>
>>
>>
>> _______________________________________________
>> 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/20160604/f3bddffe/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 70, Issue 4
*****************************************
