Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration
Hi Markus, > 1) Can it be compiled without OpenCL? No. All the data processing is done with OpenCL. > 2) Do you know beignet? Appearantly they try to implement OpenCL support for > Haswell. Yes and this should in time allow to run fosphor. But I don't think they're sufficiently advanced yet to do it. Last time I checked they were missing some features required for fosphor like : - Single channel float textures (sharing with OpenCL into a cl_mem) - Sharing of Vertex Buffer Objects (used for the 'live' spectrum line and the 'max hold' line) Possibly missing more, I was just taking a quick look at the code. I don't have any hardware supporting it ... Might be worth asking the Beignet dev if those are on their roadmap or just implement them yourself, or hack fophor to disable some features temporarely. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Live DVD for i386 ?
I have made a Gnuradio Live DVD named SDRLive for i386 based on Gnuradio 3.7 last November. The main software package on the DVD is Gnuradio, but I added some useful other SDR packages (Quisk, Linrad) plus plotting and audio DSP software as well. I was inspired to do this because I was asked to do a presentation of SDR and of the missing i386 disk and I see the need for a beginner friendly live DVD. I wanted to publish the DVD, but I had to put it on the backburner because of a death in the family. My problem is that I have no place to host the DVD via FTP/HTTP or Bittorrent and I only have a fairly slow rural broadband connection here in northern Scotland, so I want to avoid uploading the 1.8Gb image several times. I am happy to release the DVD if anyone can provide hosting space or point me in a direction where I could do this free of charge. Mark On 02/02/14 20:19, Kristoff Bonne wrote: > Hi all, > > > First, I like to thank everybody at the FOSDEM SDR devroom today. I > really really learned a lot today! > > > > I want to try to use GR for a session on "how dooes a 433 Mhz ISM > signal look like" in our local radio-club. For that, I want to use the > live-CD / DVD of gnuradio so that people can try it out themseelfs. > > > However, at http://gnuradio.org/releases/gnuradio/iso/, I find only > AMD versions of the live DVD. > > > Is there a i386 version available somewhere? > > > > > Cheerio! Kr. Bonne. > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Video Streaming Issue (most probably at receiving end)
Please ask these questions on the mailing list. On 02/03/2014 12:44 PM, Syed Aqeel Raza wrote: > Hi Martin, > > Again, I did some more work and the details are as under. > > 1. I have created a single flowgraph without USRP hardware. For your > reference the file is enclosed with the name of > gmsk_file_transceiver.grc. This work fine and we can see the stream > video output without any difficulty. This does *not* mean your flowgraphs are working. I haven't been able to check them, but there's many things that can go wrong over the air which won't in a simulation. > 2. To continue further I splitted the above mentioned file into > transmitter and receiver side along with the inclusion of USRP source > and sink blocks, respectively. Their flowgraphs are enclosed with the > name of gmsk_tx.grc and gmsk_rx.grc, respectively. The FFT plot shows > that (vdo transmission.png enclosed) transmitter and receiver handshakes > with each other but the signal difference between the transmitter and > the receiver side is 80 dB. I further noticed that whenever I stopped > the transmission the received signal at the receiver further drops to > -120 dB. You are working with relative power levels here, so the dB values don't mean that much. Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] synchronization between blocks
Hi all again, at the moment I thought that the problem was solved, but actually something strange is going on. I would only like to ask whether delay between two paths can roll out somehow (i don't know if this verb exists). The point is that at the beginig of the execution, it looks like the script is doing fine, but then I realize signs of unalligned signals which I can't in some other way. Best Nemanja On Wed, Jan 29, 2014 at 6:52 PM, Nemanja Savic wrote: > Thank you Tom. The problem is that in the configuration that is attached > delay must be arround 600 in order to allign two paths. Next I put a > complex delay block in the second path just after the theottle (and removed > the existing one) and it works fine with 330 (not perfectly alligned but > ok). Is there any other sources of delay that should be accounted. > > > On Wed, Jan 29, 2014 at 4:02 PM, Tom Rondeau wrote: > >> On Wed, Jan 29, 2014 at 4:04 AM, Nemanja Savic wrote: >> >>> Hi all gnuradioers, >>> >>> I have a problem to adjust delay between two paths in my flowgraph, and >>> thus I have a question. The flowgraph is attached. As can be seen, there >>> are two paths from the input. I would call one signal path and the other >>> would be RSSI path. In signal path, signal is first filtered, demodulated >>> and finally in clk_sync_... block the symbols are sliced. The second path >>> is used only for rssi value. At the moment I have problem to adjust delay >>> in rssi path so that correct rssi value is sampled at the moment of >>> sampling symbol values. The only block that introduces delay is filter and >>> it has 331 taps. So when I set delay to 331, the signal are not aligned. Is >>> delay between this two paths constant during execution or not? >>> >>> Best, >>> >>> >>> -- >>> Nemanja Savić >>> >> >> Yes, the delay is constant. But you've set the wrong value. For a >> symmetric FIR filter like you are using, the delay is (N-1)/2. >> >> Tom >> >> >> > > > -- > Nemanja Savić > -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Video Streaming Issue (most probably at receiving end)
The signal level on the transmitter FFT seems very high. Make sure that the IQ samples sent to the USRP are not being clipped. Ron On 2/3/2014 7:54 AM, Syed Aqeel Raza wrote: Hi, Again, I did some more work and the details are as under. 1. I have created a single flowgraph without USRP hardware. For your reference the file is enclosed with the name of gmsk_file_transceiver.grc. This work fine and we can see the stream video output without any difficulty. 2. To continue further I splitted the above mentioned file into transmitter and receiver side along with the inclusion of USRP source and sink blocks, respectively. Their flowgraphs are enclosed with the name of gmsk_tx.grc and gmsk_rx.grc, respectively. The FFT plot shows that (vdo transmission.png enclosed) transmitter and receiver handshakes with each other but the signal difference between the transmitter and the receiver side is 80 dB. I further noticed that whenever I stopped the transmission the received signal at the receiver further drops to -120 dB. I really get stuck in this issue for the last two days. I need your assistant to resolve this problem as I am a newbie in gnuradio using USRP platform. Thanks in advance. Regards, Syed Aqeel Raza ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] help me to design a hierarchical block
Hello every buddy... i want to design my hierarchical block . I go through a gnuradio tutorial but not success fully completed. can any buddy give mea simplified example of any hierarchical block design ... thank you for you time give for this query.. -- *Thanks and regard:* *MR.Maheshkumar Pandit* *call @ 9662784649* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help me to design a hierarchical block
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Maheshkumar, in the GNU Radio companion, in the "options" element, choose "hier block" instead of "wx gui", "qt gui", "no gui"; set a meaningful name here, also! Use pad sinks and pad sources to define your in- and outputs. Save, generate, refresh the block list, and you will find your hier block in the costum blocks category. Greetings, Marcus On 03.02.2014 18:13, Maheshkumar Pandit wrote: > Hello every buddy... > > i want to design my hierarchical block . I go through a gnuradio > tutorial but not success fully completed. can any buddy give mea > simplified example of any hierarchical block design ... > > thank you for you time give for this query.. > > > > ___ Discuss-gnuradio > mailing list Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS79AdAAoJEAFxB7BbsDrLo5MIAKH/Kzb+uOFGAq6Fg639yoxx /7vfeHJnLVT7pJT9O6AjwiZN7swCD9aMHeBJQIh1UHKxsBkmyDPBOmN4/cste8dP MhcIxDgP4KkGPEujX0tPLwwDsMVQjz8IsnBCmFcGZAgU8P3Xrwks8pnmxycEVrO2 AIAf6qkpaOrkqQ0aUwFs+jekU1X+EtgMIw0Zk691Rl6Ob6G1qqtQ/AiJPAYBy2SG DBPVtfehtymekwrPIGcoEMwB1LD2kZhUCmRKMFiUC7BVzYGbFLFLSExwMLZvMvTJ Fd004yft4/sT1ISV6rBNmEyC2ZzR8JJxl2uaRv5DTWLwEr8HRYx4fa3MVOrwwd8= =6eMl -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help me to design a hierarchical block
Hi Maheshkumar, Here's some details on making a hierarchical block when using Gnuradio Companion: 1. From an open GRC flow graph, mouse-select the connected elements that you want to turn into a hierarchical block. The blocks and interconnect will turn green. 2. Right click, then select Create Hier. This will create a new page. There should be Pad Source(s) and/or Sink(s). These are the inputs and outputs of the block,. GRC will provide default names like In, or Out. Double click the Pad Source and edit the label to be something useful. These will be the names of the inputs and outputs when any top_block uses your hierarchical block. 3. If some of the blocks in your hierarchical block have values set by variables (like samp_rate) then those will become parameters in the hierarchical block. If the same variable name was used for several different blocks, you'll get duplicate parameter blocks, colored red (due to dupe naming). For example, if 3 blocks in the hierarchical block all were set by samp_rate, you'll get 3 parameters all with the same name. You would in that case just delete two of those parameter blocks, and leave the variable name in all three GRC blocks set at samp_rate. That parameter name is what top_block sees when it passes something to your hiararchical block. You can have multiple parameters, but the names must be different. 4. Double click the Options block. You may want to edit the Category to be something other than Custom. This affects where the hierarchical block shows up in the block selection menu in GRC. I for example, change it to something appropriate to the function of the new hierarchical block, or leave it as Custom. Also change the ID in the options block to a name that you want to use for your new hierarchical block. This will be the name that is listed in the block picker in GRC. 5. Click the button with the triangle/arrow/circle in the GRC menu bar 'Generate the flow graph'. This will compile the hierarchical block into python code and xml file, and place both files in the ~/.grc_gnuradio folder (hidden by default) in your home directory. It will also ask you to save the GRC hierarchical flowgraph. This allows you to later edit the hierarchical block, or look at it. I usually save it to the desktop, then move it to ~/.grc_gnuradio later on when I'm happy with the block. Having all 3 files (.grc, .py, .xml) in the same folder makes it easier to keep track for stuff (for me). Once you've created the .py and .xml files, you don't actually need the .grc file, but I like to keep it around in case there is a need to understand or change something later on. You can edit the xml file if you wish with a text editor. For example, add your docs can be spelled out as text here tags to the xml to add documentation to your hierarchical block. 6. Close then restart GRC and your new hierarchical block should be available. You can distribute your hierarchical block to others by giving them the 3 files. -- Tom, N5EG From: Maheshkumar Pandit To: discuss-gnuradio@gnu.org; Thomas Rondeau Sent: Monday, February 3, 2014 9:13 AM Subject: [Discuss-gnuradio] help me to design a hierarchical block Hello every buddy... i want to design my hierarchical block . I go through a gnuradio tutorial but not success fully completed. can any buddy give mea simplified example of any hierarchical block design ... thank you for you time give for this query.. -- Thanks and regard: MR.Maheshkumar Pandit call @ 9662784649 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] WebAudio block?
Hi all! First post on the list. Beginner with gnu-radio, so forgive any ignorant questions. I want to build a "receiver" and later on an "analyzer" for signals i hear on WebSDR.org. Does anybody know if a block exists that can pick up the audio from a web-page (in the case of WebSDR a Java applet or HTML5 code) and process that in gnu-radio? Or do i have to short-circuit my audio-out of my computer to the audio-in and just use the audio source block? Thanks, Ton. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] synchronization between blocks
On Feb 3, 2014, at 10:14 AM, Nemanja Savic wrote: > at the moment I thought that the problem was solved, but actually something > strange is going on. I would only like to ask whether delay between two paths > can roll out somehow (i don't know if this verb exists). The point is that at > the beginig of the execution, it looks like the script is doing fine, but > then I realize signs of unalligned signals which I can't in some other way. IIRC: Because of the way GNU Radio internally handles data processing (it waits for data upstream to become available before -starting- processing for a given block), and since -your specific graph- contains only sync blocks (yes?), then the sample delay difference between the 2 branches of -your specific graph- should be constant. Further, it should be the same constant for every graph execution. If any blocks within a specific path are not sync blocks, e.g., a packet decoder, then the sample delay difference is not guaranteed (constant or otherwise). The wall-clock delay difference will not be constant; it can be any non-negative (and, generally > 0) time. All of the above said: If you're into compiling GNU Radio, you can go into gnuradio-runtime/lib/block_executor.cc and set "ENABLE_LOGGING" to 1. Recompile/reinstall GNU Radio, then when you execute your graph you'll get a printout dump of what each block is doing. That printout might help you debug this issue; or, not. You might also add LOG messages in that file which could help ... maybe; or, not. Hope this helps! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Live DVD for i386 ?
Mark, I sometimes distribute image files for the raspberry pi for a number of ham-related projects. For that I used bittorrent. That way, you only need to distribute it once and let the community distribute it further on. If you are interested, I have no issue to distribute the file via bittorrent. I have a Raspberry pi in a datacenter I can use for this. How do you propose you send the file to me. Do you have a NAS I can access to download it. Or, if needed, I can provide you with a ssh account so you can upload the file. Cheerio! Kr. Bonne. On 03-02-14 15:34, M Dammer wrote: I have made a Gnuradio Live DVD named SDRLive for i386 based on Gnuradio 3.7 last November. The main software package on the DVD is Gnuradio, but I added some useful other SDR packages (Quisk, Linrad) plus plotting and audio DSP software as well. I was inspired to do this because I was asked to do a presentation of SDR and of the missing i386 disk and I see the need for a beginner friendly live DVD. I wanted to publish the DVD, but I had to put it on the backburner because of a death in the family. My problem is that I have no place to host the DVD via FTP/HTTP or Bittorrent and I only have a fairly slow rural broadband connection here in northern Scotland, so I want to avoid uploading the 1.8Gb image several times. I am happy to release the DVD if anyone can provide hosting space or point me in a direction where I could do this free of charge. Mark On 02/02/14 20:19, Kristoff Bonne wrote: Hi all, First, I like to thank everybody at the FOSDEM SDR devroom today. I really really learned a lot today! I want to try to use GR for a session on "how dooes a 433 Mhz ISM signal look like" in our local radio-club. For that, I want to use the live-CD / DVD of gnuradio so that people can try it out themseelfs. However, at http://gnuradio.org/releases/gnuradio/iso/, I find only AMD versions of the live DVD. Is there a i386 version available somewhere? Cheerio! Kr. Bonne. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration
Hi Silvain, great - thanks for your answer. I got it run now on OS X via simple macports install. However I will follow the issue from time to time, as I think it would be great to have beignet available for this (and other) purposes. Also I am keen on looking into how the colored spectrum view is implemented by you ( I have no glue and have not yet looked into it). HOWEVER: I did some offline studies on this kind of plots a while ago in python. what I found to look nice was the following idea: Plot like a monochrome FFT with persistence on and where each of the line has some alpha (even the first one). So naturally the more often a peak occurs with the same level, the stronger (or more opaque) the point will be. Then apply a simple jet colormap (or any other suitable colormap) to the monochrome plot. As said, I have not looked into your code yet, chances are you are doing exactly that. This, by the way would not only make sense for the spectrum view, but also for the scope as it gives some nice colored eye-diagrams. Also I read earlier, that someone was asking about the benefit of this kind of plot with respect to a simple FFT (with persistence). The benefit of course is that you can see the probability distribution at frequency points of interest (f = const-line) and that you still see single occurring events, as they will not be very weak as in a FFT with persistence, but have some dedicated good visible color for a while. Markus Am 03.02.2014 um 09:21 schrieb Sylvain Munaut <246...@gmail.com>: > Hi Markus, > > >> 1) Can it be compiled without OpenCL? > > No. All the data processing is done with OpenCL. > > >> 2) Do you know beignet? Appearantly they try to implement OpenCL support for >> Haswell. > > Yes and this should in time allow to run fosphor. > > But I don't think they're sufficiently advanced yet to do it. Last > time I checked they were missing some features required for fosphor > like : > - Single channel float textures (sharing with OpenCL into a cl_mem) > - Sharing of Vertex Buffer Objects (used for the 'live' spectrum line > and the 'max hold' line) > > Possibly missing more, I was just taking a quick look at the code. I > don't have any hardware supporting it ... > > Might be worth asking the Beignet dev if those are on their roadmap or > just implement them yourself, or hack fophor to disable some features > temporarely. > > > Cheers, > >Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration
Hi, > However I will follow the issue from time to time, as I think it would be > great to have beignet available for this (and other) purposes. Yes, it'd be great and I would love if a beignet dev was also interested and SDR and tried to make it work and implement the missing stuff. Or a SDR guy experience in GPU programming that could hack both in beignet and fosphor. > Also I am keen on looking into how the colored spectrum view is implemented > by you ( I have no glue and have not yet looked into it). HOWEVER: I did some > offline studies on this kind of plots a while ago in python. what I found to > look nice was the following idea: > > Plot like a monochrome FFT with persistence on and where each of the line has > some alpha (even the first one). So naturally the more often a peak occurs > with the same level, the stronger (or more opaque) the point will be. Then > apply a simple jet colormap (or any other suitable colormap) to the > monochrome plot. As said, I have not looked into your code yet, chances are > you are doing exactly that. Actually that's not at all implemented like this at all. You might want to look at my grcon slides for more info. The code is pretty well optimized (from a math point of view) which makes it a bit hard to understand wtf is going on ... What you describe is closer to what's implemented in the 'persistence' mode of the WX sink. However it doesn't look as good but that might be because the WX sink has much less spectra/second processed. > This, by the way would not only make sense for the spectrum view, but also > for the scope as it gives some nice colored eye-diagrams. Yes, that'd probably be nice to try as well. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Video Streaming Issue (most probably at receiving end)
Hi Ron, Thanks for your suggestion. It works for me :) Regards, Syed Aqeel Raza On Mon, Feb 3, 2014 at 11:54 PM, Syed Aqeel Raza wrote: > Hi, > > Again, I did some more work and the details are as under. > > 1. I have created a single flowgraph without USRP hardware. For your > reference the file is enclosed with the name of gmsk_file_transceiver.grc. > This work fine and we can see the stream video output without any > difficulty. > > 2. To continue further I splitted the above mentioned file into > transmitter and receiver side along with the inclusion of USRP source and > sink blocks, respectively. Their flowgraphs are enclosed with the name of > gmsk_tx.grc and gmsk_rx.grc, respectively. The FFT plot shows that (vdo > transmission.png enclosed) transmitter and receiver handshakes with each > other but the signal difference between the transmitter and the receiver > side is 80 dB. I further noticed that whenever I stopped the transmission > the received signal at the receiver further drops to -120 dB. > > I really get stuck in this issue for the last two days. I need your > assistant to resolve this problem as I am a newbie in gnuradio using USRP > platform. > > Thanks in advance. > > Regards, > Syed Aqeel Raza > > > > > > > > > > > > On Sat, Feb 1, 2014 at 11:36 AM, Syed Aqeel Raza wrote: > >> Hi Martin, >> >> Thanks for your reply. >> >> I have made some changes in the flowgraphs due to which the transmitter >> and receiver sides handshakes with each other. Despite of this handshaking, >> the receiver side is not produced the required baseband signal. >> Furthermore, I have designed a single flowgraph that comprises on >> transmitter and receiver without the inclusion of USRP source and sink >> block. That single flowgraph works fine and perfectly streaming the video. >> >> I will send the updated flowgraphs to you by tomorrow. >> >> Regards, >> Syed Aqeel Raza >> >> >> On Sat, Feb 1, 2014 at 8:05 PM, Martin Braun wrote: >> >>> On 30.01.2014 18:17, Syed Aqeel Raza wrote: >>> I have checked the transmission part, which is working perfectly by transmitting a video stream over the wireless. Whereas, no video reception is displayed on receiver end. >>> >>> How did you test the transmitter? >>> >>> >>> For further reference, I have attached the flow charts used for transmission and reception of video streaming. An earliest reply is highly appreciated. >>> >>> There's many things that can go wrong here. Does your rx spectrum look >>> good? >>> >>> MB >>> >>> >> > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
