Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
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
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: B205mini Frequency Accuracy (Marcus M?ller)
2. Re: About Self calibration (Marcus M?ller)
3. Re: Error with multiple block output ports (Jonathon Pendlum)
4. Re: BPSK base band amplitude drift/ripple, B205 mini (Sampo Salo)
5. Re: BPSK base band amplitude drift/ripple, B205 mini
(Evert Verduin)
6. Re: Shifting frequencies (het...@iqo.uni-hannover.de)
----------------------------------------------------------------------
Message: 1
Date: Sun, 28 May 2017 22:46:21 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: carry chen <artestp...@outlook.com>, "usrp-users@lists.ettus.com"
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] B205mini Frequency Accuracy
Message-ID: <74db85c8-2d84-fb63-755d-b56e77362...@ettus.com>
Content-Type: text/plain; charset="utf-8"
Hi Carry,
I'd expect your USRP's oscillator to be measurably more physically
stable than the oscillator in your average LTE handset (but worse than
your average eNB). Could you define "very fast"? As said, any LTE
receiver has frequency correction and tracks the frequency offset. Have
you tried one of the different open source LTE implementations that are
in existence currently? gr-lte would give you an easy way to access the
structure of your LTE frames, and srsLTE tends to contain an extremely
versatile baseband implementation.
Best regards,
Marcus
On 05/28/2017 10:17 AM, carry chen wrote:
> Marcus,
>
> Thanks for your tips!
> I play with sdr lte tdd bts this days.
> lte bts need sync with each other,its is say:the frames of each bts
> need align.
> when I make my bts frame align with real lte tdd base station, I find
> that it become unalign very quick! the start sample of my bts frame is
> drift from start samples of real bts frame.
>
> So I think the clock is not good enough for lte tdd bts.
>
> Thank you very much!
>
> Best regards,
> Carry
>
>
> ???: Marcus M?ller via USRP-users
> ????: 5?25???? 04:12
> ??: Re: [USRP-users] B205mini Frequency Accuracy
> ???: usrp-users@lists.ettus.com
>
>
> Hi Carry,
>
> I'd still light to highlight the question the other Marcus asked:
>
> It's not very usual that an application needs such a high-quality
> clock source. Since no two oscillators in this universe are exactly
> the same, all practical receivers have some way to account (and often:
> correct) a clock offset! So, before you spend money, ask yourself if
> your application wouldn't need to implement something like that, anyways!
>
>
> So: what is the reason the on-board oscillator isn't good enough for you?
>
>
> Best regards,
>
> Marcus
>
>
> On 24.05.2017 21:25, carry chen via USRP-users wrote:
>
>> Steven,
>>
>>
>> Very?appreciate?for you message!
>>
>> I will try it!
>>
>>
>> ???nks all!
>>
>>
>> Carry
>>
>> *From:*Steven Knudsen <ee.k...@gmail.com> <mailto:ee.k...@gmail.com>
>> *Sent:*Wednesday, May 24, 2017 11:46:05 AM
>> *To:*carry chen
>> *Cc:*mle...@ripnet.com <mailto:mle...@ripnet.com>; Jason Matusiak;
>> USRP-users
>> *Subject:*Re: [USRP-users] B205mini Frequency Accuracy
>>
>>
>>
>> There are many options for 1 PPS or 10 MHz clock sources, it all
>> depends on where you live and how you want to get one.
>>
>>
>> You can, for example, get a GPS module from ublox, AdaFruit,
>> SparkFun, or Amazon and make your own SMA terminated cable to connect
>> to the REF input on the mini. You need to be sure that the signal
>> levels are within spec as show on the B200mini schematic, for
>> example. It may mean making a level translating circuit. Normally you
>> want to match the 50 Ohm impedance, but it?s not critical it?s exact
>> as long as the thresholds are met.
>>
>>
>> https://files.ettus.com/schematics/b200mini/
>>
>>
>> Personally, I love my Octoclock G :-)
>>
>>
>> There is support for external sources in the UHD and there are
>> example programs in the source to show you how..
>>
>>
>> Good luck,
>>
>>
>> steven
>>
>>
>>
>> Steven Knudsen, Ph.D., P.Eng.
>>
>> www. techconficio.ca <http://techconficio.ca>
>>
>> www.linkedin.com/in/knudstevenknudsen
>> <http://www.linkedin.com/in/knudstevenknudsen>
>>
>>
>> /Von einem gewissen Punkt an gibt es keine R?ckkehr mehr. Dieser
>> Punkt ist zu erreichen. - Franz Kafka/
>>
>>
>>> On May 24, 2017, at 12:25, carry chen via USRP-users
>>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>>>
>>>
>>> Thanks!
>>>
>>>
>>> I see b205mini have three sma port, one ??X/RX , one RX2, and one
>>> REF, does external clock source connect to REF sma port?
>>>
>>> Can you give me some tips where to buy the external clock source ?
>>>
>>> Does external clock source connect to port direct and the uhd is
>>> support direct?
>>>
>>> Have some body do that ?
>>>
>>>
>>> Thank you very much again!
>>>
>>> *From:* mle...@ripnet.com
>>> <mailto:mle...@ripnet.com> <mle...@ripnet.com
>>> <mailto:mle...@ripnet.com>>
>>> *Sent:* Wednesday, May 24, 2017 8:33:18 AM
>>> *To:* Jason Matusiak
>>> *Cc:* carry chen; usrp-users@lists.ettus.com
>>> <mailto:usrp-users@lists.ettus.com>
>>> *Subject:* Re: [USRP-users] Fw: B205mini Frequency Accuracy
>>>
>>>
>>>
>>> Yes, sorry if I created any confusion.
>>>
>>> The 'mini' series have no provision for an on-board GPSDO, like
>>> their big brothers do. You'd need to use an external clock source,
>>> and use the sync input on the 'mini' series.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 2017-05-24 10:45, Jason Matusiak via USRP-users wrote:
>>>
>>>> Carry, What I think Marcus means, is that you could use the
>>>> sync/clock port on the mini to get better accuracy. There is no
>>>> way to add on a GPSDO directly.
>>>>
>>>>
>>>> On 05/24/2017 01:08 AM, carry chen via USRP-users wrote:
>>>>
>>>>>
>>>>>
>>>>> Thanks, mleech,
>>>>>
>>>>>
>>>>>
>>>>> But I check the ettus website, only B210/B200/E3xx have GPSDO
>>>>> interface,
>>>>>
>>>>> Can B205mini do that?
>>>>>
>>>>> Can some body recommend some GPSD or OCXO Product use for B205mini ?
>>>>>
>>>>>
>>>>>
>>>>> Thank you very much!
>>>>>
>>>>>
>>>>>
>>>>> Carry
>>>>>
>>>>>
>>>>> *From:* mle...@ripnet.com
>>>>> <mailto:mle...@ripnet.com> <mle...@ripnet.com>
>>>>> <mailto:mle...@ripnet.com>
>>>>> *Sent:* Tuesday, May 23, 2017 12:04 PM
>>>>> *To:* carry chen
>>>>> *Cc:* usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>
>>>>> *Subject:* Re: [USRP-users] B205mini Frequency Accuracy
>>>>>
>>>>>
>>>>>
>>>>> The usual way to do that is to use an external reference
>>>>> oscillator that is better than the clock that is on-board.
>>>>>
>>>>> For example a GPSDO, or an external 10MHz OCXO source, etc.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2017-05-23 14:58, carry chen via USRP-users wrote:
>>>>>
>>>>>> Hi,list
>>>>>>
>>>>>>
>>>>>>
>>>>>> I check the b205mini datasheet and see the frequency accuracy
>>>>>> is ?2.0 ppm,
>>>>>>
>>>>>> Can I change the clock to get better frequency accuracy?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thank you very much!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Carry
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________ USRP-users mailing
>>>>> list USRP-users@lists.ettus.com
>>>>> <mailto:USRP-users@lists.ettus.com>
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>> _______________________________________________ USRP-users mailing
>> list USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>> 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/20170528/8e740411/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 28 May 2017 22:51:25 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: liu Jong <jongliu1...@gmail.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] About Self calibration
Message-ID: <024c9e25-48c9-68b8-7bab-3f6a50a5b...@ettus.com>
Content-Type: text/plain; charset="utf-8"
Hi!
Sorry, forgot to say: please try
./usrp_burn_mb_eeprom --args="addr=192.168.10.2,
type=x300,recover_mb_eeprom" --read-all
Best regards,
Marcus
On 05/27/2017 02:52 AM, liu Jong wrote:
> Hi,all
> Do you have any advice?Any suggestion is welcome.
>
>
> 2017-05-25 9:55 GMT+08:00 liu Jong <jongliu1...@gmail.com
> <mailto:jongliu1...@gmail.com>>:
>
> HI,Marcus,
> information as below:
> a sticker near the AUX I/O:
> *154573H-02L*
> then run usrp_burn_mb_eeprom:
>
> /usr/local/lib/uhd/utils$ ./usrp_burn_mb_eeprom
> --args="addr=192.168.10.2, type=x300" --read-all
> linux; GNU C++ version 4.8.4; Boost_105400;
> UHD_003.010.001.HEAD-0-g945fd653
>
> Creating USRP device from address: addr=192.168.10.2, type=x300
> -- X300 initialization sequence...
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1185.4MB/s)
> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1171.2MB/s)
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- Performing timer loopback test... pass
> Error: RuntimeError: self_cal_adc_capture_delay: Self calibration
> failed. Convergence error.
>
> will be some hardware broken?Can we start RMA?
>
> thank you.
> best regards
> Jon
>
> 2017-05-25 5:44 GMT+08:00 Marcus M?ller via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>>:
>
> Hi Jon!
>
> um,
> On 24.05.2017 04:51, liu Jong via USRP-users wrote:
>> Error: RuntimeError: self_cal_adc_capture_delay: Self
>> calibration failed. Convergence error.
> isn't very good. but: The only time I've seen that was when
> someone had overwritten the hardware revision number in EEPROM
> with a value that doesn't apply to the hardware.
>
> Can you share what the sticker at the highlighted position
> says? We should be able to figure out the right revision of
> the hardware!
>
> Revision Sticker Placement
>
> Then, find usrp_burn_mb_eeprom, and run it
> "/path/to/usrp_burn_mb_eeprom --args addr=192.168.40.2
> --read-all" (replace the addr=x.x.x.x with the IP address of
> your USRP). What does the revision eeprom content say?
>
> Best regards,
> Marcus
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <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/20170528/ea91b094/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 22621 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170528/ea91b094/attachment-0001.jpe>
------------------------------
Message: 3
Date: Mon, 29 May 2017 02:15:50 -0400
From: Jonathon Pendlum <jonathon.pend...@ettus.com>
To: "Barker, Douglas W." <douglas.bar...@jhuapl.edu>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Error with multiple block output ports
Message-ID:
<CAGdo0uTNT3sg9e8K8US0PEmfNfHyuzjUUr-UgFBz778B=26...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Try fixing these issues, especially the first one, and see if that helps:
- In uhd_rfnoc_split_stream.xml, the RX stream args defines 2 channels
instead of 3.
- In noc_block_split_stream.v, the ACTIVE_MASK on split_stream_fifo is set
to have only two active outputs.
On Fri, May 26, 2017 at 8:03 AM, Barker, Douglas W. <
douglas.bar...@jhuapl.edu> wrote:
> Jonathon,
>
>
>
> I?ve attached the XML files that I was using.
>
>
>
>
>
> Thanks!
>
> Doug
>
>
>
> *From:* Jonathon Pendlum [mailto:jonathon.pend...@ettus.com]
> *Sent:* Thursday, May 25, 2017 3:46 PM
> *To:* Barker, Douglas W.
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] Error with multiple block output ports
>
>
>
> Hi Doug,
>
>
>
> Can you share your Noc Script XML file?
>
>
>
>
>
>
>
> Jonathon
>
>
>
> On Fri, May 19, 2017 at 2:17 PM, Barker, Douglas W. via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello,
>
>
>
> I?m starting a new thread for this problem. I get an error when trying to
> use more than 2 output ports on a RFNoC block. I?ve designed a CE that has
> 9 output ports and when starting the gnuradio flowgraph it errors out.
> When I reduce the ports to 2 it works. If I increase the ports to 3 it
> errors out.
>
>
>
> I then made a simple modification to the ?noc_block_split_stream? block
> that is provided to have three output ports (also modified the associated
> XML files). It error out as well, in the same way. This test has
> Radio->DDC-SplitStream->host. Below are the messages produced by gnuradio
> when starting. Can the folks at Ettus please take a look as it appears to
> be a bug in UHD. I?ve attached the modified ?noc_block_split_stream.v?
> file so you can easily reproduce the error.
>
>
>
> Thanks
>
> Doug
>
>
>
>
>
> Generating: '/home/dm/Documents/doug_rfnoc/top_block.py'
>
>
>
> Executing: /usr/bin/python2 -u /home/dm/Documents/doug_rfnoc/top_block.py
>
>
>
> [32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 5.4.0 20160609;
> Boost_106300; UHD_4.0.0.rfnoc-devel-316-g24b98579
>
> [32;1m[INFO] [X300] [39;0mX300 initialization sequence...
>
> [32;1m[INFO] [X300] [39;0mDetermining maximum frame size...
>
> [32;1m[INFO] [X300] [39;0mMaximum frame size: 1472 bytes.
>
> [32;1m[INFO] [X300] [39;0mSetup basic communication...
>
> [32;1m[INFO] [X300] [39;0mLoading values from EEPROM...
>
> [32;1m[INFO] [X300] [39;0mSetup RF frontend clocking...
>
> [32;1m[INFO] [X300] [39;0mRadio 1x clock:200
>
> [32;1m[INFO] [RFNOC] [39;0m[DMA FIFO] Running BIST for FIFO 0...
>
> [32;1m[INFO] [RFNOC] [39;0mpass (Throughput: 1305.2MB/s)
>
> [32;1m[INFO] [RFNOC] [39;0m[DMA FIFO] Running BIST for FIFO 1...
>
> [32;1m[INFO] [RFNOC] [39;0mpass (Throughput: 1302.5MB/s)
>
> [32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
>
> [32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
>
> [32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
>
> [32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
>
> [33;1m[WARNING] [RFNOC] [39;0m[0/SplitStream_0] defines 3 input buffer
> sizes, but 1 input ports
>
> [32;1m[INFO] [CORES] [39;0mPerforming timer loopback test...
>
> [32;1m[INFO] [CORES] [39;0mTimer loopback test passed
>
> [32;1m[INFO] [CORES] [39;0mPerforming timer loopback test...
>
> [32;1m[INFO] [CORES] [39;0mTimer loopback test passed
>
> DEBUG: output item size: 8
>
> [33;1m[WARNING] [X300 RADIO] [39;0mset_rx_gain: could not apply gain for
> this daughterboard.
>
> INFO: Setting args on 0/DDC_0 (input_rate=200000000,output_
> rate=1000000,fullscale=1.0,freq=1000000.0)
>
> DEBUG: output item size: 8
>
> INFO: Setting args on 0/SplitStream_0 (gr_vlen=1)
>
> DEBUG: output item size: 8
>
> [32;1m[INFO] [RFNOC] [39;0mAssuming max packet size for 0/DDC_0
>
> [32;1m[INFO] [RFNOC] [39;0mAssuming max packet size for 0/Radio_0
>
> DEBUG: check_topology()
>
> DEBUG: RFNoC blocks with streaming ports: 1
>
> DEBUG: start(): ninputs == 0 noutputs == 3
>
> DEBUG: creating rx streamer with: gr_vlen=1,block_id=0/
> SplitStream_0,block_port0=0,block_port1=1,block_port=0
>
> DEBUG: creating rx streamer with: gr_vlen=1,block_id=0/
> SplitStream_0,block_port0=0,block_port1=1,block_port=1
>
> DEBUG: creating rx streamer with: gr_vlen=1,block_id=0/
> SplitStream_0,block_port0=0,block_port1=1,block_port=2
>
> thread[thread-per-block[0]: <block uhd_rfnoc_SplitStream (3)>]:
> LookupError: KeyError: [0/Radio_0] sr_write(): No such port: 2
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20170529/ec5c7e0e/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 29 May 2017 10:08:28 +0300
From: Sampo Salo <sampo.s...@iki.fi>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] BPSK base band amplitude drift/ripple, B205
mini
Message-ID:
<can-thxk0kjn_yfkazjmiqfezqhcc2zdas3r2sushfc6um_4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
Marcus and Leandro, thanks for your input. Nick, thanks for the solution
and also for the good explanation.
Just to sum up:
I decreased the NRZ-encoded symbol rate from 20 ks/s to 5 ks/s, and the
problem got worse (see the picture in URL below). I think that is a pretty
clear indication that the problem is caused by high pass filtering. And the
filter in question must be the DC offset rejection filter that Nick
suggested. I will look into this offset tuning stuff.
I consider this problem explained.
URL to the 5 ks/s picture:
https://ibb.co/ihFK7a
URL to the 20 ks/s picture:
https://ibb.co/dXhfca
Thanks and best regards,
Sampo
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170529/f28962c5/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 29 May 2017 09:47:59 +0200
From: Evert Verduin <e.verd...@telfort.nl>
To: Sampo Salo <sampo.s...@iki.fi>, Sampo Salo via USRP-users
<usrp-users@lists.ettus.com>, usrp-users@lists.ettus.com
Subject: Re: [USRP-users] BPSK base band amplitude drift/ripple, B205
mini
Message-ID: <1eeb9f5b-c8ea-44ea-82cb-6403daa24...@telfort.nl>
Content-Type: text/plain; charset="utf-8"
Prescramble the ingoing data with pseudonoise.
You Have a high pass problem around DC somewhere.
Are you using a PLL?
It looks like the training 1's and 0's generate overshoots. This is typical For
the above described issue.
Evert
Sampo Salo via USRP-users <usrp-users@lists.ettus.com> schreef op 29 mei 2017
09:08:28 CEST:
>Hello,
>
>Marcus and Leandro, thanks for your input. Nick, thanks for the
>solution
>and also for the good explanation.
>
>Just to sum up:
>I decreased the NRZ-encoded symbol rate from 20 ks/s to 5 ks/s, and the
>problem got worse (see the picture in URL below). I think that is a
>pretty
>clear indication that the problem is caused by high pass filtering. And
>the
>filter in question must be the DC offset rejection filter that Nick
>suggested. I will look into this offset tuning stuff.
>
>I consider this problem explained.
>
>URL to the 5 ks/s picture:
>https://ibb.co/ihFK7a
>URL to the 20 ks/s picture:
>https://ibb.co/dXhfca
>
>Thanks and best regards,
>Sampo
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>USRP-users mailing list
>USRP-users@lists.ettus.com
>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/20170529/1a0251ad/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 29 May 2017 14:57:22 +0200
From: het...@iqo.uni-hannover.de
To: Rob Kossler <rkoss...@nd.edu>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Shifting frequencies
Message-ID:
<20170529145722.horde.n3gvwnzsevllmmtyvwku...@webmail.rrzn.uni-hannover.de>
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
Hi!
Thanks for you help! This sounds like something I need! I am still new
to UHD and don't know how a lot of these things work.
to 1) Do you mean changing the center frequency by something like this:
uhd::tune_request_t tune_req(100e6, lo_offset);
usrp->set_tx_freq(tune_req);
send...
uhd::tune_request_t tune_req(105e6, lo_offset);
usrp->set_tx_freq(tune_req);
send...
I don't really know what the "lo_offset" is supposed to do. In the
end, the first frequency is set as center frequency, isn't it?
to 2) this sounds really useful. How do I generate this file? I tried
to write the samples into a dat-file the same way as I write them into
the buffer but this does not work. How does it have to look like?
Thanks for you help!
Mareike
Zitat von Rob Kossler <rkoss...@nd.edu>:
> Hi Mareike,
> I didn't look closely to know why your approach is not working. However,
> perhaps there are two other approaches you might consider.
> 1) perhaps you could use the FPGA to digitally change your frequency (using
> LO Offset)
> 2) perhaps you could generate your entire desired waveform (including all
> frequency changes) in a static baseband IQ waveform file. If this is
> possible for your application, then perhaps you could just use
> tx_samples_from_file without modification to send your waveform.
>
> Rob
>
>
> On Wed, May 24, 2017 at 5:18 AM, hetzel--- via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi!
>>
>> I want to shift my output frequency. For example I set my center frequency
>> at 100MHz and I want to send a varying frequency between 100 and 105 MHz. I
>> changed the tx_waveforms C++ code where I changed the frequency inside the
>> while-loop:
>>
>> int i = 0;
>> while (true) {
>> i++;
>> double count = static_cast<double>(i);
>>
>> if (stop_signal_called) break;
>> if (total_num_samps > 0 and num_acc_samps >= total_num_samps)
>> break;
>>
>> for (size_t n = 0; n < buff.size(); n++) {
>> double convertn = static_cast<double>(n);
>> shift[n] = (1.0 / buff.size() * convertn);
>> buff[n] = 0.15 * exp(2.0 *im* M_PI* shift[n] * count);
>> }
>>
>> num_acc_samps += tx_stream->send(
>> buffs, buff.size(), md
>> );
>> }
>>
>> This was working fine and I could define the frequency range by adjusting
>> the counter. But with higher sample rates or generating more frequencies I
>> got a lot of underflows which I could solve for static frequencies by
>> pre-calculating the buffer (outside the while-loop).
>> Now I want to pre-calculate the varying frequencies. I tried to write them
>> into an array like this:
>>
>> std::complex<float> buffer[spb][columns];
>> ...
>> for (size_t k = 0; k < columns; k++) {
>> double convertn = static_cast<double>(k);
>> shift[k] = (1.0 / columns* convertn);
>>
>> for (size_t n = 0; n < spb; n++) {
>> double count = static_cast<double>(n);
>> buffer[n][k] = 0.15 * exp(2.0 *im* M_PI* shift[k] * count);
>> }
>> }
>> int m=0;
>> while(true) {
>> m++;
>> std::vector<std::complex<float> *> buffers(channel_nums.size(),
>> &buffer[0][m]);
>> ...
>> send(...);
>> ...
>> }
>>
>> But this is generating very strange output. Instead of sweeping the
>> frequency it generates a lot of frequencies at the same time. I tried to
>> find out what is happening and started with only one column which worked.
>> But already with two columns there appeared additional peaks at +/- 10 MHz
>> with a sampling rate of 20MHz although I calculated and send only one
>> column. I did this for a couple of numbers and it generated frequencies at
>> +/-sample_rate/columns and multiples of that.
>> Do you have any solution or idea how to pre-calculate the buffers? Is it
>> possible to send parts of an array?
>> Or is there a completely different way to sweep the frequencies?
>>
>> Best regards,
>> Mareike
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 81, Issue 29
******************************************
