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: Changing FPGA Code in USRP N210 (Jinu Jayachandran)
2. Last packet corrupted on USRP1 (Jawad Seddar)
----------------------------------------------------------------------
Message: 1
Date: Sat, 23 Feb 2013 23:48:01 +0530
From: Jinu Jayachandran <[email protected]>
To: Ben Reynwar <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Changing FPGA Code in USRP N210
Message-ID:
<cakmcsyyiw+ybkqr9uqkhnqe_q2fojgj+jc68auntaqzescm...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks for the replies.
I had changed the Makefile.N210R4 as Florian had suggested to include my
custom block after the ddc chain in the receiver module. I want to confirm
whether it is the right place to put my FFT block. So what I did was, I
wrote a simple module in the custom_dsp_rx.v file which takes in
ddc_out_sample and shifts the sample to left by 16 bits (ddc_out_sample <<
16) and assign it to bbc_sample. So basically I am removing the In Phase
components from the sample and corrupting the data (am I right?). I had
also latched the bb_strobe and ddc_out_enable signals.
Then I used the /digital/narrowband example from the gnuradio to transmit a
text file from a remote machine and receive it on host machine. If my
module had worked, the text file should NOT have received correctly. But
surprisingly the data sent from the transmitter is received exactly same at
the receiver host. (I had also tried with changing the values of
ddc_out_sample in many ways and assigning it to bbc_sample. It may be a
stupid way of testing, but I would like to try out things).
1) Is the above way of testing correct ?.
2) If not, how can I test the scenario of changing the received data in
FPGA before putting in my FFT code?
3) Do I need to do anything with set_stb, set_addr and set_data signals?
4) Is the narrowband example enough to display it in the host machine ?
5) Is there anything else I am missing?
Thanks and Regards
Jinu
On 15 February 2013 21:14, Ben Reynwar <[email protected]> wrote:
> I've had a crack at getting an FFT working on the B100 FPGA. It's not
> working yet, but it might still be useful to check out.
>
> The code is at:
> https://github.com/benreynwar/fpga-sdrlib
>
> I do as much debugging on possible using the Icarus simulator and use
> MyHDL to interface with it so I can write my QA code in python.
>
> Ben
>
>
> On Fri, Feb 15, 2013 at 2:31 AM, Jinu Jayachandran
> <[email protected]> wrote:
> > Hi,
> >
> > I am trying to implement an FFT algorithm in USRP N210 R4 FPGA. I would
> > like to know if the procedure I am following to build the FPGA image is
> > correct. The procedure is as follows
> >
> > 1) Downloaded the images from
> > http://code.ettus.com/redmine/ettus/projects/uhd/repository
> > 2) I have edited the make file in the images folder to make images only
> for
> > N series firmware and N210 FPGA
> > 3) Then I did a 'make images' in the image folder
> > 4) It generated a .bin files for firmware and FPGA in /images/images
> folder
> >
> > I am facing the following problems
> >
> > 1) The building of the fpga image took around 30 minutes in my machine.
> So
> > whenever I edit the FPGA code I should wait for 30 minutes before I want
> to
> > test if it is working properly. Is this the normal time it takes to
> build ?.
> > Can I reduce the time to build image in some way?
> >
> > 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).
> >
> > Please help
> >
> > Thanks and Regards
> > Jinu
> >
> > _______________________________________________
> > 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/20130223/2173f4d0/attachment-0001.html>
------------------------------
Message: 2
Date: Sat, 23 Feb 2013 19:41:27 +0100
From: Jawad Seddar <[email protected]>
To: [email protected]
Subject: [USRP-users] Last packet corrupted on USRP1
Message-ID:
<cae9wgf-meaokyrp96gnekmhptrgbyujhvqo30s55ek8jng7...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I just started working with GNURadio 3 weeks ago.
I am currently using 2 USRP1 devices :
- The first one is equipped with a RFX900 daughter board and a RFX2400
- The second one is equipped with a RFX900 and a XCV2450
I have installed the latest GNURadio version on two computers (using the
build_gnuradio script) and have started playing around with those devices.
One of my first tests was to use the narrowband benchmark scripts in order
to check that I could send and receive on both devices and on any daugther
board. I could send and receive correctly (ok = true, no pktno missing)
using a variety of frequencies but not using the gmsk modulation (It worked
great using bpsk, dbpsk, dqpsk...).
After that first step, I went on and tried the narrowband tunnel.py example
but noticed that I wasn't seeing any packets at the receiver side though I
configured both gr0 interfaces on both computers and could see packets
being transmitted at the transmitter side.
After entering the arp tables manually on each computer, I still couldn't
ping any of the machines but oddly enough I could user iperf and send udp
packets from one machine to another. These packets were correctly received
but the answer got lost on the way back.
This got me thinking, what if only large packets could be seen at the
receiver? So I tried pinging using large packets (1400 Bytes) still
entering the arp manually, still nothing at the receiver (sometimes a
ok=false). Then I tried pinging and flooding (-f) still using large packets
(1400 Bytes), I could see the packets arriving and passing the CRC check
(ok = true).
So I went back to the benchmark scripts and played a bit with the
parameters. I noticed that when using the discontinuous mode (it sends 5
packets then stops for 1 second and repeats) I was receiving the 4 first
packets correctly but the last one failed the CRC check (ok = false). I
tried different packet sizes and different burst sizes (number of packets
in a row) and different sleeping times between emissions, I always get the
same results : the last packet doesn't pass the CRC check (sometimes the
first one as well).
So I thought that maybe the last bits of the transmission were corrupted,
so I went to the crc.py file and added stuffing bytes after the CRC field
and removed them at the receiver side. I went up to 2048 bytes of stuffing
(starting at 1 byte first), but it didn't yield much success.
Then I decided to send a dummy packet after each payload packet. I tried
different sizes for the dummy packet and got some results. For instance,
adding a 16 Byte dummy after an 8 Byte long payload did work but the size
of the dummy packet seems to be dependent on the size of the payload...
I can't seem to figure out what is causing the problem in the first place.
I have been thinking about synchronisation issues (because sometimes the
first packet is lost as well as the last one), or maybe power issues (the
transmitter shuts down before the last bit is out) . The last cause should
have been fixed by the stuffing after the CRC...
I thank everybody who has reached this point, I am currently looking for
any insights you might have on this issue.
Thank you for your help.
Jawad Seddar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130223/4a6b5abb/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 24
******************************************
