On Tue, Nov 16, 2010 at 1:26 AM, ton ph <ph.ton.sha...@gmail.com> 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 <steven.p.cl...@gmail.com>wrote:
>
>>
>>
>> On Sun, Nov 14, 2010 at 11:49 PM, ton ph <ph.ton.sha...@gmail.com> 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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
