Re: [Discuss-gnuradio] query regarding wav file recording through wav file sink block
Hello, I am using USRP-B200 mini, and as I want to use USRP offline, that's why I am trying to record the transmitted modulated signal through UHD USRP source to some file, Is it ok to use .txt file for this? And the problem arise in this is , when the signal is being recorded in a wav file through wav file sink, then the recorded wav file's amplitude is lower than the the signal I have seen during simulation in time sink and FFt sink. With Best Regards, Maitry Raval, - Original Message - From: "Marcus Müller, CEL" To: "maitry raval" Cc: "discuss-gnuradio" Sent: Friday, 7 June, 2019 06:42:44 Subject: Re: query regarding wav file recording through wav file sink block 256 kHz is not a sampling rate supported by many devices. What USRP are you using? Also, the filename doesn't matter to its content at all, so this is fine, but using .txt for a file that contains raw binary samples is questionable. So, back to your original problem: can you describe how the result of the operation is different from what you're expecting? I still must admit I don't get where the problem lies. Best regards, Marcus On Fri, 2019-06-07 at 10:04 +0530, Maitry Raval wrote: > Hello, > > PLease find attached flowgraph for other end of txt file writing, as > I have received the transmitted signal through UHD USRP source block > and record it in a text file at 256k sample rate and then this > recorded text file is being used in next flow graph for converting it > into wav file. > > that means I have received the modulated transmitted signal, record > it in txt file and remove noise as well resample it to 48k in order > to save that downcoverted signal to wav file sink. > > With Best Regards, > Maitry Raval, > > - Original Message - > From: "Marcus Müller, CEL" > To: "maitry raval" > Cc: "discuss-gnuradio" > Sent: Wednesday, 5 June, 2019 07:09:42 > Subject: Re: query regarding wav file recording through wav file sink > block > > we really need both your Wav writing (we've got that) and Wav reading > flow graph to make any qualified statement. > > Again, the file name in your file source is suspicious. > > Best regards, > Marcus > > On Wed, 2019-06-05 at 10:54 +0530, Maitry Raval wrote: > > Hello, > > > > Please check the flowgraph, as there is a wav file sink at output > > side, that record the incoming signal, but when I use that same > > recorded wav file in wav file source and check the output in time > > sink and FFT sink, then amplitude changes. > > > > With Best Regards, > > Maitry Raval, > > > > > > - Original Message - > > From: "Marcus Müller, CEL" > > To: "maitry raval" > > Cc: "discuss-gnuradio" > > Sent: Tuesday, 4 June, 2019 13:01:55 > > Subject: Re: query regarding wav file recording through wav file > > sink > > block > > > > Ok, there's no Wave file involved here; instead, you read a file as > > complex 2×3bit floating point binary that has a .txt ending. Have > > you > > read [1]? > > Then, you're doing *way* more than just multiplying with a > > constant, > > so > > really, I'm not sure this flow graph has *anything* to do with your > > question. > > > > [1] > > https://wiki.gnuradio.org/index.php/FAQ#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F > > > > On Tue, 2019-06-04 at 15:17 +0530, Maitry Raval wrote: > > > Hello, > > > > > > Please check the flow graph. > > > > > > > > > With Best Regards, > > > Maitry Raval, > > > > > > > > > - Original Message - > > > From: "Marcus Müller, CEL" > > > To: "maitry raval" > > > Cc: "discuss-gnuradio" > > > Sent: Tuesday, 4 June, 2019 08:56:22 > > > Subject: Re: query regarding wav file recording through wav file > > > sink block > > > > > > Frankly, multiplication with a constant doesn't offer any > > > benefit. > > > The > > > numbers stay the same, just scaled. > > > > > > However, 8 bit might be the giveaway here: are you maybe trying > > > to > > > multiply 8 bit numbers with a constant that leads to values > > > larger > > > than > > > what can be represented in 8 bits? > > > > > > A screenshot of your flowgraph rather than just its result would > > > be > > > most interesting here. > > > On Tue, 2019-06-04 at 13:58 +0530, Maitry Raval wrote: > > > > Hello, > > > > > > > > Thanks for your response. > > > > > > > > My requirement is to use GNU generated wav file into MATLAB. > > > > But > > > > when I record the wav file with 48k sample rate and 8 bits per > > > > sample, my recorded wavfile shows a very low amplitude signal, > > > > the screenshot is attached, please check. > > > > > > > > > > > > With Best Regards, > > > > Maitry Raval, > > > > > > > > > > > > - Original Message - > > > > From: "Marcus Müller, CEL" > > > > To: "maitry raval" > > > > Cc: "discuss-gnuradio" > > > > Sent: Tuesday, 4 June, 2019 08:02:48 > > > > Subject: Re: query regarding wav file recording through wav > > > > file > > > > sink block > > > > > > > >
Re: [Discuss-gnuradio] Request for comment: FFT optimizations
Hi Johannes,
always remember that the "f" suffix after fftw is just for "float",
without that suffix you use the double precision FFTw.
> fftwf_execute_dft(plan, *in, *out)
http://www.fftw.org/fftw3_doc/New_002darray-Execute-Functions.html
> fftwf_alignment_of()
same page, and
http://www.fftw.org/fftw3_doc/Planner-Flags.html#index-fftw_005falignment_005fof
under "FFTW_UNALIGNED".
also, and this might be a bit of a downer: use the source, Luke!
(also, this might even be more of a downer:)
fftw3/kernel/align.c, reduced by all false #if:
#define ALGN 16
int X(ialignment_of)(R *p)
{
return (int)(((uintptr_t) p) % ALGN);
}
or in other words:
address % 16
However, we should really be using the fftw function for that, in case
they get around to writing say AVX7 FFT kernels, which need 2048-byte
aligned memory instructions or so¹.
Best regards,
Marcus
¹if you're from the year 2028, and are reading up on intels new AVX7
instruction on the GNU Radio mailing list archive: this is a joke.
Obviously, AVX7 only needs 1024-byte alignment and that you only use
right-hand quantum registers.
On Fri, 2019-06-07 at 07:51 +, Johannes Demel wrote:
> Hi Marcus,
>
> do you have any online resources that point to the official
> documentation of `fftwf_execute_dft(plan, *in, *out)` and
> `fftwf_alignment_of()`? (for the latter this mail thread is on the
> first
> page of my Google results.)
> All the documentation I could find is [0] and this seems like some
> Intel
> wrapper that is not part of FFTW?!
>
> Cheers
> Johannes
>
> [0]
> http://sep.stanford.edu/sep/claudio/Research/Prst_ExpRefl/ShtPSPI/intel/mkl/10.0.3.020/interfaces/fftw3xf/wrappers/fftwf_execute_dft.c
>
> Am 06.06.19 um 14:57 schrieb Müller, Marcus (CEL):
> > Hi Albin,
> >
> > no, it's not been discussed on the list, as far as my memory
> > reaches.
> > We're talking about gr:fft:fft_vcc, right?
> >
> > Because that output memory shifting only happens when you set shift
> > = 1
> > in the constructor. I don't have any hard feelings about whether to
> > shift the output or perform an exp(j π n) frequency shift (a.k.a.
> > multiplying with +1 -1 …). My gut feeling is that copying blocks of
> > memory is probably significantly faster than accessing all elements
> > of
> > said blocks through the CPU sequentially. Memcpy implementations
> > are
> > heavily hand-assembler optimized!
> >
> > However, the actual FFT would access these elements most
> > definitely,
> > so, for amounts of input samples smaller than the available CPU
> > cache,
> > the +1 -1 variant would act like an elegant prefetcher and probably
> > be
> > a bit more efficient, but for sizes larger, it would probably even
> > thrash the caches a bit and mean one additional loop over all data.
> > So, honestly, in many cases I'd expect a small improvement, in some
> > a
> > performance degradation. Not quite sure whether looking into that
> > is
> > clever.
> >
> > I'd however say that it should be obvious to do the +1 -1 input
> > multiplication instead of the memcpy output shift if a window is
> > applied, because the +1 -1 can be absorbed into the window in that
> > case. (Watch out for the odd-length corner case where you get two
> > different windows depending on whether you do an odd- or an even-
> > numbered transform.)
> >
> > There's another easy way we can optimize things at nearly zero
> > cost:
> >
> > The memcpy to the FFTW input buffer only happens so that data is
> > properly aligned for FFTW to be able to use SIMD. Obviously, that
> > copy
> > could be avoided alltogether if the input *is* already aligned.
> >
> > FFTW does have a fftwf_alignment_of() that you can use to compare
> > the
> > alignment of the especially aligned fftw plan input buffer, and the
> > current workload input pointer.
> > Same applies to the output buffer of the fftw plan and the output
> > pointer.
> >
> > If the input buffer and the work input pointer, and the output
> > buffer
> > and the work output pointer, are of the same aligment, one could
> > simply
> > use fftwf_execute_dft(plan, *in, *out) instead of
> > fftwf_execute(plan),
> > and not memcpy anything (unless the user requests shifting).
> >
> > Chances are that, considering our circular buffers are page-
> > aligned,
> > and that fft_length mod 4 = 0, for most applications,
> >
> > fft_length * sizeof(gr_complex_float) = (fft_length/4) * 4 * 64
> >
> > are typically already 256-byte aligned, and things are "inherently
> > good".
> >
> >
> > Cheers,
> > Marcus
> >
> > On Thu, 2019-06-06 at 11:13 +0200, Albin Stigö wrote:
> > > Hi,
> > >
> > > There's a lot of memcpy/memmove going on in the FFT kernel which
> > > I
> > > suspect degrades performance quite a bit... This is partly
> > > because
> > > some platforms requires buffers to be aligned for SIMD to work
> > > and
> > > partly because DC is not normally centered (which is normally
> > > what you
> > > would like to see in a spektrum).
> > >
> > > For
Re: [Discuss-gnuradio] query regarding wav file recording through wav file sink block
Hello, On Fri, 2019-06-07 at 12:40 +0530, Maitry Raval wrote: > Hello, > > I am using USRP-B200 mini, and as I want to use USRP offline, that's > why I am trying to record the transmitted modulated signal through > UHD USRP source to some file, Is it ok to use .txt file for this? Again, the filename says *nothing* about a file's contents. So it's OK, it's just utterly misleading, because there's absolutely no text inside. > And the problem arise in this is , when the signal is being recorded > in a wav file through wav file sink, then the recorded wav file's > amplitude is lower than the the signal I have seen during simulation > in time sink and FFt sink. > Wait, the amplitude of the wav file saved with the wav file sink is different when you open it with a wav file source? Or how do you open it? Reminder, again: Files are *interpreted* by the reading software. GNU Radio maps -1 to +1 to the full scale of the wav file's sample format. Other software might do something else. Best regards, Marcus > With Best Regards, > Maitry Raval, > > > - Original Message - > From: "Marcus Müller, CEL" > To: "maitry raval" > Cc: "discuss-gnuradio" > Sent: Friday, 7 June, 2019 06:42:44 > Subject: Re: query regarding wav file recording through wav file sink > block > > 256 kHz is not a sampling rate supported by many devices. What USRP > are > you using? > > Also, the filename doesn't matter to its content at all, so this is > fine, but using .txt for a file that contains raw binary samples is > questionable. > > So, back to your original problem: can you describe how the result of > the operation is different from what you're expecting? I still must > admit I don't get where the problem lies. > > Best regards, > Marcus > > On Fri, 2019-06-07 at 10:04 +0530, Maitry Raval wrote: > > Hello, > > > > PLease find attached flowgraph for other end of txt file writing, > > as > > I have received the transmitted signal through UHD USRP source > > block > > and record it in a text file at 256k sample rate and then this > > recorded text file is being used in next flow graph for converting > > it > > into wav file. > > > > that means I have received the modulated transmitted signal, record > > it in txt file and remove noise as well resample it to 48k in order > > to save that downcoverted signal to wav file sink. > > > > With Best Regards, > > Maitry Raval, > > > > - Original Message - > > From: "Marcus Müller, CEL" > > To: "maitry raval" > > Cc: "discuss-gnuradio" > > Sent: Wednesday, 5 June, 2019 07:09:42 > > Subject: Re: query regarding wav file recording through wav file > > sink > > block > > > > we really need both your Wav writing (we've got that) and Wav > > reading > > flow graph to make any qualified statement. > > > > Again, the file name in your file source is suspicious. > > > > Best regards, > > Marcus > > > > On Wed, 2019-06-05 at 10:54 +0530, Maitry Raval wrote: > > > Hello, > > > > > > Please check the flowgraph, as there is a wav file sink at output > > > side, that record the incoming signal, but when I use that same > > > recorded wav file in wav file source and check the output in time > > > sink and FFT sink, then amplitude changes. > > > > > > With Best Regards, > > > Maitry Raval, > > > > > > > > > - Original Message - > > > From: "Marcus Müller, CEL" > > > To: "maitry raval" > > > Cc: "discuss-gnuradio" > > > Sent: Tuesday, 4 June, 2019 13:01:55 > > > Subject: Re: query regarding wav file recording through wav file > > > sink > > > block > > > > > > Ok, there's no Wave file involved here; instead, you read a file > > > as > > > complex 2×3bit floating point binary that has a .txt ending. Have > > > you > > > read [1]? > > > Then, you're doing *way* more than just multiplying with a > > > constant, > > > so > > > really, I'm not sure this flow graph has *anything* to do with > > > your > > > question. > > > > > > [1] > > > https://wiki.gnuradio.org/index.php/FAQ#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F > > > > > > On Tue, 2019-06-04 at 15:17 +0530, Maitry Raval wrote: > > > > Hello, > > > > > > > > Please check the flow graph. > > > > > > > > > > > > With Best Regards, > > > > Maitry Raval, > > > > > > > > > > > > - Original Message - > > > > From: "Marcus Müller, CEL" > > > > To: "maitry raval" > > > > Cc: "discuss-gnuradio" > > > > Sent: Tuesday, 4 June, 2019 08:56:22 > > > > Subject: Re: query regarding wav file recording through wav > > > > file > > > > sink block > > > > > > > > Frankly, multiplication with a constant doesn't offer any > > > > benefit. > > > > The > > > > numbers stay the same, just scaled. > > > > > > > > However, 8 bit might be the giveaway here: are you maybe trying > > > > to > > > > multiply 8 bit numbers with a constant that leads to values > > > > larger > > > > than > > > > what can be represented in 8 bits? > > > > > > > > A screenshot of your flo
Re: [Discuss-gnuradio] query regarding wav file recording through wav file sink block
Yes, the amplitude of a wav file saved with a wav file sink is differnt while I open it with wav file source - Original Message - From: "Marcus Müller, CEL" To: "maitry raval" Cc: "discuss-gnuradio" Sent: Friday, 7 June, 2019 08:15:30 Subject: Re: query regarding wav file recording through wav file sink block Hello, On Fri, 2019-06-07 at 12:40 +0530, Maitry Raval wrote: > Hello, > > I am using USRP-B200 mini, and as I want to use USRP offline, that's > why I am trying to record the transmitted modulated signal through > UHD USRP source to some file, Is it ok to use .txt file for this? Again, the filename says *nothing* about a file's contents. So it's OK, it's just utterly misleading, because there's absolutely no text inside. > And the problem arise in this is , when the signal is being recorded > in a wav file through wav file sink, then the recorded wav file's > amplitude is lower than the the signal I have seen during simulation > in time sink and FFt sink. > Wait, the amplitude of the wav file saved with the wav file sink is different when you open it with a wav file source? Or how do you open it? Reminder, again: Files are *interpreted* by the reading software. GNU Radio maps -1 to +1 to the full scale of the wav file's sample format. Other software might do something else. Best regards, Marcus > With Best Regards, > Maitry Raval, > > > - Original Message - > From: "Marcus Müller, CEL" > To: "maitry raval" > Cc: "discuss-gnuradio" > Sent: Friday, 7 June, 2019 06:42:44 > Subject: Re: query regarding wav file recording through wav file sink > block > > 256 kHz is not a sampling rate supported by many devices. What USRP > are > you using? > > Also, the filename doesn't matter to its content at all, so this is > fine, but using .txt for a file that contains raw binary samples is > questionable. > > So, back to your original problem: can you describe how the result of > the operation is different from what you're expecting? I still must > admit I don't get where the problem lies. > > Best regards, > Marcus > > On Fri, 2019-06-07 at 10:04 +0530, Maitry Raval wrote: > > Hello, > > > > PLease find attached flowgraph for other end of txt file writing, > > as > > I have received the transmitted signal through UHD USRP source > > block > > and record it in a text file at 256k sample rate and then this > > recorded text file is being used in next flow graph for converting > > it > > into wav file. > > > > that means I have received the modulated transmitted signal, record > > it in txt file and remove noise as well resample it to 48k in order > > to save that downcoverted signal to wav file sink. > > > > With Best Regards, > > Maitry Raval, > > > > - Original Message - > > From: "Marcus Müller, CEL" > > To: "maitry raval" > > Cc: "discuss-gnuradio" > > Sent: Wednesday, 5 June, 2019 07:09:42 > > Subject: Re: query regarding wav file recording through wav file > > sink > > block > > > > we really need both your Wav writing (we've got that) and Wav > > reading > > flow graph to make any qualified statement. > > > > Again, the file name in your file source is suspicious. > > > > Best regards, > > Marcus > > > > On Wed, 2019-06-05 at 10:54 +0530, Maitry Raval wrote: > > > Hello, > > > > > > Please check the flowgraph, as there is a wav file sink at output > > > side, that record the incoming signal, but when I use that same > > > recorded wav file in wav file source and check the output in time > > > sink and FFT sink, then amplitude changes. > > > > > > With Best Regards, > > > Maitry Raval, > > > > > > > > > - Original Message - > > > From: "Marcus Müller, CEL" > > > To: "maitry raval" > > > Cc: "discuss-gnuradio" > > > Sent: Tuesday, 4 June, 2019 13:01:55 > > > Subject: Re: query regarding wav file recording through wav file > > > sink > > > block > > > > > > Ok, there's no Wave file involved here; instead, you read a file > > > as > > > complex 2×3bit floating point binary that has a .txt ending. Have > > > you > > > read [1]? > > > Then, you're doing *way* more than just multiplying with a > > > constant, > > > so > > > really, I'm not sure this flow graph has *anything* to do with > > > your > > > question. > > > > > > [1] > > > https://wiki.gnuradio.org/index.php/FAQ#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F > > > > > > On Tue, 2019-06-04 at 15:17 +0530, Maitry Raval wrote: > > > > Hello, > > > > > > > > Please check the flow graph. > > > > > > > > > > > > With Best Regards, > > > > Maitry Raval, > > > > > > > > > > > > - Original Message - > > > > From: "Marcus Müller, CEL" > > > > To: "maitry raval" > > > > Cc: "discuss-gnuradio" > > > > Sent: Tuesday, 4 June, 2019 08:56:22 > > > > Subject: Re: query regarding wav file recording through wav > > > > file > > > > sink block > > > > > > > > Frankly, multiplication with a constant doesn't offer any > > > > benefit. >
[Discuss-gnuradio] ARM optimization update
Hi, ARM support is now pretty much done for libvolk. I'm just waiting to sign the Contributor licence agreement before I start sending pull requests. There has been some (legimite) concern that my branch is a total mess, but don't worry, I will refactor so there will be one pull request / kernel, probably starting with the most commonly used... https://github.com/gnuradio/volk/issues/243 --Albin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Determining distance from OFDM signals
Hi Andrew, What do you mean by “information from the carrier data”? I’m no OFDM expert, but my intuition tells me that in a zero-IF architecture (which I assume your USRP has) any carrier phase information is lost. There’s some results when googling for “OFDM ranging” maybe that helps. Cheers, Jonas From: Discuss-gnuradio [mailto:discuss-gnuradio-bounces+jonas.manthey=u-blox@gnu.org] On Behalf Of Andrew Wolfram Sent: Donnerstag, 6. Juni 2019 01:20 To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Determining distance from OFDM signals Hi, I'm trying to alter the file ofdm_txrx.py (https://github.com/gnuradio/gnuradio/blob/master/gr-digital/python/digital/ofdm_txrx.py) to get phase information from the carrier data so I can calculate an approximate distance between two USRP devices. Ideally I want to grab data from one of the blocks in the rx pipeline in the above python file after the frequency/timing corrections have been applied. I tried using the data after the serializer block, but it appears that this has no phase information. I tried with the equalizer block output but I'm not sure how to interpret its output data. For my particular payload with 300 occupied carriers and an fft size of 512 only the first 214 items of the equalizer output vector have any phase information, so I'm somewhat confused. Any ideas? Thanks, Andrew ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Determining distance from OFDM signals
Well, you can go ahead and at least to a degree enforce a known relative phase between transmitter and receiver, but yeah, without extensive external synchronization effort (e.g. GPSDOs – hi there, u- blox :) ), the receiver phase is random relative to the transmitter's phase. So, the distance can't be recovered from a one-way transmission. Best regards, Marcus On Fri, 2019-06-07 at 10:21 +, Jonas Manthey wrote: > Hi Andrew, > > What do you mean by “information from the carrier data”? I’m no OFDM expert, > but my intuition tells me that in a zero-IF architecture (which I assume your > USRP has) any carrier phase information is lost. There’s some results when > googling for “OFDM ranging” maybe that helps. > > Cheers, > Jonas > > From: Discuss-gnuradio > [mailto:discuss-gnuradio-bounces+jonas.manthey=u-blox@gnu.org] On Behalf > Of Andrew Wolfram > Sent: Donnerstag, 6. Juni 2019 01:20 > To: discuss-gnuradio@gnu.org > Subject: [Discuss-gnuradio] Determining distance from OFDM signals > > Hi, > > I'm trying to alter the file ofdm_txrx.py > (https://github.com/gnuradio/gnuradio/blob/master/gr-digital/python/digital/ofdm_txrx.py) > to get phase information from the carrier data so I can calculate an > approximate distance between two USRP devices. Ideally I want to grab data > from one of the blocks in the rx pipeline in the above python file after the > frequency/timing corrections have been applied. I tried using the data after > the serializer block, but it appears that this has no phase information. I > tried with the equalizer block output but I'm not sure how to interpret its > output data. For my particular payload with 300 occupied carriers and an fft > size of 512 only the first 214 items of the equalizer output vector have any > phase information, so I'm somewhat confused. Any ideas? > > Thanks, > Andrew > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Determining distance from OFDM signals
Thanks for your responses! I'm trying to implement what's already been done with USRPs in this paper (https://ieeexplore.ieee.org/document/8555795), which is based on this paper (https://ieeexplore.ieee.org/document/5505942). My apologies if you can't access the full versions of these. In the first paper with the USRP's they're using an external clock to perfectly frequency sync the two devices, but otherwise they are taking relative distance measurements. That is, after frequency and time synchronization, they are accounting for the different delays in each device by only measuring changes in distance rather than absolute distance. Assuming I had the same setup as in the paper, does my original question make more sense? On Fri, Jun 7, 2019 at 5:20 AM Müller, Marcus (CEL) wrote: > Well, you can go ahead and at least to a degree enforce a known > relative phase between transmitter and receiver, but yeah, without > extensive external synchronization effort (e.g. GPSDOs – hi there, u- > blox :) ), the receiver phase is random relative to the transmitter's > phase. So, the distance can't be recovered from a one-way transmission. > > Best regards, > Marcus > > On Fri, 2019-06-07 at 10:21 +, Jonas Manthey wrote: > > Hi Andrew, > > > > What do you mean by “information from the carrier data”? I’m no OFDM > expert, but my intuition tells me that in a zero-IF architecture (which I > assume your USRP has) any carrier phase information is lost. There’s some > results when googling for “OFDM ranging” maybe that helps. > > > > Cheers, > > Jonas > > > > From: Discuss-gnuradio [mailto:discuss-gnuradio-bounces+jonas.manthey= > u-blox@gnu.org] On Behalf Of Andrew Wolfram > > Sent: Donnerstag, 6. Juni 2019 01:20 > > To: discuss-gnuradio@gnu.org > > Subject: [Discuss-gnuradio] Determining distance from OFDM signals > > > > Hi, > > > > I'm trying to alter the file ofdm_txrx.py ( > https://github.com/gnuradio/gnuradio/blob/master/gr-digital/python/digital/ofdm_txrx.py) > to get phase information from the carrier data so I can calculate an > approximate distance between two USRP devices. Ideally I want to grab data > from one of the blocks in the rx pipeline in the above python file after > the frequency/timing corrections have been applied. I tried using the data > after the serializer block, but it appears that this has no phase > information. I tried with the equalizer block output but I'm not sure how > to interpret its output data. For my particular payload with 300 occupied > carriers and an fft size of 512 only the first 214 items of the equalizer > output vector have any phase information, so I'm somewhat confused. Any > ideas? > > > > Thanks, > > Andrew > > ___ > > 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] USRP dsp_freq request using stream tags [Python]
Hi,
I am unsure whether this question fits in this mailing list or the USRP
mailing list but it concerns stream tags so here goes..
I'd like to tune the USRP using a DSP offset without touching the LO
frequency. I'd like to do this using stream tags since it's important that
the re-tune is synchronous with the sample stream. Judging by [1] this
appears to be possible using the following structure:
tag.key = pmt.intern('tx_command')
command = pmt.make_dict()
command = pmt.dict_add(command, pmt.intern('dsp_freq'),
pmt.from_double(the_offset))
tag.value = command
// add tag to stream etc
It turns out that this does nothing unless the LO freq is also supplied:
command = pmt.dict_add(command, pmt.intern('lo_freq'),
pmt.from_double(some_center_freq))
But this causes the (relatively slow) LO to be retuned rendering the speedy
DSP retune worthless.. I've seen hints about setting the tune request
policy but this appears to not be supported by the USRP sink as a tag.. is
it necessary to create a custom USRP sink block to properly use DSP
retuning?
[1] https://www.gnuradio.org/doc/doxygen/page_uhd.html
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Determining distance from OFDM signals
On Wed, 05 Jun 2019 at 16:20:12 -0700, Andrew Wolfram wrote:
> I'm trying to alter the file ofdm_txrx.py (
> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/python/digital/ofdm_txrx.py)
> to get phase information from the carrier data so I can calculate an
> approximate distance between two USRP devices. Ideally I want to grab
> data from one of the blocks in the rx pipeline in the above python
> file after the frequency/timing corrections have been applied. I tried
> using the data after the serializer block, but it appears that this
> has no phase information. I tried with the equalizer block output but
> I'm not sure how to interpret its output data.
You cannot use the output of the equalizer block to get information on
channel phase (or amplitude). That’s the point of equalization. A
received subcarrier in a OFDM system is given by Y = H·X + N where H is
the channel transfer function at the subcarrier, X is the sent symbol
and N is noise (in frequency domain, i.e. after the FFT; note some
assumption regarding synchronisation must hold, see [1]). The equalizer
returns hat{X} = Y/hat{Y} where hat{·} denotes estimation. Note that
the serializer block is a downstream block of the equalizer in the file
you mention.
> For my particular payload with 300 occupied carriers and an fft size
> of 512 only the first 214 items of the equalizer output vector have
> any phase information, so I'm somewhat confused. Any ideas?
This might be related to the number of used pilots and their position.
Do you use 86 pilots? How do you define their position? It’s rather odd
that the position of carriers without phase information is not
scattered.
[1] https://ieeexplore.ieee.org/document/803501
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
