[Discuss-gnuradio] Tag propagation policy for tagged stream blocks

[Johannes Demel]

Hey everyone,

I have an issue with how additional tags are handled in 'tagged stream 
blocks'.
E.g. think of a 'FEC Tagged Encoder'. It does handle the length tag but 
what happens to other tags? They are left untouched. This results in a 
situation where a rate change basically makes all other tags disappear 
because these tags will be out of range for all other blocks down the line.
Right now, the options are to not use tags, implement custom blocks that 
exhibit the desired behavior, or implement the desired behavior in the 
GR source. Though, that'll force users to permanently move to a 
different GR source. A situation that is really undesirable.

What I'd like to have is a tag propagation policy that takes all tags in 
range and moves them to the correct output range. Maybe all of them to 
the same position as the length tag. Or a policy that honors the length 
tag position and the rate change for the currently processed samples.
Maybe we could switch between the current and the new tag propagation 
policy.
Since this might be a change that has quite some impact I'd like to 
discuss it and decide later how I'll move forward.

Cheers
Johannes
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tag propagation policy for tagged stream blocks

[Andrej Rode]

Hi Johannes, 

thanks for bringin this issue up.

On Wed, 17 Apr 2019 08:08:37 +
Johannes Demel  wrote:

> but what happens to other tags? They are left untouched. This results
> in a situation where a rate change basically makes all other tags
> disappear because these tags will be out of range for all other
> blocks down the line. Right now, the options are to not use tags,

This sounds like it is a bug and a solution should be implemented for
tagged stream blocks in the GR source. Recently changes were introduced
for tag propagation to use rational numbers to survive multiple down-
and upsampling steps. Plugging that calculation for tagged stream
blocks should be somehow possible, e.g. using instantaneous
decimation/interpolation rates.

Cheers
Andrej


pgpEl0kYWV7sr.pgp
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP time synchronization

[Horký Petr]

Hello Derek,

so my code looks like this:


now = self.uhd_usrp_sink_0.get_time_now()

cmd_time_sink = now + uhd.time_spec_t(0.1)
cmd_time_source = now + uhd.time_spec_t(0.2)

self.uhd_usrp_sink_0.set_start_time(cmd_time_sink)
self.uhd_usrp_source_0.set_start_time(cmd_time_source)

self.uhd_usrp_sink_0.clear_command_time()

I do not understand the sphinx docu.
Can you tell me what is the difference between set_start_time and 
set_command_time?

For me it would be the best to START timer when the first sample is transmitted 
and STOP it when the first sample is received. Then I would be able to 
calculate the time delay.
Or is there a possibility to have a constant delay?

Or could you just recommend me which commands should I use? I will manage the 
rest.
Thank you

Petr



Od: Derek Kozel 
Odesláno: čtvrtek 11. dubna 2019 9:36:38
Komu: Horký Petr; discuss-gnuradio@gnu.org
Předmět: Re: [Discuss-gnuradio] USRP time synchronization

Hi Petr,

You'll have to use timed commands for starting your transmissions. This can be 
done in GRC, but requires writing some code to issue the commands. Usually I 
find it easier to add the commands to the generated Python if I'm not changing 
the application very often.

Here's a C++ example that shows timed stream commands. You'd need to use these 
for both the transmit and reception side.
https://github.com/EttusResearch/uhd/blob/master/host/examples/test_timed_commands.cpp#L111

Regards,
Derek

On 10/04/2019 14:18, Horký Petr wrote:

Dear GNU Radio users,

I have a simple program,  Signal source (square) -> USRP SINK USRP SOURCE - 
> TIME SINK.

If I plot Tx/Rx signals in a Time sink, I see, that there is a time differnce, 
which is OK. But each time I start the program, the time difference changes (As 
shown in a picture in attachements).

What can I do? I tried to change Sync, Clock rate, Clock Source, Time 
sourceeverything. But still the delay is changing each time I execute my 
program.


If the delay was not random I could just substract that. This causes me 
problems in every radar program, since I need precise time measurements.


Regards

Petr







___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gr_zeromq on MS-Windows ?

[jean-michel.fri...@femto-st.fr]

When running a GNU/Linux VirtualBox on MS-Windows, I whish to make GNU Radio 
running
on the guest OS (GNU/Linux) communicate with GNU Radio running on the host OS 
(MS-Windows)
through ZeroMQ. Has anyone tested the proper operation of the ZeroMQ libraries 
provided
with the MS-Windows port [1] of GNU Radio ?
We get DLL loading errors upon importing _zeromq_swig:

Traceback (most recent call last):
File "", line 1, in 
File "C:\Program 
Files\GNURadio-3.7\lib\site-packages\gnuradio\zeromq\__init__.py", line 40, in

from zeromq_swig import *
File "C:\Program 
Files\GNURadio-3.7\lib\site-packages\gnuradio\zeromq\zeromq_swig.py", line 19, 
in

_zeromq_swig = swig_import_helper()
File "C:\Program 
Files\GNURadio-3.7\lib\site-packages\gnuradio\zeromq\zeromq_swig.py", line 18, 
in
swig_import_helper
return importlib.import_module('_zeromq_swig')
File "C:\Program Files\GNURadio-3.7\gr-python27\lib\importlib\__init__.py", 
line 41, in
import_module
__import__(name)
ImportError: DLL load failed: Le module spÚcifiÚ est introuvable.
^^^ French for "The specified module cannot be found"

Thanks, JM

[1] 
http://www.gcndevelopment.com/gnuradio/downloads/installers/v1.5.0/gnuradio_3.7.13.4_win64.msi



--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr_zeromq on MS-Windows ?

[Andrej Rode]

Hi Jean-Michael,

On Wed, 17 Apr 2019 15:34:21 +
"jean-michel.fri...@femto-st.fr"  wrote:

> Files\GNURadio-3.7\lib\site-packages\gnuradio\zeromq\zeromq_swig.py",
> line 18, in swig_import_helper return
> importlib.import_module('_zeromq_swig') File "C:\Program
> Files\GNURadio-3.7\gr-python27\lib\importlib\__init__.py", line 41,
> in import_module __import__(name)
> ImportError: DLL load failed: Le module spÚcifiÚ est introuvable.
> ^^^ French for "The specified module cannot be found"

This usually indicates that `_zeromq_swig.(so|dll)` was found, but
contains unresolvable dynamic linking. Maybe libzmq is missing in the
library_path/dll_path.

On a Linux host I'd go here: "C:\Program
Files\GNURadio-3.7\lib\site-packages\gnuradio\zeromq\" and look at the
`_zeromq_swig.so` with `ldd`. I don't know what the tool of choice on a
Windows platform is for looking up the dynamic linking of a library,
but certainly that information will help you locate the missing pieces.

Cheers
Andrej




pgphSzdgQZjBU.pgp
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio