How to efficiently implement dechannelization (combine multiple narrowband signals into a single broadband spectrum)

[Amr Bekhit]

Hello all,

I'm working on an SDR project where I need to transmit a narrow
baseband signal on multiple different carriers simultaneously, over a
relatively wide bandwidth (1Mhz). Essentially, when working normally,
the system acts as a radio passthrough, retransmitting the existing
channels, but then when an input is triggered, an external audio
source is then AM modulated and transmitted on several channels
instead of the original baseband.

I've been implementing the system in GNU Radio Companion and
essentially have the following for each channel:

External in -> AM mod -
  |-Selector -> Band Pass filter
-> Add -> TX
Baseband in --

Now although this works, in practice as the number of channels
increases, performance becomes an issue, as you'd expect. The main
culprit here is primarily the band pass filter, which is responsible
for about 60% of the CPU usage (the modulation is responsible for
about 30%). Using an FFT filter for the bandpass filter definitely
helped performance, but I need to improve it more.  After researching
online, I understand that the problem is primarily due to having to
deal with a very wide baseband compared to the narrowband signal that
I'm trying to filter (AM audio at 10kHz bandwidth). Unfortunately, I
can't see how I can reduce the sample rate. At the moment, everything
runs at the 1Mhz sample rate apart from the external input, which runs
at a lower rate until I have to multiply it with the AM carrier.

What is an efficient way of de-channelizing and taking multiple narrow
channels and combining them into a wide spectrum?

Re: A 21cm sky map of a goodly chunk of the northern sky

[Marcus D. Leech]

On 10/28/2019 12:55 PM, Daniel Estévez wrote:

El 28/10/19 a las 1:02, Marcus D. Leech escribió:

Here's the latest version of our 21cm sky map, derived from nearly 5
months worth of data from our 21cm spectrometer instrument.

All of the real-time processing is handled, naturally, with Gnu Radio,
and then some Python post-processing.

http://www.ccera.ca/files/21cm.png

Hi Marcus,

Very interesting. Is there any information online about how the map was
made (both GNU Radio and post-processing)?

Best,

Daniel.



Finally finalized the memo on this:

http://www.ccera.ca/files/memos/ccera-memo-0011.pdf

Re: AM demodulation

[CEL]

Hi Markus,

yeah, that sounds right, but: 
You'd probably want to use a PLL frequency detector (similarly
parameterized) to detect these and output a frequency estimate, and
then do some math on that estimate, and use it to correct the system.

Best regards,
Marcus 

On Mon, 2019-10-28 at 16:41 +0100, Markus Heller wrote:
> Dear OMs,
> 
> I guess this carrier tracking block would be useful to handle
> frequency
> drift of cheap (unstabilized) devices, when working QO-100 satellite
> connections. This block could be used to find the band end beacons
> and
> derive the frequency shift and correct it accordingly. Right?
> 
> vy73
> markus
> dl8rds
> 
> Am Montag, den 28.10.2019, 09:44 -0500 schrieb Bill Dailey:
> > Can you give a little primer on using that PLL tracking?I would
> > love to use that to just track carriers random frequencies.  For
> > instance 10mhz.  Ultimately I want to track and periodically log
> > and
> > offset from true predicted frequency. Like every 10 seconds.
> > 
> > Bill Dailey
> > 
> > Negativity always wins the short game. But positivity wins the long
> > game. - Gary Vaynerchuk
> > 
> > Don’t be easy to understand, 
> > Be impossible to misunderstand 
> > - Steve Sims
> > 
> > > On Oct 28, 2019, at 9:27 AM, Barry Duggan 
> > > wrote:
> > > 
> > > Hi Albin and Volker,
> > > 
> > > I added a PLL Carrier Tracking block to take care of the tuning
> > > problem. See the revised 
> > > https://wiki.gnuradio.org/index.php/File:FunCube_AM.png
> > > 
> > > Albin, that 'spike' is the carrier! This is AM ;)
> > > 
> > > Thank you both for your suggestions.
> > > ---
> > > Barry Duggan KV4FV
> > > 
> > > 
> > > On 2019-10-27 07:13, Albin Stigö wrote:
> > > > Hi Barry,
> > > > Some thoughts:
> > > > You have a large DC spike at the center, try using the
> > > > frequency
> > > > xlating
> > > > fir filter to tune an offset frequency.
> > > > Why don't you decimate at the channel filter?
> > > > Try observing the signal at various points using the frequency
> > > > sink.
> > > > Good luck,
> > > > Albin SM6WJM
> > > > On Sat, Oct 26, 2019, 21:02 Barry Duggan 
> > > > wrote:
> > > > > Hi,
> > > > > I've been working on a gnuradio AM broadcast receiver, and
> > > > > have
> > > > > found
> > > > > that the tuning is very critical to obtaining clear audio. My
> > > > > flowgraph
> > > > > can be seen at 
> > > > > https://wiki.gnuradio.org/index.php/File:FunCube_AM.png.
> > > > > Are there any alternate demodulation methods which are not so
> > > > > sensitive
> > > > > to exact tuning?
> > > > > Thanks,
> > > > > --
> > > > > Barry Duggan KV4FV
> 
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: AM demodulation

[CEL]

Hi Barry and Bill,

> I don't know how wide a spectrum the PLL can handle.

Generally, that's not really inherently limited by anything but the
loop bandwidth.

It's a really simple PLL, with a complex sample-argument phase
detector.

In other words: if you set the loop bandwidth too high, the PLL will
jump around like crazy in the presence of noise, or might lock onto
data instead of carrier.

Pick a bandwidth too small, and it won't be able to ever lock to even
the cleanest carrier if it's further away. It also won't be able to
"follow" a changing carrier frequency (might be pretty relevant for
satcom, if it's not geosync.

Best regards,
Marcus


smime.p7s
Description: S/MIME cryptographic signature

Re: Dynamic instances in hierarchical blocks

[CEL]

Hi Ivan,

that sounds a classical case of impossible to do in graphical, trivial
to do in Python.
So, write your hier block in Python – you could also base it on your
GRC-generated python file (and save it somewhere else, so that it
doesn't get overwritten).

Best regards,
Marcus

On Mon, 2019-10-28 at 22:18 +0100, Ivan Iudice wrote:
> Hi all!
> I’m implementing my own testbed in GRC using hierarchical blocks to
> obtain a clearer flowgraph.
> I need to have a dynamic amount of instances of a particular sub-
> block, that I can set as parameter of the higher level block.
> How can I solve my problem? It could be very cool!
> Thank you.
> 
> Ivan
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: AM demodulation

[Barry Duggan]

To all who gave me good ideas and insights,

Thank you for your help. Based on all of your comments, I have a new and 
improved AM receiver which automatically corrects small tuning errors. 
Attached is a picture of the flowgraph.


Best regards,
---
Barry Duggan KV4FV


On 2019-10-28 12:21, Albin Stigö wrote:

Last time I looked I found the AM demod block less than ideal so I just
used a complex to mag and a DC blocker and found that worked better for 
my

experiments.

73 Albin SM6WJM

On Mon, Oct 28, 2019, 16:43 Barry Duggan  wrote:


Hi Albin,

Hmm.. Good to know. I had tried a frequency translating filter to 
create

a 10khz IF, but it didn't seem to make any difference. I need to take
another look at that.

Thanks!
---
Barry Duggan KV4FV


On 2019-10-28 11:32, Albin Stigö wrote:
> A direct conversation SDR receiver like the funcube dongle pro plus has
> a
> large DC spike, it's not the carrier, it will mask your carrier
> though.. IQ
> correction will remove it, but that will also remove an AM carrier at
> 0Hz
> so it's common practice to offset a bit with a frequency translating
> filter.
>
> On Mon, Oct 28, 2019, 15:24 Barry Duggan  wrote:
>
>> Hi Albin and Volker,
>>
>> I added a PLL Carrier Tracking block to take care of the tuning
>> problem.
>> See the revised
>> https://wiki.gnuradio.org/index.php/File:FunCube_AM.png
>>
>> Albin, that 'spike' is the carrier! This is AM ;)
>>
>> Thank you both for your suggestions.
>> ---
>> Barry Duggan KV4FV
>>
>>
>> On 2019-10-27 07:13, Albin Stigö wrote:
>> > Hi Barry,
>> >
>> > Some thoughts:
>> >
>> > You have a large DC spike at the center, try using the frequency
>> > xlating
>> > fir filter to tune an offset frequency.
>> >
>> > Why don't you decimate at the channel filter?
>> >
>> > Try observing the signal at various points using the frequency sink.
>> >
>> > Good luck,
>> > Albin SM6WJM
>> >
>> > On Sat, Oct 26, 2019, 21:02 Barry Duggan  wrote:
>> >
>> >> Hi,
>> >>
>> >> I've been working on a gnuradio AM broadcast receiver, and have found
>> >> that the tuning is very critical to obtaining clear audio. My
>> >> flowgraph
>> >> can be seen at
>> >> https://wiki.gnuradio.org/index.php/File:FunCube_AM.png.
>> >> Are there any alternate demodulation methods which are not so
>> >> sensitive
>> >> to exact tuning?
>> >>
>> >> Thanks,
>> >> --
>> >> Barry Duggan KV4FV
>> >>
>> >>
>>

Dynamic instances in hierarchical blocks

[Ivan Iudice]

Hi all!
I’m implementing my own testbed in GRC using hierarchical blocks to obtain a 
clearer flowgraph.
I need to have a dynamic amount of instances of a particular sub-block, that I 
can set as parameter of the higher level block.
How can I solve my problem? It could be very cool!
Thank you.

Ivan

Re: A 21cm sky map of a goodly chunk of the northern sky

[Marcus D Leech]

I’m working on the technical memo at the moment. 

Sent from my iPhone

> On Oct 28, 2019, at 2:26 PM, Daniel Estévez  wrote:
> 
> El 28/10/19 a las 1:02, Marcus D. Leech escribió:
>> Here's the latest version of our 21cm sky map, derived from nearly 5
>> months worth of data from our 21cm spectrometer instrument.
>> 
>> All of the real-time processing is handled, naturally, with Gnu Radio,
>> and then some Python post-processing.
>> 
>> http://www.ccera.ca/files/21cm.png
> 
> Hi Marcus,
> 
> Very interesting. Is there any information online about how the map was
> made (both GNU Radio and post-processing)?
> 
> Best,
> 
> Daniel.
> 
> 

Re: A 21cm sky map of a goodly chunk of the northern sky

[Daniel Estévez]

El 28/10/19 a las 1:02, Marcus D. Leech escribió:
> Here's the latest version of our 21cm sky map, derived from nearly 5
> months worth of data from our 21cm spectrometer instrument.
> 
> All of the real-time processing is handled, naturally, with Gnu Radio,
> and then some Python post-processing.
> 
> http://www.ccera.ca/files/21cm.png

Hi Marcus,

Very interesting. Is there any information online about how the map was
made (both GNU Radio and post-processing)?

Best,

Daniel.




signature.asc
Description: OpenPGP digital signature

Re: [Discuss-gnuradio] Packet transmission questions from a newb

[Heaney, Eamon]

The final aim is to build a transmitter and receiver for 802.11p DSRC
packets.

The receiver is currently using 802.11a, for testing purposes, but I do
have a flowchart they successfully receives 802.11p instead.

I've figured out what I need to put in the file source (message binary, not
.pcap), but I'm unsure how to translate that from a gr_stream to a
gr_message, so I can feed it into the Wifi MAC block.

Thanks!

On Mon, Oct 28, 2019, 5:12 AM sumit kumar  wrote:

> " but my wi-fi packet receiver works just dandy without any OFDM blocks"
> --> Can you check the standard which your wifi receiver is following ? If
> it is 802.11b, then it wont work with gr-ieee 80211 because gr-ieee 80211
> is based on OFDM based WiFi.
>
> You cannot use .pcap file as file source for the wifi_tx.grc.
>
> May I know your final aim for this experiment so that I can put my
> suggestions ?
>
> Regards
> Sumit
>
> On Sun, 27 Oct 2019 at 20:10, Eamon Heaney  wrote:
>
>> Hi,
>>
>> I'm trying to create a wi-fi transmitter in GNURadio that can take a file
>> source and transmit it as an 802.11 packet. I'm using this
>> 
>> example as a basis, and trying to follow the guides here
>> .
>>
>> Frankly, though, a lot of what's in that guide goes way over my head. I
>> have a general understanding of what OFDM is, but my wi-fi packet receiver
>> works just dandy without any OFDM blocks. So is it still necessary to
>> incorporate such blocks into a transmitter?
>>
>> Secondly, I can't just plug a .pcap file source into the transmitter; it
>> doesn't generate, and I get the feeling that .pcap isn't the proper format
>> for transmission anyways. How can I figure out which blocks to put after
>> the file source to make it gel with the next block in the example (WiFi
>> MAC)?
>>
>> Thanks!
>>
>> --
>> Eamon Heaney
>> *Fleet Commander*
>> *President, Model UN at Virginia Tech*
>>
>
>
> --
> Sumit Kumar
>
>
>

-- 
*The information contained in this communication is confidential and may be 
legally privileged. It is intended solely for use by the intended recipient 
and others authorized to receive it. If you have received this 
communication in error, you are hereby notified that any disclosure, 
copying, distribution or taking action in reliance of the contents of this 
information is strictly prohibited and may be unlawful.*

Re: AM demodulation

[Barry Duggan]

Hi Markus,

From what I can tell, the PLL Carrier Tracking block does the 
correction, but it doesn't tell you what it did, so I'm not sure you can 
log the offsets. There are other PLL blocks I haven't looked at yet, so 
I don't know about them. See 
https://wiki.gnuradio.org/index.php/Category:Block_Docs for a list of 
all the blocks. Not all of them have been updated yet! That's what I am 
working on. Especially the example flowgraphs.


73
---
Barry Duggan KV4FV


On 2019-10-28 11:41, Markus Heller wrote:

Dear OMs,

I guess this carrier tracking block would be useful to handle frequency
drift of cheap (unstabilized) devices, when working QO-100 satellite
connections. This block could be used to find the band end beacons and
derive the frequency shift and correct it accordingly. Right?

vy73
markus
dl8rds

Am Montag, den 28.10.2019, 09:44 -0500 schrieb Bill Dailey:

Can you give a little primer on using that PLL tracking?I would
love to use that to just track carriers random frequencies.  For
instance 10mhz.  Ultimately I want to track and periodically log and
offset from true predicted frequency. Like every 10 seconds.

Bill Dailey

Negativity always wins the short game. But positivity wins the long
game. - Gary Vaynerchuk

Don’t be easy to understand,
Be impossible to misunderstand
- Steve Sims

> On Oct 28, 2019, at 9:27 AM, Barry Duggan 
> wrote:
>
> Hi Albin and Volker,
>
> I added a PLL Carrier Tracking block to take care of the tuning
> problem. See the revised
> https://wiki.gnuradio.org/index.php/File:FunCube_AM.png
>
> Albin, that 'spike' is the carrier! This is AM ;)
>
> Thank you both for your suggestions.
> ---
> Barry Duggan KV4FV
>
>
> On 2019-10-27 07:13, Albin Stigö wrote:
> > Hi Barry,
> > Some thoughts:
> > You have a large DC spike at the center, try using the frequency
> > xlating
> > fir filter to tune an offset frequency.
> > Why don't you decimate at the channel filter?
> > Try observing the signal at various points using the frequency
> > sink.
> > Good luck,
> > Albin SM6WJM
> > On Sat, Oct 26, 2019, 21:02 Barry Duggan 
> > wrote:
> > > Hi,
> > > I've been working on a gnuradio AM broadcast receiver, and have
> > > found
> > > that the tuning is very critical to obtaining clear audio. My
> > > flowgraph
> > > can be seen at
> > > https://wiki.gnuradio.org/index.php/File:FunCube_AM.png.
> > > Are there any alternate demodulation methods which are not so
> > > sensitive
> > > to exact tuning?
> > > Thanks,
> > > --
> > > Barry Duggan KV4FV

Re: AM demodulation

[Bill Dailey]

The PLL Freq Det is the one I would like to figure out.

Bill Dailey

Negativity always wins the short game. But positivity wins the long game. - 
Gary Vaynerchuk

Don’t be easy to understand, 
Be impossible to misunderstand 
- Steve Sims

> On Oct 28, 2019, at 11:01 AM, Barry Duggan  wrote:
> 
> Hi Markus,
> 
> From what I can tell, the PLL Carrier Tracking block does the correction, but 
> it doesn't tell you what it did, so I'm not sure you can log the offsets. 
> There are other PLL blocks I haven't looked at yet, so I don't know about 
> them. See https://wiki.gnuradio.org/index.php/Category:Block_Docs for a list 
> of all the blocks. Not all of them have been updated yet! That's what I am 
> working on. Especially the example flowgraphs.
> 
> 73
> ---
> Barry Duggan KV4FV
> 
> 
>> On 2019-10-28 11:41, Markus Heller wrote:
>> Dear OMs,
>> I guess this carrier tracking block would be useful to handle frequency
>> drift of cheap (unstabilized) devices, when working QO-100 satellite
>> connections. This block could be used to find the band end beacons and
>> derive the frequency shift and correct it accordingly. Right?
>> vy73
>> markus
>> dl8rds
>> Am Montag, den 28.10.2019, 09:44 -0500 schrieb Bill Dailey:
>>> Can you give a little primer on using that PLL tracking?I would
>>> love to use that to just track carriers random frequencies.  For
>>> instance 10mhz.  Ultimately I want to track and periodically log and
>>> offset from true predicted frequency. Like every 10 seconds.
>>> Bill Dailey
>>> Negativity always wins the short game. But positivity wins the long
>>> game. - Gary Vaynerchuk
>>> Don’t be easy to understand,
>>> Be impossible to misunderstand
>>> - Steve Sims
>>> > On Oct 28, 2019, at 9:27 AM, Barry Duggan 
>>> > wrote:
>>> >
>>> > Hi Albin and Volker,
>>> >
>>> > I added a PLL Carrier Tracking block to take care of the tuning
>>> > problem. See the revised
>>> > https://wiki.gnuradio.org/index.php/File:FunCube_AM.png
>>> >
>>> > Albin, that 'spike' is the carrier! This is AM ;)
>>> >
>>> > Thank you both for your suggestions.
>>> > ---
>>> > Barry Duggan KV4FV
>>> >
>>> >
>>> > On 2019-10-27 07:13, Albin Stigö wrote:
>>> > > Hi Barry,
>>> > > Some thoughts:
>>> > > You have a large DC spike at the center, try using the frequency
>>> > > xlating
>>> > > fir filter to tune an offset frequency.
>>> > > Why don't you decimate at the channel filter?
>>> > > Try observing the signal at various points using the frequency
>>> > > sink.
>>> > > Good luck,
>>> > > Albin SM6WJM
>>> > > On Sat, Oct 26, 2019, 21:02 Barry Duggan 
>>> > > wrote:
>>> > > > Hi,
>>> > > > I've been working on a gnuradio AM broadcast receiver, and have
>>> > > > found
>>> > > > that the tuning is very critical to obtaining clear audio. My
>>> > > > flowgraph
>>> > > > can be seen at
>>> > > > https://wiki.gnuradio.org/index.php/File:FunCube_AM.png.
>>> > > > Are there any alternate demodulation methods which are not so
>>> > > > sensitive
>>> > > > to exact tuning?
>>> > > > Thanks,
>>> > > > --
>>> > > > Barry Duggan KV4FV

Re: AM demodulation

[Markus Heller]

Dear OMs,

I guess this carrier tracking block would be useful to handle frequency
drift of cheap (unstabilized) devices, when working QO-100 satellite
connections. This block could be used to find the band end beacons and
derive the frequency shift and correct it accordingly. Right?

vy73
markus
dl8rds

Am Montag, den 28.10.2019, 09:44 -0500 schrieb Bill Dailey:
> Can you give a little primer on using that PLL tracking?I would
> love to use that to just track carriers random frequencies.  For
> instance 10mhz.  Ultimately I want to track and periodically log and
> offset from true predicted frequency. Like every 10 seconds.
> 
> Bill Dailey
> 
> Negativity always wins the short game. But positivity wins the long
> game. - Gary Vaynerchuk
> 
> Don’t be easy to understand, 
> Be impossible to misunderstand 
> - Steve Sims
> 
> > On Oct 28, 2019, at 9:27 AM, Barry Duggan 
> > wrote:
> > 
> > Hi Albin and Volker,
> > 
> > I added a PLL Carrier Tracking block to take care of the tuning
> > problem. See the revised 
> > https://wiki.gnuradio.org/index.php/File:FunCube_AM.png
> > 
> > Albin, that 'spike' is the carrier! This is AM ;)
> > 
> > Thank you both for your suggestions.
> > ---
> > Barry Duggan KV4FV
> > 
> > 
> > On 2019-10-27 07:13, Albin Stigö wrote:
> > > Hi Barry,
> > > Some thoughts:
> > > You have a large DC spike at the center, try using the frequency
> > > xlating
> > > fir filter to tune an offset frequency.
> > > Why don't you decimate at the channel filter?
> > > Try observing the signal at various points using the frequency
> > > sink.
> > > Good luck,
> > > Albin SM6WJM
> > > On Sat, Oct 26, 2019, 21:02 Barry Duggan 
> > > wrote:
> > > > Hi,
> > > > I've been working on a gnuradio AM broadcast receiver, and have
> > > > found
> > > > that the tuning is very critical to obtaining clear audio. My
> > > > flowgraph
> > > > can be seen at 
> > > > https://wiki.gnuradio.org/index.php/File:FunCube_AM.png.
> > > > Are there any alternate demodulation methods which are not so
> > > > sensitive
> > > > to exact tuning?
> > > > Thanks,
> > > > --
> > > > Barry Duggan KV4FV

Re: AM demodulation

[Barry Duggan]

Hi Bill,

Look at https://wiki.gnuradio.org/index.php/PLL_Carrier_Tracking. I 
think I will add this formula to the Notes: radians per sample = 2 * pi 
* freq / sample rate


I don't know how wide a spectrum the PLL can handle.

I am working on the documentation of blocks, so let me know if there is 
anything I need to add or clarify.


Cheers!
---
Barry Duggan KV4FV

P.S. I like the quote by Steve Sims :)

On 2019-10-28 10:44, Bill Dailey wrote:

Can you give a little primer on using that PLL tracking?I would
love to use that to just track carriers random frequencies.  For
instance 10mhz.  Ultimately I want to track and periodically log and
offset from true predicted frequency. Like every 10 seconds.

Bill Dailey

Negativity always wins the short game. But positivity wins the long
game. - Gary Vaynerchuk

Don’t be easy to understand,
Be impossible to misunderstand
- Steve Sims


On Oct 28, 2019, at 9:27 AM, Barry Duggan  wrote:

Hi Albin and Volker,

I added a PLL Carrier Tracking block to take care of the tuning 
problem. See the revised 
https://wiki.gnuradio.org/index.php/File:FunCube_AM.png


Albin, that 'spike' is the carrier! This is AM ;)

Thank you both for your suggestions.
---
Barry Duggan KV4FV



On 2019-10-27 07:13, Albin Stigö wrote:
Hi Barry,
Some thoughts:
You have a large DC spike at the center, try using the frequency 
xlating

fir filter to tune an offset frequency.
Why don't you decimate at the channel filter?
Try observing the signal at various points using the frequency sink.
Good luck,
Albin SM6WJM

On Sat, Oct 26, 2019, 21:02 Barry Duggan  wrote:
Hi,
I've been working on a gnuradio AM broadcast receiver, and have 
found
that the tuning is very critical to obtaining clear audio. My 
flowgraph
can be seen at 
https://wiki.gnuradio.org/index.php/File:FunCube_AM.png.
Are there any alternate demodulation methods which are not so 
sensitive

to exact tuning?
Thanks,
--
Barry Duggan KV4FV

Re: Latency out of Stream Mux block with unequal input lengths

[Michael Dickens]

Hi Adam - Check out this presentation from GRCon19 <
https://www.gnuradio.org/grcon/grcon19/presentations/managing_latency/ >.
The basic issue is that the FIFO buffer between the source and next block
will fill up with data, so any change to the source value will be at the
end of the FIFO & require all of the data in the buffer to be read out
before that value comes up. The FIFO buffer with 50 items will be updated
more quickly ... as in 49:1 more quickly! Hope this is useful! - MLD

On Mon, Oct 28, 2019 at 9:49 AM Gannon, Adam M. (GRC-LCI0) <
adam.gan...@nasa.gov> wrote:

> Hi List,
>
> I'm trying to understand the latency behavior of the Stream Mux block when
> two streams of unequal lengths are being multiplexed together. Attached is
> a minimal flow graph that illustrates the point.
>
> In the example, two streams are multiplexed: one Vector Source of length
> 50 and one of length 1 whose value is adjusted while running. It takes
> several seconds at 1Msps for the change in the value of the shorter (L=1)
> stream to be reflected in the muxed stream. The reverse is not true - a
> change in the longer stream (L=50) is immediately reflected in the muxed
> stream. I believe this is because both Vector Sources are producing samples
> at the same rate but are being muxed at a ratio of 50:1. So when the value
> of the L=1 stream changes it has to empty the existing samples from its
> output buffer before the new samples start to be muxed.
>
> In my application, I am formatting data from an external source into the
> header of my packet. There are several stream multiplexers after that to
> form the packet (adding payload, trailer, etc). I'd like to minimize the
> latency before new data is reflected in the entire formatted packet. I was
> considering writing one block to create the entire packet, but wanted to
> ask for advice on if there is a better / more modular solution.
>
>
> Much appreciated,
> Adam
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/

Re: AM demodulation

[Bill Dailey]

Can you give a little primer on using that PLL tracking?I would love to use 
that to just track carriers random frequencies.  For instance 10mhz.  
Ultimately I want to track and periodically log and offset from true predicted 
frequency. Like every 10 seconds.

Bill Dailey

Negativity always wins the short game. But positivity wins the long game. - 
Gary Vaynerchuk

Don’t be easy to understand, 
Be impossible to misunderstand 
- Steve Sims

> On Oct 28, 2019, at 9:27 AM, Barry Duggan  wrote:
> 
> Hi Albin and Volker,
> 
> I added a PLL Carrier Tracking block to take care of the tuning problem. See 
> the revised https://wiki.gnuradio.org/index.php/File:FunCube_AM.png
> 
> Albin, that 'spike' is the carrier! This is AM ;)
> 
> Thank you both for your suggestions.
> ---
> Barry Duggan KV4FV
> 
> 
>> On 2019-10-27 07:13, Albin Stigö wrote:
>> Hi Barry,
>> Some thoughts:
>> You have a large DC spike at the center, try using the frequency xlating
>> fir filter to tune an offset frequency.
>> Why don't you decimate at the channel filter?
>> Try observing the signal at various points using the frequency sink.
>> Good luck,
>> Albin SM6WJM
>>> On Sat, Oct 26, 2019, 21:02 Barry Duggan  wrote:
>>> Hi,
>>> I've been working on a gnuradio AM broadcast receiver, and have found
>>> that the tuning is very critical to obtaining clear audio. My flowgraph
>>> can be seen at https://wiki.gnuradio.org/index.php/File:FunCube_AM.png.
>>> Are there any alternate demodulation methods which are not so sensitive
>>> to exact tuning?
>>> Thanks,
>>> --
>>> Barry Duggan KV4FV
> 

Re: AM demodulation

[Barry Duggan]

Hi Albin and Volker,

I added a PLL Carrier Tracking block to take care of the tuning problem. 
See the revised https://wiki.gnuradio.org/index.php/File:FunCube_AM.png


Albin, that 'spike' is the carrier! This is AM ;)

Thank you both for your suggestions.
---
Barry Duggan KV4FV


On 2019-10-27 07:13, Albin Stigö wrote:

Hi Barry,

Some thoughts:

You have a large DC spike at the center, try using the frequency 
xlating

fir filter to tune an offset frequency.

Why don't you decimate at the channel filter?

Try observing the signal at various points using the frequency sink.

Good luck,
Albin SM6WJM

On Sat, Oct 26, 2019, 21:02 Barry Duggan  wrote:


Hi,

I've been working on a gnuradio AM broadcast receiver, and have found
that the tuning is very critical to obtaining clear audio. My 
flowgraph
can be seen at 
https://wiki.gnuradio.org/index.php/File:FunCube_AM.png.
Are there any alternate demodulation methods which are not so 
sensitive

to exact tuning?

Thanks,
--
Barry Duggan KV4FV

Latency out of Stream Mux block with unequal input lengths

[Gannon, Adam M. (GRC-LCI0)]

Hi List,

I'm trying to understand the latency behavior of the Stream Mux block when two 
streams of unequal lengths are being multiplexed together. Attached is a 
minimal flow graph that illustrates the point. 

In the example, two streams are multiplexed: one Vector Source of length 50 and 
one of length 1 whose value is adjusted while running. It takes several seconds 
at 1Msps for the change in the value of the shorter (L=1) stream to be 
reflected in the muxed stream. The reverse is not true - a change in the longer 
stream (L=50) is immediately reflected in the muxed stream. I believe this is 
because both Vector Sources are producing samples at the same rate but are 
being muxed at a ratio of 50:1. So when the value of the L=1 stream changes it 
has to empty the existing samples from its output buffer before the new samples 
start to be muxed. 

In my application, I am formatting data from an external source into the header 
of my packet. There are several stream multiplexers after that to form the 
packet (adding payload, trailer, etc). I'd like to minimize the latency before 
new data is reflected in the entire formatted packet. I was considering writing 
one block to create the entire packet, but wanted to ask for advice on if there 
is a better / more modular solution. 


Much appreciated, 
Adam


latency_test.grc
Description: latency_test.grc

Re: [Discuss-gnuradio] Packet transmission questions from a newb

[sumit kumar]

" but my wi-fi packet receiver works just dandy without any OFDM blocks"
--> Can you check the standard which your wifi receiver is following ? If
it is 802.11b, then it wont work with gr-ieee 80211 because gr-ieee 80211
is based on OFDM based WiFi.

You cannot use .pcap file as file source for the wifi_tx.grc.

May I know your final aim for this experiment so that I can put my
suggestions ?

Regards
Sumit

On Sun, 27 Oct 2019 at 20:10, Eamon Heaney  wrote:

> Hi,
>
> I'm trying to create a wi-fi transmitter in GNURadio that can take a file
> source and transmit it as an 802.11 packet. I'm using this
> 
> example as a basis, and trying to follow the guides here
> .
>
> Frankly, though, a lot of what's in that guide goes way over my head. I
> have a general understanding of what OFDM is, but my wi-fi packet receiver
> works just dandy without any OFDM blocks. So is it still necessary to
> incorporate such blocks into a transmitter?
>
> Secondly, I can't just plug a .pcap file source into the transmitter; it
> doesn't generate, and I get the feeling that .pcap isn't the proper format
> for transmission anyways. How can I figure out which blocks to put after
> the file source to make it gel with the next block in the example (WiFi
> MAC)?
>
> Thanks!
>
> --
> Eamon Heaney
> *Fleet Commander*
> *President, Model UN at Virginia Tech*
>


-- 
Sumit Kumar