Re: [Discuss-gnuradio] cross correlation in the time domain and through Fourier tranform ?

[Andy Walls]

From:   jmfriedt
Date:   Thu, 22 Jun 2017 20:00:55 +0200
> 
> 
> However I'd like to demonstrate the same effect when going through the 
> Fourier 
> domain. I convert
> the stream to vector (4096 sample long is much more than the about 256-sample 
> long PRN), multiply
> one vector with the complex conjugate of the other, iFFT the result, making 
> sure I don't swap
> quadrants (I checked that FFT -> iFFT without swapping creates the same 
> original signal), back to stream
> and display the result -> same pictures as above, top graphs.
> 1. is this the correct way of processing Fourier transforms of incoming 
> signals

Well, for cross correlation, you want f[n] * conj(g[-n]) and it looks
like your math is performing that using F(s)conj(G(s)) so I think that
is OK.  Note that the time reversal really doesn't work for arbitrary
g[n], unless g[n] is of finite length or is periodic (which it is in
your simulation).


> 2. why are the cross-correlation peaks generated in the Fourier domain not 
> located at the exact same time
> than those generated in the time domain ? I could understand some lag due to 
> the low pass filter or 
> accumulating the data in the vector, but here I get a bit of jitter of cross 
> correlation peaks generated
> through the Fourier transform wrt those generated in the time domain.

Probably because the cyclic convolution != the linear convolution
without sufficient zero padding.  Without zero padding, you're going to
get aliasing at the start or end the output of your frequency domain
convolution.

See section 9.9 of 
http://www.ece.rutgers.edu/~orfanidi/intro2sp/orfanidis-i2sp.pdf
equations 9.9.1, 9.9.3, 9.9.7, and especially 9.9.10.
Also see section 9.9.2 on the Overlap-Add and Overlap-Save methods of
filtering a continuous stream using FFT's and fast convolution.



> Obvisouly this should all end up in a passive radar measurement: I can live 
> with time-domain 
> cross-correlation calculation, but this is the first time I am using the 
> stream 
> -> vector 
> functionality so I'd like to understand the consequences.

If you can detect the Tx pulses, track the PRIs, and work a Tx pulse
interval at a time, you should be able to do the proper zero padding and
perform fast convolution.

However your simulation doesn't look like a passive radar setup to me.

Regards,
Andy

> Thanks, JM
> 
> -- 
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 
> Besancon, France


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

Re: [Discuss-gnuradio] TUN/TAP PDU not working

[Cinaed Simson]

On 06/22/2017 05:24 AM, Derek Kozel wrote:
> Hello Cinaed,
> 
> I have no experience with the TUN/TAP code or setup, but the B210 is an
> SDR which can only be connected to the host using USB.

Did you try it?

>There is no IP
> address associated with it.

Probably because you haven't given it one.

I connect my Beagle Bone to my laptop over a USB cable with 2 IP
addresses - on IP for my laptop and one IP for the Beagle Bone.

The USB cable also provides power for the Beagle Bone.

Then I use ssh to connect to the Beagle Bone.

A single tap IP address is a bridge to nowhere.

-- Cinaed



> https://www.ettus.com/product/details/UB210-KIT
> 
> Regards,
> Derek
> 
> On Thu, Jun 22, 2017 at 10:29 AM, Cinaed Simson  > wrote:
> 
> On 06/17/2017 04:26 AM, mansourabadi.mojt...@gmail.com
>  wrote:
> > Hi Cinaed,
> >
> > Sorry to miss the previous email.
> >
> > I need to clarify that B210 USRP is connected to the PC though USB 
> cable. That's why my Ethernet cards are disabled.
> >
> > Meanwhile I have been trying different things and I noticed the 
> followings:
> >
> > 1- Packet Encoder/Decoder blocks work fine with GMSK modulation scheme. 
> But with other modulation like QAM and PSK, it seems to be less efficient.
> >
> > 2- I can receive any packet delivered to the virtual IP address I 
> create using GNURadio. I also can print them to the console in GNURadio.
> >
> > 3- I can easily send/receive any form of information using GMSK Scheme 
> along with packet encoder/decoder from one USRP to another>
> > 4- but whatever I do I can't put the received packets from virtual IP 
> address though GMSK and packet en/decoder.
> 
> Try setting the IP address of your USRP in the properties by replacing
> 
>   Device Address="name=USRP_1"
> 
> with
> 
>   Device Address="addr=192.168.200.1"
> 
> -- Cinaed
> 
> >
> > Sincerely,
> > Mansour.
> >
> >> On 17 Jun 2017, at 02:46, Cinaed Simson  > wrote:
> >>
> >> Incidentally, all you need is a $20-$30 Ethernet switch with 5-8
> ports,
> >> and 3 CAT-6 Ethernet cables - twice as long as you think might need.
> >>
> >> Then plug 1 one cable into each of the 3 device and plug the
> other end
> >> the of all the cables into the switch.
> >>
> >> Configure them as below and you should be able to ping all the
> devices
> >> from either the desktop or the laptop.
> >>
> >> -- Cinaed
> >>
> >>
> >>> On 06/15/2017 02:49 PM, Cinaed Simson wrote:
> >>>
> >>> I'll assume they're connected correctly.
> >>>
> >>> On the both PC1 and PC2, type
> >>>
> >>>  ip tuntap del dev tap0 mode tap
> >>>
> >>> On PC1, type
> >>>
> >>>  ifconfig enp0s31f6 inet 192.168.200.1 netmask 255.255.255.0
> >>>  ifconfig enp0s31f6 up
> >>>
> >>> On PC2, type
> >>>
> >>>  ifconfig enp0s31f6 inet 192.168.200.3 netmask 255.255.255.0
> >>>  ifconfig enp0s31f6 up
> >>>
> >>> Then on either PC, ping the other one. Try pinging the USRP. The
> pinging
> >>> shoud work - unless you have more than one Ethernet card and you
> plugged
> >>> the cable into the wrong card.
> >>>
> >>> The idea is a tap relies on the existing Ethernet framing (and hence
> >>> routing) so if the machines are connected correctly then configuring
> >>> their Ethernet cards should provide the necessary infrastructure.
> >>>
> >>> Also, you need to go the USRP mailing list and ask them how to
> change
> >>> the IP address of the B210 - it's something you should know how
> to do.
> >>>
> >>> In general, the tap address on the B210 should have the same network
> >>> address as your PC.
> >>>
> >>> The network address of PC1 is 192.168.200.0 and the host address
> >>> 192.168.200.1.
> >>>
> >>> -- Cinaed
> >>>
>  ___
>  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
> 

[Discuss-gnuradio] cross correlation in the time domain and through Fourier tranform ?

[jmfriedt]

I am trying to understand how to use the output of FFT vectors for computation,
rather than just displaying spectra (FFT Sink). I have assembled a pseudo-random
generators (linear feedback shift registers) which output two identical 
pseudo-random
sequences (PRN) when clocked by the sound card output at different rates. This 
all works very 
well. My objective is to demonstrate fine time stamping by cross-correlating 
these two 
streams.

In http://jmfriedt.sequanux.org/xcorr_grc.png, recording the PRN sequence 
(Audio source)
as the two PRNs are generated at slightly different clock frequencies (here 
20.0 and 20.2 kHz)
and multiplying one sequence with the other (ie cross-correlating) generates 
the periodic
cross correlation peaks, all is fine (http://jmfriedt.sequanux.org/xcorr1.png or
http://jmfriedt.sequanux.org/xcorr2.png bottom chart). The frequency offset 
between the two
7-bit long PRN is 200 Hz, so the delay between cross correlation peaks is 127*5 
ms=635 ms
as observed, all is good.

However I'd like to demonstrate the same effect when going through the Fourier 
domain. I convert
the stream to vector (4096 sample long is much more than the about 256-sample 
long PRN), multiply
one vector with the complex conjugate of the other, iFFT the result, making 
sure I don't swap
quadrants (I checked that FFT -> iFFT without swapping creates the same 
original signal), back to stream
and display the result -> same pictures as above, top graphs.
1. is this the correct way of processing Fourier transforms of incoming signals
2. why are the cross-correlation peaks generated in the Fourier domain not 
located at the exact same time
than those generated in the time domain ? I could understand some lag due to 
the low pass filter or 
accumulating the data in the vector, but here I get a bit of jitter of cross 
correlation peaks generated
through the Fourier transform wrt those generated in the time domain.

Obvisouly this should all end up in a passive radar measurement: I can live 
with time-domain 
cross-correlation calculation, but this is the first time I am using the stream 
-> vector 
functionality so I'd like to understand the consequences.

Thanks, JM

-- 
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 
Besancon, France

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

Re: [Discuss-gnuradio] dB or dBm

[Ralph A. Schmid, dk5ras]

But still the dynamic range usually ends already quite below the maximum
allowed level what is more a kind of hardware protection rule.

Add some more attenuation and see if at least a 5dB change on your
transmitter creates a 5dB change on your SDR. Then you are in the linear
range and can start trying to calibrate the thingy for your frequency. And
turn off AGC if this option is available.

Ralph.

> -Original Message-
> From: Discuss-gnuradio [mailto:discuss-gnuradio-
> bounces+ralph=schmid@gnu.org] On Behalf Of GNUBeginner
> Sent: Wednesday, June 21, 2017 10:48 PM
> To: Discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] dB or dBm
> 
> I am already aware of what the maximum allowable receiver power which is
-5
> dBm. That is why I am starting from 0 dBm with 20 dB attenuator before
> injecting it to the HackRF One.
> 
> 
> 
> --
> View this message in context: http://gnuradio.4.n7.nabble.com/dB-or-dBm-
> tp64323p64335.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] TUN/TAP PDU not working

[Derek Kozel]

Hello Cinaed,

I have no experience with the TUN/TAP code or setup, but the B210 is an SDR
which can only be connected to the host using USB. There is no IP address
associated with it.
https://www.ettus.com/product/details/UB210-KIT

Regards,
Derek

On Thu, Jun 22, 2017 at 10:29 AM, Cinaed Simson 
wrote:

> On 06/17/2017 04:26 AM, mansourabadi.mojt...@gmail.com wrote:
> > Hi Cinaed,
> >
> > Sorry to miss the previous email.
> >
> > I need to clarify that B210 USRP is connected to the PC though USB
> cable. That's why my Ethernet cards are disabled.
> >
> > Meanwhile I have been trying different things and I noticed the
> followings:
> >
> > 1- Packet Encoder/Decoder blocks work fine with GMSK modulation scheme.
> But with other modulation like QAM and PSK, it seems to be less efficient.
> >
> > 2- I can receive any packet delivered to the virtual IP address I create
> using GNURadio. I also can print them to the console in GNURadio.
> >
> > 3- I can easily send/receive any form of information using GMSK Scheme
> along with packet encoder/decoder from one USRP to another>
> > 4- but whatever I do I can't put the received packets from virtual IP
> address though GMSK and packet en/decoder.
>
> Try setting the IP address of your USRP in the properties by replacing
>
>   Device Address="name=USRP_1"
>
> with
>
>   Device Address="addr=192.168.200.1"
>
> -- Cinaed
>
> >
> > Sincerely,
> > Mansour.
> >
> >> On 17 Jun 2017, at 02:46, Cinaed Simson 
> wrote:
> >>
> >> Incidentally, all you need is a $20-$30 Ethernet switch with 5-8 ports,
> >> and 3 CAT-6 Ethernet cables - twice as long as you think might need.
> >>
> >> Then plug 1 one cable into each of the 3 device and plug the other end
> >> the of all the cables into the switch.
> >>
> >> Configure them as below and you should be able to ping all the devices
> >> from either the desktop or the laptop.
> >>
> >> -- Cinaed
> >>
> >>
> >>> On 06/15/2017 02:49 PM, Cinaed Simson wrote:
> >>>
> >>> I'll assume they're connected correctly.
> >>>
> >>> On the both PC1 and PC2, type
> >>>
> >>>  ip tuntap del dev tap0 mode tap
> >>>
> >>> On PC1, type
> >>>
> >>>  ifconfig enp0s31f6 inet 192.168.200.1 netmask 255.255.255.0
> >>>  ifconfig enp0s31f6 up
> >>>
> >>> On PC2, type
> >>>
> >>>  ifconfig enp0s31f6 inet 192.168.200.3 netmask 255.255.255.0
> >>>  ifconfig enp0s31f6 up
> >>>
> >>> Then on either PC, ping the other one. Try pinging the USRP. The
> pinging
> >>> shoud work - unless you have more than one Ethernet card and you
> plugged
> >>> the cable into the wrong card.
> >>>
> >>> The idea is a tap relies on the existing Ethernet framing (and hence
> >>> routing) so if the machines are connected correctly then configuring
> >>> their Ethernet cards should provide the necessary infrastructure.
> >>>
> >>> Also, you need to go the USRP mailing list and ask them how to change
> >>> the IP address of the B210 - it's something you should know how to do.
> >>>
> >>> In general, the tap address on the B210 should have the same network
> >>> address as your PC.
> >>>
> >>> The network address of PC1 is 192.168.200.0 and the host address
> >>> 192.168.200.1.
> >>>
> >>> -- Cinaed
> >>>
>  ___
>  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
> >
>
>
> ___
> 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] TUN/TAP PDU not working

[Cinaed Simson]

On 06/17/2017 04:26 AM, mansourabadi.mojt...@gmail.com wrote:
> Hi Cinaed,
> 
> Sorry to miss the previous email.
> 
> I need to clarify that B210 USRP is connected to the PC though USB cable. 
> That's why my Ethernet cards are disabled.
> 
> Meanwhile I have been trying different things and I noticed the followings:
> 
> 1- Packet Encoder/Decoder blocks work fine with GMSK modulation scheme. But 
> with other modulation like QAM and PSK, it seems to be less efficient.
> 
> 2- I can receive any packet delivered to the virtual IP address I create 
> using GNURadio. I also can print them to the console in GNURadio.
> 
> 3- I can easily send/receive any form of information using GMSK Scheme along 
> with packet encoder/decoder from one USRP to another>
> 4- but whatever I do I can't put the received packets from virtual IP address 
> though GMSK and packet en/decoder.

Try setting the IP address of your USRP in the properties by replacing

  Device Address="name=USRP_1"

with

  Device Address="addr=192.168.200.1"

-- Cinaed

>
> Sincerely,
> Mansour.
> 
>> On 17 Jun 2017, at 02:46, Cinaed Simson  wrote:
>>
>> Incidentally, all you need is a $20-$30 Ethernet switch with 5-8 ports,
>> and 3 CAT-6 Ethernet cables - twice as long as you think might need.
>>
>> Then plug 1 one cable into each of the 3 device and plug the other end
>> the of all the cables into the switch.
>>
>> Configure them as below and you should be able to ping all the devices
>> from either the desktop or the laptop.
>>
>> -- Cinaed
>>
>>
>>> On 06/15/2017 02:49 PM, Cinaed Simson wrote:
>>>
>>> I'll assume they're connected correctly.
>>>
>>> On the both PC1 and PC2, type
>>>
>>>  ip tuntap del dev tap0 mode tap
>>>
>>> On PC1, type
>>>
>>>  ifconfig enp0s31f6 inet 192.168.200.1 netmask 255.255.255.0
>>>  ifconfig enp0s31f6 up
>>>
>>> On PC2, type
>>>
>>>  ifconfig enp0s31f6 inet 192.168.200.3 netmask 255.255.255.0
>>>  ifconfig enp0s31f6 up
>>>
>>> Then on either PC, ping the other one. Try pinging the USRP. The pinging
>>> shoud work - unless you have more than one Ethernet card and you plugged
>>> the cable into the wrong card.
>>>
>>> The idea is a tap relies on the existing Ethernet framing (and hence
>>> routing) so if the machines are connected correctly then configuring
>>> their Ethernet cards should provide the necessary infrastructure.
>>>
>>> Also, you need to go the USRP mailing list and ask them how to change
>>> the IP address of the B210 - it's something you should know how to do.
>>>
>>> In general, the tap address on the B210 should have the same network
>>> address as your PC.
>>>
>>> The network address of PC1 is 192.168.200.0 and the host address
>>> 192.168.200.1.
>>>
>>> -- Cinaed
>>>
 ___
 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
> 


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

Re: [Discuss-gnuradio] Clock recovery without change of phase

[Marcus Müller]

Hi George,

isn't the job of a clock recovery actually to *change* the phase of your
signal so that its original clocking is recovered?

I'm a bit confused; could you maybe elaborate on what you want to do
(what for/why/what specific output are you looking for)? Are you maybe
looking for the clock error signal?

Best regards,
Marcus


On 06/14/2017 12:26 PM, George Vardakis wrote:
> Hi all, 
>
> I need to perform clock recovery on a signal without constantly
> changing its phase. I think that the clock recovery block in Gnuradio
> does exactly that in order to maximize the energy of the signal. Is
> there any other way that does not tamper with the signal phase? 
>
> Thanks! 
>
>
> ___
> 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] Changing transmit gain

[Marcus Müller]

Hi Tellrell,

um, that's kind of hard to tell without knowing your flow graph!

However, if you've got a block (eg. the USRP Sink) that allows
configuration through async message passing:

Try my gr-msgblock OOT Module, and use/modify variable_to_msg to
translate the variable to a message that you send to that block.

Best regards,

Marcus



On 06/21/2017 05:26 PM, Tellrell White wrote:
> Hello Guys
> I have a flowgraph attached where I'm trying to generate BER curves
> for different transmit gain values. Right now, I have gui slider that
> allows me to adjust the gain values, however, I would like to know if
> it's possible to have the gain values adjust automatically by changing
> the python script for the flowgraph. If so, I would appreciate any
> ideas or examples on how to do this.
>
> Thanks
> Tellrell White
>
>
> ___
> 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] Question on using the GMSK Mod Block and GLFSR Block

[Cinaed Simson]

I've never used GMSK Modulator - and the parameters you're using are for
GLFSR are for type float.

Enclosed is an example.

I set the Throttle to Bypass since it runs better for some reason.

Play with samples per symbol and the delay slider.

And I used the default configuration values for GMFSK Mod/Demod.

-- Cinaed


On 06/20/2017 01:59 PM, Estrada Lupianez, Jenniffer Marie wrote:
> 
> Hi,
> 
> 1. There appears to be an issue with the GMSK modulation blocks within
> GNU Radio. See the attached screen shots, where I've removed the the
> USRP completely from the flow graph, and am running it entirely within
> GNU Radio on a x64 host, comparing the two GMSK modulation blocks (GMSK
> Mod and GMSK Modulator) available in GNU Radio.
> 
> 2. Also, I am looking at the GLFSR block in GNU Radio, and I am
> wondering what the correct input for the GLFSR block parameters should
> be for what seems like a very odd configuration, since I want only 13
> bits of a 16 bit stream comprised of 0xA5A5. All three fields, Degree,
> Mask, and Seed are type INT. I am looking to use a single length 13 LFSR
> polynomial, and have an initial seed of 0xA5A5 (How the 16 bits are
> handled to get the 13 bits of interest, depends on what software we are
> using, like MATLAB vs System Generator, and the GNU Radio implementation
> has to match).
> 
> 
> What I have currently:
> 
> Type: Byte
> 
> Degree: 13 (int between 0 and 32 according to source code on-line, 13
> seems like the correct input, but is causing some confusion for me with
> the Seed value)
> 
> 
> and while I am fairly certain of those, the following parameters are
> what I am uncertain of:
> 
>  
> 
> Mask (int format)
> 
> Seed  (int format)
> 
> 
> Am I correct in thinking the Mask parameter is 0x100D, in
> correlation to the the polynomial degree that I want (13)? I found this
> at http://wiki.spench.net/wiki/GNU_Radio_Notes.
>  If I understand the GNU
> Radio Doxygen documentation and (Balint Seeber's) notes on the website,
> then leaving the Mask as 0 will have GNU Radio pick the correct one for
> me based on the polynomial degree I enter.
> 
> 
> If that is the case, then the only thing that is really catching me is
> the Seed being a type int, when I am using Type: Byte. Is the input to
> this parameter then the 8 bits within the byte? If so, how would I go
> about creating the 13 degree polynomial with that configuration? I
> was trying to see if the Packet Encoder block or the vector Source block
> would be useful for this, but I am not sure it really is what I need for
> this. I have a 16 bit hexadecimal value (0xA5A5) that I am to use only
> 13 bits out of, but it must be consistent with the formats in System
> Generator and MATLAB explained below:
> 
> 
> Current Method:
> A single length-13 LFSR polynomial is used. The feedback polynomial can
> be defined in the following formats, all equivalent:
> 
> SystemGenerator/Xilinx:
> 0x1901
> 
> Matlab:
> [13, 12, 11, 8, 0]
> 
> Koopman (users.ece.cmu.edu/~koopman/lfsr/):
> 0x1013
> 
> In the Matlab format, the first array entry defines the obligatory
> shift-register head, while the last entry likewise defines the tail. In
> both the sysgen/xilinx and Koopman formats, the shift-reg head is
> implied. However, the resulting binary sequence, without the head bit,
> and in hex, is reversed. In other words, SystemGenerator/Xilinx has the
> implied head on the left, and Koopman has it on the right. Thus, the
> format difference can cause confusion.
> 
> The Koopman method is useful, because his website tabulates millions of
> different feedback-polynomials for max-length PRN sequences of differing
> lengths.
> 
> M-Code Polynomial (Koopman Format)   Reg Init
> 0x16010x100D  0xA5A5
> 
> 
> So, this is the GLFSR configuration that I currently have:
> 
> 
> [pastedImage.png]
> 
> 
> If context is needed, I am trying to implement a pre-coded GMSK signal
> transmission of a 13 degree LSFR source with the 0xA5A5 seed, of which I
> can control how many times the output of the LFSR is generated (I notice
> that the repeat option in the LFSR source is only able to be set as
> "yes" or "no", but I assume I can tweak that within the python generated
> code to override somehow??), using an Ettus E310 SDR. The general layout
> of the blocks in the final flow graph could be something like:
> 
> 
> GLFSR source --> Differential Encoder --> GMSK modulator --> USRP Sink
> 
> 
> As seen in the precoded_gmsk.grc flowgraph and generated python code
> attached.
> 
> 
> Any assistance is appreciated.
> 
> 
> Thank you,
> 
> 
> Jenn
> 
> 
>  
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 




  Sat Apr 15 20:19:56 2017
  
options

  author
  


  window_size