Great additions and changes. Everything seems to be working smoothly on our end. Realtime scheduling is an important option I forgot to enable. Future users should use that.
On Sun, May 5, 2019 at 1:18 PM GhostOp14 <ghosto...@gmail.com> wrote: > I folks, to complete the timing set, I also just added another timer > module to gr-filerepeater. This one you can give a time-of-day > (hours/minutes/seconds) and a duration and it'll generate a positive state > transition when the specified time is reached every day, then a 0 state > transition when the specified duration expires. So if you wanted to write > to a file starting at 3am for 15 minutes, this would be the way to do it > without having to wake up! > > > > On Thu, May 2, 2019 at 9:35 AM GhostOp14 <ghosto...@gmail.com> wrote: > >> 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
