discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Help: usrp tune not working in wbx daughter board


From: Steven Clark
Subject: Re: [Discuss-gnuradio] Help: usrp tune not working in wbx daughter board
Date: Tue, 16 Nov 2010 12:17:00 -0500


On Tue, Nov 16, 2010 at 1:26 AM, ton ph <address@hidden> wrote:
Thanks steven ,
     I am able to tune steven , but same old problem in which the tune start before and the information which i see is a little bit late , as it seems reading from the previous buffer of the fifo. And my tuning happens dynamically when i got a particular info after processing the fifo contents, i have to tune at that time and i cannot determine the time when it will come.
 And i was thinking ,if after tuning if i flush out the fifo contents wont it give proper result .. i m attaching the logic part how i m reading the fifo using subprocess in python.... hope it will make more clearer explaination of my problem....

# this is inside a thread run part
# reads the fifo with usrp  info
cmd = [' ./pythonProg1.py | ./pythonProg2.py ']
proc = subprocess.Popen(cmd, shell=True, bufsize=0, stdout=subprocess.PIPE, stderr=subprocess.STDOUT )

count = 0
next_frequency = [123,435,456]
while flag == True:
                line = proc.stdout.readline()
                # returns the tuned frequency only and "YES" when satisfy some problem
                print line
                if line == "YES":
                        # tune to another frequency
                        usrp.tune_frequency(next_frequency[count])
                        count =count +1

Might be i have implemented in a very wrong way but my situation is this steve.
the subprocess runs a  command in "cmd" variable using pipe. pythonProg1 output is fed to
pythonProg2.py and after this the output which i get in "line" variable is "YES" , until then the usrp
stay tune to that frequency and returns frequency tuned to and when i get the "YES" i tune to another frequency and tunes until end of
contents in the list "next_frequency"

Hope i explain my problem thorougly ... and may be i can implement in a different way , but i cant as imy system
has become bigger now.Please guide me if you have any means to solve my problem ....
i want to see "line" variable to show me the tuned frequency the moment i tune to that frequency.

Thanks for your concern ....



On Mon, Nov 15, 2010 at 8:17 PM, Steven Clark <address@hidden> wrote:


On Sun, Nov 14, 2010 at 11:49 PM, ton ph <address@hidden> wrote:
hi steven,
 Definitely yes , i am not getting any error and also no effect in tune, i can see ... but i dont know why its not been affected.Moreover  i am using a fifo file and simultaneously reading the fifo using another thread. I was also having a doubt if is it that the usrp is tuned , but i am reading the info from the buffer of the previous frequency... means thou its tuned but we get a display of the previous info of my previous frequency from the buffer .... can you please guide me....
Thanks.


The error is probably in the FIFO mechanism, or as you say you might not be reading out to where the newly-tuned data starts. Try to simplify the setup.  Something like this, where you only write the file, rather than trying to write & read at same time. After the program finishes, analyze the file and make sure it has the frequency tune near the middle of the file.

class MyTopBlock(gr.top_block):
    def __init__(self):
        samp_rate = 125e3 #or something low, match with decimation rate
        num_samps = samp_rate * 5 #roughly 5 seconds of capture
       
        self.u = usrp.source_c(....)
        self.limiter = gr.head(gr.sizeof_gr_complex, num_samps) #limit number of samples to file
        self.fileout = gr.file_sink(...)
       
        ...
       
        self.connect(self.u, self.limiter, self.fileout)
       

class MyTunerThread(threading.Thread):
    def __init__(self, topblock):
        threading.Thread.__init__(self)
        self.topblock = topblock
       
    def run(self):
        time.sleep(2.5)
        self.topblock.tune(new_freq)
       

def main():
    tb = MyTopBlock()
   
    tt = MyTunerThread(tb)
   
    tt.start()
   
    tb.run()
    print('top block done')
   
    tt.join()
    print('tuner thread exited')
   
if __name__ == '__main__':
    main()


Ok, so there is no problem with tuning (initially you said "i am not able to use my thread to tune the usrp").

Instead, you have a problem with timing/synchronization. I don't know if you will ever be able to achieve the perfect timing you are looking for...after you issue a tune command, there will always be some number of samples that come out of the USRP at the old frequency (due to buffering) followed by some number of samples (~200us worth) during which the LO is unstable (locking to new frequency), followed by samples at new frequency. The best you can do is to try to keep the FIFO as empty as possible to minimize the lag, and try to calibrate out the remaining lag as best as possible, and throw away samples in the uncertain period. Otherwise, you can stop the flowgraph when your condition is met, let the remaining samples flush out, issue the tune, wait a little bit, then restart the flowgraph.

Also, don't forget to keep addressing replies to the mailing list, so others have a chance to help you (I am not a guru by any stretch of the imagination).

-Steven

reply via email to

[Prev in Thread] Current Thread [Next in Thread]