From martin_z_smith at yahoo.ie Tue Sep 1 06:06:30 2015 From: martin_z_smith at yahoo.ie (Martin Smith) Date: Tue, 1 Sep 2015 06:06:30 +0000 (UTC) Subject: 2 out of 3 gains function in Gnuradio for Airspy Message-ID: <493370653.4581600.1441087590829.JavaMail.yahoo@mail.yahoo.com> Hi, There are three gains in the Airspy LNA,MIX and IF. With GQRX these are all accessible and function as expected (https://i.imgur.com/g11kehx.png?1 ). With osmocom_fft these are all accessible and function as expected ( osmocom_fft -a airspy=0 -f 88.5M -s 10M ) ( https://i.imgur.com/4Pu7sP9.png?1 ). But with Gnuradio the MIX gain is not accessible, or the set_bb_gain() in not linked to anything in the case of an Airspy ( https://i.imgur.com/KCTBmsu.jpg?1 ). I can turn "Ch0: BB gain" from its minimum to its maximum value and it changes nothing. If it was broken for all three I would assume that the problem was with the gr-osmosdr block. That it works correctly for two programs that use this block and not correctly for Gnuradio made me suspect that the problem is with Gnuradio. The ticket I logged ( http://gnuradio.org/redmine/issues/834 ) was closed. They let me know that my two out of three guess was wrong and that this is an issue with the gr-osmosdr block, so they kindly pointed me in the direction of this mailing list for help. I would try and debug it further but I have left my zone of knowledge to look any further. Thanks in advance for any help that you can provide, Martin From 246tnt at gmail.com Fri Sep 4 07:20:07 2015 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 4 Sep 2015 09:20:07 +0200 Subject: 2 out of 3 gains function in Gnuradio for Airspy In-Reply-To: <493370653.4581600.1441087590829.JavaMail.yahoo@mail.yahoo.com> References: <493370653.4581600.1441087590829.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hi, > If it was broken for all three I would assume that the problem was with the gr-osmosdr block. That it works correctly for two programs that use this block and not correctly for Gnuradio made me suspect that the problem is with Gnuradio. The ticket I logged ( http://gnuradio.org/redmine/issues/834 ) was closed. They let me know that my two out of three guess was wrong and that this is an issue with the gr-osmosdr block, so they kindly pointed me in the direction of this mailing list for help. > > I would try and debug it further but I have left my zone of knowledge to look any further. > > Thanks in advance for any help that you can provide, There is two way to pilot gains : - The "named" gain stages that are dynamically exposed at runtime to the application and that map directly to each available gain stage. That's what osmocom_fft and gqrx use. - The "fixed" bb / rf / if gains and the mapping of those to the real gain stage is hw specific depending on what you can call BB / RF / IF in that particular architecture. For the airspy, the mapping was defined to not have any gain mapping to BB because the airspy doesn't have any "baseband" gain control. RF gain was mapped to LNA afaict and fixed "IF gain" was mapped to the named "IF gain". I guess it would be more correct to map the fixed IF gain to both the named "mix" and "if" gain and auto-split within the two ... patches welcome. Now GRC (Gnuradio Companion) can only use the "fixed" ones from its UI just because the "named" ones are only available at runtime and GRC doesn't actually _run_ the flowgraph yet when building it, so no way it can know about the named stages. If you write your own custom GR app manually (in python or c++) you can control each gain independently by just using the named gain controls. Cheers, Sylvain From pavel.demin at uclouvain.be Fri Sep 18 12:46:30 2015 From: pavel.demin at uclouvain.be (Pavel Demin) Date: Fri, 18 Sep 2015 14:46:30 +0200 Subject: questions about gr-osmosdr Message-ID: <55FC07A6.1050408@uclouvain.be> Hello, I'm working on the gr-osmosdr blocks for the Red Pitaya SDR transceiver. They are based on the file block with some pieces borrowed from the rtl_tcp block. The new blocks are already working and the code can be found at: https://github.com/pavel-demin/gr-osmosdr/tree/master/lib/red_pitaya My notes about the Red Pitaya SDR transceiver can be found at: http://pavel-demin.github.io/red-pitaya-notes/sdr-transceiver I have two questions that I can't find an answer to: - What would be the best way to implement the push-to-talk (PTT) command? I don't see any method reserved for this kind of functionality in gr-osmosdr/lib/sink_impl.h. I can think of putting it to set_if_gain or set_bb_gain but I'm not sure if it's a good idea. - Once the PTT problem solved, what would be the best way to submit a patch with my modifications? Best regards, Pavel From 246tnt at gmail.com Fri Sep 18 12:53:38 2015 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 18 Sep 2015 14:53:38 +0200 Subject: questions about gr-osmosdr In-Reply-To: <55FC07A6.1050408@uclouvain.be> References: <55FC07A6.1050408@uclouvain.be> Message-ID: Hi, > - What would be the best way to implement the push-to-talk (PTT) command? What do you mean by PTT ? (I mean I know what PTT means in the context of a walkie talkie, but I don't really see how it applies to the red pitaya or gr-osmosdr. Or rather I see several different things it could mean .. ). PS: Hey, someone else than me is doing gnuradio stuff in louvain la neuve ... nice :p Cheers, sylvain From julian at julianoliver.com Fri Sep 18 12:53:49 2015 From: julian at julianoliver.com (Julian Oliver) Date: Fri, 18 Sep 2015 14:53:49 +0200 Subject: // High altitude OsmoSDR with RTLSDR // In-Reply-To: <55FC07A6.1050408@uclouvain.be> References: <55FC07A6.1050408@uclouvain.be> Message-ID: <20150918125349.GA7335@rimu> Hi list, Just thought I'd drop a link to some fun we've been having with RTLSDR and the OsmoSDR Gnu Radio block: https://criticalengineering.org/projects/deep-sweep/ Cheers, -- Julian Oliver http://julianoliver.com http://criticalengineering.org PGP key: https://julianoliver.com/key.asc Beware the auto-complete life. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From pavel.demin at uclouvain.be Fri Sep 18 13:47:25 2015 From: pavel.demin at uclouvain.be (Pavel Demin) Date: Fri, 18 Sep 2015 15:47:25 +0200 Subject: questions about gr-osmosdr In-Reply-To: References: <55FC07A6.1050408@uclouvain.be> Message-ID: <55FC15ED.1090601@uclouvain.be> Hi Sylvain, > What do you mean by PTT ? > > (I mean I know what PTT means in the context of a walkie talkie, but I > don't really see how it applies to the red pitaya or gr-osmosdr. Or > rather I see several different things it could mean .. ). In case of the Red Pitaya SDR transceiver, it's a command to enable or disable the transmitter output and eventually to drive a relay that switches the antenna between the RX path or TX path and/or to control an external amplifier. I've seen that some SDR transceivers (Elad FDM-DUO, FLEX, ANAN) have an output called PTT-Out and graphical user interfaces of some SDR programs (Quisk, PowerSDR, QtRadio) have a button called PTT or MOX that controls the PTT output of the SDR transceivers. So, I thought that it's a common name for this kind of command. Cheers, Pavel From 246tnt at gmail.com Fri Sep 18 13:55:31 2015 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 18 Sep 2015 15:55:31 +0200 Subject: questions about gr-osmosdr In-Reply-To: <55FC15ED.1090601@uclouvain.be> References: <55FC07A6.1050408@uclouvain.be> <55FC15ED.1090601@uclouvain.be> Message-ID: Hi, > In case of the Red Pitaya SDR transceiver, it's a command to enable or > disable the transmitter output and eventually to drive a relay that switches > the antenna between the RX path or TX path and/or to control an external > amplifier. The only thing that's close to this is the UHD auto TX/RX switching It's not really exposed as a different method / function on the gnuradio level, it's handled internally by the hardware / low-level driver. Basically when the hardware doesn't receive any TX sample (i.e underflow), then the hardware is in RX mode. When it starts receiving TX samples, then it auto switch to TX mode (and stops receiving and sending data to the host). Cheers, Sylvain From pavel.demin at uclouvain.be Sat Sep 19 07:47:58 2015 From: pavel.demin at uclouvain.be (Pavel Demin) Date: Sat, 19 Sep 2015 09:47:58 +0200 Subject: questions about gr-osmosdr In-Reply-To: References: <55FC07A6.1050408@uclouvain.be> <55FC15ED.1090601@uclouvain.be> Message-ID: <55FD132E.1090100@uclouvain.be> Thanks for the information about auto TX/RX switching Sylvain! What about my second question? How to submit a patch with my modifications? Should I create a pull request or send a patch file to this list? Cheers, Pavel From 246tnt at gmail.com Sat Sep 19 08:03:57 2015 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 19 Sep 2015 10:03:57 +0200 Subject: questions about gr-osmosdr In-Reply-To: <55FD132E.1090100@uclouvain.be> References: <55FC07A6.1050408@uclouvain.be> <55FC15ED.1090601@uclouvain.be> <55FD132E.1090100@uclouvain.be> Message-ID: Hi, > Thanks for the information about auto TX/RX switching Sylvain! > > What about my second question? How to submit a patch with my modifications? > Should I create a pull request or send a patch file to this list? Send a patch to this list. Try to make sure you match the code style of the project. Dimitri is the maintainer, so you can CC him when you want your patch reviewed and he should either merge it or reply with comments with what to improve. Cheers, Sylvain From picmaster at mail.bg Mon Sep 21 09:50:43 2015 From: picmaster at mail.bg (Nikolay Dimitrov) Date: Mon, 21 Sep 2015 12:50:43 +0300 Subject: [rtl-sdr][PATCH 2/2] rtl_fm: Add squelch timeout In-Reply-To: <1436013743-32758-2-git-send-email-picmaster@mail.bg> References: <1436013743-32758-1-git-send-email-picmaster@mail.bg> <1436013743-32758-2-git-send-email-picmaster@mail.bg> Message-ID: <55FFD2F3.6040502@mail.bg> Hi Dimitri, On 07/04/2015 03:42 PM, Nikolay Dimitrov wrote: > The current squelch logic waits until the received signal drops below > the squelch value and then continues the frequency scan. If there's any > continuous transmission on the air, it will block the scanning process > forever. This patch adds support for squelch timeout to prevent the > scanner from locking forever to a single signal. > > Signed-off-by: Nikolay Dimitrov > --- > src/rtl_fm.c | 21 +++++++++++++++++---- > 1 file changed, 17 insertions(+), 4 deletions(-) Can you please take a look at this patch and decide whether it's worthy of applying to the rtl-sdr tree? Thanks in advance. Regards, Nikolay From picmaster at mail.bg Mon Sep 21 09:49:59 2015 From: picmaster at mail.bg (Nikolay Dimitrov) Date: Mon, 21 Sep 2015 12:49:59 +0300 Subject: [rtl-sdr][PATCH 1/2] rtl_fm: Add scanner progress In-Reply-To: <55FFD242.2080308@mail.bg> References: <1436013743-32758-1-git-send-email-picmaster@mail.bg> <55FFD242.2080308@mail.bg> Message-ID: <55FFD2C7.8090806@mail.bg> Oops, forgot to CC the mailing list. On 09/21/2015 12:47 PM, Nikolay Dimitrov wrote: > Hi Dimitri, > > On 07/04/2015 03:42 PM, Nikolay Dimitrov wrote: >> Add scanner progress, including signal and squelch levels. >> Rename demod_state->conseq_squelch to demod_state->squelch_conseq. >> >> The scanner progress feature can be tested like this: >> >> ./rtl_fm -f 144.000M:146.000M:25k -M fm -s 48k -l 100 -t 5 | aplay \ >> -r 48k -f S16_LE -t raw -c 1 >> >> Signed-off-by: Nikolay Dimitrov >> --- >> src/rtl_fm.c | 43 +++++++++++++++++++++++++++++-------------- >> 1 file changed, 29 insertions(+), 14 deletions(-) > > Can you please take a look at this patch and decide whether it's worthy > of applying to the rtl-sdr tree? > > Thanks in advance. Regards, > Nikolay From syed at outernet.is Sat Sep 26 18:50:10 2015 From: syed at outernet.is (Syed Karim) Date: Sat, 26 Sep 2015 18:50:10 -0000 Subject: Sampling at 250 kHz without aliasing Message-ID: We have a need for a small sample rate on the rtl-sdr. We have been able to select a bandwidth of 250 kHz, but there is significant aliasing at that setting. At higher sample rates the aliasing no longer exists. We are using the dongle that is sold by the RTL-SDR.com blog: http://www.rtl-sdr.com/new-products-rtl-sdr-with-1ppm-tcxo-sma-f-connector-r820t2-bias-tee-improved-tolerances-direct-sampling-break-out-pads-now-available-in-our-store/ Since a reduced sample rate would allow for a much less resource consumption by the CPU, we would gladly sponsor an open source bounty or pay for open source development work to address this problem. Our use case is reception of a 5 kHz channel from a geostationary L-band operator. We have found that the dongle gets very hot at 1550 MHz, so we will use an LNB to downconvert to ~400 MHz. The rest of the RF chain consists of a patch antenna with 8 dBi of gain and 17 dBW EIRP from the spacecraft. The demodulator will be running on a derivative of the Beagle Bone Black. The designs for this board are available here: https://github.com/outernet-project/lantern-compute-pcb You can learn more about Outernet through the following links. http://gizmodo.com/what-is-the-outernet-and-is-it-the-future-of-the-intern-1659647614 http://www.wired.com/2015/07/plan-beam-web-3-billion-unconnected-humans/ http://www.technologyreview.com/news/537411/startup-beams-the-webs-most-important-content-from-space-free/ -------------- next part -------------- An HTML attachment was scrubbed... URL: