Re: [Discuss-gnuradio] Poly phase channelizing in Blade Or USRP

[Cinaed Simson]

On 09/26/2016 05:04 PM, Garver, Paul W wrote:
> I'm a bit confused by your calculation. Nyquist for complex data is
> equal to the analog bandwidth so you only need a sample rate of 25.6
> MSPS as stated. USB 3.0 will handle this without a problem on the B200.
> If you use short (16 bit integers) IQ then you have 4 bytes/complex
> sample so ~100MB/sec. 
> 
> I think solving your USB 3.0 woes and using GR on a general purpose
> processor will save you significant development time over FPGA
> implementations. 

Amen. Typically, if you're having USB3 problems - assuming the laptop
has a USB3 controller - and you're only using 1 USB3 port - it's the cable.

> 
> Paul Garver
> 
> 
> On Sep 26, 2016, at 7:53 PM, "du...@duaneellis.com
> "  > wrote:
> 
>> duane> It seems like a perfect fit for a poly phase filter - however
>> this is
>> duane> something that I believe needs to be done in hardware (128
>> channels *
>> duane> 200khz = about 60mhz sample rate this will not go over a USB
>> cable, and
>> duane> I doubt I can get this bandwidth into a laptop PC.
>>
>> sylvain> !?!?
>>
>> sylvain> 128 channels of 200 kHz = 25.6 MHz of bandwidth. You can
>> totally get
>> sylvain> that to a laptop.
>>
>> Nyquest requires 2x samples = 51.2mhz sample rate
>> Assuming I/Q data 2x bytes =  102.4mbyte/second
>> At 8bit bytes = 819.6 mbits per second is the bit rate.
>>
>> thats about 17% of the bandwidth of USB 3 (5gbit) however that does not
>> account for framing overhead, and other related things.
>> Figure another 10% loss for signaling over head.
>>
>> You are correct it is possible
>>
>> sylvian> B2xx or BladeRF will do that without issues given a
>> sufficiently good laptop.
>>
>> You mean a USB 3 based solution possibly - but I have had very limited
>> success with USB 3 - they always seem to fall back to USB 2 speeds,
>> and/or - the data rate is not there - perhaps my experience is flawed
>> due to cheap data sources {ie: hard drives}
>>
>> sylvian> If the transmission are "infrequent" you can even use the same
>> trick
>> sylvian> that researchers used a while back to listen to all of
>> bluetooth and
>> sylvian> deliberately alias the signal to fold the spectrum over itself.
>>
>> I understand that, after 'unfolding' I need to get the actual channel
>> number. that's not possible if I do what you describe.
>>
>> duane> Am I going to have to do FPGA work on my own?
>>
>> sylvian> Very likely.
>>
>> duane> Or - is there some existing cook book solution with the FPGA
>> duane> configuration pre-cooked?
>>
>> sylvian> Very unlikely to find something "all done".
>> sylvian> Especially that if you don't want to ship the samples, a PFB is
>> not
>> sylvian> all you need. You'd need demod for each channel in the hardware
>> as
>> sylvian> well.
>>
>> That is well understood.
>>
>> duane> What I am looking for is the FPGA channelizer solution...
>> hopefully an
>> duane> existing one I could start with?
>>
>> sylvian> There is an embryon of one in the ettus rfnoc repo and AFAIK
>> they
>> sylvian> might also replace it with another version soon.
>>
>> sylvian> But it's written for RFNoC and Series-7 Xilinx fpga. It'll need
>> quite
>> sylvian> some adaptation to run on anything else.
>> sylvian> Also, AFAIU, it's incomplete and non-tested currently so ...
>> YMMV.
>>
>> Thanks for the pointer.
>>
>> -Duane.
>>
>>
>> ___
>> 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] Poly phase channelizing in Blade Or USRP

[duane]

paul>  I'm a bit confused by your calculation. Nyquist for complex data
is equal to the analog bandwidth so you only need a sample rate of 25.6
MSPS as stated. 

Thanks, i did not know this rule about complex samples.

Paul>> short (16 bit integers)  [about] 100MB/sec. 

Ok thanks.



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

Re: [Discuss-gnuradio] Poly phase channelizing in Blade Or USRP

[Garver, Paul W]

I'm a bit confused by your calculation. Nyquist for complex data is equal to 
the analog bandwidth so you only need a sample rate of 25.6 MSPS as stated. USB 
3.0 will handle this without a problem on the B200. If you use short (16 bit 
integers) IQ then you have 4 bytes/complex sample so ~100MB/sec.

I think solving your USB 3.0 woes and using GR on a general purpose processor 
will save you significant development time over FPGA implementations.

Paul Garver


On Sep 26, 2016, at 7:53 PM, 
"du...@duaneellis.com" 
mailto:du...@duaneellis.com>> wrote:

duane> It seems like a perfect fit for a poly phase filter - however
this is
duane> something that I believe needs to be done in hardware (128
channels *
duane> 200khz = about 60mhz sample rate this will not go over a USB
cable, and
duane> I doubt I can get this bandwidth into a laptop PC.

sylvain> !?!?

sylvain> 128 channels of 200 kHz = 25.6 MHz of bandwidth. You can
totally get
sylvain> that to a laptop.

Nyquest requires 2x samples = 51.2mhz sample rate
Assuming I/Q data 2x bytes =  102.4mbyte/second
At 8bit bytes = 819.6 mbits per second is the bit rate.

thats about 17% of the bandwidth of USB 3 (5gbit) however that does not
account for framing overhead, and other related things.
Figure another 10% loss for signaling over head.

You are correct it is possible

sylvian> B2xx or BladeRF will do that without issues given a
sufficiently good laptop.

You mean a USB 3 based solution possibly - but I have had very limited
success with USB 3 - they always seem to fall back to USB 2 speeds,
and/or - the data rate is not there - perhaps my experience is flawed
due to cheap data sources {ie: hard drives}

sylvian> If the transmission are "infrequent" you can even use the same
trick
sylvian> that researchers used a while back to listen to all of
bluetooth and
sylvian> deliberately alias the signal to fold the spectrum over itself.

I understand that, after 'unfolding' I need to get the actual channel
number. that's not possible if I do what you describe.

duane> Am I going to have to do FPGA work on my own?

sylvian> Very likely.

duane> Or - is there some existing cook book solution with the FPGA
duane> configuration pre-cooked?

sylvian> Very unlikely to find something "all done".
sylvian> Especially that if you don't want to ship the samples, a PFB is
not
sylvian> all you need. You'd need demod for each channel in the hardware
as
sylvian> well.

That is well understood.

duane> What I am looking for is the FPGA channelizer solution...
hopefully an
duane> existing one I could start with?

sylvian> There is an embryon of one in the ettus rfnoc repo and AFAIK
they
sylvian> might also replace it with another version soon.

sylvian> But it's written for RFNoC and Series-7 Xilinx fpga. It'll need
quite
sylvian> some adaptation to run on anything else.
sylvian> Also, AFAIU, it's incomplete and non-tested currently so ...
YMMV.

Thanks for the pointer.

-Duane.


___
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] Poly phase channelizing in Blade Or USRP

[duane]

duane> It seems like a perfect fit for a poly phase filter - however
this is
duane> something that I believe needs to be done in hardware (128
channels *
duane> 200khz = about 60mhz sample rate this will not go over a USB
cable, and
duane> I doubt I can get this bandwidth into a laptop PC.

sylvain> !?!?

sylvain> 128 channels of 200 kHz = 25.6 MHz of bandwidth. You can
totally get
sylvain> that to a laptop.

Nyquest requires 2x samples = 51.2mhz sample rate
Assuming I/Q data 2x bytes =  102.4mbyte/second
At 8bit bytes = 819.6 mbits per second is the bit rate.

thats about 17% of the bandwidth of USB 3 (5gbit) however that does not
account for framing overhead, and other related things.
Figure another 10% loss for signaling over head. 

You are correct it is possible

sylvian> B2xx or BladeRF will do that without issues given a
sufficiently good laptop.

You mean a USB 3 based solution possibly - but I have had very limited
success with USB 3 - they always seem to fall back to USB 2 speeds,
and/or - the data rate is not there - perhaps my experience is flawed
due to cheap data sources {ie: hard drives}

sylvian> If the transmission are "infrequent" you can even use the same
trick
sylvian> that researchers used a while back to listen to all of
bluetooth and
sylvian> deliberately alias the signal to fold the spectrum over itself.

I understand that, after 'unfolding' I need to get the actual channel
number. that's not possible if I do what you describe.

duane> Am I going to have to do FPGA work on my own?

sylvian> Very likely.

duane> Or - is there some existing cook book solution with the FPGA
duane> configuration pre-cooked?

sylvian> Very unlikely to find something "all done".
sylvian> Especially that if you don't want to ship the samples, a PFB is
not
sylvian> all you need. You'd need demod for each channel in the hardware
as
sylvian> well.

That is well understood.

duane> What I am looking for is the FPGA channelizer solution...
hopefully an
duane> existing one I could start with?

sylvian> There is an embryon of one in the ettus rfnoc repo and AFAIK
they
sylvian> might also replace it with another version soon.

sylvian> But it's written for RFNoC and Series-7 Xilinx fpga. It'll need
quite
sylvian> some adaptation to run on anything else.
sylvian> Also, AFAIU, it's incomplete and non-tested currently so ...
YMMV.

Thanks for the pointer.

-Duane.


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

Re: [Discuss-gnuradio] Poly phase channelizing in Blade Or USRP

[Ed Criscuolo]

What about an RFNoC solution?

@(^.^)@ Ed
Sent from my iPhone

> On Sep 26, 2016, at 7:16 PM, Sylvain Munaut <246...@gmail.com> wrote:
> 
> Hi,
> 
> 
>> It seems like a perfect fit for a poly phase filter - however this is
>> something that I believe needs to be done in hardware (128 channels *
>> 200khz = about 60mhz sample rate this will not go over a USB cable, and
>> I doubt I can get this bandwidth into a laptop PC.
> 
> !?!?
> 
> 128 channels of 200 kHz = 25.6 MHz of bandwidth. You can totally get
> that to a laptop.
> B2xx or BladeRF will do that without issues given a sufficiently good laptop.
> Even a hackRF with USB2 only can nearly do it ( 20 MHz ).
> 
> If the transmission are "infrequent" you can even use the same trick
> that researchers used a while back to listen to all of bluetooth and
> deliberately alias the signal to fold the spectrum over itself.
> 
> 
>>Am I going to have to do FPGA work on my own?
> 
> Very likely.
> 
> 
>>Or - is there some existing cook book solution with the FPGA
>> configuration pre-cooked?
> 
> Very unlikely to find something "all done".
> Especially that if you don't want to ship the samples, a PFB is not
> all you need. You'd need demod for each channel in the hardware as
> well.
> 
> 
>> What I am looking for is the FPGA channelizer solution... hopefully an
>> existing one I could start with?
> 
> There is an embryon of one in the ettus rfnoc repo and AFAIK they
> might also replace it with another version soon.
> 
> But it's written for RFNoC and Series-7 Xilinx fpga. It'll need quite
> some adaptation to run on anything else.
> Also, AFAIU, it's incomplete and non-tested currently so ... YMMV.
> 
> 
> Cheers,
> 
>Sylvain
> 
> ___
> 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] Poly phase channelizing in Blade Or USRP

[Sylvain Munaut]

Hi,


> It seems like a perfect fit for a poly phase filter - however this is
> something that I believe needs to be done in hardware (128 channels *
> 200khz = about 60mhz sample rate this will not go over a USB cable, and
> I doubt I can get this bandwidth into a laptop PC.

!?!?

128 channels of 200 kHz = 25.6 MHz of bandwidth. You can totally get
that to a laptop.
B2xx or BladeRF will do that without issues given a sufficiently good laptop.
Even a hackRF with USB2 only can nearly do it ( 20 MHz ).

If the transmission are "infrequent" you can even use the same trick
that researchers used a while back to listen to all of bluetooth and
deliberately alias the signal to fold the spectrum over itself.


> Am I going to have to do FPGA work on my own?

Very likely.


> Or - is there some existing cook book solution with the FPGA
> configuration pre-cooked?

Very unlikely to find something "all done".
Especially that if you don't want to ship the samples, a PFB is not
all you need. You'd need demod for each channel in the hardware as
well.


> What I am looking for is the FPGA channelizer solution... hopefully an
> existing one I could start with?

There is an embryon of one in the ettus rfnoc repo and AFAIK they
might also replace it with another version soon.

But it's written for RFNoC and Series-7 Xilinx fpga. It'll need quite
some adaptation to run on anything else.
Also, AFAIU, it's incomplete and non-tested currently so ... YMMV.


Cheers,

Sylvain

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

[Discuss-gnuradio] Poly phase channelizing in Blade Or USRP

[duane]

Hi,

I need to decode about 128 channels at the same time

Details are:
   2-GFSK modulation, 25khz devation, channel separation is 200khz

It seems like a perfect fit for a poly phase filter - however this is
something that I believe needs to be done in hardware (128 channels *
200khz = about 60mhz sample rate this will not go over a USB cable, and
I doubt I can get this bandwidth into a laptop PC.

My question is:

Am I going to have to do FPGA work on my own?
Or - is there some existing cook book solution with the FPGA
configuration pre-cooked?

Some notes:
All channels are independent - and transmit randomly and
asynchronously
I am creating a *SNIFFER* that can listen to random transmissions.

Data is pretty simple -
32bit preamble (0x55, 0x55, 0x55, 0x55)
A sync word 
A length
Data, etc...
Checksum/CRC at the end

The data will eventually be forwarded to a socket interface, that
protocol is quite simple:
   UDP, with Byte 0 = the channel number, Bytes 2/3/4/5 - time of
arrival, bytes 6..N = the data packet

What I am looking for is the FPGA channelizer solution... hopefully an
existing one I could start with?

Thanks.


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

[Discuss-gnuradio] Correlation...

[duane]

Hi,

I've captured some data - and I am trying to decode this at a packet
level.

I am confused about the "binary slicer" - and how to do stuff with it.

What I am expecting ... and looking for is this:

The transmission is FSK, baud rate: 50K,  Modulation GFSK (+/- 25khz), 
The data packets look like this (and this is what I want to decode) 

Step 1:
   The preamble is 4 bytes (32bits) of either 0x55(packet-type-1), or
0xAA(packet-type-2)
   The preamble is not always recognized (ie: I see 30 bits instead of
32)
Step 2:
There is a 32bit "sync-sequence" - 0x93, 0x0b, 0x51, 0xde, 
This value also varies depending upon the internal protocol

In a perfect world this is a 64bit prefix, I'm happy if I get 48bits.

Step 3:
There is a length byte
Step 4: 
N-bytes of data
The data may or may not be whitened using a PN9 sequence
Step 5:
   Depending upon the packet type,  CRC-16 or CRC323

Problem #1 - I'm looking for some means to capture (ie: start/stop) the
preamble
   For example - I think I should have some type of correlator... whos
output spikes when pattern(X) is found.
   Where: (X) is various types of packets I might decode.

What I do see/find - is a correlator - but I do not see a "reset" input
in GRC.

What I think I need is this:

   (A) A correlator that compares against my 48/64 bit prefix

   (B) Based on a "match-signal from the correlator " - Wait (N) bits
   
   (C) Capture/extract the LENGTH field

   (D) collect the raw bits,  and effectively starts assembling bytes.

   (E) After (LEN) bytes (plus crc bytes) - stop or reset or re-arm the
start condition

I don't see how to do steps A/B/C/D/E..

Any suggestions?



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

Re: [Discuss-gnuradio] How to use correlate access code

[Dan CaJacob]

Hi Gabriel,

I think this block may be scheduled for deprecation...  You May want to
look at the Correlation Estimator block instead.

On Mon, Sep 26, 2016 at 11:19 AM Gabriel Pechiarovich <
gaps.18.2...@gmail.com> wrote:

> Hi all,
> I wanted to know how to use correlate access code block, if there is a
> example it will be usefull.
> I am tring to use it to syncronize bits in reception.
>
> Thank you all
> Gabriel Pechiarovich Salas
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

[Discuss-gnuradio] How to use correlate access code

[Gabriel Pechiarovich]

Hi all,
I wanted to know how to use correlate access code block, if there is a
example it will be usefull.
I am tring to use it to syncronize bits in reception.

Thank you all
Gabriel Pechiarovich Salas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Equalizer derived from ofdm_equalizer_1d_pilots: .base() not found.

[Oscar Sánchez]

Hi,

I've found this post related to my problem:

http://lists.gnu.org/archive/html/discuss-gnuradio/2015-02/msg00277.html

So, I've tried the following:

1) Derive a class from ofdm_equalizer_base
2) Add the function get_base_ptr() to the derived class. This function
returns a pointer to the derived class

Now, In grc, when passing the equalizer to ofdm_frame_equalizer_vcvc I've
got the following error:

Param - Equalizer(equalizer):
Value "payload_equalizer.get_base_ptr()" cannot be evaluated:
tr1::bad_weak_ptr

I've looked for information about this error, and it seems that it appears
when using shared_from_this() on an object which has no shared_ptr pointing
to it. However, In my understanding, when the equalizer is created
(function make), a shared_ptr is created.

Here my get_base_ptr() function:

sptr get_base_ptr()
{
  return boost::enable_shared_from_this::
shared_from_this();
}

Any ideas?

Oscar

On Thu, Sep 22, 2016 at 12:16 PM, Oscar Sánchez 
wrote:

> Hi all,
>
> I'm testing some equalizers for OFDM. Thus, I've derived from
> ofdm_equalizer_1d_pilots so that I can then pass it to
> ofdm_frame_equalizer_vcvc.
>
> By following this:
>
>  http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig
>
> in CMakeLists.txt I have changed the line:
>
> set(GR_REQUIRED_COMPONENTS RUNTIME)
>
> to:
>
> set(GR_REQUIRED_COMPONENTS RUNTIME DIGITAL)
>
> In this way I'm able to compile and install my module correctly: grc
> recognizes my new equalizer.
>
> However, when passing it to ofdm_frame_equalizer_vcvc, I've got the
> following error:
>
> Param - Equalizer(equalizer):
> Value "payload_equalizer.base()" cannot be evaluated:
> 'ofdm_my_equalizer' object has no attribute 'base'
>
> I've found a similar problem here:
> https://lists.gnu.org/archive/html/discuss-gnuradio/2014-03/msg00105.html
>
> But couldn't make it work in my case.
>
> Regarding namespace, do I have to include "digital"? I was only able to
> compile with the following order:
>
> namespace gr {
>   namespace digital {
> namespace myofdm {
>
> Could this be a source of problems?
>
> Thanks in advance,
>
> Oscar
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio