Hi Nives, Doesnt look like anyone mentioned it yet, but this seems to me like a common "gotcha" with RFNoC: You need at least two RFNoC blocks back-to-back! I've had weird problems otherwise, and as far as I know using just one RFNoC block is not yet officially supported (correct??).
Try a different flowgraph: `File Source => Throttle => RFNoC FIFO (index 0) => RFNoC FIFO (index 1) => File sink` Make sure your RFNoC build has two FIFOs and that in GRC you set the fifo indices to be 0 and 1 on each block. Hope this helps... EJ On Thu, Jun 14, 2018 at 1:28 PM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 06/14/2018 01:01 PM, Michael West via USRP-users wrote: > > There may also be an issue with buffered I/O and how the flowgraph is > stopped. The kill flowgraph button in the main window of GRC is like > hitting Ctrl-C. Try closing the empty window that pops up. You can also > try making the file sink unbuffered and see if that makes a difference. > > Regards, > Michael > > Given that Gnu Radio is already buffering, using the "unbuffered" option > all the time might not be so bad. > > The underlying issue is that the C-based 'stdio' buffering mechanism > doesn't in and of itself provide any kind of "flush my buffers on program > exit" > facility--because C doesn't really have anything like that. So > higher-level environments, like Python have mechanisms to take care of that > "most" of the time, except when you brutally kill them with a > signal--the buffers remain uncommitted to the kernel and the program > leaves the building, so to speak. However, if you use "unbuffered", the > writes are committed immediately to the OS, which means that > they're already conceptually "on disk" from the perspective of any > external observer. > > > > > > On Wed, Jun 13, 2018 at 2:34 PM, Martin Braun <martin.br...@ettus.com> > wrote: > >> I would expect it grow indefinitely, but it might slow down after 1.2 >> MB. If repeat is on, expect lots of data. >> >> The 106 bytes vs. 64 bytes is more interesting. I don't see why, but >> maybe somewhere the last 42 bytes are getting stuck. It might even be in >> GNU Radio. >> >> Try a file that's a multiple of your SPP value, and see what happens >> then (with repeat set to off). >> >> -- m >> >> >> On 06/12/2018 01:37 AM, Nives Novković via USRP-users wrote: >> > Hi Michael, >> > >> > Thank you for your answer. I am sending attached screenshot of the >> > flowgraph and the console. I saw that if I modify the File Source block >> > option repeat to "No" I receive only 64 bytes of a file that is 106 >> > bytes large. If I set it to "Yes" then the content of the sent file will >> > repeat itself until it fills up 1.2MB on the receiving end. >> > >> > Also I tried using Head block but that only helps if I want to send a >> > file that is smaller than 1.2MB. >> > >> > >> > uto, 12. lip 2018. u 01:57 Michael West <michael.w...@ettus.com >> > <mailto:michael.w...@ettus.com>> napisao je: >> > >> > Hi Nives, >> > >> > It is difficult to help without more information. If you share the >> > flowgraph and console output, people on the list might be able to >> > help more. >> > >> > Regards, >> > Michael >> > >> > On Mon, Jun 11, 2018 at 1:01 AM, Nives Novković via USRP-users >> > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> >> wrote: >> > >> > Hi everyone, >> > >> > I am starting to familiarize myself with GNU radio and RFNoC. >> > First thing I tried is simply to send a file to X310 using GNU >> > radio and receive it back unchanged. For that I used blocks - >> > File Source, Throttle, RFNoC: FIFO and File Sink. But no matter >> > what size the file I send, I always receive 1.2MB. Even if my >> > sent file is smaller than that it just multiplies the file >> > content until it reaches 1.2MB. Do you have any idea what could >> > be the problem? >> > >> > Kind regards, >> > Nives >> > >> > _______________________________________________ >> > USRP-users mailing list >> > USRP-users@lists.ettus.com <mailto: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 > listUSRP-users@lists.ettus.comhttp://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
