Re: SDR transceiver having independent mixer and ADC sampling clocks
On Wed, Feb 26, 2020 at 4:23 PM Heikki Laamanen wrote: > > So you want to produce something like a stable 10MHz reference and a > 1PPS which is synchronous to UTC using broadcast/terrestrial signals such > as DVB-T, ATSC, LTE, etc? And your edges can be within +/-50ns of actual > UTC? > > > > Yes. All those signals (not sure about ATSC) are synchronized to UTC > directly (via GPS) or indirectly (via PTP over fiber). Thus, the signals > carry inherent timing information. There are naturally lots of issues > related with radio wave propagation in each case like multipath propagation > caused by reflections, groundwave/skywave phenomena concerning LF radio > wave propagation, e.g. DCF-77 and the ancient C-Loran. The most ideal cases > are line-of-sight wave paths like GPS satellite – GPS receiver. > > > > I have one more question. I have not found any GNU Radio object utilizing > the possibility of controlling the ADC sampling frequency via controllable > PLLs on the RF HW. All sync-related objects seem to use – e.g., polyphase > filters, for adjusting sampling phase. Am I right? > Some radios use a DAC to control a VCTCXO with a pullability of maybe +/-10ppm. Others use an analog PLL to lock to an externally supplied reference (like 10MHz or so). Most would probably want to keep jitter to a minimum and track the sampling offset digitally. You may want to look into what it might take to do that instead of expecting a clock to be perfect. Brian
Re: How ensure consistency with timing signals
On 02/26/2020 04:11 PM, Lukas Haase wrote: Hi Marcus, Good point; but this is just for demonstration purposes here. I can tie it to USRP Source/Sink. The delta (measured in samples) should still be consistent, no matter what. Best, Lukas Looking at the siggen code, this is probably equivalent to phase-noise in the generator. The square wave outputs are derived from COS/SIN, and at such a high ratio between sample rate and frequency, there'll be a bit of phase noise. Someone with more knowledge of the siggen block can comment further.
RE: SDR transceiver having independent mixer and ADC sampling clocks
> So you want to produce something like a stable 10MHz reference and a 1PPS > which is synchronous to UTC using broadcast/terrestrial signals such as > DVB-T, ATSC, LTE, etc? And your edges can be within +/-50ns of actual UTC? Yes. All those signals (not sure about ATSC) are synchronized to UTC directly (via GPS) or indirectly (via PTP over fiber). Thus, the signals carry inherent timing information. There are naturally lots of issues related with radio wave propagation in each case like multipath propagation caused by reflections, groundwave/skywave phenomena concerning LF radio wave propagation, e.g. DCF-77 and the ancient C-Loran. The most ideal cases are line-of-sight wave paths like GPS satellite – GPS receiver. I have one more question. I have not found any GNU Radio object utilizing the possibility of controlling the ADC sampling frequency via controllable PLLs on the RF HW. All sync-related objects seem to use – e.g., polyphase filters, for adjusting sampling phase. Am I right? Heikki From: Brian Padalino Sent: 25. helmikuutata 2020 21:37 To: Heikki Laamanen Cc: GNURadio Discussion List Subject: Re: SDR transceiver having independent mixer and ADC sampling clocks On Tue, Feb 25, 2020 at 2:00 PM Heikki Laamanen mailto:heikki.laama...@dlc.fi> > wrote: Thanks Brian. You are right, there exists three VCOs and PLLs in the AD9361 which can be controlled independently. AD9361 Reference Manual UG-570 shows a more detailed diagram in Figure 7. on page 20. The baseband PLL comprises an N/N+1 divider controlled by a high-precision sigma-delta modulator. AD9361 Register Map Reference Manual UG-671 describes that the control word of the sigma-delta modulator consists of 29 bits giving a relative frequency resolution of 1.9 ppb (parts per billion). A brief description of the timing system. The objective is a system for protecting or replacing GPS-based timing. In addition to navigation, the GPS system is used for generating an accurate clock which is in synchronism with the Coordinated Universal Time (UTC). A clock synchronized with the UTC, can be for example a 1 Hz physical clock signal whose rising edge goes up exactly at the start of an UTC second. The accuracy of an GPS-based timing system is about +-50 ns. Thus, we can say that the phase accuracy of GPS-based timing is about 50 ns. The objective is to generate such clock by receiving a broadcast radio signal which is known to be in synchronism with the UTC. You mentioned that time is completely relative. If we think of the UTC, we could say that it gives an absolute time which is defined by several atomic clocks around the globe. A copy of the UTC can be generated, with a certain accuracy, by receiving the GPS or other similar satellite signal (Galileo, Glonass, Beidou) and synchronizing to it. So you want to produce something like a stable 10MHz reference and a 1PPS which is synchronous to UTC using broadcast/terrestrial signals such as DVB-T, ATSC, LTE, etc? And your edges can be within +/-50ns of actual UTC? I guess I'm still unsure if you do or do not believe the radios out there allow for this to happen? I'm not sure where you believe you have a limitation. Brian
Re: How ensure consistency with timing signals
Hi Marcus,
Good point; but this is just for demonstration purposes here. I can tie it to
USRP Source/Sink.
The delta (measured in samples) should still be consistent, no matter what.
Best, Lukas
> Gesendet: Mittwoch, 26. Februar 2020 um 15:25 Uhr
> Von: "Marcus D Leech"
> An: "Lukas Haase"
> Cc: "discuss-gnuradio@gnu.org"
> Betreff: Re: How ensure consistency with timing signals
>
> Something to understand about the throttle block is that it doesn’t guarantee
> a precise sample rate. Just that the long term average rate is what you
> expect.
>
> Sent from my iPhone
>
> > On Feb 26, 2020, at 12:09 PM, Lukas Haase wrote:
> >
> > Hello,
> >
> > I use a square wave to generate control/clocking signal for some control
> > logic:
> >
> > https://snipboard.io/WQ8p6d.jpg
> >
> > The work function of the "Controller" block looks like:
> >
> >def work(self, input_items, output_items):
> >d = np.diff(input_items[0])
> >inds = np.where(d == 1)
> >for ind in inds[0]:
> >nedge = self.nitems_read(0) + ind
> >delta = nedge - self.nedge_prev
> >print("EDGE @ " + str(nedge) + ", Delta=" + str(delta))
> >self.nedge_prev = nedge
> >return len(output_items[0])
> >
> > I.e., it detects the rising edge. The code above stores the previous edge
> > and shows the delta between them.
> > If the frequency of the square wave exactly divides the sampling rate, I
> > would expect that this delta is always constant/consistent (and I need this
> > for my application).
> >
> > However, with samp_rate=5M and freq=10:
> >
> > EDGE @ 10751169, Delta=500054
> > EDGE @ 11251224, Delta=500055
> > EDGE @ 11751278, Delta=500054
> > EDGE @ 12251332, Delta=500054
> > EDGE @ 12751387, Delta=500055
> > EDGE @ 13251441, Delta=500054
> > EDGE @ 13751496, Delta=500055
> > EDGE @ 14251550, Delta=500054
> >
> > One interval is not only not always constant but is 54/55 samples larger
> > than the expected 50.
> > When making the interval small (e.g., samp_rate=5M, freq=1k, it works:
> >
> > EDGE @ 65072534, Delta=5000
> > EDGE @ 65077534, Delta=5000
> > EDGE @ 65082534, Delta=5000
> > EDGE @ 65087534, Delta=5000
> > EDGE @ 65092534, Delta=5000
> > EDGE @ 65097534, Delta=5000
> > EDGE @ 65102534, Delta=5000
> >
> > I tried tried offsetting the frequency by a slight but but no change. E.g.,
> > freq = 1.0 / (1.0/10 - 1.0/samp_rate)
> >
> > I know I could implement a logic that adds a constant directly in the work
> > function but to keep things manageable I would really prefer to use clock
> > signals (there will be a bunch of them floating around in the end).
> >
> >
> > Thanks,
> > Lukas
> >
> >
> >
> >
>
Re: How ensure consistency with timing signals
Something to understand about the throttle block is that it doesn’t guarantee a
precise sample rate. Just that the long term average rate is what you expect.
Sent from my iPhone
> On Feb 26, 2020, at 12:09 PM, Lukas Haase wrote:
>
> Hello,
>
> I use a square wave to generate control/clocking signal for some control
> logic:
>
> https://snipboard.io/WQ8p6d.jpg
>
> The work function of the "Controller" block looks like:
>
>def work(self, input_items, output_items):
>d = np.diff(input_items[0])
>inds = np.where(d == 1)
>for ind in inds[0]:
>nedge = self.nitems_read(0) + ind
>delta = nedge - self.nedge_prev
>print("EDGE @ " + str(nedge) + ", Delta=" + str(delta))
>self.nedge_prev = nedge
>return len(output_items[0])
>
> I.e., it detects the rising edge. The code above stores the previous edge and
> shows the delta between them.
> If the frequency of the square wave exactly divides the sampling rate, I
> would expect that this delta is always constant/consistent (and I need this
> for my application).
>
> However, with samp_rate=5M and freq=10:
>
> EDGE @ 10751169, Delta=500054
> EDGE @ 11251224, Delta=500055
> EDGE @ 11751278, Delta=500054
> EDGE @ 12251332, Delta=500054
> EDGE @ 12751387, Delta=500055
> EDGE @ 13251441, Delta=500054
> EDGE @ 13751496, Delta=500055
> EDGE @ 14251550, Delta=500054
>
> One interval is not only not always constant but is 54/55 samples larger than
> the expected 50.
> When making the interval small (e.g., samp_rate=5M, freq=1k, it works:
>
> EDGE @ 65072534, Delta=5000
> EDGE @ 65077534, Delta=5000
> EDGE @ 65082534, Delta=5000
> EDGE @ 65087534, Delta=5000
> EDGE @ 65092534, Delta=5000
> EDGE @ 65097534, Delta=5000
> EDGE @ 65102534, Delta=5000
>
> I tried tried offsetting the frequency by a slight but but no change. E.g.,
> freq = 1.0 / (1.0/10 - 1.0/samp_rate)
>
> I know I could implement a logic that adds a constant directly in the work
> function but to keep things manageable I would really prefer to use clock
> signals (there will be a bunch of them floating around in the end).
>
>
> Thanks,
> Lukas
>
>
>
>
How ensure consistency with timing signals
Hello,
I use a square wave to generate control/clocking signal for some control logic:
https://snipboard.io/WQ8p6d.jpg
The work function of the "Controller" block looks like:
def work(self, input_items, output_items):
d = np.diff(input_items[0])
inds = np.where(d == 1)
for ind in inds[0]:
nedge = self.nitems_read(0) + ind
delta = nedge - self.nedge_prev
print("EDGE @ " + str(nedge) + ", Delta=" + str(delta))
self.nedge_prev = nedge
return len(output_items[0])
I.e., it detects the rising edge. The code above stores the previous edge and
shows the delta between them.
If the frequency of the square wave exactly divides the sampling rate, I would
expect that this delta is always constant/consistent (and I need this for my
application).
However, with samp_rate=5M and freq=10:
EDGE @ 10751169, Delta=500054
EDGE @ 11251224, Delta=500055
EDGE @ 11751278, Delta=500054
EDGE @ 12251332, Delta=500054
EDGE @ 12751387, Delta=500055
EDGE @ 13251441, Delta=500054
EDGE @ 13751496, Delta=500055
EDGE @ 14251550, Delta=500054
One interval is not only not always constant but is 54/55 samples larger than
the expected 50.
When making the interval small (e.g., samp_rate=5M, freq=1k, it works:
EDGE @ 65072534, Delta=5000
EDGE @ 65077534, Delta=5000
EDGE @ 65082534, Delta=5000
EDGE @ 65087534, Delta=5000
EDGE @ 65092534, Delta=5000
EDGE @ 65097534, Delta=5000
EDGE @ 65102534, Delta=5000
I tried tried offsetting the frequency by a slight but but no change. E.g.,
freq = 1.0 / (1.0/10 - 1.0/samp_rate)
I know I could implement a logic that adds a constant directly in the work
function but to keep things manageable I would really prefer to use clock
signals (there will be a bunch of them floating around in the end).
Thanks,
Lukas
Re: gnuradio 3.8 errors with gr_modtool
Thank you very much Josh and Maitland for your quick help, appreciate it. Maitland, I executed the command that you mentioned, and problem solved =D Looking forward now to try the new gnuradio version! Cheers On Wed, Feb 26, 2020 at 7:48 AM Morman, Joshua wrote: > Hi Laura, > > > Thank you for raising this issue. Maitland pinged me offline with the > fixes he did on this issue in the Debian packages which are basically > copied into the PPAs you are using with minor modifications. > > > I have now applied his fixes (and updated the ppa packages to the recent > RC release), so the ppa cleans the byte compiled code from the installation > for Ubuntu >= 19. For Ubuntu 18 the issue still remains. > > > For Ubuntu 18 - navigate to > /usr/share/gnuradio/modtool/templates/gr-newmod/ > > and run > > sudo py3clean . > > > This should clean the files that are causing issue. > > > > Josh > > > -- Forwarded message - > From: *Laura Arjona* > Date: Tue, Feb 25, 2020 at 5:25 PM > Subject: Re: gnuradio 3.8 errors with gr_modtool > To: Maitland Bottoms > Cc: GNURadio Discussion List > > > just in case, I removed the only .pyc file I found under > /usr/share/gnuradio/modtool/templates/gr-newmod/python/__pycache > /usr/share/gnuradio/modtool/templates/gr-newmod/python/__pycache__$ sudo > rm *pyc > > The same error occurs. > > Thank you! > > On Tue, Feb 25, 2020 at 2:17 PM Laura Arjona wrote: > > Thank you Maitland. > Is there a "safer" way of installing gnuradio 3.8? > > Matiland - there is not such a folder in /modtool/gr-newmod. > I only have /usr/share/gnuradio/modtool/template > > On Tue, Feb 25, 2020 at 1:13 PM Maitland Bottoms wrote: > > Laura Arjona writes: > > > 1 - Installed fresh Ubuntu 18.04.4 LTS > > 2- Installed git, cmake, swig, gnuradio. > > To install gnuradio, I used: > > $ sudo add-apt-repository ppa:gnuradio/gnuradio-releases > >$ sudo apt-get update > >$ sudo apt-get install gnuradio > > > At this point you have .pyc files where they do not belong, since as of > just now the ppa packages are still buggy. > > You can > `sudo rm /usr/share/gnuradio/modtool/gr-newmod/python/*pyc` > and get on with life. > > Hopefully the ppa packegs will be fixed soon... > > -Maitland > > > > -- > *Laura Arjona * > Washington Research Foundation Innovation Postdoctoral Fellow in > Neuroengineering > > *Paul G. Allen School of Computer Science & Engineering* > 185 E Stevens Way NE > University of Washington > Seattle, WA 98195-2350 > > > > -- > *Laura Arjona * > Washington Research Foundation Innovation Postdoctoral Fellow in > Neuroengineering > > *Paul G. Allen School of Computer Science & Engineering* > 185 E Stevens Way NE > University of Washington > Seattle, WA 98195-2350 > -- *Laura Arjona * Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering *Paul G. Allen School of Computer Science & Engineering* 185 E Stevens Way NE University of Washington Seattle, WA 98195-2350
Re: gnuradio 3.8 errors with gr_modtool
Hi Laura, Thank you for raising this issue. Maitland pinged me offline with the fixes he did on this issue in the Debian packages which are basically copied into the PPAs you are using with minor modifications. I have now applied his fixes (and updated the ppa packages to the recent RC release), so the ppa cleans the byte compiled code from the installation for Ubuntu >= 19. For Ubuntu 18 the issue still remains. For Ubuntu 18 - navigate to /usr/share/gnuradio/modtool/templates/gr-newmod/ and run sudo py3clean . This should clean the files that are causing issue. Josh -- Forwarded message - From: Laura Arjona mailto:arjo...@uw.edu>> Date: Tue, Feb 25, 2020 at 5:25 PM Subject: Re: gnuradio 3.8 errors with gr_modtool To: Maitland Bottoms mailto:aa...@amrad.org>> Cc: GNURadio Discussion List mailto:discuss-gnuradio@gnu.org>> just in case, I removed the only .pyc file I found under /usr/share/gnuradio/modtool/templates/gr-newmod/python/__pycache /usr/share/gnuradio/modtool/templates/gr-newmod/python/__pycache__$ sudo rm *pyc The same error occurs. Thank you! On Tue, Feb 25, 2020 at 2:17 PM Laura Arjona mailto:arjo...@uw.edu>> wrote: Thank you Maitland. Is there a "safer" way of installing gnuradio 3.8? Matiland - there is not such a folder in /modtool/gr-newmod. I only have /usr/share/gnuradio/modtool/template On Tue, Feb 25, 2020 at 1:13 PM Maitland Bottoms mailto:aa...@amrad.org>> wrote: Laura Arjona mailto:arjo...@uw.edu>> writes: > 1 - Installed fresh Ubuntu 18.04.4 LTS > 2- Installed git, cmake, swig, gnuradio. > To install gnuradio, I used: > $ sudo add-apt-repository ppa:gnuradio/gnuradio-releases >$ sudo apt-get update >$ sudo apt-get install gnuradio > At this point you have .pyc files where they do not belong, since as of just now the ppa packages are still buggy. You can `sudo rm /usr/share/gnuradio/modtool/gr-newmod/python/*pyc` and get on with life. Hopefully the ppa packegs will be fixed soon... -Maitland -- Laura Arjona Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering Paul G. Allen School of Computer Science & Engineering 185 E Stevens Way NE University of Washington Seattle, WA 98195-2350 -- Laura Arjona Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering Paul G. Allen School of Computer Science & Engineering 185 E Stevens Way NE University of Washington Seattle, WA 98195-2350
Re: gr-fosphor on AMD RX 550
Hi Sylvain, It tried the GLFW version but the error is the same, the shaders fail. How did you manage to install OpenCL + amdgpu? I tried that and thought I had succeeded but apparently that's not the case. Cheers PS: Yeah, taking it off the list was an error. On 26.02.20 13:39, Sylvain Munaut wrote: Hi Johannes, I really hoped I could install AMD OpenCL on top of the open driver. How do you do that? I guess, if I install the correct OpenCL + amdgpu version, this should actually work. Yeah, that's what I did ... I use the AMD binary OpenCL stuff, but I continued using the amdgpu driver. It works and look fine. This is part of the output. Oh, so that's interesting. That means the issue is somewhere in the way the OpenGL context is setup by Qt, that's really strange. Can you try the GLFW version of the fosphor GR block ? If I do `./main` without an argument, a window is opened and unresponsive. Yeah, that's expected, it's reading sample data from stdin in that mode. Cheers, Sylvain PS: I re-cc'd the mailing list since taking it off seemed like an error ...
Re: gr-fosphor on AMD RX 550
Hi Johannes, > I really hoped I could install AMD OpenCL on top of the open driver. > How do you do that? I guess, if I install the correct OpenCL + amdgpu > version, this should actually work. Yeah, that's what I did ... I use the AMD binary OpenCL stuff, but I continued using the amdgpu driver. > It works and look fine. This is part of the output. Oh, so that's interesting. That means the issue is somewhere in the way the OpenGL context is setup by Qt, that's really strange. Can you try the GLFW version of the fosphor GR block ? > If I do `./main` without an argument, a window is opened and unresponsive. Yeah, that's expected, it's reading sample data from stdin in that mode. Cheers, Sylvain PS: I re-cc'd the mailing list since taking it off seemed like an error ...
Re: Excess bandwidth in constellation modulator
This is exactly what i was looking for. Thank you so much. On Wed, 26 Feb 2020, 9:22 am Moses Browne Mwakyanjala, wrote: > Hello, > That comes down to baseband signal and passband as shown below. > Traditionally, we only quote positive frequencies. For example, for the > SRRC pulse you mentioned, the baseband signal extends from -Rs(1+alpha)/2 > to +Rs(1+alpha)/2. Thus, we say the baseband bandwidth is Rs(1+alpha)/2. > When transmitting over the air, we have a passband signal which extends > from Fc -Rs(1+alpha)/2 to Fc +Rs(1+alpha)/2 where Fc is the carrier > frequency. In this case, the positive bandwidth is Rs(1+alpha), which is > twice the bandwidth at baseband. As a general rule, passband frequency (the > frequency you transmit over the air) is twice the baseband signal. > Regards, > Moses. > PS- The attached pdf is quite a good introduction to gnuradio and signal > processing basics. > [image: image.png] > > On Wed, Feb 26, 2020 at 5:09 AM Md. Atiqur Rahman > wrote: > >> Thank you for your reply with the details. >> I do already read from the GNU Radio tutorial but wasn't fully sure. >> The equation now clear, just want to make sure one point from you. >> After the modulation(e.g qpsk) signal upconverted to RF, then the signal >> bandwidth still will be the same? >> >> Thank you again. >> >> >> On Wed, Feb 26, 2020 at 12:31 AM Moses Browne Mwakyanjala < >> mbkit...@gmail.com> wrote: >> >>> I saw your post on the gnuradio mailing list. >>> The constellation modulator block uses a Square-Root Raised-Cosine >>> filter with occupied bandwidth (double-sided a.k.a passband) given by BW = >>> (1 + alpha)Rs, where Rs is the symbol rate. The bit rate for M-ary linear >>> modulation is given by Bit Rate = Rs*Log(M)base2. Thus, for BPSK you will >>> achieve Bit Rate = Rs, and for QPSK it will be Bit Rate = 2 * Rs. >>> The transmission over-the-air is called passband, which for the SRRC >>> filter is given as described above. >>> You could read more on the SRRC filter from this Wikipedia article: >>> https://en.wikipedia.org/wiki/Root-raised-cosine_filter >>> You could get more information here: >>> https://wiki.gnuradio.org/index.php/Tutorials >>> >>> Good luck. >>> >>> >> >> -- >> Sincerely, >> Md Atiqur Rahman >> >>
