Adding C++ Code generation support for c++ implemented blocks

[Martin Hübner]

Dear GNU Radio Community,

for a university project we want to use GNU Radio / gr-satellites to 
decode some signals of S-NET satellites. The goal for this semester will 
be, to provide a software that enables easy communication with them for 
HAMs, either by using traditional transceiver or SDR.


As the software will potentially be used by a broad group of differently 
experienced persons, we want to keep the deployment as easy as possible: 
A single statically linked binary would be ideal.


We already managed to setup a receiving pipeline in GRC like shown by 
DK3WN and EA4GPZ here:
https://www.dk3wn.info/wp/satelliten/s-net/ (GRC-Screenshot quite 
below). Next, we want to try to invert the flowgraph, to tackle signal 
generation and later on transmission too.


Unfortunately there are 4 blocks in the flowgraph, that don't support 
C++ code generation:


- Frequency Xlating FIR Filter
- Quadrature Demod
- Sync and create PDU
- S-NET deframer

For the first two blocks, it looks like they are implemented completely 
in C++. So I hoped adding support for them would be rather easy. I 
oriented for that on Håkon Vågsether work done here:

https://github.com/haakov/gnuradio/commit/18cbe62c27c3dc8006b707a172da80300e2adfa8

Similarily, the C++ support for the rather easy quadrature demod block 
should look like this then, right?

https://github.com/Akira25/gnuradio/tree/add\_cpp\_generation-quadmod

We would love to upstream these changes too, if you find them useful.

Kind regards,

Martin

Re: Adding C++ Code generation support for c++ implemented blocks

[Marcus Müller]

Hey Martin,

welcome to the community :)
As you can imagine, with the GNU Radio project, code contributions are always welcome, 
especially when it comes to adding code generation for existing blocks written in C++. I'm 
pretty optimistic Daniel feels the same way about gr-satellites.


The S-NET flowgraph screenshot is already a bit older, it still uses GNU Radio 3.7, but 
with the symbol sync block, it might be quite straightforward to port it (Clock Recovery 
MM has been deprecated; you can use Symbol Sync with a Mueller and Müller TED instead). 
You need modern GNU Radio, because on 3.7, C++ generation was not there, and also, the 
more modern the GNU Radio, the more blocks already come with C++ generation definitions.


I do have one piece of bad news for you, though: Many (most, I think) blocks in 
gr-satellites, such as the S-NET deframer, are Python blocks. So, the thing that's missing 
for creating C++ flowgraphs out of these is not only the definition of how the C++ code 
needed to instantiate them looks like, but also: a C++ implementation!


And that is where it gets hairy: I don't think it's overly complicated to re-implement 
snet_deframer.py from gr-satellites in C++. The question is whether you *should*, on two 
levels: first, that's an effort you'd be doing to recreate something that already exists, 
and second, you should probably really work with upstream (so, Daniel) on whether he would 
prefer your C++ implementation (he positively might! It's going to faster, especially 
since you'll be implementing the BCH decodder in C++) or his Python implementation (which 
is going to be easier to read and maintain, probably). The thing with upstreaming is that 
you're giving someone your code to take care of, and that's a bit like giving away free 
puppies: A great gesture, but comes with some work.


In this light, I'd recommend you go through each block in the flowgraphs / applications 
you want to use and consider whether it's worth going through the porting effort to avoid 
having to package Python.


There's an alternative to having to package Python yourself, and all the libraries (which 
are quite a few) that (the used subset of the in-tree modules of) GNU Radio + 
gr-satellites would use:
Make sure the conda recipes work flawlessly for the software you want to ship, and build a 
conda installer akin to Ryan's radioconda for that specific application. I guess you're 
mostly targeting Windows there – making a nice installer should not be impossible, but I 
don't have any personal experience with it. That would have the added benefit that, if you 
decide that you want your target audience to also have access to truly unportable 
Python-only software like GRC, you could, at nearly no development cost, add that.


Either way, what you set out to do is truly remarkable and I'm happy you're 
tackling it!

Best,
Marcus


On 18.05.23 11:25, Martin Hübner wrote:

Similarily, the C++ support for the rather easy quadrature demod block should look like 
this then, right?

https://github.com/Akira25/gnuradio/tree/add\_cpp\_generation-quadmod


That link's private, but if you want us to have a look at it, why don't you open a pull 
request against gnuradio/gnuradio? You can mark it as "Draft" and write a nice comment 
what it signifies, and maybe even link to your message in the discuss-gnuradio mailing 
list archives.

USRP X300 Synchronization

[Hamed Al-Zubi]

Hello Dears,

 I would like to inquire about the synchronization of two USRPs X300, one 
acting as a transmitter (Tx) and the other as a receiver (Rx). If both USRPs 
are connected to the same laptop, I'm wondering if the accuracy provided by PC 
clock synchronization is similar (or close) to that achieved through GPSDO 
synchronization?

Regards,
HZ

Re: USRP X300 Synchronization

[Marcus Müller]

No, it's several orders of magnitude worse and generally insufficient for anything where 
you need synchronization.


Best,
Marcus

On 18.05.23 17:12, Hamed Al-Zubi wrote:

Hello Dears,

I would like to inquire about the synchronization of two USRPs X300, one acting as a 
transmitter (Tx) and the other as a receiver (Rx). If both USRPs are connected to the 
same laptop, I'm wondering if the accuracy provided by PC clock synchronization is 
similar (or close) to that achieved through GPSDO synchronization?


Regards,
HZ

Re: USRP X300 Synchronization

[Hamed Al-Zubi]

 Thanks for your response, Marcus!
I have observed a constellation rotation for OFDM subcarriers when I use the PC 
clock for synchronization. However, by using the channel model, I am able to 
see the QPSK constellation. 
Thanks!HZ
On Thursday, May 18, 2023 at 10:35:01 AM CDT, Marcus Müller 
 wrote:  
 
  
No, it's several orders of magnitude worse and generally insufficient for 
anything where you need synchronization.
 
Best,
 Marcus
 
 On 18.05.23 17:12, Hamed Al-Zubi wrote:
  
 
 Hello Dears,
 
 I would like to inquire about the synchronization of two USRPs X300, one 
acting as a transmitter (Tx) and the other as a receiver (Rx). If both USRPs 
are connected to the same laptop, I'm wondering if the accuracy provided by PC 
clock synchronization is similar (or close) to that achieved through GPSDO 
synchronization?
 
 Regards,
 HZ

Re: USRP X300 Synchronization

[Marcus Müller]

Any OFDM receiver needs a timing recovery method anyways, so that has nothing to do with 
how well your PC is suitable for synchronizing two devices.



On 18.05.23 17:43, Hamed Al-Zubi wrote:

Thanks for your response, Marcus!
I have observed a constellation rotation for OFDM subcarriers when I use the PC clock for 
synchronization. However, by using the channel model, I am able to see the QPSK 
constellation.


Thanks!
HZ

On Thursday, May 18, 2023 at 10:35:01 AM CDT, Marcus Müller 
 wrote:


No, it's several orders of magnitude worse and generally insufficient for anything where 
you need synchronization.


Best,
Marcus

On 18.05.23 17:12, Hamed Al-Zubi wrote:
Hello Dears,

I would like to inquire about the synchronization of two USRPs X300, one acting as a 
transmitter (Tx) and the other as a receiver (Rx). If both USRPs are connected to the same 
laptop, I'm wondering if the accuracy provided by PC clock synchronization is similar (or 
close) to that achieved through GPSDO synchronization?


Regards,
HZ

Convolutional Codes

[Mehrad Mehrabi]

Hi,

I'm totally new to GNU radio software. I was looking for some tutorials for
the implementation of convolutional codes and the Viterbi decoder, but I
didn't find any. I would appreciate it if someone guides me.

Re: Convolutional Codes

[Marcus Müller]

Hi Mehrad,

can you elaborate what you need a tutorial on, specifically? The way your question sounds, 
it's that you need to understand generally how CCs and Viterbi works, and less how GNU 
Radio's implementations do. But I could be wrong!


Best,
Marcus

On 18.05.23 17:45, Mehrad Mehrabi wrote:

Hi,

I'm totally new to GNU radio software. I was looking for some tutorials for the 
implementation of convolutional codes and the Viterbi decoder, but I didn't find any. I 
would appreciate it if someone guides me.

Re: USRP X300 Synchronization

[Hamed Al-Zubi]

 Actually, I don't know. I thought that by using PC clock in UHD sink and 
source block in gnuradio allows synchronization. 
Also, I thought that Schmidl and Cox algorithm used for timing recovery in OFDM 
receivers.
On Thursday, May 18, 2023 at 10:46:38 AM CDT, Marcus Müller 
 wrote:  
 
 Any OFDM receiver needs a timing recovery method anyways, so that has nothing 
to do with 
how well your PC is suitable for synchronizing two devices.


On 18.05.23 17:43, Hamed Al-Zubi wrote:
> Thanks for your response, Marcus!
> I have observed a constellation rotation for OFDM subcarriers when I use the 
> PC clock for 
> synchronization. However, by using the channel model, I am able to see the 
> QPSK 
> constellation.
> 
> Thanks!
> HZ
> 
> On Thursday, May 18, 2023 at 10:35:01 AM CDT, Marcus Müller 
>  wrote:
> 
> 
> No, it's several orders of magnitude worse and generally insufficient for 
> anything where 
> you need synchronization.
> 
> Best,
> Marcus
> 
> On 18.05.23 17:12, Hamed Al-Zubi wrote:
> Hello Dears,
> 
> I would like to inquire about the synchronization of two USRPs X300, one 
> acting as a 
> transmitter (Tx) and the other as a receiver (Rx). If both USRPs are 
> connected to the same 
> laptop, I'm wondering if the accuracy provided by PC clock synchronization is 
> similar (or 
> close) to that achieved through GPSDO synchronization?
> 
> Regards,
> HZ

  

Re: USRP X300 Synchronization

[Marcus Müller]

On 18.05.23 18:10, Hamed Al-Zubi wrote:
Actually, I don't know. I thought that by using PC clock in UHD sink and source block in 
gnuradio allows synchronization.

Not in a way meaningful for synchronizing transceivers, no.

Also, I thought that Schmidl and Cox algorithm used for timing recovery in OFDM 
receivers.
Exactly, that's why your PC clock synchronization would contribute nothing, even if it was 
more accurate. You just don't benefit from synchronization.


On Thursday, May 18, 2023 at 10:46:38 AM CDT, Marcus Müller 
 wrote:


Any OFDM receiver needs a timing recovery method anyways, so that has nothing 
to do with
how well your PC is suitable for synchronizing two devices.


On 18.05.23 17:43, Hamed Al-Zubi wrote:
> Thanks for your response, Marcus!
> I have observed a constellation rotation for OFDM subcarriers when I use the 
PC clock for
> synchronization. However, by using the channel model, I am able to see the 
QPSK
> constellation.
>
> Thanks!
> HZ
>
> On Thursday, May 18, 2023 at 10:35:01 AM CDT, Marcus Müller  
wrote:

>
>
> No, it's several orders of magnitude worse and generally insufficient for 
anything where
> you need synchronization.
>
> Best,
> Marcus
>
> On 18.05.23 17:12, Hamed Al-Zubi wrote:
> Hello Dears,
>
> I would like to inquire about the synchronization of two USRPs X300, one 
acting as a
> transmitter (Tx) and the other as a receiver (Rx). If both USRPs are connected to the 
same

> laptop, I'm wondering if the accuracy provided by PC clock synchronization is 
similar (or
> close) to that achieved through GPSDO synchronization?
>
> Regards,
> HZ

Re: USRP X300 Synchronization

[Hamed Al-Zubi]

 So, I have to get GPS modules and use GPSDO synchronization. 


On Thursday, May 18, 2023 at 11:20:02 AM CDT, Marcus Müller 
 wrote:  
 
   
 On 18.05.23 18:10, Hamed Al-Zubi wrote:
  
  Actually, I don't know. I thought that by using PC clock in UHD sink and 
source block in gnuradio allows synchronization. 
   
 Not in a way meaningful for synchronizing transceivers, no.
 
  Also, I thought that Schmidl and Cox algorithm used for timing recovery in 
OFDM receivers.  
 Exactly, that's why your PC clock synchronization would contribute nothing, 
even if it was more accurate. You just don't benefit from synchronization.
 
  
  On Thursday, May 18, 2023 at 10:46:38 AM CDT, Marcus Müller 
 wrote:  
  
   Any OFDM receiver needs a timing recovery method anyways, so that has 
nothing to do with 
  how well your PC is suitable for synchronizing two devices.
  
  
  On 18.05.23 17:43, Hamed Al-Zubi wrote:
  > Thanks for your response, Marcus!
  > I have observed a constellation rotation for OFDM subcarriers when I use 
the PC clock for 
  > synchronization. However, by using the channel model, I am able to see the 
QPSK 
  > constellation.
  > 
  > Thanks!
  > HZ
  > 
  > On Thursday, May 18, 2023 at 10:35:01 AM CDT, Marcus Müller 
 wrote:
  > 
  > 
  > No, it's several orders of magnitude worse and generally insufficient for 
anything where 
  > you need synchronization.
  > 
  > Best,
  > Marcus
  > 
  > On 18.05.23 17:12, Hamed Al-Zubi wrote:
  > Hello Dears,
  > 
  > I would like to inquire about the synchronization of two USRPs X300, one 
acting as a 
  > transmitter (Tx) and the other as a receiver (Rx). If both USRPs are 
connected to the same 
  > laptop, I'm wondering if the accuracy provided by PC clock synchronization 
is similar (or 
  > close) to that achieved through GPSDO synchronization?
  > 
  > Regards,
  > HZ
  
 
   

BPSK, QPSK image transmission

[andres felipe rodriguez rendon]

Is there any tutorial or does someone have information about how to
transmit an image using GNUradio companion 3.10.5.1, with BPSK, QPSK
modulations?

-- 
*Andrés Felipe Rodríguez *

*Ingeniero Electrónico *
*Universidad del Quindío*
*e-mail: anfer...@gmail.com *
*Móvil: 3167359558*

Re: USRP X300 Synchronization

[Marcus Müller]

No, that's the opposite of what I said. (also, why would you need a GPSDO when these USRPs 
are colocated?)


You *always* have time offset at a receiver – due to the finiteness of the 
speed of light.

So, *any* working receiver you have has to have timing recovery, there's no way around it. 
So, getting better hardware-level synchronization *does not help you at all*. Not if you 
do it badly, not if you do it really really well.


Best,

Marcus

On 18.05.23 18:21, Hamed Al-Zubi wrote:


So, I have to get GPS modules and use GPSDO synchronization.



On Thursday, May 18, 2023 at 11:20:02 AM CDT, Marcus Müller  
wrote:




On 18.05.23 18:10, Hamed Al-Zubi wrote:
Actually, I don't know. I thought that by using PC clock in UHD sink and source block 
in gnuradio allows synchronization.

Not in a way meaningful for synchronizing transceivers, no.

Also, I thought that Schmidl and Cox algorithm used for timing recovery in OFDM 
receivers.
Exactly, that's why your PC clock synchronization would contribute nothing, even if it 
was more accurate. You just don't benefit from synchronization.


On Thursday, May 18, 2023 at 10:46:38 AM CDT, Marcus Müller  
 wrote:



Any OFDM receiver needs a timing recovery method anyways, so that has nothing 
to do with
how well your PC is suitable for synchronizing two devices.


On 18.05.23 17:43, Hamed Al-Zubi wrote:
> Thanks for your response, Marcus!
> I have observed a constellation rotation for OFDM subcarriers when I use the PC clock 
for

> synchronization. However, by using the channel model, I am able to see the 
QPSK
> constellation.
>
> Thanks!
> HZ
>
> On Thursday, May 18, 2023 at 10:35:01 AM CDT, Marcus Müller > wrote:

>
>
> No, it's several orders of magnitude worse and generally insufficient for 
anything where
> you need synchronization.
>
> Best,
> Marcus
>
> On 18.05.23 17:12, Hamed Al-Zubi wrote:
> Hello Dears,
>
> I would like to inquire about the synchronization of two USRPs X300, one 
acting as a
> transmitter (Tx) and the other as a receiver (Rx). If both USRPs are connected to the 
same
> laptop, I'm wondering if the accuracy provided by PC clock synchronization is similar 
(or

> close) to that achieved through GPSDO synchronization?
>
> Regards,
> HZ

Re: BPSK, QPSK image transmission

[Marcus Müller]

Hi Andrés,

https://tutorials.gnuradio.org ; please follow the tutorials from "What is GNU Radio" to 
"Packet Communications".


Best,
Marcus

On 18.05.23 18:37, andres felipe rodriguez rendon wrote:
Is there any tutorial or does someone have information about how to transmit an image 
using GNUradio companion 3.10.5.1, with BPSK, QPSK modulations?


--
*_Andrés Felipe Rodríguez_ *
_
_
_Ingeniero Electrónico _
_Universidad del Quindío_
_e-mail: anfer...@gmail.com _
_Móvil: 3167359558_

Re: USRP X300 Synchronization

[Hamed Al-Zubi]

 Okay. I need to figure out how can I do that. 
Thanks!
HZ
On Thursday, May 18, 2023 at 11:54:42 AM CDT, Marcus Müller 
 wrote:  
 
  
No, that's the opposite of what I said. (also, why would you need a GPSDO when 
these USRPs are colocated?)
 
 
You *always* have time offset at a receiver – due to the finiteness of the 
speed of light. 
 
 
So, *any* working receiver you have has to have timing recovery, there's no way 
around it. So, getting better hardware-level synchronization *does not help you 
at all*. Not if you do it badly, not if you do it really really well.
 
Best,
 
Marcus
 
 
On 18.05.23 18:21, Hamed Al-Zubi wrote:
 
 
 So, I have to get GPS modules and use GPSDO synchronization.  
  
  
  On Thursday, May 18, 2023 at 11:20:02 AM CDT, Marcus Müller 
 wrote:  
  
 
 On 18.05.23 18:10, Hamed Al-Zubi wrote:
  
  Actually, I don't know. I thought that by using PC clock in UHD sink and 
source block in gnuradio allows synchronization. 
   
 Not in a way meaningful for synchronizing transceivers, no.
 
  Also, I thought that Schmidl and Cox algorithm used for timing recovery in 
OFDM receivers.  
 Exactly, that's why your PC clock synchronization would contribute nothing, 
even if it was more accurate. You just don't benefit from synchronization.
 
  
  On Thursday, May 18, 2023 at 10:46:38 AM CDT, Marcus Müller 
 wrote:  
  
   Any OFDM receiver needs a timing recovery method anyways, so that has 
nothing to do with 
  how well your PC is suitable for synchronizing two devices.
  
  
  On 18.05.23 17:43, Hamed Al-Zubi wrote:
  > Thanks for your response, Marcus!
  > I have observed a constellation rotation for OFDM subcarriers when I use 
the PC clock for 
  > synchronization. However, by using the channel model, I am able to see the 
QPSK 
  > constellation.
  > 
  > Thanks!
  > HZ
  > 
  > On Thursday, May 18, 2023 at 10:35:01 AM CDT, Marcus Müller 
 wrote:
  > 
  > 
  > No, it's several orders of magnitude worse and generally insufficient for 
anything where 
  > you need synchronization.
  > 
  > Best,
  > Marcus
  > 
  > On 18.05.23 17:12, Hamed Al-Zubi wrote:
  > Hello Dears,
  > 
  > I would like to inquire about the synchronization of two USRPs X300, one 
acting as a 
  > transmitter (Tx) and the other as a receiver (Rx). If both USRPs are 
connected to the same 
  > laptop, I'm wondering if the accuracy provided by PC clock synchronization 
is similar (or 
  > close) to that achieved through GPSDO synchronization?
  > 
  > Regards,
  > HZ
  
 

Re: USRP X300 Synchronization

[Marcus Müller]

Your OFDM receiver already does Schmidl&Cox, I thought? So, if you correctly designed the 
length of your OFDM symbols and the subcarrier spacing, that should be sufficient. What 
you described, a "constellation rotation for OFDM subcarriers" is unproblematic; you're 
doing subcarrier-wise multiplication with the inverse of your channel estimate, anyways, 
and that cancels that.


Best regards,
Marcus

On 18.05.23 19:08, Hamed Al-Zubi wrote:

Okay. I need to figure out how can I do that.

Thanks!
HZ

On Thursday, May 18, 2023 at 11:54:42 AM CDT, Marcus Müller 
 wrote:


No, that's the opposite of what I said. (also, why would you need a GPSDO when these USRPs 
are colocated?)


You *always* have time offset at a receiver – due to the finiteness of the 
speed of light.

So, *any* working receiver you have has to have timing recovery, there's no way around it. 
So, getting better hardware-level synchronization *does not help you at all*. Not if you 
do it badly, not if you do it really really well.


Best,

Marcus

On 18.05.23 18:21, Hamed Al-Zubi wrote:

So, I have to get GPS modules and use GPSDO synchronization.



On Thursday, May 18, 2023 at 11:20:02 AM CDT, Marcus Müller  
 wrote:




On 18.05.23 18:10, Hamed Al-Zubi wrote:
Actually, I don't know. I thought that by using PC clock in UHD sink and source block in 
gnuradio allows synchronization.

Not in a way meaningful for synchronizing transceivers, no.

Also, I thought that Schmidl and Cox algorithm used for timing recovery in OFDM 
receivers.
Exactly, that's why your PC clock synchronization would contribute nothing, even if it was 
more accurate. You just don't benefit from synchronization.


On Thursday, May 18, 2023 at 10:46:38 AM CDT, Marcus Müller  
 wrote:



Any OFDM receiver needs a timing recovery method anyways, so that has nothing 
to do with
how well your PC is suitable for synchronizing two devices.


On 18.05.23 17:43, Hamed Al-Zubi wrote:
> Thanks for your response, Marcus!
> I have observed a constellation rotation for OFDM subcarriers when I use the 
PC clock for
> synchronization. However, by using the channel model, I am able to see the 
QPSK
> constellation.
>
> Thanks!
> HZ
>
> On Thursday, May 18, 2023 at 10:35:01 AM CDT, Marcus Müller > wrote:

>
>
> No, it's several orders of magnitude worse and generally insufficient for 
anything where
> you need synchronization.
>
> Best,
> Marcus
>
> On 18.05.23 17:12, Hamed Al-Zubi wrote:
> Hello Dears,
>
> I would like to inquire about the synchronization of two USRPs X300, one 
acting as a
> transmitter (Tx) and the other as a receiver (Rx). If both USRPs are connected to the 
same

> laptop, I'm wondering if the accuracy provided by PC clock synchronization is 
similar (or
> close) to that achieved through GPSDO synchronization?
>
> Regards,
> HZ

Re: USRP X300 Synchronization

[Hamed Al-Zubi]

 I use the Shmdil and Cox gnuradio block and it does time recovery based on 
what I have read. I also can retrieve the transmitted data.
But what I am confused about the presence of constellation rotation when I used 
the USRP.  
On Thursday, May 18, 2023 at 12:32:22 PM CDT, Marcus Müller 
 wrote:  
 
 Your OFDM receiver already does Schmidl&Cox, I thought? So, if you correctly 
designed the 
length of your OFDM symbols and the subcarrier spacing, that should be 
sufficient. What 
you described, a "constellation rotation for OFDM subcarriers" is 
unproblematic; you're 
doing subcarrier-wise multiplication with the inverse of your channel estimate, 
anyways, 
and that cancels that.

Best regards,
Marcus

On 18.05.23 19:08, Hamed Al-Zubi wrote:
> Okay. I need to figure out how can I do that.
> 
> Thanks!
> HZ
> 
> On Thursday, May 18, 2023 at 11:54:42 AM CDT, Marcus Müller 
>  wrote:
> 
> 
> No, that's the opposite of what I said. (also, why would you need a GPSDO 
> when these USRPs 
> are colocated?)
> 
> You *always* have time offset at a receiver – due to the finiteness of the 
> speed of light.
> 
> So, *any* working receiver you have has to have timing recovery, there's no 
> way around it. 
> So, getting better hardware-level synchronization *does not help you at all*. 
> Not if you 
> do it badly, not if you do it really really well.
> 
> Best,
> 
> Marcus
> 
> On 18.05.23 18:21, Hamed Al-Zubi wrote:
> 
> So, I have to get GPS modules and use GPSDO synchronization.
> 
> 
> 
> On Thursday, May 18, 2023 at 11:20:02 AM CDT, Marcus Müller 
>  
>  wrote:
> 
> 
> 
> On 18.05.23 18:10, Hamed Al-Zubi wrote:
>> Actually, I don't know. I thought that by using PC clock in UHD sink and 
>> source block in 
>> gnuradio allows synchronization.
> Not in a way meaningful for synchronizing transceivers, no.
>> Also, I thought that Schmidl and Cox algorithm used for timing recovery in 
>> OFDM receivers.
> Exactly, that's why your PC clock synchronization would contribute nothing, 
> even if it was 
> more accurate. You just don't benefit from synchronization.
>>
>> On Thursday, May 18, 2023 at 10:46:38 AM CDT, Marcus Müller 
>>  
>>  wrote:
>>
>>
>> Any OFDM receiver needs a timing recovery method anyways, so that has 
>> nothing to do with
>> how well your PC is suitable for synchronizing two devices.
>>
>>
>> On 18.05.23 17:43, Hamed Al-Zubi wrote:
>> > Thanks for your response, Marcus!
>> > I have observed a constellation rotation for OFDM subcarriers when I use 
>> > the PC clock for
>> > synchronization. However, by using the channel model, I am able to see the 
>> > QPSK
>> > constellation.
>> >
>> > Thanks!
>> > HZ
>> >
>> > On Thursday, May 18, 2023 at 10:35:01 AM CDT, Marcus Müller 
>> > > > wrote:
>> >
>> >
>> > No, it's several orders of magnitude worse and generally insufficient for 
>> > anything where
>> > you need synchronization.
>> >
>> > Best,
>> > Marcus
>> >
>> > On 18.05.23 17:12, Hamed Al-Zubi wrote:
>> > Hello Dears,
>> >
>> > I would like to inquire about the synchronization of two USRPs X300, one 
>> > acting as a
>> > transmitter (Tx) and the other as a receiver (Rx). If both USRPs are 
>> > connected to the 
>> same
>> > laptop, I'm wondering if the accuracy provided by PC clock synchronization 
>> > is similar (or
>> > close) to that achieved through GPSDO synchronization?
>> >
>> > Regards,
>> > HZ
>>

  

Re: Resource issues when trying to record 2 FM broadcast

[Martin Lefkowitz]

It looks like the list doesn't handle .jpg.  i tried to post the images 
of my 2FM project to the list, but no images.  Is there a spot  to drop 
(image) files that is generally accepted on the list?



Marty


On 5/17/2023 5:23 PM, Gary Schafer wrote:

"I can post the block diagrams if someone is interested."

Yes, if you would, please. I'd be interested to see them and 
understand what it is you're trying to do.


Thanks!

Re: USRP X300 Synchronization

[Marcus Müller]

What's confusing about that? The point of S&C synchronization is to put you anywhere fixed 
in the cyclic prefix with your time-synchronization.

All such points are equally good in terms of reception quality.

As said before, the constellation rotation is inherent, and also inherently not 
a problem.

Best regards,
Marcus

On 18.05.23 19:42, Hamed Al-Zubi wrote:
I use the Shmdil and Cox gnuradio block and it does time recovery based on what I have 
read. I also can retrieve the transmitted data.

But what I am confused about the presence of constellation rotation when I used 
the USRP.

On Thursday, May 18, 2023 at 12:32:22 PM CDT, Marcus Müller 
 wrote:


Your OFDM receiver already does Schmidl&Cox, I thought? So, if you correctly 
designed the
length of your OFDM symbols and the subcarrier spacing, that should be 
sufficient. What
you described, a "constellation rotation for OFDM subcarriers" is 
unproblematic; you're
doing subcarrier-wise multiplication with the inverse of your channel estimate, 
anyways,
and that cancels that.

Best regards,
Marcus

On 18.05.23 19:08, Hamed Al-Zubi wrote:
 > Okay. I need to figure out how can I do that.
 >
 > Thanks!
 > HZ
 >
 > On Thursday, May 18, 2023 at 11:54:42 AM CDT, Marcus Müller > wrote:

 >
 >
 > No, that's the opposite of what I said. (also, why would you need a GPSDO 
when these USRPs
 > are colocated?)
 >
 > You *always* have time offset at a receiver – due to the finiteness of the 
speed of light.
 >
 > So, *any* working receiver you have has to have timing recovery, there's no 
way around it.
 > So, getting better hardware-level synchronization *does not help you at 
all*. Not if you
 > do it badly, not if you do it really really well.
 >
 > Best,
 >
 > Marcus
 >
 > On 18.05.23 18:21, Hamed Al-Zubi wrote:
 >
 > So, I have to get GPS modules and use GPSDO synchronization.
 >
 >
 >
 > On Thursday, May 18, 2023 at 11:20:02 AM CDT, Marcus Müller >

 >  wrote:
 >
 >
 >
 > On 18.05.23 18:10, Hamed Al-Zubi wrote:
 >> Actually, I don't know. I thought that by using PC clock in UHD sink and 
source block in
 >> gnuradio allows synchronization.
 > Not in a way meaningful for synchronizing transceivers, no.
 >> Also, I thought that Schmidl and Cox algorithm used for timing recovery in 
OFDM receivers.
 > Exactly, that's why your PC clock synchronization would contribute nothing, 
even if it was
 > more accurate. You just don't benefit from synchronization.
 >>
 >> On Thursday, May 18, 2023 at 10:46:38 AM CDT, Marcus Müller >

 >>  wrote:
 >>
 >>
 >> Any OFDM receiver needs a timing recovery method anyways, so that has 
nothing to do with
 >> how well your PC is suitable for synchronizing two devices.
 >>
 >>
 >> On 18.05.23 17:43, Hamed Al-Zubi wrote:
 >> > Thanks for your response, Marcus!
 >> > I have observed a constellation rotation for OFDM subcarriers when I use the PC 
clock for

 >> > synchronization. However, by using the channel model, I am able to see 
the QPSK
 >> > constellation.
 >> >
 >> > Thanks!
 >> > HZ
 >> >
 >> > On Thursday, May 18, 2023 at 10:35:01 AM CDT, Marcus Müller 
mailto:marcus.muel...@ettus.com>

 >> > wrote:
 >> >
 >> >
 >> > No, it's several orders of magnitude worse and generally insufficient for 
anything where
 >> > you need synchronization.
 >> >
 >> > Best,
 >> > Marcus
 >> >
 >> > On 18.05.23 17:12, Hamed Al-Zubi wrote:
 >> > Hello Dears,
 >> >
 >> > I would like to inquire about the synchronization of two USRPs X300, one 
acting as a
 >> > transmitter (Tx) and the other as a receiver (Rx). If both USRPs are 
connected to the
 >> same
 >> > laptop, I'm wondering if the accuracy provided by PC clock synchronization is 
similar (or

 >> > close) to that achieved through GPSDO synchronization?
 >> >
 >> > Regards,
 >> > HZ
 >>

Re: Resource issues when trying to record 2 FM broadcast

[Marcus Müller]

The list has absolutely no problems with JPEG images. We do have a file size limit, but 
what about you simply share the actual GRC flowgraph file instead of a screenshot of it?


On 18.05.23 20:32, Martin Lefkowitz wrote:
It looks like the list doesn't handle .jpg.  i tried to post the images of my 2FM project 
to the list, but no images.  Is there a spot  to drop (image) files that is generally 
accepted on the list?



Marty


On 5/17/2023 5:23 PM, Gary Schafer wrote:

"I can post the block diagrams if someone is interested."

Yes, if you would, please. I'd be interested to see them and understand what it is 
you're trying to do.


Thanks!

Re: USRP X300 Synchronization

[Marcus Müller]

Hamed,

you need to clearly formulate what you're showing there, and what the problem with that 
is. Your receiver works, as it should, with a rotating channel. Whether that channel is 
physical or an effect of perfect synchronization that's just not how you think "perfect" 
should be like is irrelevant.
At this point we're really not talking about GNU Radio, USRPs or anything, we're talking 
about understanding how OFDM works and why we use it. I think my ressources explaining 
that might have run out – any textbook on the topic of OFDM should help understand why a 
static subcarrier rotation is not a problem.


Best,
Marcus

On 18.05.23 21:07, Hamed Al-Zubi wrote:

The attached figures show the constellation using USRPs and channel models.



On Thursday, May 18, 2023 at 01:48:27 PM CDT, Marcus Müller 
 wrote:


What's confusing about that? The point of S&C synchronization is to put you 
anywhere fixed
in the cyclic prefix with your time-synchronization.
All such points are equally good in terms of reception quality.

As said before, the constellation rotation is inherent, and also inherently not 
a problem.

Best regards,
Marcus

On 18.05.23 19:42, Hamed Al-Zubi wrote:
 > I use the Shmdil and Cox gnuradio block and it does time recovery based on 
what I have
 > read. I also can retrieve the transmitted data.
 > But what I am confused about the presence of constellation rotation when I 
used the USRP.
 >
 > On Thursday, May 18, 2023 at 12:32:22 PM CDT, Marcus Müller > wrote:

 >
 >
 > Your OFDM receiver already does Schmidl&Cox, I thought? So, if you correctly 
designed the
 > length of your OFDM symbols and the subcarrier spacing, that should be 
sufficient. What
 > you described, a "constellation rotation for OFDM subcarriers" is 
unproblematic; you're
 > doing subcarrier-wise multiplication with the inverse of your channel 
estimate, anyways,
 > and that cancels that.
 >
 > Best regards,
 > Marcus
 >
 > On 18.05.23 19:08, Hamed Al-Zubi wrote:
 >  > Okay. I need to figure out how can I do that.
 >  >
 >  > Thanks!
 >  > HZ
 >  >
 >  > On Thursday, May 18, 2023 at 11:54:42 AM CDT, Marcus Müller 
mailto:marcus.muel...@ettus.com>

 > > wrote:
 >  >
 >  >
 >  > No, that's the opposite of what I said. (also, why would you need a GPSDO when these 
USRPs

 >  > are colocated?)
 >  >
 >  > You *always* have time offset at a receiver – due to the finiteness of the speed of 
light.

 >  >
 >  > So, *any* working receiver you have has to have timing recovery, there's no way 
around it.

 >  > So, getting better hardware-level synchronization *does not help you at 
all*. Not if you
 >  > do it badly, not if you do it really really well.
 >  >
 >  > Best,
 >  >
 >  > Marcus
 >  >
 >  > On 18.05.23 18:21, Hamed Al-Zubi wrote:
 >  >
 >  > So, I have to get GPS modules and use GPSDO synchronization.
 >  >
 >  >
 >  >
 >  > On Thursday, May 18, 2023 at 11:20:02 AM CDT, Marcus Müller 
mailto:marcus.muel...@ettus.com>

 > >
 >  >  wrote:
 >  >
 >  >
 >  >
 >  > On 18.05.23 18:10, Hamed Al-Zubi wrote:
 >  >> Actually, I don't know. I thought that by using PC clock in UHD sink and source 
block in

 >  >> gnuradio allows synchronization.
 >  > Not in a way meaningful for synchronizing transceivers, no.
 >  >> Also, I thought that Schmidl and Cox algorithm used for timing recovery in OFDM 
receivers.
 >  > Exactly, that's why your PC clock synchronization would contribute nothing, even if 
it was

 >  > more accurate. You just don't benefit from synchronization.
 >  >>
 >  >> On Thursday, May 18, 2023 at 10:46:38 AM CDT, Marcus Müller 

 > >
 >  >>  wrote:
 >  >>
 >  >>
 >  >> Any OFDM receiver needs a timing recovery method anyways, so that has nothing to do 
with

 >  >> how well your PC is suitable for synchronizing two devices.
 >  >>
 >  >>
 >  >> On 18.05.23 17:43, Hamed Al-Zubi wrote:
 >  >> > Thanks for your response, Marcus!
 >  >> > I have observed a constellation rotation for OFDM subcarriers when I 
use the PC
 > clock for
 >  >> > synchronization. However, by using the channel model, I am able to see 
the QPSK
 >  >> > constellation.
 >  >> >
 >  >> > Thanks!
 >  >> > HZ
 >  >> >
 >  >> > On Thursday, May 18, 2023 at 10:35:01 AM CDT, Marcus Müller
 > mailto:marcus.muel...@ettus.com> 


 >  >> > wrote:
 >  >> >
 >  >> >
 >  >> > No, it's several orders of magnitude worse and generally insufficient for 
anything where

 >  >> > you need synchronization.
 >  >> >
 >  >> > Best,
 >  >> > Marcus
 >  >> >
 >  >> > On 18.05.23 17:12, Hamed Al-Zubi wrote:
 >  >> > Hello Dears,
 >  >> >
 >  >> > I would like to inquire about the synchronization of two USRPs X300, 
one acting as a
 >  >> > transmitter (Tx) and the other as a receiver (Rx).