|
| From: | ?????? |
| Subject: | Rx_time issues, when receiving periodly. |
| Date: | Thu, 6 Apr 2023 23:23:55 +0800 |
Hello everyone,
I have been working on a simple impletation that using USRP and GNURADIO to receive signals for 0.1s per five second periodly. In order to test the receiving situation, I make the following flowgraph,
Usrp source->Head Block-> Tag Debug.
Python Snippet
The Tag Debug block can print out the rx_time of when USRP starts receiving per five second.
The Head Block can limit the num of samples each time receving, and when the num is set to samp_rate/10, the next block will only get 0.1s datas.
The Python Snippet periodly set_start_time for the usrp to schedule it to receive per second, and reset the head block. The code is written below:
i=5 #Receive from the fifth second of the clock in the USRP
while True:
current_time=self.uhd_usrp_source_0.get_time_now() #Get the current time for subsequent sleep()
full_second=uhd.time_spec_t.get_full_secs(current_time) #get whole seconds
frac_second=uhd.time_spec_t.get_frac_secs(current_time) #get fractional seconds
print(full_second,frac_second) #print current time
sleep_time=4.95-frac_second-(full_second%5) #sleep until near receive time
time.sleep(sleep_time) #Overflow at startup of scheduled reception can be avoided!
#Because topblock.start() only lasts for a short time
self.uhd_usrp_source_0.set_start_time(uhd.time_spec(i)) #timing
self.blocks_head_0.reset() #Reset Head BLock count
----------------------------------------------------------------------------------------
Overall it seems to work, but I??m witnessing an interesting effect, in other words, a BUG.
When I set the samp_rate as 2M hz, the TAG DEBUG and Python Snippet prints as below:
Tag Debug:
Input Stream: 00
offset: 0 Source: usrp_ source1
Key: rx_ time
value: {5 1.93437e-05}
50. 10658475
Tag Debug: 1
Input Stream: 00
offset: 0 Source: usrp_ source1
Key: rx_ _time
value: {10 2. 09375e-06}
10 0. 1070093125
Tag Debug: 1
Input Stream: 00
Offset: 0 Source: usrp_ source1
Key: rx_ time
Value: {15 2. 09375e-06}
15 0. 10721371875
Tag Debug: 1
Input Stream: 00
Offset: 0 Source: usrp_ source1
Key: rx_ time
Value: {20 2. 09375e-06}
200. 10639809375
??????.
It can be seen that the data can be received at the basic hour of every five seconds perfectly.
But when the sampling rate is increased to 20Mhz, there is no overflow and situations that samples can not be processed in time, the TAG DEBUG and Python Snippet prints as below:
Tag Debug: 1
Input Stream: 00
offset: 0 Source: usrp_ source1
Key: rx_ _time
value: {5 3.5e-07}
5 0.10255155
Tag Debug: 1
Input Stream: 00
offset: 0 Source: usrp_ source1
Key: rx_ _time
value: {10 3.5e-07}
10 0.1023389
Tag Debug: 1
Input Stream: 00
offset: 0
Source: usrp_ source1
Key: rx_ _time
Value: {10 0.10072}
15 0.1022307
Tag Debug: 1
Input stream: 0
offset: 0
Source: usrp_ source1
Key: rx_ _time
Value: {20 3.5e-07}
20 0. 1022381
Tag Debug: 1
Input strean: 0
offset: 0
Source: usrp_ source1
Key: rx_ _time
Value: {25 3.5e-07}
25 0. 10191055
Tag Debug: 1
Input Stream: 00
offset: 0
Source: usrp_ source1
Key: rx_ _time
Value: {25 0.100516}
30 0. 10212705
Tag Debug: 1
Input Stream: 00
Offset: 0 Source: usrp_ source1
Key: rx_ _time
value: {30 0. 100516}
The USRP receiving indicator is normal, but it can be seen that at some time UHD does not mark the arrival time stamp of the data stream at the full five seconds, but after the last receiving time of the last five seconds!
The get_time_now() is always run and print before receiving, but you can see that sometimes the time it given is later than rx_time tag.
To put it vividly, UHD does not know that the data stream has been restarted, but directly stamps the time after the last reception!
Would like to know what causes this effect? Does it caused by the software parallel architecture of GNURADIO? However, why this effect doesn't appear at low sample rate should also be considered.
Any thoughts?
Tuzi.
| [Prev in Thread] | Current Thread | [Next in Thread] |