[Discuss-gnuradio] More Options for Working with Sample Data Sets
I've been updating a number of modules following up on the GRCon working sessions around working with large and sample data sets. Yesterday I pushed another update to the new gr-sql module on github that incorporates HackRF and rtlsdr 8-bit streams to either convert with the command-line or directly play in a gnuradio flowgraph by transparently handling the conversion (for those working with either of those two SDR's). While gr-sql is meant to help extract portions of signals out of a very large sample stream, the other half of the issue for testing could be to combine individual signal isolated sample recordings into a more complex "real-world" signal for analysis, say for determining if an algorithm could distinguish individual signals in an overlapping environment by combining two prerecorded signals in a manner that you control. To that end, I updated the gr-filerepeater module with more control over playback. You can now add a delay before starting playback of a signal (would output zero's until the delay is hit), as well as have it transition back to outputting zero's after playback without stopping the flowgraph. This way you could say "for signal two, start injecting after 3 seconds, and when it finishes just output zeros as if the signal was gone but allow the rest of the flowgraph to continue". ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] New GR-SQL Module
Hi everyone, Back from GRCon2017 (one of the best conferences I've been to) and had some time for some more module development. During the conference in one of the working sessions there was a suggestion for a module that would allow you to query really large IQ files with a SQL-like syntax. Made sense, 500 GB file but you only want a minute or two of the sample rather than having to go through the whole thing. So I put one together and posted up on github (https://github.com/ghostop14/gr-sql). Basic to start. Has a command-line tool called grsql (the readme has some examples) to extract portions to a new file, and a flowgraph block to play excerpt directly. Basic syntax: Get the total time length of a file: grsql "select TIMELENGTH FROM '/tmp/myrecording_593MHz_6.2MSPS.raw' ASDATATYPE complex SAMPLERATE 6.2M" Extracting data from 45.2 seconds to 80 seconds into the save to a new file: grsql "SELECT * FROM '/tmp/myrecording_593MHz_6.2MSPS.raw' ASDATATYPE complex SAMPLERATE 6.2M STARTTIME 45.2 ENDTIME 80.0 SAVEAS '/tmp/extracted.raw'" In the flowgraph block, saveas doesn't apply but you can play specific time ranges back directly from the flowgraph without needing to extract from the file (if you're looking for a signal in the recording). If you're working on some blind analysis, if you extract a sample to a new file, you may want to use the gr-filerepeater block up on my github too. It'll let you put delays between replays so that any blocks looking for signal continuity won't get too "confused" by going directly from the end of a sample immediately to the first sample creating a weird signal discontinuity as it "jumps". gr-filerepeater will let it go "quiet" for a specified period of time so the blocks can settle before trying to decode / demod again. Anyway it's alpha/beta but it works. If you run into any bugs or are working with some big files and want any particular features, drop me a note. If all looks pretty solid and there's interest I can set up a pull to integrate it into pybombs for an easier install. Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNURadio/Module builds and std=C++11
Hi everyone, I've run into this on every Ubuntu 16.04 box I've installed gnuradio and OOT modules on and Google doesn't seem to have a nice clean answer (the search answer is always add a compile flag) so I figured I'd ask the group. When I build modules (gr-osmosdr in particular with libfreesrp support I run into this) on a fresh Ubuntu 16.04.2 LTS install, I run into a warning like this: "warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11". Depending on the code it may produce errors on some lines preventing compilation. I know what causes it, the compiler is defaulting to something earlier than the c++11 standard (like C++99) with the Ubuntu repo gcc version (5.4) installed, so some of the syntax in the code is causing the warning. I can modify the CMake and add this to it "set (CMAKE_CXX_STANDARD 11)" and it builds after that, but my guess is that this builds on everyone else's Ubuntu without these modifications or the setting would be standard in the CMake files. What I'd really like to do is tell the compiler to default to -std=C++11 even if it's not explicitly provided as a compile flag, but again if everyone were running into it I think it would have been fixed another way. If I do the same build on a standard debian build with gcc 6.3 it builds clean so it's definitely a default standard issue for compilers on Ubuntu 16.04. Does anyone have any insight/suggestions? Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Major OpenCL Updates
Hi everyone. A number of you have asked me to keep you informed of any major updates on the OpenCL gr-clenabled project and the past couple of weeks have been pretty active. There's now a version up in the repo with a significant number of updates and all blocks have been validated (at least in their basic modes). So here's the major updates: Validation flowgraphs - Almost all test flowgraphs have been posted in the examples directory. You can run the comparisons on your own hardware for comparison. This is important on older cards that don't support double precision (you can check with the included clview command-line tool). Signal Source Block - A discrepancy in the output was due to an OpenCL issue. Turns out single/float precision wasn't producing accurate enough numbers. This block now uses double precision if the hardware supports it (most new hardware will) for an even cleaner signal than the native block (no secondary nodes). Quad Demod - Same single/double trig discrepancy due to precision which was corrected. Filters - A lot of work this week has been spent on filter validation (hence the few emails about TD vs. FD from yesterday) - Both FIR and FFT implementations are now implemented and producing correct output - A generic tap-based block was added for more flexibility - A test-clfilter command-line tool was added to test performance given a number of taps across OpenCL FIR, GNURadio FIR, OpenCL FFT, and GNURadio FFT so you can pick the best performing filter given your implementation. Costas Loop - A Costas Loop was added, however the performance on a GPU kernel is horrible. Because of the sequential calculations, it couldn't be SIMD parallel processed so it was written as an OpenCL task-based kernel. This means it just runs single-threaded on a single core, which is why the performance is so bad. However if anyone has an OpenCL-capable FPGA card like an Altera I'd love to see the result of running the included test-clenabled timing tool and see how the Costas Loop performs. I just don't have access to one. Performance - Code was added to detect if the hardware supports Fused Multiply/Add functionality for added kernel performance. If it's available it's used. OpenCL Setup Instructions - For those that may not have OpenCL set up, I added some installation guides in the setup_help directory for Ubuntu and Debian with step-by-steps on getting it up and running. I've taken both of those processes on several systems and been up and running pretty quickly. I also pulled some of the important points into the main page's README, since in my experience that's generally all I look through too. Study - Based on the filter updates, the filter section in the study in the docs directory was completely rewritten. The report was noted as updated. I think that's the biggest updates for now. As always let me know if anyone runs into any issues. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] What value is in in[noutput_items+1]?
I was looking back over the Quadrature Demod code and I happened to notice something unusual. The call to the Volk multiply conjugate routine appears to use in[noutput_items+1] on the last calculation. Here's the call: volk_32fc_x2_multiply_conjugate_32fc(&tmp[0], &in[1], &in[0], noutput_items); It obviously works correctly, and the buffer's bigger than noutput_items so it doesn't seem to cause a memory access issue. So my question is: when volk uses the memory at in[noutput_items+1] what value is it using? Is it using a zeroed byte, something from a history buffer, or whatever happened to be there? Would anyone have any insight? Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to tell Flowgraph to Stop in Work()?
I'm working on a module in C++ and when a condition happens I want my work function to signal to the flowgraph to stop. I saw some references for python to self._top_block but does anyone have a suggestion on how to do it in C++? Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] PFB Clock Recovery Block (#1)
Thanks Marucs for pointing it out. Hadn't noticed. Will do. Hey Ghost, um, could you please not take the list into CC when replying to github issue discussions? It's pretty confusing. Best regards, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] CorrectIQ 2.0
Hi everyone, been a busy week on OOT modules. While working on some other signal decodes I made a number of enhancements in the CorrectIQ OOT module. First, doing some testing I was seeing inconsistencies in the plotted waveforms due to inheriting from "block" instead of sync_block so that was fixed across all the modules. There's also 2 new blocks in the group. One that does an auto-sense on the offset at the given frequency and gain then switches to to a straight DC offset mode to prevent any sense of "filtering" being applied to the signal due to the averaging. (Thanks to Ron Economos for turning me on to this technique!) If you adjust frequency or gain upstream the block will automatically recalibrate and you can configure the recalibration time. You can let it calibrate without the antenna connected and settle then connect it or just do it with the live input. The other block is a manual offset block. It's just a glorified "complex Add Const" but it makes it a bit straightforward in the flowgraph to follow by calling out the offsets in the GUI. I also added a new example GRC with all of the blocks that can be used to do comparisons. Enjoy! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OpenCL/gr-clenabled Update
Hi everyone, I just pushed a number of updates/fixes to github for the OpenCL gr-clenabled project. While working on a different OOT block I found some variations between blocks using gr::block and gr::sync_block so now the OpenCL blocks are using the correct base types. There was also a compile issue I noticed testing on Ubuntu where the compiler wasn't picking up the C++11 standard as the default causing compilation to fail (worked fine on my debian so I hadn't run into it). So now the makefiles make sure the compiler knows what version to use. I'm also going to put up some NVIDIA/OpenCL notes for a few different platforms to help folks get up and running faster. The biggest gotcha seems to be needing to install the OpenCL dev kit to get cl.hpp to show up and then either linking or copying it into /usr/include/CL/. Hopefully the notes will save folks some headaches and hours googling. Also don't forget that gr-clenabled comes with 2 command-line tools. 'test-clenabled' can be used to time the blocks on your hardware and you can vary the sample sizes if you want to test out some sizes I didn't include in the study. There's also a test-clkernel tool if you want to write your own kernels. It'll do the same performance measurements so you can see how your code performs. Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OpenCL FPGA Recommendation?
Hi everyone! I'm working on expanding the OpenCL modules for GNURadio and I want to test them with some FPGA's that support OpenCL. There's a few from Xilinx and Altera it looks like, but the ones I've seen are a bit pricey. Does anyone know of an OpenCL-capable FPGA card for under $1,000 for some testing? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ATSC Decode Issues
Hi all, I'm having an issue getting ATSC to decode and I was hoping someone who has done it successfully may have some pointers. Here's the scenario Basic SDR antenna connected to an LNA4ALL feeding into an Airspy sampling at 10 MSPS using the attached flowgraph. I get a TS file and don't get any atsc_fs_checker error warnings while capturing, however the TS file doesn't decode with vlc, ffmpeg, or tsreport. All messages indicate it can't find the codec in the stream which would explain why it can't decode the packets. I've double-checked the local channel frequency (on HDTV ch 34 with a center freq of 593 MHz). The raw signal looks good as does the waterfall for an ATSC signal. I've tried capturing with and without the initial low-pass filter in the attached flowgraph, I've tried using a HackRF at 6.2 MSPS instead of the Airspy at 10 MSPS, tried a true HDTV antenna (although it's 75 Ohm), and horizontal and vertical polarizations on the standard SDR antenna to get the cleanest frequency plot with the best visual SNR. I get there can be some bad packets in any data stream, but for the life of me I can't figure out if there's no errors coming from the decoder and it's decoding successfullly (i.e. producing data with no warnings) why the stream isn't readable. Anyone have any suggestions? Thanks! hdtv_airspy_receiveV2.2.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
