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: [Discuss-gnuradio] UHD & LibUSRP works with both
but...Re: 2 USRP1s, both loads firmware correctly, but only 1 can
run ANY sdr apps. Why? (Marcus M?ller)
2. Re: USRP B200 TX Max IQ Values (Ron Economos)
3. Synchronization of Tx-Rx (vingnu GNU)
4. Re: time accuracy at 100 MSps with X310 (Michael West)
5. Re: USRP B200 TX Max IQ Values (Marcus M?ller)
6. Re: Synchronization of Tx-Rx (Marcus M?ller)
7. Re: [Discuss-gnuradio] UHD & LibUSRP works with both
but...Re: 2 USRP1s, both loads firmware correctly, but only 1 can
run ANY sdr apps. Why? (Marcus M?ller)
8. Re: Synchronization of Tx-Rx (vingnu GNU)
9. Re: Synchronization of Tx-Rx (Marcus M?ller)
10. Re: [Discuss-gnuradio] UHD & LibUSRP works with both
but...Re: 2 USRP1s, both loads firmware correctly, but only 1 can
run ANY sdr apps. Why? (Sylvain Munaut)
11. Re: USRP B200 TX Max IQ Values (Ron Economos)
12. Re: USRP B200 TX Max IQ Values (Marcus M?ller)
13. Missing step for RFNOC XML build (Jason Matusiak)
----------------------------------------------------------------------
Message: 1
Date: Sun, 6 Dec 2015 23:11:19 +0100
From: Marcus M?ller <marcus.muel...@ettus.com>
To: discuss-gnura...@gnu.org, "usrp-users@lists.ettus.com"
<USRP-users@lists.ettus.com>
Subject: Re: [USRP-users] [Discuss-gnuradio] UHD & LibUSRP works with
both but...Re: 2 USRP1s, both loads firmware correctly, but only 1 can
run ANY sdr apps. Why?
Message-ID: <5664b287.4080...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Pretty much:
you can't, but you also don't have to:
1. it's not true that OpenBTS doesn't support UHD. So you're not stuck
with the long dead libusrp from GNU Radio 3.4.2. OpenBTS and GNU Radio
are completely independent projects.
2. With libusrp, as Marcus Leech mentioned, you simply can't handle two
USRPs.
This all with a grain of salt, I've never tried to use two USRP1s at
once, nor GNU Radio 3.4.2 (since when that was the recent version).
In other words: Simply use OpenBTS, OsmoTRX etc with the UHD interface
they come with. Don't try to use something that is this outdated.
Best regards,
Marcus
On 06.12.2015 23:07, Hi Hello wrote:
> Hello,
>
>
> I'm still stuck with the below described, and though Mr. Mueller forwarded
> this to the USRP-users list, I've still not been able to either post
> on that list, nor received an answer.
>
> How can I resolve the situtation?
>
> Yours Trully,
>
>
>
> Peter
>
> On Sat, Dec 5, 2015 at 3:35 AM, Hi Hello <thelive...@gmail.com
> <mailto:thelive...@gmail.com>> wrote:
>
> Marcus,
>
>
> Thank you for replying my replies inline below:
>
> On Sat, Dec 5, 2015 at 3:19 AM, Marcus M?ller
> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote:
>
> Hi Peter,
>
> wow: GNU Radio 3.4.2, that is OLD.
>
> With firmwares that old, I can really not tell from experience
> how the USB behaviour should be -- the link (and bcdDevice
> numbers) you mention might or might not apply.
>
>
> It applies because when you first plug in your USRP device, then
> provide power, and do a lsusb, ( WITHOUT LAUNCHING lsusrp or ANY
> UHD commands ), you'll come up with what Thomas Tsou posted:
>
> /Try running "lsusb -v"/
> >/>>> and look for the line bcdDevice under the fffe:0002 section. You/
> >/>>> should be seeing 0.04, which means unconfigured (high byte)
> and rev4/
> >/>>> (low byte)./
> >/>>>/
> >/>>> Thomas/
>
> //
>
> The USRP firmwares have gone through significant rework since
> the libusrp times to now work consistently with UHD. Whilst
> libusrp used to be a GNU Radio component, UHD is a standalone
> driver that can be used by software such as OpenBTS without
> needing any GNU Radio to operate.
>
>
> You don't need GNU Radio for modern OpenBTS, it integrates its
> own UHD driver interface as far as I know, which should be
> able to talk to your hardware; I might be incorrect, though -
> I've never used an USRP1 with OpenBTS.
>
>
> UHD doesn't work for USRP1 devices with certain "SDR APPs" such as
> OpenBTS, OsmoTRX, YateBTS, etc., etc.
>
> I'm including the USRP-users mailing list in this reply --
> this is really not much of a GNU Radio problem, and my hopes
> are that there are more people knowledgeable about firmware of
> that era over there. Please feel free to sign up to the list
> [1] and follow up there.
>
>
> UHD 3.10.0 even recognizes BOTH USRP1s, and loads the firmware
> successfully, but 1 of the USRP1 always fails at running ANY "SDR
> App".
>
> Why would 2 USRP1s work with both the old driver, /LibUSRP/, and
> the current driver, /UHD/, but yet 1 of the 2 always fails with
> SDR apps such as usrp_benchmark_usb.py?
> = https://www.ruby-forum.com/topic/144823
>
> I thank you for replying and the additional prospective support
> from the USRP-users Mailing list.
>
>
> Best regards,
> Marcus
>
> [1]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> Yours trully,
>
>
> Peter
>
>
>
> On 05.12.2015 01:45, Hi Hello wrote:
>> Hello,
>>
>>
>> I have 2 USRP1s, and either issuing the commands of /lsusrp/,
>> from Gnuradio-3.4.2, (to work with OpenBTS), both USRP1s
>> reports back that I have a USRP1 with WBX daughter cards.
>>
>> And of the 2 USRPs, when I run /lsusb -v/, it DOES show the
>> following correctly: /bcdDevice 1.04 /just as it should per
>> this following link: / /
>>
>> Re: [Discuss-gnuradio] Can't find firmware: std.ihx
>>
>> https://lists.gnu.org/archive/html/discuss-gnuradio/2010-07/msg00523.html
>> But if I run any SDR apps, such as /OpenBTS/, or
>> /USRP_benchmark.py/, or /USRPping/, one of the two USRP1s
>> just sits there, while the other always works correctly. When
>> I ran /USRP_benchmark.py/ on one of the USRP1s, while it
>> doesn't report back anything, I'll disconnect the power cord,
>> and then the command prompt reports back USB Protocol Errors
>> -71. The other USRP1, ( the one that works), when I pull the
>> power cord, the command line reports back fusb repeatedly and
>> it always works with NO issues.
>> Why would 2 USRP1s work correctly when loading firmware, but
>> only 1 of them can run any SDR app without errors? Both
>> USRP1s are in mint condition too and have matching Molex USB
>> connectors.
>> Please help.
>> Peter
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> discuss-gnura...@gnu.org <mailto:discuss-gnura...@gnu.org>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org <mailto:discuss-gnura...@gnu.org>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org <mailto:discuss-gnura...@gnu.org>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151206/7e14de48/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 06 Dec 2015 20:36:24 -0800
From: Ron Economos <w...@comcast.net>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B200 TX Max IQ Values
Message-ID: <56650cc8.2000...@comcast.net>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
I did some more testing on this today. First, sc16 input works fine with
both complex int8 and int16 wire format. The correct scaling from
complex float is 32768, not 2048.
The output with fc32 input and int12 wire format appears to be good on
the spectrum analyzer. The level is the same as int8 and int16 and
there's no obvious distortion. It just doesn't decode with the DVB-T2
receiver. The receiver does show a video frame occasionally, so the
signal isn't completely wrong. But it's going from 35 dB (with int8) to
38 dB (with int16) S/N to not being able to maintain lock.
A wild guess is that some of the lower bits of each int12 sample are
being lost (set to zero).
Ron
On 12/06/2015 06:34 AM, Ron Economos via USRP-users wrote:
> I'm using a sample rate of 6.85717 Msps ((8000000 * 6) / 7) and a 4X
> clock rate of 27.428572 MHz. I can see the receiver reported S/N ratio
> drop a few dB from int16 to int8 as expected.
>
> I can't seem to get sc16 input working either. I'm taking the known
> good fc32 output, multiplying by 2048 and using the Complex to IShort
> type converter block with the vector output.
>
> Ron
>
> On 12/06/2015 05:57 AM, Marcus M?ller via USRP-users wrote:
>> Hi Ron,
>> hm, that's interesting. Are you using a factor between your sample
>> rate and the master_clock_rate?
>>
>> Point is that I'd expect sc16 to really decrease quantization noise
>> compared to sc12 if you're using sufficient oversampling -- the
>> increased bit width is actually used during interpolation to the
>> master clock rate by the DSP logic, although the DAC is only 12bit.
>> Now, you say that int8 works -- that really worries me. I'm
>> scratching my head profoundly. Maybe someone else can comment on this?
>>
>> Can you try with input sc16 and output sc8?
>>
>> Cheers,
>> Marcus
>>
>> On 06.12.2015 14:48, Ron Economos via USRP-users wrote:
>>> I just gave Input Type = Complex float32 and Wire Format = Complex
>>> int12 a try here on a B210 with the DVB-T2 OFDM transmitter. The
>>> output appears to be too distorted to decode. Wire Format Complex
>>> int16 and int8 work fine.
>>>
>>> Ron
>>>
>>> On 12/06/2015 05:25 AM, Marcus M?ller via USRP-users wrote:
>>>> Ok, good news is: I can reproduce; bad news is: I can reproduce.
>>>> Running a similar flow graph:
>>>> minimal example
>>>> I get the same error; running it with "export UHD_LOG_LEVEL=1"
>>>> before yields the usual /tmp/uhd.log, which, with a bit of sed
>>>> magic, yields the following input/output table[1].
>>>> concentrating on the sc12_* output converters shows that there's
>>>> only fc32c ? sc12_item32 conversion; since converters are a bit
>>>> critical when it comes to quality assurance, I guess I can try to
>>>> come up with an untested converter quickly, but it might not happen
>>>> overly soon that we include that with the official UHD; so for the
>>>> maintime, I'm afraid my advice has only been half-good, and you'd
>>>> need to use float32 complex on the GNU Radio side.
>>>>
>>>> Best regards,
>>>> Marcus
>>>>
>>>> [1]
>>>> *input**
>>>> * *output**
>>>> *
>>>> f32 f32_item32_be
>>>> f32 f32_item32_le
>>>> f32_item32_be f32
>>>> f32_item32_le f32
>>>> fc32 fc32_item32_be
>>>> fc32 fc32_item32_be
>>>> fc32 fc32_item32_le
>>>> fc32 fc32_item32_le
>>>> fc32_item32_be fc32
>>>> fc32_item32_be fc32
>>>> fc32_item32_be fc64
>>>> fc32_item32_le fc32
>>>> fc32_item32_le fc32
>>>> fc32_item32_le fc64
>>>> fc32 sc12_item32_be
>>>> fc32 sc12_item32_le
>>>> fc32 sc16_item16_usrp1
>>>> fc32 sc16_item16_usrp1
>>>> fc32 sc16_item16_usrp1
>>>> fc32 sc16_item32_be
>>>> fc32 sc16_item32_be
>>>> fc32 sc16_item32_le
>>>> fc32 sc16_item32_le
>>>> fc32 sc8_item32_be
>>>> fc32 sc8_item32_be
>>>> fc32 sc8_item32_le
>>>> fc32 sc8_item32_le
>>>> fc64 fc32_item32_be
>>>> fc64 fc32_item32_le
>>>> fc64 sc16_item16_usrp1
>>>> fc64 sc16_item16_usrp1
>>>> fc64 sc16_item16_usrp1
>>>> fc64 sc16_item32_be
>>>> fc64 sc16_item32_be
>>>> fc64 sc16_item32_le
>>>> fc64 sc16_item32_le
>>>> fc64 sc8_item32_be
>>>> fc64 sc8_item32_be
>>>> fc64 sc8_item32_le
>>>> fc64 sc8_item32_le
>>>> item32 item32
>>>> item32 sc16_item32_be
>>>> item32 sc16_item32_le
>>>> s16_item32_be s16
>>>> s16_item32_le s16
>>>> s16 s16_item32_be
>>>> s16 s16_item32_le
>>>> s8_item32_be s8
>>>> s8_item32_le s8
>>>> s8 s8_item32_be
>>>> s8 s8_item32_le
>>>> sc12_item32_be fc32
>>>> sc12_item32_le fc32
>>>> sc16_item16_usrp1 fc32
>>>> sc16_item16_usrp1 fc32
>>>> sc16_item16_usrp1 fc32
>>>> sc16_item16_usrp1 fc64
>>>> sc16_item16_usrp1 fc64
>>>> sc16_item16_usrp1 fc64
>>>> sc16_item16_usrp1 sc16
>>>> sc16_item16_usrp1 sc16
>>>> sc16_item16_usrp1 sc16
>>>> sc16_item32_be fc32
>>>> sc16_item32_be fc32
>>>> sc16_item32_be fc32
>>>> sc16_item32_be fc64
>>>> sc16_item32_be fc64
>>>> sc16_item32_be fc64
>>>> sc16_item32_be item32
>>>> sc16_item32_be sc16
>>>> sc16_item32_be sc16
>>>> sc16_item32_le fc32
>>>> sc16_item32_le fc32
>>>> sc16_item32_le fc32
>>>> sc16_item32_le fc64
>>>> sc16_item32_le fc64
>>>> sc16_item32_le fc64
>>>> sc16_item32_le item32
>>>> sc16_item32_le sc16
>>>> sc16_item32_le sc16
>>>> sc16 sc16_item16_usrp1
>>>> sc16 sc16_item16_usrp1
>>>> sc16 sc16_item16_usrp1
>>>> sc16 sc16_item32_be
>>>> sc16 sc16_item32_be
>>>> sc16 sc16_item32_le
>>>> sc16 sc16_item32_le
>>>> sc16 sc8_item32_be
>>>> sc16 sc8_item32_be
>>>> sc16 sc8_item32_le
>>>> sc16 sc8_item32_le
>>>> sc8_item16_usrp1 fc32
>>>> sc8_item16_usrp1 fc32
>>>> sc8_item16_usrp1 fc32
>>>> sc8_item16_usrp1 fc64
>>>> sc8_item16_usrp1 fc64
>>>> sc8_item16_usrp1 fc64
>>>> sc8_item16_usrp1 sc16
>>>> sc8_item16_usrp1 sc16
>>>> sc8_item16_usrp1 sc16
>>>> sc8_item32_be fc32
>>>> sc8_item32_be fc32
>>>> sc8_item32_be fc32
>>>> sc8_item32_be fc64
>>>> sc8_item32_be fc64
>>>> sc8_item32_be fc64
>>>> sc8_item32_be sc16
>>>> sc8_item32_be sc16
>>>> sc8_item32_be sc8
>>>> sc8_item32_le fc32
>>>> sc8_item32_le fc32
>>>> sc8_item32_le fc32
>>>> sc8_item32_le fc64
>>>> sc8_item32_le fc64
>>>> sc8_item32_le fc64
>>>> sc8_item32_le sc16
>>>> sc8_item32_le sc16
>>>> sc8_item32_le sc8
>>>> sc8 sc8_item32_be
>>>> sc8 sc8_item32_le
>>>> u8_item32_be u8
>>>> u8_item32_le u8
>>>> u8 u8_item32_be
>>>> u8 u8_item32_le
>>>>
>>>>
>>>>
>>>>
>>>> On 06.12.2015 13:49, Marcus M?ller wrote:
>>>>> That's indeed a bit strange. Give me a second to verify, please.
>>>>>
>>>>> Best regards,
>>>>> Marcus
>>>>>
>>>>> On 03.12.2015 19:47, Andrew Wells wrote:
>>>>>> I'm now using the "short" file output and a "stream to vector" block to
>>>>>> deinterleave into IQ samples, along with a "complex int16" input to the
>>>>>> USRP sink. Due to my high sample rate, I need to set the OTW format to
>>>>>> sc12 to avoid underflow, but now it gives me the following error when I
>>>>>> run:
>>>>>>
>>>>>> thread[thread-per-block[2]: <block gr uhd usrp sink (1)>]: LookupError:
>>>>>> KeyError: Cannot find a conversion routine for conversion ID
>>>>>> Input format: sc16
>>>>>> Num inputs: 1
>>>>>> Output format: sc12_item32_le
>>>>>> Num outputs: 1
>>>>>>
>>>>>> Does this mean that it cannot convert from 16 bits to 12 bits? There was
>>>>>> no issue when using a complex float32 input and OTW format sc12.
>>>>>>
>>>>>> Thanks again,
>>>>>> Andrew
>>>>>> ________________________________________
>>>>>> From: Marcus M?ller [marcus.muel...@ettus.com]
>>>>>> Sent: Thursday, December 03, 2015 10:14 AM
>>>>>> To: Andrew Wells; Andrew Wells via USRP-users; Marcus D.
>>>>>> Leech;usrp-users@lists.ettus.com
>>>>>> Subject: Re: [USRP-users] USRP B200 TX Max IQ Values
>>>>>>
>>>>>> "Short" is 16 bit signed integer, so that's probably what you're looking
>>>>>> for.
>>>>>>
>>>>>> By the way, as much as a GNU Radio fanboy I might be, for this simple
>>>>>> use case the tx_samples_from_file example that we ship with UHD will do
>>>>>> the same, without GNU Radio.
>>>>>>
>>>>>> Best regards,
>>>>>> Marcus
>>>>>>
>>>>>> Am 3. Dezember 2015 17:55:08 WEZ, schrieb Andrew Wells via
>>>>>> USRP-users<usrp-users@lists.ettus.com>:
>>>>>>
>>>>>> Is there a way to get 16 bit complex values from a file? The only
>>>>>> options I see are complex, float, int, short, and byte. I have tried
>>>>>> selecting "int" as the output of the file source block but it seemed
>>>>>> like the USRP sink did not interpret it correctly and would not allow me
>>>>>> to set "sc12" as the otw format.
>>>>>> ________________________________
>>>>>>
>>>>>> From: USRP-users [usrp-users-boun...@lists.ettus.com] on behalf of
>>>>>> Marcus D. Leech via USRP-users [usrp-users@lists.ettus.com]
>>>>>> Sent: Wednesday, December 02, 2015 5:15 PM
>>>>>> To:usrp-users@lists.ettus.com
>>>>>> Subject: Re: [USRP-users] USRP B200 TX Max IQ Values
>>>>>>
>>>>>> On 12/02/2015 07:59 PM, Andrew Wells via USRP-users wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I am working on a project where my GNU Radio flowgraph is as follows:
>>>>>>
>>>>>> 16 bit int I/Q samples from a binary file -> Interleaved short to
>>>>>> complex -
>>>>>> >
>>>>>> USRP Sink with OTW format = sc12
>>>>>>
>>>>>> I have a few questions related to this setup:
>>>>>>
>>>>>> 1. Is there a better way to get 16 bit I/Q samples from a binary file
>>>>>> to the USRP? Converting to complex (32 bit float) seems like an
>>>>>> unnecessary step, considering that I am only actually sending 12 bits to
>>>>>> the USRP and 10 to the DAC.
>>>>>>
>>>>>> 2. What value stored in the binary file will correspond to the max
>>>>>> output from the DAC on the USRP? When I convert from 16 bit int to 32
>>>>>> bit float to 12 bits on the wire, then to transmit from the AD9364's 10
>>>>>> bit DAC, how do I know what range of values to write to the file?
>>>>>>
>>>>>> Thanks,
>>>>>> Andrew Wells
>>>>>> ________________________________
>>>>>>
>>>>>> USRP-users mailing list
>>>>>> USRP-users@lists.ettus.com
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>> The UHD sink will take 16-bit complex short. I think the converters
>>>>>> inside UHD will "do the right thing" to deal with getting that onto the
>>>>>> wire
>>>>>> in an appropriate way, and then the DSP logic in the B200 will scale
>>>>>> appropriately.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> 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
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> 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/20151206/f5ace046/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 3343 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151206/f5ace046/attachment-0001.png>
------------------------------
Message: 3
Date: Mon, 7 Dec 2015 10:40:14 +0530
From: vingnu GNU <vingnu...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Synchronization of Tx-Rx
Message-ID:
<camk4z1ssxgfj0s_wazswjph2gwednmazzbb51wbg4+3or0+...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Is it possible to synchronize transmitter and receiver by single LO and
also in data sheet,architecture of USRP showing it has separate Local
oscillator so main transmit and receive chain LO are derived from main LO
or these are separate Local Oscillators?
If I want to synchronize one Tx and one Rx channel how can I synchronize
from single LO?Its because of architecture diagram I got some confusion
Regards
Vingnu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151207/50a51f18/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 7 Dec 2015 01:05:15 -0800
From: Michael West <michael.w...@ettus.com>
To: Marcus M?ller <marcus.muel...@ettus.com>
Cc: Sanjoy Basak <sanjoybasa...@gmail.com>, Sanjoy Basak via
USRP-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] time accuracy at 100 MSps with X310
Message-ID:
<CAM4xKrocPXON7Y8OFapd-QsN=xpgr1rk8jb4crrcqyztjh7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Sanjoy,
The setting of the start time should be at the end of the initialization.
Try the following:
self.transmitter.set_clock_source("internal", 0)
self.transmitter.set_time_source("internal", 0)
self.transmitter.set_subdev_spec("A:0", 0)
self.receiver.set_clock_source("internal", 0)
self.receiver.set_time_source("internal", 0)
self.receiver.set_subdev_spec("B:0", 0)
self.transmitter.set_time_unknown_pps(uhd.time_spec())
time.sleep(1)
print('@TX')
print self.transmitter.get_time_last_pps(0).get_real_secs()
print('@RX')
print self.receiver.get_time_last_pps(0).get_real_secs()
self.transmitter.set_samp_rate(samp_rate)
self.receiver.set_samp_rate(samp_rate)
self.transmitter.set_gain(tx_gain, 0)
self.receiver.set_gain(rx_gain, 0)
self.transmitter.set_antenna("TX/RX", 0)
self.receiver.set_antenna("RX2", 0)
now = self.transmitter.get_time_now()
cmd_time=now+uhd.time_spec(0.5)
self.receiver.set_command_time(cmd_time)
self.transmitter.set_command_time(cmd_time)
self.transmitter.set_center_freq(f, 0)
self.receiver.set_center_freq(f, 0)
self.receiver.clear_command_time()
self.transmitter.clear_command_time()
time.sleep(1)
print('Transmitter LO')
print(self.transmitter.get_sensor('lo_locked'))
print('Receiver LO')
print(self.receiver.get_sensor('lo_locked'))
now = self.transmitter.get_time_now()
starttime = now + uhd.time_spec(0.5)
self.receiver.set_start_time(starttime)
self.transmitter.set_start_time(starttime)
print('transmitter/receiver tuning time')
print(uhd.time_spec_t.get_real_secs(cmd_time))
print('transmitter/receiver starttime')
print(uhd.time_spec_t.get_real_secs(starttime))
Also, be aware that the group delay may vary with sample rate, but it
should be consistent for a given sample rate.
Regards,
Michael
On Sun, Dec 6, 2015 at 4:43 AM, Marcus M?ller <marcus.muel...@ettus.com>
wrote:
> Well, as Michael mentioned, just setting the time source isn't sufficient;
> that only tells the device what PPS to use when setting a time; you should
> set a time using set_time_unknown_pps.
>
> Best regards,
> Marcus
>
>
> On 06.12.2015 12:57, Sanjoy Basak wrote:
>
> I also used "gpsdo" as the time and frequency reference, but the
> performance was the same.
> Could you please suggest anything else to change or test?
>
> Best regards
> Sanjoy
>
> On Sun, Dec 6, 2015 at 1:46 AM, Marcus M?ller <marcus.muel...@ettus.com>
> wrote:
>
>> Don't use "internal", but "gpsdo", if you want to use the GPSDO.
>> Best regards,
>> Marcus
>>
>>
>> Am 6. Dezember 2015 00:40:27 MEZ, schrieb Sanjoy Basak via USRP-users <
>> usrp-users@lists.ettus.com>:
>>>
>>> There are few more things I wanted to add.
>>> print self.transmitter.get_time_last_pps(0).get_real_secs() and also
>>> for RX I get 0.
>>> Transmitter and receiver LO, I got locked.
>>> I tried giving more time for transmitter and receiver starttime (eg.
>>> starttime
>>> = now + uhd.time_spec(5.5)) or 1.5 and few other values accordingly
>>> varying time.sleep.
>>> The start point of receive signal I found varying between different
>>> initiations. The result was the same as I mentioned in the first email.
>>>
>>> Regards
>>> Sanjoy
>>>
>>>
>>> On Sun, Dec 6, 2015 at 12:21 AM, Sanjoy Basak <sanjoybasa...@gmail.com>
>>> wrote:
>>>
>>>> Hi Micheal,
>>>> I am using the code as you suggested. I am putting my code here.
>>>> The start point is varying as I mentioned in my previous mail. At the
>>>> beginning I was getting underrun at 100 MSps. Then I started saving the RX
>>>> file into ramdisk. Then the problem with underrun gone. So I don't have any
>>>> kind of latency error message, but the start point is not still stable.
>>>> What the result show is, the TX and RX is not starting at the same time.
>>>> Please have a look if codewise I should change something that might
>>>> help.
>>>>
>>>>
>>>> self.transmitter.set_clock_source("internal", 0)
>>>> self.transmitter.set_time_source("internal", 0)
>>>> self.transmitter.set_subdev_spec("A:0", 0)
>>>> self.receiver.set_clock_source("internal", 0)
>>>> self.receiver.set_time_source("internal", 0)
>>>> self.receiver.set_subdev_spec("B:0", 0)
>>>>
>>>> self.transmitter.set_time_unknown_pps(uhd.time_spec())
>>>> time.sleep(0.1)
>>>> print('@TX')
>>>> print self.transmitter.get_time_last_pps(0).get_real_secs()
>>>> print('@RX')
>>>> print self.receiver.get_time_last_pps(0).get_real_secs()
>>>>
>>>> self.transmitter.set_samp_rate(samp_rate)
>>>> self.receiver.set_samp_rate(samp_rate)
>>>>
>>>> self.transmitter.set_gain(tx_gain, 0)
>>>> self.receiver.set_gain(rx_gain, 0)
>>>>
>>>> self.transmitter.set_antenna("TX/RX", 0)
>>>> self.receiver.set_antenna("RX2", 0)
>>>>
>>>> now = self.transmitter.get_time_now()
>>>> starttime = now + uhd.time_spec(1.1)
>>>> cmd_time=now+uhd.time_spec(1)
>>>>
>>>> self.receiver.set_start_time(starttime)
>>>> self.transmitter.set_start_time(starttime)
>>>>
>>>> self.receiver.set_command_time(cmd_time)
>>>> self.transmitter.set_command_time(cmd_time)
>>>>
>>>> print('transmitter/receiver starttime')
>>>> print(uhd.time_spec_t.get_real_secs(starttime))
>>>>
>>>> print('transmitter/receiver tuning time')
>>>> print(uhd.time_spec_t.get_real_secs(cmd_time))
>>>>
>>>> self.transmitter.set_center_freq(f, 0)
>>>> self.receiver.set_center_freq(f, 0)
>>>> self.receiver.clear_command_time()
>>>> self.transmitter.clear_command_time()
>>>>
>>>> time.sleep(1)
>>>> print('Transmitter LO')
>>>> print(self.transmitter.get_sensor('lo_locked'))
>>>> print('Receiver LO')
>>>> print(self.receiver.get_sensor('lo_locked'))
>>>>
>>>>
>>>>
>>>> On Sat, Dec 5, 2015 at 1:30 AM, Michael West <michael.w...@ettus.com>
>>>> wrote:
>>>>
>>>>> Hi Sanjoy,
>>>>>
>>>>> The +/- 50ns tolerance only applies to GPSDOs on separate devices. On
>>>>> the same device there will be no variance.
>>>>>
>>>>> You can use the internal (default) clock and time sources if you are
>>>>> using a single device, but you need to make sure you set the times on the
>>>>> radios. Make sure your source and sink blocks have the Sync set to
>>>>> "unknown PPS" and that will synchronize the times across the radios. And
>>>>> change the start time to be relative to the current time (i.e.
>>>>> Tx.set_start_time(Tx.get_time_now() + uhd.time_spec(1.5)).
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>> On Fri, Dec 4, 2015 at 4:16 PM, Sanjoy Basak <sanjoybasa...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Micheal,
>>>>>> I am using 1 X310, TX and RX ports on different daughterboards. TX
>>>>>> and RX is connected with a 40 cm cable and a 30 dB attenuator. I am not
>>>>>> using gps signal.
>>>>>> For time and freq reference I am using GPSDO.
>>>>>>
>>>>>> Could you please explain more about the tolerance for 1 X310 on
>>>>>> GPSDO?
>>>>>> If I am trying to get timing accuracy or a constant start time/start
>>>>>> point with 100 MSps, which means I require time accuracy of 10 ns. What I
>>>>>> mean is, if I am defining start time to be 1.5 seconds after startup with
>>>>>> (Tx.set_start_time(uhd.time_spec(1.5)) and same for Rx), both TX and RX
>>>>>> port starts exactly at that time not 10 ns after or before that and with
>>>>>> every initiation this is constant.
>>>>>> Is that possible?
>>>>>>
>>>>>> Regards
>>>>>> Sanjoy
>>>>>>
>>>>>> On Sat, Dec 5, 2015 at 12:52 AM, Michael West <michael.w...@ettus.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Hi Sanjoy,
>>>>>>>
>>>>>>> Are you looping back on the same device through a cable or over the
>>>>>>> air? If not, how are you time synchronizing the transmitter and the
>>>>>>> receiver? Are you verifying that you have a GPS lock?
>>>>>>>
>>>>>>> The GPSDO has a tolerance of about +/- 50ns once locked, so that is
>>>>>>> the tolerance of your start time if you are using separate devices for
>>>>>>> transmit and receive and are using GPSDO to synchronize their times. It
>>>>>>> may take several minutes to obtain a stable GPS lock and the time will
>>>>>>> get
>>>>>>> more accurate the longer the lock is held.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Michael
>>>>>>>
>>>>>>> On Fri, Dec 4, 2015 at 3:39 PM, Sanjoy Basak <
>>>>>>> sanjoybasa...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Michael,
>>>>>>>> I am transmitting OFDM signal and after receiving I am checking the
>>>>>>>> start point by cross correlation of Rx(receive) and Tx(transmit)
>>>>>>>> signal in
>>>>>>>> matlab.
>>>>>>>> I am saving the Rx signal in binary format. The start point of
>>>>>>>> signal, I referred as the 119th bin/ 120th bin. (or 119th/120th complex
>>>>>>>> data--which shows the start point of signal from cross correlation).
>>>>>>>> In general, what I get is, for example with 25 MSps, the start
>>>>>>>> point to be 49th (I forgot the exact number) bin and this is constant.
>>>>>>>> (from 1-48th bin all zeros)
>>>>>>>>
>>>>>>>> So, basically what I meant was, the start point I found varying and
>>>>>>>> not stable at 100 MSps.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Sanjoy
>>>>>>>>
>>>>>>>> On Sat, Dec 5, 2015 at 12:16 AM, Michael West <
>>>>>>>> michael.w...@ettus.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Sanjoy,
>>>>>>>>>
>>>>>>>>> Can you explain what a bin is and how exactly you are measuring
>>>>>>>>> the start point?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Michael
>>>>>>>>>
>>>>>>>>> On Fri, Dec 4, 2015 at 6:12 AM, Sanjoy Basak via USRP-users <
>>>>>>>>> usrp-users@lists.ettus.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>> I am trying to get time sync with 1 X310 at 100 MSps for 1Tx 1 Rx
>>>>>>>>>> with SBX-120 daughterboards. I used gpsdo as time and freq ref.
>>>>>>>>>> With my application time sync worked fine till 25 MSps. With 50
>>>>>>>>>> MSps, I got the similar problem as with 100 MSps.
>>>>>>>>>>
>>>>>>>>>> I don't see any latency error at 100 MSps. No underrun/late
>>>>>>>>>> packet. But the start point is varying.
>>>>>>>>>> For example, I took 17 measurements. I got start bin 119 -> 4
>>>>>>>>>> times; 120 ->6 times; 121 ->6 times; 122 -> 1 time;
>>>>>>>>>> So, mostly the start point is varying in between 3 bins.
>>>>>>>>>> What I require is, a constant start point, which does not vary
>>>>>>>>>> with initiations.
>>>>>>>>>>
>>>>>>>>>> I am doing offline processing. I put my matlab generated binary
>>>>>>>>>> file in ramdisk and then file open and putting into buffer and then
>>>>>>>>>> repeating the buffer for transmission. At receive side, I am storing
>>>>>>>>>> with
>>>>>>>>>> file sink and saving the file in another ramdisk. Finally processing
>>>>>>>>>> with
>>>>>>>>>> matlab.
>>>>>>>>>>
>>>>>>>>>> I am using uhd source and sink and using set_start_time for time
>>>>>>>>>> sync.
>>>>>>>>>>
>>>>>>>>>> I am using uhd 3.10 and fpga HG image.
>>>>>>>>>> Please let me know how to solve this problem and also let me know
>>>>>>>>>> if you need more information about setup.
>>>>>>>>>> My OS is ubuntu 14.4.3
>>>>>>>>>>
>>>>>>>>>> best regards
>>>>>>>>>> Sanjoy
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> USRP-users mailing list
>>>>>>>>>> USRP-users@lists.ettus.com
>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>> ------------------------------
>>>
>>> USRP-users mailing
>>> listUSRP-users@lists.ettus.comhttp://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/20151207/21c47a1a/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 7 Dec 2015 10:11:21 +0100
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B200 TX Max IQ Values
Message-ID: <56654d39.2060...@ettus.com>
Content-Type: text/plain; charset="utf-8"
Hi Ron,
> I did some more testing on this today. First, sc16 input works fine
> with both complex int8 and int16 wire format. The correct scaling from
> complex float is 32768, not 2048.
ha! Good catch.
> A wild guess is that some of the lower bits of each int12 sample are
> being lost (set to zero).
Hm, that sounds like we'll have some debugging to do.
The unit tests for converters we have in place simply do a loopback, so,
for example, they do float->sc12_item32_le->float and compare the in-
and output to be approximately the same. So, first I'll have to verify
that one.
I think I'll do the following:
1. Generate a 2**15 amplitude sine, send it as sc16->sc12
2. capture traffic, make sure the right data is sent to the device
3. if 2. succeeds, verify the right data comes out of the FX3
4. if 3. succeeds,...
Hope I can ping you about progress later on.
Cheers,
Marcus
On 07.12.2015 05:36, Ron Economos via USRP-users wrote:
> I did some more testing on this today. First, sc16 input works fine
> with both complex int8 and int16 wire format. The correct scaling from
> complex float is 32768, not 2048.
>
> The output with fc32 input and int12 wire format appears to be good on
> the spectrum analyzer. The level is the same as int8 and int16 and
> there's no obvious distortion. It just doesn't decode with the DVB-T2
> receiver. The receiver does show a video frame occasionally, so the
> signal isn't completely wrong. But it's going from 35 dB (with int8)
> to 38 dB (with int16) S/N to not being able to maintain lock.
>
> A wild guess is that some of the lower bits of each int12 sample are
> being lost (set to zero).
>
> Ron
>
> On 12/06/2015 06:34 AM, Ron Economos via USRP-users wrote:
>> I'm using a sample rate of 6.85717 Msps ((8000000 * 6) / 7) and a 4X
>> clock rate of 27.428572 MHz. I can see the receiver reported S/N
>> ratio drop a few dB from int16 to int8 as expected.
>>
>> I can't seem to get sc16 input working either. I'm taking the known
>> good fc32 output, multiplying by 2048 and using the Complex to IShort
>> type converter block with the vector output.
>>
>> Ron
>>
>> On 12/06/2015 05:57 AM, Marcus M?ller via USRP-users wrote:
>>> Hi Ron,
>>> hm, that's interesting. Are you using a factor between your sample
>>> rate and the master_clock_rate?
>>>
>>> Point is that I'd expect sc16 to really decrease quantization noise
>>> compared to sc12 if you're using sufficient oversampling -- the
>>> increased bit width is actually used during interpolation to the
>>> master clock rate by the DSP logic, although the DAC is only 12bit.
>>> Now, you say that int8 works ? that really worries me. I'm
>>> scratching my head profoundly. Maybe someone else can comment on this?
>>>
>>> Can you try with input sc16 and output sc8?
>>>
>>> Cheers,
>>> Marcus
>>>
>>> On 06.12.2015 14:48, Ron Economos via USRP-users wrote:
>>>> I just gave Input Type = Complex float32 and Wire Format = Complex
>>>> int12 a try here on a B210 with the DVB-T2 OFDM transmitter. The
>>>> output appears to be too distorted to decode. Wire Format Complex
>>>> int16 and int8 work fine.
>>>>
>>>> Ron
>>>>
>>>> On 12/06/2015 05:25 AM, Marcus M?ller via USRP-users wrote:
>>>>> Ok, good news is: I can reproduce; bad news is: I can reproduce.
>>>>> Running a similar flow graph:
>>>>> minimal example
>>>>> I get the same error; running it with "export UHD_LOG_LEVEL=1"
>>>>> before yields the usual /tmp/uhd.log, which, with a bit of sed
>>>>> magic, yields the following input/output table[1].
>>>>> concentrating on the sc12_* output converters shows that there's
>>>>> only fc32c ? sc12_item32 conversion; since converters are a bit
>>>>> critical when it comes to quality assurance, I guess I can try to
>>>>> come up with an untested converter quickly, but it might not
>>>>> happen overly soon that we include that with the official UHD; so
>>>>> for the maintime, I'm afraid my advice has only been half-good,
>>>>> and you'd need to use float32 complex on the GNU Radio side.
>>>>>
>>>>> Best regards,
>>>>> Marcus
>>>>>
>>>>> [1]
>>>>> *input**
>>>>> * *output**
>>>>> *
>>>>> f32 f32_item32_be
>>>>> f32 f32_item32_le
>>>>> f32_item32_be f32
>>>>> f32_item32_le f32
>>>>> fc32 fc32_item32_be
>>>>> fc32 fc32_item32_be
>>>>> fc32 fc32_item32_le
>>>>> fc32 fc32_item32_le
>>>>> fc32_item32_be fc32
>>>>> fc32_item32_be fc32
>>>>> fc32_item32_be fc64
>>>>> fc32_item32_le fc32
>>>>> fc32_item32_le fc32
>>>>> fc32_item32_le fc64
>>>>> fc32 sc12_item32_be
>>>>> fc32 sc12_item32_le
>>>>> fc32 sc16_item16_usrp1
>>>>> fc32 sc16_item16_usrp1
>>>>> fc32 sc16_item16_usrp1
>>>>> fc32 sc16_item32_be
>>>>> fc32 sc16_item32_be
>>>>> fc32 sc16_item32_le
>>>>> fc32 sc16_item32_le
>>>>> fc32 sc8_item32_be
>>>>> fc32 sc8_item32_be
>>>>> fc32 sc8_item32_le
>>>>> fc32 sc8_item32_le
>>>>> fc64 fc32_item32_be
>>>>> fc64 fc32_item32_le
>>>>> fc64 sc16_item16_usrp1
>>>>> fc64 sc16_item16_usrp1
>>>>> fc64 sc16_item16_usrp1
>>>>> fc64 sc16_item32_be
>>>>> fc64 sc16_item32_be
>>>>> fc64 sc16_item32_le
>>>>> fc64 sc16_item32_le
>>>>> fc64 sc8_item32_be
>>>>> fc64 sc8_item32_be
>>>>> fc64 sc8_item32_le
>>>>> fc64 sc8_item32_le
>>>>> item32 item32
>>>>> item32 sc16_item32_be
>>>>> item32 sc16_item32_le
>>>>> s16_item32_be s16
>>>>> s16_item32_le s16
>>>>> s16 s16_item32_be
>>>>> s16 s16_item32_le
>>>>> s8_item32_be s8
>>>>> s8_item32_le s8
>>>>> s8 s8_item32_be
>>>>> s8 s8_item32_le
>>>>> sc12_item32_be fc32
>>>>> sc12_item32_le fc32
>>>>> sc16_item16_usrp1 fc32
>>>>> sc16_item16_usrp1 fc32
>>>>> sc16_item16_usrp1 fc32
>>>>> sc16_item16_usrp1 fc64
>>>>> sc16_item16_usrp1 fc64
>>>>> sc16_item16_usrp1 fc64
>>>>> sc16_item16_usrp1 sc16
>>>>> sc16_item16_usrp1 sc16
>>>>> sc16_item16_usrp1 sc16
>>>>> sc16_item32_be fc32
>>>>> sc16_item32_be fc32
>>>>> sc16_item32_be fc32
>>>>> sc16_item32_be fc64
>>>>> sc16_item32_be fc64
>>>>> sc16_item32_be fc64
>>>>> sc16_item32_be item32
>>>>> sc16_item32_be sc16
>>>>> sc16_item32_be sc16
>>>>> sc16_item32_le fc32
>>>>> sc16_item32_le fc32
>>>>> sc16_item32_le fc32
>>>>> sc16_item32_le fc64
>>>>> sc16_item32_le fc64
>>>>> sc16_item32_le fc64
>>>>> sc16_item32_le item32
>>>>> sc16_item32_le sc16
>>>>> sc16_item32_le sc16
>>>>> sc16 sc16_item16_usrp1
>>>>> sc16 sc16_item16_usrp1
>>>>> sc16 sc16_item16_usrp1
>>>>> sc16 sc16_item32_be
>>>>> sc16 sc16_item32_be
>>>>> sc16 sc16_item32_le
>>>>> sc16 sc16_item32_le
>>>>> sc16 sc8_item32_be
>>>>> sc16 sc8_item32_be
>>>>> sc16 sc8_item32_le
>>>>> sc16 sc8_item32_le
>>>>> sc8_item16_usrp1 fc32
>>>>> sc8_item16_usrp1 fc32
>>>>> sc8_item16_usrp1 fc32
>>>>> sc8_item16_usrp1 fc64
>>>>> sc8_item16_usrp1 fc64
>>>>> sc8_item16_usrp1 fc64
>>>>> sc8_item16_usrp1 sc16
>>>>> sc8_item16_usrp1 sc16
>>>>> sc8_item16_usrp1 sc16
>>>>> sc8_item32_be fc32
>>>>> sc8_item32_be fc32
>>>>> sc8_item32_be fc32
>>>>> sc8_item32_be fc64
>>>>> sc8_item32_be fc64
>>>>> sc8_item32_be fc64
>>>>> sc8_item32_be sc16
>>>>> sc8_item32_be sc16
>>>>> sc8_item32_be sc8
>>>>> sc8_item32_le fc32
>>>>> sc8_item32_le fc32
>>>>> sc8_item32_le fc32
>>>>> sc8_item32_le fc64
>>>>> sc8_item32_le fc64
>>>>> sc8_item32_le fc64
>>>>> sc8_item32_le sc16
>>>>> sc8_item32_le sc16
>>>>> sc8_item32_le sc8
>>>>> sc8 sc8_item32_be
>>>>> sc8 sc8_item32_le
>>>>> u8_item32_be u8
>>>>> u8_item32_le u8
>>>>> u8 u8_item32_be
>>>>> u8 u8_item32_le
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 06.12.2015 13:49, Marcus M?ller wrote:
>>>>>> That's indeed a bit strange. Give me a second to verify, please.
>>>>>>
>>>>>> Best regards,
>>>>>> Marcus
>>>>>>
>>>>>> On 03.12.2015 19:47, Andrew Wells wrote:
>>>>>>> I'm now using the "short" file output and a "stream to vector" block to
>>>>>>> deinterleave into IQ samples, along with a "complex int16" input to the
>>>>>>> USRP sink. Due to my high sample rate, I need to set the OTW format to
>>>>>>> sc12 to avoid underflow, but now it gives me the following error when I
>>>>>>> run:
>>>>>>>
>>>>>>> thread[thread-per-block[2]: <block gr uhd usrp sink (1)>]: LookupError:
>>>>>>> KeyError: Cannot find a conversion routine for conversion ID
>>>>>>> Input format: sc16
>>>>>>> Num inputs: 1
>>>>>>> Output format: sc12_item32_le
>>>>>>> Num outputs: 1
>>>>>>>
>>>>>>> Does this mean that it cannot convert from 16 bits to 12 bits? There
>>>>>>> was no issue when using a complex float32 input and OTW format sc12.
>>>>>>>
>>>>>>> Thanks again,
>>>>>>> Andrew
>>>>>>> ________________________________________
>>>>>>> From: Marcus M?ller [marcus.muel...@ettus.com]
>>>>>>> Sent: Thursday, December 03, 2015 10:14 AM
>>>>>>> To: Andrew Wells; Andrew Wells via USRP-users; Marcus D. Leech;
>>>>>>> usrp-users@lists.ettus.com
>>>>>>> Subject: Re: [USRP-users] USRP B200 TX Max IQ Values
>>>>>>>
>>>>>>> "Short" is 16 bit signed integer, so that's probably what you're
>>>>>>> looking for.
>>>>>>>
>>>>>>> By the way, as much as a GNU Radio fanboy I might be, for this simple
>>>>>>> use case the tx_samples_from_file example that we ship with UHD will do
>>>>>>> the same, without GNU Radio.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Marcus
>>>>>>>
>>>>>>> Am 3. Dezember 2015 17:55:08 WEZ, schrieb Andrew Wells via USRP-users
>>>>>>> <usrp-users@lists.ettus.com>:
>>>>>>>
>>>>>>> Is there a way to get 16 bit complex values from a file? The only
>>>>>>> options I see are complex, float, int, short, and byte. I have tried
>>>>>>> selecting "int" as the output of the file source block but it seemed
>>>>>>> like the USRP sink did not interpret it correctly and would not allow
>>>>>>> me to set "sc12" as the otw format.
>>>>>>> ________________________________
>>>>>>>
>>>>>>> From: USRP-users [usrp-users-boun...@lists.ettus.com] on behalf of
>>>>>>> Marcus D. Leech via USRP-users [usrp-users@lists.ettus.com]
>>>>>>> Sent: Wednesday, December 02, 2015 5:15 PM
>>>>>>> To: usrp-users@lists.ettus.com
>>>>>>> Subject: Re: [USRP-users] USRP B200 TX Max IQ Values
>>>>>>>
>>>>>>> On 12/02/2015 07:59 PM, Andrew Wells via USRP-users wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I am working on a project where my GNU Radio flowgraph is as follows:
>>>>>>>
>>>>>>> 16 bit int I/Q samples from a binary file -> Interleaved short to
>>>>>>> complex -
>>>>>>> >
>>>>>>> USRP Sink with OTW format = sc12
>>>>>>>
>>>>>>> I have a few questions related to this setup:
>>>>>>>
>>>>>>> 1. Is there a better way to get 16 bit I/Q samples from a binary file
>>>>>>> to the USRP? Converting to complex (32 bit float) seems like an
>>>>>>> unnecessary step, considering that I am only actually sending 12 bits
>>>>>>> to the USRP and 10 to the DAC.
>>>>>>>
>>>>>>> 2. What value stored in the binary file will correspond to the max
>>>>>>> output from the DAC on the USRP? When I convert from 16 bit int to 32
>>>>>>> bit float to 12 bits on the wire, then to transmit from the AD9364's 10
>>>>>>> bit DAC, how do I know what range of values to write to the file?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Andrew Wells
>>>>>>> ________________________________
>>>>>>>
>>>>>>> USRP-users mailing list
>>>>>>> USRP-users@lists.ettus.com
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>
>>>>>>> The UHD sink will take 16-bit complex short. I think the converters
>>>>>>> inside UHD will "do the right thing" to deal with getting that onto the
>>>>>>> wire
>>>>>>> in an appropriate way, and then the DSP logic in the B200 will scale
>>>>>>> appropriately.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> 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
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> 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
> 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/20151207/eafe425e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 3343 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151207/eafe425e/attachment-0001.png>
------------------------------
Message: 6
Date: Mon, 7 Dec 2015 10:23:59 +0100
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Synchronization of Tx-Rx
Message-ID: <5665502f.2050...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Hi Vingnu,
what device are we talking about?
On the same device, TX and RX LO are derived from the same reference
oscillator, so they shouldn't expose a frequency offset, but a random
phase after tuning by default. For some devices, you can align phases
using timed commands.
We have a manual page about this:
http://files.ettus.com/manual/page_sync.html
If your system is not on that page, then no, your hardware can't do
that, and you'll have to estimate phase offset in software, and correct it.
Best regards,
Marcus
On 07.12.2015 06:10, vingnu GNU via USRP-users wrote:
> Hi,
> Is it possible to synchronize transmitter and receiver by single LO
> and also in data sheet,architecture of USRP showing it has separate
> Local oscillator so main transmit and receive chain LO are derived
> from main LO or these are separate Local Oscillators?
>
> If I want to synchronize one Tx and one Rx channel how can I
> synchronize from single LO?Its because of architecture diagram I got
> some confusion
>
> Regards
> Vingnu
>
>
> _______________________________________________
> 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/20151207/6254c4d8/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 7 Dec 2015 10:27:27 +0100
From: Marcus M?ller <marcus.muel...@ettus.com>
To: Hi Hello <thelive...@gmail.com>, discuss-gnura...@gnu.org,
"usrp-users@lists.ettus.com" <USRP-users@lists.ettus.com>
Subject: Re: [USRP-users] [Discuss-gnuradio] UHD & LibUSRP works with
both but...Re: 2 USRP1s, both loads firmware correctly, but only 1 can
run ANY sdr apps. Why?
Message-ID: <566550ff.7080...@ettus.com>
Content-Type: text/plain; charset="utf-8"
Hi Peter,
ah, I can see my misunderstanding now; I'll have to apologize.
If you have two USRPs with the same libusrp-compatible firmware, then
you'd be using libusrp as driver for both USRPs.
If your "second" application is not OpenBTS / doesn't rely on using this
very old driver, you can use the first USRP with libusrp firmware, and
the second with UHD firmware, and use it with SDR software that uses the
modern UHD driver. This really depends on what you want to do with the
second USRP.
Best regards,
Marcus
On 06.12.2015 23:26, Hi Hello wrote:
> Marcus,
>
>
> On Sun, Dec 6, 2015 at 4:11 PM, Marcus M?ller
> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>>wrote:
>
> Pretty much:
> you can't, but you also don't have to:
> 1. it's not true that OpenBTS doesn't support UHD. So you're not
> stuck with the long dead libusrp from GNU Radio 3.4.2. OpenBTS and
> GNU Radio are completely independent projects.
>
>
> ? The USRP1 only works with libusrp if your using either OpenBTS or
> OsmoTRX.
>
> http://openbts.org/w/index.php/USRP1 = /The official Ettus Research
> driver, UHD, does not support FPGA timestamp functionality for the
> USRP1. As a result, an alternative FPGA firmware and driver
> configuration is required for using the USRP1 with OpenBTS. The
> alternative configuration is based on a customized FPGA image and the
> now deprecated 'libusrp' driver found in early versions of GNU Radio.
> /
>
> /The last release version of GNU Radio to contain the libusrp driver
> is 3.4.2. Note that this version of GNU Radio is not maintained, and
> installation on recent Linux distributions may be difficult - detailed
> setup instructions are no longer available./
>
> /http://gnuradio.org/releases/gnuradio/gnuradio-3.4.2.tar.gz/
>
>
> ?
>
>
> 2. With libusrp, as Marcus Leech mentioned, you simply can't
> handle two USRPs.
>
>
> ? I'm NOT handling 2 USRP1s with the libusrp driver, (AT THE SAME TIME):
>
> I can connect 1 USRP1 to the computer, and run either /lsusrp/, via
> the libusrp driver, or /UHD/, and both drivers identifies the USRP1 as
> a USRP1 correctly loading the firmware, and the USRP1's LED blinks
> calmly & happily.
>
> When I connect the 2nd USRP1 to the computer, after disconnecting the
> 1st USRP1, I can run either libusrp?
>
> ? or UHD, and it too loads the firmware correctly and reports back
> that I've connected a USRP1 to the computer. The LED lights blinks
> the same as the 1st USRP1.
>
>
> BUT, whenever I attempt to run the 2nd USRP1 with ANY SDR app, such as
> *benchmark*_*usb*.*py
> ? , it always fails.?
> *
> *
>
> *
>
>
> This all with a grain of salt, I've never tried to use two USRP1s
> at once, nor GNU Radio 3.4.2 (since when that was the recent
> version).
>
> In other words: Simply use OpenBTS, OsmoTRX etc with the UHD
> interface they come with. Don't try to use something that is this
> outdated.
>
>
> ? Again, the USRP1 can't be utilized with the UHD driver as documented
> here:
>
> OpenBTS, USRP1 and UHD - SourceForge
> <http://sourceforge.net/p/openbts/mailman/message/31896213/>
> sourceforge.net <http://sourceforge.net> ? Browse ? Projects ? OpenBTS
> <https://www.google.com/search?q=openbts+usrp1&oq=openbts+usrp1&aqs=chrome..69i57j69i65j0l2.2000j0j4&sourceid=chrome&es_sm=93&ie=UTF-8#>
>
>
> *
>
>
> *
>
>
>
> Higher versions of OpenBTS work only with UHD, but USRP1 > cannot work
> with UHD as USRP1 doesn't have timestamps. Wrong - latest version
> works just fine ...
>
> ?I appreciate the assistance, but we're not there yet with the answer.
>
> Any assistance would be appreciated please :-)
>
> Yours Trully,
>
>
> Peter ?
>
>
>
> Best regards,
> Marcus
>
> On 06.12.2015 23:07, Hi Hello wrote:
>> Hello,
>>
>>
>> I'm still stuck with the below described, and though Mr. Mueller
>> forwarded
>> this to the USRP-users list, I've still not been able to either
>> post on that list, nor received an answer.
>>
>> How can I resolve the situtation?
>>
>> Yours Trully,
>>
>>
>>
>> Peter
>>
>> On Sat, Dec 5, 2015 at 3:35 AM, Hi Hello <thelive...@gmail.com
>> <mailto:thelive...@gmail.com>> wrote:
>>
>> Marcus,
>>
>>
>> Thank you for replying my replies inline below:
>>
>> On Sat, Dec 5, 2015 at 3:19 AM, Marcus M?ller
>> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>>
>> wrote:
>>
>> Hi Peter,
>>
>> wow: GNU Radio 3.4.2, that is OLD.
>>
>> With firmwares that old, I can really not tell from
>> experience how the USB behaviour should be -- the link
>> (and bcdDevice numbers) you mention might or might not
>> apply.
>>
>>
>> It applies because when you first plug in your USRP device,
>> then provide power, and do a lsusb, ( WITHOUT LAUNCHING
>> lsusrp or ANY UHD commands ), you'll come up with what Thomas
>> Tsou posted:
>>
>> /Try running "lsusb -v"/
>> >/>>> and look for the line bcdDevice under the fffe:0002
>> section. You/
>> >/>>> should be seeing 0.04, which means unconfigured (high
>> byte) and rev4/
>> >/>>> (low byte)./
>> >/>>>/
>> >/>>> Thomas/
>>
>> //
>>
>> The USRP firmwares have gone through significant rework
>> since the libusrp times to now work consistently with
>> UHD. Whilst libusrp used to be a GNU Radio component, UHD
>> is a standalone driver that can be used by software such
>> as OpenBTS without needing any GNU Radio to operate.
>>
>>
>> You don't need GNU Radio for modern OpenBTS, it
>> integrates its own UHD driver interface as far as I know,
>> which should be able to talk to your hardware; I might be
>> incorrect, though - I've never used an USRP1 with OpenBTS.
>>
>>
>> UHD doesn't work for USRP1 devices with certain "SDR APPs"
>> such as OpenBTS, OsmoTRX, YateBTS, etc., etc.
>>
>> I'm including the USRP-users mailing list in this reply
>> -- this is really not much of a GNU Radio problem, and my
>> hopes are that there are more people knowledgeable about
>> firmware of that era over there. Please feel free to sign
>> up to the list [1] and follow up there.
>>
>>
>> UHD 3.10.0 even recognizes BOTH USRP1s, and loads the
>> firmware successfully, but 1 of the USRP1 always fails at
>> running ANY "SDR App".
>>
>> Why would 2 USRP1s work with both the old driver, /LibUSRP/,
>> and the current driver, /UHD/, but yet 1 of the 2 always
>> fails with SDR apps such as usrp_benchmark_usb.py?
>> = https://www.ruby-forum.com/topic/144823
>>
>> I thank you for replying and the additional prospective
>> support from the USRP-users Mailing list.
>>
>>
>> Best regards,
>> Marcus
>>
>> [1]
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> Yours trully,
>>
>>
>> Peter
>>
>>
>>
>> On 05.12.2015 01:45, Hi Hello wrote:
>>> Hello,
>>>
>>>
>>> I have 2 USRP1s, and either issuing the commands of
>>> /lsusrp/, from Gnuradio-3.4.2, (to work with OpenBTS),
>>> both USRP1s reports back that I have a USRP1 with WBX
>>> daughter cards.
>>>
>>> And of the 2 USRPs, when I run /lsusb -v/, it DOES show
>>> the following correctly: /bcdDevice 1.04 /just as it
>>> should per this following link: / /
>>>
>>> Re: [Discuss-gnuradio] Can't find firmware: std.ihx
>>>
>>> https://lists.gnu.org/archive/html/discuss-gnuradio/2010-07/msg00523.html
>>> But if I run any SDR apps, such as /OpenBTS/, or
>>> /USRP_benchmark.py/, or /USRPping/, one of the two
>>> USRP1s just sits there, while the other always works
>>> correctly. When I ran /USRP_benchmark.py/ on one of the
>>> USRP1s, while it doesn't report back anything, I'll
>>> disconnect the power cord, and then the command prompt
>>> reports back USB Protocol Errors -71. The other USRP1, (
>>> the one that works), when I pull the power cord, the
>>> command line reports back fusb repeatedly and it always
>>> works with NO issues.
>>> Why would 2 USRP1s work correctly when loading firmware,
>>> but only 1 of them can run any SDR app without errors?
>>> Both USRP1s are in mint condition too and have matching
>>> Molex USB connectors.
>>> Please help.
>>> Peter
>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> discuss-gnura...@gnu.org <mailto:discuss-gnura...@gnu.org>
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> discuss-gnura...@gnu.org <mailto:discuss-gnura...@gnu.org>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> discuss-gnura...@gnu.org <mailto:discuss-gnura...@gnu.org>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> discuss-gnura...@gnu.org <mailto:discuss-gnura...@gnu.org>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org <mailto:discuss-gnura...@gnu.org>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151207/daf1d859/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 7 Dec 2015 15:26:02 +0530
From: vingnu GNU <vingnu...@gmail.com>
To: Marcus M?ller <marcus.muel...@ettus.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Synchronization of Tx-Rx
Message-ID:
<CAMK4Z1sTyL0iTmx4uKrSnUiZ8VSpdhRForHFLjp3Ly0nez=x...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus,
My question was on device USRP E310.
Regards
Vingnu
On Mon, Dec 7, 2015 at 2:53 PM, Marcus M?ller <usrp-users@lists.ettus.com>
wrote:
> Hi Vingnu,
>
> what device are we talking about?
> On the same device, TX and RX LO are derived from the same reference
> oscillator, so they shouldn't expose a frequency offset, but a random phase
> after tuning by default. For some devices, you can align phases using timed
> commands.
> We have a manual page about this:
> http://files.ettus.com/manual/page_sync.html
> If your system is not on that page, then no, your hardware can't do that,
> and you'll have to estimate phase offset in software, and correct it.
>
> Best regards,
> Marcus
>
>
> On 07.12.2015 06:10, vingnu GNU via USRP-users wrote:
>
> Hi,
> Is it possible to synchronize transmitter and receiver by single LO and
> also in data sheet,architecture of USRP showing it has separate Local
> oscillator so main transmit and receive chain LO are derived from main LO
> or these are separate Local Oscillators?
>
> If I want to synchronize one Tx and one Rx channel how can I synchronize
> from single LO?Its because of architecture diagram I got some confusion
>
> Regards
> Vingnu
>
>
> _______________________________________________
> USRP-users mailing
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> 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/20151207/1abc9b61/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 7 Dec 2015 11:04:17 +0100
From: Marcus M?ller <marcus.muel...@ettus.com>
To: vingnu GNU <vingnu...@gmail.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Synchronization of Tx-Rx
Message-ID: <566559a1.9090...@ettus.com>
Content-Type: text/plain; charset="utf-8"
There's no way to phase-sync the TX and RX LOs on the E310, but they are
inherently frequency synced, so a simple cross-correlation timing offset
estimator should do the trick.
Best regards,
Marcus
On 07.12.2015 10:56, vingnu GNU wrote:
> Hi Marcus,
>
> My question was on device USRP E310.
>
>
> Regards
> Vingnu
>
> On Mon, Dec 7, 2015 at 2:53 PM, Marcus M?ller
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> Hi Vingnu,
>
> what device are we talking about?
> On the same device, TX and RX LO are derived from the same
> reference oscillator, so they shouldn't expose a frequency offset,
> but a random phase after tuning by default. For some devices, you
> can align phases using timed commands.
> We have a manual page about this:
> http://files.ettus.com/manual/page_sync.html
> If your system is not on that page, then no, your hardware can't
> do that, and you'll have to estimate phase offset in software, and
> correct it.
>
> Best regards,
> Marcus
>
>
> On 07.12.2015 06:10, vingnu GNU via USRP-users wrote:
>> Hi,
>> Is it possible to synchronize transmitter and receiver by
>> single LO and also in data sheet,architecture of USRP showing it
>> has separate Local oscillator so main transmit and receive chain
>> LO are derived from main LO or these are separate Local Oscillators?
>>
>> If I want to synchronize one Tx and one Rx channel how can I
>> synchronize from single LO?Its because of architecture diagram I
>> got some confusion
>>
>> Regards
>> Vingnu
>>
>>
>> _______________________________________________
>> 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/20151207/83031092/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 7 Dec 2015 11:40:34 +0100
From: Sylvain Munaut <246...@gmail.com>
To: Marcus M?ller <marcus.muel...@ettus.com>
Cc: GNURadio Discussion List <discuss-gnura...@gnu.org>,
"usrp-users@lists.ettus.com" <USRP-users@lists.ettus.com>
Subject: Re: [USRP-users] [Discuss-gnuradio] UHD & LibUSRP works with
both but...Re: 2 USRP1s, both loads firmware correctly, but only 1 can
run ANY sdr apps. Why?
Message-ID:
<cahl+j0-ivvfx7phs-tn3x4aagt8a6thjbowgoqcldlqqzkj...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
> 1. it's not true that OpenBTS doesn't support UHD. So you're not stuck with
> the long dead libusrp from GNU Radio 3.4.2. OpenBTS and GNU Radio are
> completely independent projects.
For USRP1 you don't have a choice.
UHD support in OpenBTS (and derivatives) requires HW timestamp
supports. Which the UHD driver for the USRP1 lacks.
Only thought libusrp and a special fpga image are hw timestamps
supported on the USRP1.
Cheers,
Sylvain
------------------------------
Message: 11
Date: Mon, 07 Dec 2015 02:56:41 -0800
From: Ron Economos <w...@comcast.net>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B200 TX Max IQ Values
Message-ID: <566565e9.6050...@comcast.net>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
An additional observation with int12 wire format. Lower modulation
orders work better. I was originally testing with 256QAM. At 64QAM there
is still a massive amount of errors, but many more frames are decoded.
At 16QAM it works pretty well, but still an occasional error.
Ron
On 12/07/2015 01:11 AM, Marcus M?ller via USRP-users wrote:
> Hi Ron,
>
>> I did some more testing on this today. First, sc16 input works fine
>> with both complex int8 and int16 wire format. The correct scaling
>> from complex float is 32768, not 2048.
> ha! Good catch.
>> A wild guess is that some of the lower bits of each int12 sample are
>> being lost (set to zero).
> Hm, that sounds like we'll have some debugging to do.
> The unit tests for converters we have in place simply do a loopback,
> so, for example, they do float->sc12_item32_le->float and compare the
> in- and output to be approximately the same. So, first I'll have to
> verify that one.
>
> I think I'll do the following:
>
> 1. Generate a 2**15 amplitude sine, send it as sc16->sc12
> 2. capture traffic, make sure the right data is sent to the device
> 3. if 2. succeeds, verify the right data comes out of the FX3
> 4. if 3. succeeds,...
>
> Hope I can ping you about progress later on.
>
> Cheers,
> Marcus
>
>
> On 07.12.2015 05:36, Ron Economos via USRP-users wrote:
>> I did some more testing on this today. First, sc16 input works fine
>> with both complex int8 and int16 wire format. The correct scaling
>> from complex float is 32768, not 2048.
>>
>> The output with fc32 input and int12 wire format appears to be good
>> on the spectrum analyzer. The level is the same as int8 and int16 and
>> there's no obvious distortion. It just doesn't decode with the DVB-T2
>> receiver. The receiver does show a video frame occasionally, so the
>> signal isn't completely wrong. But it's going from 35 dB (with int8)
>> to 38 dB (with int16) S/N to not being able to maintain lock.
>>
>> A wild guess is that some of the lower bits of each int12 sample are
>> being lost (set to zero).
>>
>> Ron
>>
>> On 12/06/2015 06:34 AM, Ron Economos via USRP-users wrote:
>>> I'm using a sample rate of 6.85717 Msps ((8000000 * 6) / 7) and a 4X
>>> clock rate of 27.428572 MHz. I can see the receiver reported S/N
>>> ratio drop a few dB from int16 to int8 as expected.
>>>
>>> I can't seem to get sc16 input working either. I'm taking the known
>>> good fc32 output, multiplying by 2048 and using the Complex to
>>> IShort type converter block with the vector output.
>>>
>>> Ron
>>>
>>> On 12/06/2015 05:57 AM, Marcus M?ller via USRP-users wrote:
>>>> Hi Ron,
>>>> hm, that's interesting. Are you using a factor between your sample
>>>> rate and the master_clock_rate?
>>>>
>>>> Point is that I'd expect sc16 to really decrease quantization noise
>>>> compared to sc12 if you're using sufficient oversampling -- the
>>>> increased bit width is actually used during interpolation to the
>>>> master clock rate by the DSP logic, although the DAC is only 12bit.
>>>> Now, you say that int8 works -- that really worries me. I'm
>>>> scratching my head profoundly. Maybe someone else can comment on this?
>>>>
>>>> Can you try with input sc16 and output sc8?
>>>>
>>>> Cheers,
>>>> Marcus
>>>>
>>>> On 06.12.2015 14:48, Ron Economos via USRP-users wrote:
>>>>> I just gave Input Type = Complex float32 and Wire Format = Complex
>>>>> int12 a try here on a B210 with the DVB-T2 OFDM transmitter. The
>>>>> output appears to be too distorted to decode. Wire Format Complex
>>>>> int16 and int8 work fine.
>>>>>
>>>>> Ron
>>>>>
>>>>> On 12/06/2015 05:25 AM, Marcus M?ller via USRP-users wrote:
>>>>>> Ok, good news is: I can reproduce; bad news is: I can reproduce.
>>>>>> Running a similar flow graph:
>>>>>> minimal example
>>>>>> I get the same error; running it with "export UHD_LOG_LEVEL=1"
>>>>>> before yields the usual /tmp/uhd.log, which, with a bit of sed
>>>>>> magic, yields the following input/output table[1].
>>>>>> concentrating on the sc12_* output converters shows that there's
>>>>>> only fc32c ? sc12_item32 conversion; since converters are a bit
>>>>>> critical when it comes to quality assurance, I guess I can try to
>>>>>> come up with an untested converter quickly, but it might not
>>>>>> happen overly soon that we include that with the official UHD; so
>>>>>> for the maintime, I'm afraid my advice has only been half-good,
>>>>>> and you'd need to use float32 complex on the GNU Radio side.
>>>>>>
>>>>>> Best regards,
>>>>>> Marcus
>>>>>>
>>>>>> [1]
>>>>>> *input**
>>>>>> * *output**
>>>>>> *
>>>>>> f32 f32_item32_be
>>>>>> f32 f32_item32_le
>>>>>> f32_item32_be f32
>>>>>> f32_item32_le f32
>>>>>> fc32 fc32_item32_be
>>>>>> fc32 fc32_item32_be
>>>>>> fc32 fc32_item32_le
>>>>>> fc32 fc32_item32_le
>>>>>> fc32_item32_be fc32
>>>>>> fc32_item32_be fc32
>>>>>> fc32_item32_be fc64
>>>>>> fc32_item32_le fc32
>>>>>> fc32_item32_le fc32
>>>>>> fc32_item32_le fc64
>>>>>> fc32 sc12_item32_be
>>>>>> fc32 sc12_item32_le
>>>>>> fc32 sc16_item16_usrp1
>>>>>> fc32 sc16_item16_usrp1
>>>>>> fc32 sc16_item16_usrp1
>>>>>> fc32 sc16_item32_be
>>>>>> fc32 sc16_item32_be
>>>>>> fc32 sc16_item32_le
>>>>>> fc32 sc16_item32_le
>>>>>> fc32 sc8_item32_be
>>>>>> fc32 sc8_item32_be
>>>>>> fc32 sc8_item32_le
>>>>>> fc32 sc8_item32_le
>>>>>> fc64 fc32_item32_be
>>>>>> fc64 fc32_item32_le
>>>>>> fc64 sc16_item16_usrp1
>>>>>> fc64 sc16_item16_usrp1
>>>>>> fc64 sc16_item16_usrp1
>>>>>> fc64 sc16_item32_be
>>>>>> fc64 sc16_item32_be
>>>>>> fc64 sc16_item32_le
>>>>>> fc64 sc16_item32_le
>>>>>> fc64 sc8_item32_be
>>>>>> fc64 sc8_item32_be
>>>>>> fc64 sc8_item32_le
>>>>>> fc64 sc8_item32_le
>>>>>> item32 item32
>>>>>> item32 sc16_item32_be
>>>>>> item32 sc16_item32_le
>>>>>> s16_item32_be s16
>>>>>> s16_item32_le s16
>>>>>> s16 s16_item32_be
>>>>>> s16 s16_item32_le
>>>>>> s8_item32_be s8
>>>>>> s8_item32_le s8
>>>>>> s8 s8_item32_be
>>>>>> s8 s8_item32_le
>>>>>> sc12_item32_be fc32
>>>>>> sc12_item32_le fc32
>>>>>> sc16_item16_usrp1 fc32
>>>>>> sc16_item16_usrp1 fc32
>>>>>> sc16_item16_usrp1 fc32
>>>>>> sc16_item16_usrp1 fc64
>>>>>> sc16_item16_usrp1 fc64
>>>>>> sc16_item16_usrp1 fc64
>>>>>> sc16_item16_usrp1 sc16
>>>>>> sc16_item16_usrp1 sc16
>>>>>> sc16_item16_usrp1 sc16
>>>>>> sc16_item32_be fc32
>>>>>> sc16_item32_be fc32
>>>>>> sc16_item32_be fc32
>>>>>> sc16_item32_be fc64
>>>>>> sc16_item32_be fc64
>>>>>> sc16_item32_be fc64
>>>>>> sc16_item32_be item32
>>>>>> sc16_item32_be sc16
>>>>>> sc16_item32_be sc16
>>>>>> sc16_item32_le fc32
>>>>>> sc16_item32_le fc32
>>>>>> sc16_item32_le fc32
>>>>>> sc16_item32_le fc64
>>>>>> sc16_item32_le fc64
>>>>>> sc16_item32_le fc64
>>>>>> sc16_item32_le item32
>>>>>> sc16_item32_le sc16
>>>>>> sc16_item32_le sc16
>>>>>> sc16 sc16_item16_usrp1
>>>>>> sc16 sc16_item16_usrp1
>>>>>> sc16 sc16_item16_usrp1
>>>>>> sc16 sc16_item32_be
>>>>>> sc16 sc16_item32_be
>>>>>> sc16 sc16_item32_le
>>>>>> sc16 sc16_item32_le
>>>>>> sc16 sc8_item32_be
>>>>>> sc16 sc8_item32_be
>>>>>> sc16 sc8_item32_le
>>>>>> sc16 sc8_item32_le
>>>>>> sc8_item16_usrp1 fc32
>>>>>> sc8_item16_usrp1 fc32
>>>>>> sc8_item16_usrp1 fc32
>>>>>> sc8_item16_usrp1 fc64
>>>>>> sc8_item16_usrp1 fc64
>>>>>> sc8_item16_usrp1 fc64
>>>>>> sc8_item16_usrp1 sc16
>>>>>> sc8_item16_usrp1 sc16
>>>>>> sc8_item16_usrp1 sc16
>>>>>> sc8_item32_be fc32
>>>>>> sc8_item32_be fc32
>>>>>> sc8_item32_be fc32
>>>>>> sc8_item32_be fc64
>>>>>> sc8_item32_be fc64
>>>>>> sc8_item32_be fc64
>>>>>> sc8_item32_be sc16
>>>>>> sc8_item32_be sc16
>>>>>> sc8_item32_be sc8
>>>>>> sc8_item32_le fc32
>>>>>> sc8_item32_le fc32
>>>>>> sc8_item32_le fc32
>>>>>> sc8_item32_le fc64
>>>>>> sc8_item32_le fc64
>>>>>> sc8_item32_le fc64
>>>>>> sc8_item32_le sc16
>>>>>> sc8_item32_le sc16
>>>>>> sc8_item32_le sc8
>>>>>> sc8 sc8_item32_be
>>>>>> sc8 sc8_item32_le
>>>>>> u8_item32_be u8
>>>>>> u8_item32_le u8
>>>>>> u8 u8_item32_be
>>>>>> u8 u8_item32_le
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 06.12.2015 13:49, Marcus M?ller wrote:
>>>>>>> That's indeed a bit strange. Give me a second to verify, please.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Marcus
>>>>>>>
>>>>>>> On 03.12.2015 19:47, Andrew Wells wrote:
>>>>>>>> I'm now using the "short" file output and a "stream to vector" block
>>>>>>>> to deinterleave into IQ samples, along with a "complex int16" input to
>>>>>>>> the USRP sink. Due to my high sample rate, I need to set the OTW
>>>>>>>> format to sc12 to avoid underflow, but now it gives me the following
>>>>>>>> error when I run:
>>>>>>>>
>>>>>>>> thread[thread-per-block[2]: <block gr uhd usrp sink (1)>]:
>>>>>>>> LookupError: KeyError: Cannot find a conversion routine for conversion
>>>>>>>> ID
>>>>>>>> Input format: sc16
>>>>>>>> Num inputs: 1
>>>>>>>> Output format: sc12_item32_le
>>>>>>>> Num outputs: 1
>>>>>>>>
>>>>>>>> Does this mean that it cannot convert from 16 bits to 12 bits? There
>>>>>>>> was no issue when using a complex float32 input and OTW format sc12.
>>>>>>>>
>>>>>>>> Thanks again,
>>>>>>>> Andrew
>>>>>>>> ________________________________________
>>>>>>>> From: Marcus M?ller [marcus.muel...@ettus.com]
>>>>>>>> Sent: Thursday, December 03, 2015 10:14 AM
>>>>>>>> To: Andrew Wells; Andrew Wells via USRP-users; Marcus D.
>>>>>>>> Leech;usrp-users@lists.ettus.com
>>>>>>>> Subject: Re: [USRP-users] USRP B200 TX Max IQ Values
>>>>>>>>
>>>>>>>> "Short" is 16 bit signed integer, so that's probably what you're
>>>>>>>> looking for.
>>>>>>>>
>>>>>>>> By the way, as much as a GNU Radio fanboy I might be, for this simple
>>>>>>>> use case the tx_samples_from_file example that we ship with UHD will
>>>>>>>> do the same, without GNU Radio.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Marcus
>>>>>>>>
>>>>>>>> Am 3. Dezember 2015 17:55:08 WEZ, schrieb Andrew Wells via
>>>>>>>> USRP-users<usrp-users@lists.ettus.com>:
>>>>>>>>
>>>>>>>> Is there a way to get 16 bit complex values from a file? The only
>>>>>>>> options I see are complex, float, int, short, and byte. I have tried
>>>>>>>> selecting "int" as the output of the file source block but it seemed
>>>>>>>> like the USRP sink did not interpret it correctly and would not allow
>>>>>>>> me to set "sc12" as the otw format.
>>>>>>>> ________________________________
>>>>>>>>
>>>>>>>> From: USRP-users [usrp-users-boun...@lists.ettus.com] on behalf of
>>>>>>>> Marcus D. Leech via USRP-users [usrp-users@lists.ettus.com]
>>>>>>>> Sent: Wednesday, December 02, 2015 5:15 PM
>>>>>>>> To:usrp-users@lists.ettus.com
>>>>>>>> Subject: Re: [USRP-users] USRP B200 TX Max IQ Values
>>>>>>>>
>>>>>>>> On 12/02/2015 07:59 PM, Andrew Wells via USRP-users wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I am working on a project where my GNU Radio flowgraph is as follows:
>>>>>>>>
>>>>>>>> 16 bit int I/Q samples from a binary file -> Interleaved short to
>>>>>>>> complex -
>>>>>>>> >
>>>>>>>> USRP Sink with OTW format = sc12
>>>>>>>>
>>>>>>>> I have a few questions related to this setup:
>>>>>>>>
>>>>>>>> 1. Is there a better way to get 16 bit I/Q samples from a binary
>>>>>>>> file to the USRP? Converting to complex (32 bit float) seems like an
>>>>>>>> unnecessary step, considering that I am only actually sending 12 bits
>>>>>>>> to the USRP and 10 to the DAC.
>>>>>>>>
>>>>>>>> 2. What value stored in the binary file will correspond to the max
>>>>>>>> output from the DAC on the USRP? When I convert from 16 bit int to 32
>>>>>>>> bit float to 12 bits on the wire, then to transmit from the AD9364's
>>>>>>>> 10 bit DAC, how do I know what range of values to write to the file?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Andrew Wells
>>>>>>>> ________________________________
>>>>>>>>
>>>>>>>> USRP-users mailing list
>>>>>>>> USRP-users@lists.ettus.com
>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>
>>>>>>>> The UHD sink will take 16-bit complex short. I think the converters
>>>>>>>> inside UHD will "do the right thing" to deal with getting that onto
>>>>>>>> the wire
>>>>>>>> in an appropriate way, and then the DSP logic in the B200 will
>>>>>>>> scale
>>>>>>>> appropriately.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151207/bc0e5b74/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 3343 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151207/bc0e5b74/attachment-0001.png>
------------------------------
Message: 12
Date: Mon, 7 Dec 2015 12:01:02 +0100
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B200 TX Max IQ Values
Message-ID: <566566ee.7050...@ettus.com>
Content-Type: text/plain; charset="utf-8"
... which aligns well with your suspicion of lower bits being
distorted... hm...
On 07.12.2015 11:56, Ron Economos via USRP-users wrote:
> An additional observation with int12 wire format. Lower modulation
> orders work better. I was originally testing with 256QAM. At 64QAM
> there is still a massive amount of errors, but many more frames are
> decoded. At 16QAM it works pretty well, but still an occasional error.
>
> Ron
>
> On 12/07/2015 01:11 AM, Marcus M?ller via USRP-users wrote:
>> Hi Ron,
>>
>>> I did some more testing on this today. First, sc16 input works fine
>>> with both complex int8 and int16 wire format. The correct scaling
>>> from complex float is 32768, not 2048.
>> ha! Good catch.
>>> A wild guess is that some of the lower bits of each int12 sample are
>>> being lost (set to zero).
>> Hm, that sounds like we'll have some debugging to do.
>> The unit tests for converters we have in place simply do a loopback,
>> so, for example, they do float->sc12_item32_le->float and compare the
>> in- and output to be approximately the same. So, first I'll have to
>> verify that one.
>>
>> I think I'll do the following:
>>
>> 1. Generate a 2**15 amplitude sine, send it as sc16->sc12
>> 2. capture traffic, make sure the right data is sent to the device
>> 3. if 2. succeeds, verify the right data comes out of the FX3
>> 4. if 3. succeeds,...
>>
>> Hope I can ping you about progress later on.
>>
>> Cheers,
>> Marcus
>>
>>
>> On 07.12.2015 05:36, Ron Economos via USRP-users wrote:
>>> I did some more testing on this today. First, sc16 input works fine
>>> with both complex int8 and int16 wire format. The correct scaling
>>> from complex float is 32768, not 2048.
>>>
>>> The output with fc32 input and int12 wire format appears to be good
>>> on the spectrum analyzer. The level is the same as int8 and int16
>>> and there's no obvious distortion. It just doesn't decode with the
>>> DVB-T2 receiver. The receiver does show a video frame occasionally,
>>> so the signal isn't completely wrong. But it's going from 35 dB
>>> (with int8) to 38 dB (with int16) S/N to not being able to maintain
>>> lock.
>>>
>>> A wild guess is that some of the lower bits of each int12 sample are
>>> being lost (set to zero).
>>>
>>> Ron
>>>
>>> On 12/06/2015 06:34 AM, Ron Economos via USRP-users wrote:
>>>> I'm using a sample rate of 6.85717 Msps ((8000000 * 6) / 7) and a
>>>> 4X clock rate of 27.428572 MHz. I can see the receiver reported S/N
>>>> ratio drop a few dB from int16 to int8 as expected.
>>>>
>>>> I can't seem to get sc16 input working either. I'm taking the known
>>>> good fc32 output, multiplying by 2048 and using the Complex to
>>>> IShort type converter block with the vector output.
>>>>
>>>> Ron
>>>>
>>>> On 12/06/2015 05:57 AM, Marcus M?ller via USRP-users wrote:
>>>>> Hi Ron,
>>>>> hm, that's interesting. Are you using a factor between your sample
>>>>> rate and the master_clock_rate?
>>>>>
>>>>> Point is that I'd expect sc16 to really decrease quantization
>>>>> noise compared to sc12 if you're using sufficient oversampling --
>>>>> the increased bit width is actually used during interpolation to
>>>>> the master clock rate by the DSP logic, although the DAC is only
>>>>> 12bit.
>>>>> Now, you say that int8 works ? that really worries me. I'm
>>>>> scratching my head profoundly. Maybe someone else can comment on this?
>>>>>
>>>>> Can you try with input sc16 and output sc8?
>>>>>
>>>>> Cheers,
>>>>> Marcus
>>>>>
>>>>> On 06.12.2015 14:48, Ron Economos via USRP-users wrote:
>>>>>> I just gave Input Type = Complex float32 and Wire Format =
>>>>>> Complex int12 a try here on a B210 with the DVB-T2 OFDM
>>>>>> transmitter. The output appears to be too distorted to decode.
>>>>>> Wire Format Complex int16 and int8 work fine.
>>>>>>
>>>>>> Ron
>>>>>>
>>>>>> On 12/06/2015 05:25 AM, Marcus M?ller via USRP-users wrote:
>>>>>>> Ok, good news is: I can reproduce; bad news is: I can reproduce.
>>>>>>> Running a similar flow graph:
>>>>>>> minimal example
>>>>>>> I get the same error; running it with "export UHD_LOG_LEVEL=1"
>>>>>>> before yields the usual /tmp/uhd.log, which, with a bit of sed
>>>>>>> magic, yields the following input/output table[1].
>>>>>>> concentrating on the sc12_* output converters shows that there's
>>>>>>> only fc32c ? sc12_item32 conversion; since converters are a bit
>>>>>>> critical when it comes to quality assurance, I guess I can try
>>>>>>> to come up with an untested converter quickly, but it might not
>>>>>>> happen overly soon that we include that with the official UHD;
>>>>>>> so for the maintime, I'm afraid my advice has only been
>>>>>>> half-good, and you'd need to use float32 complex on the GNU
>>>>>>> Radio side.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Marcus
>>>>>>>
>>>>>>> [1]
>>>>>>> *input**
>>>>>>> * *output**
>>>>>>> *
>>>>>>> f32 f32_item32_be
>>>>>>> f32 f32_item32_le
>>>>>>> f32_item32_be f32
>>>>>>> f32_item32_le f32
>>>>>>> fc32 fc32_item32_be
>>>>>>> fc32 fc32_item32_be
>>>>>>> fc32 fc32_item32_le
>>>>>>> fc32 fc32_item32_le
>>>>>>> fc32_item32_be fc32
>>>>>>> fc32_item32_be fc32
>>>>>>> fc32_item32_be fc64
>>>>>>> fc32_item32_le fc32
>>>>>>> fc32_item32_le fc32
>>>>>>> fc32_item32_le fc64
>>>>>>> fc32 sc12_item32_be
>>>>>>> fc32 sc12_item32_le
>>>>>>> fc32 sc16_item16_usrp1
>>>>>>> fc32 sc16_item16_usrp1
>>>>>>> fc32 sc16_item16_usrp1
>>>>>>> fc32 sc16_item32_be
>>>>>>> fc32 sc16_item32_be
>>>>>>> fc32 sc16_item32_le
>>>>>>> fc32 sc16_item32_le
>>>>>>> fc32 sc8_item32_be
>>>>>>> fc32 sc8_item32_be
>>>>>>> fc32 sc8_item32_le
>>>>>>> fc32 sc8_item32_le
>>>>>>> fc64 fc32_item32_be
>>>>>>> fc64 fc32_item32_le
>>>>>>> fc64 sc16_item16_usrp1
>>>>>>> fc64 sc16_item16_usrp1
>>>>>>> fc64 sc16_item16_usrp1
>>>>>>> fc64 sc16_item32_be
>>>>>>> fc64 sc16_item32_be
>>>>>>> fc64 sc16_item32_le
>>>>>>> fc64 sc16_item32_le
>>>>>>> fc64 sc8_item32_be
>>>>>>> fc64 sc8_item32_be
>>>>>>> fc64 sc8_item32_le
>>>>>>> fc64 sc8_item32_le
>>>>>>> item32 item32
>>>>>>> item32 sc16_item32_be
>>>>>>> item32 sc16_item32_le
>>>>>>> s16_item32_be s16
>>>>>>> s16_item32_le s16
>>>>>>> s16 s16_item32_be
>>>>>>> s16 s16_item32_le
>>>>>>> s8_item32_be s8
>>>>>>> s8_item32_le s8
>>>>>>> s8 s8_item32_be
>>>>>>> s8 s8_item32_le
>>>>>>> sc12_item32_be fc32
>>>>>>> sc12_item32_le fc32
>>>>>>> sc16_item16_usrp1 fc32
>>>>>>> sc16_item16_usrp1 fc32
>>>>>>> sc16_item16_usrp1 fc32
>>>>>>> sc16_item16_usrp1 fc64
>>>>>>> sc16_item16_usrp1 fc64
>>>>>>> sc16_item16_usrp1 fc64
>>>>>>> sc16_item16_usrp1 sc16
>>>>>>> sc16_item16_usrp1 sc16
>>>>>>> sc16_item16_usrp1 sc16
>>>>>>> sc16_item32_be fc32
>>>>>>> sc16_item32_be fc32
>>>>>>> sc16_item32_be fc32
>>>>>>> sc16_item32_be fc64
>>>>>>> sc16_item32_be fc64
>>>>>>> sc16_item32_be fc64
>>>>>>> sc16_item32_be item32
>>>>>>> sc16_item32_be sc16
>>>>>>> sc16_item32_be sc16
>>>>>>> sc16_item32_le fc32
>>>>>>> sc16_item32_le fc32
>>>>>>> sc16_item32_le fc32
>>>>>>> sc16_item32_le fc64
>>>>>>> sc16_item32_le fc64
>>>>>>> sc16_item32_le fc64
>>>>>>> sc16_item32_le item32
>>>>>>> sc16_item32_le sc16
>>>>>>> sc16_item32_le sc16
>>>>>>> sc16 sc16_item16_usrp1
>>>>>>> sc16 sc16_item16_usrp1
>>>>>>> sc16 sc16_item16_usrp1
>>>>>>> sc16 sc16_item32_be
>>>>>>> sc16 sc16_item32_be
>>>>>>> sc16 sc16_item32_le
>>>>>>> sc16 sc16_item32_le
>>>>>>> sc16 sc8_item32_be
>>>>>>> sc16 sc8_item32_be
>>>>>>> sc16 sc8_item32_le
>>>>>>> sc16 sc8_item32_le
>>>>>>> sc8_item16_usrp1 fc32
>>>>>>> sc8_item16_usrp1 fc32
>>>>>>> sc8_item16_usrp1 fc32
>>>>>>> sc8_item16_usrp1 fc64
>>>>>>> sc8_item16_usrp1 fc64
>>>>>>> sc8_item16_usrp1 fc64
>>>>>>> sc8_item16_usrp1 sc16
>>>>>>> sc8_item16_usrp1 sc16
>>>>>>> sc8_item16_usrp1 sc16
>>>>>>> sc8_item32_be fc32
>>>>>>> sc8_item32_be fc32
>>>>>>> sc8_item32_be fc32
>>>>>>> sc8_item32_be fc64
>>>>>>> sc8_item32_be fc64
>>>>>>> sc8_item32_be fc64
>>>>>>> sc8_item32_be sc16
>>>>>>> sc8_item32_be sc16
>>>>>>> sc8_item32_be sc8
>>>>>>> sc8_item32_le fc32
>>>>>>> sc8_item32_le fc32
>>>>>>> sc8_item32_le fc32
>>>>>>> sc8_item32_le fc64
>>>>>>> sc8_item32_le fc64
>>>>>>> sc8_item32_le fc64
>>>>>>> sc8_item32_le sc16
>>>>>>> sc8_item32_le sc16
>>>>>>> sc8_item32_le sc8
>>>>>>> sc8 sc8_item32_be
>>>>>>> sc8 sc8_item32_le
>>>>>>> u8_item32_be u8
>>>>>>> u8_item32_le u8
>>>>>>> u8 u8_item32_be
>>>>>>> u8 u8_item32_le
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 06.12.2015 13:49, Marcus M?ller wrote:
>>>>>>>> That's indeed a bit strange. Give me a second to verify, please.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Marcus
>>>>>>>>
>>>>>>>> On 03.12.2015 19:47, Andrew Wells wrote:
>>>>>>>>> I'm now using the "short" file output and a "stream to vector" block
>>>>>>>>> to deinterleave into IQ samples, along with a "complex int16" input
>>>>>>>>> to the USRP sink. Due to my high sample rate, I need to set the OTW
>>>>>>>>> format to sc12 to avoid underflow, but now it gives me the following
>>>>>>>>> error when I run:
>>>>>>>>>
>>>>>>>>> thread[thread-per-block[2]: <block gr uhd usrp sink (1)>]:
>>>>>>>>> LookupError: KeyError: Cannot find a conversion routine for
>>>>>>>>> conversion ID
>>>>>>>>> Input format: sc16
>>>>>>>>> Num inputs: 1
>>>>>>>>> Output format: sc12_item32_le
>>>>>>>>> Num outputs: 1
>>>>>>>>>
>>>>>>>>> Does this mean that it cannot convert from 16 bits to 12 bits? There
>>>>>>>>> was no issue when using a complex float32 input and OTW format sc12.
>>>>>>>>>
>>>>>>>>> Thanks again,
>>>>>>>>> Andrew
>>>>>>>>> ________________________________________
>>>>>>>>> From: Marcus M?ller [marcus.muel...@ettus.com]
>>>>>>>>> Sent: Thursday, December 03, 2015 10:14 AM
>>>>>>>>> To: Andrew Wells; Andrew Wells via USRP-users; Marcus D. Leech;
>>>>>>>>> usrp-users@lists.ettus.com
>>>>>>>>> Subject: Re: [USRP-users] USRP B200 TX Max IQ Values
>>>>>>>>>
>>>>>>>>> "Short" is 16 bit signed integer, so that's probably what you're
>>>>>>>>> looking for.
>>>>>>>>>
>>>>>>>>> By the way, as much as a GNU Radio fanboy I might be, for this simple
>>>>>>>>> use case the tx_samples_from_file example that we ship with UHD will
>>>>>>>>> do the same, without GNU Radio.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Marcus
>>>>>>>>>
>>>>>>>>> Am 3. Dezember 2015 17:55:08 WEZ, schrieb Andrew Wells via USRP-users
>>>>>>>>> <usrp-users@lists.ettus.com>:
>>>>>>>>>
>>>>>>>>> Is there a way to get 16 bit complex values from a file? The only
>>>>>>>>> options I see are complex, float, int, short, and byte. I have tried
>>>>>>>>> selecting "int" as the output of the file source block but it seemed
>>>>>>>>> like the USRP sink did not interpret it correctly and would not allow
>>>>>>>>> me to set "sc12" as the otw format.
>>>>>>>>> ________________________________
>>>>>>>>>
>>>>>>>>> From: USRP-users [usrp-users-boun...@lists.ettus.com] on behalf of
>>>>>>>>> Marcus D. Leech via USRP-users [usrp-users@lists.ettus.com]
>>>>>>>>> Sent: Wednesday, December 02, 2015 5:15 PM
>>>>>>>>> To: usrp-users@lists.ettus.com
>>>>>>>>> Subject: Re: [USRP-users] USRP B200 TX Max IQ Values
>>>>>>>>>
>>>>>>>>> On 12/02/2015 07:59 PM, Andrew Wells via USRP-users wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I am working on a project where my GNU Radio flowgraph is as follows:
>>>>>>>>>
>>>>>>>>> 16 bit int I/Q samples from a binary file -> Interleaved short to
>>>>>>>>> complex -
>>>>>>>>> >
>>>>>>>>> USRP Sink with OTW format = sc12
>>>>>>>>>
>>>>>>>>> I have a few questions related to this setup:
>>>>>>>>>
>>>>>>>>> 1. Is there a better way to get 16 bit I/Q samples from a binary
>>>>>>>>> file to the USRP? Converting to complex (32 bit float) seems like an
>>>>>>>>> unnecessary step, considering that I am only actually sending 12 bits
>>>>>>>>> to the USRP and 10 to the DAC.
>>>>>>>>>
>>>>>>>>> 2. What value stored in the binary file will correspond to the max
>>>>>>>>> output from the DAC on the USRP? When I convert from 16 bit int to 32
>>>>>>>>> bit float to 12 bits on the wire, then to transmit from the AD9364's
>>>>>>>>> 10 bit DAC, how do I know what range of values to write to the file?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Andrew Wells
>>>>>>>>> ________________________________
>>>>>>>>>
>>>>>>>>> USRP-users mailing list
>>>>>>>>> USRP-users@lists.ettus.com
>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>
>>>>>>>>> The UHD sink will take 16-bit complex short. I think the converters
>>>>>>>>> inside UHD will "do the right thing" to deal with getting that onto
>>>>>>>>> the wire
>>>>>>>>> in an appropriate way, and then the DSP logic in the B200 will
>>>>>>>>> scale
>>>>>>>>> appropriately.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>
>
>
> _______________________________________________
> 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/20151207/9b937c4a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 3343 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151207/9b937c4a/attachment-0001.png>
------------------------------
Message: 13
Date: Mon, 07 Dec 2015 06:34:31 -0700
From: "Jason Matusiak" <ja...@gardettoengineering.com>
To: "Ettus Mail List" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Missing step for RFNOC XML build
Message-ID:
<20151207063431.ba066092a6e013ef68fa4f5a8d80e9ee.45f8188a40....@email02.secureserver.net>
Content-Type: text/plain; charset="utf-8"
I think I am missing a step in my RFNoC build. If I add my XML file to
~/pybombs/src/uhd/host/include/uhd/rfnoc/blocks, and then go to
~/pybombs/src/uhd/host/build and run a:
make clean && make -j4 && make install
I see things getting installed to my target directory (~/target/share),
but if I look in : ~/target/share/uhd/rfnoc/blocks , I don't see my xml
file in there, and a running of uhd_usrp_probe seg-faults when it gets
to my new block. If I copy the xml file in by hand it is then happy.
So my question is, what step am i missing for getting this to happen
automagically?
------------------------------
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 64, Issue 7
*****************************************
