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: Finding E310 Release Version (Philip Balister)
2. gr-scan & usrp (rv pellarin)
3. Re: gr-scan & usrp (Marcus M?ller)
4. Re: Non-uniform behaviour of swigged objects (Martin Braun)
5. Re: Error using RFNoC OFDM Sync block on E310 (Martin Braun)
6. Re: gr-scan & usrp (rv pellarin)
7. Re: gr-scan & usrp (Marcus M?ller)
8. Re: gr-scan & usrp (Chris Kuethe)
9. NEWSDR Coming Next Week (Neel Pandeya)
10. Re: gr-scan & usrp (rv pellarin)
11. Re: gr-scan & usrp (Chris Kuethe)
12. Re: UBX Tx-to-Rx interference, Performance and Power-Save
modes (hanwen)
13. Re: UBX Tx-to-Rx interference, Performance and Power-Save
modes (Michael West)
14. Modifying the carrier wave/creating USRP2920 UHD (Robin Coxe)
15. Re: gr-scan & usrp (rv pellarin)
16. Re: Modifying the carrier wave/creating USRP2920 UHD
(Marcus M?ller)
17. E310 headphone jack (Jason Matusiak)
----------------------------------------------------------------------
Message: 1
Date: Mon, 23 May 2016 12:09:22 -0400
From: Philip Balister <[email protected]>
To: devin kelly <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] Finding E310 Release Version
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 05/23/2016 11:57 AM, devin kelly via USRP-users wrote:
> A co-worker (who's out this week) gave me an E310 to use. He didn't tell
> me the release version/number on the SD card. Is there any way to figure
> this out?
>
> If it helps here's the output from uname -a
>
> Linux e310-02 3.14.2-xilinx #1 SMP PREEMPT Tue Apr 21 06:51:07 EDT 2015
> armv7l GNU/Linux
>
> e310-02 is the hostname. Can I estimate the version based on the date
> here? That doesn't seem like the most reliable way to do it.
Look at:
/etc/version
/etc/version-image
and
/etc/build (Only on later images)
Philip
>
> Thanks,
> Devin
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 2
Date: Mon, 23 May 2016 18:29:13 +0200
From: rv pellarin <[email protected]>
To: [email protected]
Subject: [USRP-users] gr-scan & usrp
Message-ID:
<CAHLh5KGGxU=R70=sMz4pzthhZTs5sw_HpyT=pug6figyxfc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
hi guys,
have some of you succeed using gr-scan with an usrp device?
best regards
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/54cce0b3/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 23 May 2016 18:53:42 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] gr-scan & usrp
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi RV,
I like your straightforward attitude, but:
This sounds like you've tried something, and it failed.
You should definitely describe your problems in greater detail,
otherwise it'll be hard for people to help you.
For example, there's several projects out there that are called gr-scan.
Most of them haven't been updated/maintained in years. Which one are you
referring to?
What are you trying to do?
Generally, I'd like to encourage you to increase the descriptiveness of
your mailing list posts; that'll make it much easier to help you fast :)
Best regards,
Marcus
On 05/23/2016 06:29 PM, rv pellarin via USRP-users wrote:
> hi guys,
> have some of you succeed using gr-scan with an usrp device?
> best regards
> ?
>
>
> _______________________________________________
> 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/20160523/107d30ea/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 23 May 2016 10:03:52 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Non-uniform behaviour of swigged objects
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Elvis,
looks like you're the first to use tune_requests in this fashion.
However, I'm not sure what the correct Boolean representation of a tune
request is -- same with a string.
This is on gr-uhd, and I'm open for suggestions or pull requests.
However, I recommend you simply check the individual class attributes of
your tune request instead (e.g., f.target_freq == <..>).
Cheers,
Martin
On 05/22/2016 09:15 AM, Elvis Angelaccio via USRP-users wrote:
> 2016-05-22 18:09 GMT+02:00 Marcus M?ller <[email protected]>:
>> ha! uhd.tune_request (and others, like sensor_value) python objects have a
>> __nonzero__ method, which is inherently used for conversion to bool, if
>> present. And guess what: they return False.
>> Wondering where they come from.
>>
>> Cheers,
>> Marcus
>>
>> On 22.05.2016 18:02, Marcus M?ller wrote:
>>
>> Well, the python semantics, at least as I understand them, dictate that "not
>> objectname" is True if objectname is of NoneType, or if objectname is
>> actually False, or evaluates to something that is False (i.e. 0).
>>
>> A valid object "should be".
>>
>> Checking it against the typical swigged GNU Radio objects:
>>
>> $from gnuradio import blocks, uhd
>> $vs = blocks_vector_sink_b()
>> $f = uhd.tune_request(10)
>> $bool(vs)
>> True
>> $bool(f)
>> False
>
> Not sure if related, but why does "str(f)" returns 0.0?
> (I was assuming this was a float - rather than a structure - because of that)
>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 5
Date: Mon, 23 May 2016 10:06:38 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Did you rebuild and reinstall UHD, GNU Radio and gr-ettus? Can you
provide a core dump?
Thanks,
Martin
On 05/22/2016 08:19 AM, Sergio Cruz Perez via USRP-users wrote:
> Hi Jonathon,
>
>
> I found that the problem was that the schmidlcox. xml file located in
> {uhd_installation_path}/share/uhd/rfnoc/blocks doesn't have the correct
> registers declared. I modified that file and uhd_rfnoc_schmidlcox.xml
> in my local copy of uhd and gr-ettus repos. I reinstalled both on my pc
> and cross-compiled for the E310. Now, I can see how the registers are
> correctly added to the xbar:
>
>
> The problem now is that every program that I run on the E310 using my
> fpga image sends a message of segmentation fault.
>
>
>
> root@ettus-e300:~/rfnoc# ./schmidl.py
>
> linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-308-g63b98f87
>
>
> -- Loading FPGA image: /home/root/usrp_e310_rfnoc_fpga.bit... done
>
> -- Initializing core control...
>
> -- Performing register loopback test... pass
>
> -- Setting up dest map for ep 0 to be stream 1
>
> -- Performing register loopback test... pass
>
>
> [...]
>
>
>
> -- [RFNOC] ------- Block Setup -----------
>
> -- Setting up dest map for ep 2 to be stream 7
>
> -- Setting up NoC-Shell Control #0 (SID: 00:02>02:30)...OK
>
> -- Port 48: Found NoC-Block with ID 5CC0000000000000.
>
> -- base_path = "/usr/share/uhd/rfnoc"
>
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/schmidlcox.xml
>
> -- [RFNoC Factory] block_ctrl_base::make()
>
> -- base_path = "/usr/share/uhd/rfnoc"
>
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/schmidlcox.xml
>
> -- [RFNoC Factory] Using controller key 'Block' and block name 'SchmidlCox'
>
> -- block_ctrl_base()
>
> -- base_path = "/usr/share/uhd/rfnoc"
>
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/schmidlcox.xml
>
> -- Found valid blockdef
>
> -- NOC ID: 0x5CC0000000000000 Block ID: 0/SchmidlCox_0
>
> -- [0/SchmidlCox_0] Adding port definition at
> xbar/SchmidlCox_0/ports/in/0: type = 'sc16' pkt_size = '0' vlen = '0'
>
> -- [0/SchmidlCox_0] Adding port definition at
> xbar/SchmidlCox_0/ports/out/0: type = 'sc16' pkt_size = '%vlen' vlen =
> '$fftsize'
>
> -- added arg path: xbar/SchmidlCox_0/args/0/fftsize/value
>
> -- added arg path: xbar/SchmidlCox_0/args/0/frame_len/value
>
> -- added arg path: xbar/SchmidlCox_0/args/0/gap_len/value
>
> -- added arg path: xbar/SchmidlCox_0/args/0/offset/value
>
> -- added arg path: xbar/SchmidlCox_0/args/0/max_num_symbols/value
>
> -- added arg path: xbar/SchmidlCox_0/args/0/short_num_symbols/value
>
> -- added arg path: xbar/SchmidlCox_0/args/0/threshold/value
>
> -- added arg path: xbar/SchmidlCox_0/args/0/agc_ref_level/value
>
> -- [NocScript] Executing and asserting code: SR_WRITE("FRAME_LENGTH",
> $frame_len)
>
> -- [NocScript] Executing SR_WRITE()
>
> -- [0/SchmidlCox_0] sr_write(FRAME_LENGTH, 00000040) ==>
> [0/SchmidlCox_0] sr_write(129, 00000040, 0)
>
> -- [NocScript] Executing and asserting code: SR_WRITE("GAP_LENGTH",
> $gap_len)
>
> -- [NocScript] Executing SR_WRITE()
>
> -- [0/SchmidlCox_0] sr_write(GAP_LENGTH, 00000010) ==>
> [0/SchmidlCox_0] sr_write(130, 00000010, 0)
>
> -- [NocScript] Executing and asserting code: SR_WRITE("OFFSET", $offset)
>
> -- [NocScript] Executing SR_WRITE()
>
> -- [0/SchmidlCox_0] sr_write(OFFSET, 00000010) ==> [0/SchmidlCox_0]
> sr_write(131, 00000010, 0)
>
> -- [NocScript] Executing and asserting code: GE($max_num_symbols, 0) AND
> LE($max_num_symbols, 1000)
>
> -- [NocScript] Executing and asserting code: SR_WRITE("NUM_SYMBOLS_MAX",
> $max_num_symbols)
>
> -- [NocScript] Executing SR_WRITE()
>
> -- [0/SchmidlCox_0] sr_write(NUM_SYMBOLS_MAX, 0000000C) ==>
> [0/SchmidlCox_0] sr_write(132, 0000000C, 0)
>
> -- [NocScript] Executing and asserting code: GE($short_num_symbols, 0)
> AND LE($short_num_symbols, 1000)
>
> -- [NocScript] Executing and asserting code:
> SR_WRITE("NUM_SYMBOLS_SHORT", $short_num_symbols)
>
> -- [NocScript] Executing SR_WRITE()
>
> -- [0/SchmidlCox_0] sr_write(NUM_SYMBOLS_SHORT, 00000008) ==>
> [0/SchmidlCox_0] sr_write(133, 00000008, 0)
>
> -- [NocScript] Executing and asserting code: GE($threshold, 0.0) AND
> LE($threshold, 1.0)
>
> -- [NocScript] Executing and asserting code: SR_WRITE("THRESHOLD",
> IROUND(MULT(16384.0, $threshold)))
>
> -- [NocScript] Executing SR_WRITE()
>
> -- [0/SchmidlCox_0] sr_write(THRESHOLD, 00003800) ==>
> [0/SchmidlCox_0] sr_write(134, 00003800, 0)
>
> -- [NocScript] Executing and asserting code: GE($agc_ref_level, 0.0) AND
> LE($agc_ref_level, 1.0)
>
> -- [NocScript] Executing and asserting code: SR_WRITE("AGC_REF_LEVEL",
> IROUND(MULT(32768.0, $agc_ref_level)))
>
> -- [NocScript] Executing SR_WRITE()
>
> -- [0/SchmidlCox_0] sr_write(AGC_REF_LEVEL, 00001000) ==>
> [0/SchmidlCox_0] sr_write(135, 00001000, 0)
>
> -- ========== Full list of RFNoC blocks: ============
>
> -- * 0/Radio_0
>
> -- * 0/Radio_1
>
> -- * 0/SchmidlCox_0
>
> -- [0/Radio_0] block_ctrl_base::clear()
>
> -- node_ctrl_base::clear()
>
> -- [0/Radio_1] block_ctrl_base::clear()
>
> -- node_ctrl_base::clear()
>
> -- [0/SchmidlCox_0] block_ctrl_base::clear()
>
> -- node_ctrl_base::clear()
>
> -- [0/SchmidlCox_0] block_ctrl_base::_clear()
>
> -- [0/SchmidlCox_0] sr_write(126, 00C1EA12, 0)
>
> -- [0/Radio_0] _resolve_port_def()
>
> -- [0/Radio_0] item type: sc16
>
> -- [0/Radio_0] vector length: 0
>
> -- [0/Radio_0] packet size: 0
>
> -- [0/Radio_0] _resolve_port_def()
>
> -- [0/Radio_0] item type: sc16
>
> -- [0/Radio_0] vector length: 0
>
> -- [0/Radio_0] packet size: 0
>
>
> UHD Warning:
>
> The hardware does not support the requested RX sample rate:
>
> Target sample rate: 10.000000 MSps
>
> Actual sample rate: 8.000000 MSps
>
> enabling rx dc offset removal: 1
>
> -- [0/SchmidlCox_0] _resolve_port_def()
>
> -- [0/SchmidlCox_0] item type: sc16
>
> -- [0/SchmidlCox_0] vector length: 0
>
> -- [0/SchmidlCox_0] packet size: 0
>
> -- [0/SchmidlCox_0] _resolve_port_def()
>
> -- [0/SchmidlCox_0] item type: sc16
>
> -- [0/SchmidlCox_0] vector length: 64
>
> -- [0/SchmidlCox_0] packet size: 64
>
> -- [NocScript] Executing and asserting code: SR_WRITE("FRAME_LENGTH",
> $frame_len)
>
> -- [NocScript] Executing SR_WRITE()
>
> -- [0/SchmidlCox_0] sr_write(FRAME_LENGTH, 00000010) ==>
> [0/SchmidlCox_0] sr_write(129, 00000010, 0)
>
> -- [NocScript] Executing and asserting code: SR_WRITE("GAP_LENGTH",
> $gap_len)
>
> -- [NocScript] Executing SR_WRITE()
>
> -- [0/SchmidlCox_0] sr_write(GAP_LENGTH, 00000010) ==>
> [0/SchmidlCox_0] sr_write(130, 00000010, 0)
>
> -- [NocScript] Executing and asserting code: SR_WRITE("OFFSET", $offset)
>
> -- [NocScript] Executing SR_WRITE()
>
> -- [0/SchmidlCox_0] sr_write(OFFSET, 00000000) ==> [0/SchmidlCox_0]
> sr_write(131, 00000000, 0)
>
> -- [NocScript] Executing and asserting code: GE($max_num_symbols, 0) AND
> LE($max_num_symbols, 1000)
>
> -- [NocScript] Executing and asserting code: SR_WRITE("NUM_SYMBOLS_MAX",
> $max_num_symbols)
>
> -- [NocScript] Executing SR_WRITE()
>
> -- [0/SchmidlCox_0] sr_write(NUM_SYMBOLS_MAX, 0000000C) ==>
> [0/SchmidlCox_0] sr_write(132, 0000000C, 0)
>
> -- [NocScript] Executing and asserting code: GE($short_num_symbols, 0)
> AND LE($short_num_symbols, 1000)
>
> -- [NocScript] Executing and asserting code:
> SR_WRITE("NUM_SYMBOLS_SHORT", $short_num_symbols)
>
> -- [NocScript] Executing SR_WRITE()
>
> -- [0/SchmidlCox_0] sr_write(NUM_SYMBOLS_SHORT, 00000008) ==>
> [0/SchmidlCox_0] sr_write(133, 00000008, 0)
>
> -- [NocScript] Executing and asserting code: GE($threshold, 0.0) AND
> LE($threshold, 1.0)
>
> -- [NocScript] Executing and asserting code: SR_WRITE("THRESHOLD",
> IROUND(MULT(16384.0, $threshold)))
>
> -- [NocScript] Executing SR_WRITE()
>
> -- [0/SchmidlCox_0] sr_write(THRESHOLD, 00003800) ==>
> [0/SchmidlCox_0] sr_write(134, 00003800, 0)
>
> -- [NocScript] Executing and asserting code: GE($agc_ref_level, 0.0) AND
> LE($agc_ref_level, 1.0)
>
> -- [NocScript] Executing and asserting code: SR_WRITE("AGC_REF_LEVEL",
> IROUND(MULT(32768.0, $agc_ref_level)))
>
> -- [NocScript] Executing SR_WRITE()
>
> -- [0/SchmidlCox_0] sr_write(AGC_REF_LEVEL, 00001000) ==>
> [0/SchmidlCox_0] sr_write(135, 00001000, 0)
>
> Segmentation fault
>
>
> I attached the files I modified. Any suggestion of what can I do now?
>
> Thanks
>
> Sergio
>
>
> ------------------------------------------------------------------------
> To: [email protected]
> Date: Thu, 31 Mar 2016 18:37:34 -0600
> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
> From: [email protected]
> CC: [email protected]
>
> Jonathon,
>
> I'm compiling uhd locally on the E310. I installed this branch:
>
> root@ettus-e300:~/uhd# git status
> On branch rfnoc-ofdm
> Your branch is up-to-date with 'origin/rfnoc-ofdm'.
>
> root@ettus-e300:~/uhd/fpga-src# git status
> HEAD detached at b2d9bca
>
> I did it using the next commands:
>
> cmake -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_USRP1=OFF -DENABLE_USRP2=OFF
> DENABLE_B100=OFF -DENABLE_E100=OFF -DENABLE_X300=ON -DENABLE_B200=OFF
> -DENABLE_E300=ON ..
>
> make and make install. No errors were detected when it finished.
>
> Is this ok or I need to cross compile UHD? If I use just the rfnoc FIFO
> block, I don't have the problem.
>
> Sergio
>
>
>
>
>
> ------------------------------------------------------------------------
> From: [email protected]
> Date: Thu, 31 Mar 2016 17:19:13 -0700
> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
> To: [email protected]
> CC: [email protected]
>
> Hi Sergio,
>
> Are you cross compiling UHD using the rfnoc-ofdm branch? If you use the
> built in UHD on the fido test image it won't work since it isn't built
> from the correct commit.
>
>
>
> Jonathon
>
> On Thu, Mar 31, 2016 at 4:56 PM, Sergio Cruz Perez
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi Jonathon,
>
> I'm already tested the schmidl_cox block using the rfnoc-branch
> branch and using the commit commit
> *b2d9bca4907d74059e7db5ed295df10c045e054e *for the fpga-src, but I
> still having the next error:
>
> /Traceback (most recent call last):/
> / File "./schmidl.py", line 192, in <module>/
> / main()/
> / File "./schmidl.py", line 181, in main/
> / tb = top_block_cls(chan_est=options.chan_est,
> freq=options.freq, gain=options.gain, lo_offset=options.lo_offset,
> samp_rate=options.samp_rate)/
> / File "./schmidl.py", line 93, in __init__/
> / self.uhd_rfnoc_ofdm_schmidlcox_0.set_arg("offset", 77)/
> / File
> "/usr/local/lib/python2.7/site-packages/ettus/ettus_swig.py", line
> 3002, in set_arg/
> / return _ettus_swig.rfnoc_generic_sptr_set_arg(self, *args)/
> /RuntimeError: LookupError: Path not found in tree:
> /mboards/0/xbar/SchmidlCox_0/args/0/offset/value/
>
> Do you think I need to upgrade the firmware also to solve this? I'm
> currently using the
> alpha/fido_rfnoc_test/sdimage-gnuradio-dev.direct.xz
>
> Thanks
> Sergio
>
>
>
>
>
> ------------------------------------------------------------------------
> From: [email protected] <mailto:[email protected]>
> Date: Wed, 30 Mar 2016 13:34:45 -0700
>
> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
> To: [email protected] <mailto:[email protected]>
> CC: [email protected] <mailto:[email protected]>
>
> Hey Sergio,
>
> I updated the commit fpga-src is pointing at in uhd/rfnoc-ofdm. Give
> it try now.
>
>
>
> Jonathon
>
>
> On Wed, Mar 30, 2016 at 12:31 PM, Sergio Cruz Perez
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi Jonathon,
>
> I used the rfnoc-ofdm branch to make the fpga image. Now I have
> the same problem that I had when I used the rfnoc-devel branch:
>
> ERROR: [Synth 8-448] named port connection 's_axis_phase_tlast'
> does not exist for instance 'cfo_corrector' of module
> 'cordic_rotator'
> [/home/sheko/uhd/fpga-src/usrp3/lib/rfnoc/schmidl_cox.v:163]
>
> The commit of the fpga-src folder that I'm using is:
> 8fc97e5eeb3abfcccfb5b71e2d28717ec9b673a0 and
> uhd commit: 8cbec5e4b8ab5fd7c8f04c09c995d337bc0ba603.
>
> I saw that the schmidl_cox.v that is contained in this branch of
> fpga-src is older than the version in the rfnoc-ofdm branch.
>
> When I installed uhd I changed to rfnoc-ofmd branch and then I
> updated the fpga-src submodule. Is this correct?
>
> Thanks
>
> Sergio
>
>
>
>
> ------------------------------------------------------------------------
> From: [email protected] <mailto:[email protected]>
> Date: Mon, 28 Mar 2016 09:53:09 -0700
>
> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
> To: [email protected] <mailto:[email protected]>
> CC: [email protected] <mailto:[email protected]>
>
> Hi Sergio,
>
> I just pushed a branch on uhd called rfnoc-ofdm. Give that one a
> try.
>
>
> Jonathon
>
>
> On Thu, Mar 24, 2016 at 11:35 AM, Sergio Cruz Perez
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi Jonathon,
>
> I'm using commit b7546712aa0091f87b793ef4c4a9e9c084467173
>
> Thanks
>
> Sergio
>
>
> ------------------------------------------------------------------------
> From: [email protected]
> <mailto:[email protected]>
> Date: Wed, 23 Mar 2016 20:12:59 -0700
>
> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block
> on E310
> To: [email protected] <mailto:[email protected]>
> CC: [email protected]
> <mailto:[email protected]>
>
> Hi Sergio,
>
> Looks like the block is being enumerated but UHD is not
> populating the property tree correctly. What commit of UHD
> rfnoc-devel are you using?
>
>
>
> Jonathon
>
> On Wed, Mar 23, 2016 at 11:15 AM, Sergio Cruz Perez
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi Jonathon,
>
> Finally I could make the image updating the e300_core.v
> file as you said. I ran the uhd_usrp_probe init only and
> now I can see the rfnoc blocks schmidl_cox and fifo.
>
> /-- ========== Full list of RFNoC blocks: ============/
> /-- * 0/Radio_0/
> /-- * 0/Radio_1/
> /-- * 0/FIFO_0/
> /-- * 0/SchmidlCox_0/
>
> But, when i run my application I got again the same problem:
>
> ...
> /-- [0/SchmidlCox_0] _resolve_port_def()/
> /-- [0/SchmidlCox_0] item type: sc16/
> /-- [0/SchmidlCox_0] vector length: 0/
> /-- [0/SchmidlCox_0] packet size: 0/
> /-- [0/SchmidlCox_0] _resolve_port_def()/
> /-- [0/SchmidlCox_0] item type: sc16/
> /-- [0/SchmidlCox_0] vector length: 64/
> /-- [0/SchmidlCox_0] packet size: 64/
> /-- [NocScript] Executing and asserting code:
> SR_WRITE("CP_LENGTH", $cp_len)/
> /-- [NocScript] Executing SR_WRITE() /
> /-- [0/SchmidlCox_0] sr_write(CP_LENGTH, 00000040) ==>
> [0/SchmidlCox_0] sr_write(130, 00000040, 0)/
> /-- [NocScript] Executing and asserting code:
> GE($threshold, 0.0) AND LE($threshold, 1.0)/
> /-- [NocScript] Executing and asserting code:
> SR_WRITE("THRESHOLD", IROUND(MULT(32768.0, $threshold)))/
> /-- [NocScript] Executing SR_WRITE() /
> /-- [0/SchmidlCox_0] sr_write(THRESHOLD, 00007000) ==>
> [0/SchmidlCox_0] sr_write(134, 00007000, 0)/
> /Traceback (most recent call last):/
> / File "./rx_rfnoc.py", line 207, in <module>/
> / main()/
> / File "./rx_rfnoc.py", line 196, in main/
> / tb = top_block_cls(chan_est=options.chan_est,
> freq=options.freq, gain=options.gain,
> lo_offset=options.lo_offset, samp_rate=options.samp_rate)/
> / File "./rx_rfnoc.py", line 97, in __init__/
> / self.uhd_rfnoc_ofdm_schmidlcox_0.set_arg("offset", 77)/
> / File
> "/usr/local/lib/python2.7/site-packages/ettus/ettus_swig.py",
> line 3002, in set_arg/
> / return _ettus_swig.rfnoc_generic_sptr_set_arg(self,
> *args)/
> /RuntimeError: LookupError: Path not found in tree:
> /mboards/0/xbar/SchmidlCox_0/args/0/offset/value/
> ...
>
> How is that path generated? I can't find it on the E310
>
>
>
>
>
> ------------------------------------------------------------------------
> From: [email protected]
> <mailto:[email protected]>
> Date: Tue, 22 Mar 2016 15:17:40 -0700
> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync
> block on E310
> To: [email protected] <mailto:[email protected]>
> CC: [email protected]
> <mailto:[email protected]>
>
> Sergio,
>
> rfnoc-ofdm has gotten a little out of sync with UHD
> rfnoc-devel. The compat number on line 172 in
> e300_core.v needs to be updated to RB32_CORE_COMPAT :
> rb_data <= {8'hAC, 8'h0, 8'h255, 8'h0};
>
> I am going to merge rfnoc-ofdm into rfnoc-radio-redo
> soon which will fix this issue. This temporary fix
> should hold you over until the merge.
>
>
>
> Jonathon
>
> On Tue, Mar 22, 2016 at 3:07 PM, Sergio Cruz Perez
> <[email protected] <mailto:[email protected]>>
> wrote:
>
>
> Hi Jonathon,
>
> It's a GNU radio flowgraph and I'm using my rfnoc
> fpga image. I copied the image that I made on my PC
> using the rfnoc-ofdm branches to the E310. My
> flowgraph has the root to that image in the device3
> args so when I run my applications I can see that
> it's loading my image.
>
> root@ettus-e300:~/pruebas# ./rx_rfnoc.py
> linux; GNU C++ version 4.9.2; Boost_105700;
> UHD_003.010.rfnoc-316-gb7546712
>
> -- Loading FPGA image:
> /home/root/sheko/usrp_e310_rfnoc_fpga.bit... done
> -- Initializing core control...
> -- Performing register loopback test... pass .
> ....
>
> When I don't use the rfnoc-ofdm branches I can make
> the image and run it on the E310 but I return to the
> first problem of this thread.
>
> Thanks
>
> Sergio
>
>
> ------------------------------------------------------------------------
> From: [email protected]
> <mailto:[email protected]>
> Date: Tue, 22 Mar 2016 14:23:28 -0700
>
> Subject: Re: [USRP-users] Error using RFNoC OFDM
> Sync block on E310
> To: [email protected] <mailto:[email protected]>
> CC: [email protected]
> <mailto:[email protected]>
>
> Hi Sergio,
>
> You need copy your bitstream to the E310 and replace
> /usr/share/uhd/images/usrp_e300_fpga.bit. How are
> you running your application? Is it a GNU Radio
> flowgraph?
>
>
>
> Jonathon
>
> On Tue, Mar 22, 2016 at 10:56 AM, Sergio Cruz Perez
> <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> Hi Jonathon,
>
> I installed uhd rfnoc-devel version with the
> rfnoc-ofdm branches on both the PC and the E310
> (UHD_003.010.rfnoc-316-gb7546712). I made the
> image with the schmidl_cox block but when I run
> my application, I got the next error:
>
> RuntimeError: Expected FPGA compatibility number
> 255.x, but got 7.0:
> The FPGA build is not compatible with the host
> code build.
>
> What should I update on my PC to make a
> compatible image with the E310?
>
> Regards
> Sergio
>
>
>
>
> ------------------------------------------------------------------------
> From: [email protected]
> <mailto:[email protected]>
> Date: Wed, 9 Mar 2016 13:05:58 -0800
>
> Subject: Re: [USRP-users] Error using RFNoC OFDM
> Sync block on E310
> To: [email protected]
> <mailto:[email protected]>
> CC: [email protected]
> <mailto:[email protected]>
>
> Hi Sergio,
>
> Try using the "rfnoc-ofdm" branches for uhd and
> gr-ettus and rebuild your FPGA image. Make sure
> to add the schmidl_cox block to
> rfnoc_e310_ce_auto_inst.v and run 'make
> cleanall' before building the FPGA image.
>
>
>
> Jonathon
>
> On Tue, Mar 8, 2016 at 8:31 PM, Sergio Cruz
> Perez <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Jonathon,
>
> Yes, I followed the RFNoC:Getting started
> guide to install the rfnoc-devel branch and
> the gr-ettus OOT module. I forgot to
> mention that in my first attempt to make the
> fpga image I had the next error:
>
> ERROR: [Synth 8-448] named port connection
> 's_axis_phase_tlast' does not exist for
> instance 'cfo_corrector' of module
> 'cordic_rotator'
>
> [/home/sheko/uhd/fpga-src/usrp3/lib/rfnoc/schmidl_cox.v:163]
>
>
> I removed that port in the schmidl_cox.v
> file and then it was possible to make the
> image with the schmidl_cox block.
>
> Thanks
>
> Sergio
>
>
>
>
>
>
> ------------------------------------------------------------------------
> From: [email protected]
> <mailto:[email protected]>
> Date: Tue, 8 Mar 2016 16:51:20 -0800
> Subject: Re: [USRP-users] Error using RFNoC
> OFDM Sync block on E310
> To: [email protected]
> <mailto:[email protected]>
> CC: [email protected]
> <mailto:[email protected]>
>
>
> Hi Sergio,
>
> Are you using the rfnoc-ofdm branches for
> uhd and gr-ettus?
>
>
>
> Jonathon
>
> On Tue, Mar 8, 2016 at 4:31 PM, Sergio Cruz
> Perez via USRP-users
> <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> Hi,
>
> I'm learning to use RFNoC to implement
> an OFDM receiver on a E310. The
> original FPGA image had just 3 RFNoC
> blocks: FIFO, Window and FFT, so I made
> a new image removing the window and the
> FFT blocks and replacing them for a
> schmidl_cox block. When I run my
> application with the new image I get the
> next error:
>
> File
>
> "/usr/local/lib/python2.7/site-packages/ettus/ettus_swig.py",
> line 3002, in set_arg
> return
> _ettus_swig.rfnoc_generic_sptr_set_arg(self,
> *args)
>
> RuntimeError: LookupError: Path not
> found in tree:
>
> /mboards/0/xbar/SchmidlCox_0/args/0/offset/value
>
> Has anyone run into the same problem?
>
> I'm using UHD_003.010.rfnoc-314-gf773e72b
>
> Thanks
>
> Sergio Cruz
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> <mailto:[email protected]>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
>
>
>
>
> _______________________________________________ USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 6
Date: Mon, 23 May 2016 19:21:14 +0200
From: rv pellarin <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] gr-scan & usrp
Message-ID:
<CAHLh5KHJPB=+-woifrlljg8d+ezdpco7pxv5dmn6bz_w29y...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
hi marcus,
gr-scan is a linux executable that allow to perform quic radio scan, for
example ./gr-scan -x 150 -y 175 , that ll automaticly scan between 150 &
175 mhz and show result.
unfortunately it see the usrp device but gives lots off error and fail to
scan.
idealy i m looking for a solution with my usr that scan and log
automaticaly, that s why i asked you if some of you succeed to get this
utility working :)
thxx for your time marcus.
best rgeards
herve
?
On 23 May 2016 at 18:53, Marcus M?ller <[email protected]> wrote:
> Hi RV,
>
> I like your straightforward attitude, but:
>
> This sounds like you've tried something, and it failed.
> You should definitely describe your problems in greater detail, otherwise
> it'll be hard for people to help you.
> For example, there's several projects out there that are called gr-scan.
> Most of them haven't been updated/maintained in years. Which one are you
> referring to?
>
> What are you trying to do?
>
> Generally, I'd like to encourage you to increase the descriptiveness of
> your mailing list posts; that'll make it much easier to help you fast :)
>
> Best regards,
> Marcus
>
>
> On 05/23/2016 06:29 PM, rv pellarin via USRP-users wrote:
>
> hi guys,
> have some of you succeed using gr-scan with an usrp device?
> best regards
> ?
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> 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/20160523/d0bdb0d6/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 23 May 2016 20:01:19 +0200
From: Marcus M?ller <[email protected]>
To: rv pellarin <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] gr-scan & usrp
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
>From where did you get your gr-scan? Again, Google points me to multiple
>projects with that name. Which exactly is the one you are talking about?
Also, as I said, you need to be *descriptive*.
"A lot of errors" helps no-one at helping you. Please apply some more effort in
reporting problems.
BR,
Marcus
Am 23. Mai 2016 19:21:14 MESZ, schrieb rv pellarin <[email protected]>:
>hi marcus,
>gr-scan is a linux executable that allow to perform quic radio scan,
>for
>example ./gr-scan -x 150 -y 175 , that ll automaticly scan between 150
>&
>175 mhz and show result.
>unfortunately it see the usrp device but gives lots off error and fail
>to
>scan.
>idealy i m looking for a solution with my usr that scan and log
>automaticaly, that s why i asked you if some of you succeed to get this
>utility working :)
>thxx for your time marcus.
>best rgeards
>herve
>?
>
>On 23 May 2016 at 18:53, Marcus M?ller <[email protected]>
>wrote:
>
>> Hi RV,
>>
>> I like your straightforward attitude, but:
>>
>> This sounds like you've tried something, and it failed.
>> You should definitely describe your problems in greater detail,
>otherwise
>> it'll be hard for people to help you.
>> For example, there's several projects out there that are called
>gr-scan.
>> Most of them haven't been updated/maintained in years. Which one are
>you
>> referring to?
>>
>> What are you trying to do?
>>
>> Generally, I'd like to encourage you to increase the descriptiveness
>of
>> your mailing list posts; that'll make it much easier to help you fast
>:)
>>
>> Best regards,
>> Marcus
>>
>>
>> On 05/23/2016 06:29 PM, rv pellarin via USRP-users wrote:
>>
>> hi guys,
>> have some of you succeed using gr-scan with an usrp device?
>> best regards
>> ?
>>
>>
>> _______________________________________________
>> USRP-users mailing
>[email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/aa107df3/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 23 May 2016 11:17:29 -0700
From: Chris Kuethe <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: rv pellarin <[email protected]>, "USRP mailing list
([email protected])" <[email protected]>
Subject: Re: [USRP-users] gr-scan & usrp
Message-ID:
<CAGHP0pJnx=t+a75ktocrsupsfefjcta_+jeke2ce6eq9va6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
And rather than posting errors as screenshots (images), either copy the
text either into an email or stick it on something like pastebin
On Mon, May 23, 2016 at 11:01 AM, Marcus M?ller <[email protected]>
wrote:
> From where did you get your gr-scan? Again, Google points me to multiple
> projects with that name. Which exactly is the one you are talking about?
>
> Also, as I said, you need to be *descriptive*.
> "A lot of errors" helps no-one at helping you. Please apply some more
> effort in reporting problems.
>
> BR,
> Marcus
>
>
> Am 23. Mai 2016 19:21:14 MESZ, schrieb rv pellarin <[email protected]>:
>>
>> hi marcus,
>> gr-scan is a linux executable that allow to perform quic radio scan, for
>> example ./gr-scan -x 150 -y 175 , that ll automaticly scan between 150 &
>> 175 mhz and show result.
>> unfortunately it see the usrp device but gives lots off error and fail to
>> scan.
>> idealy i m looking for a solution with my usr that scan and log
>> automaticaly, that s why i asked you if some of you succeed to get this
>> utility working :)
>> thxx for your time marcus.
>> best rgeards
>> herve
>> ?
>>
>> On 23 May 2016 at 18:53, Marcus M?ller <[email protected]>
>> wrote:
>>
>>> Hi RV,
>>>
>>> I like your straightforward attitude, but:
>>>
>>> This sounds like you've tried something, and it failed.
>>> You should definitely describe your problems in greater detail,
>>> otherwise it'll be hard for people to help you.
>>> For example, there's several projects out there that are called gr-scan.
>>> Most of them haven't been updated/maintained in years. Which one are you
>>> referring to?
>>>
>>> What are you trying to do?
>>>
>>> Generally, I'd like to encourage you to increase the descriptiveness of
>>> your mailing list posts; that'll make it much easier to help you fast :)
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 05/23/2016 06:29 PM, rv pellarin via USRP-users wrote:
>>>
>>> hi guys,
>>> have some of you succeed using gr-scan with an usrp device?
>>> best regards
>>> ?
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing
>>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
GDB has a 'break' feature; why doesn't it have 'fix' too?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/0e8ba05e/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 23 May 2016 11:30:21 -0700
From: Neel Pandeya <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] NEWSDR Coming Next Week
Message-ID:
<cacaxmv8pr4jhcudpkdmchyewhdcpfzxw1dy7lri5z5_ghg_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
*** Symposium Registration Still Open ***
*** Workshop Registration Now Closed ***
*********************************************************************
NEWSDR 2016
New England Workshop on Software-Defined Radio
Sixth-Annual
Workshops
Thursday June 2
08:00 to 16:10
Symposium
Friday June 3
18:00 to 21:00
Northeastern University (NEU)
Boston, MA, USA
http://www.sdr-boston.org/
Free Registration
Poster Submissions Accepted Until Friday May 15
*********************************************************************
INVITATION TO PARTICIPATE
You are cordially invited to the 2016 New England Workshop on
Software Defined Radio (NEWSDR 2016), which is the sixth installment
of an annual series of symposium and workshop events organized by
the Boston SDR User Group (SDR-Boston).
This year, NEWSDR will be held at Northeastern University (NEU),
and consists of a day-long symposium on Friday, as well as several
hands-on workshops the evening before on Thursday. You are welcome
to attend either or both events, which are entirely free.
Attendance is typically about 100 people, and attendees are from
both academia and industry.
*********************************************************************
WORKSHOPS
THURSDAY JUNE 2
18:00 to 21:00
Forsyth Building
?70 Forsyth Street
Room 236 and 237
AGENDA
16:00 ? 18:00 Early Sessions for Workshop Setup and Prerequisites
18:00 ? 21:00 Workshop Events
Two workshops are being offered:
* "SDR Challenge ? Identifying Mystery Waveform Using Simulink
and RTL-SDR" by MathWorks (more details listed below)
* "Hands-On Tutorial on FPGA Computing for SDR with RFNoC"
by Ettus Research (more details listed below)
MathWorks and Ettus Research will each run a workshop on the evening
before the main event. Workshops are technical, practical, hands-on
activities in a group setting. Specific topics and further details
about the workshops will be announced shortly. Attendance is free,
but advance registration is required. Free pizza and soda will be
provided.
*********************************************************************
SYMPOSIUM
FRIDAY JUNE 3
08:00 to 16:10
Raytheon Amphitheater
Egan Research Center
120 Forsyth Street
AGENDA
08:00 ? 08:30 Coffee and Light Refreshments
08:30 ? 08:40 Welcome and Introduction
08:40 ? 10:00 Sponsor Flash Talks (20 minutes each)
10:00 ? 10:30 Poster Session Elevator Pitches (2 minutes each)
10:30 ? 11:00 Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits and Demos
11:00 ? 12:00 Invited Presentation:
Mr. Richard Reinhart, NASA Glenn Research Center
12:00 ? 13:00 Lunch and Networking
13:00 ? 14:00 Invited Presentation:
Professor Tommaso Melodia, Northeastern University
14:00 ? 15:00 Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits and Demos
15:00 ? 16:00 Sponsor Short Course by Analog Devices
16:00 ? 16:10 Closing Remarks
Plenary Speakers:
* Mr. Richard Reinhart, NASA Glenn Research Center
* Prof. Tommaso Melodia, Northeastern University
Technical Poster Presentations:
* Covering the recent work in SDR and cognitive radio technology
* Poster presentations are now being solicited
* See link at the bottom of this email to submit your abstract
Corporate Sponsors:
* Analog Devices
* Ettus Research / National Instruments
* MathWorks
* MediaTek Wireless
The symposium features plenary speakers, technical poster
presentation sessions, hardware and software demonstrations from the
event sponsors, and workshops from the event sponsors, all focusing
on recent work in SDR and cognitive radio technology. Free breakfast,
lunch, and coffee will be provided. Attendance is free, but advance
registration is required.
The symposium provides an excellent networking opportunity and a
terrific venue to exchange thoughts and ideas with other people
working in the SDR space.
*********************************************************************
WORKSHOP DESCRIPTION
SDR Challenge ? Identifying Mystery
Waveform Using Simulink and RTL-SDR
by MathWorks
During this evening event, the audience will be tasked with
identifying a ?mystery waveform? that is being generated in their
vicinity. Using MATLAB/Simulink and the RTL-SDR platform, both of
which will be provided during this event, each team will be given
several partially completed models and some details of the mystery
waveform. The objective of this challenge is to add the remaining
functionality to the models provided and leverage the RTL-SDR in
order to classify the received signal and potentially even decode
the signal.
The learning outcomes of this event include:
* Obtaining an understanding of the MATLAB/Simulink software
environment and its capabilities.
* Gaining knowledge on how MATLAB/Simulink interfaces with the
RTL-SDR device.
* Experience hands-on real-time wireless experimentation using
MATLAB/Simulink and the RTL-SDR in a controlled wireless scenario.
Given the limited number of computer workstations and RTL-SDR
platforms available, this event has a registration limit of 30
individuals (teams of 3 individuals will be formed at this event).
Facilitators: Mike McLernon, Dr Ethem Sozer
*********************************************************************
WORKSHOP DESCRIPTION
Hands-On Tutorial on FPGA Computing for SDR with RFNoC
by Ettus Research
Ettus Research has introduced a platform called RF Network-on-Chip
(RFNoC) which makes FPGA computing for SDR more accessible and
flexible. RFNoC is a new architecture for USRP devices that use
Xilinx 7-series FPGAs (E310, X300, and X310). RFNoC is built around
a packetized network infrastructure in the FPGA that handles the
transport of control and sample data between the host CPU and the
radio. Users target their custom algorithms to the FPGA in the form
of Computation Engines (CE), which are processing blocks that attach
to this network. CEs act as independent nodes on the network that can
receive and transmit data to any other node (e.g., another CE, the
radio block, or the host CPU). This architecture permits scalable
designs that can distribute processing across many nodes. Users can
create modular, FPGA-accelerated SDR applications by chaining CEs
into a flow graph. RFNoC is supported in UHD and GNU Radio. In this
workshop, we will present an interactive tutorial on RFNoC, including
a discussion on its design and capabilities, demonstrations of
several existing examples, and a walk-through on implementing a
user-defined CE and integrating the CE into GNU Radio.
Prerequisites:
* Attendees are expected to bring their own laptops to the workshop.
The laptop should have at least 2 GB memory, have at least one
Ethernet port and one USB 3.0 port, and be able to boot into a Linux
environment from a USB 3.0 flash drive.
* Attendees must create Xilinx user accounts at least three days
before the workshop, in order to obtain Xilinx licenses for the free
WebPack Edition of Vivado version 2015.4.
USB flash drives and USRP hardware will be provided in the workshop.
Enrollment is limited to 20 people.
Facilitators: Jonathon Pendlum, Wan Liu, Neel Pandeya
*********************************************************************
REGISTRATION
* Register for the Symposium, or the Workshop, or both
* Registration is required but is completely free
* Registration takes less than 5 minutes
* Registration includes free food
* Parking available
* You must register online for food and parking
* Attendance, food, parking are all limited, so please register
online as soon as possible to secure your spot
* Registration deadline is Friday May 20
* See link at the bottom of this announcement to register online
*********************************************************************
LINKS
Attendee Registration:
https://docs.google.com/forms/d/1QCIyKIVzpZfzh4ptim7zCIbcKvi2drDLurkptokdqN4
Poster Abstract Submission:
https://docs.google.com/forms/d/17faN0FQuifOHS4xX1TZWN9ABMlY__s3g81ZUfIwdtqE
*********************************************************************
ADDITIONAL INFORMATION
More information, and the event schedule,
for this event can be found at our website:
http://www.sdr-boston.org/
*********************************************************************
EOF
*********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/35a60ad7/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 23 May 2016 14:56:47 -0400
From: rv pellarin <[email protected]>
To: Chris Kuethe <[email protected]>
Cc: Marcus M?ller <[email protected]>, "USRP mailing list
([email protected])" <[email protected]>
Subject: Re: [USRP-users] gr-scan & usrp
Message-ID:
<CAHLh5KGozn3K_LwqVEZr1BBwxHs=rg0mblcqkxm-plrghxz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
hi,
sorry again for my post, didn t mean to offense you, was busy with kids and
work, i should have wait before post.
so here is the soft:
https://github.com/pinkavaj/gr-scan
got no error when compile, and when i run it, this is what i get as error
message.
root@kali:~/Documents/gr-scan/gr-scan-master# ./gr-scan -x 150 -y 175
linux; GNU C++ version 5.3.1 20160409; Boost_105800;
UHD_003.009.003-0-unknown
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.9
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf
rfspace airspy redpitaya
-- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
FATAL: No supported devices found to pick from.
Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.
Using Volk machine: avx_64_mmx_orc
gr::buffer::allocate_buffer: warning: tried to allocate
4 items of size 16000. Due to alignment requirements
32 were allocated. If this isn't OK, consider padding
your structure to a power-of-two bytes.
On this platform, our allocation granularity is 4096 bytes.
gr::buffer::allocate_buffer: warning: tried to allocate
16 items of size 8000. Due to alignment requirements
64 were allocated. If this isn't OK, consider padding
your structure to a power-of-two bytes.
On this platform, our allocation granularity is 4096 bytes.
gr::buffer::allocate_buffer: warning: tried to allocate
8 items of size 8000. Due to alignment requirements
64 were allocated. If this isn't OK, consider padding
your structure to a power-of-two bytes.
On this platform, our allocation granularity is 4096 bytes.
gr::buffer::allocate_buffer: warning: tried to allocate
8 items of size 8000. Due to alignment requirements
64 were allocated. If this isn't OK, consider padding
your structure to a power-of-two bytes.
On this platform, our allocation granularity is 4096 bytes.
^C
root@kali:~/Documents/gr-scan/gr-scan-master#
if you have any clues how to fix it, would be great, seems to be a nice
prog.
one thing i ve noticed, they show an example on their website with -o
filename.csv but in real, this option is not any longer available, pitty,
was handy
thxx for your time, and again, my apologies.
best regards
herve
On 23 May 2016 at 14:17, Chris Kuethe <[email protected]> wrote:
> And rather than posting errors as screenshots (images), either copy the
> text either into an email or stick it on something like pastebin
>
> On Mon, May 23, 2016 at 11:01 AM, Marcus M?ller <
> [email protected]> wrote:
>
>> From where did you get your gr-scan? Again, Google points me to multiple
>> projects with that name. Which exactly is the one you are talking about?
>>
>> Also, as I said, you need to be *descriptive*.
>> "A lot of errors" helps no-one at helping you. Please apply some more
>> effort in reporting problems.
>>
>> BR,
>> Marcus
>>
>>
>> Am 23. Mai 2016 19:21:14 MESZ, schrieb rv pellarin <[email protected]>:
>>>
>>> hi marcus,
>>> gr-scan is a linux executable that allow to perform quic radio scan, for
>>> example ./gr-scan -x 150 -y 175 , that ll automaticly scan between 150 &
>>> 175 mhz and show result.
>>> unfortunately it see the usrp device but gives lots off error and fail
>>> to scan.
>>> idealy i m looking for a solution with my usr that scan and log
>>> automaticaly, that s why i asked you if some of you succeed to get this
>>> utility working :)
>>> thxx for your time marcus.
>>> best rgeards
>>> herve
>>> ?
>>>
>>> On 23 May 2016 at 18:53, Marcus M?ller <[email protected]>
>>> wrote:
>>>
>>>> Hi RV,
>>>>
>>>> I like your straightforward attitude, but:
>>>>
>>>> This sounds like you've tried something, and it failed.
>>>> You should definitely describe your problems in greater detail,
>>>> otherwise it'll be hard for people to help you.
>>>> For example, there's several projects out there that are called
>>>> gr-scan. Most of them haven't been updated/maintained in years. Which one
>>>> are you referring to?
>>>>
>>>> What are you trying to do?
>>>>
>>>> Generally, I'd like to encourage you to increase the descriptiveness of
>>>> your mailing list posts; that'll make it much easier to help you fast :)
>>>>
>>>> Best regards,
>>>> Marcus
>>>>
>>>>
>>>> On 05/23/2016 06:29 PM, rv pellarin via USRP-users wrote:
>>>>
>>>> hi guys,
>>>> have some of you succeed using gr-scan with an usrp device?
>>>> best regards
>>>> ?
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing
>>>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
> --
> GDB has a 'break' feature; why doesn't it have 'fix' too?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/5939db9e/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 23 May 2016 12:38:36 -0700
From: Chris Kuethe <[email protected]>
To: rv pellarin <[email protected]>
Cc: Marcus M?ller <[email protected]>, "USRP mailing list
([email protected])" <[email protected]>
Subject: Re: [USRP-users] gr-scan & usrp
Message-ID:
<CAGHP0pLoYTemnzP9qTHQXyT=hftpkyly5pslnyc8kfnkfgo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
OK, that's a better request. This tells us exactly what software you're
running and gives a very strong indication of where to start debugging.
"FATAL: No supported devices found to pick from."
Here are some things that you can investigate
1) do you see the device with lsusb?
2) do you see the device with uhd_usrp_probe?
3) does this program work with any other receivers (rtlsdr)?
4) can you use your receiver with osmocom_fft?
5) can you use your receiver with uhd_fft?
On Mon, May 23, 2016 at 11:56 AM, rv pellarin <[email protected]> wrote:
> hi,
> sorry again for my post, didn t mean to offense you, was busy with kids
> and work, i should have wait before post.
> so here is the soft:
> https://github.com/pinkavaj/gr-scan
>
> got no error when compile, and when i run it, this is what i get as error
> message.
> root@kali:~/Documents/gr-scan/gr-scan-master# ./gr-scan -x 150 -y 175
> linux; GNU C++ version 5.3.1 20160409; Boost_105800;
> UHD_003.009.003-0-unknown
>
> gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.9
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
> bladerf rfspace airspy redpitaya
> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
>
> FATAL: No supported devices found to pick from.
>
> Trying to fill up 1 missing channel(s) with null source(s).
> This is being done to prevent the application from crashing
> due to gnuradio bug #528.
>
> Using Volk machine: avx_64_mmx_orc
> gr::buffer::allocate_buffer: warning: tried to allocate
> 4 items of size 16000. Due to alignment requirements
> 32 were allocated. If this isn't OK, consider padding
> your structure to a power-of-two bytes.
> On this platform, our allocation granularity is 4096 bytes.
> gr::buffer::allocate_buffer: warning: tried to allocate
> 16 items of size 8000. Due to alignment requirements
> 64 were allocated. If this isn't OK, consider padding
> your structure to a power-of-two bytes.
> On this platform, our allocation granularity is 4096 bytes.
> gr::buffer::allocate_buffer: warning: tried to allocate
> 8 items of size 8000. Due to alignment requirements
> 64 were allocated. If this isn't OK, consider padding
> your structure to a power-of-two bytes.
> On this platform, our allocation granularity is 4096 bytes.
> gr::buffer::allocate_buffer: warning: tried to allocate
> 8 items of size 8000. Due to alignment requirements
> 64 were allocated. If this isn't OK, consider padding
> your structure to a power-of-two bytes.
> On this platform, our allocation granularity is 4096 bytes.
> ^C
> root@kali:~/Documents/gr-scan/gr-scan-master#
>
>
>
> if you have any clues how to fix it, would be great, seems to be a nice
> prog.
> one thing i ve noticed, they show an example on their website with -o
> filename.csv but in real, this option is not any longer available, pitty,
> was handy
>
>
> thxx for your time, and again, my apologies.
> best regards
>
> herve
>
> On 23 May 2016 at 14:17, Chris Kuethe <[email protected]> wrote:
>
>> And rather than posting errors as screenshots (images), either copy the
>> text either into an email or stick it on something like pastebin
>>
>> On Mon, May 23, 2016 at 11:01 AM, Marcus M?ller <
>> [email protected]> wrote:
>>
>>> From where did you get your gr-scan? Again, Google points me to multiple
>>> projects with that name. Which exactly is the one you are talking about?
>>>
>>> Also, as I said, you need to be *descriptive*.
>>> "A lot of errors" helps no-one at helping you. Please apply some more
>>> effort in reporting problems.
>>>
>>> BR,
>>> Marcus
>>>
>>>
>>> Am 23. Mai 2016 19:21:14 MESZ, schrieb rv pellarin <[email protected]>:
>>>>
>>>> hi marcus,
>>>> gr-scan is a linux executable that allow to perform quic radio scan,
>>>> for example ./gr-scan -x 150 -y 175 , that ll automaticly scan between 150
>>>> & 175 mhz and show result.
>>>> unfortunately it see the usrp device but gives lots off error and fail
>>>> to scan.
>>>> idealy i m looking for a solution with my usr that scan and log
>>>> automaticaly, that s why i asked you if some of you succeed to get this
>>>> utility working :)
>>>> thxx for your time marcus.
>>>> best rgeards
>>>> herve
>>>> ?
>>>>
>>>> On 23 May 2016 at 18:53, Marcus M?ller <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi RV,
>>>>>
>>>>> I like your straightforward attitude, but:
>>>>>
>>>>> This sounds like you've tried something, and it failed.
>>>>> You should definitely describe your problems in greater detail,
>>>>> otherwise it'll be hard for people to help you.
>>>>> For example, there's several projects out there that are called
>>>>> gr-scan. Most of them haven't been updated/maintained in years. Which one
>>>>> are you referring to?
>>>>>
>>>>> What are you trying to do?
>>>>>
>>>>> Generally, I'd like to encourage you to increase the descriptiveness
>>>>> of your mailing list posts; that'll make it much easier to help you fast
>>>>> :)
>>>>>
>>>>> Best regards,
>>>>> Marcus
>>>>>
>>>>>
>>>>> On 05/23/2016 06:29 PM, rv pellarin via USRP-users wrote:
>>>>>
>>>>> hi guys,
>>>>> have some of you succeed using gr-scan with an usrp device?
>>>>> best regards
>>>>> ?
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing
>>>>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>
>>> --
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>>
>> --
>> GDB has a 'break' feature; why doesn't it have 'fix' too?
>>
>
>
--
GDB has a 'break' feature; why doesn't it have 'fix' too?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/1d15a956/attachment-0001.html>
------------------------------
Message: 12
Date: Mon, 23 May 2016 22:35:32 +0200
From: hanwen <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>, Marcus
M?ller <[email protected]>
Subject: Re: [USRP-users] UBX Tx-to-Rx interference, Performance and
Power-Save modes
Message-ID:
<cabjuse1e7sdy709m7wqp46yaw0jppz9z+zcwvj6r6yttlj7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Michael,
Thanks for the patch. I tried today and it fixed the issue that the Rx
noise floor raises along with the increasing Tx gain.
But it seems in the default performance mode, the noise floor is higher
than in the powersave mode and the actual noise figure is also poorer. I'll
do some further test tomorrow and try to tweak the CPLD field options in
db_ubx.cpp.
Br, Hanwen
2016-05-19 19:47 GMT+02:00 Michael West <[email protected]>:
> Hi Hanwen,
>
> There is an issue for UBX in TDD mode of which we are aware and in the
> process of fixing. In the meantime, apply the attached patch and use the
> default (performance) power mode and let me know if it helps.
>
> Regards,
> Michael
>
> On Wed, May 18, 2016 at 9:03 PM, hanwen <[email protected]> wrote:
>
>> Dear USRP users and experts,
>>
>>
>>
>> Instructed by Michael in:
>> https://www.mail-archive.com/[email protected]/msg01766.html
>>
>> I tried the switching between powersave and performance mode for the new
>> UBX and did some further test.
>>
>>
>>
>> Basic config: 11.42MS/s, Carrier: 2.6GHz, TDMA mode with 1ms time slot
>> and one device switches between Tx and Rx every 1ms; UHD and firmware are
>> the fresh 3.9.4 release.
>>
>>
>>
>>
>>
>> *Power Save*
>>
>> *Performance*
>>
>> *Tx*
>>
>> The transmitted signal is very weak no matter what Tx gain is chosen
>>
>> The transmission is fine, but the maximum Tx power is 2~3dB lower than
>> SBX
>>
>> The device is getting very hot
>>
>> *Rx*
>>
>> The noise floor not affected by Tx
>>
>> Noise floor rising up by c.a. 7dB by setting to higher Tx gain (>21.5),
>> EVEN WHEN no transmission in Tx slot
>>
>>
>>
>> In the attachment you could see some screenshots:
>>
>> ? Tg_1.5~31.5.png: showing the rising Rx noise floor in the
>> default Performance mode
>>
>> ? Cst_performance/powersave.png: showing in the Powersave mode:
>> the constellation demodulated at another device is very poor due to weak
>> transmit power.
>>
>>
>>
>> For both powersave and performance mode we observed unacceptable problems
>> for our system, but using the older SBX-40 and SBX 120 boards we didn?t
>> observe these problems.
>>
>>
>>
>> Bests, Hanwen
>>
>>
>>
>> [image: ???? 7][image: ???? 8][image: ???? 9][image: ???? 10][image:
>> ???? 11][image: ???? 12]
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/04f2c3e0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_11.5.png
Type: image/png
Size: 24955 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/04f2c3e0/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cst_performance.png
Type: image/png
Size: 21136 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/04f2c3e0/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_21.5.png
Type: image/png
Size: 25015 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/04f2c3e0/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cst_powersave.png
Type: image/png
Size: 31677 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/04f2c3e0/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_1.5.png
Type: image/png
Size: 24942 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/04f2c3e0/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_31.5.png
Type: image/png
Size: 25055 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/04f2c3e0/attachment-0011.png>
------------------------------
Message: 13
Date: Mon, 23 May 2016 15:43:37 -0700
From: Michael West <[email protected]>
To: hanwen <[email protected]>
Cc: "[email protected]" <[email protected]>, Marcus
M?ller <[email protected]>
Subject: Re: [USRP-users] UBX Tx-to-Rx interference, Performance and
Power-Save modes
Message-ID:
<CAM4xKrqNeA-qrjWtP6Wt9N0wAk37=2v5cb9+xip5znurwhm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Hanwen,
We see the same results. Further investigation into the issue has yielded
the attached updated patch. We are still working on the issue, but please
try the patch and let me know if it improves the noise figure for you. It
should work well in performance or powersave mode.
Regards,
Michael
On Mon, May 23, 2016 at 1:35 PM, hanwen <[email protected]> wrote:
> Hi Michael,
>
> Thanks for the patch. I tried today and it fixed the issue that the Rx
> noise floor raises along with the increasing Tx gain.
> But it seems in the default performance mode, the noise floor is higher
> than in the powersave mode and the actual noise figure is also poorer. I'll
> do some further test tomorrow and try to tweak the CPLD field options in
> db_ubx.cpp.
>
> Br, Hanwen
>
> 2016-05-19 19:47 GMT+02:00 Michael West <[email protected]>:
>
>> Hi Hanwen,
>>
>> There is an issue for UBX in TDD mode of which we are aware and in the
>> process of fixing. In the meantime, apply the attached patch and use the
>> default (performance) power mode and let me know if it helps.
>>
>> Regards,
>> Michael
>>
>> On Wed, May 18, 2016 at 9:03 PM, hanwen <[email protected]> wrote:
>>
>>> Dear USRP users and experts,
>>>
>>>
>>>
>>> Instructed by Michael in:
>>> https://www.mail-archive.com/[email protected]/msg01766.html
>>>
>>> I tried the switching between powersave and performance mode for the new
>>> UBX and did some further test.
>>>
>>>
>>>
>>> Basic config: 11.42MS/s, Carrier: 2.6GHz, TDMA mode with 1ms time slot
>>> and one device switches between Tx and Rx every 1ms; UHD and firmware are
>>> the fresh 3.9.4 release.
>>>
>>>
>>>
>>>
>>>
>>> *Power Save*
>>>
>>> *Performance*
>>>
>>> *Tx*
>>>
>>> The transmitted signal is very weak no matter what Tx gain is chosen
>>>
>>> The transmission is fine, but the maximum Tx power is 2~3dB lower than
>>> SBX
>>>
>>> The device is getting very hot
>>>
>>> *Rx*
>>>
>>> The noise floor not affected by Tx
>>>
>>> Noise floor rising up by c.a. 7dB by setting to higher Tx gain (>21.5),
>>> EVEN WHEN no transmission in Tx slot
>>>
>>>
>>>
>>> In the attachment you could see some screenshots:
>>>
>>> ? Tg_1.5~31.5.png: showing the rising Rx noise floor in the
>>> default Performance mode
>>>
>>> ? Cst_performance/powersave.png: showing in the Powersave mode:
>>> the constellation demodulated at another device is very poor due to weak
>>> transmit power.
>>>
>>>
>>>
>>> For both powersave and performance mode we observed unacceptable
>>> problems for our system, but using the older SBX-40 and SBX 120 boards we
>>> didn?t observe these problems.
>>>
>>>
>>>
>>> Bests, Hanwen
>>>
>>>
>>>
>>> [image: ???? 7][image: ???? 8][image: ???? 9][image: ???? 10][image:
>>> ???? 11][image: ???? 12]
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/17d6578f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cst_performance.png
Type: image/png
Size: 21136 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/17d6578f/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cst_powersave.png
Type: image/png
Size: 31677 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/17d6578f/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_11.5.png
Type: image/png
Size: 24955 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/17d6578f/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_21.5.png
Type: image/png
Size: 25015 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/17d6578f/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_31.5.png
Type: image/png
Size: 25055 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/17d6578f/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_1.5.png
Type: image/png
Size: 24942 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/17d6578f/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ubx_tdd.patch
Type: application/force-download
Size: 3440 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/17d6578f/attachment-0001.patch>
------------------------------
Message: 14
Date: Mon, 23 May 2016 21:03:12 -0700
From: Robin Coxe <[email protected]>
To: USRP-users <[email protected]>
Cc: Shuhei Takahashi <[email protected]>
Subject: [USRP-users] Modifying the carrier wave/creating USRP2920 UHD
Message-ID:
<CAGVTi8Wa6a1P+FfwfoO1Nbt3dtB3=k5fwsbjilrdxd5bdms...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Posted on behalf of Shuhei. (cc'ed)
-------------------------------------------------
Hello all,
A question similar to the Pulse Radar question asked earlier by Avinash.
I've been working with a possible setup to create radar pulses on USRP 2920
and realized that modifying the carrier wave by modulating it with a square
wave signal is not really working. I was wondering if it possible to
somehow go into the firmware to change the carrier wave it self to say,
maybe change the oscillator going into the mixer (USRP2920 Diagram
<http://zone.ni.com/reference/en-XX/help/373380B-01/usrphelp/2920_block_diagram/>)
or maybe somehow bypass the mixer (Just have it not oscillate?).
Going further with a topic, I've seen posts that says USRP 2920 could be
used with GNU-Radio but I need to write my own UHD for it. I think this
would be great time for me to learn a lot more about the hardware,
firmware, low level side of GNU radio but honestly, I'm pretty lost and not
sure where to even begin looking, any advice on where to start with
learning more about writing the UHD would be spectacular. Thank you!
Best,
-stak
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/25f85da7/attachment-0001.html>
------------------------------
Message: 15
Date: Tue, 24 May 2016 08:00:05 +0200
From: rv pellarin <[email protected]>
To: Chris Kuethe <[email protected]>
Cc: Marcus M?ller <[email protected]>, "USRP mailing list
([email protected])" <[email protected]>
Subject: Re: [USRP-users] gr-scan & usrp
Message-ID:
<CAHLh5KFuLnQqz4J-QpWhWnR_Z7=1JvBBVjbvkeL0ji7xckR=m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
hi chris,
i am using it on windows,mostyly, but when it agree to connect on linux vm
lsusb sees it
using (on winblows) uhd_usrp_probe gives me this result:
C:\WINDOWS\system32>uhd_usrp_probe
Win32; Microsoft Visual C++ version 12.0; Boost_105600;
UHD_003.009.002-release
-- Detected Device: B205mini
-- Loading FPGA image: C:\Program Files
(x86)\UHD\share\uhd\images\usrp_b205mini_fpga.bin... done
-- Operating over USB 3.
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 16.000000 MHz...
-- Actually got clock rate 16.000000 MHz.
-- Performing timer loopback test... pass
-- Setting master clock rate selection to 'automatic'.
_____________________________________________________
/
| Device: B-Series Device
| _____________________________________________________
| /
| | Mboard: B205mini
| | revision: 1
| | product: 30522
| | serial: 30C7E1D
| | name: B205i
| | FW Version: 8.0
| | FPGA Version: 4.0
| |
| | Time sources: none, internal, external
| | Clock sources: internal, external
| | Sensors: ref_locked
| | _____________________________________________________
| | /
| | | RX DSP: 0
| | | Freq range: -8.000 to 8.000 MHz
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | _____________________________________________________
| | | /
| | | | RX Frontend: A
| | | | Name: FE-RX1
| | | | Antennas: TX/RX, RX2
| | | | Sensors: temp, rssi, lo_locked
| | | | Freq range: 50.000 to 6000.000 MHz
| | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB
| | | | Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: B205mini RX dual ADC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX DSP: 0
| | | Freq range: -8.000 to 8.000 MHz
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | _____________________________________________________
| | | /
| | | | TX Frontend: A
| | | | Name: FE-TX1
| | | | Antennas: TX/RX
| | | | Sensors: temp, lo_locked
| | | | Freq range: 50.000 to 6000.000 MHz
| | | | Gain range PGA: 0.0 to 89.8 step 0.3 dB
| | | | Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: B205mini TX dual DAC
| | | | Gain Elements: None
i am also able to use it with gqrx and gnuradio without any issues
best regards
?
On 23 May 2016 at 21:38, Chris Kuethe <[email protected]> wrote:
> OK, that's a better request. This tells us exactly what software you're
> running and gives a very strong indication of where to start debugging.
>
> "FATAL: No supported devices found to pick from."
>
> Here are some things that you can investigate
> 1) do you see the device with lsusb?
> 2) do you see the device with uhd_usrp_probe?
> 3) does this program work with any other receivers (rtlsdr)?
> 4) can you use your receiver with osmocom_fft?
> 5) can you use your receiver with uhd_fft?
>
>
> On Mon, May 23, 2016 at 11:56 AM, rv pellarin <[email protected]> wrote:
>
>> hi,
>> sorry again for my post, didn t mean to offense you, was busy with kids
>> and work, i should have wait before post.
>> so here is the soft:
>> https://github.com/pinkavaj/gr-scan
>>
>> got no error when compile, and when i run it, this is what i get as error
>> message.
>> root@kali:~/Documents/gr-scan/gr-scan-master# ./gr-scan -x 150 -y 175
>> linux; GNU C++ version 5.3.1 20160409; Boost_105800;
>> UHD_003.009.003-0-unknown
>>
>> gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.9
>> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
>> bladerf rfspace airspy redpitaya
>> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
>>
>> FATAL: No supported devices found to pick from.
>>
>> Trying to fill up 1 missing channel(s) with null source(s).
>> This is being done to prevent the application from crashing
>> due to gnuradio bug #528.
>>
>> Using Volk machine: avx_64_mmx_orc
>> gr::buffer::allocate_buffer: warning: tried to allocate
>> 4 items of size 16000. Due to alignment requirements
>> 32 were allocated. If this isn't OK, consider padding
>> your structure to a power-of-two bytes.
>> On this platform, our allocation granularity is 4096 bytes.
>> gr::buffer::allocate_buffer: warning: tried to allocate
>> 16 items of size 8000. Due to alignment requirements
>> 64 were allocated. If this isn't OK, consider padding
>> your structure to a power-of-two bytes.
>> On this platform, our allocation granularity is 4096 bytes.
>> gr::buffer::allocate_buffer: warning: tried to allocate
>> 8 items of size 8000. Due to alignment requirements
>> 64 were allocated. If this isn't OK, consider padding
>> your structure to a power-of-two bytes.
>> On this platform, our allocation granularity is 4096 bytes.
>> gr::buffer::allocate_buffer: warning: tried to allocate
>> 8 items of size 8000. Due to alignment requirements
>> 64 were allocated. If this isn't OK, consider padding
>> your structure to a power-of-two bytes.
>> On this platform, our allocation granularity is 4096 bytes.
>> ^C
>> root@kali:~/Documents/gr-scan/gr-scan-master#
>>
>>
>>
>> if you have any clues how to fix it, would be great, seems to be a nice
>> prog.
>> one thing i ve noticed, they show an example on their website with -o
>> filename.csv but in real, this option is not any longer available, pitty,
>> was handy
>>
>>
>> thxx for your time, and again, my apologies.
>> best regards
>>
>> herve
>>
>> On 23 May 2016 at 14:17, Chris Kuethe <[email protected]> wrote:
>>
>>> And rather than posting errors as screenshots (images), either copy the
>>> text either into an email or stick it on something like pastebin
>>>
>>> On Mon, May 23, 2016 at 11:01 AM, Marcus M?ller <
>>> [email protected]> wrote:
>>>
>>>> From where did you get your gr-scan? Again, Google points me to
>>>> multiple projects with that name. Which exactly is the one you are talking
>>>> about?
>>>>
>>>> Also, as I said, you need to be *descriptive*.
>>>> "A lot of errors" helps no-one at helping you. Please apply some more
>>>> effort in reporting problems.
>>>>
>>>> BR,
>>>> Marcus
>>>>
>>>>
>>>> Am 23. Mai 2016 19:21:14 MESZ, schrieb rv pellarin <[email protected]>:
>>>>>
>>>>> hi marcus,
>>>>> gr-scan is a linux executable that allow to perform quic radio scan,
>>>>> for example ./gr-scan -x 150 -y 175 , that ll automaticly scan between 150
>>>>> & 175 mhz and show result.
>>>>> unfortunately it see the usrp device but gives lots off error and fail
>>>>> to scan.
>>>>> idealy i m looking for a solution with my usr that scan and log
>>>>> automaticaly, that s why i asked you if some of you succeed to get this
>>>>> utility working :)
>>>>> thxx for your time marcus.
>>>>> best rgeards
>>>>> herve
>>>>> ?
>>>>>
>>>>> On 23 May 2016 at 18:53, Marcus M?ller <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi RV,
>>>>>>
>>>>>> I like your straightforward attitude, but:
>>>>>>
>>>>>> This sounds like you've tried something, and it failed.
>>>>>> You should definitely describe your problems in greater detail,
>>>>>> otherwise it'll be hard for people to help you.
>>>>>> For example, there's several projects out there that are called
>>>>>> gr-scan. Most of them haven't been updated/maintained in years. Which one
>>>>>> are you referring to?
>>>>>>
>>>>>> What are you trying to do?
>>>>>>
>>>>>> Generally, I'd like to encourage you to increase the descriptiveness
>>>>>> of your mailing list posts; that'll make it much easier to help you fast
>>>>>> :)
>>>>>>
>>>>>> Best regards,
>>>>>> Marcus
>>>>>>
>>>>>>
>>>>>> On 05/23/2016 06:29 PM, rv pellarin via USRP-users wrote:
>>>>>>
>>>>>> hi guys,
>>>>>> have some of you succeed using gr-scan with an usrp device?
>>>>>> best regards
>>>>>> ?
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing
>>>>>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> [email protected]
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>>
>>> --
>>> GDB has a 'break' feature; why doesn't it have 'fix' too?
>>>
>>
>>
>
>
> --
> GDB has a 'break' feature; why doesn't it have 'fix' too?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160524/1223b56a/attachment-0001.html>
------------------------------
Message: 16
Date: Tue, 24 May 2016 12:03:11 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Modifying the carrier wave/creating USRP2920
UHD
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Dear Shuhei,
those are a bunch of interesting points! So let me address these one-by-one:
> A question similar to the Pulse Radar question asked earlier by
> Avinash. I've been working with a possible setup to create radar
> pulses on USRP 2920 and realized that modifying the carrier wave by
> modulating it with a square wave signal is not really working.
Why so? If your desired pulse bandwidth is within what you can
communicate to the N210, then this /should /work. Now, I'm fully aware
that sending a single burst might not work as expected, because you need
to give the hardware time to power up, but I really don't think that on
a modern machine, 50MS/s of 8bit-samples should be impossible ? for your
pulse, you really don't need high sample resolution.
As a side note: due to the fixed 1/(pulse width)-to-range resolution
relation, SDR doesn't lend itself overly much to the very concept of
pulse radar. If you, instead of a pulse, used a chirp (or some other
high-bandwidth waveform), and used pulse compression (which is what most
low-power radars do nowadays, because you can get a much better SNR with
the same TX power), all these problems disappear.
> I was wondering if it possible to somehow go into the firmware to
> change the carrier wave it self to say, maybe change the oscillator
> going into the mixer (USRP2920 Diagram
> <http://zone.ni.com/reference/en-XX/help/373380B-01/usrphelp/2920_block_diagram/>)
That's exactly what UHD does when you tune! I don't see why you want to
bypass that?
> or maybe somehow bypass the mixer (Just have it not oscillate?).
And transmit a pulse a 0 Hz? That's not going to work.
>
> Going further with a topic, I've seen posts that says USRP 2920 could
> be used with GNU-Radio but I need to write my own UHD for it.
I think you're referring to writing your own UHD-based application. Is
that right? Is that a hard requirement? If so, why? What is it that you
need to implement?
Best regards,
Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160524/c07a3ca8/attachment-0001.html>
------------------------------
Message: 17
Date: Tue, 24 May 2016 11:28:44 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] E310 headphone jack
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Is there anything special I need to know about using the headphone jack
on the E310? I bought a 2.5mm to 3.5mm adapter for it and plugged in my
device, but the audio seems to have a lot of issues coming out in
stereo. Maybe it is the connection between the adapter jack and the
E310, but I thought I would check to make sure there isn't anything I am
missing. I am currently using a sample rate of 8k for it.
------------------------------
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 69, Issue 24
******************************************
