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 <barry@dcsmail.net>
>> > 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 <barry@dcsmail.net>
>> > > 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
Read the mailing list of the GNU project right here! The information here is regarding the GNU radio project for USRP radios.
Monday, October 28, 2019
Re: AM demodulation
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 <barry@dcsmail.net>
> > 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 <barry@dcsmail.net>
> > > 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
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 <barry@dcsmail.net>
> > 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 <barry@dcsmail.net>
> > > 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
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 <barry@dcsmail.net> 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 <barry@dcsmail.net> 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
>>
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 <barry@dcsmail.net> 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 <barry@dcsmail.net> 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
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.gannon@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
Re: AM demodulation
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 <barry@dcsmail.net> 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 xlatingfir 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 SM6WJMOn Sat, Oct 26, 2019, 21:02 Barry Duggan <barry@dcsmail.net> wrote:Hi,I've been working on a gnuradio AM broadcast receiver, and have foundthat the tuning is very critical to obtaining clear audio. My flowgraphcan be seen at https://wiki.gnuradio.org/index.php/File:FunCube_AM.png.Are there any alternate demodulation methods which are not so sensitiveto exact tuning?Thanks,--Barry Duggan KV4FV
Re: AM demodulation
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 <barry@dcsmail.net> 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
>>
>>
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 <barry@dcsmail.net> 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
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
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
Subscribe to:
Posts (Atom)