Re: Synchronization: PPS and Tx signal in a USRP N200

[Marcus D. Leech]

On 2021-12-13 16:56, isaac mario tupac davila wrote:

Hello

Thanks for the information !!!

I have a question regarding the parameter unknown pps. I'm focusing 
wrong, I think so ...


1. If I read the concept This method is used to sync when the edge of 
PPS is UNKNOWN. But when I use a N200, a trimble(GPS) and GRC 
(uhd:usrp source) with this configuration (unknown pps), my N200 gets 
synchronized using a trimble (known pps)... So , when should I use 
unknown PPS?


2. Also says It waits for the last pps and later set time next pps. In 
another website there is a method 1 to poll the USRP time registers.. 
Is unknown pps using the same method?...  I think the Method 1 is used 
for known PPS (trimble and USRP)


Regards
Isaac T.

"Uknown PPS" has NOTHING to do with whether UHD "knows" what type of 
GPSDO unit you have.


It has to do with the synchronization sequence.

"unknown_pps" waits for the time register to change (get_time_now()), 
and schedules "set_time_next_pps()" for whatever that returned + 1 
second.  The provides good guarantees

  that the timestamp register will be set correctly.

But I should AGAIN emphasize that the 1PPS input DOES NOT provide any 
kind of on-going synchronization of the clocks inside the N200--it's 
simply a "trigger point" to assure
  that the time that is set is aligned with the 1PPS pulse.  It has 
nothing to do with ongoing synchronization of samples etc.


But once your program has high confidence that it knows what the time is 
on the N200, it can then schedule events on the device knowing what time 
the device thinks it is,

  and in the receive case, the timestamps on the incoming samples.

https://files.ettus.com/manual_archive/release_003_001_001/manual/html/sync.html

https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD

Re: How to detect that the input item is empty?

[Marcus Müller]

Linge,

> How to judge that this is the last input?

There's no way.

seriously, we discussed this yesterday. It's a bit tiring to explain things in chat, and 
then say exactly the same thing next day on the mailing list.


You cann't do it this way. Your framing must come from where you read the data.
By far the easiest way to achieve that is by writing a Python block that reads a file, 
adds a kind of header that says how many bytes of useful data will come, and then output 
the file, and add the trailing zeros.


Best regards,
Marcus

On 13.12.21 04:08, 能书能言 wrote:

Hi,all
I want to know how a block judges that input has been stopped? For example, my source has 
a total of 1000 samples, the number of input buffers is different each time, it may be 
500, 100, 68... etc. When the input buffer has enough input, the work function will be called,
but when the last set of data of 1000 samples has reached the input buffer, there will be 
no more input, and no more work functions will be called. When processing the last set of 
input data, I need to be able to judge that this is the last time the work function is 
called, and there will be no more input next, and then I will perform zero padding during 
the call to the work function this time.

How to judge that this is the last input? Thanks in advance.
Best Regards,
linge93

Re: Adaptation of Federico La Roccas ISDB-T blocks for DVB-T

[Federico 'Larroca' La Rocca]

Hi Ralf,

Good news!

Regarding your question, In order to be sure that what the block was
measuring was right, I've used a complete software transceiver together
with a Channel Model block. You may take a look at
https://github.com/git-artes/gr-isdbt/blob/master/examples/full_transceiver.grc.
This example is easily reproduced in DVB-T by combining the TX and RX
example flowgraphs.

best
Federico

El lun, 13 dic 2021 a las 8:02, Ralf Gorholt ()
escribió:

> Hello Federico,
>
> after a lot of thinking I have finally managed to adapt your OFDM
> Synchronization and TMCC Decoder blocks for DVB-T :-) The problem was that
> the frame and symbol indexes in the tags sent by the TPS decoder were not
> correct.
>
> Although I can see the video now, I am not sure that I have really done
> everything right, because I have still some problems of understanding.
> Perhaps you can bring some light into the dark?
>
> I have connected GUI number sinks to the freq. error and samp. error
> outputs of the OFDM Synchronization block to display the values and I have
> noticed the following:
>
> 1) With interpolation in the OFDM Synchronization block turned on, when I
> adjust the frequency of the source block (frequency correction ppm) so that
> the freq. error output value is near to zero, this value drifts very slowly
> in one direction, from higher to lower values, crossing zero (i.e. from
> positive to negative values).
> 2) The value at the samp. error output is zero and constant (at least I
> have seen no change during about 30 minutes).
>
> Is this the correct behaviour? If not, how should it be?
>
> Thank you very much for your help and kind regards,
>
> Ralf
>
> Am 11.12.2021 um 16:11 schrieb Ralf Gorholt:
>
> Hello Federico,
>
> I have a lot of difficulties to generate the output and the tags for the
> blocks that follow my TPS Decoder in the flowgraph. That's why I had the
> idea to take a different approach.
>
> The OFDM Synchronization block outputs the payload carriers (1705 in 2K
> mode) whereas the Demod Reference Symbols block that normally follows the
> FFT expects 2048 carriers. My question sounds certainly silly but would it
> be possible to fill in the missing carriers with zero carriers (amplitude
> and phase == 0) to get 2048 carriers again and thus be able to use the
> original DVB-T blocks? As far as I know, in DVB-T the carriers at the
> borders are all set to zero (and perhaps the one in the middle too).
> Perhaps this would be too simple to be true :-)
>
> Regards,
>
> Ralf
>
> Am 10.12.2021 um 14:41 schrieb Ralf Gorholt:
>
> Hi Federico,
>
> indeed, the "symbol_index" tag that is normally sent for each OFDM symbol
> is missing. This might cause an unexpected situation for the following
> deinterleaver block, "Access not within mapped region" according to
> valgrind.
>
> I will see how I can generate the symbol index for each symbol. The "Demod
> Reference Signals" block uses the dvbt_pilot_gen object to parse the input
> data and to generate symbol and frame indices.
>
> As far as I have understood, in your block OFDM Synchronization you have
> combined the symbol acquisition and the FFT. Then you connect a TMCC
> decoder that eliminates the TMCC and auxiliary carriers, generates tags and
> outputs the data carriers. My idea was to do the same for the TPS signals
> in DVB-T.
>
> To my surprise, in principle what I have done seems to work. If not, my
> TPS decoder would not be able to correctly decode the TPS information that
> changes accordingly when I change settings in the transmitter, for instance
> the modulation scheme.
>
> I will focus on the tags and see what is missing.
>
> Regards,
>
> Ralf
>
> Am 10.12.2021 um 14:25 schrieb Federico 'Larroca' La Rocca:
>
> Hi,
>
> I'd be more than happy to help. A couple of things that come into my mind.
>
> The OFDM Synchronization block is a combination of our "old" OFDM Symbol
> acquisition (for a while now it's been part of GNU Radio) and Sync and
> Channel estimation blocks (which performed equalization and integer
> frequency correction) . The most important difference is that OFDM
> Synchronization includes a loop with the estimated channel gains, which in
> turn is used to estimate the sampling error (plus fine frequency errors).
> It also indicates some events downstream via tags, just like the older
> blocks. This new "DVB-T OFDM Synchronization" block should then be a
> combination, if I'm not mistaken, of OFDM Symbol Acquisition plus Demod
> Reference Signals (I'm sure Ron will know more on this).
>
> Anyhow, my point is that you should take a look at the OFDM Symbol
> Acquisition and Demod Reference Signals blocks in GNU Radio, and check
> which tags are used and when. Maybe this lack of tags is generating an
> unforeseen situation on the downstream blocks which generate the segfault?
> Furthermore, if I'm not mistaken, the pilots in DVB-T (in particular
> continuous pilots) are not exactly the same as in ISDB-T. Another
> possibility is 

Re: Does complex conjugate invert IQ ?

[Johannes Demel]

Hi,

I assume the "Swap IQ" block is exactly what you're looking for.
https://wiki.gnuradio.org/index.php/Swap_IQ

Cheers
Johannes

On 13.12.21 16:39, Cyrille Morin wrote:

Hi,

You could use a "Complex to Float" to separate the I and Q components, 
followed by a "Float to Complex", inverting the re and im inputs.



Le 13/12/2021 à 16:31, Rachida SAROUI a écrit :
Thank you for responding, but what I meant by invert is swapping the I 
and Q components of the signal.


Le lun. 13 déc. 2021 à 16:25, Fabian Schwartau > a écrit :


Complex conjugate only inverts the imaginary (Q) part of the signal.
If you want to invert both, just multiply with -1.

Am 13.12.21 um 16:22 schrieb Rachida SAROUI:
> Hi everyone,
>
> I need to invert the I and Q of a complex signal. Does the block
complex
> conjugate do the job?
>
> Thank you
>

Re: Does complex conjugate invert IQ ?

[Albin Stigö]

This might be of interest.

https://www.dsprelated.com/showarticle/51.php


--Albin

On Mon, Dec 13, 2021, 16:45 Cyrille Morin 
wrote:

> Hi,
>
> You could use a "Complex to Float" to separate the I and Q components,
> followed by a "Float to Complex", inverting the re and im inputs.
>
>
> Le 13/12/2021 à 16:31, Rachida SAROUI a écrit :
>
> Thank you for responding, but what I meant by invert is swapping the I
> and Q components of the signal.
>
> Le lun. 13 déc. 2021 à 16:25, Fabian Schwartau  a
> écrit :
>
>> Complex conjugate only inverts the imaginary (Q) part of the signal.
>> If you want to invert both, just multiply with -1.
>>
>> Am 13.12.21 um 16:22 schrieb Rachida SAROUI:
>> > Hi everyone,
>> >
>> > I need to invert the I and Q of a complex signal. Does the block
>> complex
>> > conjugate do the job?
>> >
>> > Thank you
>> >
>>
>>
>>

Re: Does complex conjugate invert IQ ?

[Cyrille Morin]

Hi,

You could use a "Complex to Float" to separate the I and Q components, 
followed by a "Float to Complex", inverting the re and im inputs.



Le 13/12/2021 à 16:31, Rachida SAROUI a écrit :
Thank you for responding, but what I meant by invert is swapping the I 
and Q components of the signal.


Le lun. 13 déc. 2021 à 16:25, Fabian Schwartau > a écrit :


Complex conjugate only inverts the imaginary (Q) part of the signal.
If you want to invert both, just multiply with -1.

Am 13.12.21 um 16:22 schrieb Rachida SAROUI:
> Hi everyone,
>
> I need to invert the I and Q of a complex signal. Does the block
complex
> conjugate do the job?
>
> Thank you
>

Re: Does complex conjugate invert IQ ?

[Martin Luelf]

Dear Rachida,

in order to do that, use the "complex to float" and "float to complex" 
blocks and connect the re output to the im input and the im output to 
the re input.


Yours
Martin


On 13.12.21 16:31, Rachida SAROUI wrote:
Thank you for responding, but what I meant by invert is swapping the I 
and Q components of the signal.


Le lun. 13 déc. 2021 à 16:25, Fabian Schwartau > a écrit :


Complex conjugate only inverts the imaginary (Q) part of the signal.
If you want to invert both, just multiply with -1.

Am 13.12.21 um 16:22 schrieb Rachida SAROUI:
 > Hi everyone,
 >
 > I need to invert the I and Q of a complex signal. Does the block
complex
 > conjugate do the job?
 >
 > Thank you
 >

Re: Does complex conjugate invert IQ ?

[Rachida SAROUI]

Thank you for responding, but what I meant by invert is swapping the I and
Q components of the signal.

Le lun. 13 déc. 2021 à 16:25, Fabian Schwartau  a
écrit :

> Complex conjugate only inverts the imaginary (Q) part of the signal.
> If you want to invert both, just multiply with -1.
>
> Am 13.12.21 um 16:22 schrieb Rachida SAROUI:
> > Hi everyone,
> >
> > I need to invert the I and Q of a complex signal. Does the block complex
> > conjugate do the job?
> >
> > Thank you
> >
>
>
>

Re: Does complex conjugate invert IQ ?

[Fabian Schwartau]

Complex conjugate only inverts the imaginary (Q) part of the signal.
If you want to invert both, just multiply with -1.

Am 13.12.21 um 16:22 schrieb Rachida SAROUI:

Hi everyone,

I need to invert the I and Q of a complex signal. Does the block complex 
conjugate do the job?


Thank you

Does complex conjugate invert IQ ?

[Rachida SAROUI]

Hi everyone,

I need to invert the I and Q of a complex signal. Does the block complex
conjugate do the job?

Thank you

Re: Adaptation of Federico La Roccas ISDB-T blocks for DVB-T

[Ralf Gorholt]

Hello Federico,

after a lot of thinking I have finally managed to adapt your OFDM
Synchronization and TMCC Decoder blocks for DVB-T :-) The problem was
that the frame and symbol indexes in the tags sent by the TPS decoder
were not correct.

Although I can see the video now, I am not sure that I have really done
everything right, because I have still some problems of understanding.
Perhaps you can bring some light into the dark?

I have connected GUI number sinks to the freq. error and samp. error
outputs of the OFDM Synchronization block to display the values and I
have noticed the following:

1) With interpolation in the OFDM Synchronization block turned on, when
I adjust the frequency of the source block (frequency correction ppm) so
that the freq. error output value is near to zero, this value drifts
very slowly in one direction, from higher to lower values, crossing zero
(i.e. from positive to negative values).
2) The value at the samp. error output is zero and constant (at least I
have seen no change during about 30 minutes).

Is this the correct behaviour? If not, how should it be?

Thank you very much for your help and kind regards,

Ralf

Am 11.12.2021 um 16:11 schrieb Ralf Gorholt:

Hello Federico,

I have a lot of difficulties to generate the output and the tags for
the blocks that follow my TPS Decoder in the flowgraph. That's why I
had the idea to take a different approach.

The OFDM Synchronization block outputs the payload carriers (1705 in
2K mode) whereas the Demod Reference Symbols block that normally
follows the FFT expects 2048 carriers. My question sounds certainly
silly but would it be possible to fill in the missing carriers with
zero carriers (amplitude and phase == 0) to get 2048 carriers again
and thus be able to use the original DVB-T blocks? As far as I know,
in DVB-T the carriers at the borders are all set to zero (and perhaps
the one in the middle too). Perhaps this would be too simple to be
true :-)

Regards,

Ralf

Am 10.12.2021 um 14:41 schrieb Ralf Gorholt:

Hi Federico,

indeed, the "symbol_index" tag that is normally sent for each OFDM
symbol is missing. This might cause an unexpected situation for the
following deinterleaver block, "Access not within mapped region"
according to valgrind.

I will see how I can generate the symbol index for each symbol. The
"Demod Reference Signals" block uses the dvbt_pilot_gen object to
parse the input data and to generate symbol and frame indices.

As far as I have understood, in your block OFDM Synchronization you
have combined the symbol acquisition and the FFT. Then you connect a
TMCC decoder that eliminates the TMCC and auxiliary carriers,
generates tags and outputs the data carriers. My idea was to do the
same for the TPS signals in DVB-T.

To my surprise, in principle what I have done seems to work. If not,
my TPS decoder would not be able to correctly decode the TPS
information that changes accordingly when I change settings in the
transmitter, for instance the modulation scheme.

I will focus on the tags and see what is missing.

Regards,

Ralf

Am 10.12.2021 um 14:25 schrieb Federico 'Larroca' La Rocca:

Hi,

I'd be more than happy to help. A couple of things that come into my
mind.

The OFDM Synchronization block is a combination of our "old" OFDM
Symbol acquisition (for a while now it's been part of GNU Radio) and
Sync and Channel estimation blocks (which performed equalization and
integer frequency correction) . The most important difference is
that OFDM Synchronization includes a loop with the estimated channel
gains, which in turn is used to estimate the sampling error (plus
fine frequency errors). It also indicates some events downstream via
tags, just like the older blocks. This new "DVB-T OFDM
Synchronization" block should then be a combination, if I'm not
mistaken, of OFDM Symbol Acquisition plus Demod Reference Signals
(I'm sure Ron will know more on this).

Anyhow, my point is that you should take a look at the OFDM Symbol
Acquisition and Demod Reference Signals blocks in GNU Radio, and
check which tags are used and when. Maybe this lack of tags is
generating an unforeseen situation on the downstream blocks which
generate the segfault? Furthermore, if I'm not mistaken, the pilots
in DVB-T (in particular continuous pilots) are not exactly the same
as in ISDB-T. Another possibility is that the Demod Reference
Signals block is not equivalent to our Sync and Channel estimation
block, and further processing is needed for it to be ready for the
DVB-T Demap...

best
Federico

El vie, 10 dic 2021 a las 9:55, Ralf Gorholt ()
escribió:

Hi Vasil,

thank you for your message. As I have no experience with GNU
Radio and
command line debugging, your hints may be really helpful. I have
attached the gdb and valgrind output to this email.

In the gdb output thread 27 that receives the SIGSEGV is the DVB-T
"Symbol Inner Interleaver" that comes with GNU Radio, not one of
my blocks.

As far as 

Re: Questions On GNU Radio FFT Data logging

[Johannes Demel]

Hi Zen Chen,

I add the mailing list to the discussion again. Please reply to the 
mailing list for all mailing list discussions.


This is an example for a UDP client/server
https://pythontic.com/modules/socket/udp-client-server-example

Your visualization app is probably a server waiting for your GNU Radio 
flowgraph (the client) to send data.


Cheers
Johannes

On 13.12.21 03:38, Zen Chen wrote:

Hi Demel,

I sort of get what you meant . How do I read the data from UDP sink ? 
That is one of my questions.


Regards,
Chen Chong Zhi

On Fri, 10 Dec 2021 at 19:49, Johannes Demel > wrote:


Hi Chong Zhi,

I assume you want to observe the FM band ~90MHz to ~100MHz is that
correct?

If you want to listen to audio, have a look at gr-rds.
https://github.com/bastibl/gr-rds 
It helps quite a bit more to understand FM.

Since this discussion seems to have started in the GR Matrix chat, I
infer you actually want to re-implement the Qt GUI Frequency Sink block
outside of GNU Radio.
Further, this needs to happen online.

As Martin mentioned, at your current sample rate a CSV is a bad choice.
If CSV is a hard requirement, sent the resulting CSV to the person
requesting it and ask them to open it. I just hope they understand the
issue after their spreadsheet visualization tool crashed/is
unresponsive
or anything else.

The file format is explained in the GR wiki, as Marcus pointed out.

https://wiki.gnuradio.org/index.php/File_Sink#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F



Let's assume you use a binary file and want to open in in Python, in
your case this would be
```
import numpy as np
samples = np.fromfile('your_file.cdat', dtype=np.complex64)
```
Please mind that the File extension (.cdat) is an arbitrary choice. In
your flowgraph, the filename is just "Yes933FFT".

The most common tool for visualization in Python is matplotlib.
However,
this is more directed at drawing a static graph. It might be a good
idea
to look into e.g. pyqtgraph, if you want to continuously update your
graph. There are probably hundreds of libraries that will cater your
needs depending on what you want to do. e.g. there are libraries that
help you create an interactive website, if you want to do that.

The Qt GUI Frequency Sink block does quite a few more things. The
processing chain looks a bit like this:
1. FFT
2. compute magnitude squared
3. moving average
4. compute dB values, i.e. 10*log10(...)
5. Discard most samples and only draw a new line at the "update rate".

You might be able to swap step 4 and 5.
It might be interesting for you to perform some, most, or all of these
steps in your GNU Radio flowgraph. This might lower your sample rate.

Besides, if you want to visualize your data "online", a file is a bad
choice for data exchange. I would expect that you end up in
"concurrency
hell".
GNU Radio offers quite a few useful options here. e.g. UDP or TCP
sinks.
Or there are ZeroMQ sinks. With Python you should be able to receive
data from these sinks with just a few lines of code.
For example, you might use a UDP sink in your flowgraph and send all
data to a UDP port on your machine. Then, your visualization tool
listens on that UDP port, receives your data and does what it is
supposed to do.

Cheers
Johannes



On 10.12.21 09:59, Zen Chen wrote:
 > Yes933_10_12_20212nd.csv
 >

>
 > HI all,My name is Zen Chen , a GNU radio Novice and I tried to
create an
 > account on the GNU Radio .org website to post my questions on the
 > mailing list however I could not . I am using GNU radio and Hack
RF 1 to
 > design a power spectrum analyser and I am using the attached
flowgraph
 > to and python script to give me the attached CSV file however , the
 > results (FFT connect to file sink) is to large to be contained in a
 > single excel file . Is there a problem in my GNU Radio Flowgraph?
 >
 > Regards,
 > Chong Zhi