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: USRP E100 (Josh Blum)
2. Re: Libertas driver for the W2CBW003 (Philip Balister)
3. Bandwidth control approach (Juan Daniel Fernandez Martinez)
4. timed commands not tuning the device at the desired time
(Birhane Alemayoh)
5. OFDM Demod in usrpn210 (Mohammed Ramadan)
----------------------------------------------------------------------
Message: 1
Date: Wed, 27 Feb 2013 13:14:48 -0600
From: Josh Blum <[email protected]>
To: "Macre, William R" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP E100
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 02/27/2013 10:20 AM, Macre, William R wrote:
> Josh:
>
> Correction: I downloaded the tested your second build:
> http://files.ettus.com/binaries/e100-misc/usrp_e100_fpga_v2_timing.bin
>
> not the first one:
>
> http://files.ettus.com/binaries/e100-misc/usrp_e100_fpga_v2.bin
>
> bill
Apologies, I have uploaded an E110 and E100 image just now:
http://files.ettus.com/binaries/e100-misc/
-josh
>
>
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Macre, William R
> Sent: Wednesday, February 27, 2013 10:30 AM
> To: McKeever, Kenneth R.; [email protected]; [email protected]
> Cc: Hodge, James E; Miller, Robert David
> Subject: Re: [USRP-users] USRP E100
>
> Josh:
>
> I am having the same problem as Ken with the "S"s while transmitting from the
> USRP-E110. I thought I would get your latest FPGA fix a try downloading
> usrp_e100_fpga_v2.bin to /usr/local/share/uhd/images, saving the original
> E110 bin file, and renaming it to usrp_e110_fpga.bin. I thought that would be
> too easy to fix the problem and it didn't. I got the following error:
>
> linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500;
> UHD_003.005.001-25-ge134b863 Creating the usrp device with: ...
> -- Loading FPGA image: /usr/local/share/uhd/images/usrp_e110_fpga.bin... done
> = 1
> ERROR: EnvironentError: OSError: INIT_B went high, error occurred.
>
>
> I am guessing that there are some differences in the FPGA builds between the
> E100 and E110. Do you have a version with the fixes for the E110???
>
> Bill Macre
> Applied Communication Sciences
>
>
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> McKeever, Kenneth R.
> Sent: Thursday, February 21, 2013 8:59 AM
> To: [email protected]; [email protected]
> Subject: Re: [USRP-users] USRP E100
>
> Hi Josh,
>
> I replaced the file and the problem still remained. However, it seemed to
> take a bit longer before the sequence errors kicked in.
>
> Thanks,
> Ken
>
> On 2/20/13 10:12 PM, "Josh Blum" <[email protected]> wrote:
>
>>
>>
>> On 02/20/2013 06:37 AM, Leonardo S. Cardoso wrote:
>>> Hello all,
>>>
>>> I've been having "S" (sequence) problems trying to transmit with my
>>> USRP e100. I've recently updated all of my GNU Radio (3.6.2) and UHD
>>> (UHD_003.005.000) installation, with no luck...
>>>
>>> Looking for info on the web, I've seen this error reported before for
>>> earlier versions of the UHD driver. I've tried all the versions of the
>>> UHD driver I could find online with no luck. Is there something I'm
>>> missing?
>>>
>>> Can anyone help?
>>
>> Sorry guys. Its looks like there is an unconstrained path. Can you try
>> this fpga image in place of the one on your system in
>> /usr/share/uhd/images (this is where opkg puts it)
>>
>> http://files.ettus.com/binaries/e100-misc/usrp_e100_fpga_v2.bin
>>
>> -josh
>>
>>>
>>> Thank you.
>>>
>>> Best,
>>>
>>> Leonardo S. Cardoso
>>> [email protected]
>>>
>>>
>>>
>>> _______________________________________________
>>> 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: 2
Date: Wed, 27 Feb 2013 11:28:28 -0800
From: Philip Balister <[email protected]>
To: Michael Yan <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [USRP-users] Libertas driver for the W2CBW003
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 02/27/2013 07:32 AM, Michael Yan wrote:
> Hi,
>
> For our application, we wish to decode 802.11 packets on a consumer
> grade wifi module. I'm reaching out to anyone who has replaced the
> Gumstix Overo board in the E100-series machine with a wifi-enabled
> Gumstix board, namely the Overo FireSTORM. I have already replaced the
> board in our machine, but have been unable to get the wifi module to
> work (Everything else seems to work perfectly).
I've ordered a FireStorm so I can test this combination in an E100. I
can't get to this right away, but will try to get this sorted out so the
stock E100 (+ updates) support the wifi.
Philip
>
> The FireSTORM has the exact same configuration as the packaged Gumstix
> board, but with the addition of a wifi module soldered on. I see no
> reason why reason it shouldn't work, and suspect it is a driver problem.
>
> Namely, in my driver log, I found the following error:
>
> lib80211: common routines for IEEE802.11 drivers
> lib80211_crypt: registered algorithm 'NULL'
> cfg80211: Calling CRDA to update world regulatory domain
> libertas_sdio: Libertas SDIO driver
> libertas_sdio: Copyright Pierre Ossman
> libertas_sdio: failed to find firmware (-2)
> libertas_sdio: probe of mmc1:0001:1 failed with error -2
>
> Has anyone else attempted to do this? I've tried downloading the
> relevant linux-firmware files and placing them in /lib/firmware, but
> that didn't seem to work (same error).
>
> Regards,
>
> Michael Yan
> HCLab, University of Waterloo
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
------------------------------
Message: 3
Date: Wed, 27 Feb 2013 20:05:48 +0000
From: Juan Daniel Fernandez Martinez <[email protected]>
To: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: [USRP-users] Bandwidth control approach
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi everyone:
I need to manage a span that can be bigger than the USRP span limit. I have
been looking at usrp_spectrum_sense.py but I would rather prefer to solve this
matter in C++ with a control block that changes the central frequency and span
(I don't understand how to apply the usrp_spectrum_sense approach to my
blocks). Is this possible? Can a block manage the variables that are used by
the UHD:USRP Source?
Thanks in advance :)
________________________________
Este documento puede contener informaci?n privilegiada o confidencial. Por
tanto, usar esta informaci?n y sus anexos para prop?sitos ajenos a los de la
Universidad Icesi, divulgarla a personas a las cuales no se encuentre destinado
este correo o reproducirla total o parcialmente, se encuentra prohibido en
virtud de la legislaci?n vigente. La universidad no asumir? responsabilidad
sobre informaci?n, opiniones o criterios contenidos en este correo que no est?n
directamente relacionados con la Icesi. Si usted no es el destinatario
autorizado o por error recibe este mensaje, por favor informe al remitente y
posteriormente b?rrelo de su sistema sin conservar copia del mismo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130227/de40169d/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 28 Feb 2013 09:48:33 +0300
From: Birhane Alemayoh <[email protected]>
To: usrp users forum <[email protected]>
Subject: [USRP-users] timed commands not tuning the device at the
desired time
Message-ID:
<CAPF4MOyJkSU0AA91M9_=xyiqt2pgveg4ob2gag79wgzklms...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Dear all
I have written a piece of code to test timed-commands.
My application implements two threads the first thread to tune USRP
periodically every 1.5 seconds from now and the second thread to display
the overall receiving chain frequency that is to observe whether the tuning
takes place in the desired time. below is the implementation of
timed-command for timed tuning of the USRP
usrp->set_time_now(uhd::time_spec_t(0.0));
MAList=[3, 7,33, 45, 80, 85, 94,103]
usrp->set_rx_freq(936.4e6); //setting beacon channel
while(i<8)
{
int MAIO =(i%8);
arfcn=MAList[MAIO];
if(arfcn>=1 && arfcn<=124)
{
hope_freq=(935+ .2*arfcn)*1e6 ;
}
//hopping from cord
uhd::tune_request_t tune_req(hope_freq); //retune USRP
tune_req.rf_freq_policy=uhd::tune_request_t::POLICY_NONE;
const uhd::time_spec_t tune_time = usrp->get_time_now() +
uhd::time_spec_t(1.5);
usrp->set_command_time(tune_time);
tune_res = usrp->set_rx_freq(tune_req);
usrp->clear_command_time();
while(usrp->get_time_now()<tune_time)
{
cout<<"do nothing and wait to prevent premature tuning"<<endl;
}
i++;
}
now my expectation when I run this program was, to get @ least 1.5 second
time difference between successive tune requests, unfortunately the result
shows some early tuning
Actual RX Freq after hopping: 935.600000 Mhz...@time: 1.50161
Actual RX Freq after hopping: 935.600000 Mhz...@time: 1.50222
Actual RX Freq after hopping: 935.600000 Mhz...@time: 1.50258
Actual RX Freq after hopping: 936.400000 Mhz...@time: 1.50298 ->unexpected
Actual RX Freq after hopping: 936.400000 Mhz...@time: 3.00306
Actual RX Freq after hopping: 936.400000 Mhz...@time: 3.00352
Actual RX Freq after hopping: 941.600000 Mhz...@time: 3.00409 ->unexpected
Actual RX Freq after hopping: 941.600000 Mhz...@time: 4.50418
Actual RX Freq after hopping: 941.600000 Mhz...@time: 4.50488
Actual RX Freq after hopping: 941.600000 Mhz...@time: 4.50526
Actual RX Freq after hopping: 944.000000 Mhz...@time: 6.00517
Actual RX Freq after hopping: 944.000000 Mhz...@time: 6.00578
Actual RX Freq after hopping: 944.000000 Mhz...@time: 6.00615
Actual RX Freq after hopping: 951.000000 Mhz...@time: 6.00655 ->unexpected
Actual RX Freq after hopping: 951.000000 Mhz...@time: 7.50661
Actual RX Freq after hopping: 951.000000 Mhz...@time: 7.5071
Actual RX Freq after hopping: 951.000000 Mhz...@time: 7.50769
Actual RX Freq after hopping: 952.000000 Mhz...@time: 9.00758
Actual RX Freq after hopping: 952.000000 Mhz...@time: 9.00821
Actual RX Freq after hopping: 952.000000 Mhz...@time: 9.00858
Actual RX Freq after hopping: 953.800000 Mhz...@time: 9.00897 ->unexpected
Actual RX Freq after hopping: 953.800000 Mhz...@time: 10.5088
Actual RX Freq after hopping: 953.800000 Mhz...@time: 10.5093
Actual RX Freq after hopping: 953.800000 Mhz...@time: 10.5097
Actual RX Freq after hopping: 953.800000 Mhz...@time: 10.5101
Actual RX Freq after hopping: 955.600000 Mhz...@time: 10.5105 ->unexpected
Actual RX Freq after hopping: 955.600000 Mhz...@time: 12.0105
Actual RX Freq after hopping: 955.600000 Mhz...@time: 12.011
what do you think is the problem?
Please help me here cause in real-time hopping such kind of premature
tuning result in synchronization problem with BTS
Thanks in advance!
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
With best regards,
BirhA
Birhane Alemayoh Siyum
BSc in Electrical and Electronics Engineering
M.Tech in Communication Engineering
CCNA certified
INSA, Addis Ababa, Ethiopia
Mobile: +251 912603216
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130228/30092265/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 28 Feb 2013 06:24:16 -0800 (PST)
From: Mohammed Ramadan <[email protected]>
To: [email protected]
Subject: [USRP-users] OFDM Demod in usrpn210
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
i try to use usrpn210 as a simple transiever so i use?Random source<<OFDM Mod<<
usrp sink (parallel with fft sink) ? ? ?thenUSRP source<<OFDM Demod<< Scope Sink
when run this example i have plot in fftbut demodulated signal not
appears(written TIMEOUT)also kindly advise me if i want to send via one port in
the usrp front end and?receive?via the other one (daughter?board
xcvr2450)??????which can be the transmitter and which the receiver.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130228/d347943b/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 30, Issue 28
******************************************
