Re: [Discuss-gnuradio] Setting up a simple packet radio in 3.7.7.2
Hi Julian, I managed to finally get data across…I was leaving the payload to automatic (0) and it turns out I was sending messages less than the default of 512…I knew it had to be something simple and there it is. I change the payload to 8 and now it will send messages greater than 8 characters long in the terminal. Thanks for the help! Priyank From: discuss-gnuradio-bounces+priyank.patel=gtri.gatech@gnu.org [mailto:discuss-gnuradio-bounces+priyank.patel=gtri.gatech@gnu.org] On Behalf Of Patel, Priyank Sent: Tuesday, August 25, 2015 10:17 AM To: Julian Arnold julian.arn...@ettus.com Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Setting up a simple packet radio in 3.7.7.2 Hi Julian, I've verified that it works with the setup you provided (it was very similar to a test I did initially before I switched to TCP sources/sinks). The reason I want to use a TCP source/sink is that I want to be able to send application data through the radio (fairly slow and small data packets, i.e. occasional application commands). I then switched over the Time sink to a TCP sink: address 127.0.0.1, port 9001, client mode I ran the code again with the sine wave still outputting as the source and opened up a terminal with nc -l 9001 (to connect to the tcp sink client). I was immediately able to see the data was flowing through still (it was garbled, but data regardless in the terminal window). I then switched the Signal Source to the TCP source: address 127.0.0.1, port 9000, server mode I ran the code again and got nothing as I entered data into the TCP source terminal window (using nc 127.0.0.1 9000). I added a QT GUI Number sink to the output of the encoder and saw that the output as always 0. I believe I am still getting blocked at the packet encoder whenever I use my TCP source. I've tried changing the data links between the TCP source/sink and Packet Encoder/Decoder to bytes, but still didn't change the output of the encoder at always being 0. Any other ideas? I feel like there must be some simple setting or method I am using incorrectly at this point. Thanks for your help! Priyank From: Julian Arnold julian.arn...@ettus.commailto:julian.arn...@ettus.com Sent: Tuesday, August 25, 2015 5:04 AM To: Patel, Priyank Cc: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Setting up a simple packet radio in 3.7.7.2 Hi Priyank, I rebuild your setup without the TCP source and it is working for me [1]. Can you run it without using TCP? You have to wait a little for the output to appear on time sink though. Is there something I need to do for the terminal messages I am sending through the tcp-source in order for the encoder block to properly process it? No, generally everything should be handled within the packet encoder. [1] [cid:image001.jpg@01D0DF36.D8D3C690] Cheers, Julian On Mon, Aug 24, 2015 at 9:47 PM, Patel, Priyank priyank.pa...@gtri.gatech.edumailto:priyank.pa...@gtri.gatech.edu wrote: Hi Julian, Thanks for responding so quickly! I've attached a picture of the current setup (if it gets through). I've tried looking at the output of the encoder and am seeing nothing come out of it and so there is no signal from that point on (through the gmsk mod-gmsk demod-decoder-tcp-sink). Is there something I need to do for the terminal messages I am sending through the tcp-source in order for the encoder block to properly process it? I am currently just simulating it locally by going directly between the gmsk-mod-gmsk-demod as I wanted to make sure everything goes through before I add in the USRPs. Thanks, Priyank From: julian.arn...@ettus.commailto:julian.arn...@ettus.com julian.arn...@ettus.commailto:julian.arn...@ettus.com Sent: Monday, August 24, 2015 3:16 PM To: Patel, Priyank Cc: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Setting up a simple packet radio in 3.7.7.2 Hi Priyank, The packet decoder is checking for a preamble sequence in the data stream. If there is no output coming from the decoder the preamble is probably not being detected. How does the output of the gmsk demod look like? Also, are you transmitting the signal or are you just simulating locally? Cheers, Julian Am 24.08.2015 um 21:05 schrieb Patel, Priyank priyank.pa...@gtri.gatech.edumailto:priyank.pa...@gtri.gatech.edu: Hello, I am trying to get a simple packet radio GRC working but so far have had no luck with the following scheme: tcp-source (port 9000) - packet encoder - gmsk mod - gmsk demod - packet decoder - tcp-sink (port 9001) If I remove the encoder/decoder and the gmsk mod/demod and go directly between the ports, then I am able to clearly see everything (I am using two terminals, one for tcp source and one for tcp sink). If I add back in the gmsk mod/demod I see stuff in my
Re: [Discuss-gnuradio] USRP's not Communicating
Ah sorry I wasn't specific. This was from years ago, the numbers I used were just meant to be an example, not accurate. On Tue, Aug 25, 2015 at 10:25 PM, Marcus D. Leech mle...@ripnet.com wrote: On 08/25/2015 10:17 PM, devin kelly wrote: You can have each USRP on the same computer or not, that shouldn't matter. I've done this test with some USRP2's and I remember what we did was transmit a CW tone from one to another and measure a frequency offset (maybe 10s of kHz?). Basically, transmit a tone at some known frequency (like 200 MHz) and measure the received frequency (maybe something like 200.02 MHz) and then add the 0.02 into you center frequency for this test. You can also just synchronize the USRPs with a 10MHz reference and 1PPS. Devin The USRP2 uses a 2.5PPM master on-board clock, so at 200Mhz tuned frequency, the max it can be off is about 500Hz. For narrowband transmission, that may be too much, but I'd be very surprised to see 20kHz offset with a 200MHz carrier. On Tue, Aug 25, 2015 at 5:14 PM, John Garrick li...@ruby-forum.com wrote: Hello, I want to transmit the data between two USRP's and make them communicate with each other. But I guess the packets are not being received properly. I am connected the two USRP's to the same laptop and trying it. Is that applicable? I mean, will it work if I do that? Or should I connect to two computers and perform that? I have been receiving this error. linux; GNU C++ version 4.8.4; Boost_105500; UHD_003.009.git-144-g407e3086 Using Volk machine: avx_64_mmx -- Opening a USRP1 device... -- Using FPGA clock rate of 64.00MHz... No gain specified. Setting gain to 56.25 (from [0.00, 112.50]) UHD Warning: The hardware does not support the requested RX sample rate: Target sample rate: 0.05 MSps Actual sample rate: 0.25 MSps Symbol Rate: 25000.00 Requested sps: 2.00 Given sample rate: 25.00 Actual sps for rate: 10.00 Requested sample rate: 5.00 Actual sample rate: 25.00 ok = False pktno = 53034 n_rcvd =1 n_right =0 ok = False pktno = 24 n_rcvd =2 n_right =0 ok = False pktno = 35 n_rcvd =3 n_right =0 ok = False pktno = 44 n_rcvd =4 n_right =0 ok = False pktno = 46 n_rcvd =5 n_right =0 ok = False pktno = 46 n_rcvd =6 n_right =0 ok = False pktno = 3872 n_rcvd =7 n_right =0 ok = False pktno = 12304 n_rcvd =8 n_right =0 ok = False pktno = 49 n_rcvd =9 n_right =0 ok = False pktno = 50 n_rcvd = 10 n_right =0 ok = False pktno = 54 n_rcvd = 11 n_right =0 ok = False pktno = 200 n_rcvd = 12 n_right =0 ok = False pktno = 63 n_rcvd = 13 n_right =0 Please suggest. Thank you Regards, Ravi -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://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] USRP's not Communicating
On 08/25/2015 10:17 PM, devin kelly wrote: You can have each USRP on the same computer or not, that shouldn't matter. I've done this test with some USRP2's and I remember what we did was transmit a CW tone from one to another and measure a frequency offset (maybe 10s of kHz?). Basically, transmit a tone at some known frequency (like 200 MHz) and measure the received frequency (maybe something like 200.02 MHz) and then add the 0.02 into you center frequency for this test. You can also just synchronize the USRPs with a 10MHz reference and 1PPS. Devin The USRP2 uses a 2.5PPM master on-board clock, so at 200Mhz tuned frequency, the max it can be off is about 500Hz. For narrowband transmission, that may be too much, but I'd be very surprised to see 20kHz offset with a 200MHz carrier. On Tue, Aug 25, 2015 at 5:14 PM, John Garrick li...@ruby-forum.com mailto:li...@ruby-forum.com wrote: Hello, I want to transmit the data between two USRP's and make them communicate with each other. But I guess the packets are not being received properly. I am connected the two USRP's to the same laptop and trying it. Is that applicable? I mean, will it work if I do that? Or should I connect to two computers and perform that? I have been receiving this error. linux; GNU C++ version 4.8.4; Boost_105500; UHD_003.009.git-144-g407e3086 Using Volk machine: avx_64_mmx -- Opening a USRP1 device... -- Using FPGA clock rate of 64.00MHz... No gain specified. Setting gain to 56.25 (from [0.00, 112.50]) UHD Warning: The hardware does not support the requested RX sample rate: Target sample rate: 0.05 MSps Actual sample rate: 0.25 MSps Symbol Rate: 25000.00 Requested sps: 2.00 Given sample rate: 25.00 Actual sps for rate: 10.00 Requested sample rate: 5.00 Actual sample rate: 25.00 ok = False pktno = 53034 n_rcvd =1 n_right =0 ok = False pktno = 24 n_rcvd =2 n_right =0 ok = False pktno = 35 n_rcvd =3 n_right =0 ok = False pktno = 44 n_rcvd =4 n_right =0 ok = False pktno = 46 n_rcvd =5 n_right =0 ok = False pktno = 46 n_rcvd =6 n_right =0 ok = False pktno = 3872 n_rcvd =7 n_right =0 ok = False pktno = 12304 n_rcvd =8 n_right =0 ok = False pktno = 49 n_rcvd =9 n_right =0 ok = False pktno = 50 n_rcvd = 10 n_right =0 ok = False pktno = 54 n_rcvd = 11 n_right =0 ok = False pktno = 200 n_rcvd = 12 n_right =0 ok = False pktno = 63 n_rcvd = 13 n_right =0 Please suggest. Thank you Regards, Ravi -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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] USRP's not Communicating
You can have each USRP on the same computer or not, that shouldn't matter. I've done this test with some USRP2's and I remember what we did was transmit a CW tone from one to another and measure a frequency offset (maybe 10s of kHz?). Basically, transmit a tone at some known frequency (like 200 MHz) and measure the received frequency (maybe something like 200.02 MHz) and then add the 0.02 into you center frequency for this test. You can also just synchronize the USRPs with a 10MHz reference and 1PPS. Devin On Tue, Aug 25, 2015 at 5:14 PM, John Garrick li...@ruby-forum.com wrote: Hello, I want to transmit the data between two USRP's and make them communicate with each other. But I guess the packets are not being received properly. I am connected the two USRP's to the same laptop and trying it. Is that applicable? I mean, will it work if I do that? Or should I connect to two computers and perform that? I have been receiving this error. linux; GNU C++ version 4.8.4; Boost_105500; UHD_003.009.git-144-g407e3086 Using Volk machine: avx_64_mmx -- Opening a USRP1 device... -- Using FPGA clock rate of 64.00MHz... No gain specified. Setting gain to 56.25 (from [0.00, 112.50]) UHD Warning: The hardware does not support the requested RX sample rate: Target sample rate: 0.05 MSps Actual sample rate: 0.25 MSps Symbol Rate: 25000.00 Requested sps: 2.00 Given sample rate: 25.00 Actual sps for rate: 10.00 Requested sample rate: 5.00 Actual sample rate: 25.00 ok = False pktno = 53034 n_rcvd =1 n_right =0 ok = False pktno = 24 n_rcvd =2 n_right =0 ok = False pktno = 35 n_rcvd =3 n_right =0 ok = False pktno = 44 n_rcvd =4 n_right =0 ok = False pktno = 46 n_rcvd =5 n_right =0 ok = False pktno = 46 n_rcvd =6 n_right =0 ok = False pktno = 3872 n_rcvd =7 n_right =0 ok = False pktno = 12304 n_rcvd =8 n_right =0 ok = False pktno = 49 n_rcvd =9 n_right =0 ok = False pktno = 50 n_rcvd = 10 n_right =0 ok = False pktno = 54 n_rcvd = 11 n_right =0 ok = False pktno = 200 n_rcvd = 12 n_right =0 ok = False pktno = 63 n_rcvd = 13 n_right =0 Please suggest. Thank you Regards, Ravi -- Posted via http://www.ruby-forum.com/. ___ 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] Capturing DMR (MOTOTRBO) data with gnuradio
Hello there, I am trying to capture DMR/MOTOTRBO data packets (not voice) with gnuradio. I have found gr-dsd block that successfully decodes the signal in question. Only problem is that gr-dsd does not unpack the data packets, it only outputs voice audio (float). All I get from gr-dsd (apart from voice) is output like this (in terminal): [slot0] slot1 Slot idle slot0 [slot1] CSBK [slot0] slot1 Slot idle slot0 [slot1] CSBK [slot0] slot1 Slot idle slot0 [slot1] RATE 1/2 DATA [slot0] slot1 Slot idle slot0 [slot1] CSBK [slot0] slot1 Slot idle slot0 [slot1] RATE 1/2 DATA ... The target system is Ubuntu 14.04LTS (if it makes any difference). Another option is not to use gr-dsd, but plainly demodulate the signal with C4FM/4FSK (for which I am yet to find a stand alone demodulator that works with current gnuradio), and then cut out the data in post. I have looked at the gr-dsd source and it is way too complicated for my skill set to modify it to output data as byte stream. I have tried to install gr-op25 (just so I can use 4FSK demod block), but it was way too heavy (way too many dependencies). I failed to install gr-fsk4 ( http://vk2lk.com/Wireless/Franks/GnuradioFourLevelFSK.html), it looks like it is incompatible with current gnuradio (it fails on missing gnuradio-core). I suspect it is possible to come up with 4FSK demod with just using standard gnuradio blocks, my understanding of signal processing is very limited... TL;DR: how can I extract the byte contents out of DMR data packets with gnuradio? Thanks a lot! Sergei. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Padding burtsy blocks
Hi Devin, the padding with zeros unless samples occur within a specific time job can be done with gr-eventstream [1] [2] , but: If you're going to use USRP sink anyway, what about using tagged stream blocks[3]? You could replace your Pull Source with a Pull Message Source - PDU to tagged stream-signal processing-USRP Sink (with packet length tag name set accordingly) Best regards, Marcus [1] https://github.com/osh/gr-eventstream [2] http://oshearesearch.com/tag/gr-eventstream/ [3] https://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html On 25.08.2015 04:00, devin kelly wrote: I have a flowgraph that I'm trying to develop in simulation first before deploying to some sort of hardware like a USRP. The flowgraph begins with a ZMQ Pull Source and then I have all my signal processing blocks afterwards (eventually there would be a UHD Sink). The ZMQ block only produces samples when it receives a message so when it doesn't receive samples the flowgraph doesn't run. If the work function for any block is only called when there are samples in the input buffer I don't see how adding any blocks after my ZMQ Pull Source could help. So that leaves making my own ZMQ Pull Source that emits zeros when it has no other message. Do I have any other options? If I add a this feature would be useful to merge back into GR or is this not really an intended use case for GR? Thanks, Devin ___ 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] Better approach for FEC
Hi, I have a burst system in gnuradio which is working fine with usrps. I have used tags (tx_time, tx_eob and tx_sob) to define packet boundaries and transmission time. Tags are inserted by a block which is connected before the usrp sink. I did not use any tagged stream block in the burst system. All the blocks used are streaming blocks. Now I want to insert FEC in my system. After going through the FEC API, I realized that I can use any of FEC deployments (Streaming, Tagged stream, Asynchronus). Are there any difference(s) performance wise? Which one should is better for my system? I have attached a picture of my current system and identified where I want to insert FEC in tx and rx. Comments are appreciated. -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
Hi Andreas, thanks for the hint. However I am using a Ettus B200 and do not have access to a different SDR right now. I will test outside and then trying to find out what is going on. BR Mike Hi Michael, i read your mail and i could remember i had a similar problem with a lot of lost sync and bad block messages. My solution was to use a different RTL USB stick and to play with antenna type / antenna position and the gain of the RTL stick. I used a classical lamda / 2 dipol UKW Radio antenna. The stick was a noname. regards, Andreas Am 23.08.2015 um 20:02 schrieb Michael Thelen DK4MT: Hi Marcus, thanks, tried your script and found out, that it is always a little bit uncomely if something is not really reproducible. This is the status: With your script I did not get the earlier error anymore. However with my original I did not get it either. Instead I get the following message in GRC: @ Sync State Detected @ Lost Sync (Got 50 bad blocks on 50 total) I do not get this message if I run your script. Both scripts though do not show RDS information. So before I steal somebody's time I wonder if one reason could be, that I can only receive one station really at the limit and only if I set gain to a max. I can hear fairly clear audio, but I am not sure if I can conclude from, that RDS decoding should work. I am pretty much insulated from RF at my place. What would be in favor by people being sensitive to EM waves, but for experimenting it is pretty bad. So I might gonna check this outside, where I can see in my car, that RDS reception is working on my radio and then I can compare. Just want to make sure we or you aren't chasing an error which might be based on poor reception. However the messages in the terminal have been there last time and the I copied to also were there. Still don't no if this is part of the problem though. Therefore probably more testing on my side. Best regards, Mike Hi Mike, dashed only means message port connection rather than item stream, so that's nothing to worry about, usually. So the bad news is that this is possible a GRC bug, which on the other hand is good news, because it means that gr-rds isn't broken, GRC just has a hard time correctly generating the python file. Since that worked for me: can you try the attached python file? Best regards, Marcus On 22.08.2015 11:26, Michael Thelen DK4MT wrote: Hi, I am using GNU Radio 3.7.7.2 and I checked out out and built gr-rds. However RDS Decoding is not working. I found that there are to two connections have dashed lines (see picture). And in the terminal all I get is Error: Cannot create connection. But I could not find a hint, what is going wrong. Can somebody tell me, what to check for? Best regards, Mike ___ 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP's not Communicating
Hello, I want to transmit the data between two USRP's and make them communicate with each other. But I guess the packets are not being received properly. I am connected the two USRP's to the same laptop and trying it. Is that applicable? I mean, will it work if I do that? Or should I connect to two computers and perform that? I have been receiving this error. linux; GNU C++ version 4.8.4; Boost_105500; UHD_003.009.git-144-g407e3086 Using Volk machine: avx_64_mmx -- Opening a USRP1 device... -- Using FPGA clock rate of 64.00MHz... No gain specified. Setting gain to 56.25 (from [0.00, 112.50]) UHD Warning: The hardware does not support the requested RX sample rate: Target sample rate: 0.05 MSps Actual sample rate: 0.25 MSps Symbol Rate: 25000.00 Requested sps: 2.00 Given sample rate: 25.00 Actual sps for rate: 10.00 Requested sample rate: 5.00 Actual sample rate: 25.00 ok = False pktno = 53034 n_rcvd =1 n_right =0 ok = False pktno = 24 n_rcvd =2 n_right =0 ok = False pktno = 35 n_rcvd =3 n_right =0 ok = False pktno = 44 n_rcvd =4 n_right =0 ok = False pktno = 46 n_rcvd =5 n_right =0 ok = False pktno = 46 n_rcvd =6 n_right =0 ok = False pktno = 3872 n_rcvd =7 n_right =0 ok = False pktno = 12304 n_rcvd =8 n_right =0 ok = False pktno = 49 n_rcvd =9 n_right =0 ok = False pktno = 50 n_rcvd = 10 n_right =0 ok = False pktno = 54 n_rcvd = 11 n_right =0 ok = False pktno = 200 n_rcvd = 12 n_right =0 ok = False pktno = 63 n_rcvd = 13 n_right =0 Please suggest. Thank you Regards, Ravi -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-rds
Hi Mike, the B200 should usually be a little more reliable than the RTL dongles; what gain setting are you using? Best regards, Marcus On 08/25/2015 02:08 PM, Michael Thelen DK4MT wrote: Hi Andreas, thanks for the hint. However I am using a Ettus B200 and do not have access to a different SDR right now. I will test outside and then trying to find out what is going on. BR Mike Hi Michael, i read your mail and i could remember i had a similar problem with a lot of lost sync and bad block messages. My solution was to use a different RTL USB stick and to play with antenna type / antenna position and the gain of the RTL stick. I used a classical lamda / 2 dipol UKW Radio antenna. The stick was a noname. regards, Andreas Am 23.08.2015 um 20:02 schrieb Michael Thelen DK4MT: Hi Marcus, thanks, tried your script and found out, that it is always a little bit uncomely if something is not really reproducible. This is the status: With your script I did not get the earlier error anymore. However with my original I did not get it either. Instead I get the following message in GRC: @ Sync State Detected @ Lost Sync (Got 50 bad blocks on 50 total) I do not get this message if I run your script. Both scripts though do not show RDS information. So before I steal somebody's time I wonder if one reason could be, that I can only receive one station really at the limit and only if I set gain to a max. I can hear fairly clear audio, but I am not sure if I can conclude from, that RDS decoding should work. I am pretty much insulated from RF at my place. What would be in favor by people being sensitive to EM waves, but for experimenting it is pretty bad. So I might gonna check this outside, where I can see in my car, that RDS reception is working on my radio and then I can compare. Just want to make sure we or you aren't chasing an error which might be based on poor reception. However the messages in the terminal have been there last time and the I copied to also were there. Still don't no if this is part of the problem though. Therefore probably more testing on my side. Best regards, Mike Hi Mike, dashed only means message port connection rather than item stream, so that's nothing to worry about, usually. So the bad news is that this is possible a GRC bug, which on the other hand is good news, because it means that gr-rds isn't broken, GRC just has a hard time correctly generating the python file. Since that worked for me: can you try the attached python file? Best regards, Marcus On 22.08.2015 11:26, Michael Thelen DK4MT wrote: Hi, I am using GNU Radio 3.7.7.2 and I checked out out and built gr-rds. However RDS Decoding is not working. I found that there are to two connections have dashed lines (see picture). And in the terminal all I get is Error: Cannot create connection. But I could not find a hint, what is going wrong. Can somebody tell me, what to check for? Best regards, Mike ___ 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 ___ 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-rds
Hi Marcus, I hoped so, that is why I bought one ;-). I think the max is 73dB. The actual value I set with a slider is 90dB. Thus I am pretty much maxed out there. But like I wrote earlier, that is the only way to receive at least one station. Don't have good RF working conditions. Even cellular is a problem. BR Mike Hi Mike, the B200 should usually be a little more reliable than the RTL dongles; what gain setting are you using? Best regards, Marcus On 08/25/2015 02:08 PM, Michael Thelen DK4MT wrote: Hi Andreas, thanks for the hint. However I am using a Ettus B200 and do not have access to a different SDR right now. I will test outside and then trying to find out what is going on. BR Mike Hi Michael, i read your mail and i could remember i had a similar problem with a lot of lost sync and bad block messages. My solution was to use a different RTL USB stick and to play with antenna type / antenna position and the gain of the RTL stick. I used a classical lamda / 2 dipol UKW Radio antenna. The stick was a noname. regards, Andreas Am 23.08.2015 um 20:02 schrieb Michael Thelen DK4MT: Hi Marcus, thanks, tried your script and found out, that it is always a little bit uncomely if something is not really reproducible. This is the status: With your script I did not get the earlier error anymore. However with my original I did not get it either. Instead I get the following message in GRC: @ Sync State Detected @ Lost Sync (Got 50 bad blocks on 50 total) I do not get this message if I run your script. Both scripts though do not show RDS information. So before I steal somebody's time I wonder if one reason could be, that I can only receive one station really at the limit and only if I set gain to a max. I can hear fairly clear audio, but I am not sure if I can conclude from, that RDS decoding should work. I am pretty much insulated from RF at my place. What would be in favor by people being sensitive to EM waves, but for experimenting it is pretty bad. So I might gonna check this outside, where I can see in my car, that RDS reception is working on my radio and then I can compare. Just want to make sure we or you aren't chasing an error which might be based on poor reception. However the messages in the terminal have been there last time and the I copied to also were there. Still don't no if this is part of the problem though. Therefore probably more testing on my side. Best regards, Mike Hi Mike, dashed only means message port connection rather than item stream, so that's nothing to worry about, usually. So the bad news is that this is possible a GRC bug, which on the other hand is good news, because it means that gr-rds isn't broken, GRC just has a hard time correctly generating the python file. Since that worked for me: can you try the attached python file? Best regards, Marcus On 22.08.2015 11:26, Michael Thelen DK4MT wrote: Hi, I am using GNU Radio 3.7.7.2 and I checked out out and built gr-rds. However RDS Decoding is not working. I found that there are to two connections have dashed lines (see picture). And in the terminal all I get is Error: Cannot create connection. But I could not find a hint, what is going wrong. Can somebody tell me, what to check for? Best regards, Mike ___ 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 ___ 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
