Ali, I just pushed a couple of updates.  Let's see if that fixes it for you.

I added:
1. [Timer] Some thread safety to the timer module.  I also noticed in my
flowgraph if I went to the top block options and turned on "realtime
scheduling" it was generally more accurate on the timing (makes sense).
2. [File Sink] Added a proper gnuradio stop() function to make sure files
get properly closed on exit. (Burns me every time.... swig doesn't
guarantee that C++ destructors get called so you really need to clean up in
stop().  I just get lazy sometimes)

Anyway do a fresh git pull and let me know if that fixes any of your issues
or if you still experience them.



On Wed, May 1, 2019 at 8:52 PM GhostOp14 <ghosto...@gmail.com> wrote:

> Thanks Ali,
>
> I'll take a look at what you found with inconsistencies and see if I can
> hunt them down.
>
>
>
> On Wed, May 1, 2019 at 5:35 PM Ali Dormiani <sdorm...@eng.ucsd.edu> wrote:
>
>> Hello GhostOp14 and USRP users,
>>
>> Your oot blocks are amazing. They do exactly what we need in a clean way.
>> In testing, we have found that there are rare anomalies though (occur like
>> a rare Poisson process).
>>
>> 1. Sometimes the advanced file sink will create an empty file of 0 bytes.
>>
>> 2. Sometimes the state timer messes up. We avoid a runaway data capture
>> by using the 'max file size' parameter in the advanced file sink.
>>
>> Overall, this solution is very good and eliminates a lot of variables
>> from our experiments. All of our USRP devices are initialized once and
>> constantly stream data (only some of which is saved). Our phase calibration
>> is a lot more consistent now.
>>
>> Thank you again for providing these oot blocks on Github. My own custom
>> embedded python block was inelegant and inconsistent.
>>
>> Cheers,
>>
>> Ali
>>
>>
>> On Wed, May 1, 2019 at 6:19 AM GhostOp14 via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Morning everyone, not sure my note yesterday hit the list correctly so
>>> I'm trying again.
>>>
>>> Mark: I have a solution for you.  I added a new block yesterday to
>>> gr-filerepeater (pybombs or github).  There's now a state timer block
>>> that'll generate a message based on block-specified timing.  Trigger time,
>>> cycle time, etc.  gr-filerepeater also has a new file sink block I've added
>>> in the past couple of weeks specifically to address the same kind of
>>> problem.  You can feed the timer msg out to the new sink msg in.  The new
>>> block will then key off the state (1/0) in the msg metadata and start/stop
>>> writing to a file.  You can specify a directory and a base file name, then
>>> every time a new file write is started it'll append a timestamp.  Should
>>> exactly match up to what you're trying to accomplish.  I'll post on the
>>> gnuradio list as well since they're gnuradio blocks.
>>>
>>>
>>>
>>> On Mon, Apr 29, 2019 at 8:24 PM Marcus D. Leech via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> On 04/29/2019 08:08 PM, Mark Wagner via USRP-users wrote:
>>>> > Hey all,
>>>> >
>>>> > I'd like to know how to write short files of streamed USRP data
>>>> > periodically using GNUradio. For instance, I'd like the USRP to
>>>> > automatically record 5 seconds of data every 10 minutes. It does not
>>>> > matter to me whether the USRP is constantly on and most of the data
>>>> is
>>>> > being discarded, or if the USRP wakes up every 10 minutes to record
>>>> > the data before sleeping. Whichever is easiest to achieve is fine by
>>>> > me. Does anyone have experience doing this kind of thing?
>>>> >
>>>> > -Mark
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Mark Wagner
>>>> > University of California San Diego
>>>> > Electrical and Computer Engineering
>>>> >
>>>> >
>>>> If you're using Gnu Radio, you can simply use the file sink, and have
>>>> it
>>>> record to "/dev/null" most of the time, then have something (perhaps via
>>>>    the XMLRPC built-in feature) change the filename to whatever your
>>>> desired filename is, and then revert it back to "/dev/null".
>>>>
>>>> I think I said the same thing on the discuss-gnuradio mailing list a
>>>> few
>>>> days ago.
>>>>
>>>> The usrp-users mailing list isn't the best place to ask Gnu Radio
>>>> questions, a question like this, which is inherently radio-type
>>>> agnostic, probably
>>>>    belongs on the discuss-gnuradio mailng list, because it's more about
>>>> "how do I make Gnu Radio dance".
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> USRP-users@lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to