[Discuss-gnuradio] UHD Daughter Board EEPROM Format (calibration data)

2013-10-16 Thread Alexander B 

I am wondering if there has been any formalized structure for storing the IQ
balance offset data in the dboard EEPROM.

The following snippet is taken from the UHD that is packaged with GNU radio
3.5.1
(I'm not actually sure if the UHD version is different from the GNU radio
package 3.7?)


// format of daughterboard EEPROM
// 00: 0xDB code for ``I'm a daughterboard''
// 01:   .. Daughterboard ID (LSB)
// 02:   .. Daughterboard ID (MSB)
// 03:   .. io bits  7-0 direction (bit set if it's an output from m'board)
// 04:   .. io bits 15-8 direction (bit set if it's an output from m'board)
// 05:   .. ADC0 DC offset correction (LSB)
// 06:   .. ADC0 DC offset correction (MSB)
// 07:   .. ADC1 DC offset correction (LSB)
// 08:   .. ADC1 DC offset correction (MSB)
//  ...
// 1f:   .. negative of the sum of bytes [0x00, 0x1e]

#define DB_EEPROM_MAGIC 0x00
#define DB_EEPROM_MAGIC_VALUE   0xDB
#define DB_EEPROM_ID_LSB0x01
#define DB_EEPROM_ID_MSB0x02
#define DB_EEPROM_REV_LSB   0x03
#define DB_EEPROM_REV_MSB   0x04
#define DB_EEPROM_OFFSET_0_LSB  0x05 // offset correction for ADC or DAC 0
#define DB_EEPROM_OFFSET_0_MSB  0x06
#define DB_EEPROM_OFFSET_1_LSB  0x07 // offset correction for ADC or DAC 1
#define DB_EEPROM_OFFSET_1_MSB  0x08
#define DB_EEPROM_SERIAL0x09
#define DB_EEPROM_SERIAL_LEN0x09 //9 ASCII characters
#define DB_EEPROM_CHKSUM0x1f

#define DB_EEPROM_CLEN  0x20 // length of common portion of eeprom

#define DB_EEPROM_CUSTOM_BASE   DB_EEPROM_CLEN // first avail offset for
   //   daughterboard specific
use


The storage of calibration data for DC offset is stored in 0x05 - 0x08.

But what about the IQ offsets? 
There is a gap between reserved addresses 0x09 and 0x1f. 
Is the use of this area documented?

There is a utility to calibrate the board and it generates a text file.
Presumably, the authors also implemented a method to make use of this data?

Continuing, the ettus boards driver code sets the gain, though I do not see
any request for the offset data stored in EEPROM inside the constructor or
elsewhere.

This is a similar issue with IQ balance, ie. formalized structure for both
storing calibration data in EEPROM and then accessing it and using it during
runtime.




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/UHD-Daughter-Board-EEPROM-Format-calibration-data-tp44187.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] UHD version

2013-10-16 Thread Alexander B 
Does anyone know if the UHD and GNUradio version are linked together, as in,
I have the UHD and GNUradio that comes with the gnuradio-install script
(3.6.5.1) and I know the latest is 3.7.x.

This script also installs UHD version 3.6.0-1.

Is this the latest UHD?

Alkex



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/UHD-version-tp44188.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time synchronization between two USRPs without external signal

2013-10-16 Thread Miklos Maroti 
Hi Harry,

On Sat, Oct 12, 2013 at 3:12 PM, Harry Zhang  wrote:
> Dear Miklos,
> Thank you for your inspiring reply.
> 1.I do think this method sounds like a receiver-receiver sync while sync
> message's transmitter A also doing beacon node C's function ( (1)sending
> sync message and (2)recording receive time which would be sended to B for
> sync).Is it correct?

Well, it is a transmitter-receiver synchronization, since only two
nodes are involved A and B, and only A sends, B only receives. The
real problem is to correlate samples with time, and I have used the RX
chain sample counter as "time" both on node A and B. You cannot use PC
time because of large errors over ethernet/USB so you have to use the
clock of the FPGA.

> 2.For 1us accuracy, does it mean the sample rate must be more than 1e6?

Yes, of course. But you can even synchronize at 10 times the sampling
rate (hard, but not impossible), i.e. you would use 1e6 sampling rate
and get 1e7 precision.

> 3.Does "close to zero samples" means the sample_rate*sample_offset
> produces larger error when I use it for getting sync message's receive time?

close to zero samples is complex numbers 1e^-4 + 1e^-4*j. The reason I
do not use zero complex numbers is because I am afraid that the FPGA
switches off the TX chain if you continuously try to transmit zeros. I
am not sure that it does, you can experiment with that.

> 4.The 1us is the jitter caused by sample duration.What about the jitter
> produced by tx/rx tags? I do think 160us is mainly caused by the difference
> between actual time when message leaving/arriving antenna and tx/rx tags's
> time.What's your opinion?

I do not know about the tx/rx tags. Of course the FPGA needs time to
do the DSP, so it is possible that what you are seeing is the DSP
time. However, the DSP time should be almost completely deterministic,
so it cannot be a jitter just some time offset. If you see a jitter,
then I think it must be caused by either ethernet or some DSP startup
artifacts.

Miklos

>
> Best,
> Harry
>
>
> 2013/10/12 19:17, Miklos Maroti wrote:
>>
>> Hi Harry,
>>
>> First, you should always transmit from node A, but when you want to be
>> silent, then transmit something very close to zero complex numbers.
>> This will ensure, that you have a nice continuous stream of data going
>> out, and you can plan to do anything you want with sampling rate
>> precision (better than 1us). Once you can do this, then transmit some
>> pseudo random sequence from node A, e.g. BPSK with 2 samples per bit,
>> and it is possible to synchronize to that with sampling rate precision
>> again. Now comes the trick: node A not only transmits continuously,
>> but it also receives continuously just like node B (with an antenna or
>> just overhearing in the board). Both A and B synchronizes to the
>> signal transmitted by A. In case of node A you do not have to worry of
>> slightly different clocks, so once you are synchronized you will never
>> get out of sync if you count the number of samples. In the case of
>> node B it is harder, since node A might run a little faster or slower,
>> so you will get out of sync, so you have to maintain synchronization.
>> At this point, you have achieved synchronization of the two USRP
>> nodes: you can stop sending periodically (continue spending close to
>> zero samples) and then you can sample some data from node C, doing
>> beam forming (depends on modulation), or whatever. You can correlate
>> the received samples at node B with the received samples at node A
>> with close to one sample precision (better than 1us).
>>
>> If you do not want to transmit all the time, then you can use TX tags,
>> but it gets a little trickier, and I think there is some bug in the
>> FPGA hardware to cause very rarely one sample shift between the TX and
>> RX chain. I am not absolutely sure about this, but I could not explain
>> something in any other way.
>>
>> Best,
>> Miklos
>>
>> On Sat, Oct 12, 2013 at 10:10 AM, Harry Zhang  wrote:
>>>
>>> Dear Miklos,
>>>  I'm glad to hear from you.
>>>  The idea of this experiment is quite similar to the core of your
>>> honored
>>> paper "The flooding time synchronization protocol". It's a
>>> transmitter-receiver sync method using precious tx/rx timestamp to
>>> synchronize transmitter's and receiver's local timer.
>>>  On the transmitter side, sync message is transmitted every 1 sec.
>>> Using
>>> rx tags, it's easy to get the average receive interval is 1.0003sec and
>>> the
>>> jitter is around 320us. Considering the interval jitter is 2*(rx
>>> jitter+rx
>>> jitter), the sync accuracy is 160us.
>>>  I wanna break into USRP FPGA to achieve 1us or less accuracy. And I
>>> don't understand your "continuously transmission". Could give me some
>>> details.
>>>
>>>
>>> 2013/10/12 9:03, Miklos Maroti wrote:
>>>
>>> Hi Harrz,
>>>
>>> What do you mean by 160us precision? How did you measure it or compute
>>> it exactly? I do not understand your go

Re: [Discuss-gnuradio] UHD version

2013-10-16 Thread Marcus D. Leech 

On 10/16/2013 07:25 AM, Alexander B wrote:

Does anyone know if the UHD and GNUradio version are linked together, as in,
I have the UHD and GNUradio that comes with the gnuradio-install script
(3.6.5.1) and I know the latest is 3.7.x.

This script also installs UHD version 3.6.0-1.

Is this the latest UHD?

Alkex



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/UHD-version-tp44188.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

The UHD version numbers and Gnu Radio version numbers are entirely 
independent.


If gr-uhd detects an API/ABI mismatch to the UHD version you're running, 
it will tell you.




--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] cmake module issue

2013-10-16 Thread Michael Dickens 
I received a report this morning that gr-osmosdr was not configuring correctly 
in MacPorts; not able to find GNU Radio.  Trying this myself, I can recreate 
the issue.  After some investigation, the issue is somewhere between a cmake 
bug, and GR issue, and "my bad".  I've read through the cmake documents on this 
topic as well as tried what cmake printed as its error message, but none of 
those make sense or work.  I can work around the issue, but I think there needs 
to be better integration between GR and cmake.

What happened is that yesterday (Tuesday, 15-Oct-2013) I pushed a change which 
moved the GR cmake files from their default install location, 
${prefix}/lib/cmake, to a common (across all ports) cmake location: 
${prefix}/share/cmake/modules/.  After install, I moved ${prefix}/lib/cmake/* 
into ${prefix}/share/cmake/modules/ -> which means there are 2 directories now: 
gnuradio and volk.  I thought that this is the way cmake should like things, 
and I know it is the way MacPorts prefers non-cmake-provided cmake modules to 
be installed.

But, cmake does not like this setup; it cannot find GR using this setup.  After 
testing a bunch, I find that there are 2 configurations cmake likes:

1) having "FindGnuradio.cmake" in a directory in CMAKE_MODULE_PATH (whether as 
an actual file or linked).

2) having "GnuradioConfig.cmake" in a top-level directory in some other cmake 
search path -- I don't have a variable name for this one, but it seems to 
include "${prefix}/lib/cmake:${prefix}/share/cmake", where the "cmake-X.Y" is 
installed (and known) by cmake itself; seems like it is like each value in 
CMAKE_MODULE_PATH but with "[Mm]odules" removed from the end.

GR provides just GnuradioConfig.cmake, not FindGnuradio.cmake.  Hence, I have 
to place the "gnuradio" directory in a top-level directory, not in a modules 
directory.  It also seems to work that I can link GnuradioConfig.cmake to 
FindGnuradio.cmake so long as this link is in a directory in CMAKE_MODULE_PATH.

So ... I'm not sure what to make of this behavior by cmake.  I will fix the way 
these files are installed within MacPorts, for now, but I hope we come up with 
a better solution. - MLD


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Importing and using blocks from new version of GRC to the previous version

2013-10-16 Thread Marcus Müller 

Hi Kresimir,

sadly, the answer to your question is "no", unless you start backporting 
stuff yourself.
I know this is kind of not really a satsfying answer, but: If you don't 
really really rely on GNU Radio running under windows, I strongly 
recommend looking into linux as GNU Radio development platform; maybe 
first try running it in a virtual machine, see if it is big of a problem 
using linux.


Then: If you want to sound "real" channels (big scale outdoor ones, at 
least), try the excellent gr-channelsounder: 
https://github.com/gbaier/gr_channelsounder that runs under GR 3.6; it 
will give you channel models that can be directly used.


Hope that helped anyway,
Marcus


Hi all!

While trying to use the latest version of GR on Windows, I am 
receiving the same error discussed here (No module named wxgui_swig):

http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg44400.html

The new version of the GR is particularly appealing to me as in the 
GRC, there seem to be are "Fading model" and "Frequency selective 
fading" blocks that I would like to use.


Is there a way to somehow "import" these blocks so that I can use them 
in version 2.6?


Thanks!

Regards,
Kresimir

Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] how to install blocks in gnuradio

2013-10-16 Thread Maheshkumar Pandit 
Dear all,


ther is some block are not available in gnuradio companion
, like fast autocorrelation and any block , am sink .spectrum recorder.
ther code are available in following link
http://wiki.spench.net/wiki/Fast_Auto-correlation


but did not get how to install,

help me if any buddy done before ...
-- 
*Thanks and regard:*
*

MR.Maheshkumar Pandit
**
*
*call @ 9662784649
*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD Daughter Board EEPROM Format (calibration data)

2013-10-16 Thread Marcus Müller 

Hello Alexander,
UHD does not come bundled with GNU Radio; they are two completely 
independent libraries.
You're sending some code from UHD, but from the defines below I'm not 
quite sure if you're a) referring to the firmware code or b) referring 
to the host (PC) code.

What file exactly is this from?
Anyway, this has nothng to do with GNU Radio as such, but with the Code 
for Ettus USRPs.
Since your question is quite complicated, please join the USRP users 
mailing list  () and write your question to usrp-us...@lists.ettus.com, 
the folks there will be glad to help you.


Greetings,
Marcus


I am wondering if there has been any formalized structure for storing the IQ
balance offset data in the dboard EEPROM.

The following snippet is taken from the UHD that is packaged with GNU radio
3.5.1
(I'm not actually sure if the UHD version is different from the GNU radio
package 3.7?)


// format of daughterboard EEPROM
// 00: 0xDB code for ``I'm a daughterboard''
// 01:   .. Daughterboard ID (LSB)
// 02:   .. Daughterboard ID (MSB)
// 03:   .. io bits  7-0 direction (bit set if it's an output from m'board)
// 04:   .. io bits 15-8 direction (bit set if it's an output from m'board)
// 05:   .. ADC0 DC offset correction (LSB)
// 06:   .. ADC0 DC offset correction (MSB)
// 07:   .. ADC1 DC offset correction (LSB)
// 08:   .. ADC1 DC offset correction (MSB)
//  ...
// 1f:   .. negative of the sum of bytes [0x00, 0x1e]

#define DB_EEPROM_MAGIC 0x00
#define DB_EEPROM_MAGIC_VALUE   0xDB
#define DB_EEPROM_ID_LSB0x01
#define DB_EEPROM_ID_MSB0x02
#define DB_EEPROM_REV_LSB   0x03
#define DB_EEPROM_REV_MSB   0x04
#define DB_EEPROM_OFFSET_0_LSB  0x05 // offset correction for ADC or DAC 0
#define DB_EEPROM_OFFSET_0_MSB  0x06
#define DB_EEPROM_OFFSET_1_LSB  0x07 // offset correction for ADC or DAC 1
#define DB_EEPROM_OFFSET_1_MSB  0x08
#define DB_EEPROM_SERIAL0x09
#define DB_EEPROM_SERIAL_LEN0x09 //9 ASCII characters
#define DB_EEPROM_CHKSUM0x1f

#define DB_EEPROM_CLEN  0x20 // length of common portion of eeprom

#define DB_EEPROM_CUSTOM_BASE   DB_EEPROM_CLEN // first avail offset for
//   daughterboard specific
use


The storage of calibration data for DC offset is stored in 0x05 - 0x08.

But what about the IQ offsets?
There is a gap between reserved addresses 0x09 and 0x1f.
Is the use of this area documented?

There is a utility to calibrate the board and it generates a text file.
Presumably, the authors also implemented a method to make use of this data?

Continuing, the ettus boards driver code sets the gain, though I do not see
any request for the offset data stored in EEPROM inside the constructor or
elsewhere.

This is a similar issue with IQ balance, ie. formalized structure for both
storing calibration data in EEPROM and then accessing it and using it during
runtime.




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/UHD-Daughter-Board-EEPROM-Format-calibration-data-tp44187.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Logo

2013-10-16 Thread Josh Blum 


On 10/13/2013 09:01 AM, Marcus Müller wrote:
> Hello folks,
> 
> I remembered there was a discussion on the IRC channel during gr-con '13
> about GR needing usable logos.
> I happened to just had reproduced an original version of the logo for
> sticker printing, and promised to share those files.
> 
> Well, here they are: https://github.com/marcusmueller/GrLogo.git
> 
> Little problem here: I didn't design the original logo. So I can't
> really claim or assign copyright, define a license etc.; I'm not quite
> sure what to do. Does anyone know how the logo is licensed (if at all)
> and who was the original creator?

http://comments.gmane.org/gmane.comp.gnu.radio.general/15339

-josh

> 
> Anyway: Enjoy!
> 
> Marcus
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Dev Call October 2013

2013-10-16 Thread Martin Braun (CEL) 
On Wed, Oct 09, 2013 at 10:57:39AM +0200, Martin Braun (CEL) wrote:
> As usual, we will be doing a developer's call the third Thursday a
> month, which is October 17, 1700 UTC (19:00 CET, other timezoners please
> convert yourself).

Just a quick reminder--this call is tomorrow, so if you want to join us,
feel free to do so. Make sure you're Google Hangout is working!

Bye,
MB



-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgpmOQeDsDbTO.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Retrieving audio after FFT and IFFT

2013-10-16 Thread Gui Ritter 
Hi everyone.
I'm trying to pass an audio file through FFT and IFFT, and the resulting audio 
is being distorted. I searched about it and I only found this link:
http://lists.gnu.org/archive/html/discuss-gnuradio/2012-10/msg00111.html
I did as suggested and divided the signal by the FFT size after the FFT but it 
didn't fixed the problem, although it did changed it a bit. I tried several 
combinations, such as switching the Forward/Reverse settings, dividing in other 
places and using several power-of-two values.
I have tested the flowgraph part by part, and it works normally as far as the 
conversions to and from complex. I've attached the flowgraph for further 
reference. The part with unpacking is related the rest of the flowgraph, which 
is not relevant here.
Thanks in advance.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Modifing ber_simulator for simple OFDM test

2013-10-16 Thread maiconkist 
Hi list,

I want to realize a simple BER test using OFDM instead the modulations
options in the original bert_simulator.grc. I thought that a simple change
would work. Basically, I remove de mod/demod used in change for OFDM
Mod/Demod.

However, when I run the flowgraph, after I few seconds (3 at max) the
flowgraph hangs.

Does anyone know how to solve it?
The .grc file modified is attached.

ber_simulation.grc
  


Best Regards



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Modifing-ber-simulator-for-simple-OFDM-test-tp44196.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Retrieving audio after FFT and IFFT

2013-10-16 Thread Gui Ritter 
Sorry, forgot the attachment.   
  

fft test.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Repeatability of delivery ratios using benchmark_tx/rx

2013-10-16 Thread Aditya Dhananjay 
Hi All,

I have two USRP N210 devices connected by an attenuator cable. I set up the
following experiments.

-- BEGIN EXPERIMENT 1

Step 1) Use benchmark_tx on one of the USRPs and send 100 packets. At the
receiver, I simply record the incoming samples and save them into a file
called samples1.dat. This file is static and does not change from now on.

Step 2) Run benchmark_rx with the --from-file=samples1.dat option. The
other parameters (modulation, fft-length, occupied-tones, etc) are
identical to those I used at the transmitter in Step 1. Measure the packet
delivery rate.

Step 3) Repeat Step 2 a bunch of times. Sometimes, I notice differences in
the packet delivery ratios, even though all runs of the experiment use the
identical 'samples1.dat' file and an identical set of parameters These
differences are small (1-2 packet difference), but I don't understand why
they exist.

Is this normal behavior? If so, could someone please let me know what the
probable causes are?

-- END EXPERIMENT 1

The next experiment does not use either of the USRP devices.

-- BEGIN EXPERIMENT 2

1) Use benchmark_tx to generate 100 packets, and write the samples into a
file (samples2.dat) using the --to-file option.

2) Use benchmark_rx with the --from-file=samples2.dat option and check the
packet delivery rate. The parameters used (fft-length, etc) are obviously
identical to those used to generate the samples in Step 1. I observe that
the delivery rate is never even close to 100%.

3) Change to a different parameter set and repeat steps 1 and 2. Across
different runs, I observe that the delivery rate is anywhere between 30%
and 85%.

This cannot be the expected behavior. Any pointers on what I'm doing wrong
would be much appreciated!

-- END EXPERIMENT 2

Thanks!

Aditya
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Repeatability of delivery ratios using benchmark_tx/rx

2013-10-16 Thread Aditya Dhananjay 
On Wed, Oct 16, 2013 at 10:22 PM, Aditya Dhananjay wrote:

> Hi All,
>
> I have two USRP N210 devices connected by an attenuator cable. I set up
> the following experiments.
>
> -- BEGIN EXPERIMENT 1
>
> Step 1) Use benchmark_tx on one of the USRPs and send 100 packets. At the
> receiver, I simply record the incoming samples and save them into a file
> called samples1.dat. This file is static and does not change from now on.
>
> Step 2) Run benchmark_rx with the --from-file=samples1.dat option. The
> other parameters (modulation, fft-length, occupied-tones, etc) are
> identical to those I used at the transmitter in Step 1. Measure the packet
> delivery rate.
>
> Step 3) Repeat Step 2 a bunch of times. Sometimes, I notice differences in
> the packet delivery ratios, even though all runs of the experiment use the
> identical 'samples1.dat' file and an identical set of parameters These
> differences are small (1-2 packet difference), but I don't understand why
> they exist.
>
> Is this normal behavior? If so, could someone please let me know what the
> probable causes are?
>
> -- END EXPERIMENT 1
>
> The next experiment does not use either of the USRP devices.
>
> -- BEGIN EXPERIMENT 2
>
> 1) Use benchmark_tx to generate 100 packets, and write the samples into a
> file (samples2.dat) using the --to-file option.
>
> 2) Use benchmark_rx with the --from-file=samples2.dat option and check the
> packet delivery rate. The parameters used (fft-length, etc) are obviously
> identical to those used to generate the samples in Step 1. I observe that
> the delivery rate is never even close to 100%.
>
> 3) Change to a different parameter set and repeat steps 1 and 2. Across
> different runs, I observe that the delivery rate is anywhere between 30%
> and 85%.
>
> This cannot be the expected behavior. Any pointers on what I'm
> doing wrong would be much appreciated!
>
> -- END EXPERIMENT 2
>
> Thanks!
>
> Aditya
>


I should have made a brief mention of my environment:

GNU Radio 3.7.1 installed from source
Ubuntu 12.04 LTS (64-bit)
Thanks!

Aditya
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio