Re: [Discuss-gnuradio] OFDM_TX_RX

[farid mihoub]

Indeed25.05.2019, 22:07, "Marcus Müller" :After reading the original paper, you've meant "2D- or 3D-DCT" :)On Sat, 2019-05-25 at 21:20 +0100, farid mihoub wrote: Hi, Discrete cosine transform 25.05.2019, 21:02, "Marcus Müller" : > hi, what's 2DCT_or_3DCT? >  > Best regards, > Marcus >  > On Sat, 2019-05-25 at 19:38 +0100, farid mihoub wrote: > >  My application is to broadcast a video using softcast approach.  > >  Video-->2DCT_or_3DCT-->Floating coefficients-->complex_mapping > >  -->ofdm_phy > >  My video quality (PSNR) will depend linearly to my SNR so no > > need to > >  have an adaptive modulation. > >  > >  > >  25.05.2019, 18:27, "Marcus Müller" : > >  > 1- So, you have an SNR of best-case 16 dB; that's not high for > > an > >  > OFDM > >  > system. > >  >  > >  > 2- No, there's no power normalization. Hint: you can look all > > this > >  > up > >  > by actually looking inside these blocks! This would make a lot > > of > >  > sense, since it sounds you don't actually want to use tzhe > > OFDM > >  > blocks > >  > at all. The whole advantage of the OFDM blocks compared to > > just > >  > doing > >  > an IFFT of your transmit vector is that you get a header and > >  > modulation > >  > scheme. > >  >  > >  > 3- Not quite sure what "information is linearly related to > > complex > >  > symbols" means? Can you elaborate? > >  > 3b- A case where you *don't* do FEC is either a non- > > communications > >  > system (i.e. you don't actually want to do OFDM for the reason > > of > >  > transmitting information) or the extremely-bad-SNR case (where > > FEC > >  > makes your BER better). For both cases, the existing OFDM > > blocks > >  > are > >  > more of an obstacle than a solution. > >  >  > >  > What are you building? What is your overall application. > > Please > >  > paint > >  > the bigger picture – it's a bit frustrating to try to help > > you, but > >  > then only get told that "this is not how I want to do it". > >  >  > >  > Best regards, > >  > Marcus > >  >  > >  > On Sat, 2019-05-25 at 18:39 +0200, Marcus Müller wrote: > >  > > Dear Farid, > >  > >  > >  > > please always respond on the mailing list. > >  > > Thank you, > >  > > Marcus Müller > >  > >  > >  > > On Sat, 2019-05-25 at 17:36 +0100, farid mihoub wrote: > >  > > > 1- For the noise : in the TX side the output is in the > > order > >  > > of 2A, > >  > > > the noise 0.05A. > >  > > > 2-Second even without noise, the const does not affect the > >  > > > transmission, is there any sort of power normalization? > >  > > > 3-For the FEC and the modulation I want to try my custom > >  > > mapping > >  > > > where information is linearly related to complex symbols, > > and > >  > > my > >  > > > application doesn't require error correction.  > >  > > >  > >  > > > Thank you. > >  > > >  > >  > > >  > >  > > > 25.05.2019, 17:06, "Marcus Müller"  > > : > >  > > > > Hello Farid, > >  > > > > On Sat, 2019-05-25 at 15:59 +0100, farid mihoub wrote: > >  > > > > > Hello, > >  > > > > >  > >  > > > > > In the OFDM_tx, rx examples in gr-digital : > >  > > > > > 1- Why just a low level of noise affect the > > transmission > >  > > and > >  > > > > > cause it > >  > > > > > to stop. > >  > > > >  > >  > > > > "low" is relative. It seems it's high enough to cause > > packet > >  > > > > losses, > >  > > > > iff it's actually the noise. > >  > > > >  > >  > > > > > 2- in the the Tx output and the Rx input no matter the > >  > > value > >  > > > > > of > >  > > > > > the > >  > > > > > multiply constant we apply > >  > > > > > that would not affect our transmission. > >  > > > >  > >  > > > > Then it's probably not only the noise! > >  > > > >  > >  > > > > > 3- Is there any way to separate channel estimation and > >  > > > > > tracking > >  > > > > > from > >  > > > > > data transmission, sometime I get the error "invalid > >  > > packet > >  > > > > > detected!" form the packet parser, also I need my data > > to > >  > > > > > bypass > >  > > > > > FEC > >  > > > > > and QAM. > >  > > > >  > >  > > > > Um, prior to QAM demodulation there is no data, and > > prior to > >  > > FEC > >  > > > > decoding there is no information bits, so I'm not sure > > what > >  > > you > >  > > > > want? > >  > > > >  > >  > > > > > My purpose is to stream raw complex data to the I/Q > >  > > > > > components > >  > > > > > directly. > >  > > > >  > >  > > > > Then it seems you don't want an OFDM transceiver but > > maybe > >  > > just > >  > > > > simply > >  > > > > a single IFFT? Not quite sure what you have in mind. > >  > > > >  > >  > > > > Best regards, > >  > > > > Marcus > >  > > > >  > >  > >  > >  > > ___ > >  > > Discuss-gnuradio mailing list > >  > > Discuss-gnuradio@gnu.org > >  > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >  > >  > >  > >  ___ > >  Discuss-gnuradio mailing list > >  

[Discuss-gnuradio] OFDM / softcast / rate distortion theory (was:Re: OFDM_TX_RX)

[Marcus Müller]

As said, I doubt that omitting channel coding is a good idea, but OK,
you do the math. 

In any case, when you really don't want channel coding and symbol
mapping, and none of the header structure the OFDM blocks offer, you'll
simply be best off writing your own OFDM transmitter – no big deal,
it's but an IFFT and a cyclic prefix block. That shouldn't take you
very long!

Also, the softcast folks used GNU Radio, so they most definitely have
source code to what they've done – and since MIT takes pride in doing
good science, I'm pretty sure that if you ask, you can get all the code
you need to reproduce.


By the way, they write:

> the receiver with low noise can distinguish
> which of the 16 small squares the original sample
> belongs to, and hence can correctly decode the 4 most
> significant bits of the transmitted sample. The receiver
> with higher noise can distinguish only the quadrant of
> the transmitted signal sample, and hence can decode
> only the two most significant bits of the transmitted
> sample. Thus, wireless broadcast naturally delivers to
> each receiver a number of signal bits that match its SNR.

That's a pretty established method. I think DVB-T does that.

Generally, I'm a bit surprised about the whole "try to contain the
numerical properties from the source video through video coding AND
channel coding" approach, from which they say they get better behaviour
under bit flips:

The very idea of video coding (i.e. source coding) is to maximize the
entropy of each bit. So, if you want to have "least significant bits",
as they argue they can get, not all bits are equally random, i.e.
there's bits that carry more, and bits that carry less information. 
The amount in which this non-equal-distribution of information /
probability happens is called redundancy, and simply means that you
spend more energy per video pixel to get the same error probability.
Sounds counter-productive to me!

Now, the argument of softcast seems to be: 

> Haha! The energy we waste in non-optimal source coding is more than
compensated by the r=1 rate channel code of not doing any channel
coding at all!

That seems strange. If I remember correctly, the whole point is that
joint source-channel coding (which softcast is) can be shown to be
rate-achieving for a *lossless* transmission, but separated source and
channel encoders, in which the source encoder actually maximizes
infobit entropy, and the channel coder minimizes bit error rate, are
superior when it comes to achieving a limited, yet non-zero rate
distortion.
If I was to write a publication about all this, I'd be very sure to
find a paper (I'm certain they cite their theoretical foundations
somewhere – the paper [1] as I could find it really just says "here's
how we're doing it, and that's how much better it is") that explains
how they found a sweet spot where an uncoded transmission achieves
higher info rate under the same distortion as the coded transmission in
an explicitly high-SNR scenario.

Best regards,
Marcus

[1]http://people.csail.mit.edu/szym/softcast/tr2.pdf

On Sat, 2019-05-25 at 19:38 +0100, farid mihoub wrote:
> My application is to broadcast a video using softcast approach. 
> Video-->2DCT_or_3DCT-->Floating coefficients-->complex_mapping
> -->ofdm_phy
> My video quality (PSNR) will depend linearly to my SNR so no need to
> have an adaptive modulation.
> 
> 
> 25.05.2019, 18:27, "Marcus Müller" :
> > 1- So, you have an SNR of best-case 16 dB; that's not high for an
> > OFDM
> > system.
> > 
> > 2- No, there's no power normalization. Hint: you can look all this
> > up
> > by actually looking inside these blocks! This would make a lot of
> > sense, since it sounds you don't actually want to use tzhe OFDM
> > blocks
> > at all. The whole advantage of the OFDM blocks compared to just
> > doing
> > an IFFT of your transmit vector is that you get a header and
> > modulation
> > scheme.
> > 
> > 3- Not quite sure what "information is linearly related to complex
> > symbols" means? Can you elaborate?
> > 3b- A case where you *don't* do FEC is either a non-communications
> > system (i.e. you don't actually want to do OFDM for the reason of
> > transmitting information) or the extremely-bad-SNR case (where FEC
> > makes your BER better). For both cases, the existing OFDM blocks
> > are
> > more of an obstacle than a solution.
> > 
> > What are you building? What is your overall application. Please
> > paint
> > the bigger picture – it's a bit frustrating to try to help you, but
> > then only get told that "this is not how I want to do it".
> > 
> > Best regards,
> > Marcus
> > 
> > On Sat, 2019-05-25 at 18:39 +0200, Marcus Müller wrote:
> > >  Dear Farid,
> > > 
> > >  please always respond on the mailing list.
> > >  Thank you,
> > >  Marcus Müller
> > > 
> > >  On Sat, 2019-05-25 at 17:36 +0100, farid mihoub wrote:
> > >  > 1- For the noise : in the TX side the output is in the order
> > > of 2A,
> > >  > the noise 0.05A.
> > >  > 2-Second even without 

Re: [Discuss-gnuradio] OFDM_TX_RX

[Marcus Müller]

After reading the original paper, you've meant "2D- or 3D-DCT" :)
On Sat, 2019-05-25 at 21:20 +0100, farid mihoub wrote:
> Hi,
> Discrete cosine transform
> 
> 
> 25.05.2019, 21:02, "Marcus Müller" :
> > hi, what's 2DCT_or_3DCT?
> > 
> > Best regards,
> > Marcus
> > 
> > On Sat, 2019-05-25 at 19:38 +0100, farid mihoub wrote:
> > >  My application is to broadcast a video using softcast approach. 
> > >  Video-->2DCT_or_3DCT-->Floating coefficients-->complex_mapping
> > >  -->ofdm_phy
> > >  My video quality (PSNR) will depend linearly to my SNR so no
> > > need to
> > >  have an adaptive modulation.
> > > 
> > > 
> > >  25.05.2019, 18:27, "Marcus Müller" :
> > >  > 1- So, you have an SNR of best-case 16 dB; that's not high for
> > > an
> > >  > OFDM
> > >  > system.
> > >  > 
> > >  > 2- No, there's no power normalization. Hint: you can look all
> > > this
> > >  > up
> > >  > by actually looking inside these blocks! This would make a lot
> > > of
> > >  > sense, since it sounds you don't actually want to use tzhe
> > > OFDM
> > >  > blocks
> > >  > at all. The whole advantage of the OFDM blocks compared to
> > > just
> > >  > doing
> > >  > an IFFT of your transmit vector is that you get a header and
> > >  > modulation
> > >  > scheme.
> > >  > 
> > >  > 3- Not quite sure what "information is linearly related to
> > > complex
> > >  > symbols" means? Can you elaborate?
> > >  > 3b- A case where you *don't* do FEC is either a non-
> > > communications
> > >  > system (i.e. you don't actually want to do OFDM for the reason
> > > of
> > >  > transmitting information) or the extremely-bad-SNR case (where
> > > FEC
> > >  > makes your BER better). For both cases, the existing OFDM
> > > blocks
> > >  > are
> > >  > more of an obstacle than a solution.
> > >  > 
> > >  > What are you building? What is your overall application.
> > > Please
> > >  > paint
> > >  > the bigger picture – it's a bit frustrating to try to help
> > > you, but
> > >  > then only get told that "this is not how I want to do it".
> > >  > 
> > >  > Best regards,
> > >  > Marcus
> > >  > 
> > >  > On Sat, 2019-05-25 at 18:39 +0200, Marcus Müller wrote:
> > >  > > Dear Farid,
> > >  > > 
> > >  > > please always respond on the mailing list.
> > >  > > Thank you,
> > >  > > Marcus Müller
> > >  > > 
> > >  > > On Sat, 2019-05-25 at 17:36 +0100, farid mihoub wrote:
> > >  > > > 1- For the noise : in the TX side the output is in the
> > > order
> > >  > > of 2A,
> > >  > > > the noise 0.05A.
> > >  > > > 2-Second even without noise, the const does not affect the
> > >  > > > transmission, is there any sort of power normalization?
> > >  > > > 3-For the FEC and the modulation I want to try my custom
> > >  > > mapping
> > >  > > > where information is linearly related to complex symbols,
> > > and
> > >  > > my
> > >  > > > application doesn't require error correction. 
> > >  > > > 
> > >  > > > Thank you.
> > >  > > > 
> > >  > > > 
> > >  > > > 25.05.2019, 17:06, "Marcus Müller" 
> > > :
> > >  > > > > Hello Farid,
> > >  > > > > On Sat, 2019-05-25 at 15:59 +0100, farid mihoub wrote:
> > >  > > > > > Hello,
> > >  > > > > > 
> > >  > > > > > In the OFDM_tx, rx examples in gr-digital :
> > >  > > > > > 1- Why just a low level of noise affect the
> > > transmission
> > >  > > and
> > >  > > > > > cause it
> > >  > > > > > to stop.
> > >  > > > > 
> > >  > > > > "low" is relative. It seems it's high enough to cause
> > > packet
> > >  > > > > losses,
> > >  > > > > iff it's actually the noise.
> > >  > > > > 
> > >  > > > > > 2- in the the Tx output and the Rx input no matter the
> > >  > > value
> > >  > > > > > of
> > >  > > > > > the
> > >  > > > > > multiply constant we apply
> > >  > > > > > that would not affect our transmission.
> > >  > > > > 
> > >  > > > > Then it's probably not only the noise!
> > >  > > > > 
> > >  > > > > > 3- Is there any way to separate channel estimation and
> > >  > > > > > tracking
> > >  > > > > > from
> > >  > > > > > data transmission, sometime I get the error "invalid
> > >  > > packet
> > >  > > > > > detected!" form the packet parser, also I need my data
> > > to
> > >  > > > > > bypass
> > >  > > > > > FEC
> > >  > > > > > and QAM.
> > >  > > > > 
> > >  > > > > Um, prior to QAM demodulation there is no data, and
> > > prior to
> > >  > > FEC
> > >  > > > > decoding there is no information bits, so I'm not sure
> > > what
> > >  > > you
> > >  > > > > want?
> > >  > > > > 
> > >  > > > > > My purpose is to stream raw complex data to the I/Q
> > >  > > > > > components
> > >  > > > > > directly.
> > >  > > > > 
> > >  > > > > Then it seems you don't want an OFDM transceiver but
> > > maybe
> > >  > > just
> > >  > > > > simply
> > >  > > > > a single IFFT? Not quite sure what you have in mind.
> > >  > > > > 
> > >  > > > > Best regards,
> > >  > > > > Marcus
> > >  > > > > 
> > >  > > 
> > >  > > ___
> > >  > > Discuss-gnuradio mailing list
> > >  > > 

Re: [Discuss-gnuradio] OFDM_TX_RX

[farid mihoub]

Hi,Discrete cosine transform25.05.2019, 21:02, "Marcus Müller" :hi, what's 2DCT_or_3DCT?Best regards,MarcusOn Sat, 2019-05-25 at 19:38 +0100, farid mihoub wrote: My application is to broadcast a video using softcast approach.  Video-->2DCT_or_3DCT-->Floating coefficients-->complex_mapping -->ofdm_phy My video quality (PSNR) will depend linearly to my SNR so no need to have an adaptive modulation. 25.05.2019, 18:27, "Marcus Müller" : > 1- So, you have an SNR of best-case 16 dB; that's not high for an > OFDM > system. >  > 2- No, there's no power normalization. Hint: you can look all this > up > by actually looking inside these blocks! This would make a lot of > sense, since it sounds you don't actually want to use tzhe OFDM > blocks > at all. The whole advantage of the OFDM blocks compared to just > doing > an IFFT of your transmit vector is that you get a header and > modulation > scheme. >  > 3- Not quite sure what "information is linearly related to complex > symbols" means? Can you elaborate? > 3b- A case where you *don't* do FEC is either a non-communications > system (i.e. you don't actually want to do OFDM for the reason of > transmitting information) or the extremely-bad-SNR case (where FEC > makes your BER better). For both cases, the existing OFDM blocks > are > more of an obstacle than a solution. >  > What are you building? What is your overall application. Please > paint > the bigger picture – it's a bit frustrating to try to help you, but > then only get told that "this is not how I want to do it". >  > Best regards, > Marcus >  > On Sat, 2019-05-25 at 18:39 +0200, Marcus Müller wrote: > >  Dear Farid, > >  > >  please always respond on the mailing list. > >  Thank you, > >  Marcus Müller > >  > >  On Sat, 2019-05-25 at 17:36 +0100, farid mihoub wrote: > >  > 1- For the noise : in the TX side the output is in the order > > of 2A, > >  > the noise 0.05A. > >  > 2-Second even without noise, the const does not affect the > >  > transmission, is there any sort of power normalization? > >  > 3-For the FEC and the modulation I want to try my custom > > mapping > >  > where information is linearly related to complex symbols, and > > my > >  > application doesn't require error correction.  > >  >  > >  > Thank you. > >  >  > >  >  > >  > 25.05.2019, 17:06, "Marcus Müller" : > >  > > Hello Farid, > >  > > On Sat, 2019-05-25 at 15:59 +0100, farid mihoub wrote: > >  > > > Hello, > >  > > >  > >  > > > In the OFDM_tx, rx examples in gr-digital : > >  > > > 1- Why just a low level of noise affect the transmission > > and > >  > > > cause it > >  > > > to stop. > >  > >  > >  > > "low" is relative. It seems it's high enough to cause packet > >  > > losses, > >  > > iff it's actually the noise. > >  > >  > >  > > > 2- in the the Tx output and the Rx input no matter the > > value > >  > > > of > >  > > > the > >  > > > multiply constant we apply > >  > > > that would not affect our transmission. > >  > >  > >  > > Then it's probably not only the noise! > >  > >  > >  > > > 3- Is there any way to separate channel estimation and > >  > > > tracking > >  > > > from > >  > > > data transmission, sometime I get the error "invalid > > packet > >  > > > detected!" form the packet parser, also I need my data to > >  > > > bypass > >  > > > FEC > >  > > > and QAM. > >  > >  > >  > > Um, prior to QAM demodulation there is no data, and prior to > > FEC > >  > > decoding there is no information bits, so I'm not sure what > > you > >  > > want? > >  > >  > >  > > > My purpose is to stream raw complex data to the I/Q > >  > > > components > >  > > > directly. > >  > >  > >  > > Then it seems you don't want an OFDM transceiver but maybe > > just > >  > > simply > >  > > a single IFFT? Not quite sure what you have in mind. > >  > >  > >  > > Best regards, > >  > > 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___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM_TX_RX

[Marcus Müller]

hi, what's 2DCT_or_3DCT?

Best regards,
Marcus

On Sat, 2019-05-25 at 19:38 +0100, farid mihoub wrote:
> My application is to broadcast a video using softcast approach. 
> Video-->2DCT_or_3DCT-->Floating coefficients-->complex_mapping
> -->ofdm_phy
> My video quality (PSNR) will depend linearly to my SNR so no need to
> have an adaptive modulation.
> 
> 
> 25.05.2019, 18:27, "Marcus Müller" :
> > 1- So, you have an SNR of best-case 16 dB; that's not high for an
> > OFDM
> > system.
> > 
> > 2- No, there's no power normalization. Hint: you can look all this
> > up
> > by actually looking inside these blocks! This would make a lot of
> > sense, since it sounds you don't actually want to use tzhe OFDM
> > blocks
> > at all. The whole advantage of the OFDM blocks compared to just
> > doing
> > an IFFT of your transmit vector is that you get a header and
> > modulation
> > scheme.
> > 
> > 3- Not quite sure what "information is linearly related to complex
> > symbols" means? Can you elaborate?
> > 3b- A case where you *don't* do FEC is either a non-communications
> > system (i.e. you don't actually want to do OFDM for the reason of
> > transmitting information) or the extremely-bad-SNR case (where FEC
> > makes your BER better). For both cases, the existing OFDM blocks
> > are
> > more of an obstacle than a solution.
> > 
> > What are you building? What is your overall application. Please
> > paint
> > the bigger picture – it's a bit frustrating to try to help you, but
> > then only get told that "this is not how I want to do it".
> > 
> > Best regards,
> > Marcus
> > 
> > On Sat, 2019-05-25 at 18:39 +0200, Marcus Müller wrote:
> > >  Dear Farid,
> > > 
> > >  please always respond on the mailing list.
> > >  Thank you,
> > >  Marcus Müller
> > > 
> > >  On Sat, 2019-05-25 at 17:36 +0100, farid mihoub wrote:
> > >  > 1- For the noise : in the TX side the output is in the order
> > > of 2A,
> > >  > the noise 0.05A.
> > >  > 2-Second even without noise, the const does not affect the
> > >  > transmission, is there any sort of power normalization?
> > >  > 3-For the FEC and the modulation I want to try my custom
> > > mapping
> > >  > where information is linearly related to complex symbols, and
> > > my
> > >  > application doesn't require error correction. 
> > >  > 
> > >  > Thank you.
> > >  > 
> > >  > 
> > >  > 25.05.2019, 17:06, "Marcus Müller" :
> > >  > > Hello Farid,
> > >  > > On Sat, 2019-05-25 at 15:59 +0100, farid mihoub wrote:
> > >  > > > Hello,
> > >  > > > 
> > >  > > > In the OFDM_tx, rx examples in gr-digital :
> > >  > > > 1- Why just a low level of noise affect the transmission
> > > and
> > >  > > > cause it
> > >  > > > to stop.
> > >  > > 
> > >  > > "low" is relative. It seems it's high enough to cause packet
> > >  > > losses,
> > >  > > iff it's actually the noise.
> > >  > > 
> > >  > > > 2- in the the Tx output and the Rx input no matter the
> > > value
> > >  > > > of
> > >  > > > the
> > >  > > > multiply constant we apply
> > >  > > > that would not affect our transmission.
> > >  > > 
> > >  > > Then it's probably not only the noise!
> > >  > > 
> > >  > > > 3- Is there any way to separate channel estimation and
> > >  > > > tracking
> > >  > > > from
> > >  > > > data transmission, sometime I get the error "invalid
> > > packet
> > >  > > > detected!" form the packet parser, also I need my data to
> > >  > > > bypass
> > >  > > > FEC
> > >  > > > and QAM.
> > >  > > 
> > >  > > Um, prior to QAM demodulation there is no data, and prior to
> > > FEC
> > >  > > decoding there is no information bits, so I'm not sure what
> > > you
> > >  > > want?
> > >  > > 
> > >  > > > My purpose is to stream raw complex data to the I/Q
> > >  > > > components
> > >  > > > directly.
> > >  > > 
> > >  > > Then it seems you don't want an OFDM transceiver but maybe
> > > just
> > >  > > simply
> > >  > > a single IFFT? Not quite sure what you have in mind.
> > >  > > 
> > >  > > Best regards,
> > >  > > 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


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

Re: [Discuss-gnuradio] OFDM_TX_RX

[farid mihoub]

My application is to broadcast a video using softcast approach. Video-->2DCT_or_3DCT-->Floating coefficients-->complex_mapping-->ofdm_phyMy video quality (PSNR) will depend linearly to my SNR so no need to have an adaptive modulation.25.05.2019, 18:27, "Marcus Müller" :1- So, you have an SNR of best-case 16 dB; that's not high for an OFDMsystem.2- No, there's no power normalization. Hint: you can look all this upby actually looking inside these blocks! This would make a lot ofsense, since it sounds you don't actually want to use tzhe OFDM blocksat all. The whole advantage of the OFDM blocks compared to just doingan IFFT of your transmit vector is that you get a header and modulationscheme.3- Not quite sure what "information is linearly related to complexsymbols" means? Can you elaborate?3b- A case where you *don't* do FEC is either a non-communicationssystem (i.e. you don't actually want to do OFDM for the reason oftransmitting information) or the extremely-bad-SNR case (where FECmakes your BER better). For both cases, the existing OFDM blocks aremore of an obstacle than a solution.What are you building? What is your overall application. Please paintthe bigger picture – it's a bit frustrating to try to help you, butthen only get told that "this is not how I want to do it".Best regards,MarcusOn Sat, 2019-05-25 at 18:39 +0200, Marcus Müller wrote: Dear Farid, please always respond on the mailing list. Thank you, Marcus Müller On Sat, 2019-05-25 at 17:36 +0100, farid mihoub wrote: > 1- For the noise : in the TX side the output is in the order of 2A, > the noise 0.05A. > 2-Second even without noise, the const does not affect the > transmission, is there any sort of power normalization? > 3-For the FEC and the modulation I want to try my custom mapping > where information is linearly related to complex symbols, and my > application doesn't require error correction.   >   > Thank you. >  >  > 25.05.2019, 17:06, "Marcus Müller" : > > Hello Farid, > > On Sat, 2019-05-25 at 15:59 +0100, farid mihoub wrote: > > >  Hello, > > >  > > >  In the OFDM_tx, rx examples in gr-digital : > > >  1- Why just a low level of noise affect the transmission and > > > cause it > > >  to stop. > >  > > "low" is relative. It seems it's high enough to cause packet > > losses, > > iff it's actually the noise. > >  > > >  2- in the the Tx output and the Rx input no matter the value > > > of > > > the > > >  multiply constant we apply > > > that would not affect our transmission. > >  > > Then it's probably not only the noise! > >  > > >  3- Is there any way to separate channel estimation and > > > tracking > > > from > > > data transmission, sometime I get the error "invalid packet > > >  detected!" form the packet parser, also I need my data to > > > bypass > > > FEC > > >  and QAM. > >  > > Um, prior to QAM demodulation there is no data, and prior to FEC > > decoding there is no information bits, so I'm not sure what you > > want? > >  > > > My purpose is to stream raw complex data to the I/Q > > > components > > >  directly. > >  > > Then it seems you don't want an OFDM transceiver but maybe just > > simply > > a single IFFT? Not quite sure what you have in mind. > >  > > Best regards, > > 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] OFDM_TX_RX

[Marcus Müller]

1- So, you have an SNR of best-case 16 dB; that's not high for an OFDM
system.

2- No, there's no power normalization. Hint: you can look all this up
by actually looking inside these blocks! This would make a lot of
sense, since it sounds you don't actually want to use tzhe OFDM blocks
at all. The whole advantage of the OFDM blocks compared to just doing
an IFFT of your transmit vector is that you get a header and modulation
scheme.

3- Not quite sure what "information is linearly related to complex
symbols" means? Can you elaborate?
3b- A case where you *don't* do FEC is either a non-communications
system (i.e. you don't actually want to do OFDM for the reason of
transmitting information) or the extremely-bad-SNR case (where FEC
makes your BER better). For both cases, the existing OFDM blocks are
more of an obstacle than a solution.

What are you building? What is your overall application. Please paint
the bigger picture – it's a bit frustrating to try to help you, but
then only get told that "this is not how I want to do it".

Best regards,
Marcus

On Sat, 2019-05-25 at 18:39 +0200, Marcus Müller wrote:
> Dear Farid,
> 
> please always respond on the mailing list.
> Thank you,
> Marcus Müller
> 
> On Sat, 2019-05-25 at 17:36 +0100, farid mihoub wrote:
> > 1- For the noise : in the TX side the output is in the order of 2A,
> > the noise 0.05A.
> > 2-Second even without noise, the const does not affect the
> > transmission, is there any sort of power normalization?
> > 3-For the FEC and the modulation I want to try my custom mapping
> > where information is linearly related to complex symbols, and my
> > application doesn't require error correction.  
> >  
> > Thank you.
> > 
> > 
> > 25.05.2019, 17:06, "Marcus Müller" :
> > > Hello Farid,
> > > On Sat, 2019-05-25 at 15:59 +0100, farid mihoub wrote:
> > > >  Hello,
> > > > 
> > > >  In the OFDM_tx, rx examples in gr-digital :
> > > >  1- Why just a low level of noise affect the transmission and
> > > > cause it
> > > >  to stop.
> > > 
> > > "low" is relative. It seems it's high enough to cause packet
> > > losses,
> > > iff it's actually the noise.
> > > 
> > > >  2- in the the Tx output and the Rx input no matter the value
> > > > of
> > > > the
> > > >  multiply constant we apply
> > > > that would not affect our transmission.
> > > 
> > > Then it's probably not only the noise!
> > > 
> > > >  3- Is there any way to separate channel estimation and
> > > > tracking
> > > > from
> > > > data transmission, sometime I get the error "invalid packet
> > > >  detected!" form the packet parser, also I need my data to
> > > > bypass
> > > > FEC
> > > >  and QAM.
> > > 
> > > Um, prior to QAM demodulation there is no data, and prior to FEC
> > > decoding there is no information bits, so I'm not sure what you
> > > want?
> > > 
> > > > My purpose is to stream raw complex data to the I/Q
> > > > components
> > > >  directly.
> > > 
> > > Then it seems you don't want an OFDM transceiver but maybe just
> > > simply
> > > a single IFFT? Not quite sure what you have in mind.
> > > 
> > > Best regards,
> > > 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] OFDM_TX_RX

[Marcus Müller]

Dear Farid,

please always respond on the mailing list.
Thank you,
Marcus Müller

On Sat, 2019-05-25 at 17:36 +0100, farid mihoub wrote:
> 1- For the noise : in the TX side the output is in the order of 2A,
> the noise 0.05A.
> 2-Second even without noise, the const does not affect the
> transmission, is there any sort of power normalization?
> 3-For the FEC and the modulation I want to try my custom mapping
> where information is linearly related to complex symbols, and my
> application doesn't require error correction.  
>  
> Thank you.
> 
> 
> 25.05.2019, 17:06, "Marcus Müller" :
> > Hello Farid,
> > On Sat, 2019-05-25 at 15:59 +0100, farid mihoub wrote:
> > >  Hello,
> > > 
> > >  In the OFDM_tx, rx examples in gr-digital :
> > >  1- Why just a low level of noise affect the transmission and
> > > cause it
> > >  to stop.
> > 
> > "low" is relative. It seems it's high enough to cause packet
> > losses,
> > iff it's actually the noise.
> > 
> > >  2- in the the Tx output and the Rx input no matter the value of
> > > the
> > >  multiply constant we apply
> > > that would not affect our transmission.
> > 
> > Then it's probably not only the noise!
> > 
> > >  3- Is there any way to separate channel estimation and tracking
> > > from
> > > data transmission, sometime I get the error "invalid packet
> > >  detected!" form the packet parser, also I need my data to bypass
> > > FEC
> > >  and QAM.
> > 
> > Um, prior to QAM demodulation there is no data, and prior to FEC
> > decoding there is no information bits, so I'm not sure what you
> > want?
> > 
> > > My purpose is to stream raw complex data to the I/Q
> > > components
> > >  directly.
> > 
> > Then it seems you don't want an OFDM transceiver but maybe just
> > simply
> > a single IFFT? Not quite sure what you have in mind.
> > 
> > Best regards,
> > Marcus
> > 


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

Re: [Discuss-gnuradio] OFDM_TX_RX

[Marcus Müller]

Hello Farid,
On Sat, 2019-05-25 at 15:59 +0100, farid mihoub wrote:
> Hello,
>  
> In the OFDM_tx, rx examples in gr-digital :
> 1- Why just a low level of noise affect the transmission and cause it
> to  stop.

"low" is relative. It seems it's high enough to cause packet losses,
iff it's actually the noise.

> 2- in the the Tx output and the Rx input no matter the value of the
> multiply constant we apply
>that would not affect our transmission.

Then it's probably not only the noise!

> 3- Is there any way to separate channel estimation and tracking from
>data transmission, sometime I get the error "invalid packet
> detected!" form the packet parser, also I need my data to bypass FEC
> and QAM.

Um, prior to QAM demodulation there is no data, and prior to FEC
decoding there is no information bits, so I'm not sure what you want?

>My purpose is to stream raw complex data to the I/Q components
> directly.

Then it seems you don't want an OFDM transceiver but maybe just simply
a single IFFT? Not quite sure what you have in mind.

Best regards,
Marcus


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

[Discuss-gnuradio] OFDM_TX_RX

[farid mihoub]

Hello, In the OFDM_tx, rx examples in gr-digital :1- Why just a low level of noise affect the transmission and cause it to  stop.2- in the the Tx output and the Rx input no matter the value of the multiply constant we apply   that would not affect our transmission.3- Is there any way to separate channel estimation and tracking from   data transmission, sometime I get the error "invalid packet detected!" form the packet parser, also I need my data to bypass FEC and QAM.   My purpose is to stream raw complex data to the I/Q components directly.  Thank you.

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

Re: [Discuss-gnuradio] Clarification on the subject gnuradio‏

[CEL]

Dear Moon Light,

there's no such course. Get yourself familiar with GNU Radio; the usage
of these blocks should be relatively self-explanatory and illustrated
by the examples with GNU Radio. Feel free to ask specific questions
related to the blocks you want to use on the mailing list.

Best regards,
Marcus

On Sat, 2019-05-25 at 15:07 +0300, Moon Light wrote:
> Dear Mr
> Ok, I will. 
> 
> 
> 
> ‫في السبت، 25 مايو 2019 في 2:30 م تمت كتابة ما يلي بواسطة ‪Müller,
> Marcus (CEL)‬‏ <‪muel...@kit.edu‬‏>:‬
> > Dear Moon light,
> > 
> > Please stay on the mailing list.
> > 
> > Best regards,
> > Marcus
> > On Sat, 2019-05-25 at 14:19 +0300, Moon Light wrote:
> > > Dear Mr
> > > i am need course to explain for example gr-dvbs2 blocks and 
> > > Anything like him
> > > Best regards
> > > 
> > > ‫في الخميس، 23 مايو 2019 في 3:29 م تمت كتابة ما يلي بواسطة
> > ‪Müller,
> > > Marcus (CEL)‬‏ <‪muel...@kit.edu‬‏>:‬
> > > > Dear Moon Light,
> > > > 
> > > > Please stay on the mailing list.
> > > > The guided tutorials *are* a course through GNU Radio.
> > > > If you need an introduction to digital communications and DSP,
> > > > typically I'd say "these are subjects in every electrical
> > > > engineering
> > > > program", but since you're asking:
> > > > https://wiki.gnuradio.org/index.php/SuggestedReading
> > > > 
> > > > 
> > > > Best regards,
> > > > Marcus
> > > > 
> > > > On Thu, 2019-05-23 at 15:19 +0300, Moon Light wrote:
> > > > > Dear Mr
> > > > > i am want to explain for block digital communcaition and
> > digital
> > > > signal processing
> > > > > i am need  course online Is there 
> > > > > Sincerely
> > > > > 
> > > > > ‫في الخميس، 23 مايو 2019 في 3:05 م تمت كتابة ما يلي بواسطة
> > > > ‪Müller, Marcus (CEL)‬‏ <‪muel...@kit.edu‬‏>:‬
> > > > > > Dear Moon Light,
> > > > > > 
> > > > > > the "Guided Tutorials" on
> > > > > > 
> > > > > > https://tutorials.gnuradio.org
> > > > > > 
> > > > > > Best regards,
> > > > > > Marcus Müller
> > > > > > 
> > > > > > On Thu, 2019-05-23 at 14:55 +0300, Moon Light wrote:
> > > > > > > Dear Mr
> > > > > > > I am a new student with software defined radio
> > > > > > > I would like to learn sdr with gnuradio 
> > > > > > > Where I followed your projects on github
> > > > > > > But I want a course that explains the mechanics of
> > dealing
> > > > with the block in gnuradio or any material Explain this
> > > > > > > 
> > > > > > > Sincerely
> > > > > > > 
> > > > > > > ___
> > > > > > > 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] Clarification on the subject gnuradio‏

[Moon Light]

Dear Mr
Ok, I will.



‫في السبت، 25 مايو 2019 في 2:30 م تمت كتابة ما يلي بواسطة ‪Müller, Marcus
(CEL)‬‏ <‪muel...@kit.edu‬‏>:‬

> Dear Moon light,
>
> Please stay on the mailing list.
>
> Best regards,
> Marcus
> On Sat, 2019-05-25 at 14:19 +0300, Moon Light wrote:
> > Dear Mr
> > i am need course to explain for example gr-dvbs2 blocks and
> > Anything like him
> > Best regards
> >
> > ‫في الخميس، 23 مايو 2019 في 3:29 م تمت كتابة ما يلي بواسطة ‪Müller,
> > Marcus (CEL)‬‏ <‪muel...@kit.edu‬‏>:‬
> > > Dear Moon Light,
> > >
> > > Please stay on the mailing list.
> > > The guided tutorials *are* a course through GNU Radio.
> > > If you need an introduction to digital communications and DSP,
> > > typically I'd say "these are subjects in every electrical
> > > engineering
> > > program", but since you're asking:
> > > https://wiki.gnuradio.org/index.php/SuggestedReading
> > >
> > >
> > > Best regards,
> > > Marcus
> > >
> > > On Thu, 2019-05-23 at 15:19 +0300, Moon Light wrote:
> > > > Dear Mr
> > > > i am want to explain for block digital communcaition and digital
> > > signal processing
> > > > i am need  course online Is there
> > > > Sincerely
> > > >
> > > > ‫في الخميس، 23 مايو 2019 في 3:05 م تمت كتابة ما يلي بواسطة
> > > ‪Müller, Marcus (CEL)‬‏ <‪muel...@kit.edu‬‏>:‬
> > > > > Dear Moon Light,
> > > > >
> > > > > the "Guided Tutorials" on
> > > > >
> > > > > https://tutorials.gnuradio.org
> > > > >
> > > > > Best regards,
> > > > > Marcus Müller
> > > > >
> > > > > On Thu, 2019-05-23 at 14:55 +0300, Moon Light wrote:
> > > > > > Dear Mr
> > > > > > I am a new student with software defined radio
> > > > > > I would like to learn sdr with gnuradio
> > > > > > Where I followed your projects on github
> > > > > > But I want a course that explains the mechanics of dealing
> > > with the block in gnuradio or any material Explain this
> > > > > >
> > > > > > Sincerely
> > > > > >
> > > > > > ___
> > > > > > 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] Clarification on the subject gnuradio‏

[CEL]

Dear Moon light,

Please stay on the mailing list.

Best regards,
Marcus
On Sat, 2019-05-25 at 14:19 +0300, Moon Light wrote:
> Dear Mr
> i am need course to explain for example gr-dvbs2 blocks and 
> Anything like him
> Best regards
> 
> ‫في الخميس، 23 مايو 2019 في 3:29 م تمت كتابة ما يلي بواسطة ‪Müller,
> Marcus (CEL)‬‏ <‪muel...@kit.edu‬‏>:‬
> > Dear Moon Light,
> > 
> > Please stay on the mailing list.
> > The guided tutorials *are* a course through GNU Radio.
> > If you need an introduction to digital communications and DSP,
> > typically I'd say "these are subjects in every electrical
> > engineering
> > program", but since you're asking:
> > https://wiki.gnuradio.org/index.php/SuggestedReading
> > 
> > 
> > Best regards,
> > Marcus
> > 
> > On Thu, 2019-05-23 at 15:19 +0300, Moon Light wrote:
> > > Dear Mr
> > > i am want to explain for block digital communcaition and digital
> > signal processing
> > > i am need  course online Is there 
> > > Sincerely
> > > 
> > > ‫في الخميس، 23 مايو 2019 في 3:05 م تمت كتابة ما يلي بواسطة
> > ‪Müller, Marcus (CEL)‬‏ <‪muel...@kit.edu‬‏>:‬
> > > > Dear Moon Light,
> > > > 
> > > > the "Guided Tutorials" on
> > > > 
> > > > https://tutorials.gnuradio.org
> > > > 
> > > > Best regards,
> > > > Marcus Müller
> > > > 
> > > > On Thu, 2019-05-23 at 14:55 +0300, Moon Light wrote:
> > > > > Dear Mr
> > > > > I am a new student with software defined radio
> > > > > I would like to learn sdr with gnuradio 
> > > > > Where I followed your projects on github
> > > > > But I want a course that explains the mechanics of dealing
> > with the block in gnuradio or any material Explain this
> > > > > 
> > > > > Sincerely
> > > > > 
> > > > > ___
> > > > > 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] Audio Source - 2 outputs in a windows enviroment

[Marcus Müller]

Hi Charlie,

Sorry to hear you've got problems! So, the issue is this: The native
windows audio source simply can't do two outputs so far. That's a
feature clearly lacking!

However, together with Gary we've been able to track down the issue and
come up with a workaround[1].

Long story short, two issues:

1. The "native windows" audio system used internally by default on
windows doesn't have stereo, but there's also the "portaudio"
implementation that works under windows and does. 
All you have to do is change a couple of preferences to allow you to do
that.
2. Sadly, under Windows the preferences-file-reading system is broken,
but we've got a fix for that in the next release.


So, we need to fix 2. before we can fix 1. WITH THIS RELEASE OF GNU
RADIO (3.7.13.5 and before). The next release will already contain a
fix for issue 2.

You need to have a directory {XYZ}\etc\gnuradio\conf.d ; that's
probably already somewhere in your Windows GNU Radio installation. Take
the "{XYZ}" of that path, and set it as GR_PREFIX, like this on a
command window:

set GR_PREFIX=XYZ

If 

set GR_PREFIX=XYZ
gnuradio-config-info --prefsdir 

works and now shows your full path to conf.d, you can simply go and 
also run

gnuradio-config-info --userprefsdir

which should yield something like
C:\Users\YourNameHere\AppData\Roaming\.gnuradio

In this directory should be a config.conf file.  Open it in notepad or
whatever text editor, and add 

[audio]

audio_module = portaudio

then, save and close.

If you 

gnuradio-config-info --prefs

it should now list exactly these lines (among others) that specify you
want to use portaudio instead of the default audio system choice. 

Congrats!

So, the way to make that work consistently is to edit "run_gr.bat" in
C:\Program Files\Gnuradio-3.7\bin (or wherever it's installed) to
reflect the GR_PREFIX path above.

Sorry it's such a hassle: Testing whether things work on Windows is a
very more manual task to us, and I'm eternally thankful for Geof to
build these windows versions at all!

Best regards,
Marcus

[1] 
http://lists.gnu.org/archive/html/discuss-gnuradio/2019-05/msg00033.html

On Fri, 2019-05-24 at 20:18 -0700, Charlie22911 wrote:
> I've found what appears to be a bug with the Audio Source block when
> using dual outputs.
> This can be replicated very simply by attaching a dual output Audio
> Source block to a Wav File Sink, it always results in the following
> error:
> 
> ValueError: port number 1 exceeds max of 0
> 
> The only solution I've found was simply "use linux", but this isn't
> really acceptable for my use case.
> 
> Any help would be greatly appreciated.
> 
> With regards,
> 
> Charlie
> 
> ___
> 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] Audio source cannot use 2 outputs (Stereo) in windows

[Marcus Müller]

Hey Geof,

somehow I've now been missing your reply. Thanks for all you do!

Best regards,
Marcus

On Mon, 2019-05-13 at 08:46 -0400, Geof Nieboer wrote:
> I apologize for missing this email chain.  
> 
> FYI, anytime you see a "Z:\gr-build" somewhere in a Windows install,
> know that that is the path I use when buildiing the installers, so
> exactly as was already deduced, that is a path that ended up being
> hardcoded someplace.  It's particular of the cultural difference
> between Linux/Win, as Linux tends to assume that code is running on
> the machine that built it.
> 
> The best approach to modification of environment variables specific
> to GR usage on Windows is to modify the "run_gr.bat" in C:\Program
> Files\Gnuradio-3.7\bin, which sets up a complete set of variable to
> support the custom python install etc., and will also then allow
> side-by-side of multiple installs (when we release a 3.8 version).
> 
> So I will create an issue on the scripts github to set this
> environment variable automatically in run_gr.bat in the next version
> (I'll also include the stereo source fix as well).
> 
> Geof
> 
> 
> 
> On Sat, May 11, 2019 at 5:48 AM Marcus Müller <
> marcus.muel...@ettus.com> wrote:
> > Hi Gary,
> > 
> > I'm sorry for the long silence, but just to let you know:
> > a) if you think you can get me fed up with you, you'll have to do
> > better than to patiently report bugs, take suggestions, give
> > feedback.
> > That's absolutely no way to annoy me!
> > b) Your work has led me to writing a small patch that we'll
> > hopefully
> > be able to roll out soon, see 
> > https://github.com/gnuradio/gnuradio/pull/2475
> > 
> > Best regards,
> > Marcus
> > 
> > On Mon, 2019-05-06 at 12:16 +0100, Gary.Simpkins wrote:
> > > Hi Marcus.
> > > 
> > > It was late last night and I missed the errors in the 
> > > grnradio-config-info -- prefsdir response.
> > > 
> > > It had the dirs twice. So I changed the Prefix in windows to be
> > just 
> > > GNUradio-3.7, and the tried again.
> > > 
> > > The prefs now has details includng portaudio.
> > > 
> > > When I start gnuradio companion  I now see lots of warnings about
> > > files 
> > > already existing.
> > > 
> > > When try to generate with the audio source I get a lot of audio
> > > config 
> > > lines. all to do with portaudio
> > > 
> > > BUT  --IT Looks like portaudio is working for me on windows.
> > > 
> > > Certainly I get two outputs. If they are the I and Q Ioutputs t
> > is
> > > my 
> > > next test, but looking very good.
> > > 
> > > Many Many thanks.
> > > 
> > > Regards
> > > 
> > > Gary
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > On 05/05/2019 17:43, Marcus Müller wrote:
> > > > Hi Gary,
> > > > 
> > > > > This confuses simple folk like me.
> > > > this confuses simple folks such as me, too!
> > > > 
> > > > That --prefsdir output is most defintely bogus. I can speculate
> > > > what
> > > > happened there, however:
> > > > 
> > > > > Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d
> > > > That --prefsdir value is part of the source code that gets
> > compiled
> > > > into the tool/the GNU Radio libraries. Normally, you wouldn't
> > do
> > > > that,
> > > > "hardwiring" a directory path into a library, but write it in a
> > > > configuration file or something.
> > > > 
> > > > However, in this case, that's the place we start looking into
> > to
> > > > find
> > > > the configuration files. So, that's the one thing that actually
> > > > need to
> > > > hardwire.
> > > > 
> > > > So, there's a text string "Z:\gr-build\src-
> > > > stage3\staged_install\Release\etc\gnuradio\conf.d" in there,
> > which
> > > > is
> > > > probably a remnant of the machine that your GNU Radio got built
> > on
> > > > (again, how did you install that?).
> > > > Sadly, the "\" gets interpreted by the compiler to be "escape
> > > > symbol",
> > > > so that you can have things like "\n" for newline in strings.
> > > > Luckily,
> > > > none of the first letters of directory names combined with "\"
> > give
> > > > a
> > > > valid escape sequence, so the compiler just silently drops the
> > "\"
> > > > and
> > > > this is the string you end up with.
> > > > 
> > > > I'll admit it: that's funky, and I didn't know that happened.
> > We'll
> > > > most definitely will have to rewrite something to make this
> > work
> > > > under
> > > > windows (which uses backslashes for directory separation,
> > unlike
> > > > unixoids, which use forward slashes).
> > > > 
> > > > So, why does --userprefsdir work, but --prefsdir not?
> > > > 
> > > > Well, --userprefsdir is built from environment variables at
> > > > runtime, so
> > > > it's correct, not mangled by a compiler.
> > > > 
> > > > I hear you say, that's fine and all, and now?
> > > > 
> > > > Welll! I thought it strange that, although your
> > userprefsdir
> > > > seems
> > > > correct, GNU Radio didn't read the