0

I'm having some problems with my flowgraph in GNU Radio. I built a custom block to be a Delay block because the native block didn't work very well for my application. Before my custom block there is a UHD Source. It's working in a sample rate of 4M. However when I start my simulation it is generating overflows ("O"). I think this is strange because when I save in a file the output of UHD source and then play again the simulation in mode "off-line" there isn't errors of overflow. In the other words, I have problems just when I am working in mode "on-line". Only when I'm working with UHD Source and not a file saved before by UHD Source.

enter image description here

Delay_amostra_sync block code:

import numpy

from gnuradio import gr

class Delay_amostra_sync(gr.sync_block): """ docstring for block Delay_amostra_sync """ def init(self, var): gr.sync_block.init(self, name="Delay_amostra_sync", in_sig=[numpy.complex64], out_sig=[numpy.complex64]) self.var = var self.cont = 0
self.buffer = numpy.array([])
self.c = 1

def work(self, input_items, output_items):
    in0 = input_items[0]
    out = output_items[0]

    self.dados = numpy.array(input_items[0], copy=True)

    self.buffer = numpy.append(self.buffer, self.dados)      

    if self.cont >= self.var:                         
        out[:] = self.buffer[range(0,len(out))]
        self.buffer = numpy.delete(self.buffer, range(0,len(out)), 0)            
    self.cont = self.cont + 1

return len(output_items[0])

  • So, your custom block is too slow. – Marcus Müller Oct 25 '17 at 18:34
  • So, what does your custom block do that the original delay block did not? Explaining that and analyzing why your block is too slow is the solution to your problem. – Marcus Müller Oct 25 '17 at 18:35
  • Clean up grammar. – Sean Perry Oct 25 '17 at 20:36
  • Thanks for your attention @MarcusMüller . I follow the Stackoverflow website and appreciate your contribuitions to others users in this area of RF. I am working in a company that develop solutions to IoT. My area is SDR. Currently we are working with WiSUN. My flowgraph should identificate some channels in a range of frequency and next send to the filter the central frequency. To this i need delay the signal before the filter because when my "identificator" find some frequency the signal can't pass througth it. – Luis Antonio R. Scudeler Oct 27 '17 at 13:57
  • I dindn't know why the native delay block dont work. So i decided to build a delay custom block. The problem is that this custom block is generating "overflow". A interesting observation is that when i decreased the sample rate to 2M it didn't generate "overflows". I will change to a computer that have a lot of memory to check if this is a problem(memory). – Luis Antonio R. Scudeler Oct 27 '17 at 13:57
  • PS: I put a photo to help understand the problem @MarcusMüller. – Luis Antonio R. Scudeler Oct 27 '17 at 14:03
  • If the stock delay block didn't work for you, then that means you're expecting it to do something that it doesn't. That's what I asked you: what does *your* block do. – Marcus Müller Oct 27 '17 at 17:43
  • The block "Delay_amostra_sync" stores in a buffer the signal of input until the counter reaches a value especificated by user. This will cause a delay that is enough to the "Wisun_process" block to have indentificate a channel. So after my filter is configred rigtly i can demodulate my packet of data. – Luis Antonio R. Scudeler Oct 27 '17 at 18:36
  • PS: I put the code of Delay_amostra_sync block above – Luis Antonio R. Scudeler Oct 27 '17 at 18:38

0 Answers0