About flowgraph stop and blocks sending last-data-indicator

2022-04-28 Thread Jonas Wenner 
Hello,
 
long time lurker, first time poster + newbie in GNURadio and digital signal 
processing here.
I'm terribly sorry if the question I'm about to ask is already answered in the 
wiki (couldn't find anything so far).
 
I have a question about flowgraph deconstruction / end of execution for message 
blocks.
 
Imagine, I have two message passing blocks (written in C++). One msg_send that 
periodically sends a message to a msg_recv block.
Now, for one reason or another, I'd like msg_recv to know that the message it 
receives is the last one msg_send will send due to someone/thing stopping the 
flowgraph.
Is it possible to propagate this somehow aka can msg_send be aware that the 
flowgraph should stop and send a special message to msg_recv?
I tried building this into msg_send's destructor and, while the message gets 
sent, it never arrives at msg_receive (I imagine due to a disconnect call on 
flowgraph end).
So for this to work, msg_send would need to know it is done with its entire 
work in its work function / message generation function (before the block gets 
disconnected). Is this possible in any way?
 
On that note, I have a few related questions I couldn't find the answer for:
- Is it guaranteed that a message will arrive at its destination as long as the 
flowgraph is connected, or can it be dropped somewhere between two blocks?
- What would be the order of block destruction when stopping a flowgraph? Is it 
first created - last destroyed?
 
Thanks in advance for your help and time
JW

'Moving average' block always freezes with certain parameter values

2022-04-28 Thread Kimmo Lehtinen 
Hi 

I have the following flowgraph:
Noise source  ->  Throttle  ->   Stream to vector (Num items=1024)  -> 
FFT (FFT size=1024)  ->  Complex to mag^2  ->  Moving average  ->  
QT GUI vector sink
In 'Moving average' the parameters are:
Length = n_average
Scale = 1.0 / n_average
Max iter = 4000Length of vectors = 1024
To give a value for the parameter 'n_average' I have a 'QT GUI Range', with the 
following parameters:
ID = n_average
Default value = 9Start = 2Stop = 10 
Step = 1
If the 'Default value' above is 8, 9 or 10, I can change the value of 
'n_average' to any value between 2-10 when the flowgraph is running, and 
everything works fine. 

However, if the 'Default value' above is between 2-7, then always when I change 
the value of 'n_average' to 9, the flowgraph freezes (GUI vector sink is not 
updated anymore). There are no error messages. 

If I change the value of the 'Stop' parameter to 100, the same happens when 
'n_average' is changed to 9, but if I change 'n_average' to e.g. 62, I get an 
error message like
'gr::log :ERROR: block_executor - sched:  is 
requesting more input data  than we can provide.  

ninput_items_required = 62  max_possible_items_available = 15  If this is a 
filter, consider reducing the number of taps.'


I am using Gnu Radio Companion version 3.9.5.0 (Python 3.8.10) in Ubuntu 
20.04.4 LTS. 
GRC has been installed by using PPA installation. 

cheers, Kimmo 




 

USRP b210 time stamp corrupted with two-channel receive

2022-04-28 Thread Edwin Peters 

Hi,

I am using an Ettus B210 in two-channel receive and require accurate 
time stamps. The B210 is connected to an external 10 MHz clock and PPS 
source.


Setting the time on the B210 works fine, and reading back the time 
reports the expected time.


When streaming a single channel, everything works as expected, and if I 
read back the time after ending the stream, the time reported by the 
USRP is correct. The time in the hdr metadata files is correct as well.


/2022-04-29 13:39:02.117 | INFO | __main__:start:317 - Before stream 
start: system time 1651203542.1179564 usrp time 1651203542.0 (2022-04-29 
13:39:02.00)
2022-04-29 13:39:02.118 | WARNING  | __main__:start:329 - Starting 
recording immediately

2022-04-29 13:39:02.118 | INFO | __main__:start:331 - Calling start()
2022-04-29 13:39:02.119 | INFO | __main__:start:335 - Time after 
issuing start stream command: 1651203542.1197705 usrp time 1651203542.0 
(2022-04-29 13:39:02.00)


/

When streaming two channels, the setup works fine, but after the 
top_block.start() command is issued, the time read back is somehow the 
current time stamp multiplied by 2. The time in the hdr metadata files 
has the first time stamp being the time stamp around calling 
top_block.start() multiplied by 2. It however increments properly (from 
the corrupted origin) when counting the samples.


/2022-04-29 13:39:20.120 | INFO | __main__:start:317 - Before stream 
start: system time 1651203560.1199565 usrp time 1651203560.0 (2022-04-29 
13:39:20.00)
2022-04-29 13:39:20.120 | WARNING  | __main__:start:329 - Starting 
recording immediately

2022-04-29 13:39:20.120 | INFO | __main__:start:331 - Calling start()
2022-04-29 13:39:22.012 | INFO | __main__:start:335 - Time after 
issuing start stream command: 1651203562.012672 usrp time 3302407122.0 
(2074-08-25 17:18:42.00)

/Where /3302407122//= //1651203560///*2 + 2//

I have tested this with both UHD 4.1 and UHD 4.2. GNU radio version: 
3.8.0.0 (Python 3.8.10)



Is anyone on this mailing list familiar with the issue and have a 
solution/workaround for this?


I have attached log output and a not so small MWE


Thanks,

--
Edwin Peters (PhD,MEng)
Research Fellow - UNSW Canberra Space

Single channel recording
2022-04-29 13:38:58.358 | INFO | __main__:__init__:165 - USRPS: [{'usrp': , 'n_channels': 1, 'antenna': 'RX2', 'serial': '3136D4B', 'config': {'serial': '3136D4B', 'subdev': 'A:A', 'args': 'recv_frame_size=1032, num_recv_frames=5120', 'antenna': 'RX2'}}]
2022-04-29 13:38:58.359 | DEBUG| __main__:__init__:166 - settings: {'Fc_hz': 43700.0, 'Fs_hz': 50.0, 'gain_dB': 45, 'NID': 666, 'file_name': '', 'file_path': '/media/rf_data/recordings', 'antenna': 'RX2', 'pps_present': True, 'test_dev_null': False, 'usrps': [{'serial': '3136D4B', 'subdev': 'A:A', 'args': 'recv_frame_size=1032, num_recv_frames=5120', 'antenna': 'RX2'}]}
2022-04-29 13:38:58.359 | DEBUG| __main__:__init__:174 - USRP {'usrp': , 'n_channels': 1, 'antenna': 'RX2', 'serial': '3136D4B', 'config': {'serial': '3136D4B', 'subdev': 'A:A', 'args': 'recv_frame_size=1032, num_recv_frames=5120', 'antenna': 'RX2'}}: Setting clock source to external and time source to external
2022-04-29 13:38:58.775 | INFO | __main__:__init__:180 - Clock ref locked True
2022-04-29 13:38:58.775 | DEBUG| __main__:__init__:183 - 0 antenna RX2 gain 45
2022-04-29 13:38:58.777 | DEBUG| __main__:__init__:206 - 1
2022-04-29 13:38:59.779 | WARNING  | __main__:__init__:222 - syncing time -- If this hangs, please verify that an external pps is configured
2022-04-29 13:38:59.780 | DEBUG| __main__:sync_clock:244 - USRP0 time 1.316781625 1970-01-01 10:00:01.316782
2022-04-29 13:39:00.083 | INFO | __main__:sync_clock:258 - USRP 3136D4B -- Successfully synced USRP GPS time in 1 attempts
2022-04-29 13:39:00.084 | INFO | __main__:__init__:224 - verifying time
2022-04-29 13:39:01.010 | INFO | __main__:check_clock:275 - USRP0 time 1651203541.0 2022-04-29 13:39:01.00
2022-04-29 13:39:01.010 | WARNING  | __main__:check_clock:280 - All USRP clocks in sync (to the second)
2022-04-29 13:39:02.011 | DEBUG| __main__:__init__:229 - tune the USRPs
2022-04-29 13:39:02.117 | DEBUG| __main__:__init__:231 - done
2022-04-29 13:39:02.117 | INFO | __main__::353 - start recording
2022-04-29 13:39:02.117 | INFO | __main__:start:317 - Before stream start: system time 1651203542.1179564 usrp time 1651203542.0 (2022-04-29 13:39:02.00)
2022-04-29 13:39:02.118 | WARNING  | __main__:start:329 - Starting recording immediately
2022-04-29 13:39:02.118 | INFO | __main__:start:331 - Calling start()
2022-04-29 13:39:02.119 | INFO | __main__:start:335 - Time after issuing start stream command: 1651203542.1197705 usrp time 1651203542.0 (2022-04-29 13:39:02.00)
2022-04-29 13:39:04.894 | WARNING  | __main__::363 - verifying clock after recording
2022-04-29 13:39:05.011 | INFO | __main__:check_clock:275 - US