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. N210 Boot Problem (Tim Schuschies)
2. Re: N210 Boot Problem (Nick Foster)
3. GPSDO Time Synchronization (Scott Johnston)
4. E100 Sequence Errors (McKeever, Kenneth R.)
5. USRP E100 (Leonardo S. Cardoso)
6. Data format problem USRPn210 (Invizible Box)
7. Re: Data format problem USRPn210 (Mike McLernon)
8. Re: Changing FPGA Code in USRP N210 (Florian Schlembach)
9. Re: Changing FPGA Code in USRP N210 (Florian Schlembach)
10. Re: CogWave project (Vincent Le Nir)
----------------------------------------------------------------------
Message: 1
Date: Tue, 19 Feb 2013 18:51:44 +0100
From: Tim Schuschies <[email protected]>
To: [email protected]
Subject: [USRP-users] N210 Boot Problem
Message-ID:
<caov+zhv80w9ofzpym8vnnttty4okfk-_hsqpkykc30j3j+-...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
I have a problem booting my USRP N210 Device.
After I got a time out failure while burning my FPGA and FW image, I tried
to set it to the safe mode. This procedure I had to do several times before
and it worked every time. But now only the orange network LED is constantly
on and nothing happens. The device is not booting.
So I tried to program the FPGA using Xilinx debugger which seems to work.
After I could program my own Images like every other time. But when I tried
to reset the device after programming I had the same behavior again. This
time I also could program the FPGA with the debugger, but the net_burner
python script doesn't recognize the device and also uhd_find_devices fails.
Does anyone have an idea whats the problem and how to solve it ?
The images were working well before so I cannot imagine that the images are
broken.
Thank you very much.
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130219/6f78eeb3/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 19 Feb 2013 10:00:44 -0800
From: Nick Foster <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] N210 Boot Problem
Message-ID:
<CALALHJWAq8dadmtQjYvwonMHAYpHmdSVi=myz3mqlu1mwgq...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
After using JTAG to boot the device, use the firmware burner with the
--overwrite-safe option to burn both FPGA and firmware images to the safe
mode slots. This will let the N210 boot from Flash again.
--n
On Feb 19, 2013 10:52 AM, "Tim Schuschies" <[email protected]>
wrote:
> Hi all,
> I have a problem booting my USRP N210 Device.
> After I got a time out failure while burning my FPGA and FW image, I tried
> to set it to the safe mode. This procedure I had to do several times before
> and it worked every time. But now only the orange network LED is constantly
> on and nothing happens. The device is not booting.
> So I tried to program the FPGA using Xilinx debugger which seems to work.
> After I could program my own Images like every other time. But when I tried
> to reset the device after programming I had the same behavior again. This
> time I also could program the FPGA with the debugger, but the net_burner
> python script doesn't recognize the device and also uhd_find_devices fails.
> Does anyone have an idea whats the problem and how to solve it ?
> The images were working well before so I cannot imagine that the images
> are broken.
>
> Thank you very much.
> Tim
>
> _______________________________________________
> 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/20130219/dd168bcc/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 19 Feb 2013 14:17:48 -0500
From: Scott Johnston <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] GPSDO Time Synchronization
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Hello,
I am having trouble with GPSDO Time Synchronization across multiple
USRPs that are connected to separate computers and each one has its own
GPSDO.
I am observing that about half the time, two or more USRPs will disagree
about what time it is. I'm testing this by transmitting from one USRP
and receiving that signal split into two USRPs. I then compare the
difference in time in the stream tags of the two receiving USRPs to the
difference in time when they start receiving the common transmitted signal.
Sometimes its the same and sometimes it is exactly 1 second off.
The GRC file I used on the receive side is attached. The transmit side
is irrelevant, as long as the signal is split into receivers.
I have ensured that the GPSDO units are locked to GPS.
Can someone please explain how to fix this 1 second ambiguity?
Thanks
Scott Johnston
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_tags.grc
Type: text/xml
Size: 15736 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130219/7e5c28f8/attachment-0001.grc>
------------------------------
Message: 4
Date: Tue, 19 Feb 2013 15:51:57 -0500
From: "McKeever, Kenneth R." <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] E100 Sequence Errors
Message-ID: <cd49501d.166e6%[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello,
I am currently working with some E100s which appear to be exhibiting
sequence errors whenever I try to transmit ("S" is flooded on the
output). This seems to happen only when I run a flowgraph with a
transmitting component, whether it is code that I have written or is
example code, such as benchmark_tx.py. I see the same issue on both E100s
that I am working with, which have the same hardware and software
configuration.
This was a problem when I first started development using the factory SD
card images (e1xx-002). Regardless of the code being used, the flowgraph
would run for a while with good RF output from the USRP, then after some
random amount of time (usually minutes), the RF output would halt and "S"
characters would flood the screen.
I have since updated to the latest image (e1xx-003) and have updated all
of the software using opkg. Not only does the problem persist, but it
almost immediately (less than 0.5 second) produces errors upon running any
transmitting code. The time it takes to cut out is related to the sample
rate -- lower sample rates make it cut out quickly (~15 ms) whereas larger
sample rates take a bit longer to cut out (100's of ms).
I am using E100s with WBX RF daughtercards and GPSDOs running up-to-date
software via opkg (GNURadio v.3.6.2 with UHD v.003.005.000).
I came across a discussion on a USENET post from last May talking about a
similar problem, but I'm not sure if a solution reached the official
GNURadio or UHD builds.
http://en.usenet.digipedia.org/thread/13088/3660/
If anyone has run into this before or has more information about a
solution or work around, I'd really appreciate any pointers.
Thanks,
Ken
------------------------------
Message: 5
Date: Wed, 20 Feb 2013 13:37:28 +0100
From: "Leonardo S. Cardoso" <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] USRP E100
Message-ID:
<cajscaaw9vfbz1zdoytyszdbrsjzz38mqkvi72vwlxz19_35...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
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?
Thank you.
Best,
Leonardo S. Cardoso
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130220/37e196e6/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 20 Feb 2013 14:07:45 +0100
From: Invizible Box <[email protected]>
To: [email protected]
Subject: [USRP-users] Data format problem USRPn210
Message-ID:
<cadsorv_xnx0lkxalxh7sk7leuhyrfmbezf9wfyv-smhi_7d...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello everyone,
I hope you guys are doing great.
I have a problem working with my usrp n210.
I am trying to send a signal from a file to the USRP in order to transmit
it and analyse on my spectrum analyzer (SA).
When I read data from a file written in 'float,' format everything is fine
I see the same spectrum on the SA as in the spectrum scope in my simulink
transmitter model.
Next when I read another file where the data is written in 'int16' format,
I see the expected spectrum on the spectrum scope in my simulink model but
on the SA it shows some signal but thats not what I am sending.
Moreover I have tried with other int16/int32 format files, everytime it
shows me the same spectrum on the SA which is not the correct one but the
result on the spectrum scope in simulink model is correct, which means that
I am reading the files correctly.
Please help. I am completely blocked.
Cordially,
ciao.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130220/6a3579e8/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 20 Feb 2013 13:37:44 +0000
From: Mike McLernon <[email protected]>
To: Invizible Box <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Data format problem USRPn210
Message-ID:
<e3879be9a282cb45aab7ce258a9ae48f218a8...@exmb-01-ah.ad.mathworks.com>
Content-Type: text/plain; charset="us-ascii"
Hi Ciao,
What if you read the file in int16 format, then cast the data to double before
you transmit with the USRP radio?
Mike
From: USRP-users [mailto:[email protected]] On Behalf Of
Invizible Box
Sent: Wednesday, February 20, 2013 8:08 AM
To: [email protected]
Subject: [USRP-users] Data format problem USRPn210
Hello everyone,
I hope you guys are doing great.
I have a problem working with my usrp n210.
I am trying to send a signal from a file to the USRP in order to transmit it
and analyse on my spectrum analyzer (SA).
When I read data from a file written in 'float,' format everything is fine I
see the same spectrum on the SA as in the spectrum scope in my simulink
transmitter model.
Next when I read another file where the data is written in 'int16' format, I
see the expected spectrum on the spectrum scope in my simulink model but on the
SA it shows some signal but thats not what I am sending.
Moreover I have tried with other int16/int32 format files, everytime it shows
me the same spectrum on the SA which is not the correct one but the result on
the spectrum scope in simulink model is correct, which means that I am reading
the files correctly.
Please help. I am completely blocked.
Cordially,
ciao.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130220/a13ce4e3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 476 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130220/a13ce4e3/attachment-0001.sig>
------------------------------
Message: 8
Date: Wed, 20 Feb 2013 15:02:22 +0100
From: Florian Schlembach <[email protected]>
To: [email protected]
Cc: [email protected], Jinu
Jayachandran
<[email protected]>
Subject: Re: [USRP-users] Changing FPGA Code in USRP N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 2) I would like to know where to put by FFT verilog code for the
> receiver in the FPGA?. From the code review I have done, my
> understanding is to put the code in /usrp2/top/N2x0/u2plus_core.v.
> And I need to get the sample_rx0 value and strobe_rx0 values from
> the ddc_chain block as input to my FFT block and give the output to
> vita_rx_chain. Is my understanding correct ?. (I tried to implement
> a simple code by taking the sample_rx0 from ddc_chain, modify it
> and sent to vita_rx_chain. Then i used the narrowband example in the
> gnuradio to check if there is any change in data. But there is no
> change and sometimes the receiver doesn't receive at all).
>
>
> This is a good place to do it. Alternatively, you can modify
> ddc_chain.v to add your logic to the end of the RX processing. Either
> way, however, it is important to understand the function of the 'run'
> input from the rx_control module. This is directly controlled by the
> UHD logic to gate when to stream samples over sample_rx0/strobe_rx0, and
> acts as a sort of enable for much of the ddc_chain logic. If you modify
> the logic you will have to ensure that anything inserted between
> ddc_chain and rx_control manages this properly, and also accounts for
> any pipeline delay within your new logic.
Neither of both options is the most straightforwarded options anymore
since was designed a placeholder for some custom logic. It got quite
"easy" if you know how to do it. :-)
Have a look at this README file:
https://github.com/EttusResearch/UHD-Mirror/blob/master/fpga/README.txt
For your purpose, you should proceed as followed:
1. Modify Makefile.N210:
# set me in a custom makefile
CUSTOM_SRCS = $(abspath $(addprefix $(BASE_DIR)/../custom/, \
custom_dsp_rx.v \
))
CUSTOM_DEFS = RX_DSP0_MODULE=custom_dsp_rx
2. Implement your code into /custom/custom_dsp_rx.v
Depending on where you wanna perform fft (before or after the existing
ddc chain, so full bandwidth or decimated) you have to grab the
respective signals. Lets assume now your module should take effect after
ddc, grab your //strobed samples {I16,Q16} from the RX DDC chain
signal ddc_out_sample that comes in with a ddc_out_strobe:
input [31:0] ddc_out_sample,
input ddc_out_strobe, //high on valid sample
output ddc_out_enable, //enables DDC module
and send it further as the bb_sample with a bb_strobe being asserted:
//strobbed baseband samples {I16,Q16} from this module
output [31:0] bb_sample,
output bb_strobe //high on valid sample
3. Validate your custom_dsp_rx.v with a testbench feeding your module
with some stimulus signals
4. Burn it onto your device and hope everything works! :)
------------------------------
Message: 9
Date: Wed, 20 Feb 2013 15:04:33 +0100
From: Florian Schlembach <[email protected]>
To: [email protected]
Cc: [email protected], Jinu
Jayachandran
<[email protected]>
Subject: Re: [USRP-users] Changing FPGA Code in USRP N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 2) I would like to know where to put by FFT verilog code for the
> receiver in the FPGA?. From the code review I have done, my
> understanding is to put the code in /usrp2/top/N2x0/u2plus_core.v.
> And I need to get the sample_rx0 value and strobe_rx0 values from
> the ddc_chain block as input to my FFT block and give the output to
> vita_rx_chain. Is my understanding correct ?. (I tried to implement
> a simple code by taking the sample_rx0 from ddc_chain, modify it
> and sent to vita_rx_chain. Then i used the narrowband example in the
> gnuradio to check if there is any change in data. But there is no
> change and sometimes the receiver doesn't receive at all).
>
>
> This is a good place to do it. Alternatively, you can modify
> ddc_chain.v to add your logic to the end of the RX processing. Either
> way, however, it is important to understand the function of the 'run'
> input from the rx_control module. This is directly controlled by the
> UHD logic to gate when to stream samples over sample_rx0/strobe_rx0, and
> acts as a sort of enable for much of the ddc_chain logic. If you modify
> the logic you will have to ensure that anything inserted between
> ddc_chain and rx_control manages this properly, and also accounts for
> any pipeline delay within your new logic.
>
> Johnathan
Neither of both options is the most straightforwarded options anymore
since was designed a placeholder for some custom logic. It got quite
"easy" if you know how to do it. :-)
Have a look at this README file:
https://github.com/EttusResearch/UHD-Mirror/blob/master/fpga/README.txt
For your purpose, you should proceed as followed:
1. Modify Makefile.N210:
# set me in a custom makefile
CUSTOM_SRCS = $(abspath $(addprefix $(BASE_DIR)/../custom/, \
custom_dsp_rx.v \
))
CUSTOM_DEFS = RX_DSP0_MODULE=custom_dsp_rx
2. Implement your code into /custom/custom_dsp_rx.v
Depending on where you wanna perform fft (before or after the existing
ddc chain, so full bandwidth or decimated) you have to grab the
respective signals. Lets assume now your module should take effect after
ddc, grab your //strobed samples {I16,Q16} from the RX DDC chain
signal ddc_out_sample that comes in with a ddc_out_strobe:
input [31:0] ddc_out_sample,
input ddc_out_strobe, //high on valid sample
output ddc_out_enable, //enables DDC module
and send it further as the bb_sample with a bb_strobe being asserted:
//strobbed baseband samples {I16,Q16} from this module
output [31:0] bb_sample,
output bb_strobe //high on valid sample
3. Validate your custom_dsp_rx.v with a testbench feeding your module
with some stimulus signals
4. Go synthesise it!
5. Burn it onto your device and hope everything works! :)
------------------------------
Message: 10
Date: Wed, 20 Feb 2013 17:45:53 +0100
From: Vincent Le Nir <[email protected]>
To: Chenfei Gao <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] CogWave project
Message-ID: <[email protected]>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Hi Chenfei,
I've just pushed a new update with the spectrum and constellation plots.
Best regards
Vincent
On 02/19/2013 12:46 AM, Chenfei Gao wrote:
> Hi all,
>
> Is anybody using CogWave proposed by Vincent? It's a great project,
> especially on Cognitive radio platform building. I checkout from git but I
> found I could only launch the CogWave.pro in qtcreator which showed only a
> tx/rx main window. I don't know how to launch the main window showing
> spectrum sensing information as that in demo video. That't one of my
> questions. Another, where is the video source I should put? Is it coming from
> webcam or video files located at some place ? Seems that the git version is
> not the same one in demo video cause it lacks of some functionality. Does
> anybody have the similar situation?
>
> Any suggestions would be appreciated.
>
> Chenfei
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
------------------------------
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 20
******************************************
