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: Problem with Synch of two N210s for 4*4MIMO (Ian Buckley)
2. Re: Python for Windows (Josh Blum)
3. Re: Read Only File System ? (Ben Hilburn)
4. Re: Python for Windows (Simon HB9DRV)
5. Re: Problem with Synch of two N210s for 4*4MIMO (Josh Blum)
6. WBX + Pre-amp (Simon HB9DRV)
7. Re: high packet loss tunnel.py (Josh Blum)
8. Re: WBX + Pre-amp ([email protected])
9. Re: WBX + Pre-amp (Simon HB9DRV)
10. Re: WBX + Pre-amp ([email protected])
11. GPS not reporting LAT / LONG (Joel Parker)
12. Re: GPS not reporting LAT / LONG (Nick Foster)
13. Re: GPS not reporting LAT / LONG (Joel Parker)
14. Re: GPS not reporting LAT / LONG (Joel Parker)
15. USRP N210 No devices found (Louis Rey)
16. Re: USRP N210 No devices found (Josh Blum)
17. Re: USRP-users Digest, Vol 21, Issue 15 (Steve Wright)
18. Re: Problem with Synch of two N210s for 4*4MIMO (Farrukh Aziz)
19. Re: Problem with Synch of two N210s for 4*4MIMO (Josh Blum)
20. television transceiver witu USRP 1 ? (anak galer)
21. Re: television transceiver witu USRP 1 ? (Deddi Hariprawira)
22. Re: high packet loss tunnel.py (Nguyen Truong)
23. Re: high packet loss tunnel.py (Josh Blum)
24. About writing to file speed (Eddie Sun)
25. Windows VS 2010 Help Please (Simon HB9DRV)
26. Re: Windows VS 2010 Help Please (Simon HB9DRV)
27. Re: About writing to file speed (Nick Foster)
28. Re: About writing to file speed (John Malsbury)
----------------------------------------------------------------------
Message: 1
Date: Tue, 15 May 2012 09:20:29 -0700
From: Ian Buckley <[email protected]>
To: Farrukh Aziz <[email protected]>
Cc: USRP user forum <[email protected]>
Subject: Re: [USRP-users] Problem with Synch of two N210s for 4*4MIMO
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Farrukh,
leaving aside the issue of synchronizing multiple USRP's for the time being, I
think you have a more fundamental problem.
The error message indicates you are trying to configure the USRP to output a
1KHz sample rate stream, and UHD is reporting that it has configured the URSP
for the maximum possible decimation in H/W that is supported which is 512
(100e6/512=0.195312e6). If you really require such a low bandwidth signal then
will need to distribute the total decimation required between H/W in the USRP
and S/W (Gnuradio/Matlab etc)
-Ian
On May 15, 2012, at 1:14 AM, Farrukh Aziz wrote:
> I am using two N210s (fitted with TVRX2 dbs) connected in master/slave
> configuration. Despite feeding the two external reference signals (1PPS and
> 10MHz) I am not able to receive the four complex data streams (Synch=unknown
> PPS). This is the error that I get:
>
> UHD Warning:
> The hardware does not support the requested RX sample rate:
> Target sample rate: 0.001000 MSps
> Actual sample rate: 0.195312 MSps
> OUHD source block got error code 0x2
> gr_block_executor: source <gr_block gr uhd usrp source (49)> produced no
> output. We're marking it DONE.
>
> When I use 'dont sync' option (in UHD USRP source) then I do receive four
> complex streams.
> Thanks in advance, for any useful comments.
>
> Farrukh Aziz Bhatti
> Department of Electrical & Computer Engineering
> University of Auckland
>
>
>
>
> _______________________________________________
> 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/20120515/a2514a8e/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 15 May 2012 09:28:09 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Python for Windows
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 05/15/2012 06:04 AM, Sanat Gulvadi wrote:
> Hi Simon,
>
> For me it's always worked on versions 2.6 or 2.7
3.0 should work as well. Python windows installer comes with tk, which
lets us have a nice little burner gui app free of build dependencies.
-josh
>
> Regards,
> Sanat
>
>
>
> On Tue, May 15, 2012 at 1:55 PM, Simon HB9DRV <[email protected]> wrote:
>
>> Hi All,****
>>
>> ** **
>>
>> To my utter amazement I have to upgrade the FPGA code on my new N210 via a
>> python program! ****
>>
>> ** **
>>
>> Which / what python installation is recommended please?****
>>
>> ** **
>>
>> I?m slowing getting going?****
>>
>> ** **
>>
>> Simon Brown, HB9DRV
>> http://dit-dit-dit.com****
>>
>> ** **
>>
>> Not sent from an iPhone: I don't have one and I don't want one.****
>>
>> ** **
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
> --
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 3
Date: Tue, 15 May 2012 09:29:06 -0700
From: Ben Hilburn <[email protected]>
To: Thomas Tsou <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Read Only File System ?
Message-ID:
<caoevzklo8wnhejvxpa3nryqx8womgem3ivjyexbyhnkpv8n...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Tom -
Thanks!
Cheers,
Ben
On Tue, May 15, 2012 at 8:01 AM, Thomas Tsou <[email protected]> wrote:
> On Mon, May 14, 2012 at 11:59 AM, Philip Balister <[email protected]>
> wrote:
> > On 05/14/2012 11:44 AM, Joel Parker wrote:
> >> It complains that the build requirements have not been met because it
> is missing libosip2 . Any idea's
> >> how I can get this lib ?
> >>
> >
> > opkg update
> > opkg install libosip-dev
> >
> > Let me know if you have any more issues with missing packages.
>
> I have updated the wiki.
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSE100#Dependencies
>
> -Tom
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120515/5e7548df/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 15 May 2012 18:31:55 +0200
From: "Simon HB9DRV" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] Python for Windows
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Thanks,
I'll give it a go tomorrow (best not play with pythons after a few beers).
Simon Brown, HB9DRV
http://dit-dit-dit.com
You are standing at the end of a road before a small brick building. Around
you is a forest.
A small stream flows out of the building and down a gully.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Josh Blum
3.0 should work as well. Python windows installer comes with tk, which lets
us have a nice little burner gui app free of build dependencies.
------------------------------
Message: 5
Date: Tue, 15 May 2012 09:35:16 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Problem with Synch of two N210s for 4*4MIMO
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/15/2012 01:14 AM, Farrukh Aziz wrote:
> I am using two N210s (fitted with TVRX2 dbs) connected in master/slave
> configuration. Despite feeding the two external reference signals (1PPS and
> 10MHz) I am not able to receive the four complex data streams (Synch=unknown
> PPS). This is the error that I get:
>
> UHD Warning:
> The hardware does not support the requested RX sample rate:
> Target sample rate: 0.001000 MSps
> Actual sample rate: 0.195312 MSps
> OUHD source block got error code 0x2
> gr_block_executor: source <gr_block gr uhd usrp source (49)> produced no
> output. We're marking it DONE.
>
ERROR_CODE_LATE_COMMAND = 0x2,
That tells me the synchronization didnt work.
I would make sure you can detect PPS on both devices. There is an
examples/test_pps_.... example that might be helpful here.
> When I use 'dont sync' option (in UHD USRP source) then I do receive four
> complex streams.
> Thanks in advance, for any useful comments.
>
Its possible for all channels to stream, when the device times are
close, but not synchronized.
-josh
------------------------------
Message: 6
Date: Tue, 15 May 2012 18:38:45 +0200
From: "Simon HB9DRV" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] WBX + Pre-amp
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
I see the WBX quoted as having a noise figure of 5dB. I have a LNA 5000 from
SSB electronics:
http://www.ssb.de/product_info.php?language=en
<http://www.ssb.de/product_info.php?language=en&info=p1128_LNA-5000---Breitb
and-Vorverstaerker-bis-5GHz.html>
&info=p1128_LNA-5000---Breitband-Vorverstaerker-bis-5GHz.html
Is there any reason why I shouldn't use this? I do not plan to transmit with
the WBX at the moment.
Simon Brown, HB9DRV
http://dit-dit-dit.com
Not sent from an iPhone: I don't have one and I don't want one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120515/914655d7/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 15 May 2012 09:40:25 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] high packet loss tunnel.py
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/15/2012 05:36 AM, vegihat vegihat wrote:
> hello folks,
>
>
> I have tried to set TCP/IP over GNU Radio between 2 USRP1 with RFX2400
> daughterboards using the example
> gnuradio/examples/digital/narrowband/tunnel.py
>
> i give
> ./tunnel.py -f 2500e6 --bitrate 500k -v --tx-amplitude=1 --tx-gain=20000
> --rx-gain=20000 -c 50
>
watch out for --tx-amplitude=1, the float values are +/-1.0. To avoid
clipping, I would half this value while you are debugging.
> and i take a ~80% packet loss.
>
>
> How to reduce the high packet loss?
>
> if you want additional info , tell me.
>
> ps: i have attached the output of uhd_usrp_probe
>
>
I recommend to observe the transmit spectrum. Is it at acceptable output
power level and RF frequency.
Same for the RX signal. Is the power level good, and the signal at the
expected baseband frequency?
-josh
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 8
Date: Tue, 15 May 2012 12:55:52 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] WBX + Pre-amp
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
That should be fine, although you'll find that a frequency-specific
LNA will give a *much lower* noise figure.
You'll need to adjust gains
in your application.
-Marcus
On Tue, 15 May 2012 18:38:45 +0200,
Simon HB9DRV wrote:
> Hi,
>
> I see the WBX quoted as having a noise
figure of 5dB. I have a LNA 5000 from SSB electronics:
>
>
http://www.ssb.de/product_info.php?language=en&info=p1128_LNA-5000---Breitband-Vorverstaerker-bis-5GHz.html
[1]
>
> Is there any reason why I shouldn't use this? I do not plan
to transmit with the WBX at the moment.
>
> Simon Brown, HB9DRV
>
http://dit-dit-dit.com
>
> Not sent from an iPhone: I don't have one
and I don't want one.
Links:
------
[1]
http://www.ssb.de/product_info.php?language=en|+|amp|+|info=p1128_LNA-5000---Breitband-Vorverstaerker-bis-5GHz.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120515/b975d662/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 15 May 2012 19:11:08 +0200
From: "Simon HB9DRV" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] WBX + Pre-amp
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi,
Thanks for the input. I have about a 10m co-ax run which will be lossy. When it
comes to the need for lower noise I?ll let the customers buy two and send me
one J . Same with the 10m dish I want J .
I guess to be safe I should use the RX2 connection (or something).
Simon Brown, HB9DRV
<http://dit-dit-dit.com> http://dit-dit-dit.com
You are standing at the end of a road before a small brick building. Around you
is a forest.
A small stream flows out of the building and down a gully.
From: [email protected]
[mailto:[email protected]] On Behalf Of [email protected]
That should be fine, although you'll find that a frequency-specific LNA will
give a *much lower* noise figure.
You'll need to adjust gains in your application.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120515/6518c011/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 15 May 2012 13:20:55 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] WBX + Pre-amp
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
I genenrally prefer the RX2 connection for RX applications.
With
the LNA at the "masthead", you should be able to drive a fair amount of
coax without noticeable dehancements to the noise figure.
-Marcus
On
Tue, 15 May 2012 19:11:08 +0200, Simon HB9DRV wrote:
> Hi,
>
>
Thanks for the input. I have about a 10m co-ax run which will be lossy.
When it comes to the need for lower noise I'll let the customers buy two
and send me one J . Same with the 10m dish I want J .
>
> I guess to
be safe I should use the RX2 connection (or something).
>
> Simon
Brown, HB9DRV
> http://dit-dit-dit.com [1]
>
> You are standing at the
end of a road before a small brick building. Around you is a forest.
>
> A small stream flows out of the building and down a gully.
>
>
FROM: [email protected]
[mailto:[email protected]] ON BEHALF OF
[email protected]
>
> That should be fine, although you'll find that a
frequency-specific LNA will give a *much lower* noise figure.
>
>
You'll need to adjust gains in your application.
Links:
------
[1]
http://dit-dit-dit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120515/6c9d3848/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 15 May 2012 11:34:00 -0700 (PDT)
From: Joel Parker <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] GPS not reporting LAT / LONG
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I have my GPSDO connected to a GPS Antenna with clear view of the sky but the
sensor shows no LAT / LONG is there something I need to do to enable the
polling ?
root@usrp-e1xx:~/GPS# ./gps_test
linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500;
UHD_003.004.000-0-unknown
-- Opening device node /dev/usrp_e0...
-- Initializing FPGA clock to 64.000000MHz...
-- USRP-E100 clock control: 10
--?? r_counter: 2
--?? a_counter: 0
--?? b_counter: 20
--?? prescaler: 8
--?? vco_divider: 5
--?? chan_divider: 5
--?? vco_rate: 1600.000000MHz
--?? chan_rate: 320.000000MHz
--?? out_rate: 64.000000MHz
--
-- Performing wishbone readback test... pass
-- Found a Jackson Labs GPS
-- Setting references to the internal GPSDO
-- Initializing time to the internal GPSDO
GPS GPGGA : GPS_GPGGA:
$GPGGA,183032.00,0000.0000,N,0000.0000,E,0,00,100.0,0.0,M,0.0,M,,*67
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120515/87ce9287/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 15 May 2012 11:36:36 -0700
From: Nick Foster <[email protected]>
To: Joel Parker <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] GPS not reporting LAT / LONG
Message-ID:
<calalhjxr3j5sb6venbznnhjuwotvm6+492cuxub9b0yon9o...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Be patient. Looks like it's not locked yet. The GPS can take a few minutes
to acquire lock. It's slower than a positioning GPS because it does what's
called a "site survey" to determine an accurate location for timing
purposes. Are you using an active antenna?
--n
On Tue, May 15, 2012 at 11:34 AM, Joel Parker <[email protected]>wrote:
> I have my GPSDO connected to a GPS Antenna with clear view of the sky but
> the sensor shows no LAT / LONG is there something I need to do to enable
> the polling ?
>
> root@usrp-e1xx:~/GPS# ./gps_test
> linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500;
> UHD_003.004.000-0-unknown
>
> -- Opening device node /dev/usrp_e0...
> -- Initializing FPGA clock to 64.000000MHz...
> -- USRP-E100 clock control: 10
> -- r_counter: 2
> -- a_counter: 0
> -- b_counter: 20
> -- prescaler: 8
> -- vco_divider: 5
> -- chan_divider: 5
> -- vco_rate: 1600.000000MHz
> -- chan_rate: 320.000000MHz
> -- out_rate: 64.000000MHz
> --
> -- Performing wishbone readback test... pass
> -- Found a Jackson Labs GPS
> -- Setting references to the internal GPSDO
> -- Initializing time to the internal GPSDO
> GPS GPGGA : GPS_GPGGA:
> $GPGGA,183032.00,0000.0000,N,0000.0000,E,0,00,100.0,0.0,M,0.0,M,,*67
>
> _______________________________________________
> 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/20120515/5a98a172/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 15 May 2012 11:41:00 -0700 (PDT)
From: Joel Parker <[email protected]>
To: Nick Foster <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] GPS not reporting LAT / LONG
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
The unit has been up for at least 24 hours at this point. I am wondering if I
just have a bad GPS antenna. Do you have one that you can recommend ?
-- Joel
________________________________
From: Nick Foster <[email protected]>
To: Joel Parker <[email protected]>
Cc: "[email protected]" <[email protected]>
Sent: Tuesday, May 15, 2012 1:36 PM
Subject: Re: [USRP-users] GPS not reporting LAT / LONG
Be patient. Looks like it's not locked yet. The GPS can take a few minutes to
acquire lock. It's slower than a positioning GPS because it does what's called
a "site survey" to determine an accurate location for timing purposes. Are you
using an active antenna?
--n
On Tue, May 15, 2012 at 11:34 AM, Joel Parker <[email protected]> wrote:
I have my GPSDO connected to a GPS Antenna with clear view of the sky but the
sensor shows no LAT / LONG is there something I need to do to enable the
polling ?
>
>
>root@usrp-e1xx:~/GPS# ./gps_test
>linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500;
>UHD_003.004.000-0-unknown
>
>-- Opening device node /dev/usrp_e0...
>-- Initializing FPGA clock to 64.000000MHz...
>-- USRP-E100 clock control: 10
>--?? r_counter: 2
>--?? a_counter: 0
>--?? b_counter: 20
>--?? prescaler: 8
>--?? vco_divider: 5
>--?? chan_divider: 5
>--?? vco_rate: 1600.000000MHz
>--?? chan_rate: 320.000000MHz
>--?? out_rate: 64.000000MHz
>--
>-- Performing wishbone readback test... pass
>-- Found a Jackson Labs
GPS
>-- Setting references to the internal GPSDO
>-- Initializing time to the internal GPSDO
>GPS GPGGA : GPS_GPGGA:
>$GPGGA,183032.00,0000.0000,N,0000.0000,E,0,00,100.0,0.0,M,0.0,M,,*67
>
>_______________________________________________
>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/20120515/58710c32/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 15 May 2012 12:14:08 -0700 (PDT)
From: Joel Parker <[email protected]>
To: Nick Foster <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] GPS not reporting LAT / LONG
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
You were right. Strange that I had to query it before it decided to lock.
-- Joel Parker
________________________________
From: Nick Foster <[email protected]>
To: Joel Parker <[email protected]>
Cc: "[email protected]" <[email protected]>
Sent: Tuesday, May 15, 2012 1:36 PM
Subject: Re: [USRP-users] GPS not reporting LAT / LONG
Be patient. Looks like it's not locked yet. The GPS can take a few minutes to
acquire lock. It's slower than a positioning GPS because it does what's called
a "site survey" to determine an accurate location for timing purposes. Are you
using an active antenna?
--n
On Tue, May 15, 2012 at 11:34 AM, Joel Parker <[email protected]> wrote:
I have my GPSDO connected to a GPS Antenna with clear view of the sky but the
sensor shows no LAT / LONG is there something I need to do to enable the
polling ?
>
>
>root@usrp-e1xx:~/GPS# ./gps_test
>linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500;
>UHD_003.004.000-0-unknown
>
>-- Opening device node /dev/usrp_e0...
>-- Initializing FPGA clock to 64.000000MHz...
>-- USRP-E100 clock control: 10
>--?? r_counter: 2
>--?? a_counter: 0
>--?? b_counter: 20
>--?? prescaler: 8
>--?? vco_divider: 5
>--?? chan_divider: 5
>--?? vco_rate: 1600.000000MHz
>--?? chan_rate: 320.000000MHz
>--?? out_rate: 64.000000MHz
>--
>-- Performing wishbone readback test... pass
>-- Found a Jackson Labs
GPS
>-- Setting references to the internal GPSDO
>-- Initializing time to the internal GPSDO
>GPS GPGGA : GPS_GPGGA:
>$GPGGA,183032.00,0000.0000,N,0000.0000,E,0,00,100.0,0.0,M,0.0,M,,*67
>
>_______________________________________________
>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/20120515/bb000415/attachment-0001.html>
------------------------------
Message: 15
Date: Tue, 15 May 2012 15:32:51 -0700
From: Louis Rey <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP N210 No devices found
Message-ID:
<cabhn0f+5tvkusp+gk_+m9noftvttfv3narfr4yav2dswq+g...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello all,
I finally built and got gnuradio working on ubuntu 10.04. I just received a
USRP N210 rev. 4.
When I run uhd_find or uhd_usrp_probe, I get:
linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.001-129-g23355268
No devices found.
I cannot ping the device either.
Is there something I missed?
Regards,
Lew
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120515/aba23128/attachment-0001.html>
------------------------------
Message: 16
Date: Tue, 15 May 2012 15:39:44 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP N210 No devices found
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/15/2012 03:32 PM, Louis Rey wrote:
> Hello all,
>
> I finally built and got gnuradio working on ubuntu 10.04. I just received a
> USRP N210 rev. 4.
> When I run uhd_find or uhd_usrp_probe, I get:
>
>
> linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.001-129-g23355268
>
> No devices found.
>
> I cannot ping the device either.
>
> Is there something I missed?
>
> Regards,
> Lew
>
Network setup? firewall issue?
http://files.ettus.com/uhd_docs/manual/html/usrp2.html#setup-networking
-josh
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 17
Date: Wed, 16 May 2012 12:47:32 +1200
From: Steve Wright <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP-users Digest, Vol 21, Issue 15
Message-ID: <1337129252.1344.29.camel@steve-desktop>
Content-Type: text/plain; charset="UTF-8"
On Tue, 2012-05-15 at 12:00 -0400, [email protected]
wrote:
> [...] However, FM signals are not designed for this, so you will get
> multipath in the overlapping areas.
>
> The signals from the different transmitters will arrive with different
> phases depending on relative distance [...]180 degrees will tend to cancel
> each other [etc]
That is the answer I thought you were going to give. So this simulcast
transmission thing is bunkum? I concede to your logic, but others are
doing it and it's working.
The VOTER Simulcast that Allstar are doing GPSDO-locks traditional FM
narrow-band communications radios with voting receive, and simulcast
transmit, and they say its working fine - no holes or irregularities.
Why will one work and a similar (also analog) system not?
http://206.212.254.21/unode_docs/rtcm_%20manual.pdf
http://www.wb6ece.org/
Also @Moritz, thank you.
many thanks,
Steve
------------------------------
Message: 18
Date: Tue, 15 May 2012 17:47:50 -0700 (PDT)
From: Farrukh Aziz <[email protected]>
To: Ian Buckley <[email protected]>
Cc: USRP user forum <[email protected]>
Subject: Re: [USRP-users] Problem with Synch of two N210s for 4*4MIMO
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Ian, thanks for your reply. Yes, I did choose a very high decimation factor (D)
in order to decrease the data flow. However by choosing D=512, this problem has
been resolved. But my initial problem still persists and I am getting this
error now:
UHD Warning:
??? The recv buffer could not be resized sufficiently.
??? Target sock buff size: 50000000 bytes.
??? Actual sock buff size: 1000000 bytes.
??? See the transport application notes on buffer resizing.
??? Please run: sudo sysctl -w net.core.rmem_max=50000000
-- mboard1 is MIMO slave
--???? 1) catch time transition at pps edge
--???? 2) set times next pps (synchronously)
UHD Warning:
??? Detected time deviation between board 1 and board 0.
??? Board 0 time is 0.008328 seconds.
??? Board 1 time is 73.011430 seconds.
UHD Error:
??? The receive packet handler failed to time-align packets.
??? 1002 received packets were processed by the handler.
??? However, a timestamp match could not be determined.
UHD source block got error code 0xc
gr_block_executor: source <gr_block gr uhd usrp source (45)> produced no
output.? We're marking it DONE.
I have re-checked the reference signals (1 Hz square wave, Amplitude=5Vpp? and
10 MHz square wave, Amplitude=100mVpp), they appear to be fine but the error is
related to time stamping.
thanks
Farrukh Aziz Bhatti
Department of Electrical & Computer Engineering
University of Auckland
--- On Tue, 15/5/12, Ian Buckley <[email protected]> wrote:
From: Ian Buckley <[email protected]>
Subject: Re: [USRP-users] Problem with Synch of two N210s for 4*4MIMO
To: "Farrukh Aziz" <[email protected]>
Cc: "USRP user forum" <[email protected]>
Received: Tuesday, 15 May, 2012, 9:20 PM
Farrukh,?leaving aside the issue of synchronizing multiple USRP's for the time
being, I think you have a more fundamental problem.The error message indicates
you are trying to configure the USRP to output a 1KHz sample rate stream, and
UHD is reporting that it has configured the URSP for the maximum possible
decimation in H/W that is supported which is 512 (100e6/512=0.195312e6). If you
really require such a low bandwidth signal then will need to distribute the
total decimation required between H/W in the USRP and S/W (Gnuradio/Matlab
etc)-Ian
On May 15, 2012, at 1:14 AM, Farrukh Aziz wrote:
I am using two N210s (fitted with TVRX2 dbs) connected in master/slave
configuration. Despite feeding the two external reference signals (1PPS and
10MHz) I am not able to receive the four complex data streams (Synch=unknown
PPS). This is the error that I get:
UHD Warning:
??? The hardware does not support the requested RX sample rate:
??? Target sample rate: 0.001000 MSps
??? Actual sample rate: 0.195312 MSps
OUHD source block got error code 0x2
gr_block_executor: source <gr_block gr uhd usrp source (49)> produced no
output.? We're marking it DONE.
When I use 'dont sync' option (in UHD USRP source) then I do receive four
complex streams.
Thanks in advance, for any useful comments.
Farrukh Aziz Bhatti
Department of Electrical & Computer Engineering
University of Auckland
_______________________________________________
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/20120515/164807e9/attachment-0001.html>
------------------------------
Message: 19
Date: Tue, 15 May 2012 18:08:17 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Problem with Synch of two N210s for 4*4MIMO
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/15/2012 05:47 PM, Farrukh Aziz wrote:
> Ian, thanks for your reply. Yes, I did choose a very high decimation factor
> (D) in order to decrease the data flow. However by choosing D=512, this
> problem has been resolved. But my initial problem still persists and I am
> getting this error now:
>
> UHD Warning:
> The recv buffer could not be resized sufficiently.
> Target sock buff size: 50000000 bytes.
> Actual sock buff size: 1000000 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=50000000
> -- mboard1 is MIMO slave
> -- 1) catch time transition at pps edge
> -- 2) set times next pps (synchronously)
>
1) Here is my concern "mboard1 is MIMO slave" to me, means that board 1
should lock its time and ref over the mimo cable. You didnt mention a
mimo cable, so this might explain things.
2) I recall this print is from a quite old version of UHD at this point.
I recommend upgrading to the latest 3.4 release or master, maint branch.
also see: http://files.ettus.com/uhd_docs/manual/html/sync.html
All options are available in GRC as well.
> UHD Warning:
> Detected time deviation between board 1 and board 0.
> Board 0 time is 0.008328 seconds.
> Board 1 time is 73.011430 seconds.
>
Well, I think that clears things up. Board 1 is either not getting PPS
or not triggered on PPS.
-Josh
------------------------------
Message: 20
Date: Wed, 16 May 2012 09:15:39 +0700
From: anak galer <[email protected]>
To: [email protected]
Subject: [USRP-users] television transceiver witu USRP 1 ?
Message-ID:
<CAO_+gxKLyKFV87J=etqR9F=9dup8ben1zzwmp8wql7eouja...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
hello
can I use USRP 1 for transceiver television,I want create my own stasiun.
thank you
------------------------------
Message: 21
Date: Wed, 16 May 2012 09:32:26 +0700
From: Deddi Hariprawira <[email protected]>
To: anak galer <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] television transceiver witu USRP 1 ?
Message-ID:
<CAD0oyt+nmo0=bw_usLB7BFr91VvyGjT=e+e9ctttm3fqq6w...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
stasiun apa mas ?
On Wed, May 16, 2012 at 9:15 AM, anak galer <[email protected]> wrote:
> hello
>
> can I use USRP 1 for transceiver television,I want create my own stasiun.
>
> thank you
>
> _______________________________________________
> 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/20120516/28dda569/attachment-0001.html>
------------------------------
Message: 22
Date: Wed, 16 May 2012 13:42:49 +0900
From: Nguyen Truong <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] high packet loss tunnel.py
Message-ID:
<caopsyjstq0b-8aumvor-h6xprj4+agopeqoba45q-rs_4io...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I have completely same problem with USRP E100.
Even the packet loss for benchmark_tx/benchmark_rx is more than 90%.
I tried to calibrate the amplitude and gain but the packet loss is still
very high.
>From my point of view, it's due to the low computational ability of the
processor.
If you're using Virtual machine, you will face the same problem.
On Wed, May 16, 2012 at 1:40 AM, Josh Blum <[email protected]> wrote:
>
>
> On 05/15/2012 05:36 AM, vegihat vegihat wrote:
> > hello folks,
> >
> >
> > I have tried to set TCP/IP over GNU Radio between 2 USRP1 with RFX2400
> > daughterboards using the example
> > gnuradio/examples/digital/narrowband/tunnel.py
> >
> > i give
> > ./tunnel.py -f 2500e6 --bitrate 500k -v --tx-amplitude=1 --tx-gain=20000
> > --rx-gain=20000 -c 50
> >
>
> watch out for --tx-amplitude=1, the float values are +/-1.0. To avoid
> clipping, I would half this value while you are debugging.
>
> > and i take a ~80% packet loss.
> >
> >
> > How to reduce the high packet loss?
> >
> > if you want additional info , tell me.
> >
> > ps: i have attached the output of uhd_usrp_probe
> >
> >
>
> I recommend to observe the transmit spectrum. Is it at acceptable output
> power level and RF frequency.
>
> Same for the RX signal. Is the power level good, and the signal at the
> expected baseband frequency?
>
> -josh
>
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120516/d04b9fdd/attachment-0001.html>
------------------------------
Message: 23
Date: Tue, 15 May 2012 23:36:20 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] high packet loss tunnel.py
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/15/2012 09:42 PM, Nguyen Truong wrote:
> I have completely same problem with USRP E100.
> Even the packet loss for benchmark_tx/benchmark_rx is more than 90%.
>
> I tried to calibrate the amplitude and gain but the packet loss is still
> very high.
>
> From my point of view, it's due to the low computational ability of the
> processor.
>
> If you're using Virtual machine, you will face the same problem.
> last I read,
>
If you are seeing overflow on RX or underflow on TX than that is
probably the case. Otherwise, it has to be something else.
-josh
> On Wed, May 16, 2012 at 1:40 AM, Josh Blum <[email protected]> wrote:
>
>>
>>
>> On 05/15/2012 05:36 AM, vegihat vegihat wrote:
>>> hello folks,
>>>
>>>
>>> I have tried to set TCP/IP over GNU Radio between 2 USRP1 with RFX2400
>>> daughterboards using the example
>>> gnuradio/examples/digital/narrowband/tunnel.py
>>>
>>> i give
>>> ./tunnel.py -f 2500e6 --bitrate 500k -v --tx-amplitude=1 --tx-gain=20000
>>> --rx-gain=20000 -c 50
>>>
>>
>> watch out for --tx-amplitude=1, the float values are +/-1.0. To avoid
>> clipping, I would half this value while you are debugging.
>>
>>> and i take a ~80% packet loss.
>>>
>>>
>>> How to reduce the high packet loss?
>>>
>>> if you want additional info , tell me.
>>>
>>> ps: i have attached the output of uhd_usrp_probe
>>>
>>>
>>
>> I recommend to observe the transmit spectrum. Is it at acceptable output
>> power level and RF frequency.
>>
>> Same for the RX signal. Is the power level good, and the signal at the
>> expected baseband frequency?
>>
>> -josh
>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 24
Date: Wed, 16 May 2012 16:33:17 +0800
From: Eddie Sun <[email protected]>
To: [email protected]
Subject: [USRP-users] About writing to file speed
Message-ID:
<CAB6xtHPc-Fg8UKmMf=XbOpWw=ii2yjrdbg8vjt7qst2kd6c...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
I have a problem while i synchronize two usrp with MIMO and samples to
files, it seems the writing speed is not fast enough while i saving the
files.
i create two usrp device and use two thread to run the function
recv_to_file<std::complex<short>>(original from the rx_samples_to_file.cpp)
while receving
i modified a little like following
template<typename samp_type> void recv_to_file(
uhd::usrp::multi_usrp::sptr usrp,
const std::string &file,
size_t samps_per_buff
){
uhd::rx_metadata_t md;
std::vector<samp_type> buff(samps_per_buff);
std::ofstream outfile(file.c_str(), std::ofstream::binary);
double timeout=1.5+0.1;
while(not stop_signal_called){
size_t num_rx_samps = usrp->get_device()->recv(
&buff.front(), buff.size(), md, uhd::io_type_t::COMPLEX_INT16,
uhd::device::RECV_MODE_ONE_PACKET, timeout
);
timeout=0.1;
if (md.error_code == uhd::rx_metadata_t::ERROR_CODE_TIMEOUT) break;
if (md.error_code != uhd::rx_metadata_t::ERROR_CODE_NONE){
throw std::runtime_error(str(boost::format(
"Unexpected error code 0x%x"
) % md.error_code));
}
outfile.write((const char*)&buff.front(),
num_rx_samps*sizeof(samp_type));
}
outfile.close();
}
the main problem is when i try to save to files(two usrp, two files, the
sampling rate are 4M/s and 20M/s), after starting the program about 7 or 8
secs, and it will show
0terminate called after throwing an instance of 'std::runtime_error'
unexcept error 0x8
it looks like there is an overflow, but if i Comment the line
outfile.write((const char*)&buff.front(), num_rx_samps*sizeof(samp_type));
the program will not write to the files, and the whole process can run over
a minute and still work fine.
I would like to ask is there any other method that can replace this line
and still can do the same thing(write to file),
or it is only the hardware problem?? What should i do so i can fix it, i
want to have this two files to do some post-processing and analysis.
Thanks,
Eddie
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120516/f03d2bb6/attachment-0001.html>
------------------------------
Message: 25
Date: Wed, 16 May 2012 14:16:47 +0200
From: "Simon HB9DRV" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Windows VS 2010 Help Please
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
An embarrassing plea for help J
I'm trying to get a basic program to run. Using rx_multi_samples.cpp I'm
compiling a 32-bit application inside a standard VS 2010 Console
application, so the only change made is to add stdafx.h to the top of the
source.
I can start the application, as soon as I get to the line
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
there is an access violation in UHD.dll. I'm an experienced developer with
VS, there must be something basic that I must to get this to run. Although
creating a 32-bit app the same happens if I create a 64-bit app (yes, I have
the correct UHD installed).
Here's the stack:
> uhd.dll!637aaeab()
[Frames below may be incorrect and/or missing, no symbols
loaded for uhd.dll]
uhd.dll!637ab915()
uhd.dll!637ac07c()
uhd.dll!637ac6b8()
uhd.dll!637acad9()
uhd.dll!637acdd7()
uhd.dll!637adf7a()
kernel32.dll!_HeapFree@12() + 0x14 bytes
msvcr100d.dll!__free_base() + 0x29 bytes
0039e25c()
0039e59c()
Simon Brown, HB9DRV
http://dit-dit-dit.com
Not sent from an iPhone: I don't have one and I don't want one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120516/1492d15e/attachment-0001.html>
------------------------------
Message: 26
Date: Wed, 16 May 2012 15:05:42 +0200
From: "Simon HB9DRV" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] Windows VS 2010 Help Please
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I've been pointed at this:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-April/00417
0.html
OMG I am annoyed.
Simon Brown, HB9DRV
<http://dit-dit-dit.com> http://dit-dit-dit.com
You are standing at the end of a road before a small brick building. Around
you is a forest.
A small stream flows out of the building and down a gully.
From: [email protected]
[mailto:[email protected]] On Behalf Of Simon HB9DRV
Sent: 16 May 2012 14:17
To: [email protected]
Subject: [USRP-users] Windows VS 2010 Help Please
Hi,
An embarrassing plea for help J
I'm trying to get a basic program to run. Using rx_multi_samples.cpp I'm
compiling a 32-bit application inside a standard VS 2010 Console
application, so the only change made is to add stdafx.h to the top of the
source.
I can start the application, as soon as I get to the line
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
there is an access violation in UHD.dll. I'm an experienced developer with
VS, there must be something basic that I must to get this to run. Although
creating a 32-bit app the same happens if I create a 64-bit app (yes, I have
the correct UHD installed).
Here's the stack:
> uhd.dll!637aaeab()
[Frames below may be incorrect and/or missing, no symbols
loaded for uhd.dll]
uhd.dll!637ab915()
uhd.dll!637ac07c()
uhd.dll!637ac6b8()
uhd.dll!637acad9()
uhd.dll!637acdd7()
uhd.dll!637adf7a()
kernel32.dll!_HeapFree@12() + 0x14 bytes
msvcr100d.dll!__free_base() + 0x29 bytes
0039e25c()
0039e59c()
Simon Brown, HB9DRV
http://dit-dit-dit.com
Not sent from an iPhone: I don't have one and I don't want one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120516/f0543940/attachment-0001.html>
------------------------------
Message: 27
Date: Wed, 16 May 2012 07:31:50 -0700
From: Nick Foster <[email protected]>
To: Eddie Sun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] About writing to file speed
Message-ID:
<calalhjvo-1mrjmm52bqupaky_acg5fyzncgkm2mcwajuyu7...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, May 16, 2012 at 1:33 AM, Eddie Sun <[email protected]> wrote:
> Hi all,
>
> I have a problem while i synchronize two usrp with MIMO and samples to
> files, it seems the writing speed is not fast enough while i saving the
> files.
>
> i create two usrp device and use two thread to run the function
> recv_to_file<std::complex<short>>(original from the rx_samples_to_file.cpp)
> while receving
>
> i modified a little like following
>
> template<typename samp_type> void recv_to_file(
> uhd::usrp::multi_usrp::sptr usrp,
> const std::string &file,
> size_t samps_per_buff
> ){
> uhd::rx_metadata_t md;
> std::vector<samp_type> buff(samps_per_buff);
> std::ofstream outfile(file.c_str(), std::ofstream::binary);
> double timeout=1.5+0.1;
> while(not stop_signal_called){
> size_t num_rx_samps = usrp->get_device()->recv(
> &buff.front(), buff.size(), md, uhd::io_type_t::COMPLEX_INT16,
> uhd::device::RECV_MODE_ONE_PACKET, timeout
> );
> timeout=0.1;
> if (md.error_code == uhd::rx_metadata_t::ERROR_CODE_TIMEOUT) break;
> if (md.error_code != uhd::rx_metadata_t::ERROR_CODE_NONE){
> throw std::runtime_error(str(boost::format(
> "Unexpected error code 0x%x"
> ) % md.error_code));
> }
> outfile.write((const char*)&buff.front(),
> num_rx_samps*sizeof(samp_type));
> }
> outfile.close();
> }
>
>
> the main problem is when i try to save to files(two usrp, two files, the
> sampling rate are 4M/s and 20M/s), after starting the program about 7 or 8
> secs, and it will show
>
> 0terminate called after throwing an instance of 'std::runtime_error'
> unexcept error 0x8
>
> it looks like there is an overflow, but if i Comment the line
>
> outfile.write((const char*)&buff.front(), num_rx_samps*sizeof(samp_type));
>
> the program will not write to the files, and the whole process can run
> over a minute and still work fine.
>
> I would like to ask is there any other method that can replace this line
> and still can do the same thing(write to file),
> or it is only the hardware problem?? What should i do so i can fix it, i
> want to have this two files to do some post-processing and analysis.
>
> Thanks,
> Eddie
>
A 20Msps stream is 160MB/s of data -- this is a HUGE amount of data to
stream to disk in real time. If you need only a short capture, you can
create a ramdisk and save the file to RAM and then write it out later. You
will be limited to the amount of RAM you have available, but it will be
able to keep up with the writing. Your only other option is a very very
fast solid state drive.
--n
>
> _______________________________________________
> 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/20120516/d95414ee/attachment-0001.html>
------------------------------
Message: 28
Date: Wed, 16 May 2012 07:36:49 -0700
From: John Malsbury <[email protected]>
To: Eddie Sun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] About writing to file speed
Message-ID:
<can5wegri4ylbvqvsospeg1vk0bw-nnnkgznqeldn1gn-955...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Eddie,
I have seen some success at these rates with usb 3.0 external drives. I'm
still experimenting and will keep you updated. No promises.
Or just do what nick said.
John
On Wednesday, May 16, 2012, Eddie Sun <[email protected]> wrote:
> Hi all,
>
> I have a problem while i synchronize two usrp with MIMO and samples to
files, it seems the writing speed is not fast enough while i saving the
files.
>
> i create two usrp device and use two thread to run the function
recv_to_file<std::complex<short>>(original from the rx_samples_to_file.cpp)
while receving
>
> i modified a little like following
>
> template<typename samp_type> void recv_to_file(
> uhd::usrp::multi_usrp::sptr usrp,
> const std::string &file,
> size_t samps_per_buff
> ){
> uhd::rx_metadata_t md;
> std::vector<samp_type> buff(samps_per_buff);
> std::ofstream outfile(file.c_str(), std::ofstream::binary);
> double timeout=1.5+0.1;
> while(not stop_signal_called){
> size_t num_rx_samps = usrp->get_device()->recv(
> &buff.front(), buff.size(), md, uhd::io_type_t::COMPLEX_INT16,
> uhd::device::RECV_MODE_ONE_PACKET, timeout
> );
> timeout=0.1;
> if (md.error_code == uhd::rx_metadata_t::ERROR_CODE_TIMEOUT)
break;
> if (md.error_code != uhd::rx_metadata_t::ERROR_CODE_NONE){
> throw std::runtime_error(str(boost::format(
> "Unexpected error code 0x%x"
> ) % md.error_code));
> }
> outfile.write((const char*)&buff.front(),
num_rx_samps*sizeof(samp_type));
> }
> outfile.close();
> }
>
>
> the main problem is when i try to save to files(two usrp, two files, the
sampling rate are 4M/s and 20M/s), after starting the program about 7 or 8
secs, and it will show
>
> 0terminate called after throwing an instance of 'std::runtime_error'
unexcept error 0x8
>
> it looks like there is an overflow, but if i Comment the line
>
> outfile.write((const char*)&buff.front(), num_rx_samps*sizeof(samp_type));
>
> the program will not write to the files, and the whole process can run
over a minute and still work fine.
>
> I would like to ask is there any other method that can replace this line
and still can do the same thing(write to file),
> or it is only the hardware problem?? What should i do so i can fix it, i
want to have this two files to do some post-processing and analysis.
>
> Thanks,
> Eddie
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120516/b8fdf751/attachment-0001.html>
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 21, Issue 16
******************************************
