Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: B200 bus bandwidth oddness (and a newbie question)
(Theo Holloway)
2. Re: B200 bus bandwidth oddness (and a newbie question)
(Marcus Leech)
3. Installing Live USB Environment to Hard Drive (L Ll)
4. USRP2 RFX2400 benchmark_tx/rx false packet (Jay)
5. X310 FPGA Compile (Kevin Perry)
6. Re: RX timeout after longer inactivity (Michael West)
7. Re: RX timeout after longer inactivity (Michael West)
8. Re: B210 Aliasing and Sampling Rate Precision (Ian Buckley)
9. Re: using the uhd api on my own code (Michael West)
10. Synchronization between B210 and N210 (Yu-Hsuan Chen)
11. Re: Synchronization between B210 and N210 (Matt Ettus)
12. Re: Synchronization between B210 and N210 (Marcus D. Leech)
13. Could I use set_user_register function with USRP X310
(Luong Tan Phong)
14. Re: RX timeout after longer inactivity (Ales Povalac)
15. Re: B210 Aliasing and Sampling Rate Precision (Sabathy Mischa)
----------------------------------------------------------------------
Message: 1
Date: Wed, 16 Apr 2014 17:17:38 +0100
From: "Theo Holloway" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] B200 bus bandwidth oddness (and a newbie
question)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Ralph - thanks for your input - slowly and carefully I guess is the way
forward!
I hope no-one minds if I bump for some feedback on the first issue (below) -
it's making my B200 significantly less useful than I had hoped.
Thanks,
Theo.
>
> * Using benchmark_rate suggests that my USB3 bus (Intel 8 series
> chipset)
is
> happy passing samples from a B200 at 48MS/s (and a bit hiccoughy at
> 52MS/s); however, I can't get HDSDR (under W7x64) or uhd_fft (Ubuntu
> 13.10) to pass more than 16MS/s (32M clock div'd by 2) without
> consistent overruns. Any thoughts on where to start to get to the bottom
of this?
>
------------------------------
Message: 2
Date: Wed, 16 Apr 2014 16:24:46 +0000 (UTC)
From: Marcus Leech <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] B200 bus bandwidth oddness (and a newbie
question)
Message-ID: <1279329644.7332.1397665487261.JavaMail.mail@webmail09>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140416/8cb52a0c/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 15 Apr 2014 21:31:34 -0400 (EDT)
From: L Ll <[email protected]>
To: [email protected]
Subject: [USRP-users] Installing Live USB Environment to Hard Drive
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi all,
I'm brand new to the list. I am the owner of an Ettus B200. I've been trying to
get my system setup and stumbled upon the GNURadio Live DVD. I thought I would
be able to install this ISO to my hard drive, but it has proven nearly
impossible. In any case, I was attempting to do the same with the Ettus Live
USB Environment. I saw this post and saw that Ben suggested using DD. I tried
that with the GNURadio ISO and although that finished with no errors I found
out I would have to edit my GRUB menu in order to make the installation
selectable on boot. This seems to be the HARDEST part! Since both these images
are custom made, they don't seem to apply to any of the guides out there.
The issue seems to be pointing the grub menu to an appropriate initrd and
kernel. I currently have an SSD with 3 partitions on it - The first partition
is an ext4 BackTrack install, the second one is an NTFS partition used for
storage, and the third partition should be my Ettus LiveUSB install. My current
menu entry for this install in grub.cfg (accessed from BackTrack under
/boot/grub/) looks like this:
### BEGIN /etc/grub.d/50_ettuse ###
menuentry "Ettus Environment" {
insmod ext4
set root='(hd1,3)'
linux /casper/vmlinuz boot=casper root=dev/ram1 ramdisk_size=1048576 rw
initrd /casper/initrd.gz
}
### END /etc/grub.d/50_ettuse ###
Looking at the Ettus LiveUSB File system, it seems there is not even a /casper/
directory anywhere, so I'm sure that grub config is wrong, but I can't figure
out what to put. The standard Ubuntu Kernal and Initrd paths are what I have
already written in the grub config... Anybody know where I should point to for
the Ettus LiveUSB Environment???
I have a lot more info to go over from my trials and tribulations - I will put
it all together in a guide once I find a working solution - there seems to be
nothing out there for doing this with the GNURadio Live DVD or the Ettus
LiveUSB Environment.
Let me know if you have any ideas or leads
Thanks,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140415/c807f5b2/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 15 Apr 2014 18:05:19 +0800
From: Jay <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USRP2 RFX2400 benchmark_tx/rx false packet
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Dear usrp2-user,
Hi, I was trying the OFDM benchmark_tx/rx example in the gnuradio folder using
two USRP2+ RFX2400 daughter card plugged with VERT2450 athena using single
computer. Both USRP2s and my PC are connected via a Gigabit switch while My PC
are running Ubuntu 12.04 with gnuradio-companion installed. Two USRP2s are
placed approximately 1m apart.
The sender and receiver used the following code.
Sender: ./benchmark_tx.py -a serial=2061 -f 2.37G -v --tx-amplitude=0.4 -M 0.2
-s 2000
Receiver: ./benchmark_rx.py -a serial=2067 -f 2.37003G -v
After some tuning and playing around with frequency, I still can't get a
perfect transmission where some packet loss or false packet occurs. The
correctness of packet is around 95% only.
Has anyone knows what should I do to improve the transmission?
Terminal output of sender and receiver is as followed:
####################SENDER#########################
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.007.000-1-ga8caec5f
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
No gain specified.
Setting gain to 0.000000 (from [0.000000, 0.000000])
UHD Transmitter:
UHD Args: serial=2061
Freq: 2.37GHz
LO Offset: 0Hz
Gain: 0.000000 dB
Sample Rate: 500ksps
Antenna: None
Subdev Sec: None
Clock Source: None
Using Volk machine: sse4_1_64_orc
OFDM Modulator:
Modulation Type: bpsk
FFT length: 512
Occupied Tones: 200
CP length: 128
Tx amplitude 0.4
######################RECEIVER#######################
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.007.000-1-ga8caec5f
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
No gain specified.
Setting gain to 35.000000 (from [0.000000, 70.000000])
UHD Receiver:
UHD Args: serial=2067
Freq: 2.37003GHz
LO Offset: 0Hz
Gain: 35.000000 dB
Sample Rate: 500ksps
Antenna: None
Subdev Sec: None
Clock Source: None
Using Volk machine: sse4_1_64_orc
OFDM Demodulator:
Modulation Type: bpsk
FFT length: 512
Occupied Tones: 200
CP length: 128
ok: False pktno: 65471 n_rcvd: 1 n_right: 0
ok: True pktno: 1 n_rcvd: 2 n_right: 1
ok: True pktno: 2 n_rcvd: 3 n_right: 2
ok: True pktno: 3 n_rcvd: 4 n_right: 3
ok: True pktno: 4 n_rcvd: 5 n_right: 4
ok: True pktno: 5 n_rcvd: 6 n_right: 5
ok: True pktno: 6 n_rcvd: 7 n_right: 6
ok: True pktno: 7 n_rcvd: 8 n_right: 7
ok: True pktno: 8 n_rcvd: 9 n_right: 8
ok: True pktno: 9 n_rcvd: 10 n_right: 9
ok: True pktno: 10 n_rcvd: 11 n_right: 10
ok: True pktno: 11 n_rcvd: 12 n_right: 11
ok: True pktno: 12 n_rcvd: 13 n_right: 12
ok: True pktno: 13 n_rcvd: 14 n_right: 13
ok: True pktno: 14 n_rcvd: 15 n_right: 14
ok: True pktno: 15 n_rcvd: 16 n_right: 15
ok: True pktno: 16 n_rcvd: 17 n_right: 16
ok: True pktno: 17 n_rcvd: 18 n_right: 17
ok: True pktno: 18 n_rcvd: 19 n_right: 18
ok: True pktno: 19 n_rcvd: 20 n_right: 19
ok: True pktno: 20 n_rcvd: 21 n_right: 20
ok: True pktno: 21 n_rcvd: 22 n_right: 21
ok: True pktno: 22 n_rcvd: 23 n_right: 22
ok: True pktno: 23 n_rcvd: 24 n_right: 23
ok: True pktno: 24 n_rcvd: 25 n_right: 24
ok: True pktno: 25 n_rcvd: 26 n_right: 25
ok: True pktno: 26 n_rcvd: 27 n_right: 26
ok: False pktno: 27 n_rcvd: 28 n_right: 26
ok: True pktno: 28 n_rcvd: 29 n_right: 27
ok: True pktno: 29 n_rcvd: 30 n_right: 28
ok: True pktno: 30 n_rcvd: 31 n_right: 29
ok: True pktno: 31 n_rcvd: 32 n_right: 30
ok: True pktno: 32 n_rcvd: 33 n_right: 31
ok: True pktno: 33 n_rcvd: 34 n_right: 32
ok: True pktno: 34 n_rcvd: 35 n_right: 33
ok: False pktno: 16419 n_rcvd: 36 n_right: 33
ok: True pktno: 36 n_rcvd: 37 n_right: 34
ok: True pktno: 37 n_rcvd: 38 n_right: 35
ok: True pktno: 38 n_rcvd: 39 n_right: 36
ok: True pktno: 39 n_rcvd: 40 n_right: 37
ok: True pktno: 40 n_rcvd: 41 n_right: 38
ok: True pktno: 41 n_rcvd: 42 n_right: 39
ok: True pktno: 42 n_rcvd: 43 n_right: 40
ok: True pktno: 43 n_rcvd: 44 n_right: 41
ok: True pktno: 44 n_rcvd: 45 n_right: 42
ok: True pktno: 45 n_rcvd: 46 n_right: 43
ok: True pktno: 46 n_rcvd: 47 n_right: 44
ok: True pktno: 47 n_rcvd: 48 n_right: 45
ok: True pktno: 48 n_rcvd: 49 n_right: 46
ok: True pktno: 49 n_rcvd: 50 n_right: 47
ok: True pktno: 50 n_rcvd: 51 n_right: 48
ok: True pktno: 51 n_rcvd: 52 n_right: 49
ok: True pktno: 52 n_rcvd: 53 n_right: 50
ok: True pktno: 53 n_rcvd: 54 n_right: 51
ok: True pktno: 54 n_rcvd: 55 n_right: 52
ok: True pktno: 55 n_rcvd: 56 n_right: 53
ok: False pktno: 7736 n_rcvd: 57 n_right: 53
ok: True pktno: 57 n_rcvd: 58 n_right: 54
ok: True pktno: 58 n_rcvd: 59 n_right: 55
ok: True pktno: 59 n_rcvd: 60 n_right: 56
ok: True pktno: 60 n_rcvd: 61 n_right: 57
ok: True pktno: 61 n_rcvd: 62 n_right: 58
ok: True pktno: 62 n_rcvd: 63 n_right: 59
ok: True pktno: 63 n_rcvd: 64 n_right: 60
ok: True pktno: 64 n_rcvd: 65 n_right: 61
ok: True pktno: 65 n_rcvd: 66 n_right: 62
ok: True pktno: 66 n_rcvd: 67 n_right: 63
ok: True pktno: 67 n_rcvd: 68 n_right: 64
ok: True pktno: 68 n_rcvd: 69 n_right: 65
ok: True pktno: 69 n_rcvd: 70 n_right: 66
ok: True pktno: 70 n_rcvd: 71 n_right: 67
ok: True pktno: 71 n_rcvd: 72 n_right: 68
ok: False pktno: 72 n_rcvd: 73 n_right: 68
ok: True pktno: 73 n_rcvd: 74 n_right: 69
ok: True pktno: 74 n_rcvd: 75 n_right: 70
ok: True pktno: 75 n_rcvd: 76 n_right: 71
ok: True pktno: 76 n_rcvd: 77 n_right: 72
ok: True pktno: 77 n_rcvd: 78 n_right: 73
ok: True pktno: 78 n_rcvd: 79 n_right: 74
ok: True pktno: 79 n_rcvd: 80 n_right: 75
ok: True pktno: 80 n_rcvd: 81 n_right: 76
ok: True pktno: 81 n_rcvd: 82 n_right: 77
ok: True pktno: 82 n_rcvd: 83 n_right: 78
ok: True pktno: 83 n_rcvd: 84 n_right: 79
ok: True pktno: 84 n_rcvd: 85 n_right: 80
ok: True pktno: 85 n_rcvd: 86 n_right: 81
ok: True pktno: 86 n_rcvd: 87 n_right: 82
ok: True pktno: 87 n_rcvd: 88 n_right: 83
ok: True pktno: 88 n_rcvd: 89 n_right: 84
ok: True pktno: 89 n_rcvd: 90 n_right: 85
ok: True pktno: 90 n_rcvd: 91 n_right: 86
ok: True pktno: 91 n_rcvd: 92 n_right: 87
ok: True pktno: 92 n_rcvd: 93 n_right: 88
ok: True pktno: 93 n_rcvd: 94 n_right: 89
ok: True pktno: 94 n_rcvd: 95 n_right: 90
ok: True pktno: 95 n_rcvd: 96 n_right: 91
ok: True pktno: 96 n_rcvd: 97 n_right: 92
ok: True pktno: 97 n_rcvd: 98 n_right: 93
ok: True pktno: 98 n_rcvd: 99 n_right: 94
ok: True pktno: 99 n_rcvd: 100 n_right: 95
TIMEOUT
#####################################################
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140415/42d53767/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 15 Apr 2014 09:07:32 -0400
From: Kevin Perry <[email protected]>
To: [email protected]
Subject: [USRP-users] X310 FPGA Compile
Message-ID:
<CAENvC0_TRUCd7=wlzuatmgkddbohqzc18ukeqzntj1xsq93...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
We have not been sucessful compiling the baseline design with the make
scripts in the repository. From previous posts we have seen that there are
issues with getting the code to compile/place/route and that you have had
to run the scripts multiple times before it completes successfully. We
have not been able to replicate this with the baseline. We would like to
add our modifications but prior to doing that we wanted to make sure we had
a clean baseline.
This is the environment we are running with:
Linux - red hat 6.5, kernel version 2.6.32-431.el6.i686
Xilinx 14.4
We are running with 4/7/14 GIT repositry date.
We have run this numerous times. We will see timing violations within the
ZPU mostly, but we always see this timing error on the ADC_Clock paths.
----------------------------------------------------------------------------------------------------------
Constraint | Check | Worst Case |
Best Case | Timing | Timing
| | Slack |
Achievable | Errors | Score
----------------------------------------------------------------------------------------------------------
* OFFSET = IN 0.75 ns VALID 1.5 ns BEFORE C | SETUP | 1.955ns|
-1.205ns| 0| 0
OMP "DB1_ADC_DCLK_P" "FALLING" | HOLD |
-2.873ns| | 14| 39666
----------------------------------------------------------------------------------------------------------
* OFFSET = IN 0.75 ns VALID 1.5 ns BEFORE C | SETUP | 1.955ns|
-1.205ns| 0| 0
OMP "DB1_ADC_DCLK_P" "RISING" | HOLD |
-2.873ns| | 14| 39666
----------------------------------------------------------------------------------------------------------
* OFFSET = IN 0.75 ns VALID 1.5 ns BEFORE C | SETUP | 1.968ns|
-1.218ns| 0| 0
OMP "DB0_ADC_DCLK_P" "FALLING" | HOLD |
-2.842ns| | 14| 39388
----------------------------------------------------------------------------------------------------------
* OFFSET = IN 0.75 ns VALID 1.5 ns BEFORE C | SETUP | 1.968ns|
-1.218ns| 0| 0
OMP "DB0_ADC_DCLK_P" "RISING" | HOLD |
-2.842ns| | 14| 39388
Attached is the build directory for one of the compiles.
Please advise
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140415/fc6369e5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x310_compile.zip
Type: application/zip
Size: 1014413 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140415/fc6369e5/attachment-0001.zip>
------------------------------
Message: 6
Date: Wed, 16 Apr 2014 14:46:59 -0500
From: Michael West <[email protected]>
To: Ales Povalac <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] RX timeout after longer inactivity
Message-ID:
<CAM4xKrpN+inTm48za8pr80ZsvbHoahbaO0RB3ZW=r3_gnpl...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ales,
I have reproduced the issue and am looking into it now.
Regards,
Michael
On Tue, Apr 15, 2014 at 6:01 PM, Michael West <[email protected]>wrote:
> Hi Ales,
>
> I am still trying, but I have not been able to reproduce the issue yet.
>
> Regards,
> Michael
>
>
> On Mon, Apr 14, 2014 at 10:13 AM, Ales Povalac <[email protected]> wrote:
>
>> Hi Michael,
>>
>> have you already tested the issue on Windows? Can you confirm this as
>> a bug in UHD?
>>
>> Regards,
>> Ales
>>
>>
>> 2014-03-20 23:36 GMT+01:00 Michael West <[email protected]>:
>> > Ales,
>> >
>> > My apologies for the delayed response. I have not yet been able to
>> > reproduce the issue, but I have only tested on Linux systems so far. I
>> will
>> > try a Windows system and get back to you.
>> >
>> > --Michael
>> >
>> >
>> > On Mon, Mar 17, 2014 at 9:13 AM, Ales Povalac <[email protected]> wrote:
>> >>
>> >> Hi Michael,
>> >>
>> >> any news regarding the issue? Were you able to reproduce it?
>> >>
>> >> Thanks,
>> >> Ales
>> >>
>> >>
>> >>
>> >> 2014-03-10 7:13 GMT+01:00 Ales Povalac <[email protected]>:
>> >>
>> >>> Hi Michael,
>> >>>
>> >>> system is Windows 7 64-bit, tested on several computers. Last
>> >>> experiment was with N210 and WBX, same issue was also on N200 and
>> >>> TVRX2. Gigabit adapters are from Intel (PCIe) and Realtek (PCI).
>> >>>
>> >>> Regards,
>> >>> Ales
>> >>>
>> >>>
>> >>> 2014-03-07 1:21 GMT+01:00 Michael West <[email protected]>:
>> >>> > Ales,
>> >>> >
>> >>> > Can you provide me with some information about your set up (i.e. OS,
>> >>> > type of
>> >>> > device, type of daughterboards, etc...)?
>> >>> >
>> >>> > Thanks,
>> >>> >
>> >>> > Michael E. West
>> >>> > Senior Software Design Engineer
>> >>> > Ettus Research
>> >>> > www.ettus.com
>> >>> >
>> >>> >
>> >>> > On Wed, Mar 5, 2014 at 3:58 PM, Michael West <
>> [email protected]>
>> >>> > wrote:
>> >>> >>
>> >>> >> Ales,
>> >>> >>
>> >>> >> Thanks for letting us know. We will try to reproduce the issue and
>> >>> >> file a
>> >>> >> bug if appropriate. I will let you know if we find a workaround or
>> >>> >> fix.
>> >>> >>
>> >>> >> Best regards,
>> >>> >> Michael E. West
>> >>> >> Senior Software Design Engineer
>> >>> >> Ettus Research
>> >>> >> www.ettus.com
>> >>> >>
>> >>> >>
>> >>> >> On Wed, Mar 5, 2014 at 6:10 AM, Ales Povalac <[email protected]>
>> wrote:
>> >>> >>>
>> >>> >>> Dear all,
>> >>> >>>
>> >>> >>> we have a problem with UHD RX code. If there is a delay between
>> >>> >>> get_rx_stream() and issue_stream_cmd() longer than ca. 64 seconds,
>> >>> >>> the
>> >>> >>> recv() call always fails with ERROR_CODE_TIMEOUT.
>> >>> >>>
>> >>> >>> Issue can be reproduced in rx_samples_to_file example by adding a
>> >>> >>> delay of >64 seconds before stream command, diff at
>> >>> >>> http://pastebin.com/MFDNVyYy . Threshold is near 64 seconds - 60
>> sec
>> >>> >>> always works, 70 sec always fails with "Timeout while streaming".
>> >>> >>>
>> >>> >>> I am on maint branch of UHD, tested also on 003.005.001 with the
>> same
>> >>> >>> result. Any ideas how to fix this issue?
>> >>> >>>
>> >>> >>> Thanks,
>> >>> >>> Ales
>> >>> >>>
>> >>> >>> _______________________________________________
>> >>> >>> USRP-users mailing list
>> >>> >>> [email protected]
>> >>> >>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >>> >>
>> >>> >>
>> >>> >
>> >>
>> >>
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140416/42f3e244/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 16 Apr 2014 15:24:34 -0500
From: Michael West <[email protected]>
To: Ales Povalac <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] RX timeout after longer inactivity
Message-ID:
<CAM4xKrpExso_NNze2EQR4YPWTNYA=EfkJ=gree=jy0v9uw1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ales,
I am opening a bug for further investigation. I did find that the problem
goes away if the sleep is done before the call to usrp->get_rx_stream(). I
would suggest using that as a work around until the bug is fixed
permanently. Thank you for bringing this to our attention.
Best regards,
Michael
On Wed, Apr 16, 2014 at 2:46 PM, Michael West <[email protected]>wrote:
> Hi Ales,
>
> I have reproduced the issue and am looking into it now.
>
> Regards,
> Michael
>
>
> On Tue, Apr 15, 2014 at 6:01 PM, Michael West <[email protected]>wrote:
>
>> Hi Ales,
>>
>> I am still trying, but I have not been able to reproduce the issue yet.
>>
>> Regards,
>> Michael
>>
>>
>> On Mon, Apr 14, 2014 at 10:13 AM, Ales Povalac <[email protected]> wrote:
>>
>>> Hi Michael,
>>>
>>> have you already tested the issue on Windows? Can you confirm this as
>>> a bug in UHD?
>>>
>>> Regards,
>>> Ales
>>>
>>>
>>> 2014-03-20 23:36 GMT+01:00 Michael West <[email protected]>:
>>> > Ales,
>>> >
>>> > My apologies for the delayed response. I have not yet been able to
>>> > reproduce the issue, but I have only tested on Linux systems so far.
>>> I will
>>> > try a Windows system and get back to you.
>>> >
>>> > --Michael
>>> >
>>> >
>>> > On Mon, Mar 17, 2014 at 9:13 AM, Ales Povalac <[email protected]> wrote:
>>> >>
>>> >> Hi Michael,
>>> >>
>>> >> any news regarding the issue? Were you able to reproduce it?
>>> >>
>>> >> Thanks,
>>> >> Ales
>>> >>
>>> >>
>>> >>
>>> >> 2014-03-10 7:13 GMT+01:00 Ales Povalac <[email protected]>:
>>> >>
>>> >>> Hi Michael,
>>> >>>
>>> >>> system is Windows 7 64-bit, tested on several computers. Last
>>> >>> experiment was with N210 and WBX, same issue was also on N200 and
>>> >>> TVRX2. Gigabit adapters are from Intel (PCIe) and Realtek (PCI).
>>> >>>
>>> >>> Regards,
>>> >>> Ales
>>> >>>
>>> >>>
>>> >>> 2014-03-07 1:21 GMT+01:00 Michael West <[email protected]>:
>>> >>> > Ales,
>>> >>> >
>>> >>> > Can you provide me with some information about your set up (i.e.
>>> OS,
>>> >>> > type of
>>> >>> > device, type of daughterboards, etc...)?
>>> >>> >
>>> >>> > Thanks,
>>> >>> >
>>> >>> > Michael E. West
>>> >>> > Senior Software Design Engineer
>>> >>> > Ettus Research
>>> >>> > www.ettus.com
>>> >>> >
>>> >>> >
>>> >>> > On Wed, Mar 5, 2014 at 3:58 PM, Michael West <
>>> [email protected]>
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> Ales,
>>> >>> >>
>>> >>> >> Thanks for letting us know. We will try to reproduce the issue
>>> and
>>> >>> >> file a
>>> >>> >> bug if appropriate. I will let you know if we find a workaround
>>> or
>>> >>> >> fix.
>>> >>> >>
>>> >>> >> Best regards,
>>> >>> >> Michael E. West
>>> >>> >> Senior Software Design Engineer
>>> >>> >> Ettus Research
>>> >>> >> www.ettus.com
>>> >>> >>
>>> >>> >>
>>> >>> >> On Wed, Mar 5, 2014 at 6:10 AM, Ales Povalac <[email protected]>
>>> wrote:
>>> >>> >>>
>>> >>> >>> Dear all,
>>> >>> >>>
>>> >>> >>> we have a problem with UHD RX code. If there is a delay between
>>> >>> >>> get_rx_stream() and issue_stream_cmd() longer than ca. 64
>>> seconds,
>>> >>> >>> the
>>> >>> >>> recv() call always fails with ERROR_CODE_TIMEOUT.
>>> >>> >>>
>>> >>> >>> Issue can be reproduced in rx_samples_to_file example by adding a
>>> >>> >>> delay of >64 seconds before stream command, diff at
>>> >>> >>> http://pastebin.com/MFDNVyYy . Threshold is near 64 seconds -
>>> 60 sec
>>> >>> >>> always works, 70 sec always fails with "Timeout while streaming".
>>> >>> >>>
>>> >>> >>> I am on maint branch of UHD, tested also on 003.005.001 with the
>>> same
>>> >>> >>> result. Any ideas how to fix this issue?
>>> >>> >>>
>>> >>> >>> Thanks,
>>> >>> >>> Ales
>>> >>> >>>
>>> >>> >>> _______________________________________________
>>> >>> >>> USRP-users mailing list
>>> >>> >>> [email protected]
>>> >>> >>>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> >>> >>
>>> >>> >>
>>> >>> >
>>> >>
>>> >>
>>> >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140416/b8a688df/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 16 Apr 2014 16:02:15 -0700
From: Ian Buckley <[email protected]>
To: Sabathy Mischa <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 Aliasing and Sampling Rate Precision
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Sabathy,
I've reproduced your issue #1. I see the alias very clearly. We need to work
out what the regression is now.
-Ian
On Apr 16, 2014, at 2:01 AM, Sabathy Mischa <[email protected]> wrote:
> Thanks for your answer Ian,
> Honestly it doesn?t look like that there is a 7 tap filter active in my
> configuration. The aliasing is not attenuated it is fully visible. The
> attenuation starts just at the end of the 30.72e6/2.
> At the moment it is simply not possible to use two channels on two different
> center frequencies using the tune_request possibility, since aliasing
> destroys everything :P
>
> Has somebody an idea about my second question?
> Thanks
>
> From: Ian Buckley [mailto:[email protected]]
> Sent: Dienstag, 15. April 2014 22:00
> To: Sabathy Mischa
> Cc: [email protected]
> Subject: Re: [USRP-users] B210 Aliasing and Sampling Rate Precision
>
> In answer to your first question, that is expected behavior, you would also
> see it if you used N210 @ 50Msps (8bit) mode. This is because there are two
> half band interpolating filters in both designs, one is 31tap, the other 7
> tap. The 7 tap design can run at 1 output sample per clock, the 31 tap at 1
> output sample for every two clocks. Thus in this configuration the only
> filter that can be used is the 7 tap, which as you might expect being so
> short is less effective at suppressing aliasing than the 31 tap. In N210 @
> 25Msps you have both of these filters cascaded with good performance.
>
> The next B2x0 UHD release will contain a new interpolation filter design that
> will greatly improve this performance. In the mean time you could reduce
> master_clock_rate to 15.36MHz so that all FPGA filters are bypassed which
> should improve your measured system performance.
>
> -Ian
>
> On Apr 15, 2014, at 7:38 AM, Sabathy Mischa <[email protected]> wrote:
>
>
> Dear All,
>
> I have two questions regarding the B210 performance.
>
> 1. If I use the Clock Rate 30.72e6 Hz and Sampling Rate 15.36e6 (set in GRC)
> i have aliasing effects. I think there was already a discussion about it.
> Will this be fixed soon? I pulled today the latest UHD from git and I still
> have this issue. I need to use this when I want to have two seperate channel
> on two different centre frequencies using the tune_request possibility. I
> also have aliasing issue when I only use one channel with a clock rate of
> 30.72e6 Hz and the sampling rate of 15.36e6 Hz. It seems that the lowpass
> filter is not enabled.
>
> 2. I made some tests correlating with a reference signal in the time domain.
> The B210 was set to 15.36e6 Hz clock and sampling rate. The B210 was
> configured to the centre frequency of ~1.85e9 Hz. I used a rubidium freq
> standard which is locked to a GPS 1pps as external reference (10 MHz and 1
> PPS). If I observing my interpolated correlation peak, I see a significant
> higher drift in the time domain as I am used to see when I use N210 with a
> WBX board installed (locked to the same rubidium) measuring in parallel the
> same signal. Of course the N210 was configured to 25e6 Hz sampling rate but I
> used the rational resampler in gnuradio to resample to 15.36e6 Hz.
> It seems that the sampling rate is not as precise (not 15.36e6 Hz) as in the
> N210+WBX, does anybody made a similar observations or has an idea what causes
> this error? I don't really get why this can happen on the B210 since there is
> a PLL as well :P
>
> I appreciate your comments and your help.
> Best Regards
> Mischa
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140416/abc83f29/attachment-0001.html>
------------------------------
Message: 9
Date: Wed, 16 Apr 2014 18:03:43 -0500
From: Michael West <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] using the uhd api on my own code
Message-ID:
<CAM4xKroLCaWiAcLEQovgTfCwTA2BhqnS=jspiszz_qcdmzz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
This is a linking error and not a compiler error, so the good news is that
the code compiled fine. The errors indicate that either the include files
found did not match the libuhd found or that libuhd was not found at all.
In the project properties, under "Linker", check to make sure that the
"Additional Library Directories" contains the correct path to the libuhd
and that there isn't another path in the list before it pointing to another
version of the library. Also check that the path to the include files is
correct and points to the include files that match the library.
Regards,
Michael E. West
On Tue, Apr 15, 2014 at 12:19 PM, Marcus M?ller <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> These are linking errors.
> I'm not really used to visual Studio, but you have to define the
> libraries you link against in your project properties, somewhere
> hidden, if I remember correctly.
>
> Greetings,
> Marcus
>
> On 15.04.2014 18:44, iftah giladi wrote:
> > Hey all,
> >
> >
> >
> > I am trying to start from one of the examples supplied like
> > tx_timed_samples by building a project in msvc 2010.
> >
> > I have add all the include and lib libraries from boost and from
> > uhd.
> >
> > Compiled and received these error which I cannot figure out what to
> > do with.
> >
> >
> >
> > Please help..
> >
> >
> >
> > Error:
> >
> >
> >
> > Error 2 error LNK2001: unresolved external
> > symbol "__declspec(dllimport) public: __thiscall
> > uhd::stream_args_t::~stream_args_t(void)"
> > (__imp_??1stream_args_t@uhd@@QAE@XZ)
> > c:\Users\iftah\documents\visual studio
> > 2010\Projects\rx_timed_samples\rx_timed_samples\rx_timed_samples.obj
> >
> >
> rx_timed_samples
> >
> > Error 3 error LNK2001: unresolved external
> > symbol "__declspec(dllimport) public: __int64 __thiscall
> > uhd::time_spec_t::get_full_secs(void)const "
> > (__imp_?get_full_secs@time_spec_t@uhd@@QBE_JXZ)
> > c:\Users\iftah\documents\visual studio
> > 2010\Projects\rx_timed_samples\rx_timed_samples\rx_timed_samples.obj
> >
> >
> rx_timed_samples
> >
> > Error 4 error LNK2001: unresolved external
> > symbol "__declspec(dllimport) public: double __thiscall
> > uhd::time_spec_t::get_frac_secs(void)const "
> > (__imp_?get_frac_secs@time_spec_t@uhd@@QBENXZ)
> > c:\Users\iftah\documents\visual studio
> > 2010\Projects\rx_timed_samples\rx_timed_samples\rx_timed_samples.obj
> >
> >
> rx_timed_samples
> >
> > Error 5 error LNK2001: unresolved external
> > symbol "__declspec(dllimport) public: class
> > std::basic_string<char,struct std::char_traits<char>,class
> > std::allocator<char> > __thiscall
> > uhd::rx_metadata_t::strerror(void)const "
> > (__imp_?strerror@rx_metadata_t@uhd@@QBE?AV?$basic_string@DU
> ?$char_traits@D@s
> >
> >
> td@@V?$allocator@D@2@@std@@XZ) c:\Users\iftah\documents\visual
> studio
> > 2010\Projects\rx_timed_samples\rx_timed_samples\rx_timed_samples.obj
> >
> >
> rx_timed_samples
> >
> > Error 6 error LNK2001: unresolved external
> > symbol "__declspec(dllimport) public: __thiscall
> > uhd::rx_metadata_t::rx_metadata_t(void)"
> > (__imp_??0rx_metadata_t@uhd@@QAE@XZ)
> > c:\Users\iftah\documents\visual studio
> > 2010\Projects\rx_timed_samples\rx_timed_samples\rx_timed_samples.obj
> >
> >
> rx_timed_samples
> >
> > Error 7 error LNK2001: unresolved external
> > symbol "__declspec(dllimport) public: __thiscall
> > uhd::stream_cmd_t::stream_cmd_t(enum
> > uhd::stream_cmd_t::stream_mode_t const &)"
> > (__imp_??0stream_cmd_t@uhd@@QAE@ABW4stream_mode_t@01@@Z)
> > c:\Users\iftah\documents\visual studio
> > 2010\Projects\rx_timed_samples\rx_timed_samples\rx_timed_samples.obj
> >
> >
> rx_timed_samples
> >
> > Error 8 error LNK2001: unresolved external
> > symbol "__declspec(dllimport) public: __thiscall
> > uhd::stream_args_t::stream_args_t(class
> > std::basic_string<char,struct std::char_traits<char>,class
> > std::allocator<char> > const &,class std::basic_string<char,struct
> > std::char_traits<char>,class std::allocator<char> > const &)"
> > (__imp_??0stream_args_t@uhd@@QAE@ABV?$basic_string@DU?$char_traits@D
> @std@@V?
> >
> >
> $allocator@D@2@@std@@0@Z) c:\Users\iftah\documents\visual
> > studio
> > 2010\Projects\rx_timed_samples\rx_timed_samples\rx_timed_samples.obj
> >
> >
> rx_timed_samples
> >
> > Error 9 error LNK2001: unresolved external
> > symbol "__declspec(dllimport) public: __thiscall
> > uhd::time_spec_t::time_spec_t(double)"
> > (__imp_??0time_spec_t@uhd@@QAE@N@Z) c:\Users\iftah\documents\visual
> > studio
> > 2010\Projects\rx_timed_samples\rx_timed_samples\rx_timed_samples.obj
> >
> >
> rx_timed_samples
> >
> > Error 10 error LNK2001: unresolved external symbol
> > "__declspec(dllimport) public: __thiscall
> > uhd::device_addr_t::~device_addr_t(void)"
> > (__imp_??1device_addr_t@uhd@@QAE@XZ)
> > c:\Users\iftah\documents\visual studio
> > 2010\Projects\rx_timed_samples\rx_timed_samples\rx_timed_samples.obj
> >
> >
> rx_timed_samples
> >
> > Error 11 error LNK2001: unresolved external symbol
> > "__declspec(dllimport) public: static class
> > boost::shared_ptr<class uhd::usrp::multi_usrp> __cdecl
> > uhd::usrp::multi_usrp::make(class uhd::device_addr_t const &)"
> > (__imp_?make@multi_usrp@usrp@uhd@@SA?AV?$shared_ptr@Vmulti_usrp@usrp@uhd
> @@@b
> >
> >
> oost@@ABVdevice_addr_t@3@@Z) c:\Users\iftah\documents\visual studio
> > 2010\Projects\rx_timed_samples\rx_timed_samples\rx_timed_samples.obj
> >
> >
> rx_timed_samples
> >
> > Error 12 error LNK2001: unresolved external symbol
> > "__declspec(dllimport) public: __thiscall
> > uhd::device_addr_t::device_addr_t(class
> > std::basic_string<char,struct std::char_traits<char>,class
> > std::allocator<char> > const &)"
> > (__imp_??0device_addr_t@uhd@@QAE@ABV?$basic_string@DU?$char_traits@D
> @std@@V?
> >
> >
> $allocator@D@2@@std@@@Z) c:\Users\iftah\documents\visual
> studio
> > 2010\Projects\rx_timed_samples\rx_timed_samples\rx_timed_samples.obj
> >
> >
> rx_timed_samples
> >
> > Error 13 error LNK2001: unresolved external symbol
> > "__declspec(dllimport) bool __cdecl
> > uhd::set_thread_priority_safe(float,bool)"
> > (__imp_?set_thread_priority_safe@uhd@@YA_NM_N@Z)
> > c:\Users\iftah\documents\visual studio
> > 2010\Projects\rx_timed_samples\rx_timed_samples\rx_timed_samples.obj
> >
> >
> rx_timed_samples
> >
> > Error 14 error LNK1120: 12 unresolved externals
> > c:\users\iftah\documents\visual studio
> > 2010\Projects\rx_timed_samples\Debug\rx_timed_samples.exe
> > rx_timed_samples
> >
> >
> >
> > Thanks,
> >
> > iftah
> >
> >
> >
> >
> > _______________________________________________ USRP-users mailing
> > list [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTTWowAAoJEBQ6EdjyzlHtdPkIAIVcVZ3W49ItgeGJ0lTpakFX
> iIRDjCSSvGcEgHH/FM5Hijtx6xG1RkQdZocaLr1fw3twtspw98ReTFnm7dCut6P+
> 2OaImfxAif+AL9zrs4sFIlTVu1VtOYoqheFaRPVHcpARGQYbm4QZ2lbd4zg2gjRZ
> aoQYR7kEP2Ra8+VsyVrJdfGB/95LcZEcpoSB05aM3UpVTdI3+8izVB4fj1VevS2g
> fNjDUMcsG3EMpX74jNJRIqWyx2oUvPzgMkaO3m6ZezGKZDl8tQ86QO6rd4JdD7Bg
> iMfk0CcSrvvNaLy6cCsH2GVJBtzNk2eUDco/ZgJoLPeYCst6S+fvLAsRh9DqvEs=
> =PtTx
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140416/08c2b286/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 16 Apr 2014 19:00:21 -0700
From: Yu-Hsuan Chen <[email protected]>
To: [email protected]
Subject: [USRP-users] Synchronization between B210 and N210
Message-ID:
<cabv9qyjijsfjkwrol7dko3oc4bwsqvuemmwybfopa1j8+mg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I tried to synchronize one N210 and one B210 using external PPS. But,
whatever I setup the same master_clock_rate, the time difference is around
0.01 seconds. Moreover, each time I get different time offset within 0.01~
0.0101 seconds. Is it possible to synchronize B210 and N210?
Best,
Yu-Hsuan Chen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140416/cec5e2f1/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 16 Apr 2014 19:06:54 -0700
From: Matt Ettus <[email protected]>
To: Yu-Hsuan Chen <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Synchronization between B210 and N210
Message-ID:
<CAN=1kn-tgam08kYF4pkX0y2qD=zlfjjvapztnrsggxmmd14...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
If you are trying to use this for a MIMO system, with 3 antennas (1 on the
N210 and 2 on theB210), I think it is going to be hard. The delays are
very different between the devices, and this is not really how it is meant
to be used.
If you are trying to synchronize for a different purpose, a description of
that application would help.
Matt
On Wed, Apr 16, 2014 at 7:00 PM, Yu-Hsuan Chen <[email protected]>wrote:
> Hi all,
>
> I tried to synchronize one N210 and one B210 using external PPS. But,
> whatever I setup the same master_clock_rate, the time difference is around
> 0.01 seconds. Moreover, each time I get different time offset within 0.01~
> 0.0101 seconds. Is it possible to synchronize B210 and N210?
>
> Best,
> Yu-Hsuan Chen
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140416/919b9e09/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 16 Apr 2014 22:39:27 -0400
From: "Marcus D. Leech" <[email protected]>
To: Yu-Hsuan Chen <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Synchronization between B210 and N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 04/16/2014 10:29 PM, Yu-Hsuan Chen wrote:
> Hi Marcus,
>
> They share the same 10MHz refclock.
>
> I create two uhd::usrp::multi_usrp::sptr. usrp is for N210 and usrp2
> is for B210. Then, do follows.
>
> ===========================
> // setup time and clock source
> usrp->set_time_source("external");
> usrp2->set_time_source("external");
>
> usrp->set_clock_source("external");
> usrp2->set_clock_source("external");
>
> /*
> set rate and frequency
> */
>
> // synchronization
> std::cout << boost::format("Synchronizing the device time...") <<
> std::endl;
> std::cout << boost::format(" 1. catch time transition at pps
> edge") << std::endl;
> uhd::time_spec_t time_start = usrp->get_time_now();
> uhd::time_spec_t time_start_last_pps = usrp->get_time_last_pps();
> while(true){
> if (usrp->get_time_last_pps() != time_start_last_pps) break;
> if ((usrp->get_time_now() - time_start) >
> uhd::time_spec_t(1.1)){
> throw uhd::runtime_error(
> "Board 0 may not be getting a PPS signal!\n"
> "No PPS detected within the time interval.\n"
> "See the application notes for your device.\n"
> );
> }
> }
>
> std::cout << boost::format(" 2. set times next pps synchronously") <<
> std::endl;
> usrp->set_time_next_pps(uhd::time_spec_t(0.0));
> usrp2->set_time_next_pps(uhd::time_spec_t(0.0));
> ======================================
>
> After saving samples to files, I have my own code to see the time
> offset between N210 and B210.
> Basically, they share the same source of GPS signal and I check time
> synchronization by processing the signal from the same satellite.
>
> Yu-Hsuan
>
>
The internal and communicatons latencies between the two devices will be
quite different, and the exact point where sample frames are time-stamped
will be slightly different as well, although not as large as 10ms.
You'll probably find that if you actually check the timestamps in the sample
meta-data, things will be much, much, closer aligned than 10ms.
------------------------------
Message: 13
Date: Thu, 17 Apr 2014 14:45:05 +0700
From: Luong Tan Phong <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Could I use set_user_register function with USRP
X310
Message-ID:
<CAA8YXsoT2nPvak_uNhgwn9Wq0yoat1rq6Z2vF-h0qxzf=qx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi list,
I've bought USRP X310 and I'd like to modify FPGA source code for my
application. I've look around the FPGA code and it seems that it don't
support to setting user registers.
Could I setting user registers on USRP X310, pls?
With best regards.
LTP
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140417/2ce39ffd/attachment-0001.html>
------------------------------
Message: 14
Date: Thu, 17 Apr 2014 11:12:49 +0200
From: Ales Povalac <[email protected]>
To: Michael West <[email protected]>
Cc: usrp-users <[email protected]>, Vojt?ch Derbek
<[email protected]>
Subject: Re: [USRP-users] RX timeout after longer inactivity
Message-ID:
<CADyMgmxZP23cgbNs=gtmsqsp1qqmroaudftxqczympnxcq7...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Michael,
thanks for the confirmation, I hope you will be able to solve the
problem. We are already using similar workaround, but fixing the
problem in drivers would be definitively a better solution.
Regards,
Ales
2014-04-16 22:24 GMT+02:00 Michael West <[email protected]>:
> Hi Ales,
>
> I am opening a bug for further investigation. I did find that the problem
> goes away if the sleep is done before the call to usrp->get_rx_stream(). I
> would suggest using that as a work around until the bug is fixed
> permanently. Thank you for bringing this to our attention.
>
> Best regards,
> Michael
>
>
> On Wed, Apr 16, 2014 at 2:46 PM, Michael West <[email protected]>
> wrote:
>>
>> Hi Ales,
>>
>> I have reproduced the issue and am looking into it now.
>>
>> Regards,
>> Michael
>>
>>
>> On Tue, Apr 15, 2014 at 6:01 PM, Michael West <[email protected]>
>> wrote:
>>>
>>> Hi Ales,
>>>
>>> I am still trying, but I have not been able to reproduce the issue yet.
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> On Mon, Apr 14, 2014 at 10:13 AM, Ales Povalac <[email protected]> wrote:
>>>>
>>>> Hi Michael,
>>>>
>>>> have you already tested the issue on Windows? Can you confirm this as
>>>> a bug in UHD?
>>>>
>>>> Regards,
>>>> Ales
>>>>
>>>>
>>>> 2014-03-20 23:36 GMT+01:00 Michael West <[email protected]>:
>>>> > Ales,
>>>> >
>>>> > My apologies for the delayed response. I have not yet been able to
>>>> > reproduce the issue, but I have only tested on Linux systems so far.
>>>> > I will
>>>> > try a Windows system and get back to you.
>>>> >
>>>> > --Michael
>>>> >
>>>> >
>>>> > On Mon, Mar 17, 2014 at 9:13 AM, Ales Povalac <[email protected]> wrote:
>>>> >>
>>>> >> Hi Michael,
>>>> >>
>>>> >> any news regarding the issue? Were you able to reproduce it?
>>>> >>
>>>> >> Thanks,
>>>> >> Ales
>>>> >>
>>>> >>
>>>> >>
>>>> >> 2014-03-10 7:13 GMT+01:00 Ales Povalac <[email protected]>:
>>>> >>
>>>> >>> Hi Michael,
>>>> >>>
>>>> >>> system is Windows 7 64-bit, tested on several computers. Last
>>>> >>> experiment was with N210 and WBX, same issue was also on N200 and
>>>> >>> TVRX2. Gigabit adapters are from Intel (PCIe) and Realtek (PCI).
>>>> >>>
>>>> >>> Regards,
>>>> >>> Ales
>>>> >>>
>>>> >>>
>>>> >>> 2014-03-07 1:21 GMT+01:00 Michael West <[email protected]>:
>>>> >>> > Ales,
>>>> >>> >
>>>> >>> > Can you provide me with some information about your set up (i.e.
>>>> >>> > OS,
>>>> >>> > type of
>>>> >>> > device, type of daughterboards, etc...)?
>>>> >>> >
>>>> >>> > Thanks,
>>>> >>> >
>>>> >>> > Michael E. West
>>>> >>> > Senior Software Design Engineer
>>>> >>> > Ettus Research
>>>> >>> > www.ettus.com
>>>> >>> >
>>>> >>> >
>>>> >>> > On Wed, Mar 5, 2014 at 3:58 PM, Michael West
>>>> >>> > <[email protected]>
>>>> >>> > wrote:
>>>> >>> >>
>>>> >>> >> Ales,
>>>> >>> >>
>>>> >>> >> Thanks for letting us know. We will try to reproduce the issue
>>>> >>> >> and
>>>> >>> >> file a
>>>> >>> >> bug if appropriate. I will let you know if we find a workaround
>>>> >>> >> or
>>>> >>> >> fix.
>>>> >>> >>
>>>> >>> >> Best regards,
>>>> >>> >> Michael E. West
>>>> >>> >> Senior Software Design Engineer
>>>> >>> >> Ettus Research
>>>> >>> >> www.ettus.com
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> On Wed, Mar 5, 2014 at 6:10 AM, Ales Povalac <[email protected]>
>>>> >>> >> wrote:
>>>> >>> >>>
>>>> >>> >>> Dear all,
>>>> >>> >>>
>>>> >>> >>> we have a problem with UHD RX code. If there is a delay between
>>>> >>> >>> get_rx_stream() and issue_stream_cmd() longer than ca. 64
>>>> >>> >>> seconds,
>>>> >>> >>> the
>>>> >>> >>> recv() call always fails with ERROR_CODE_TIMEOUT.
>>>> >>> >>>
>>>> >>> >>> Issue can be reproduced in rx_samples_to_file example by adding
>>>> >>> >>> a
>>>> >>> >>> delay of >64 seconds before stream command, diff at
>>>> >>> >>> http://pastebin.com/MFDNVyYy . Threshold is near 64 seconds - 60
>>>> >>> >>> sec
>>>> >>> >>> always works, 70 sec always fails with "Timeout while
>>>> >>> >>> streaming".
>>>> >>> >>>
>>>> >>> >>> I am on maint branch of UHD, tested also on 003.005.001 with the
>>>> >>> >>> same
>>>> >>> >>> result. Any ideas how to fix this issue?
>>>> >>> >>>
>>>> >>> >>> Thanks,
>>>> >>> >>> Ales
>>>> >>> >>>
>>>> >>> >>> _______________________________________________
>>>> >>> >>> USRP-users mailing list
>>>> >>> >>> [email protected]
>>>> >>> >>>
>>>> >>> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>> >>> >>
>>>> >>> >>
>>>> >>> >
>>>> >>
>>>> >>
>>>> >
>>>
>>>
>>
>
------------------------------
Message: 15
Date: Thu, 17 Apr 2014 12:30:53 +0000
From: Sabathy Mischa <[email protected]>
To: Ian Buckley <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 Aliasing and Sampling Rate Precision
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello Ian,
Ok I'm glad you could reproduce it. If you need further support please let me
know, but I have to mention that I never looked at the FPGA code.
Best Regards,
Mischa
From: Ian Buckley [mailto:[email protected]]
Sent: Donnerstag, 17. April 2014 01:02
To: Sabathy Mischa
Cc: [email protected]
Subject: Re: [USRP-users] B210 Aliasing and Sampling Rate Precision
Sabathy,
I've reproduced your issue #1. I see the alias very clearly. We need to work
out what the regression is now.
-Ian
On Apr 16, 2014, at 2:01 AM, Sabathy Mischa
<[email protected]<mailto:[email protected]>> wrote:
Thanks for your answer Ian,
Honestly it doesn't look like that there is a 7 tap filter active in my
configuration. The aliasing is not attenuated it is fully visible. The
attenuation starts just at the end of the 30.72e6/2.
At the moment it is simply not possible to use two channels on two different
center frequencies using the tune_request possibility, since aliasing destroys
everything :P
Has somebody an idea about my second question?
Thanks
From: Ian Buckley [mailto:[email protected]<http://ionconcepts.com>]
Sent: Dienstag, 15. April 2014 22:00
To: Sabathy Mischa
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] B210 Aliasing and Sampling Rate Precision
In answer to your first question, that is expected behavior, you would also see
it if you used N210 @ 50Msps (8bit) mode. This is because there are two half
band interpolating filters in both designs, one is 31tap, the other 7 tap. The
7 tap design can run at 1 output sample per clock, the 31 tap at 1 output
sample for every two clocks. Thus in this configuration the only filter that
can be used is the 7 tap, which as you might expect being so short is less
effective at suppressing aliasing than the 31 tap. In N210 @ 25Msps you have
both of these filters cascaded with good performance.
The next B2x0 UHD release will contain a new interpolation filter design that
will greatly improve this performance. In the mean time you could reduce
master_clock_rate to 15.36MHz so that all FPGA filters are bypassed which
should improve your measured system performance.
-Ian
On Apr 15, 2014, at 7:38 AM, Sabathy Mischa
<[email protected]<mailto:[email protected]>> wrote:
Dear All,
I have two questions regarding the B210 performance.
1. If I use the Clock Rate 30.72e6 Hz and Sampling Rate 15.36e6 (set in GRC) i
have aliasing effects. I think there was already a discussion about it. Will
this be fixed soon? I pulled today the latest UHD from git and I still have
this issue. I need to use this when I want to have two seperate channel on two
different centre frequencies using the tune_request possibility. I also have
aliasing issue when I only use one channel with a clock rate of 30.72e6 Hz and
the sampling rate of 15.36e6 Hz. It seems that the lowpass filter is not
enabled.
2. I made some tests correlating with a reference signal in the time domain.
The B210 was set to 15.36e6 Hz clock and sampling rate. The B210 was
configured to the centre frequency of ~1.85e9 Hz. I used a rubidium freq
standard which is locked to a GPS 1pps as external reference (10 MHz and 1
PPS). If I observing my interpolated correlation peak, I see a significant
higher drift in the time domain as I am used to see when I use N210 with a WBX
board installed (locked to the same rubidium) measuring in parallel the same
signal. Of course the N210 was configured to 25e6 Hz sampling rate but I used
the rational resampler in gnuradio to resample to 15.36e6 Hz.
It seems that the sampling rate is not as precise (not 15.36e6 Hz) as in the
N210+WBX, does anybody made a similar observations or has an idea what causes
this error? I don't really get why this can happen on the B210 since there is a
PLL as well :P
I appreciate your comments and your help.
Best Regards
Mischa
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140417/8a1e20c4/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 44, Issue 17
******************************************
