Hi Marcus, Is this the only type of GPS antenna that I can use on the Octoclock-G? https://www.ettus.com/product/details/GPS-ANT-3V
Or can I use any other type of antenna at 1.57 GHz or 1.23 GHz? On Fri, Jul 8, 2016 at 1:33 PM, Pavan Yedavalli <psy2...@columbia.edu> wrote: > The 1 PPS is flashing - it just wasn't flashing in the picture that I sent > (captured the pic at the wrong time), so that appears to be working, but > the GPS lock has never been on, I believe. > > I know that when I turn off the Octoclock-G, the received signals are all > over the place, but with the Octoclock-G on, the received signals are much > more coherent (just at the problem of completely random offsets). I figured > that's confirmation that all of them are getting the proper 10 MHz > reference clock, but maybe not? Thanks! > > On Fri, Jul 8, 2016 at 1:24 PM, <mle...@ripnet.com> wrote: > >> Pavan: >> >> Do you have any way of verifying that you have 1PPS and 10MHz coming out >> of those ports on the Octoclock-G, as seen at the ends of the cables? >> [Looking for both the broken-Octoclock and broken-cables case]. >> >> >> >> >> >> >> >> >> On 2016-07-08 00:12, Pavan Yedavalli wrote: >> >> It's an Octoclock-G (https://www.ettus.com/product/details/OctoClock-G >> is what I ordered). And yes, that is true about the external clock inputs >> and GPS lock. Does that matter if it's an Octoclock-G? >> >> On Thu, Jul 7, 2016 at 7:46 PM, <mle...@ripnet.com> wrote: >> >>> Is this an Octoclock, or Octoclock-G? >>> >>> If it's just an Octoclock, then it has no internal clocks, and acts as a >>> high-quality clock/pps distributor. >>> >>> I notice you don't have the external clock inputs connected to anything, >>> and there's no GPS LOCK indicator. >>> >>> >>> >>> >>> >>> >>> >>> >>> On 2016-07-07 17:08, Pavan Yedavalli wrote: >>> >>> Hi Marcus, >>> >>> I did what you suggested by wrapping the timed commands as follows: >>> >>> For the TX side (what you sent me in for_pavan.py): >>> >>> self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec()) >>> now = self.uhd_usrp_source_0.get_time_now() >>> start_time = now + uhd.time_spec(.5) >>> self.uhd_usrp_source_0.set_command_time(start_time) >>> self.uhd_usrp_source_0.set_clock_source("external", 0) >>> self.uhd_usrp_source_0.set_time_source("external", 0) >>> self.uhd_usrp_source_0.set_clock_source("external", 1) >>> self.uhd_usrp_source_0.set_time_source("external", 1) >>> self.uhd_usrp_source_0.set_samp_rate(samp_rate) >>> self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec()) >>> self.uhd_usrp_source_0.set_center_freq(rx_center_freq, 0) >>> self.uhd_usrp_source_0.set_normalized_gain(rx_gain, 0) >>> self.uhd_usrp_source_0.set_antenna(Antenna_sel, 0) >>> self.uhd_usrp_source_0.set_center_freq(rx_center_freq, 1) >>> self.uhd_usrp_source_0.set_normalized_gain(rx_gain, 1) >>> self.uhd_usrp_source_0.set_antenna("TX/RX", 1) >>> self.uhd_usrp_source_0.clear_command_time() >>> >>> And for the RX side (B210_Phase_Viewer.py): >>> >>> self.uhd_usrp_sink_0.set_time_unknown_pps(uhd.time_spec()) >>> now = self.uhd_usrp_sink_0.get_time_now() >>> start_time = now + uhd.time_spec(.5) >>> self.uhd_usrp_sink_0.set_command_time(start_time) >>> self.uhd_usrp_sink_0.set_clock_source("external", 0) >>> self.uhd_usrp_sink_0.set_time_source("external", 0) >>> self.uhd_usrp_sink_0.set_subdev_spec("A:0", 0) >>> self.uhd_usrp_sink_0.set_clock_source("external", 1) >>> self.uhd_usrp_sink_0.set_time_source("external", 1) >>> self.uhd_usrp_sink_0.set_subdev_spec("A:0", 1) >>> self.uhd_usrp_sink_0.set_samp_rate(samp_rate) >>> self.uhd_usrp_sink_0.set_center_freq(915e6, 0) >>> self.uhd_usrp_sink_0.set_gain(1.5, 0) >>> self.uhd_usrp_sink_0.set_center_freq(915e6, 1) >>> self.uhd_usrp_sink_0.set_gain(1.5, 1) >>> self.uhd_usrp_sink_0.clear_command_time() >>> >>> >>> However, it still does not work when I have the phase viewer running and >>> stop and restart the for_pavan.py flowgraph. I had a run of three straight >>> where the phase offset was around 11 degrees, but then afterward it started >>> fluctuating again (-140, 45, 81 degrees, etc.). >>> >>> Attached is the front of the Octoclock. I believe the settings are >>> correct, but maybe something is wrong with that. Note that the PPS flashes >>> (but I couldn't capture when it flashed in the picture). Also note that I >>> get the thread priority warning when running each of them, but I don't >>> think that is a problem. >>> >>> I am really not sure what the issue is here, sadly. Thanks again for >>> your help and patience. >>> >>> >>> On Wed, Jul 6, 2016 at 6:22 PM, Marcus D. Leech <mle...@ripnet.com> >>> wrote: >>> >>>> On 07/06/2016 09:04 PM, Pavan Yedavalli wrote: >>>> >>>> Hi Marcus, >>>> >>>> Trying the attached code with two of the USRPs transmitting, and with >>>> the B210_Phase_Viewer for the other 2 USRPs receiving, still gives me >>>> different offsets for every different run call. And by different run call, >>>> I'm simply running the flowgraph once, seeing the offset, stopping the >>>> graph, and then running it again, seeing the new offset, and so on. I must >>>> be doing something wrong here. A you mentioned, since all of them are using >>>> the Octoclock, that means that they all are having the same reference and >>>> pps, but both receive boards may also not be timed in an aligned fashion >>>> for the same reason, right? So the receive side LO offsets could also be >>>> causing problems in narrowing down the issue, I'm assuming? Thanks again. >>>> >>>> Yes, the receive side needs to be as mutually-coherent as possible as >>>> well. >>>> >>>> Also, I forgot to mention that you'll need to modify the output of the >>>> flow-graph I provided to wrap timed-command stuff around the tuning. >>>> >>>> Same on any RX flow-graph. That's the only sane we to be able to >>>> measure any kind of phase-offset that you can trust. >>>> >>>> If the RX side is a B210, you don't need to do timed commands (and, >>>> indeed, they aren't supported for tuning on the B210). What I'd do is >>>> leave the RX side running, while you bring the TX side up and down. >>>> >>>> >>>> >>>> >>>> On Wed, Jul 6, 2016 at 5:47 PM, Marcus D. Leech <mle...@ripnet.com> >>>> wrote: >>>> >>>>> On 07/06/2016 02:48 PM, Pavan Yedavalli wrote: >>>>> >>>>> I disconnected the MIMO cable and now have all 4 directly connected to >>>>> the Octoclock, but I get the same results in which the offset changes at >>>>> every run (using the above code). >>>>> >>>>> What about the attached code? >>>>> >>>>> Keep in mind that you'll have to measure it with something that is >>>>> also mutually coherent. >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jul 5, 2016 at 9:11 PM, Marcus D. Leech <mle...@ripnet.com> >>>>> wrote: >>>>> >>>>>> On 07/05/2016 11:45 PM, Pavan Yedavalli wrote: >>>>>> >>>>>> Yes, sorry - two of them are actually connected via MIMO cable, with >>>>>> the master connected to the Octoclock. Then the other two are directly >>>>>> connected to the Octoclock. I used the MIMO cable just because I had it, >>>>>> but hopefully that's not changing the functionality. >>>>>> >>>>>> Yes, I added even more attenuation because the Tx gain was already >>>>>> quite low. Thanks for the suggestion. >>>>>> >>>>>> So, a useful experiment would be to do your coherent TX from a pair >>>>>> that are both hooked up to the Octoclock. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jul 5, 2016 at 7:29 PM, Marcus D. Leech <mle...@ripnet.com> >>>>>> wrote: >>>>>> >>>>>>> On 07/05/2016 09:45 PM, Pavan Yedavalli wrote: >>>>>>> >>>>>>> According to the spectrum analyzer, there's nothing being >>>>>>> transmitted in the 900 MHz band around me, so that is actually fine. The >>>>>>> biggest unknown could be what you are saying about how they combine in >>>>>>> the >>>>>>> RSSI circuit (which I'm not sure how it works). >>>>>>> >>>>>>> I am not gaining any more insight when using over-the-air antennas, >>>>>>> so I used 2 USRPs as transmitters and 2 as receivers, connected them >>>>>>> directly with SMA cables (and attenuation), and used Derek Kozel's >>>>>>> B210_Phase_Viewer on the receive side to see whether they were aligned >>>>>>> after each run. And I am noticing that they are not. The first run >>>>>>> produced >>>>>>> a 125 degree phase offset, while the second one produced a 3 degree >>>>>>> phase >>>>>>> offset, and this continues to fluctuate after each run (see attached). >>>>>>> Note >>>>>>> that I am using the code that I pasted above to transmit. >>>>>>> >>>>>>> I must be doing something wrong with the code, or not wrapping the >>>>>>> timed commands around the correct code. I am not sure though. Thanks >>>>>>> again. >>>>>>> >>>>>>> Looks like you have a bit of clipping as well. Back off the gain on >>>>>>> the TX side. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Jul 5, 2016 at 5:51 PM, Marcus D. Leech <mle...@ripnet.com> >>>>>>> wrote: >>>>>>> >>>>>>>> On 07/05/2016 08:20 PM, Pavan Yedavalli wrote: >>>>>>>> >>>>>>>> I see, but the offset in phase between the two radios will affect >>>>>>>> the amplitude, right? That was the assumption I was using, since it >>>>>>>> gives >>>>>>>> out an amplitude reading, but the phase clearly will affect that >>>>>>>> reading, I >>>>>>>> presumed. >>>>>>>> >>>>>>>> Unfortunately, I don't have any documentation on the RSSI circuit >>>>>>>> apart from the following description from the vendor: >>>>>>>> >>>>>>>> The RSSI functionality allows the sampling of the received signal >>>>>>>> to provide an indication of the amount of energy being harvested. When >>>>>>>> DSET >>>>>>>> is driven high the harvested DC power will be directed to an internal >>>>>>>> sense >>>>>>>> resistor, and the corresponding voltage will be provided to the DOUT >>>>>>>> pin. >>>>>>>> The voltage on the DOUT pin can be read after a 50μs settling time. >>>>>>>> RSSI >>>>>>>> shows the actual power level that is being received at the antenna. >>>>>>>> This >>>>>>>> number is accurate from 0.04mW to 50mW. >>>>>>>> >>>>>>>> This probably does not help at all to debug. Sorry about that. >>>>>>>> >>>>>>>> You're making assumptions about how your signals will combine in >>>>>>>> that RSSI circuit, and how they'll combine with other ambient signals >>>>>>>> within >>>>>>>> your frequency band. I cannot imagine that being stable. >>>>>>>> >>>>>>>> To measure the phase between two signals, you need a device that is >>>>>>>> phase sensitive (like, for example, another USRP with two inputs), and >>>>>>>> compute conjugate multiplication between them, or the >>>>>>>> phase-angle, via the complex-argument block. >>>>>>>> >>>>>>>> Or just plot the two signals on a Qt Time sync, and observe that >>>>>>>> the phase relationship is the same--that of course requires that your >>>>>>>> receiver system is internally coherent between the two channels. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jul 5, 2016 at 4:42 PM, Marcus D. Leech <mle...@ripnet.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 07/05/2016 07:28 PM, Pavan Yedavalli wrote: >>>>>>>>> >>>>>>>>> The way I'm doing it is the following (please correct me if there >>>>>>>>> is a fundamental error in assumptions): I am actually using an RSSI >>>>>>>>> circuit >>>>>>>>> that is receiving the power from the USRPs/antennas, and I'm >>>>>>>>> determining >>>>>>>>> whether the phase offset is the same based on that RSSI value. For >>>>>>>>> example, >>>>>>>>> I run the flowgraph once, and I get an RSSI value on the other side >>>>>>>>> of 2.5 >>>>>>>>> mW, but when I run the flowgraph again, it produces an RSSI value of >>>>>>>>> 9.5 >>>>>>>>> mW. In my mind, if that offset was constant, then it would have >>>>>>>>> produced >>>>>>>>> something around 2.5 mW again. I know this adds another variable to >>>>>>>>> the >>>>>>>>> mix, but I have confirmed the accurate functioning of the RSSI >>>>>>>>> circuit/receiver as well as the static nature of the channel, so its >>>>>>>>> reading is very reliable. >>>>>>>>> >>>>>>>>> Could you describe this RSSI circuit? Normally, they're only >>>>>>>>> sensitive to amplitude, not phase. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jul 5, 2016 at 4:19 PM, Marcus D. Leech <mle...@ripnet.com >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> On 07/05/2016 06:47 PM, Pavan Yedavalli wrote: >>>>>>>>>> >>>>>>>>>> Hi Marcus, >>>>>>>>>> >>>>>>>>>> Thanks for the background. That helps greatly. Having said that, >>>>>>>>>> I am unclear which commands specifically tune the radios, so I did >>>>>>>>>> the >>>>>>>>>> following around the frequency tuning (after all of the time source, >>>>>>>>>> gain, >>>>>>>>>> and antenna setting code): >>>>>>>>>> >>>>>>>>>> addr_string = "addr0=192.168.10.3,addr1=192.168.10.4" >>>>>>>>>> self.uhd_usrp_sink_0_0 = uhd.usrp_sink( >>>>>>>>>> ",".join((addr_string, "")), >>>>>>>>>> uhd.stream_args( >>>>>>>>>> cpu_format="fc32", >>>>>>>>>> channels=range(2), >>>>>>>>>> ), >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> self.uhd_usrp_sink_0_0.set_clock_source("external", 0) >>>>>>>>>> self.uhd_usrp_sink_0_0.set_time_source("external", 0) >>>>>>>>>> self.uhd_usrp_sink_0_0.set_clock_source("mimo", 1) >>>>>>>>>> self.uhd_usrp_sink_0_0.set_time_source("mimo", 1) >>>>>>>>>> self.uhd_usrp_sink_0_0.set_samp_rate(samp_rate) >>>>>>>>>> self.uhd_usrp_sink_0_0.set_gain(31.5, 0) >>>>>>>>>> self.uhd_usrp_sink_0_0.set_gain(31.5, 1) >>>>>>>>>> self.uhd_usrp_sink_0_0.set_antenna("TX/RX", 0) >>>>>>>>>> self.uhd_usrp_sink_0_0.set_antenna("TX/RX", 1) >>>>>>>>>> self.analog_sig_source_x_0_1 = >>>>>>>>>> analog.sig_source_c(samp_rate, analog.GR_CONST_WAVE, 10000, 1, 0) >>>>>>>>>> self.analog_sig_source_x_0_0_0 = >>>>>>>>>> analog.sig_source_c(samp_rate, analog.GR_CONST_WAVE, 10000, 1, 0) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> * >>>>>>>>>> self.uhd_usrp_sink_0_0.set_time_unknown_pps(uhd.time_spec()) >>>>>>>>>> now = >>>>>>>>>> self.uhd_usrp_sink_0_0.get_time_now() start_time = now + >>>>>>>>>> uhd.time_spec(.5) >>>>>>>>>> self.uhd_usrp_sink_0_0.set_command_time(start_time) >>>>>>>>>> self.uhd_usrp_sink_0_0.set_center_freq(915000000, 0) >>>>>>>>>> self.uhd_usrp_sink_0_0.set_center_freq(915000000, 1) >>>>>>>>>> self.uhd_usrp_sink_0_0.clear_command_time()* >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> However, when running it, this does not appear to produce a >>>>>>>>>> constant offset either, but I'm not sure whether this is the correct >>>>>>>>>> code >>>>>>>>>> to wrap around. Please keep me posted. Thanks. >>>>>>>>>> >>>>>>>>>> On Tue, Jul 5, 2016 at 12:49 PM, <mle...@ripnet.com> wrote: >>>>>>>>>> >>>>>>>>>>> That is precisely what I'm saying, and precisely what >>>>>>>>>>> timed-commands for tuning were invented. On certain hardware, >>>>>>>>>>> after the >>>>>>>>>>> tune is complete, a phase-reset pulse is sent by the FPGA. The only >>>>>>>>>>> way for >>>>>>>>>>> THAT to have the desired effect is to make sure that the >>>>>>>>>>> phase-reset pulse >>>>>>>>>>> happens at the same instant. >>>>>>>>>>> >>>>>>>>>>> Modern synthesizers use a technique called fractional-N >>>>>>>>>>> synthesis. One of the side effects of this is that you can't >>>>>>>>>>> predict where >>>>>>>>>>> the LO will "lock" with respect to the reference clock. So, any two >>>>>>>>>>> PLL >>>>>>>>>>> synthesizers, even when feed an identical reference clock, will not >>>>>>>>>>> have >>>>>>>>>>> the same phase offset with respect to one another. It's the >>>>>>>>>>> "physics" of >>>>>>>>>>> fractional-N PLL synthesis. >>>>>>>>>>> >>>>>>>>>>> SO, if you're using GRC to generate you flows, you'll have to >>>>>>>>>>> modify the generated code, and wrap >>>>>>>>>>> set_command_time()/clear_command_time() >>>>>>>>>>> around the place in the code where it tunes the radios. >>>>>>>>>>> >>>>>>>>>>> Clearly, if this depends on TIME, then all radios involved need >>>>>>>>>>> to agree on the current time, to high precision, hence the related >>>>>>>>>>> requirement for set_time_unknown_pps(), which uses the 1PPS signal >>>>>>>>>>> to >>>>>>>>>>> trigger loading of the time-of-day clocks on each USRP in the >>>>>>>>>>> multi_usrp >>>>>>>>>>> object. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016-07-05 15:41, Pavan Srikrishna Yedavalli wrote: >>>>>>>>>>> >>>>>>>>>>> I am using USRP N210 with SBX daughterboards. All devices are >>>>>>>>>>> connected to the octoclock ref and octoclock PPS. It would be nice >>>>>>>>>>> to get >>>>>>>>>>> phase alignment, but mere coherence-with-an-offset is sufficient if >>>>>>>>>>> that >>>>>>>>>>> offset stays constant across different runs of the file/flowgraph. >>>>>>>>>>> Are you >>>>>>>>>>> saying that that offset cannot be constant due to the randomness of >>>>>>>>>>> the LO >>>>>>>>>>> phase offset at each run? Thanks again. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _____________________________ >>>>>>>>>>> From: mle...@ripnet.com >>>>>>>>>>> Sent: Tuesday, July 5, 2016 12:35 PM >>>>>>>>>>> Subject: Re: [Discuss-gnuradio] random phase offset constantly >>>>>>>>>>> changing with octoclock setup >>>>>>>>>>> To: Pavan Yedavalli <psy2...@columbia.edu> >>>>>>>>>>> Cc: Discuss-gnuradio < >>>>>>>>>>> discuss-gnuradio-bounces+mleech=ripnet....@gnu.org>, GNURadio >>>>>>>>>>> Discussion List <discuss-gnuradio@gnu.org> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> WHat specific hardware line-up do you have? >>>>>>>>>>> >>>>>>>>>>> You have to use set_time_unknown_pps(), but also, if you want >>>>>>>>>>> phase alignment (as opposed to mere coherence-with-an-offset), you >>>>>>>>>>> need to >>>>>>>>>>> use timed tuning commands across your systems. This will result in >>>>>>>>>>> zero >>>>>>>>>>> relative phase offset between boards, if you're using SBX or UBX >>>>>>>>>>> (on the >>>>>>>>>>> X310). Note that this is phase between the boards, there's no way >>>>>>>>>>> to make >>>>>>>>>>> certain the the LO phase has a predictable offset with respect to >>>>>>>>>>> external >>>>>>>>>>> received signals, only that the two LO phases agree. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016-07-05 15:26, Pavan Yedavalli wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Despite all of my boards being connected via the Octoclock (ref >>>>>>>>>>> and pps), I am constantly getting different phase offsets every >>>>>>>>>>> time I run >>>>>>>>>>> a gnuradio flowgraph (or python file). >>>>>>>>>>> >>>>>>>>>>> I am not sure why this is happening, but I do know that I need >>>>>>>>>>> to call one of the functions, set_time_now() and/or >>>>>>>>>>> set_time_unknown_pps(), >>>>>>>>>>> to make sure all of them are synced. Which one am I supposed to >>>>>>>>>>> call? I >>>>>>>>>>> have been calling set_time_unknown_pps(), but I am getting the >>>>>>>>>>> above/below >>>>>>>>>>> problem with that, so maybe set_time_now() could be correct? >>>>>>>>>>> >>>>>>>>>>> In general, I don't understand why I continually get a different >>>>>>>>>>> random phase offset of all of the radios after every new flowgraph >>>>>>>>>>> run. >>>>>>>>>>> Shouldn't this offset be the same if I continue to transmit at the >>>>>>>>>>> same >>>>>>>>>>> frequency? Would one of the above functions fix that? >>>>>>>>>>> >>>>>>>>>>> Hopefully that is clear. Thank you so much for the help. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Pavan >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Discuss-gnuradio mailing list >>>>>>>>>>> Discuss-gnuradio@gnu.org >>>>>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Pavan >>>>>>>>>> >>>>>>>>>> How are you measuring the phase-offset between the two sinks? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Pavan >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Pavan >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Pavan >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Pavan >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Pavan >>>>> >>>>> >>>> >>>> >>>> -- >>>> Pavan >>>> >>>> >>> >>> >>> -- >>> Pavan >>> >>> >> >> >> -- >> Pavan >> >> > > > -- > Pavan > -- Pavan
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
