Re: [Discuss-gnuradio] Change filter parameters in running flowgraph?

[mleech]

For the most part, decimation cannot be changed at runtime, due to the
way the scheduler does static allocation and buffer management. 

On 2017-11-02 13:05, John Ackermann N8UR wrote:

> I'm getting ready to do a Gnuradio tutorial for a local group, and want to 
> show the impact of decimation and filtering.  I created a QT Gui Range 
> parameter that sets the ID "decimation".
> 
> In the low pass filter block I the decimation value is set to "decimation."  
> That seems to work and I can see the span of the QT Frequency Sink change as 
> the decimation value changes.
> 
> But I also use the decimation parameter to determine the cutoff frequency 
> ((samp_rate/decimation)/2) and transition width ((samp_rate/decimation)/10).  
> However, these don't seem to change dynamically when the flowgraph is 
> running-- the filter remains at the width it was when the flowgraph started.
> 
> Is there a way to have the filter change as the decimation parameter changes?
> 
> Thanks,
> John
> 
> ___
> 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] Synchronisation

[mleech]

Use "unknown PPS" on both of them.  The MIMO cable shares both REFCLOCK
and 1PPS signals, so they will both be synchronized to the same time. 

On 2017-09-12 16:13, John Shields wrote:

> Thanks Derek,
> No, I hadn't been power cycling between the runs - good point, obviously, I 
> should have.
> 
> In terms of the 10 MHz and 1 pps references, in the configuration I was 
> testing, I don't believe so in that I had the MIMO cable disconnected. My 
> strategy was to have 2 USRPs with no MIMO - expecting little synchonisation. 
> Then I was going to add the devices into the same container and connect the 
> MIMO cable and expected things to improve and lastly, I was going to 
> hand-code the SBX phase synch code.
> 
> In terms of the version of UHD, the fg shows: <<< Welcome to GNU Radio 
> Companion 3.7.11.1 >>>
> 
> Thanks Marcus,
> I will implement your way of measuring the running phase offset and also 
> thanks for correcting my understanding of O/B GPS .
> 
> In terms of getting the devices in the container to be the best synch they 
> can be, I presume for the device which has the GPS, for the clock source and 
> time source, I would put O/B GPS for the device which has it and for the 
> other, I would put MIMO cable for both but in terms of the 'Sync' field, 
> where the options are PC Clock, Unknown PPS and Don't Sync, which option 
> should I select?
> 
> Thanks again for your help.
> 
> Kind Regards,
> 
> John
> 
> On 11/09/17 09:00, Derek Kozel wrote: 
> 
> Hi John,
> 
> Are you power cycling the USRPs between tests or just rerunning the GRC 
> flowgraph? Do you have shared 10 MHz and 1 PPS references? What version of 
> UHD is printed in the output? Thanks, Derek 
> 
> On Mon, Sep 11, 2017 at 1:50 AM, John Shields  wrote:
> 
> Thanks for the feedback but I am not sure that I understand it. What I was 
> hoping to do was step through the configurations with increasing levels of 
> synchronisation and expecting to see same.
> 
> Marcus' comment is correct and I have not, yet, put in the code which 
> synchronises SBXs.
> 
> I guess my basic point, from looking at previous post from others Marcus L 
> included, was that UHD would somehow improve the synchronisation between two 
> USRPs in the same container versus those two separately. 
> 
> When I executed the FG shown (separately) with the USRPs individually and 
> then within a UHD container the results in terms of phase variation was the 
> same. I had expected that, based on my understanding, the containerised USRPs 
> would have behaved better.
> 
> So, either my FG does not measure what I thought it should or there is little 
> UHD-related benefit to having USRPs individually or in the 'domain' as 
> MarcusL has mentioned previously. From my situation it doesn't hence the 
> first question in the post: 
> 
> Does my FG not measure what I claim to be wishing to measure?
> 
> Kind Regards,
> 
> John 
> 
> On 11/09/17 01:03, Marcus D. Leech wrote: 
> 
> On 09/10/2017 08:58 PM, Dan CaJacob wrote: 
> 
> I could be wrong, but I thought the SBX was one of the few daughter cards 
> that starts with s known phase offset? Only if you ask it to do so, and only 
> if it's sharing clock with its buddies...
> 
> On Sun, Sep 10, 2017, 2:49 PM Fulcrum Associates  
> wrote: Dear All,
> 
> I have a couple of USRPs connected, through  a strong
> attenuator to a signal generator (NWT4001). While the units have a MIMO
> option, I don't have that cable. (Option A) When I run the GRC as
> attached, I see too good a result to the extent that the differential
> Phi seems to range over +/- 5 degrees.
> 
> What I had hoped to prove to myself that two N200 with SBX
> would have a varying offset without MIMO cable, then I would connect the
> MIMO cable and move the USRPs into a multi-unit and enable GPSD O/B on
> the unit which has the feature and MIMO for one without (Option B) and
> that the phase differential would improve noticeably and be a variable
> constant, but it didn't.
> 
> If it had, but there still was a fixed phase offset which
> varied each time it was setup (which is what I would expect under B)
> then I would hand-code the SBX stream initialisation code to remove the
> offset.
> 
> Does my FG not measure what I claim to be wishing to
> measure?
> 
> If it does measure it correctly, why do my expectations
> of options A and B leading to a different (though improved) situation
> not eventuate?
> 
> Kind Regards,
> 
> John
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1] 
> -- 
> 
> Very Respectfully, 
> 
> Dan CaJacob 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/di

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[mleech]

I have time-synchronized RTLSDRs using a known, pseudo-random, sequence
injected into the RX inputs using directional couplers.   These all had
a common clock so they wouldn't drift apart. 

On 2017-08-16 11:57, Derek Kozel wrote:

> It should be pointed out that the hardware based timestamping is only needed 
> if you need time alignment better than a half second or so. With USB 
> transfers, various buffers, NTP based alignment of the host computer's time, 
> and some extra code on the host side you could do a coarse time alignment, 
> probably with less than a half second of error.
> 
> You could also time align the streams if both radios receive the same signal 
> and you know the distance (and other details depending on the precision 
> needed) between the transmitter and your two receivers. This is done by many 
> protocols like the cellular standards to create a distributed timebase, but 
> quickly becomes non-trivial.
> 
> The B200 does timestamping in the FPGA and can use a 1PPS signal to align to 
> GPS time. It is more expensive than the HackRF, but much less than the $3000 
> mentioned above. 
> 
> On Wed, Aug 16, 2017 at 4:20 PM, Sylvain Munaut <246...@gmail.com> wrote:
> 
>> On Wed, Aug 16, 2017 at 5:11 PM,   wrote:
>>> What type of hardware? I thought from hardware point of view only precise 
>>> clock is required and all the other things in
>>> firmware. I've naively thought i could modify hackrf firmware to get this 
>>> feature.
>> 
>> Mostly a FPGA and a PPS input from a GPS receiver.
>> 
>> Each individual sample has a timestamp of when it has been received.
>> And you can also reset the timestamp on the next  PPS edge.
>> 
>> Technically it would be possible to modify the hackrf firmware and
>> repurpose some GPIOs and have all samples transmitted to the host be
>> in timestamped packets and implements timestamping in the on-board
>> ARM.
>> For additional hardware you'd only need an external GPS receiver (or
>> some other way to have both a single freq reference + single sync
>> pulse).
>> 
>> Cheers,
>> 
>> Sylvain
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 

Links:
--
[1] 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] Issues transmitting and receiving simultaneously on B210

[mleech]

The frequency seperation has to be less than the IF channel bandwidth,
using a tune_request, you can make this happen using the DDC to shift
the two frequencies from within the IF bandwidth.Otherwise, no,
there's only a single synthesizer in each direction. 

I'll post an example tune_request later. 

On 2017-07-28 14:42, Jose Ruvalcaba wrote:

> Hi Marcus,
> 
> Thanks for the response. So just to be clear, if I am using the RF:A channel 
> Tx/Rx port at say 200MHz, and wanted to also transmit from the Rx:B channel 
> Tx/Rx port, then the only frequency I can transmit from the second channel 
> would be 200 MHz because both channels are shared right? Is there a known way 
> to be able to transmit (or receive) from both channels in a B210 using 
> different frequencies ?
> 
> Thanks again, Jose  
> 
> On Wed, Jul 26, 2017 at 6:38 PM, Marcus D. Leech  wrote:
> 
> On 07/20/2017 02:23 AM, Jose Ruvalcaba wrote: 
> 
> Hello, 
> 
> I'm currently having issues simultaneously transmitting and receiving data 
> from one B210 to another B210. My goal is to send Tx data from one B210 and 
> have it be received and re transmitted from a second B210 back to the first. 
> I am trying to use both channels (RF A and RF B) to simultaneously transmit 
> and receive on both radios. To do this I have set the "Mb0 Subdev Spec" to 
> "A:A A:B" on both the USRP source and sink blocks, as I have shown in the 
> flowgraphs attached. My radio can successfully transmit data from one B210 
> and have it be received in the second B210. However, my issue arises when my 
> second B210 tries to re transmit the received data back to the original B210 
> (This is shown if usrp_2_channel.png flowgraph).  
> 
> My question is, in order to accomplish successful Tx to Rx loopback on both 
> radios, do I need to label the Subdev spec section as A:A A:B? Have I labeled 
> the Subdev correctly for a B210 or do I need to change it? Is it possible for 
> a USRP to transmit and receive simultaneously on both RFA and RFB channels of 
> a B210? If so, can I do this while using different frequencies on each 
> channel?  Just for completeness I have both radios connected to each other 
> using coaxial cables with a 38dB attenuation between each path.   
> 
> Thanks, 
> Jose 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
> 
> Jose:
> 
> Your basic problem is that on the B210, the synthesizer for BOTH TX channels 
> is shared, and the synthesizer for both RX channels is shared.
> 
> This means that ordinarily both channels have to be tuned to the same 
> frequency.   There are ways to "cheat" if your two desired "air" frequencies
> are close together, but in your case, they are 30MHz apart.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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] Signal distorted when using concurrently two USRP B210 devices

[mleech]

In the two-USRPs scenario, one of the USRPs is transmitting, and one is
receiving? 

Are they "through the air" or over a cable.  If over a cable, how much
attenuation has been added to the cable. 

On 2017-06-13 11:16, Manolis Surligas wrote:

> Ok lets explain a little bit more what actually you observe. Each burst is a 
> training sequence that has a duration of 64 samples and then 1000 zero 
> samples. This is generated using a vector source block repeatedly. As you can 
> see in the ok.jpeg all sequences are exactly the same. In the other plot 
> however the sequence constantly changes. To me, it seems that parts of the 
> actual sequence are randomly cropped or re-arranged. This happens only when 
> two different B210 are used. We also tried to transmit the sequence from a 
> third device with the same results. 
> 
> And yes we have tried to receive from both devices each one working on a 
> separate flowgraph. The result was exactly the same. 
> On 06/13/2017 06:05 PM, mle...@ripnet.com wrote: 
> 
> I'm having a hard time seeing a significant functional difference between the 
> two.  Could you perhaps explain? 
> 
> Also, maybe a diagram showing the two configurations? 
> 
> Do you get any error messages during a run? 
> 
> Are you doing reception on the two USRPs within a single flow-graph, or two 
> separate processes? 
> 
> On 2017-06-13 10:51, Manolis Surligas wrote: 
> 
> Hi Marcus, 
> 
> yeah we have updated the UHD on the latest version and the problem still 
> persists. I have started to debug the UHD and we suspect some kind of 
> inconsistency between the device pointers of the different devices. Perhaps a 
> race condition is hidden somewhere. 
> 
> I also attach two plots. The first one is the problematic with two different 
> USRPs and the second the expected signal transmitting and receiving using the 
> same USRP.
> 
> On 06/13/2017 05:30 PM, mle...@ripnet.com wrote: 
> 
> Thanks, George. 
> 
> Two things: 
> 
> Could you try updating to the most recent UHD version? 
> 
> It would be helpful if you provided your .dat files in the form of plots or 
> graphs, highlighting the areas you consider "distortion".  This will help us 
> help you. 
> 
> On 2017-06-13 07:23, George Vardakis wrote: 
> Good evening, 
> 
> I attach three captures to show you the problem, one with the reference 
> signal i transmit, one with the received samples when using the same device 
> for TX and RX and one with the received samples of the one device, when the 
> second one transmits. I also attach the flowgraph i used for this capture. 
> The sampling rate i use is 1MHz. The specific captures are done with the 
> USRPs over USB-2 ports, but i have also tried over USB-3 and observed the 
> same behavior. 
> 
> Thank you for your time​
> same_tx_rx_device.dat [2] ​​
> refference.dat [3] ​​
> different_tx_rx_device.dat [4] ​ 
> 
> On Tue, Jun 13, 2017 at 12:04 AM, Marcus D. Leech  wrote:
> 
> On 06/12/2017 03:53 PM, George Vardakis wrote: 
> 
> Hello all, 
> 
> I have two USRP B210 devices which i use in my MIMO application. When i use 
> the two of them concurrently in a flowgraph - or different flowgraphs - i 
> notice that the signal received by the streams of one of the devices (the one 
> whose serial number is last in lexicographical order) is distorted. Because i 
> transmit a known training sequence, i know what to expect, and i observe that 
> sometimes the real or imaginary part of the signal has flipped its sign (i 
> see the signal mirrored compared to the known one), or other times it is 
> completely distorted. When i use each device separately, everything works 
> fine. The UHD driver i use is the v3.9.5 one.Any ideas about it? 
> 
> Thank you!   
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
> 
> COuld you perhaps share a very-simple flow-graph that shows the issue? What 
> sample-rate are you using?  Is this over USB-2 or USB-3? 
> ___ Discuss-gnuradio mailing list 
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-- 
/* Code is the Law */

___ Discuss-gnuradio mailing
list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio 

-- 
/* Code is the Law */
 

Links:
--
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[2]
https://drive.google.com/file/d/0BxyASy57xNmqV2pLd2xUVWRRRU0/view?usp=drive_web
[3]
https://drive.google.com/file/d/0BxyASy57xNmqT1JQd2xfWjF6SjQ/view?usp=drive_web
[4]
https://drive.google.com/file/d/0BxyASy57xNmqMVhqd29NTmdiMDA/view?usp=drive_web___
Discuss-gnuradio mailing list
Discu

Re: [Discuss-gnuradio] Signal distorted when using concurrently two USRP B210 devices

[mleech]

I'm having a hard time seeing a significant functional difference
between the two.  Could you perhaps explain? 

Also, maybe a diagram showing the two configurations? 

Do you get any error messages during a run? 

Are you doing reception on the two USRPs within a single flow-graph, or
two separate processes? 

On 2017-06-13 10:51, Manolis Surligas wrote:

> Hi Marcus, 
> 
> yeah we have updated the UHD on the latest version and the problem still 
> persists. I have started to debug the UHD and we suspect some kind of 
> inconsistency between the device pointers of the different devices. Perhaps a 
> race condition is hidden somewhere. 
> 
> I also attach two plots. The first one is the problematic with two different 
> USRPs and the second the expected signal transmitting and receiving using the 
> same USRP.
> 
> On 06/13/2017 05:30 PM, mle...@ripnet.com wrote: 
> 
> Thanks, George. 
> 
> Two things: 
> 
> Could you try updating to the most recent UHD version? 
> 
> It would be helpful if you provided your .dat files in the form of plots or 
> graphs, highlighting the areas you consider "distortion".  This will help us 
> help you. 
> 
> On 2017-06-13 07:23, George Vardakis wrote: 
> Good evening, 
> 
> I attach three captures to show you the problem, one with the reference 
> signal i transmit, one with the received samples when using the same device 
> for TX and RX and one with the received samples of the one device, when the 
> second one transmits. I also attach the flowgraph i used for this capture. 
> The sampling rate i use is 1MHz. The specific captures are done with the 
> USRPs over USB-2 ports, but i have also tried over USB-3 and observed the 
> same behavior. 
> 
> Thank you for your time​
> same_tx_rx_device.dat [2] ​​
> refference.dat [3] ​​
> different_tx_rx_device.dat [4] ​ 
> 
> On Tue, Jun 13, 2017 at 12:04 AM, Marcus D. Leech  wrote:
> 
> On 06/12/2017 03:53 PM, George Vardakis wrote: 
> 
> Hello all, 
> 
> I have two USRP B210 devices which i use in my MIMO application. When i use 
> the two of them concurrently in a flowgraph - or different flowgraphs - i 
> notice that the signal received by the streams of one of the devices (the one 
> whose serial number is last in lexicographical order) is distorted. Because i 
> transmit a known training sequence, i know what to expect, and i observe that 
> sometimes the real or imaginary part of the signal has flipped its sign (i 
> see the signal mirrored compared to the known one), or other times it is 
> completely distorted. When i use each device separately, everything works 
> fine. The UHD driver i use is the v3.9.5 one.Any ideas about it? 
> 
> Thank you!   
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
> 
> COuld you perhaps share a very-simple flow-graph that shows the issue? What 
> sample-rate are you using?  Is this over USB-2 or USB-3? 
> ___ Discuss-gnuradio mailing list 
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-- 
/* Code is the Law */

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio 

Links:
--
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[2]
https://drive.google.com/file/d/0BxyASy57xNmqV2pLd2xUVWRRRU0/view?usp=drive_web
[3]
https://drive.google.com/file/d/0BxyASy57xNmqT1JQd2xfWjF6SjQ/view?usp=drive_web
[4]
https://drive.google.com/file/d/0BxyASy57xNmqMVhqd29NTmdiMDA/view?usp=drive_web___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Signal distorted when using concurrently two USRP B210 devices

[mleech]

Thanks, George. 

Two things: 

Could you try updating to the most recent UHD version? 

It would be helpful if you provided your .dat files in the form of plots
or graphs, highlighting the areas you consider "distortion".  This will
help us help you. 

On 2017-06-13 07:23, George Vardakis wrote:

> Good evening, 
> 
> I attach three captures to show you the problem, one with the reference 
> signal i transmit, one with the received samples when using the same device 
> for TX and RX and one with the received samples of the one device, when the 
> second one transmits. I also attach the flowgraph i used for this capture. 
> The sampling rate i use is 1MHz. The specific captures are done with the 
> USRPs over USB-2 ports, but i have also tried over USB-3 and observed the 
> same behavior. 
> 
> Thank you for your time​
> same_tx_rx_device.dat [2] ​​
> refference.dat [3] ​​
> different_tx_rx_device.dat [4] ​ 
> 
> On Tue, Jun 13, 2017 at 12:04 AM, Marcus D. Leech  wrote:
> 
> On 06/12/2017 03:53 PM, George Vardakis wrote: 
> 
> Hello all, 
> 
> I have two USRP B210 devices which i use in my MIMO application. When i use 
> the two of them concurrently in a flowgraph - or different flowgraphs - i 
> notice that the signal received by the streams of one of the devices (the one 
> whose serial number is last in lexicographical order) is distorted. Because i 
> transmit a known training sequence, i know what to expect, and i observe that 
> sometimes the real or imaginary part of the signal has flipped its sign (i 
> see the signal mirrored compared to the known one), or other times it is 
> completely distorted. When i use each device separately, everything works 
> fine. The UHD driver i use is the v3.9.5 one.Any ideas about it? 
> 
> Thank you!   
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
> 
> COuld you perhaps share a very-simple flow-graph that shows the issue?
> 
> What sample-rate are you using?  Is this over USB-2 or USB-3?
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[2]
https://drive.google.com/file/d/0BxyASy57xNmqV2pLd2xUVWRRRU0/view?usp=drive_web
[3]
https://drive.google.com/file/d/0BxyASy57xNmqT1JQd2xfWjF6SjQ/view?usp=drive_web
[4]
https://drive.google.com/file/d/0BxyASy57xNmqMVhqd29NTmdiMDA/view?usp=drive_web___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD recv demuxer errors with a simple Python flowgraph

[mleech]

You might also try specifying num_recv_frames=128 or 256 in the device
args, to see if that helps the USB subsystem 

On 2017-06-05 15:15, Marcus Müller wrote:

> Hi Pierre,
> 
> that looks more like a USB communication breakdown than an issue with
> your software.
> 
> just as a quick test: if you set the sampling rate to something USB2 can
> handle (e.g. 8 MHz or lower), does that work with a USB2-only port (ie.
> pick one that's not blue)? Some USB3 port controllers just misbehave.
> 
> Best regards,
> 
> Marcus
> 
> On 05.06.2017 15:01, Pierre Baudry wrote: Hi,
> 
> While working with gr-gsm blocks and examples I ran into some weird UHD
> errors.
> 
> I tried to reduce as much as possible the flowgraph complexity, and
> ended up writing a very simple flowgraph that seems to reliably trigger
> the UHD errors.
> 
> I uploaded the flowgraph here:
> https://gist.github.com/anonymous/d3c0c9f1f72ab7cdc2c3460126682bc6
> 
> The point of this flowgraph is to simply tune into a frequency, acquire
> some samples and proceed with a new acquisition. This is similar to what
> grgsm-scanner does, with the sample analysis removed.
> 
> On my hardware (Xeon E5-2650 with USRP B200 on USB3), this flowgraph
> will produce a lot of UHD errors every time such as:
> 
> Tuning to 1934.301035 MHz
> Acquisition N° 13 finished
> 
> Tuning to 1619.216092 MHz
> 
> UHD Error:
> recv packet demuxer unexpected sid 0xc449c000
> 
> UHD Error:
> recv packet demuxer unexpected sid 0x44208000
> 
> UHD Error:
> recv packet demuxer unexpected sid 0xc4064000
> 
> UHD Error:
> recv packet demuxer unexpected sid 0xc278
>  snip  Am I doing something the wrong way ?
> Is there a limitation of some kind with the way I retune the USRP ?
> I first thought that these errors were tied to the processing power
> required but the flowgraph I wrote just trashes received samples so this
> is very unlikely.
> 
> Best,
> Pierre
> 
> ___
> 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] Phase shift using a multiply block

[mleech]

Just use: 

complex(math.cos(angle-in-radians),math.sin(angle-in-radians)) 

As the constant in a multiply-const block 

On 2017-04-18 10:23, Trejo Treviño wrote:

> I am trying add a phase-shift to my signal via the use of a multiply block, 
> but I have not been able to find the correct inputs for the block. What 
> syntax should I use to input an exponential or a complex cosine/sine 
> combination for the multiplication? 
> 
> Best, 
> 
> FERNANDO 
> 
> ___
> 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] Huge Bandwidth Issues

[mleech]

My guess is that you're operating over USB-2.0, which can only sustain
an *aggregate* (TX and RX) of ca 8Msps, as far as I know. 

On 2017-04-17 12:17, Santos Campos wrote:

> Hello! 
> 
> I'm trying to use a b200mini to implement a relay with 6MHz of bandwidth. 
> Would it be feasible to do this as a time division to be able to use the same 
> center frequency? 
> 
> I know to not alias any data, the sampling frequency must be at least the 
> nyquist rate. The specs from the board seem like it can handle those 
> parameters easily, but it throws a channal capacity error upon running code. 
> 
> Any advice on what I'm doing wrong? 
> 
> Thanks and appreciated!
> -- 
> 
> /* 
> Santos Campos 
> University of Michigan '17 | Computer Engineering 
> Virtual EM Inc | Engineering Intern 
> santosecampos.com [1] 
> (269)419-5113 
> */ 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 

Links:
--
[1] http://santosecampos.com___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] File sink: file size

[mleech]

Why not do the spectral and power analysis steps within GR, having it
log summary data every few seconds, instead of raw data at high rate.  I
mean, that's what GR is good at. 

On 2017-04-07 14:53, Ellie White wrote:

> Hello, 
> 
> As I've mentioned in an earlier email to this list, I'm working on a small 
> loop antenna with the purpose of monitoring solar activity. I am currently 
> reading in the data through an RTL-SDR source, flowgraph attached. 
> 
> For this project, I need to be able to let my antenna run for long periods of 
> time (upwards of an hour or more, preferably several hours) in order to get a 
> graph of signal intensity vs. time. Right now, my setup consists of the GNU 
> Radio flowgraph attached, that produces a file which I analyze using a Python 
> program to get a spectral plot and a time series (for one of the 1024 
> channels saved in the file). 
> 
> I let my antenna and GNU Radio run for about 15 minutes last night collecting 
> data, and the file size ended up at over 7 GB. I am wondering if there is any 
> way to reduce the size of the file without tremendously reducing the quality 
> of the data? I have a few ideas on this, but I'm hoping someone else will 
> have better ones: 
> 
> -Maybe I need to reduce the sample rate. 
> 
> -Another option is to somehow just save the channel I need to the file, 
> instead of all 1024. Does anyone have any advice as to how to accomplish 
> that? 
> 
> If you need any more information or if I should clarify anything, please let 
> me know. Thanks! 
> 
> Ellie 
> ___
> 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] AWGN using E310

[mleech]

The baseband signal is simply mixed with the LO in the hardware. 

On 2017-03-28 13:46, John B. Wood wrote:

> Hello, all.  When I connect a GRC "Fast Noise Source" block output to the 
> input of a "UHD: USRP Sink" (an Ettus E310) and connect a spectrum analyzer 
> to the Tx port on the E310 I can see the RF output.  My question (using 
> either a gaussian or normal distribution specified as a baseband input to the 
> E310), what is the type of modulation being imposed by the E310 to produce 
> the RF output?  Thanks for your time and comment.  Sincerely,
> 
> John Wood
> U.S. Naval Research laboratory
> 
> ___
> 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] Measure and record the phase at the receiver

[mleech]

Phase is a relative measurement.  Against what are you measuring the
incoming phase? 

You can measure a PSK signal instantaneous phase-shift by computing the
arctran2 between adjacent critically-sampled samples. But there's no way
to look at a signal and say "what is its absolute phase" without having
something against which to measure said phase. 

On 2017-03-23 12:53, Trejo Treviño wrote:

> I am aware that a random phase shift will be introduced by the channel, but I 
> need a method to measure the received phase (even if it does not exactly 
> match the one from the transmitter) and store it, so I can then run some 
> statistics on them  This is why I think that the TX and RX do not need to be 
> phase-synchronized. 
> 
> Best, 
> 
> FERNANDO TREJO 
> 
> -
> 
> FROM: Discuss-gnuradio 
>  on 
> behalf of Marcus Müller 
> SENT: Wednesday, March 22, 2017 7:02:35 PM
> TO: discuss-gnuradio@gnu.org
> SUBJECT: Re: [Discuss-gnuradio] Measure and record the phase at the receiver 
> 
> Hi Fernando! 
> On 03/22/2017 06:51 PM, Trejo Treviño, Fernando Alberto wrote: 
> 
>> Hi Marcus! 
>> 
>> I am implementing a transmitter and a receiver model using two USRP N210s. 
>> Both are using GFSK modulation, and the data is transmitted at 2.4 GHz.
> Cool :)
> 
>> I would like to add a phase shift at the transmitter side via the use of a 
>> multiplier block with an exponential.
> Ah, so a multiply_const with a constant of 
> $e^{j\frac{2\pi}{f_\text{sample}\varphi}$, yeah.
> 
>> Then, at the receiver I would like to receive this transmitted signal and 
>> check if the phase matches the one that was transmitted. This is why I need 
>> a measuring method.
> Well, you can't see absolute phase without further ado - that would need your 
> TX and RX to be phase-synchronized (you don't know the electrical length 
> between your transmitter and receiver, it's absolutely random by itself).
> 
> Best regards,
> Marcus 
> ___
> 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] USRPs having the same IP address on a network

[mleech]

OK, so, dedicated ethernet cards on each computer for the N210s? 

If so, those are, unless you turn each machine into a router that "plays
nice" with the local network infrastructure, *private*
connections--dont' think of them as network connections but a bus
connection between your computer and the N210.  In which case, they
could each have retained their original factory address. 

On 2017-01-18 14:13, Qurat-Ul-Ann Akbar wrote:

> Each USRP is connected with a different computer and therefore they both have 
> separate Ethernet ports. There is no switch in between the computers and the 
> USRPs. 
> 
> Best, 
> Annie 
> 
> On Wed, Jan 18, 2017 at 1:08 PM,  wrote:
> 
> We're going to need more of a description about how things are connected--do 
> your USRPs have dedicated ethernet connections per computer, or are they 
> connected to the same ports that your computers use to talk to the rest of 
> your network?
> 
> On 2017-01-18 14:05, Qurat-Ul-Ann Akbar wrote: 
> 
> Hi Marcus, 
> 
> I have set the IP address of one USRPN210 to 192.168.10.3 replacing its 
> default 192.168.10.2 IP but the I can not ping this USRP from a different 
> computer which has the other USRP conneced to it. I can ping it from the same 
> computer to which it is connected. Why is that? And how do you think I can 
> fix this ? 
> 
> Best, 
> Annie 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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] USRPs having the same IP address on a network

[mleech]

We're going to need more of a description about how things are
connected--do your USRPs have dedicated ethernet connections per
computer, or are they connected to the same ports that your computers
use to talk to the rest of your network? 

On 2017-01-18 14:05, Qurat-Ul-Ann Akbar wrote:

> Hi Marcus, 
> 
> I have set the IP address of one USRPN210 to 192.168.10.3 replacing its 
> default 192.168.10.2 IP but the I can not ping this USRP from a different 
> computer which has the other USRP conneced to it. I can ping it from the same 
> computer to which it is connected. Why is that? And how do you think I can 
> fix this ? 
> 
> Best, 
> Annie 
> ___
> 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] filesink to multiple files without dropping data

[mleech]

If you want strict control over the file-size, then you'll likely need
to write your own block. 

It should perhaps NOT come as a surprise that there aren't examples that
cover every possible use case, since the field-of-endeavor is
essentially-infinite, and there's only a finite number of entities
working on this stuff 

The www.gnuradio.org [1] website has lots of tutorials, and info on
writing your own blocks... 

On 2017-01-16 16:19, BuRaK wrote:

> Thanks Marcus, 
> However, I would like to strictly limit the samplesize. If I use a 
> controlport can I achieve this. 
> Is there an example that I can refer to? Because I did not quite get how to 
> do it. 
> Thanks 
> 
> On Tuesday, January 17, 2017 12:09 AM, "mle...@ripnet.com" 
>  wrote:
> 
> There are a whack of approaches to doing this. 
> The filename parameter of the filesink block is runtime changeable. 
> You could have an external process using controlport or xmlrpc to change this 
> setting (from a variable) at regular intervals.  The existing file will be 
> closed, and a new one started under whatever name you give it. 
> Or, you could start with the filesink block, and write a new one that 
> implements your naming policy as you see fit. 
> 
> On 2017-01-16 15:39, BuRaK wrote: 
> 
>> Hi all, 
>> 
>> I am trying to do a simple task but could not decide how to approach and do 
>> it.  
>> 
>> I would like to collect data from usrp continuously. The filesize will be 
>> huge and what I would like to do is say if 10 minutes passed (or xxx samples 
>> are collected) 
>> close file1.dat and open file2.dat and keep writing to that one. But I do 
>> not want to interrupt dataflow or lose any single sample.  
>> 
>> Would it be possible to do this through GRC or should I write a new block? 
>> It would be great if somebody can help me through this.  
>> Thank you in advance.  
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 

Links:
--
[1] http://www.gnuradio.org___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] filesink to multiple files without dropping data

[mleech]

There are a whack of approaches to doing this. 

The filename parameter of the filesink block is runtime changeable. 

You could have an external process using controlport or xmlrpc to change
this setting (from a variable) at regular intervals.  The existing file
will be closed, and a new one started under whatever name you give it. 

Or, you could start with the filesink block, and write a new one that
implements your naming policy as you see fit. 

On 2017-01-16 15:39, BuRaK wrote:

> Hi all, 
> 
> I am trying to do a simple task but could not decide how to approach and do 
> it.  
> 
> I would like to collect data from usrp continuously. The filesize will be 
> huge and what I would like to do is say if 10 minutes passed (or xxx samples 
> are collected) 
> close file1.dat and open file2.dat and keep writing to that one. But I do not 
> want to interrupt dataflow or lose any single sample.  
> 
> Would it be possible to do this through GRC or should I write a new block? 
> It would be great if somebody can help me through this.  
> Thank you in advance.  
> ___
> 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] Tune Requests

[mleech]

http://files.ettus.com/manual/structuhd_1_1tune__request__t.html 

Should help 

On 2017-01-04 12:37, Sean Horton wrote:

> I have my flowgraph set up so that parameters such as rx and tx frequencies 
> can be changed while running, and it's being sent two frequencies to listen 
> to, freq1 and freq2, and the idea is that if there are two frequencies, to 
> set the frequency to (freq1 + freq2) / 2, but the fft shows that one of the 
> receive chains has the dc spike in it, which makes me think the center 
> frequency is really freq1, but it's simply shifting the received signal. What 
> type of request will force the center frequency to actually be at (freq1 + 
> freq2) / 2? If it's a tune_request, how do you make one in cpp, I can't find 
> any example of it being done. It's not a big deal, but if I can get rid of 
> the dc spike, I'd certainly like to. 
> 
> Regards,
> -- 
> 
> Sean Horton
> 
> ___
> 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] Using Function Probe To Get Value From Probe Signal Vector

[mleech]

Meh, I use function probes to capture 'stuff' that changes
slowly--timescales of seconds or tens-of-seconds. 

I wouldn't do this for faster stuff, but doing that allows you to use
"ordinary" python in a python module, with the probe value as calling
parameter. 

On 2016-12-21 11:47, Marcus Müller wrote:

> Hi Sean, 
> 
> you really shouldn't be doing that at all. 
> 
> If you want to do signal processing, write a simple python block that 
> operates on a sample stream. 
> 
> The signal probe is really just that, for sporadic "debug" and "display" 
> operation, not for any "useful" application.ö 
> 
> Best regards, 
> 
> Marcus 
> 
> On 21.12.2016 17:30, Sean Horton wrote: 
> 
>> I have a function probe to get an int from one block's output, and been 
>> using a function probe to get the value of the probe signal. I now want to 
>> have the block output a vector of ints, and use a probe signal vector to 
>> capture them, and nave a few function probes to get index 0, 1, and so 
>> forth. How do you do that? It does not seem to be as simple as replacing 
>> level with leve[index] (where index is 0, 1, etc) in the function probe's 
>> function name field. In my test setup, the function probe never changes from 
>> the default value, which is not one of the values in my vector source I'm 
>> using for testing. 
>> -- 
>> 
>> Sean Horton
>> 
>> ___
>> 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] What Is The Proper Way To Change Block Parameters While Running

[mleech]

If your flow-graph is GRC based, then any block parameters that can be
changed at runtime can be tied to a variable. 

Once you have that, then you can use, for example, XMLRPC to set any
variable in the flow-graph from the "outside world" (which includes
"reflexive" setting from non-flowgraph python code). 

There's also controlport, which I have haven't played with. 

On 2016-12-20 11:38, Sean Horton wrote:

> What is the best way to change settings such as gain, taps, frequency values, 
> etc of various blocks while running? The current setup I'm refactoring 
> receives new configs over tcp, and a block outputs the new config values to 
> probe signals, and those probe signals are used to change various settings. 
> In the case of setting some usrp source parameters (center frequency), it 
> appears to not properly work, so for the usrp sink and sources, I am going to 
> pass messages to change the parameters. This isn't possible for other blocks, 
> though, as they do not have message inputs.  
> 
> If I should stick with the current method, though, I'm really curious how 
> there is mutual exclusion, as the values are being changed while the 
> flowgraph is running. I have looked at the source code for some of the blocks 
> I'm using, and I don't see any mutexes. This makes me think this isn't the 
> best way to do what is being done. 
> 
> Thanks, 
> Sean
> -- 
> 
> Sean Horton
> 
> ___
> 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] Dropped data when changing frequency dynamically using an Ettus B200

[mleech]

No data are dropped, but there will *always* be a disturbance in the
analog domain when you're changing the synthesizer frequency.  PLLs
require a non-zero time to "lock", which means they converge to the
correct frequency over some small time interval (a few msec, typically).
 Along with this, the filters in the DDC will take  time
for the analog disturbance to propagate through the filter. 

What underlying USRP device are you using?

On 2016-12-20 10:14, Tom Golden wrote:

> Hi All, 
> 
> I am connecting my flowgraph to a doppler prediction tool.  My block 
> currently modifies a variable that is used to specify the center frequency of 
> the USRP Source block.  The variable is updated every second. 
> 
> When the variable updates, I see blank data (looks like all zeros) for a 
> short blip when this occurs.  My QT FFT and Scope sinks flatline for a short 
> period (subsecond).  Has anyone else seen this? 
> 
> I've changed my flowgraph to leave the USRP Source alone and shift the 
> frequency using a signal generator and multiply block.  I'm concerned about 
> doing this for TX.  My concern is reduced performance because I'm not 
> transmitting at the center frequency for the USRP Sink.  Is my concern 
> unfounded?  Does anyone know if the same discontinuity for USRP Source is 
> present for USRP Sink? 
> 
> Thanks in advance, 
> -Tom 
> 
> ___
> 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] Probable pulsar observing success at CCERA

[mleech]

Effective integration time was about 40 minutes. 

The beamshape is roughly 42 x 18 degrees from our array antenna. 

On 2016-12-01 15:54, Daniel R. Marlow wrote:

> Hello, 
> 
> First, congrats to Marcus and CCERA.   
> 
> We are working at 21 cm (1420 MHz) and find that there are at least a few 
> pulsars not that far below B0329+54 (now called J0332+5434) in signal 
> strength. Indeed, one of the interesting things is that owing to 
> scintillation effects, there are times when this pulsar is not as bright as 
> some of the pulsars. Of course, when this pulsar is at its best, the 
> signal really is quite strong: we get a good detection after just a few turns 
> using a 60' dish and 50 MHz of BW.   
> 
> A question . . . roughly what was the integration time for the plot that you 
> showed? 
> 
> Sincerely,
> Dan Marlow 
> 
> FROM: Discuss-gnuradio 
>  on behalf of 
> "mle...@ripnet.com" 
> DATE: Thursday, December 1, 2016 at 3:41 PM
> TO: "Iain Young, G7III" 
> CC: Discuss-gnuradio , 
> "discuss-gnuradio@gnu.org" 
> SUBJECT: Re: [Discuss-gnuradio] Probable pulsar observing success at CCERA 
> 
> Keep in mind also that B0329+54 is really the only one within reasonable 
> "reach" for an amateur in the northern hemisphere--the others are much 
> fainter, although if one simply added another "gulp" of antenna every 
> paycheque or two... 
> 
> Also, you need a stable clock--I'm using an OCXO, but a TCXO will work for 
> shorter observing times.  So, if you are using a dongle, you'll need to 
> replace its clock. 
> 
> On 2016-12-01 15:19, Iain Young, G7III wrote: 
> 
> Hi Marcus,
> 
> Brilliant. I am in the middle of assembling my own radio telescope,
> but had not thought Pulsar reception would be possible.
> 
> I have a couple of questions on the RF Hardware. I see from some other
> updates, that the antenna is essentially sets of a 4 bay HDTV antenna.
> 
> How are you phasing them all together ? Just additive combiners with
> same length coax ? What amplification are you using before feeding
> them to the SDR ? Or ?
> 
> Best Regards
> 
> Iain
> 
> On 01/12/16 18:45, Marcus D. Leech wrote: 
> 
> One of the many goals we set for ourselves at the Canadian Centre for
> Experimental Radio Astronomy was to successfully observe
> pulsar B0329+54 before spring.  This pulsar is the only one bright
> enough for a small observatory in the northern hemisphere to
> observe.
> 
> See our update:
> 
> http://www.ccera.ca/uncategorized/success-in-observing-pulsar-b032954/
> 
> The software is available via github:
> 
> https://github.com/ccera-astro/pulsar_pfb _display
> 
> No custom blocks required--just a modern Gnu Radio install, and ideally,
> pyephem.
> 
> Doing this with Gnu Radio was so very easy...
> 
> ___
> 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] Probable pulsar observing success at CCERA

[mleech]

Keep in mind also that B0329+54 is really the only one within reasonable
"reach" for an amateur in the northern hemisphere--the others are much
fainter, although if one simply added another "gulp" of antenna every
paycheque or two... 

Also, you need a stable clock--I'm using an OCXO, but a TCXO will work
for shorter observing times.  So, if you are using a dongle, you'll need
to replace its clock. 

On 2016-12-01 15:19, Iain Young, G7III wrote:

> Hi Marcus,
> 
> Brilliant. I am in the middle of assembling my own radio telescope,
> but had not thought Pulsar reception would be possible.
> 
> I have a couple of questions on the RF Hardware. I see from some other
> updates, that the antenna is essentially sets of a 4 bay HDTV antenna.
> 
> How are you phasing them all together ? Just additive combiners with
> same length coax ? What amplification are you using before feeding
> them to the SDR ? Or ?
> 
> Best Regards
> 
> Iain
> 
> On 01/12/16 18:45, Marcus D. Leech wrote: 
> 
>> One of the many goals we set for ourselves at the Canadian Centre for
>> Experimental Radio Astronomy was to successfully observe
>> pulsar B0329+54 before spring.  This pulsar is the only one bright
>> enough for a small observatory in the northern hemisphere to
>> observe.
>> 
>> See our update:
>> 
>> http://www.ccera.ca/uncategorized/success-in-observing-pulsar-b032954/
>> 
>> The software is available via github:
>> 
>> https://github.com/ccera-astro/pulsar_pfb _display
>> 
>> No custom blocks required--just a modern Gnu Radio install, and ideally,
>> pyephem.
>> 
>> Doing this with Gnu Radio was so very easy...
>> 
>> ___
>> 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] Probable pulsar observing success at CCERA

[mleech]

Yes, they are Digiwave ANT2084--available on-line through WalMart as it
happens.  But any similar 4-bay antenna will work. 

We use 6 of them in a 2 x 3 array.  I was using a commercial combiner,
but it was lossy and had poor phase balance (actually any hybrid-tree
style combiner will have issues if the split ratio isn't a power of 2). 
I built my own transmission line combiner that combines all six in one
go, transforming the 12.5 parallel impedance of all those lines into
50ohm for the LNA.  Next time I build one, I shall use a
slightly-different layout that will improve phase match a bit. 

One can, of course, calculate the line lengths required to effect any
given pointing, but using matched-length lines from each module means
that the beam is pretty much aligned with the mechanical axis. 

The LNA is prefixed with a pair of shorted-quarter-wave stubs, and it's
a TQP3M9036, using the eval board available through DigiKey.  But there
are SPF5189Z LNAs on eBay at the moment for quite cheap that would do
just as well. 

If you have an 8-10ft dish already, then use that.  We went with the
"modular" approach, since it allows us to increase antenna gain without
taking down a dish and putting up a new one, and the HDTV antennae are
fairly cheap, and readily available anywhere.  They typically usefully
cover about 300Mhz to 850MHz. 

On 2016-12-01 15:19, Iain Young, G7III wrote:

> Hi Marcus,
> 
> Brilliant. I am in the middle of assembling my own radio telescope,
> but had not thought Pulsar reception would be possible.
> 
> I have a couple of questions on the RF Hardware. I see from some other
> updates, that the antenna is essentially sets of a 4 bay HDTV antenna.
> 
> How are you phasing them all together ? Just additive combiners with
> same length coax ? What amplification are you using before feeding
> them to the SDR ? Or ?
> 
> Best Regards
> 
> Iain
> 
> On 01/12/16 18:45, Marcus D. Leech wrote: 
> 
>> One of the many goals we set for ourselves at the Canadian Centre for
>> Experimental Radio Astronomy was to successfully observe
>> pulsar B0329+54 before spring.  This pulsar is the only one bright
>> enough for a small observatory in the northern hemisphere to
>> observe.
>> 
>> See our update:
>> 
>> http://www.ccera.ca/uncategorized/success-in-observing-pulsar-b032954/
>> 
>> The software is available via github:
>> 
>> https://github.com/ccera-astro/pulsar_pfb _display
>> 
>> No custom blocks required--just a modern Gnu Radio install, and ideally,
>> pyephem.
>> 
>> Doing this with Gnu Radio was so very easy...
>> 
>> ___
>> 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] Probable pulsar observing success at CCERA

[mleech]

This is 6MHz, centered at 611MHz (a notionally-TV channel that is
allocated in North America and Caribbean to Radio Astronomy). 

I used a PFB channelizer with individual detectors, and then delay
adjustment after the detectors and then simply added, low-pass filtered,
then resampled to a precise multiple of the current topcentric pulse
rate. 

On 2016-12-01 14:28, Matt Ettus wrote:

> That's awesome work!  Thanks for sharing it.  How much bandwidth are you 
> observing and did you also use de-dispersion? 
> 
> Matt 
> 
> On Thu, Dec 1, 2016 at 10:45 AM, Marcus D. Leech  wrote:
> 
>> One of the many goals we set for ourselves at the Canadian Centre for 
>> Experimental Radio Astronomy was to successfully observe
>> pulsar B0329+54 before spring.  This pulsar is the only one bright enough 
>> for a small observatory in the northern hemisphere to
>> observe.
>> 
>> See our update:
>> 
>> http://www.ccera.ca/uncategorized/success-in-observing-pulsar-b032954/ [1]
>> 
>> The software is available via github:
>> 
>> https://github.com/ccera-astro/pulsar_pfb [2] _display
>> 
>> No custom blocks required--just a modern Gnu Radio install, and ideally, 
>> pyephem.
>> 
>> Doing this with Gnu Radio was so very easy...
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]
 

Links:
--
[1]
http://www.ccera.ca/uncategorized/success-in-observing-pulsar-b032954/
[2] https://github.com/ccera-astro/pulsar_pfb
[3] 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] How to recover USRP MB EEPROM

[mleech]

They load their operating code (FPGA + CYPRESS FX2) over USB
dynamically. 

If you have a recent version of UHD, you should also have the images for
these devices. 

What does "lsusb" show for the USRP1 and B100 when you plug them into
the USB bus (with external power--these devices won't take power from
USB). 

On 2016-11-18 18:27, Marcus Müller wrote:

> Hi Rob,
> 
> this might be something more suited for the USRP-users mailing list [1 [1]],
> which I put in CC: here.
> 
>> My question is, how do I burn a startup code to EEPROM of...
> 
> The EEPROM doesn't contain any startup code, but just the serial number,
> device name and model.
> 
> You can change those with the usrp_burn_mb_eeprom (for the USRPs) or the
> usrp_burn_db_eeprom (for the daughterboard). But you usually don't.
> However, those tools will report the contents of the EEPROM. But: they
> only work if you can already talk to your USRP. If you can't, there
> might be something wrong.
> 
> Also the USRP1 and B100 do have firmware and FPGA images. But if I
> remember correctly, those are loaded at usage time when finding the
> device on the USRP1.
> 
> Best regards,
> 
> Marcus
> 
> [1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> On 18.11.2016 23:47, Robert Light wrote: 
> 
>> I have a couple of old USRP1 and B100 boards that I am trying to revive. My 
>> question is,
>> how do I burn a startup code to EEPROM of:
>> 1. USRP1
>> 2. B100
>> 3. RFX1800 ?
>> Does any of the UHD utils allow to dump all the contents of my old EEPROMS 
>> bit by bit to a file?
>> 
>> Rob
>> 
>> ___
>> 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
 

Links:
--
[1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Performance for GNU-Radio: Intel i3-6100 or AMD FX-4300

[mleech]

Yeah, the entire FX series (I think) has a single FP-unit per *pair* of
cores. 

This is in contrast to that which went before, the Phenom II X6, for
example, had 6 FP units. 

On 2016-09-22 12:53, Anon Lister wrote:

> The AMD only has 2 floating point units too, they just define "core" 
> differently(believe there was a class action lawsuit over this started 
> recently). Given GR is mostly FP math, I'd go with the intel.
> 
> On Sep 22, 2016 10:43 AM, "Fernando Peral"  wrote:
> 
>> I'm buying a new computer and two possible options will be intel
>> i3-6100   and AMD FX-4300.
>> 
>> Performance using GNU-Radio may be the key to the selection of one or
>> the other.
>> 
>> I guess the more cores the CPU, the better the performance.
>> 
>> FX-4300 is 4 cores,  i3-6100 is only two cores but they say both of them
>> runs 4 threads.
>> 
>> I should think that a real core (AMD) will work faster than a "logic"
>> one (intel), but reading benchmarks it seems that i3-6100 beats FX-4300
>> .  but  what with GNU-Radio?
>> 
>> Anyone has test both?
>> 
>> regards
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 

Links:
--
[1] 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] Performance for GNU-Radio: Intel i3-6100 or AMD FX-4300

[mleech]

Note that the FX series (at least, some of them) use a shared FPU
arrangement. 

Having said that, I have an FX-8350 system that does fairly well with 6
receivers operating at 2.56Msps, doing correlation interferometry
(computing 15 visibility functions in parallel for the 6 receivers). 

On 2016-09-22 11:55, Henry Barton wrote:

> I would go for more real cores. Back when I was doing CGI, I thought the  
> Pentium 4 with HT would be a good idea, but it wasn't. On that CPU, the  
> logical Intel cores only do integer operations; floating-point can only be  
> done on real cores. It's probably the same on the modern chips, otherwise  
> they'd just say 4 real cores. So even though I normally favor Intel PC's,  
> if these 2 are your only choices then I would suggest the AMD.
> 
> On Thu, 22 Sep 2016 10:20:50 -0400, Fernando Peral  
>  wrote:
> 
>> I'm buying a new computer and two possible options will be intel
>> i3-6100   and AMD FX-4300.
>> 
>> Performance using GNU-Radio may be the key to the selection of one or
>> the other.
>> 
>> I guess the more cores the CPU, the better the performance.
>> 
>> FX-4300 is 4 cores,  i3-6100 is only two cores but they say both of them
>> runs 4 threads.
>> 
>> I should think that a real core (AMD) will work faster than a "logic"
>> one (intel), but reading benchmarks it seems that i3-6100 beats FX-4300
>> .  but  what with GNU-Radio?
>> 
>> Anyone has test both?
>> 
>> regards
>> 
>> ___
>> 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] random phase offset constantly changing with octoclock setup

[mleech]

Any type of active GPS antennna will work. 

If you're using a passive antenna make sure you have a DC block in
place--some antennae are DC shorts. 

On 2016-07-11 16:16, Pavan Yedavalli wrote:

> 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  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,  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,  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  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 

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

[mleech]

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,  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  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  wrote:
> 
> O

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

[mleech]

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  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  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  wrote:
> 
> On 07/05/2016 11:45 PM, Pavan Yedavalli wrote: 
> Yes, sorry - two of them are actually connected via MIMO cable, 

Re: [Discuss-gnuradio] UHD FW Issue for NI USRP 2943R

[mleech]

You wanted to use the packaged Gnu Radio, which packages UHD 3.9.3, so,
that header show the correct version coming out of the UHD version that
is packaged with the GNu Radio package for windows. 

I asked you to remove the UHD 3.9.4 package that you'd installed
separately, because it was in conflict with the Gnu Radio install. 

On 2016-07-07 09:55, Sanat Kumar Mishra wrote:

> Hello,
> 
> Any uüdate on the below issue??
> 
> Now the link is not getting establisged to flash the images.
> 
> Regards,
> Sanat
> 
> Zitat von Sanat Kumar Mishra :
> 
> Hi again,
> 
> So this means that usrp_x310_fpga_HGS.lvbitx icludes both FW and FPGA image?
> 
> and we also still see the error of  "Win32; Microsoft Visual C++  version 
> 14.0; Boost_106000; UHD_003.009.003-0-unknown" even I have deleted the 
> standalone UHD 3.9.4

Best Regards,
Sanat

Quoting mle...@ripnet.com:

> X3xx images include both firmware and FPGA cod.e
> 
> On 2016-07-06 12:10, Sanat Kumar Mishra wrote:
> 
>> We have unistalled the UHD 3.9.4 and flashed the image of UHD   available 
>> with the GNUradio which is:
>> 
>> C:\Program Files\GNURadio-3.7\share\uhd\images\usrp_x310_fpga_HGS.lvbitx
>> 
>> my question, does this image include the FW and the FPGA together  as I  
>> have no option for standalone FW for the
>> x310 ?
>> 
>> Thank you for help
>> Sanat.
>> 
>> Quoting mle...@ripnet.com:
>> 
>> The installer that you used to install GNU RADIO *includes* UHD.  You
>> now have newer UHD interspersed with the version that came bundled with
>> your GnuRadio install.
>> 
>> On 2016-07-05 11:33, Sanat Kumar Mishra wrote:
>> 
>> UHD 3.9.36 is the latestv version of USRP Hardware Driver   available.  If I 
>> uninstall it then what do you recomend me to use   because as per  my 
>> understanding I need UHD to communicate with   USRP using GNU Radio.
>> 
>> Quoting mle...@ripnet.com:
>> 
>> The windows installer from that site seems to have been linked against
>> UHD 3.9.3, which is why the mismatch. There was no reason to have
>> separately installed UHD, since UHD is listed as a package that is
>> bundled into the installer.
>> 
>> I would remove the 3.9.4 UHD you have if you plan to use Gnu Radio
>> extensively, and the person who builds these windows releases will, at
>> some point, update the packaged UHD to 3.9.4 (or later).
>> 
>> On 2016-07-05 11:19, Sanat Kumar Mishra wrote:
>> 
>> Hi,
>> 
>> As suggested, I am putting the below mail in the discuss gnuradio list. 
>> I installed gnu radio from
>> http://www.gcndevelopment.com/gnuradio/downloads.htm
>> 64-Bit Any CPU - v3.7.9.2/v1.1.1.
>> 
>> I first Installed GNU radio and then Installed the UHD. Will that might 
>> be a reason for the below mentioned problem??
>> 
>> Best Regards,
>> Sanat
>> 
>> 
>> Not sure why you're getting the communication failtures, but your device
>> appears, from the uhd_usrp_probe output to be functioning correctly.
>> 
>> I suspect that your Gnu Radio installed was linked against UHD 3.9.3,
>> which is why the apparent version mismatch, because clearly, your
>> uhd_usrp_probe is linked against the newer library.
>> 
>> How did you install Gnu Radio?  This part of the discussion should
>> probably be continued on the discuss-gnuradio mailing list.
>> 
>> On 2016-07-05 10:58, Sanat Kumar Mishra wrote:
>> I have got the following results: Please note I am using NI USRP2943R   
>> which is like x310 from specification.
>> 
>> Microsoft Windows [Version 6.1.7601]
>> Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.
>> 
>> C:\Users\smishra>uhd_usrp_probe --args resource=RIO0
>> Win32; Microsoft Visual C++ version 14.0; Boost_105800;  
>> UHD_003.009.004-release
>> 
>> UHD Error:
>> x300 fw communication failure #1
>> EnvironmentError: IOError: x300 fw poke32 - operation timed out
>> 
>> UHD Error:
>> x300 fw communication failure #1
>> EnvironmentError: IOError: x300 fw poke32 - operation timed out
>> -- X300 initialization sequence...
>> -- Connecting to niusrpriorpc at localhost:5444...
>> -- Using LVBITX bitfile C:\Program Files  
>> (x86)\UHD\share\uhd\images\usrp_x310_fp
>> ga_HGS.lvbitx...
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- Detecting internal GPSDO No GPSDO found
>> -- Initialize Radio0 control...
>> -- Performing register loopback test... pass
>> -- Initialize Radio1 control...
>> -- Performing register loopback test... pass
>> _
>> /
>> |   Device: X-Series Device
>> | _
>> |/
>> |   |   Mboard: X310
>> |   |   revision: 8
>> |   |   revision_compat: 7
>> |   |   product: 30813
>> |   |   mac-addr0: 00:80:2f:25:18:f9
>> |   |   mac-addr1: 00:80:2f:25:18:fa
>> |   |   gateway: 192.168.10.1
>> |   |   ip-addr0: 192.168.10.2
>> |   |   sub

Re: [Discuss-gnuradio] UHD FW Issue for NI USRP 2943R

[mleech]

X3xx images include both firmware and FPGA cod.e 

On 2016-07-06 12:10, Sanat Kumar Mishra wrote:

> We have unistalled the UHD 3.9.4 and flashed the image of UHD  available with 
> the GNUradio which is:
> 
> C:\Program Files\GNURadio-3.7\share\uhd\images\usrp_x310_fpga_HGS.lvbitx
> 
> my question, does this image include the FW and the FPGA together as I  have 
> no option for standalone FW for the
> x310 ?
> 
> Thank you for help
> Sanat.
> 
> Quoting mle...@ripnet.com:
> 
> The installer that you used to install GNU RADIO *includes* UHD.  You
> now have newer UHD interspersed with the version that came bundled with
> your GnuRadio install.
> 
> On 2016-07-05 11:33, Sanat Kumar Mishra wrote:
> 
> UHD 3.9.36 is the latestv version of USRP Hardware Driver  available.  If I 
> uninstall it then what do you recomend me to use  because as per  my 
> understanding I need UHD to communicate with  USRP using GNU Radio.
> 
> Quoting mle...@ripnet.com:
> 
> The windows installer from that site seems to have been linked against
> UHD 3.9.3, which is why the mismatch. There was no reason to have
> separately installed UHD, since UHD is listed as a package that is
> bundled into the installer.
> 
> I would remove the 3.9.4 UHD you have if you plan to use Gnu Radio
> extensively, and the person who builds these windows releases will, at
> some point, update the packaged UHD to 3.9.4 (or later).
> 
> On 2016-07-05 11:19, Sanat Kumar Mishra wrote:
> 
> Hi,
> 
> As suggested, I am putting the below mail in the discuss gnuradiolist. I 
> installed gnu radio from
> http://www.gcndevelopment.com/gnuradio/downloads.htm
> 64-Bit Any CPU - v3.7.9.2/v1.1.1.
> 
> I first Installed GNU radio and then Installed the UHD. Will thatmight be 
> a reason for the below mentioned problem??
> 
> Best Regards,
> Sanat
> 
> 
> Not sure why you're getting the communication failtures, but your device
> appears, from the uhd_usrp_probe output to be functioning correctly.
> 
> I suspect that your Gnu Radio installed was linked against UHD 3.9.3,
> which is why the apparent version mismatch, because clearly, your
> uhd_usrp_probe is linked against the newer library.
> 
> How did you install Gnu Radio?  This part of the discussion should
> probably be continued on the discuss-gnuradio mailing list.
> 
> On 2016-07-05 10:58, Sanat Kumar Mishra wrote:
> I have got the following results: Please note I am using NI USRP   2943R   
> which is like x310 from specification.
> 
> Microsoft Windows [Version 6.1.7601]
> Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.
> 
> C:\Users\smishra>uhd_usrp_probe --args resource=RIO0
> Win32; Microsoft Visual C++ version 14.0; Boost_105800; 
> UHD_003.009.004-release
> 
> UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - operation timed out
> 
> UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - operation timed out
> -- X300 initialization sequence...
> -- Connecting to niusrpriorpc at localhost:5444...
> -- Using LVBITX bitfile C:\Program Files 
> (x86)\UHD\share\uhd\images\usrp_x310_fp
> ga_HGS.lvbitx...
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Detecting internal GPSDO No GPSDO found
> -- Initialize Radio0 control...
> -- Performing register loopback test... pass
> -- Initialize Radio1 control...
> -- Performing register loopback test... pass
> _
> /
> |   Device: X-Series Device
> | _
> |/
> |   |   Mboard: X310
> |   |   revision: 8
> |   |   revision_compat: 7
> |   |   product: 30813
> |   |   mac-addr0: 00:80:2f:25:18:f9
> |   |   mac-addr1: 00:80:2f:25:18:fa
> |   |   gateway: 192.168.10.1
> |   |   ip-addr0: 192.168.10.2
> |   |   subnet0: 255.255.255.0
> |   |   ip-addr1: 192.168.20.2
> |   |   subnet1: 255.255.255.0
> |   |   ip-addr2: 192.168.30.2
> |   |   subnet2: 255.255.255.0
> |   |   ip-addr3: 192.168.40.2
> |   |   subnet3: 255.255.255.0
> |   |   serial: 30D44AD
> |   |   FW Version: 4.0
> |   |   FPGA Version: 19.0
> |   |
> |   |   Time sources: internal, external, gpsdo
> |   |   Clock sources: internal, external, gpsdo
> |   |   Sensors: ref_locked
> |   | _
> |   |/
> |   |   |   RX DSP: 0
> |   |   |   Freq range: -100.000 to 100.000 MHz
> |   | _
> |   |/
> |   |   |   RX DSP: 1
> |   |   |   Freq range: -100.000 to 100.000 MHz
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: CBX-120 (0x0085)
> |   |   |   Serial: 30D2211
> |   |   | _
>

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

[mleech]

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 
> Cc: Discuss-gnuradio , 
> GNURadio Discussion List 
> 
> 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___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

[mleech]

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___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD FW Issue for NI USRP 2943R

[mleech]

The installer that you used to install GNU RADIO *includes* UHD.  You
now have newer UHD interspersed with the version that came bundled with
your GnuRadio install. 

On 2016-07-05 11:33, Sanat Kumar Mishra wrote:

> UHD 3.9.36 is the latestv version of USRP Hardware Driver available.  If I 
> uninstall it then what do you recomend me to use because as per  my 
> understanding I need UHD to communicate with USRP using GNU Radio.
> 
> Quoting mle...@ripnet.com:
> 
> The windows installer from that site seems to have been linked against
> UHD 3.9.3, which is why the mismatch. There was no reason to have
> separately installed UHD, since UHD is listed as a package that is
> bundled into the installer.
> 
> I would remove the 3.9.4 UHD you have if you plan to use Gnu Radio
> extensively, and the person who builds these windows releases will, at
> some point, update the packaged UHD to 3.9.4 (or later).
> 
> On 2016-07-05 11:19, Sanat Kumar Mishra wrote:
> 
> Hi,
> 
> As suggested, I am putting the below mail in the discuss gnuradio   list. I 
> installed gnu radio from
> http://www.gcndevelopment.com/gnuradio/downloads.htm
> 64-Bit Any CPU - v3.7.9.2/v1.1.1.
> 
> I first Installed GNU radio and then Installed the UHD. Will that   might be 
> a reason for the below mentioned problem??
> 
> Best Regards,
> Sanat
> 
> 
> Not sure why you're getting the communication failtures, but your device
> appears, from the uhd_usrp_probe output to be functioning correctly.
> 
> I suspect that your Gnu Radio installed was linked against UHD 3.9.3,
> which is why the apparent version mismatch, because clearly, your
> uhd_usrp_probe is linked against the newer library.
> 
> How did you install Gnu Radio?  This part of the discussion should
> probably be continued on the discuss-gnuradio mailing list.
> 
> On 2016-07-05 10:58, Sanat Kumar Mishra wrote:
> I have got the following results: Please note I am using NI USRP  2943R   
> which is like x310 from specification.
> 
> Microsoft Windows [Version 6.1.7601]
> Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.
> 
> C:\Users\smishra>uhd_usrp_probe --args resource=RIO0
> Win32; Microsoft Visual C++ version 14.0; Boost_105800;
> UHD_003.009.004-release
> 
> UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - operation timed out
> 
> UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - operation timed out
> -- X300 initialization sequence...
> -- Connecting to niusrpriorpc at localhost:5444...
> -- Using LVBITX bitfile C:\Program Files
> (x86)\UHD\share\uhd\images\usrp_x310_fp
> ga_HGS.lvbitx...
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Detecting internal GPSDO No GPSDO found
> -- Initialize Radio0 control...
> -- Performing register loopback test... pass
> -- Initialize Radio1 control...
> -- Performing register loopback test... pass
> _
> /
> |   Device: X-Series Device
> | _
> |/
> |   |   Mboard: X310
> |   |   revision: 8
> |   |   revision_compat: 7
> |   |   product: 30813
> |   |   mac-addr0: 00:80:2f:25:18:f9
> |   |   mac-addr1: 00:80:2f:25:18:fa
> |   |   gateway: 192.168.10.1
> |   |   ip-addr0: 192.168.10.2
> |   |   subnet0: 255.255.255.0
> |   |   ip-addr1: 192.168.20.2
> |   |   subnet1: 255.255.255.0
> |   |   ip-addr2: 192.168.30.2
> |   |   subnet2: 255.255.255.0
> |   |   ip-addr3: 192.168.40.2
> |   |   subnet3: 255.255.255.0
> |   |   serial: 30D44AD
> |   |   FW Version: 4.0
> |   |   FPGA Version: 19.0
> |   |
> |   |   Time sources: internal, external, gpsdo
> |   |   Clock sources: internal, external, gpsdo
> |   |   Sensors: ref_locked
> |   | _
> |   |/
> |   |   |   RX DSP: 0
> |   |   |   Freq range: -100.000 to 100.000 MHz
> |   | _
> |   |/
> |   |   |   RX DSP: 1
> |   |   |   Freq range: -100.000 to 100.000 MHz
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: CBX-120 (0x0085)
> |   |   |   Serial: 30D2211
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: CBX-120 RX
> |   |   |   |   Antennas: TX/RX, RX2, CAL
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 1200.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> |   |   |   |   Bandwidth range: 12000.0 to 12000.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | 

Re: [Discuss-gnuradio] UHD FW Issue for NI USRP 2943R

[mleech]

The windows installer from that site seems to have been linked against
UHD 3.9.3, which is why the mismatch. There was no reason to have
separately installed UHD, since UHD is listed as a package that is
bundled into the installer. 

I would remove the 3.9.4 UHD you have if you plan to use Gnu Radio
extensively, and the person who builds these windows releases will, at
some point, update the packaged UHD to 3.9.4 (or later). 

On 2016-07-05 11:19, Sanat Kumar Mishra wrote:

> Hi,
> 
> As suggested, I am putting the below mail in the discuss gnuradio  list. I 
> installed gnu radio from
> http://www.gcndevelopment.com/gnuradio/downloads.htm
> 64-Bit Any CPU - v3.7.9.2/v1.1.1.
> 
> I first Installed GNU radio and then Installed the UHD. Will that  might be a 
> reason for the below mentioned problem??
> 
> Best Regards,
> Sanat
> 
> 
> Not sure why you're getting the communication failtures, but your device
> appears, from the uhd_usrp_probe output to be functioning correctly.
> 
> I suspect that your Gnu Radio installed was linked against UHD 3.9.3,
> which is why the apparent version mismatch, because clearly, your
> uhd_usrp_probe is linked against the newer library.
> 
> How did you install Gnu Radio?  This part of the discussion should
> probably be continued on the discuss-gnuradio mailing list.
> 
> On 2016-07-05 10:58, Sanat Kumar Mishra wrote:
> I have got the following results: Please note I am using NI USRP 2943R   
> which is like x310 from specification.
> 
> Microsoft Windows [Version 6.1.7601]
> Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.
> 
> C:\Users\smishra>uhd_usrp_probe --args resource=RIO0
> Win32; Microsoft Visual C++ version 14.0; Boost_105800;   
> UHD_003.009.004-release
> 
> UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - operation timed out
> 
> UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - operation timed out
> -- X300 initialization sequence...
> -- Connecting to niusrpriorpc at localhost:5444...
> -- Using LVBITX bitfile C:\Program Files   
> (x86)\UHD\share\uhd\images\usrp_x310_fp
> ga_HGS.lvbitx...
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Detecting internal GPSDO No GPSDO found
> -- Initialize Radio0 control...
> -- Performing register loopback test... pass
> -- Initialize Radio1 control...
> -- Performing register loopback test... pass
> _
> /
> |   Device: X-Series Device
> | _
> |/
> |   |   Mboard: X310
> |   |   revision: 8
> |   |   revision_compat: 7
> |   |   product: 30813
> |   |   mac-addr0: 00:80:2f:25:18:f9
> |   |   mac-addr1: 00:80:2f:25:18:fa
> |   |   gateway: 192.168.10.1
> |   |   ip-addr0: 192.168.10.2
> |   |   subnet0: 255.255.255.0
> |   |   ip-addr1: 192.168.20.2
> |   |   subnet1: 255.255.255.0
> |   |   ip-addr2: 192.168.30.2
> |   |   subnet2: 255.255.255.0
> |   |   ip-addr3: 192.168.40.2
> |   |   subnet3: 255.255.255.0
> |   |   serial: 30D44AD
> |   |   FW Version: 4.0
> |   |   FPGA Version: 19.0
> |   |
> |   |   Time sources: internal, external, gpsdo
> |   |   Clock sources: internal, external, gpsdo
> |   |   Sensors: ref_locked
> |   | _
> |   |/
> |   |   |   RX DSP: 0
> |   |   |   Freq range: -100.000 to 100.000 MHz
> |   | _
> |   |/
> |   |   |   RX DSP: 1
> |   |   |   Freq range: -100.000 to 100.000 MHz
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: CBX-120 (0x0085)
> |   |   |   Serial: 30D2211
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: CBX-120 RX
> |   |   |   |   Antennas: TX/RX, RX2, CAL
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 1200.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> |   |   |   |   Bandwidth range: 12000.0 to 12000.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: A
> |   |   |   |   Name: ads62p48
> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
> |   | _
> |   |/
> |   |   |   RX Dboard: B
> |   |   |   ID: CBX-120 (0x0085)
> |   |   |   Serial: 30D2216
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: CBX-120 RX
> |   |   | 

Re: [Discuss-gnuradio] new user

[mleech]

The "PLL lock messages" are normal during start-up for the gr-osmosdr
rtl-sdr driver. 

SO, on your liveDVD image, you could do something like: 

osmocom_fft -a rtl=0 -f 101.1e6 -g 30 -s 1.0e6 --fft-rate 10 

Does you radio station show up on the FFT display? 

On 2016-07-04 11:49, Darin Decker wrote:

> Thank you Marcus!
> 
> Sorry, I should have been more clear. 
> When trying to use the little RTL-SDR dongle, I have the following:
> 
> 1. Tried to install on a Macbook Pro running El Capitan and that is where I'm 
> getting 'The xterm executable " is missing' issue.  When I just accept that 
> and the flow runs, I get the no module named osmosdr error from python.
> 
> 2. I have not tried to install GNU Radio on the Ubuntu 12.04 laptop because I 
> had seen somewhere that 14.04 was needed to run it but I can give it a shot.  
> 
> 3. Live DVD which has Ubuntu 14.04 on it has the PLL won't lock when tried on 
> either machine 
> 
> And just no luck at all trying to get the SDRplay to connect to it though I 
> can get it to work with CubicSDR and HDSDR(don't like either very much).
> 
> Thanks,
> Darin
> 
> On Jul 4, 2016, at 10:31 AM, Marcus Müller  wrote:
> 
> Hi Darin,
> 
> welcome! If I understand correctly, Ubuntu 12.04 is not supported I don't 
> think that's true! I'd personally recommend not using a more
> than four years old distro when doing new, non-legacy stuff, but you
> should be able to build things on Ubuntu 12.04. so I have not pursued that 
> much but focused on the Macbook Pro. ... which implies you're running OS X? 
> Or some other version of a Linux
> Distro than Ubuntu 12.04?
> 
> So, how did you install GNU Radio on that?
> 
> Best regards,
> Marcus
> 
> On 07/04/2016 04:52 PM, Darin Decker wrote: Good morning, I have been trying 
> to get Gnuradio up and and running all weekend on either a Macbook Pro or a 
> System 76 Ubuntu 12.04 machine but have not had any success.  If I understand 
> correctly, Ubuntu 12.04 is not supported so I have not pursued that much but 
> focused on the Macbook Pro. 
> 
> When I try to run gnuradio-companion on the Mac, I initially get 'The xterm 
> executable " is missing'.  When I search for gnu radio.conf, the file doesn't 
> seem to be on the computer.
> 
> Then when I run a simple flow(RTL-SDR Source -> WX GUI FFT Sink), i get a 
> python error of no module named osmosdr.
> 
> Then I tried the Live DVD.  Trying both from DVD and from USB Flashdrive.  On 
> both the System 76 and the Mac hardware, I get the same issue.
> 
> I have an RTL-SDR device and I believe the program is recognizing the device 
> because it says Rafael Tuner 820; however, it then says PLL won't lock.  I 
> have tried multiple FM broadcast frequencies; as well as, AM broadcast 
> frequencies.  On the FM, I'm inputting values of 101.1e06 for example.  On 
> the AM I input 108e04 as an example(1080 on am dial is the intended target in 
> that case).  
> 
> I also have a SDRplay but can't get that to connect at all.  Looks like if 
> you don't have a Windows machine, that doesn't seem to work well yet.  
> Guessing drivers or something on SDRplay side.
> 
> Any help is greatly appreciated.  For right now, I'm just wanting to get it 
> up and running in any way possible.
> 
> Darin
> ___
> 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] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[mleech]

I just forked Keenerd's repo, which actually has support for turning
dither on/off in the API, but of course, gr-osmosdr has no support for
it. 

My fork is: 

https://github.com/patchvonbraun/rtl-sdr 

Also the difference in frequency resolution with dither on/off is very
small--less than the error introduced by the standard crystal.

On 2016-06-28 06:55, Piotr Krysik wrote:

> W dniu 28.06.2016 o 12:25, Piotr Krysik pisze: W dniu 28.06.2016 o 03:31, 
> Marcus D. Leech pisze: On 06/25/2016 04:25 PM, Piotr Krysik wrote: W dniu 
> 25.06.2016 o 01:56, Marcus D. Leech pisze: On 05/26/2016 04:09 AM, Piotr 
> Krysik wrote: Is there some good candidate that can be asked to do that? When 
> I
> search
> for rtlsdr driver the first page with actual source code is osmocom's
> site:
> 
> sdr.osmocom.org/trac/wiki/rtl-sdr
> 
> Maybe they have the maintainer who feels responsible for how this code
> works?
> I can try to correct this offset in software (especially if it doesn't
> change too often) but it doesn't seem as the optimal solution.
> Frequency
> offset estimation might not be perfect either.
> 
> -- 
> Piotr Peter East has been playing with stuff as well, although his website
> has been suffering from the "Slashdot Effect(tm)" since RTL-SDR blog
> pointed to his paper a couple of days ago.  Now, he does all his
> stuff post-facto, rather than in real-time, but i don't see why there
> couldn't be two stages of 'sync' state in your code--one to do time
> synchronization, the other to do frequency-offset estimation based on
> the phase of the cross-correlation after time sync.The residual
> frequency offset (which shows up as a phase walk) is, according to
> Peter, always some small multiple of about 0.072Hz--he measures the
> slope of the cross-correlation a few thousand samples apart, and
> uses that to estimate the frequency offset.   That works well.
> 
> Ideally, yes, you just want the hardware to behave correctly--and for
> the standard drivers to take care of this.  But doing this in your
> multi-rtl block isn't a lot of extra work, and it means you get no
> residual phase-walk whether dither is turned on or off.
 Hi Marcus,

If it is possible to do estimate this frequency offset correctly (better
than one would expect from normal measurement thanks to some a-priori
knowledge like ~0.072Hz granularity that as you said might be there) - I
can live with additional step. What might be possibly harder for me to
swallow is if the estimated value of frequency offset has some error
that may be avoided if one patches rtl-sdr driver to include the changes
mentioned by you before.

Thanks for pointing to Peter's East work - I will try to experiment
with it.

Best Regards,
Piotr Krysik

 OK, now I've got people excited about building phased arrays.

I suspect that the existing block will get awkward to use after about
8 inputs.  I wonder if there's a re-org of the input parameters that
could make it less awkward?  Like having the device args all in one
line, having a "General" and "RF Parameters" tab, etc.

 Hi Marcus,

It's great to hear that there is interest in using the block. I can
change how parameters are displayed but I don't have clear idea how to
do this so the user experience with for a systems with 8+ inputs will be
improved. I can separate RF options to another tab but it won't improve
much - you will still have a very long list of parameters that you will
have to scroll.

I can do this - it is not any problem for me (actually I already did
this after your post:
https://github.com/ptrkrysik/multi-rtl/commit/dfda15b5332cafb7da9288707fc9c58be91370b6).
But in my opinion if you want to have more than 8 inputs you can
consider coding the flowgraph in Python. GRC might be cumbersome in
itself when you have blocks with
so many ports.

Regarding the coherent operation - I have to play with the driver
prepared by you. If it works fine - it is the way to go in my opinion.
Some people might still need dithering (i.e. because they don't care
about coherency but want to set the frequency more precisely). One
solution for this might be some additional option in the gr-osmosdr
block that turns on/off dithering. Or if frequencies for which dithering
is used can be easily listed/computed - then dithering can be just not
used when the user sets frequency that doesn't require it.

Best Regards,
Piotr

 By the way... do you have the driver source with added patches in some
publicly accessible repository?

Best Regards,
Piotr

___
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] File source problem

[mleech]

Among SDRs, there is no universal "model" for things like total gain,
acceptable baseband magnitudes, etc. Even if there were, expected
variations in analog behavior mean that you usually have to tweak things
to make it work across multiple hardware.  That's just an attribute of
the analog world that "all digital" folks may not be used to. 

On 2016-06-16 10:09, Olivier Goyette wrote:

> UPDATE
> 
> Even without any Costa loop or clock recovery, it works. It seems that the 
> trouble was only the TX amplitude. 
> 
> 2016-06-16 9:36 GMT-04:00 Olivier Goyette :
> 
> YEH ! it works now.
> 
> Only 2 major things to do :
> 
> 1st - I multiplied the TX amplitude by 0.5 with a multiply const block
> 
> 2nd - I used a Costa loop before my demod and it works great. 
> 
> My video got a tiny bit of error but I guess that with a special coding (reed 
> solomon ) I could get it back in good shape.
> 
> Now I gotta to test it but with CPFSK and see if I can get the same result !
> 
> Thank you all :) ! 
> 
> 2016-06-16 3:36 GMT-04:00 Johannes Demel :
> Hi Olivier,
> 
> I guess Nick already pointed out the important bits. Also, the warnings GRC 
> prints to the shell should help you.
> 
> Could you solve your file source issues? Your questions here seem to be 
> related to a different issue.
> 
> Tx flowgraph: get rid of the throttle block. (also see the warning)
> spectrum: this seems inconsistent. the TX spectrum suggests OFDM at first 
> glance. The MDO spectrum looks completely different. You should investigate 
> this.
> Most importantly here, the RX spectrum looks a lot like clipping/saturation 
> or alike. In any case non-linear effects seem to cause trouble here.
> TX time: It is important to keep the TX values < 1.0! Everything else will be 
> clipped. Non-linear effects.
> RX time: looks like a frequency offset. You need synchronization first. 
> Really tight synchronization, FLL, Costas-Loop etc. You may simulate that by 
> multiplying with a signal source with a really low frequency like 10Hz (or 
> maybe even 1Hz, play a bit around).
> Rx constellation: you can observe a frequency offset here.
> Rx time 2: my guess: it's the same as the other except for a scaling factor. 
> Maybe a different radio channel, maybe because the other hardware behaves a 
> bit differently.
> 
> Cheers
> Johannes 
> 
> On 15.06.2016 22:24, Olivier Goyette wrote: 
> 
> I'm giving a copy of the email I just sent to Ettus Research. I think
> that it's been a hardware problem since the beginning but i'm waiting
> for their response.
> 
> Check it out, maybe some of view have already seen this kind of bug
> 
> *E-mail*
> 
> Hi !
> 
> My name is Olivier and I'm actually working with your USRP N210 and
> GNURadio Companion. It's been a couple of week since I started using
> your equipment and yet, I already had issues with it. Doing a simple
> modulation/demodulation seems impossible and everything I came up with
> until now, suggest me that it's a hardware problem. So, I took quite a
> lot of pictures for you to see what's wrong and I'll share the links to
> my dropbox so it will be easier like that.
> 
> What I'm trying to do is a PSK mod and demod. I know it works because
> one of my colleague is using a Nutaq Zepto SDR and he's been using the
> same flowgraph as mine in an other project and it works perfectly. So,
> what we did is the following setup :
> https://www.dropbox.com/s/ottq341sob5z90r/Actual_setup.jpg?dl=0
> 
> The upper radio represents the TX link (WBX card) and the one at the
> bottom represent the RX link (SBX card).
> 
> This is the flowgraph on the TX radio :
> https://www.dropbox.com/s/ir5ehp6caiy525a/TX_side.jpg?dl=0
> 
> This is the flowgraph on the RX radio :
> https://www.dropbox.com/s/tl95cwbstwzl4r8/RX_side.jpg?dl=0
> 
> What we're trying to do is to transmit a video stream from one computer
> to another. Unfortunately, on the RX computer, the file supposedly
> containing the video is empty (0 bytes when you right click on it and go
> to the properties panel).
> 
> This is the TX spectrum :
> https://www.dropbox.com/s/pzsn8oo74sgrehp/TX_spectrum.jpg?dl=0 and this
> is the spectrum when you look at it with a spectrum analyser :
> https://www.dropbox.com/s/5bks7aksih8ctzh/TX_MDO_spectrum.jpg?dl=0
> 
> This is the RX spectrum :
> https://www.dropbox.com/s/dlsovfxovv4n9tm/RX_spectrum.jpg?dl=0
> 
> This is the TX time domain graph :
> https://www.dropbox.com/s/q25sbjukyzsyymz/TX_time_domain.jpg?dl=0
> 
> This is the RX time domain graph :
> https://www.dropbox.com/s/qetgf0cr4s7d5hb/RX_time_domain_1.jpg?dl=0
> 
> This is the TX constellation :
> https://www.dropbox.com/s/gflb0f65oa0m1rl/TX_constellation.jpg?dl=0
> 
> This is the RX constellation :
> https://www.dropbox.com/s/4j0hnhl97v2uj7g/RX_constellation.jpg?dl=0
> 
> What seems strange to me is the time domain graph at RX. It's like if
> the imaginary part and the real part 

Re: [Discuss-gnuradio] GNURadio Subdev spec

[mleech]

Use a subdev spec of: 

A:0 B:0 

And specify the RX2 antenna for each channel. 

On 2016-06-16 08:08, olvhammar wrote:

> Hi,
> 
> I have a Ettus X310 and two UBX-160 daughterboards. I'm looking to receive on 
> RX2 on each card simultaneously.
> How should I specify the subdev spec in my python/gnuradio application?
> 
> Regards Simon
> 
> ___
> 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] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[mleech]

A bias in the dither algorithm could explain that, which is why turning
off dither clears up the problem.  The drifting-out-of-lock problem is
due to charge-pump current settings being too low in some cases. 

On 2016-05-26 11:47, Juha Vierinen wrote:

> Would either of these issues in the rtlsdr driver consistently tune the two 
> dongles on slightly different frequencies, even if you ask them to tune to 
> exactly the same frequency? This is what the problem seems to be.  
> 
> juha 
> 
> On Wed, May 25, 2016 at 10:35 AM,  wrote:
> 
> There are a couple of issues with the rtlsdr driver used by gr-osmocom in 
> this regard: 
> 
> (A) The charge-pump loop current is too constrained for the higher 
> frequencies 
> 
> (B) The "dither" option appears to have a bias that causes a (small) 
> frequency offset. 
> 
> The driver that AirSpy uses fixes both of these, although without "dither", 
> the tuning granularity is worse.  Not sure this matters.
> 
> On 2016-05-25 09:28, Marcus Müller wrote: 
> That, or simply, the output clock VCO changes its reaction to the
> control voltage under certain circumstances (temperature, frequency) so
> much that the control loop loses the ability to reach stationary
> exactness (e.g. due to natural limits on the magnitude of the VCO
> voltage). These devices definitely were made with cost in mind - not
> with maximum reliability, and hence I can believe that for example with
> the Elonics E4000 tuner, the charge pump used to generate the VCO
> voltage simply might deteriorate with temperature.
> 
> Cheers,
> Marcus
> 
> On 25.05.2016 14:25, Sylvain Munaut wrote: Hi,
> 
> of the drift remains a mistery (probably due to the implementation of the PLL,
> but I cannot understand why Phase Locked Loops would drift in Phase !). If 
> the phase comparator is digital ( i.e. a XOR ) and the input clock
> is somewhat analog, the gate thresholds might vary depending on
> temperature, thus shifting the cycle a bit.
> 
> Just a thought.
> 
> Cheers,
> 
> Sylvain
> 
> ___
> 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] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[mleech]

The AirSpy uses the R820T2 chip for the tuner, but a different
sampling/DSP "engine". 

Yes, making the charge-pump and "dither" mods will help with
phase-coherence. 

Somebody needs to "own" the rtlsdr driver, and merge in the last couple
of years of field experience and branching that has gone on with it. 

On 2016-05-25 15:04, Piotr Krysik wrote:

> Hi Marcus,
> 
> I don't know much about AirSpy.
> 
> Does it use the same demodulator chip as current RTL-SDR dongles?
> And does it mean that change to low level part of rtlsdr driver might
> help to get rid of that frequency offset?
> 
> --
> Piotr
> 
> W dniu 25.05.2016 o 16:35, mle...@ripnet.com pisze: 
> There are a couple of issues with the rtlsdr driver used by gr-osmocom
> in this regard:
> 
> (A) The charge-pump loop current is too constrained for the higher
> frequencies
> 
> (B) The "dither" option appears to have a bias that causes a (small)
> frequency offset.
> 
> The driver that AirSpy uses fixes both of these, although without
> "dither", the tuning granularity is worse.  Not sure this matters.
> 
> On 2016-05-25 09:28, Marcus Müller wrote:
> 
> That, or simply, the output clock VCO changes its reaction to the
> control voltage under certain circumstances (temperature, frequency) so
> much that the control loop loses the ability to reach stationary
> exactness (e.g. due to natural limits on the magnitude of the VCO
> voltage). These devices definitely were made with cost in mind - not
> with maximum reliability, and hence I can believe that for example with
> the Elonics E4000 tuner, the charge pump used to generate the VCO
> voltage simply might deteriorate with temperature.
> 
> Cheers,
> Marcus
> 
> On 25.05.2016 14:25, Sylvain Munaut wrote: Hi,
> 
> of the drift remains a mistery (probably due to the implementation
> of the PLL,
> but I cannot understand why Phase Locked Loops would drift in Phase !). If 
> the phase comparator is digital ( i.e. a XOR ) and the input clock
> is somewhat analog, the gate thresholds might vary depending on
> temperature, thus shifting the cycle a bit.
> 
> Just a thought.
> 
> Cheers,
> 
> Sylvain
> 
> ___

___
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] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[mleech]

There are a couple of issues with the rtlsdr driver used by gr-osmocom
in this regard: 

  (A) The charge-pump loop current is too constrained for the higher
frequencies 

  (B) The "dither" option appears to have a bias that causes a (small)
frequency offset. 

The driver that AirSpy uses fixes both of these, although without
"dither", the tuning granularity is worse.  Not sure this matters. 

On 2016-05-25 09:28, Marcus Müller wrote:

> That, or simply, the output clock VCO changes its reaction to the
> control voltage under certain circumstances (temperature, frequency) so
> much that the control loop loses the ability to reach stationary
> exactness (e.g. due to natural limits on the magnitude of the VCO
> voltage). These devices definitely were made with cost in mind - not
> with maximum reliability, and hence I can believe that for example with
> the Elonics E4000 tuner, the charge pump used to generate the VCO
> voltage simply might deteriorate with temperature.
> 
> Cheers,
> Marcus
> 
> On 25.05.2016 14:25, Sylvain Munaut wrote: Hi,
> 
> of the drift remains a mistery (probably due to the implementation of the PLL,
> but I cannot understand why Phase Locked Loops would drift in Phase !). If 
> the phase comparator is digital ( i.e. a XOR ) and the input clock
> is somewhat analog, the gate thresholds might vary depending on
> temperature, thus shifting the cycle a bit.
> 
> Just a thought.
> 
> Cheers,
> 
> Sylvain
> 
> ___
> 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] UDP Source Error (on windows)

[mleech]

Not sure how this would get leveraged by itself. 

But there are likely lots of kernel calls that have parameters that are
ignored in certain contexts.  I would be astonished if a
general-purpose, long-lived, operating existed without that being the
case from time to time. 

On 2016-05-19 11:58, Andy Walls wrote:

> On Thu, 2016-05-19 at 11:32 -0400, mle...@ripnet.com wrote: 
> 
>> I'll comment that the Windows socket implementation isn't in
>> compliance with the spirit of the robustness principle.  But, whatevs.
>> Easy enough to just remove that option for the UDP case.
> 
> I think it's a bit of a security failing of Linux to allow injection of
> 4 unused bytes into the kernel space from user-space for every locally
> opened UDP socket.  I'm not sure how I could exploit it (perhaps coding
> a jump instruction to a no-op sled somewhere nearby?),  but I'm not that
> creative.
> 
> Meh.
> 
> -Andy___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UDP Source Error (on windows)

[mleech]

I'll comment that the Windows socket implementation isn't in compliance
with the spirit of the robustness principle.  But, whatevs.  Easy enough
to just remove that option for the UDP case. 

On 2016-05-19 08:59, Andy Walls wrote:

>> OK, I was able to reproduce the issue, and it appears to me to a core
>> GNURadio issue not specifically related to the installer
>> 
>> udp_source_impl.cc is setting the SO_LINGER option on the UDP socket,
>> which at least on Windows, causes a WSAENOPROTOOPT exception, because
>> linger doesn't really mean anything for a UDP socket.  
>> 
>> Perhaps the Linux folks can help here, but I'm guessing that this
>> option must be simply ignored on Linux so there is no error for most
>> users.  Looking at the man pages doesn't specify any particular
>> behavior required.
>> 
>> Geof
> 
> SO_LINGER gets processed by the Linux kernel generically here:
> 
> http://lxr.free-electrons.com/source/net/core/sock.c#L644
> 
> with no check against socket type.
> 
> The UDP socket handling doesn't use the resulting SOCK_LINGER flag
> setting.
> http://lxr.free-electrons.com/source/net/ipv4/udp.c
> http://lxr.free-electrons.com/source/net/ipv6/udp.c
> 
> Only TCP and the Bluetooth SCO protocol in the Linux kernel care about
> SO_LINGER.
> 
> Regards,
> Andy
> 
> ___
> 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] INMARSAT wide signal question

[mleech]

I assume you're asking "Is there a big blue DECODE ALL THE INMARSAT
THINGS" knob in Gnu Radio.  The answer to that would be a resounding NO.


If the question is, instead: 

   (1) Is the Gnu Radio development environment suitable for
*developing* signal-processing chains to decode INMARSAT 

   (2) Has anyone developed INMARSAT decoding/demod blocks for Gnu
Radio. 

For (1), the answer is yes.  For (2) the answer is--check with google. 
The phrase "inmarsat gnuradio" doesn't return a lot, but that doesn't
mean somewhere out there someone hasn't developed some capability. 

On 2016-05-03 15:45, Henry Barton wrote:

> http://rtlsdrblog.rtlsdrblog.netdna-cdn.com/wp-content/uploads/2015/10/sdrplay_lband-1024x573.png
>  
> 
> I didn't see the widest signal (bright yellow) from this picture on 
> sigidwiki.com. Does anyone know what it is? If so, can it be decoded by 
> GNUradio? Thanks. 
> ___
> 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-users] minimum PPS voltage for N200

[mleech]

What you're going to need to do is provide the *simplest* flow-graph
that demonstrates the issue, rather than requiring the community to
debug your entire end-to-end setup. 

Also a diagram of your setup showing the RF and 1PPS and 10MHz paths. 

On 2016-05-03 15:39, khalid.el-darymli wrote:

> Thanks again Marcus. I really appreciate your help.
> 
> I am setting Ref Clock / PPS to external, etc. I get the syncing to work 
> properly around a year ago. Since then, we made various changes and I think 
> one or more change may be causing the issue. Among the changes are: buy N200 
> units with a new revision (could that be a problem when syncing?), upgrading 
> GNU Radio / UHD, enabling Rs 232  echoing in the GPSDO, etc.
> 
> Similar to my last year tests (I entirely unplugged the RS 232 cable), and 
> now it is not detected as an Internal GPSDO. However, I am still having issue 
> syncing the two motherboards.
> 
> Attached are two figures for the phase drift between Rx1 vs. Rx2, and Rx1 vs. 
> Rx3. This was generated through splitting the Tx and looping it back to the 
> Rx's. Signal processing was done properly (for dechirping, downsamplng, etc). 
> My application is LFMCW radar, so each 490 samples in the attachment 
> represents one sweep, and sweeping was done continuously. 
> 
> angle(Rx1./Rx2) looks great. As to angle(Rx1./Rx3), I would expect a linear 
> phase offset between different motherboards. However, as .shown in the 
> attachment, Rx1 vs. Rx3 has weird phase spikes. I think this shows that, for 
> some reason, the Tx is not properly synced with the second motherboard. Any 
> ideas on what might be causing this issue?
> 
> I am using Starttech Ethernet Adapter (ST1000SPEX4). The problem I have with 
> this card is that it won't turn AUTONEG off, it is always on. Could this 
> cause the problem? 
> 
> I tried this on two different Ubuntu machines, with similar results as shown 
> in the attachment. 
> 
> For the first machine, 
> 
> UBUNTU 14.04 LTS
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.002-80-ge28d7844
> 
> For the second machine,
> UBUNTU 14.04 LTS
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.000-46-g5b706d29
> 
> I'll highly appreciate any suggestions to solve this problem.
> 
> Thank you.
> 
> Best wishes, 
> khalid
> 
> On Tue, May 3, 2016 at 1:45 PM,  wrote:
> 
> The only way the USRP knows that there's a GPSDO present is if the serial 
> data from the GSPDO is validated.  If it doesn't see that data, it concludes 
> that there's no (internal) GPSDO present. 
> 
> There is no concept of "external GPSDO" -- only that *something* is providing 
> 10MHz and 1PPS externally.  The N2xx has no idea what that might be. 
> 
> You should set both 1PPS and 10MHz clock to "external" in your flow-graph. 
> The only time "GPSDO" is used is when you have a properly-installed 
> internally-mounted, GPSDO unit.
> 
> On 2016-05-03 12:02, khalid.el-darymli wrote: 
> 
> Thanks Marcus. 
> 
> OK, I'm communicating with the external Firefly-1A GPSDO unit using an RS 232 
> cable. I am able to do so after enabling echoing on RS 232 from the GPSDO. 
> Would that be a problem? Do I need to completely disable the RS 232 echoing, 
> even while the RS 232 cable is completely unplugged?
> 
> When the RS 232 cable is plugged-in, N200 DETECTs it as an INTERNAL GPSDO. 
> When I completely unplug the RS 232 cable on both ends, I am not getting any 
> messages for detecting neither external nor internal GPSDO. It only shows the 
> following in the terminal for both N200 devices,
> 
> (1) catch time transition at pps edge (2) set time next pps (synchronously).
> 
> khalid
> 
> On Tue, May 3, 2016 at 12:20 PM,  wrote:
> 
> The PPS input is conditioned with a: 
> 
> http://www.ti.com/product/SN74AUP1T57/description 
> 
> Looks to me like it should work just fine.
> 
> On 2016-05-03 10:23, khalid.el-darymli via USRP-users wrote: 
> 
> Hi,
> 
> I'll appreciate any help on the following. According to the link below [1], 
> the PPS voltage for N200 should be in the range [3.3, 5] V p-p.
> [1] http://files.ettus.com/manual/page_usrp2.html#usrp2_hw_leds
> 
> I am getting a PPS signal through fan-outs from an external Firefly-1A GPSDO. 
> I measured the output PPS voltage using a scope, and it is 2.52 V P-P 
> (terminated with 50 ohms).
> 
> Would this relatively low PPS voltage work for N200?  I am having a problem 
> syncing two N200 units (2 LFRX/ 1 LFTX ), and I am not sure if this would be 
> the cause?
> 
> Thank you.
> 
> Best wishes, 
> Khalid
> 
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu

[mleech]

The native BER of 1000BASE-T is better than 1.0e-11 or so. 

Which means you'd expect a bad bit roughly every half-hour at 2msps
(64Mbit/sec), the bad-bit probabilities get worse as you make the cable
longer. 

On 2016-05-03 12:59, John Shields wrote:

> On 03/05/16 15:01, mle...@ripnet.com wrote: 
> 
> It's possible that we're dealing with a memory leak somewhere.  Could you 
> watch the memory consumption of simple_ra over time? 
> 
> Also, could you just run something like uhd_fft with the same sample rate for 
> long periods to see if it gets the same 'D' treatment? 
> 
> On 2016-05-03 04:32, John Shields wrote: 
> Thanks Marcus,
> 
> Have put answers in-line.
> 
> Kind Regards,
> 
> John
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 Ok, Marcus, will do. Overnight (NZ time) I got 1 D with the Atheros. I
should have said that the N200 was in the shack and the Ubuntu system in
the house. I have several runs of Ethernet out to the shack so will do
some experimentation on the different connections. Then I will move the
Ubuntu system to the shack and see if colocation helps. These
investigations will take some days but will let you know.

 Kind Regards,

  John___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu

[mleech]

This has me thinking that this is a PHY-layer issue. 

How long are your Ethernet runs, and are you using Cat5e cabling? 

On 2016-05-03 12:59, John Shields wrote:

> On 03/05/16 15:01, mle...@ripnet.com wrote: 
> 
> It's possible that we're dealing with a memory leak somewhere.  Could you 
> watch the memory consumption of simple_ra over time? 
> 
> Also, could you just run something like uhd_fft with the same sample rate for 
> long periods to see if it gets the same 'D' treatment? 
> 
> On 2016-05-03 04:32, John Shields wrote: 
> Thanks Marcus,
> 
> Have put answers in-line.
> 
> Kind Regards,
> 
> John
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 Ok, Marcus, will do. Overnight (NZ time) I got 1 D with the Atheros. I
should have said that the N200 was in the shack and the Ubuntu system in
the house. I have several runs of Ethernet out to the shack so will do
some experimentation on the different connections. Then I will move the
Ubuntu system to the shack and see if colocation helps. These
investigations will take some days but will let you know.

 Kind Regards,

  John___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] minimum PPS voltage for N200

[mleech]

The only way the USRP knows that there's a GPSDO present is if the
serial data from the GSPDO is validated.  If it doesn't see that data,
it concludes that there's no (internal) GPSDO present. 

There is no concept of "external GPSDO" -- only that *something* is
providing 10MHz and 1PPS externally.  The N2xx has no idea what that
might be. 

You should set both 1PPS and 10MHz clock to "external" in your
flow-graph. The only time "GPSDO" is used is when you have a
properly-installed internally-mounted, GPSDO unit. 

On 2016-05-03 12:02, khalid.el-darymli wrote:

> Thanks Marcus. 
> 
> OK, I'm communicating with the external Firefly-1A GPSDO unit using an RS 232 
> cable. I am able to do so after enabling echoing on RS 232 from the GPSDO. 
> Would that be a problem? Do I need to completely disable the RS 232 echoing, 
> even while the RS 232 cable is completely unplugged?
> 
> When the RS 232 cable is plugged-in, N200 DETECTs it as an INTERNAL GPSDO. 
> When I completely unplug the RS 232 cable on both ends, I am not getting any 
> messages for detecting neither external nor internal GPSDO. It only shows the 
> following in the terminal for both N200 devices,
> 
> (1) catch time transition at pps edge (2) set time next pps (synchronously).
> 
> khalid
> 
> On Tue, May 3, 2016 at 12:20 PM,  wrote:
> 
> The PPS input is conditioned with a: 
> 
> http://www.ti.com/product/SN74AUP1T57/description 
> 
> Looks to me like it should work just fine.
> 
> On 2016-05-03 10:23, khalid.el-darymli via USRP-users wrote: 
> 
> Hi,
> 
> I'll appreciate any help on the following. According to the link below [1], 
> the PPS voltage for N200 should be in the range [3.3, 5] V p-p.
> [1] http://files.ettus.com/manual/page_usrp2.html#usrp2_hw_leds
> 
> I am getting a PPS signal through fan-outs from an external Firefly-1A GPSDO. 
> I measured the output PPS voltage using a scope, and it is 2.52 V P-P 
> (terminated with 50 ohms).
> 
> Would this relatively low PPS voltage work for N200?  I am having a problem 
> syncing two N200 units (2 LFRX/ 1 LFTX ), and I am not sure if this would be 
> the cause?
> 
> Thank you.
> 
> Best wishes, 
> Khalid
> 
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu

[mleech]

It's possible that we're dealing with a memory leak somewhere.  Could
you watch the memory consumption of simple_ra over time? 

Also, could you just run something like uhd_fft with the same sample
rate for long periods to see if it gets the same 'D' treatment? 

On 2016-05-03 04:32, John Shields wrote:

> Thanks Marcus,
> 
> Have put answers in-line.
> 
> Kind Regards,
> 
> John
> 
> ___
> 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-users] minimum PPS voltage for N200

[mleech]

The PPS input is conditioned with a: 

http://www.ti.com/product/SN74AUP1T57/description 

Looks to me like it should work just fine. 

On 2016-05-03 10:23, khalid.el-darymli via USRP-users wrote:

> Hi,
> 
> I'll appreciate any help on the following. According to the link below [1], 
> the PPS voltage for N200 should be in the range [3.3, 5] V p-p.
> [1] http://files.ettus.com/manual/page_usrp2.html#usrp2_hw_leds
> 
> I am getting a PPS signal through fan-outs from an external Firefly-1A GPSDO. 
> I measured the output PPS voltage using a scope, and it is 2.52 V P-P 
> (terminated with 50 ohms).
> 
> Would this relatively low PPS voltage work for N200?  I am having a problem 
> syncing two N200 units (2 LFRX/ 1 LFTX ), and I am not sure if this would be 
> the cause?
> 
> Thank you.
> 
> Best wishes, 
> Khalid
> 
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Building on ODroid C2 running CentOS 7 report.

[mleech]

I use all of my Odroids that run GR in a "headless" mode--I find no
reason to do flow-graph development on the device itself, and processing
flowgraphs in radio astronomy just don't really need a graphical
component to be running on the Odroid. 

On 2016-04-28 13:28, Marcus Müller wrote:

> Do you *really* want to use GRC on the C2? Doesn't make much sense - a
> flow graph designed on a normal PC works identically on your C2 (iff all
> the blocks are there, too).
> Same goes for anything that has to do with the GUI blocks - I don't
> really know your intended application, but as a gut feeling, the C2 is
> an embedded device that I use for its size and power efficiency to be
> wherever my radio is, and then I'd visualize what I need on my PC
> sitting at my desk. You could, for example, use the C2 to receive and
> demodulate audio transmissions, and just selectively display them on a
> PC somewhere else by streaming the wanted channels over network, for
> example.
> 
> Best regards,
> Marcus
> 
> On 04/28/2016 07:23 PM, Lamar Owen wrote: On 04/28/2016 12:44 PM, Anon Lister 
> wrote: 
> Nice. I just did an x64 el7, so I only had to source build a few
> packages. I'd be curious to know what kind of performance you get on
> that platform.
> 
> I'll let you know.  I am so far very pleased with the performance.
> Quad 2GHz ARMv8 cores with 2GB RAM is reasonably fast.
> 
> For deps, you may be able to harvest a list from the the work Geoff
> has been doing for the windows build scripts[1]. He also lists the
> versions used.
> 
> Hmm, cool, I'll look into it.  Right now I'm winding my way down the
> rabbit hole of python dependencies.  The nice thing is that if I get
> stuck and if it is a 'noarch' RPM I can just load the x86_64 version
> (in theory..).
> 
> ___
> 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] Building on ODroid C2 running CentOS 7 report.

[mleech]

Kyle Keen does GR+friends packaging for Arch/ALARM, and may have some
insights. 

I've never tried to run build-gnuradio on ARM platforms, because the
flags required vary from platform to platform, and not that many
beginners are doing this for ARM platforms.  YMMV, etc, etc. 

On 2016-04-28 12:19, Marcus Müller wrote:

> Dear Owen,
> 
> I'd say the fact that you quickly eat up all your RAM is the best
> indication for it possibly being a good idea to cross-build for the
> Odroid on a PC. I've never actually did a cross-compilation for CentOS
> or Fedora packages (just for the same architecture), but that might just
> be the way to go: Get a .spec file for GNU Radio on x86_64, adjust it as
> necessary, and use it to build stuff for the C2. As said, I've never
> done this myself, though.
> 
> Best regards,
> Marcus
> 
> On 04/28/2016 06:13 PM, Lamar Owen wrote: 
> 
>> I have been successful in getting CentOS 7 onto an ODroid C2.  This is
>> the AArch64 version; armv8, 64-bit.
>> 
>> I did run into a bug in build-gnuradio, however.  The logic that
>> determines the release number for CentOS/RHEL/SL 6 is flawed.  The
>> logic looks for the pattern '*elease*6*' in /etc/redhat-release;
>> however, on the CentOS 7 AArch64 version, here's what is in that file:
>> [lowen@dhcp-pool169 ~]$ cat /etc/redhat-release
>> CentOS Linux release 7.2.1603 (AltArch)
>> [lowen@dhcp-pool169 ~]$
>> 
>> This incorrectly drives the script to try the prereqs for
>> CentOS/RHEL//SL 6 instead of 7.  Changing the test to '*elease*6.*'
>> fixes it.
>> 
>> I don't quite have a full GUI build of GNURadio yet since I've been
>> hand-building the EPEL dependencies one by one, and now I have another
>> list of deps to build. (There is no EPEL for CentOS7 on any arm,
>> 32 or 64-bit, yet).  The build, not counting GRC and a few other GUI
>> modules, takes over 6 and a half hours on the C2 and eats swap for
>> lunch (a couple of the wrapper files need >2GB of virt during the
>> build, and the C2 only has 2GB of RAM).
>> 
>> I'll give a fuller report once I have a successful GUI build, and/or
>> when EPEL is available for AArch64..
>> 
>> ___
>> 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] Apparent bug in gr-osmosdsr

[mleech]

 

Actually, I may have mis-spoke on this one. 

I had the gr-osmosdr source block set to "Manual" for DC-offset, and
that, as it turned out, led to a very different DC-offset spike, leading
to misleadingly-different power values. 

Turning them both to "Automatic" restored both app sanity, and mine. 

Thanks everyone for reading along, but, how do they put it "no fault
found". 

On 2016-04-12 14:19, Marcus D. Leech wrote: 

> Running using the UHD device path, with UHD from master, using device string 
> of:
> 
> uhd,type=b200,nchan=2
> 
> And configuring both channels identically (gain, bandwidth, antenna, 
> center-frequency)
> 
> The resulting signal magnitudes differ by 20dB for inputs that are identical.
> 
> Reconfigure to just use the underlying UHD source block--everything is 
> fine--the two channels are within 0.5dB of each other.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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] Overflow error in benchmark receiver side "DDDD"

[mleech]

 

What if you make the file "/dev/null" -- does this still happen? 

On 2016-04-05 14:12, monika bansal wrote: 

> Hii,
> 
> I am running benchmark code and on the receiver side after receiving some 
> number of packets(8000 so), it starts showing overflow errors ("") on 
> terminal. 
> Following is the system configuration 
> 
> python benchmark_rx.py -f 1100M --args "addr=10.32.38.163" 
> --to-file=/home/ashokbandi/GNU/a_rx.txt --bandwidth=50
> 
> Decreasing the bandwidth delays the error. 
> 
> I tried changing buffer size by setting net.core.rmem_max and 
> net.core.wmem_max to 33445532 but to no avail. 
> 
> Following is the screen shot of terminal
> 
> DDok: True pktno: 24116 n_rcvd: 9730 n_right: 9723
> ok: True pktno: 24182 n_rcvd: 9731 n_right: 9724
> DDok: True pktno: 24319 n_rcvd: 9732 n_right: 9725
> ok: True pktno: 24442 n_rcvd: 9733 n_right: 9726
> DDDok: True pktno: 24477 n_rcvd: 9734 n_right: 9727
> Dok: True pktno: 24568 n_rcvd: 9735 n_right: 9728
> Dok: 
> False pktno: 22729 n_rcvd: 9736 n_right: 9728
> 
> Thanks 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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] radio astronomy fast radio burst

[mleech]

 

Yes, entirely feasible if you kind of "fudge and pray" on the practical
realities. Even 10,000Jy is a tiny signal when cast in the context of a
small antenna (2-3dBi). 

But can the technical infrastructure be built with relatively-cheap
SDR-based kit, and Gnu Radio? Absolutely. 

On 2016-04-01 11:14, Dan McKenna wrote: 

> Marcus,
> 
> Thank you for your replies
> 
> Yes, No way with a dipole at a signal flux of 30J
> 
> In discussions with two of our faculty members I was told that
> the bursts can be 10,000 J and attempts to find an afterglow
> have not yielded certain results.
> 
> it is not known if any big antenna was really pointing at the burst such
> that the real gain of the antenna relative to the source position is known.
> 
> This project is looking for the Big Bursts 
> 
> Yes the V/UHF bands are very busy so the big key is the identification of 
> a burst that sweeps through the 10 Mhz bandwidth within certain criteria. 
> 
> The network would then be used to further process events using time of arrival
> as the second filter.
> 
> We would also like to make this work using two orthogonally polarized 
> antennas 
> 
> Does this seem more reasonable?
> 
> D.
> 
> The Lorimer burst was 30Jy peak, lasting only a few milliseconds. You 
> need instruments with *LARGE* effective apertures to "see" such an
> event, and I have doubts about the ability to use a mere ca 20 
> dipoles globally distributed to synthesize such an aperture. Most of the
> FRB events that have been logged are a *LOT* smaller than the Lorimer 
> event. Since those stations would likely not be phase-coherent,
> then any spectra adding would only improve sensitivity by 
> sqrt(N)--you don't get to effectively use the sum of the effective 
> apertures of
> the individual stations.
> 
> The CHIME observatory, currently entering early operations near 
> Penticton, BC, has FRBs as a secondary objective, and their antenna
> can hardly be described as "a dipole or two".
> 
> But, you're the astronomer, so perhaps there's something critical that 
> I've missed...
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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] radio astronomy fast radio burst help requested

[mleech]

 

The main thing is that these bursts are *weak* (< 1Jy typically), and
*short duration*. Detecting a CW weak source with smaller antennae is
feasible, because you can use long integration times. You have no such
option here, unless you're talking about hundreds or thousands of
dipoles, all phase coherent. 

For example, to equal the collecting area of Parkes, you'd need (at
500MHz): 

Parkes gain: 45dBi 

Dipole gain: 2.15dBi 

45 - 2.15 = 42.85dB(antenna) 

Almost 20,000 simple half-wave dipole antenna required, and they'd all
need to be phase-coherent. 

If I've botched the math, please correct me. 

On 2016-04-01 10:20, Alexander Levedahl wrote: 

> There are 3 options that I can think of: 1) Use multiple SDRs at each 
> location. 2) Run an optimization algorithm as a post processing step to 
> figure out what the phase synchronization should be. 
> 3) If there is a transmitting satellite near there in frequency, use that to 
> determine what the phase synch should be. 
> Each of these has a problem. 1) The necessary budget is larger.
> 
> 2) This will be computationally expensive if the feature to search for is 
> unknown. 
> 3) The sat signal and the bursts being looked for may propagate through the 
> ionosphere differently and so this may prove to be unreliable. 
> 
> On Fri, Apr 1, 2016 at 9:59 AM,  wrote:
> 
> VLBI guys usually have a local H1 maser clock, they go through a complex 
> synchronization ritual prior to the start of observations. H1 masers have 
> short-term stability on the order of 1e-16. 
> 
> GPS synchronization would be a *starting point* for such things. 
> 
> On 2016-04-01 08:42, madengr wrote: 
> 
> What would it take to get phase coherency, say at 1 GHz, on a global scale;
> short of running cables? I assume with a moderate priced GPSDO one can get
> 10E-12 stability, so that would be 0.01 Hz frequency stability at 1 GHz. 
> Does that mean you can integrate for 10 seconds and stay within 0.1 radian
> phase drift?
> Lou
> 
> Marcus D. Leech wrote
> Since those stations would likely not be phase-coherent, then any spectra 
> adding would only improve sensitivity by sqrt(N)--you don't get to 
> effectively use the sum of the effective apertures of the individual 
> stations. 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/radio-astronomy-fast-radio-burst-help-requested-tp59287p59297.html
>  [1]
> Sent from the GnuRadio mailing list archive at Nabble.com.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]

___
 Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]

 

Links:
--
[1]
http://gnuradio.4.n7.nabble.com/radio-astronomy-fast-radio-burst-help-requested-tp59287p59297.html
[2] 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] radio astronomy fast radio burst help requested

[mleech]

 

VLBI guys usually have a local H1 maser clock, they go through a complex
synchronization ritual prior to the start of observations. H1 masers
have short-term stability on the order of 1e-16. 

GPS synchronization would be a *starting point* for such things. 

On 2016-04-01 08:42, madengr wrote: 

> What would it take to get phase coherency, say at 1 GHz, on a global scale;
> short of running cables? I assume with a moderate priced GPSDO one can get
> 10E-12 stability, so that would be 0.01 Hz frequency stability at 1 GHz. 
> Does that mean you can integrate for 10 seconds and stay within 0.1 radian
> phase drift?
> Lou
> 
> Marcus D. Leech wrote
> 
>> Since those stations would likely not be phase-coherent, then any spectra 
>> adding would only improve sensitivity by sqrt(N)--you don't get to 
>> effectively use the sum of the effective apertures of the individual 
>> stations.
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/radio-astronomy-fast-radio-burst-help-requested-tp59287p59297.html
>  [1]
> Sent from the GnuRadio mailing list archive at Nabble.com.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]
 

Links:
--
[1]
http://gnuradio.4.n7.nabble.com/radio-astronomy-fast-radio-burst-help-requested-tp59287p59297.html
[2] 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] Idea for gr-osmosdr/rtlsdr drivers

[mleech]

 

How about a thingy that makes a note of the local high-precision time
when the first samples arrive in the work() function, and then somehow
make that available to higher layers, so that you can get a first-order
approximation of the time skew between the streams? 

 ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] comparing SDR upconverters, thermal stability

[mleech]

 

Tsys is essentially irrelevant for HF receivers, since Tambient is much,
much higher (thousands of K) than even some really-poor RF engineering
scenarios. 

At HF, galactic background can be very high--1e4K or more. 

On 2016-03-30 10:30, Marcus Müller wrote: 

> Hi Daniel,
> 
> haven't made experience with any of these upconverters; but:
> 
> The really temperature-sensitive aspect of an upconverter is probably
> the oscillator, not the mixer. So the trick might really be keeping
> your upconverter in the same environment as your SDR receiver (assuming
> both don't have overly well temperature-compensated or oven-controlled
> oscillators), as that will just as much limit your frequency accuracy.
> 
> Mixer circuits do exhibit conversion loss that tends to get worse with
> rising temperature, but that'll not distort your signal much.
> 
> The core question here is whether you'll deterioriate your system
> performance if you keep your upverter far from your antenna; my guess is
> that you'd have an LNA close to the antenna, anyway, so keeping the
> upverter's oscillator warm and cozy near your SDR device won't be that
> complicated, probably.
> 
> That brings one down to the question whether you have the chance to use
> the same oscillator for both your SDR device and the upconversion; that
> way, you'd only have to worry about one device drifting under any
> circumstance. Does your device give you the chance to couple out a clock
> or maybe transmit a sine?
> 
> Best regards,
> Marcus
> 
> On 30.03.2016 09:18, Daniel Pocock wrote:
> 
>> Hi all, Has anybody been using any of the upconverters for SDR and has 
>> anybody made any comparison of them? I've seen some comments suggesting that 
>> many of the low cost models have poor thermal stability[1], has anybody seen 
>> problems with this in practice for receiving modes like SSB on amateur HF 
>> bands? If this is an issue, is anybody aware of alternative models that are 
>> more robust? Regards, Daniel 1. 
>> http://www.rtl-sdr.com/review-of-the-spyverter-upconverter/#comment-79953 
>> [1] ___ Discuss-gnuradio mailing 
>> list Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]
 

Links:
--
[1]
http://www.rtl-sdr.com/review-of-the-spyverter-upconverter/#comment-79953
[2] 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] comparing SDR upconverters, thermal stability

[mleech]

 

I know that some of them, like the HAMITUP, use a socket for the XO,
which one could easily replace with a TCXO. Check with the
 manufacturers about the XO spec they use. 

On 2016-03-30 11:43, Daniel Pocock wrote: 

> On 30/03/16 16:49, mle...@ripnet.com wrote:
> 
>> All of them use reasonably good crystals or crystal XOs. Certainly a lot 
>> better than the RTLSDRs most of these were intended for. I assume that 
>> you're talking about frequency stability, rather than gain stability?
> 
> Yes, frequency stability. SSB voice signals in the HF spectrum may be
> around 3000 Hz wide
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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] comparing SDR upconverters, thermal stability

[mleech]

 

All of them use reasonably good crystals or crystal XOs. Certainly a lot
better than the RTLSDRs most of these were intended for. 

I assume that you're talking about frequency stability, rather than gain
stability? 

On 2016-03-30 03:18, Daniel Pocock wrote: 

> Hi all,
> 
> Has anybody been using any of the upconverters for SDR and has anybody
> made any comparison of them?
> 
> I've seen some comments suggesting that many of the low cost models have
> poor thermal stability[1], has anybody seen problems with this in
> practice for receiving modes like SSB on amateur HF bands?
> 
> If this is an issue, is anybody aware of alternative models that are
> more robust?
> 
> Regards,
> 
> Daniel
> 
> 1. http://www.rtl-sdr.com/review-of-the-spyverter-upconverter/#comment-79953 
> [1]
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]
 

Links:
--
[1]
http://www.rtl-sdr.com/review-of-the-spyverter-upconverter/#comment-79953
[2] 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] gnuradios place in the state of the art of SDR

[mleech]

 

Also, the question is somewhat bifurcated. There are two aspects: 

 (a) Which parameters in the hardware end of things have advanced, and
at what rate, and what is considered "state of the art". This gets
broken down into a few sub-categories: 

 o ADC/DAC speeds 

 o FPGA gate-counts and speed 

 o frequency-range of the analog front-ends, and analog performance
(noise figure, OIP3, etc) 

 (b) Advances in GPP hardware that support high-speed DSP on a regular
computer, and somewhat orthogonal to that, what "kewl new stuff" has
been implemented, and at what rate does that happen, and where can we
expect the "art" to evolve. 

On 2016-02-23 15:09, Maicon Kist wrote: 

> You probably will want to look at the papers published in this call for 
> papers: 
> 
> http://www.comsoc.org/commag/cfp/software-defined-radio-20-years-later [1] 
> 
> On February 23, 2016 at 17:05:49, Mabel Pita (mabel.pita2...@gmail.com) 
> wrote: 
> 
> Hi, 
> 
> Thank you so much for your answers. 
> Maybe i did not express myself correctly in my original mail. 
> I am taking a course on SDRs at my university, and an assignment is to do 
> some research about SDRs, especially on the state of the art of SDR, by this 
> i mean, the most cutting edge technology that is available nowadays on the 
> field. I have not been able to found information about this on the internet, 
> just different frameworks used for developing SDRs. However, i have to 
> justify somehow, that gnu radio is useful for serious academical research and 
> not a program for modest projects (not that i think that is this way but i 
> have to justify it somehow). For example, quote some important projects 
> developed in gnuradio, or important companies working with gnu radio, etc. 
> 
> Are there any books or papers that investigate this matter, and explain 
> thoroughly what is the most advanced technology to perform virtualization of 
> signal processing and why gnu radio is a good choice for this task? 
> 
> Thanks in advance. 
> 
> 2016-02-22 18:22 GMT-03:00 Michael Berman :
> 
> Mabel, 
> 
> I am kind of confused as to what you mean by "state of the art". I personally 
> would consider any SDR to be pretty state of the art; it has been around for 
> some years, but it is by no means common place. 
> 
> Being unfamiliar with SDRsharp, a quick google search and read through of 
> their website seems that the software is tuned fairly narrowly towards their 
> custom hardware which would be quite lacking in many more advanced 
> applications due to its USB 2.0 interface. From this, you can only take a 
> look at up to 10 MHz of spectrum at a time, and the overall bandwidth of the 
> product seems like it may be a nuance for some applications as it will only 
> go from 20 MHz to 1.8 GHz. Also, the SDRsharp software states it can be used 
> "with their partner hardware". If you are setting up a learning environment, 
> this may be restrictive in terms of capabilities of testing and system 
> designs by their and their partners hardware limitations. One last thing, 
> their software seems to be closed source. You cannot make changes or see how 
> things are done internally, all you have is the API. 
> 
> GNURadio is 100% open sourced and will work with a myriad of just about any 
> SDR hardware out there. All that needs to be done is a small interface set of 
> code be written to conform the hardware with GNURadio's code structure. With 
> this, as long as there is even an API for a hardware device, it is feasible 
> that any hardware could be interface with and use GNURadio (there is already 
> such code available for the airspy which is the base hardware for SDRsharp). 
> Also, with GNURadio being open source, if you wonder the exact algorithm that 
> something is using, you can go look at the source code. Also, if there is 
> something extremely custom that would be much better off with a custom code 
> block than piecing it together with pre-defined blocks. 
> 
> From my point of view (having used GNURadio for an academic project) I would 
> much prefer GNURadio. Being open source and having a community backing it as 
> it does let's you actually learn what's going on, instead of taking it at as 
> a black box, and never really knowing how things work at a lower level. 
> 
> Hope my rant finds some use. 
> 
> Michael Berman 
> 
> On Mon, Feb 22, 2016 at 12:48 PM, Mabel Pita  
> wrote: 
> 
> Hello, 
> 
> I am just starting to get into the world of SDRs, and i have been looking for 
> information about SDRs state of the art, and this is when i found GNURadio 
> and SDRsharp as the top contenders. 
> I know that i am writing to the gnuradio mailing list so i wont talk about 
> its competitors, but can someone tell me in an objective way whether gnuradio 
> is considered state of the art in the matter of sdrs? 
> 
> Are there any books / sites that treat this subject in a thorough manner? I 
> am doing this for a course at my college and it requires as a first step t

Re: [Discuss-gnuradio] Airspy: multiple boards available with GNU Radio?

[mleech]

 

Quick look. 

libairpsy provides an API to open based on serial number. Near as I can
tell, gr-osmosdr hasn't caught up with the newer airspy API. 

On 2015-12-18 14:07, Tom Rondeau wrote: 

> On Mon, Dec 7, 2015 at 2:23 PM, Mamoru Yamamoto  
> wrote:
> 
>> Mr. Tom Rondeau,
>> 
>> Thank you for the info. Yes, I thought of controlling the airspy by the 
>> source-block parameters. But, reading this URL.
>> 
>> http://sdr.osmocom.org/trac/wiki/GrOsmoSDR [1]
>> 
>> Airspy explanation is like this.
>> 
>> AirSpy? Source
>> airspy Use this argument without a value
>> bias=1|0 Enable or disable DC bias at the antenna input
>> 
>> So there seems no parameter for choosing 1 device from 2 (or more).
>> How can we control? I want to know this point...
>> 
>> Regards,
>> 
>> Mamoru Yamamoto
> 
> Any osmosdr people here that can help Mamoru? Sylvain, do you know anything 
> about this? 
> 
> Tom 
> 
> On 2015/12/08 0:36, Tom Rondeau wrote:
> On Sun, Dec 6, 2015 at 8:43 PM, Mamoru Yamamoto
> mailto:yamam...@rish.kyoto-u.ac.jp>> wrote:
> 
> Dear Experts,
> 
> We recently found Airspy as a very interesting SDR board for our
> purposes. Our project, some may already know, is to develop 2-channel
> (or more-channel) coherent receiver for satellite beacon. We so far are
> successful at 2-ch (150/400MHz) RX with USRP-1. We now search for new
> SDR boards for future expansion.
> 
> My question is simple. We bought 2 units of Airspy. Now we can run
> Airspy on Ubuntu, but do not know how to run 2 units from GNU Radio. Is
> it possible? Airspy software with Ubuntu consists of several programs.
> For example "airspy_info" can find 2 units on the PC and show info.
> "airspy_rx" can run by selecting one of the 2 units. Running 2
> "airspy_rx" programs from Ubuntu seems OK. However, now we do not know
> whether it is possible to control 2 Airspy from GNU Radio python code or
> not. We hope to know current situation and (hopefully) near-future
> possibilities.
> 
> Sincerely,
> 
> You can use the gr-osmosdr's source block to address multiple devices:
> 
> http://cgran.org/pages/gr-osmosdr.html [2]
> 
> Tom
> 
> -- 
> Mamoru Yamamoto / RISH, Kyoto University
> yamam...@rish.kyoto-u.ac.jp
> Phone +81-774-38-3814 [3], Cell +81-90-5653-7555 [4]

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [5]

 

Links:
--
[1] http://sdr.osmocom.org/trac/wiki/GrOsmoSDR
[2] http://cgran.org/pages/gr-osmosdr.html
[3] tel:%2B81-774-38-3814
[4] tel:%2B81-90-5653-7555
[5] 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] how to downgrade UHD？

[mleech]

 

Rebuild Gnu Radio against the new UHD. 

On 2015-12-04 10:57, like wrote: 

> Hi,all: 
> 
> unfortunately it becomes incompatible after the uhd update:
> 
> RuntimeError:
> GR-UHD detected ABI compatibility mismatch with UHD library.
> GR-UHD was build against ABI: 3.9.0-0,
> but UHD library reports ABI: 3.10.0-0
> Suggestion: install an ABI compatible version of UHD,
> or rebuild GR-UHD component against this ABI version.
> 
> So, how can I do? Downgrade UHD to 3.9.0 is a correct measure?
> 
> I'm confused how to downgrade UHD? I'm new in GNUradio. So please tell me in 
> detail.
> 
> Regards,
> 
> Kerry
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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 Latency.

[mleech]

 

You're probably just seeing the group delay of the interpolation filters
on the N210, which for a given configuration,
 should be of a fixed and predictable duration. 

On 2015-11-13 11:18, Will Thompson wrote: 

> Hi 
> 
> I have question about the latency of transmissions in the N210 USPR. 
> 
> A bit of back ground in my system: 
> 
> I have three nodes. 
> 
> One (Node1) that periodically transmits a signal. 
> 
> The one of the other nodes (Node2) tries to synchronise its transmission with 
> that of Node 1. 
> 
> Node3 is simply used to record the transmissions and check that they align. 
> 
> When Node2 starts up, it saves the rx_time of the initial stream item Tag 
> from the USRP source. 
> 
> It then listens for the periodic transmission from Node1. Node2 then 
> estimates the timing offset of Node1's transmission and starts to transmits 
> its signal that should be synchronised with Node1's. 
> 
> It adds a tx_time tag to its burst which is based on the rx_time tag of its 
> first arriving sample and a multiple of the sample time and then number of 
> sample bins needed to align with Node1's transmissions. 
> 
> (the system is working with a sample rate of 1Ms, centre frequency of 
> 2.48GHz, and using N210 with XCVR2450) 
> 
> The issue I'm having is that the actual transmission of Node2 is about 26us 
> behind that of Node1, and I'm wondering why this might be… is this a 
> predictable delay, or might it change with other systems? 
> 
> Possible issues might be that it is the delay between the Tx burst being 
> released from the buffers and actually being transmitted, but I feel that 
> 26us is quite a long time really. 
> 
> Or it might be from the original rx_time tag somehow. 
> 
> Any advice or insight into this would be greatly appreciated. 
> 
> Thanks. 
> 
> Will 
> 
> -- 
> 
> William Thompson Ph.D. 
> 
> Research Engineer 
> 
> Toshiba Research Europe Limited 
> 
> 32 Queen Square, Bristol, BS1 4ND, UK 
> 
> Tel: +44 (0) 117 906 0734 
> 
> -
> 
> NOTE: The information in this email and any attachments may be confidential 
> and/or legally privileged. This message may be read, copied and used only by 
> the intended recipient. If you are not the intended recipient, please destroy 
> this message, delete any copies held on your system and notify the sender 
> immediately.
> 
> Toshiba Research Europe Limited, registered in England and Wales (2519556). 
> Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
> England. Web: www.toshiba.eu/research/trl
> 
> -
> This email has been scanned for email related threats and delivered safely by 
> Mimecast.
> For more information please visit http://www.mimecast.com [2]
> -
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[2] http://www.mimecast.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DBPSK and USRPs

[mleech]

 

Your center frequency is in the 2.4GHz WiFi band. So, yeah, you could be
seeing lots of interference. 

On 2015-10-29 11:41, Washbourne, Logan wrote: 

> So I decimated both sides, right in front of the constellation plots. The TX 
> side looks a lot better, no zero groupings. The RX side still looks very 
> noisy. Could this be a product of my environment? 
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Tue, Oct 27, 2015 at 11:33 AM, Richard Bell  
> wrote:
> 
> To sanity check the transmitter, instead of showing the constellation of 
> every sample, show every other sample, i.e. decimate by 2 going into the 
> constellation plot. The two comes from the fact you use 2 samples/symbol. We 
> don't want to see the every sample on a constellation, only symbols. That's 
> why the transmitter block has the grouping it does. Once you've confirmed you 
> see the expected BPSK constellation, you can move on to the receiver. 
> 
> On Tue, Oct 27, 2015 at 9:08 AM,  wrote:
> 
> Try cranking your RX gain up/down 5dB and see how that affects your 
> constellation. 
> 
> On 2015-10-27 11:55, Washbourne, Logan wrote: 
> Ok, that sampling rate mismatch was my fault. The RX spectrum looks better 
> after that fix. The unpacked to packed bits didn't seem to remove the zero 
> grouping on the constellation plot. Here are pictures of the setup now.
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Tue, Oct 27, 2015 at 10:34 AM, Richard Bell  
> wrote:
> 
> Logan, make sure you're feeding packed bytes into the DPSK Mod block. That's 
> probably why you're seeing a constellation point at zero, you're feeding in 
> unpacked bytes. That might fix everything. 
> 
> Rich
> 
> Sent from my iPad 
> 
> On Oct 27, 2015, at 8:16 AM, mle...@ripnet.com wrote:
> 
> What does the spectral plot look like? It should look very similar to the TX 
> side of the house. 
> 
> On 2015-10-27 11:10, Washbourne, Logan wrote: 
> 
> Thanks for the info guys! They are both using antennas btw. I came in this 
> morning and turned the RX gain up pretty high, roughly 45dB, and the 
> constellation plot on the RX side is starting to look pretty square, which I 
> think is a bad sign. My thoughts are that with the increase in gain, there is 
> too much noise coming through.
> 
> I've been toying with adding in a frequency offset on the TX side. I've been 
> adding and subtracting up to 30kHz from the center frequency and I haven't 
> seen any improvement in the constellation plot on the RX side.
> 
> Another thing that is confusing me, on the TX constellation plot, before it 
> gets sent to the USRP, there are 3 groupings, -.5, 0, .5. I'm not sure where 
> the 0 points are coming from. Since this is DBPSK, there should only be -.5 
> and .5 groupings right?
> 
> Should this exercise be pretty straightforward? 
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 3:12 PM,  wrote:
> 
> Consulting now, the book of armaments, errr, UHD manual: 
> 
> http://files.ettus.com/manual/page_dboards.html#dboards_rfx [2] 
> 
> The RFX series has no TX RF gain control, output magnitude is entirely 
> dependent on baseband magnitude. 
> 
> There's 70dB of gain range on RX, however. So, crank up the RX gain. 
> 
> Also, across 1m, the path loss is about 40dB at 2.5GHz, your TX is probably 
> putting out 5dBm, so at the RX end, that's maybe as much as -35dBm. If your 
> RX is set properly, should be enough to see the signal. 
> 
> On 2015-10-26 15:46, Marcus Müller wrote: Hi!
> 
> * looking at your constellation, relief comes setting in: It looks pretty 
> circular to me; notice how the axes are scaled differently. So no 
> catastrophic IQ imbalance.
> * the fact that it's circular and not a line is probably the result of the 
> constellation sink not being able to achieve timing synchronization, i.e. it 
> doesn't "know" when a symbol starts
> * You're right, RX SNR is terrible. However, RX power is very little indeed
> * Rule of thumb: if(not clipping && in doubt) increase gain;
> * What exactly is your "RF channel": antennas, direct cable with attenuator?
> * The mistake I do every few months: Did you connect the antenna/cable to the 
> wrong SMA port?
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 20:33, Washbourne, Logan wrote: 
> I looked at the spectrums of both sides and the RX side looks to be inundated 
> with a lot of noise. I'm not sure if its my environment or my USRPs, but I 
> really expected to see some resemblance of a signal. I am posting links to 
> screencaps of the TX and RX sides.
> 
> http://imgur.com/GBTHw8T- [3] TX
> http://imgur.com/DBy8gqs [4] - RX
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 1:31 PM, Marcus Müller  
> wrote:
> 
> Can you compare the TX spectrum with the RX spectrum? Maybe it'd worthwhile 
> to first look at at e.g. 500kHz of

Re: [Discuss-gnuradio] DBPSK and USRPs

[mleech]

 

Try cranking your RX gain up/down 5dB and see how that affects your
constellation. 

On 2015-10-27 11:55, Washbourne, Logan wrote: 

> Ok, that sampling rate mismatch was my fault. The RX spectrum looks better 
> after that fix. The unpacked to packed bits didn't seem to remove the zero 
> grouping on the constellation plot. Here are pictures of the setup now.
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Tue, Oct 27, 2015 at 10:34 AM, Richard Bell  
> wrote:
> 
> Logan, make sure you're feeding packed bytes into the DPSK Mod block. That's 
> probably why you're seeing a constellation point at zero, you're feeding in 
> unpacked bytes. That might fix everything. 
> 
> Rich
> 
> Sent from my iPad 
> 
> On Oct 27, 2015, at 8:16 AM, mle...@ripnet.com wrote:
> 
> What does the spectral plot look like? It should look very similar to the TX 
> side of the house. 
> 
> On 2015-10-27 11:10, Washbourne, Logan wrote: 
> 
> Thanks for the info guys! They are both using antennas btw. I came in this 
> morning and turned the RX gain up pretty high, roughly 45dB, and the 
> constellation plot on the RX side is starting to look pretty square, which I 
> think is a bad sign. My thoughts are that with the increase in gain, there is 
> too much noise coming through.
> 
> I've been toying with adding in a frequency offset on the TX side. I've been 
> adding and subtracting up to 30kHz from the center frequency and I haven't 
> seen any improvement in the constellation plot on the RX side.
> 
> Another thing that is confusing me, on the TX constellation plot, before it 
> gets sent to the USRP, there are 3 groupings, -.5, 0, .5. I'm not sure where 
> the 0 points are coming from. Since this is DBPSK, there should only be -.5 
> and .5 groupings right?
> 
> Should this exercise be pretty straightforward? 
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 3:12 PM,  wrote:
> 
> Consulting now, the book of armaments, errr, UHD manual: 
> 
> http://files.ettus.com/manual/page_dboards.html#dboards_rfx [2] 
> 
> The RFX series has no TX RF gain control, output magnitude is entirely 
> dependent on baseband magnitude. 
> 
> There's 70dB of gain range on RX, however. So, crank up the RX gain. 
> 
> Also, across 1m, the path loss is about 40dB at 2.5GHz, your TX is probably 
> putting out 5dBm, so at the RX end, that's maybe as much as -35dBm. If your 
> RX is set properly, should be enough to see the signal. 
> 
> On 2015-10-26 15:46, Marcus Müller wrote: Hi!
> 
> * looking at your constellation, relief comes setting in: It looks pretty 
> circular to me; notice how the axes are scaled differently. So no 
> catastrophic IQ imbalance.
> * the fact that it's circular and not a line is probably the result of the 
> constellation sink not being able to achieve timing synchronization, i.e. it 
> doesn't "know" when a symbol starts
> * You're right, RX SNR is terrible. However, RX power is very little indeed
> * Rule of thumb: if(not clipping && in doubt) increase gain;
> * What exactly is your "RF channel": antennas, direct cable with attenuator?
> * The mistake I do every few months: Did you connect the antenna/cable to the 
> wrong SMA port?
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 20:33, Washbourne, Logan wrote: 
> I looked at the spectrums of both sides and the RX side looks to be inundated 
> with a lot of noise. I'm not sure if its my environment or my USRPs, but I 
> really expected to see some resemblance of a signal. I am posting links to 
> screencaps of the TX and RX sides.
> 
> http://imgur.com/GBTHw8T- [3] TX
> http://imgur.com/DBy8gqs [4] - RX
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 1:31 PM, Marcus Müller  
> wrote:
> 
> Can you compare the TX spectrum with the RX spectrum? Maybe it'd worthwhile 
> to first look at at e.g. 500kHz of RX spectrum to see whether, due to 
> frequency offset, some of the wanted signal simply gets cut off; admittedly, 
> with 2S/sym that's not too likely...
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 19:16, Washbourne, Logan wrote: 
> I am using 250k! 
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 1:05 PM, Marcus Müller  
> wrote:
> 
> Hello!
> what's the sampling rate you're using?
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 18:38, Washbourne, Logan wrote: 
> 
> Hello all,
> 
> I'm trying to take a step back from my previous postings and try a simple 
> approach to try and understand working with over the air communications with 
> the USRPs. Let me know if it would be better to post this in the USRPs-Users 
> list.
> 
> I'm trying to have a simple TX and simple RX side so I can eliminate and 
> unnecessary complications.
> 
> The TX side has the following flowgraph: Vector Source(preamble+data)->DPSK 
> Mod(DBPSK,2samples/symbol)-> Multiply C

Re: [Discuss-gnuradio] DBPSK and USRPs

[mleech]

 

What does the spectral plot look like? It should look very similar to
the TX side of the house. 

On 2015-10-27 11:10, Washbourne, Logan wrote: 

> Thanks for the info guys! They are both using antennas btw. I came in this 
> morning and turned the RX gain up pretty high, roughly 45dB, and the 
> constellation plot on the RX side is starting to look pretty square, which I 
> think is a bad sign. My thoughts are that with the increase in gain, there is 
> too much noise coming through.
> 
> I've been toying with adding in a frequency offset on the TX side. I've been 
> adding and subtracting up to 30kHz from the center frequency and I haven't 
> seen any improvement in the constellation plot on the RX side.
> 
> Another thing that is confusing me, on the TX constellation plot, before it 
> gets sent to the USRP, there are 3 groupings, -.5, 0, .5. I'm not sure where 
> the 0 points are coming from. Since this is DBPSK, there should only be -.5 
> and .5 groupings right?
> 
> Should this exercise be pretty straightforward? 
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 3:12 PM,  wrote:
> 
> Consulting now, the book of armaments, errr, UHD manual: 
> 
> http://files.ettus.com/manual/page_dboards.html#dboards_rfx [2] 
> 
> The RFX series has no TX RF gain control, output magnitude is entirely 
> dependent on baseband magnitude. 
> 
> There's 70dB of gain range on RX, however. So, crank up the RX gain. 
> 
> Also, across 1m, the path loss is about 40dB at 2.5GHz, your TX is probably 
> putting out 5dBm, so at the RX end, that's maybe as much as -35dBm. If your 
> RX is set properly, should be enough to see the signal. 
> 
> On 2015-10-26 15:46, Marcus Müller wrote: Hi!
> 
> * looking at your constellation, relief comes setting in: It looks pretty 
> circular to me; notice how the axes are scaled differently. So no 
> catastrophic IQ imbalance.
> * the fact that it's circular and not a line is probably the result of the 
> constellation sink not being able to achieve timing synchronization, i.e. it 
> doesn't "know" when a symbol starts
> * You're right, RX SNR is terrible. However, RX power is very little indeed
> * Rule of thumb: if(not clipping && in doubt) increase gain;
> * What exactly is your "RF channel": antennas, direct cable with attenuator?
> * The mistake I do every few months: Did you connect the antenna/cable to the 
> wrong SMA port?
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 20:33, Washbourne, Logan wrote: 
> I looked at the spectrums of both sides and the RX side looks to be inundated 
> with a lot of noise. I'm not sure if its my environment or my USRPs, but I 
> really expected to see some resemblance of a signal. I am posting links to 
> screencaps of the TX and RX sides.
> 
> http://imgur.com/GBTHw8T- [3] TX
> http://imgur.com/DBy8gqs [4] - RX
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 1:31 PM, Marcus Müller  
> wrote:
> 
> Can you compare the TX spectrum with the RX spectrum? Maybe it'd worthwhile 
> to first look at at e.g. 500kHz of RX spectrum to see whether, due to 
> frequency offset, some of the wanted signal simply gets cut off; admittedly, 
> with 2S/sym that's not too likely...
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 19:16, Washbourne, Logan wrote: 
> I am using 250k! 
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 1:05 PM, Marcus Müller  
> wrote:
> 
> Hello!
> what's the sampling rate you're using?
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 18:38, Washbourne, Logan wrote: 
> 
> Hello all,
> 
> I'm trying to take a step back from my previous postings and try a simple 
> approach to try and understand working with over the air communications with 
> the USRPs. Let me know if it would be better to post this in the USRPs-Users 
> list.
> 
> I'm trying to have a simple TX and simple RX side so I can eliminate and 
> unnecessary complications.
> 
> The TX side has the following flowgraph: Vector Source(preamble+data)->DPSK 
> Mod(DBPSK,2samples/symbol)-> Multiply Const(.707) -> UHD:USRP SINK(2.448GHz 
> center freq, 10dB default gain)
> 
> RX Side: UHD:USRP Source(2.448GHz center freq, 10dB gain default) -> DPSK 
> DEMOD(DBPSK, 2 samples/ symbol, rest default values) - > file sink
> 
> I'm checking the progress of the communication by looking at a constellation 
> plot that is connected directly to the USRP SOURCE block on the receiver 
> side. I'm getting a very elliptical shape, more spread out in the horizontal 
> direction but not by much. I'm also looking at the bits from the receiver 
> side in matlab and my preamble is not showing up.
> 
> These were the same problems I had when trying to use a correlated system for 
> OTA communications. I feel like I'm missing something really simple.
> 
> Does anyone know of a simple TX, RX grc setup that I can use to test my US

Re: [Discuss-gnuradio] DBPSK and USRPs

[mleech]

 

You're transmitting at 1MS, and receiving at 250ksps. Your receiver is
only seeing part of your signal. 

On 2015-10-27 11:27, Washbourne, Logan wrote: 

> The RX side looks drowned out, almost like its all noise.
> 
> I'm attaching the pictures, hopefully they make it trough the email filter. 
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Tue, Oct 27, 2015 at 10:16 AM,  wrote:
> 
> What does the spectral plot look like? It should look very similar to the TX 
> side of the house. 
> 
> On 2015-10-27 11:10, Washbourne, Logan wrote: 
> 
> Thanks for the info guys! They are both using antennas btw. I came in this 
> morning and turned the RX gain up pretty high, roughly 45dB, and the 
> constellation plot on the RX side is starting to look pretty square, which I 
> think is a bad sign. My thoughts are that with the increase in gain, there is 
> too much noise coming through.
> 
> I've been toying with adding in a frequency offset on the TX side. I've been 
> adding and subtracting up to 30kHz from the center frequency and I haven't 
> seen any improvement in the constellation plot on the RX side.
> 
> Another thing that is confusing me, on the TX constellation plot, before it 
> gets sent to the USRP, there are 3 groupings, -.5, 0, .5. I'm not sure where 
> the 0 points are coming from. Since this is DBPSK, there should only be -.5 
> and .5 groupings right?
> 
> Should this exercise be pretty straightforward? 
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 3:12 PM,  wrote:
> 
> Consulting now, the book of armaments, errr, UHD manual: 
> 
> http://files.ettus.com/manual/page_dboards.html#dboards_rfx [2] 
> 
> The RFX series has no TX RF gain control, output magnitude is entirely 
> dependent on baseband magnitude. 
> 
> There's 70dB of gain range on RX, however. So, crank up the RX gain. 
> 
> Also, across 1m, the path loss is about 40dB at 2.5GHz, your TX is probably 
> putting out 5dBm, so at the RX end, that's maybe as much as -35dBm. If your 
> RX is set properly, should be enough to see the signal. 
> 
> On 2015-10-26 15:46, Marcus Müller wrote: Hi!
> 
> * looking at your constellation, relief comes setting in: It looks pretty 
> circular to me; notice how the axes are scaled differently. So no 
> catastrophic IQ imbalance.
> * the fact that it's circular and not a line is probably the result of the 
> constellation sink not being able to achieve timing synchronization, i.e. it 
> doesn't "know" when a symbol starts
> * You're right, RX SNR is terrible. However, RX power is very little indeed
> * Rule of thumb: if(not clipping && in doubt) increase gain;
> * What exactly is your "RF channel": antennas, direct cable with attenuator?
> * The mistake I do every few months: Did you connect the antenna/cable to the 
> wrong SMA port?
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 20:33, Washbourne, Logan wrote: 
> I looked at the spectrums of both sides and the RX side looks to be inundated 
> with a lot of noise. I'm not sure if its my environment or my USRPs, but I 
> really expected to see some resemblance of a signal. I am posting links to 
> screencaps of the TX and RX sides.
> 
> http://imgur.com/GBTHw8T- [3] TX
> http://imgur.com/DBy8gqs [4] - RX
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 1:31 PM, Marcus Müller  
> wrote:
> 
> Can you compare the TX spectrum with the RX spectrum? Maybe it'd worthwhile 
> to first look at at e.g. 500kHz of RX spectrum to see whether, due to 
> frequency offset, some of the wanted signal simply gets cut off; admittedly, 
> with 2S/sym that's not too likely...
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 19:16, Washbourne, Logan wrote: 
> I am using 250k! 
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 1:05 PM, Marcus Müller  
> wrote:
> 
> Hello!
> what's the sampling rate you're using?
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 18:38, Washbourne, Logan wrote: 
> 
> Hello all,
> 
> I'm trying to take a step back from my previous postings and try a simple 
> approach to try and understand working with over the air communications with 
> the USRPs. Let me know if it would be better to post this in the USRPs-Users 
> list.
> 
> I'm trying to have a simple TX and simple RX side so I can eliminate and 
> unnecessary complications.
> 
> The TX side has the following flowgraph: Vector Source(preamble+data)->DPSK 
> Mod(DBPSK,2samples/symbol)-> Multiply Const(.707) -> UHD:USRP SINK(2.448GHz 
> center freq, 10dB default gain)
> 
> RX Side: UHD:USRP Source(2.448GHz center freq, 10dB gain default) -> DPSK 
> DEMOD(DBPSK, 2 samples/ symbol, rest default values) - > file sink
> 
> I'm checking the progress of the communication by looking at a constellation 
> plot that is connected directly to the USRP SOURCE block on the receiver 
> si

Re: [Discuss-gnuradio] DBPSK and USRPs

[mleech]

 

Consulting now, the book of armaments, errr, UHD manual: 

http://files.ettus.com/manual/page_dboards.html#dboards_rfx 

The RFX series has no TX RF gain control, output magnitude is entirely
dependent on baseband magnitude. 

There's 70dB of gain range on RX, however. So, crank up the RX gain. 

Also, across 1m, the path loss is about 40dB at 2.5GHz, your TX is
probably putting out 5dBm, so at the RX end, that's maybe as much as
-35dBm. If your RX is set properly, should be enough to see the signal. 

On 2015-10-26 15:46, Marcus Müller wrote: 

> Hi!
> 
> * looking at your constellation, relief comes setting in: It looks pretty 
> circular to me; notice how the axes are scaled differently. So no 
> catastrophic IQ imbalance.
> * the fact that it's circular and not a line is probably the result of the 
> constellation sink not being able to achieve timing synchronization, i.e. it 
> doesn't "know" when a symbol starts
> * You're right, RX SNR is terrible. However, RX power is very little indeed
> * Rule of thumb: if(not clipping && in doubt) increase gain;
> * What exactly is your "RF channel": antennas, direct cable with attenuator?
> * The mistake I do every few months: Did you connect the antenna/cable to the 
> wrong SMA port?
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 20:33, Washbourne, Logan wrote: 
> I looked at the spectrums of both sides and the RX side looks to be inundated 
> with a lot of noise. I'm not sure if its my environment or my USRPs, but I 
> really expected to see some resemblance of a signal. I am posting links to 
> screencaps of the TX and RX sides.
> 
> http://imgur.com/GBTHw8T- [2] TX
> http://imgur.com/DBy8gqs [3] - RX
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 1:31 PM, Marcus Müller  
> wrote:
> 
> Can you compare the TX spectrum with the RX spectrum? Maybe it'd worthwhile 
> to first look at at e.g. 500kHz of RX spectrum to see whether, due to 
> frequency offset, some of the wanted signal simply gets cut off; admittedly, 
> with 2S/sym that's not too likely...
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 19:16, Washbourne, Logan wrote: 
> I am using 250k! 
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 1:05 PM, Marcus Müller  
> wrote:
> 
> Hello!
> what's the sampling rate you're using?
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 18:38, Washbourne, Logan wrote: 
> 
> Hello all,
> 
> I'm trying to take a step back from my previous postings and try a simple 
> approach to try and understand working with over the air communications with 
> the USRPs. Let me know if it would be better to post this in the USRPs-Users 
> list.
> 
> I'm trying to have a simple TX and simple RX side so I can eliminate and 
> unnecessary complications.
> 
> The TX side has the following flowgraph: Vector Source(preamble+data)->DPSK 
> Mod(DBPSK,2samples/symbol)-> Multiply Const(.707) -> UHD:USRP SINK(2.448GHz 
> center freq, 10dB default gain)
> 
> RX Side: UHD:USRP Source(2.448GHz center freq, 10dB gain default) -> DPSK 
> DEMOD(DBPSK, 2 samples/ symbol, rest default values) - > file sink
> 
> I'm checking the progress of the communication by looking at a constellation 
> plot that is connected directly to the USRP SOURCE block on the receiver 
> side. I'm getting a very elliptical shape, more spread out in the horizontal 
> direction but not by much. I'm also looking at the bits from the receiver 
> side in matlab and my preamble is not showing up.
> 
> These were the same problems I had when trying to use a correlated system for 
> OTA communications. I feel like I'm missing something really simple.
> 
> Does anyone know of a simple TX, RX grc setup that I can use to test my USRPs?
> 
> Again, I really appreciate the help you guys give.
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

 ___
 Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

 

Links:
--
[1] https://lists.gnu.org/mailma

Re: [Discuss-gnuradio] DBPSK and USRPs

[mleech]

 

With antennae, or with a cable, and if with a cable, how much
attenuation in the cable system? 

On 2015-10-26 15:54, Washbourne, Logan wrote: 

> Tx and Rx are on their own USRP1s, the daughter board is the RFX2400. They 
> are roughl 3ft apart from each other on a desk. The Rx side is using the RX2 
> port. 
> 
> I will definitely try upping the gain when I get back into the office 
> tomorrow. I will check the SMA ports, I didn't configure these myself so I 
> should probably double check them anyways. 
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 2:46 PM, Marcus Müller  
> wrote:
> 
> Hi!
> 
> * looking at your constellation, relief comes setting in: It looks pretty 
> circular to me; notice how the axes are scaled differently. So no 
> catastrophic IQ imbalance.
> * the fact that it's circular and not a line is probably the result of the 
> constellation sink not being able to achieve timing synchronization, i.e. it 
> doesn't "know" when a symbol starts
> * You're right, RX SNR is terrible. However, RX power is very little indeed
> * Rule of thumb: if(not clipping && in doubt) increase gain;
> * What exactly is your "RF channel": antennas, direct cable with attenuator?
> * The mistake I do every few months: Did you connect the antenna/cable to the 
> wrong SMA port?
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 20:33, Washbourne, Logan wrote: 
> I looked at the spectrums of both sides and the RX side looks to be inundated 
> with a lot of noise. I'm not sure if its my environment or my USRPs, but I 
> really expected to see some resemblance of a signal. I am posting links to 
> screencaps of the TX and RX sides.
> 
> http://imgur.com/GBTHw8T- [2] TX
> http://imgur.com/DBy8gqs [3] - RX
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 1:31 PM, Marcus Müller  
> wrote:
> 
> Can you compare the TX spectrum with the RX spectrum? Maybe it'd worthwhile 
> to first look at at e.g. 500kHz of RX spectrum to see whether, due to 
> frequency offset, some of the wanted signal simply gets cut off; admittedly, 
> with 2S/sym that's not too likely...
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 19:16, Washbourne, Logan wrote: 
> I am using 250k! 
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 1:05 PM, Marcus Müller  
> wrote:
> 
> Hello!
> what's the sampling rate you're using?
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 18:38, Washbourne, Logan wrote: 
> 
> Hello all,
> 
> I'm trying to take a step back from my previous postings and try a simple 
> approach to try and understand working with over the air communications with 
> the USRPs. Let me know if it would be better to post this in the USRPs-Users 
> list.
> 
> I'm trying to have a simple TX and simple RX side so I can eliminate and 
> unnecessary complications.
> 
> The TX side has the following flowgraph: Vector Source(preamble+data)->DPSK 
> Mod(DBPSK,2samples/symbol)-> Multiply Const(.707) -> UHD:USRP SINK(2.448GHz 
> center freq, 10dB default gain)
> 
> RX Side: UHD:USRP Source(2.448GHz center freq, 10dB gain default) -> DPSK 
> DEMOD(DBPSK, 2 samples/ symbol, rest default values) - > file sink
> 
> I'm checking the progress of the communication by looking at a constellation 
> plot that is connected directly to the USRP SOURCE block on the receiver 
> side. I'm getting a very elliptical shape, more spread out in the horizontal 
> direction but not by much. I'm also looking at the bits from the receiver 
> side in matlab and my preamble is not showing up.
> 
> These were the same problems I had when trying to use a correlated system for 
> OTA communications. I feel like I'm missing something really simple.
> 
> Does anyone know of a simple TX, RX grc setup that I can use to test my USRPs?
> 
> Again, I really appreciate the help you guys give.
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

 ___
 Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

___
 Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
h

Re: [Discuss-gnuradio] DBPSK and USRPs

[mleech]

 

How much attenuation do you have in the path between the TX and RX? What
daughtercards? Two separate USRPs, or a single, looped back? 

If you turn the RX gain up, does the RX FFT change? Are you on the RX2
port on the RX side? 

On 2015-10-26 15:33, Washbourne, Logan wrote: 

> I looked at the spectrums of both sides and the RX side looks to be inundated 
> with a lot of noise. I'm not sure if its my environment or my USRPs, but I 
> really expected to see some resemblance of a signal. I am posting links to 
> screencaps of the TX and RX sides.
> 
> http://imgur.com/GBTHw8T- [2] TX
> http://imgur.com/DBy8gqs [3] - RX
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 1:31 PM, Marcus Müller  
> wrote:
> 
> Can you compare the TX spectrum with the RX spectrum? Maybe it'd worthwhile 
> to first look at at e.g. 500kHz of RX spectrum to see whether, due to 
> frequency offset, some of the wanted signal simply gets cut off; admittedly, 
> with 2S/sym that's not too likely...
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 19:16, Washbourne, Logan wrote: 
> I am using 250k! 
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> On Mon, Oct 26, 2015 at 1:05 PM, Marcus Müller  
> wrote:
> 
> Hello!
> what's the sampling rate you're using?
> 
> Best regards,
> Marcus 
> 
> On 26.10.2015 18:38, Washbourne, Logan wrote: 
> 
> Hello all,
> 
> I'm trying to take a step back from my previous postings and try a simple 
> approach to try and understand working with over the air communications with 
> the USRPs. Let me know if it would be better to post this in the USRPs-Users 
> list.
> 
> I'm trying to have a simple TX and simple RX side so I can eliminate and 
> unnecessary complications.
> 
> The TX side has the following flowgraph: Vector Source(preamble+data)->DPSK 
> Mod(DBPSK,2samples/symbol)-> Multiply Const(.707) -> UHD:USRP SINK(2.448GHz 
> center freq, 10dB default gain)
> 
> RX Side: UHD:USRP Source(2.448GHz center freq, 10dB gain default) -> DPSK 
> DEMOD(DBPSK, 2 samples/ symbol, rest default values) - > file sink
> 
> I'm checking the progress of the communication by looking at a constellation 
> plot that is connected directly to the USRP SOURCE block on the receiver 
> side. I'm getting a very elliptical shape, more spread out in the horizontal 
> direction but not by much. I'm also looking at the bits from the receiver 
> side in matlab and my preamble is not showing up.
> 
> These were the same problems I had when trying to use a correlated system for 
> OTA communications. I feel like I'm missing something really simple.
> 
> Does anyone know of a simple TX, RX grc setup that I can use to test my USRPs?
> 
> Again, I really appreciate the help you guys give.
> 
> Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

___
 Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

 

Links:
--
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[2] http://imgur.com/GBTHw8T-
[3] http://imgur.com/DBy8gqs
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] complex type clarification

[mleech]

 

Yeah, theyre 32-bit float I and Q, and for CPUs whose native FP format
is IEEE 754, that's what they'll be on disk 

On 2015-10-02 12:55, Jason Matusiak wrote: 

> I just wanted to make sure I have this right (because I always seem to
> confuse myself); the complex data type is 64bits, 4 bytes of I and 4
> bytes of Q, right?
> 
> Secondly, those 4B are of type signed floats from [-1,1], right? I
> assume that these are of the IEEE 754 type?
> 
> TIA!
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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] UDP Sink Size Limit - ERROR: send error:send_to: Message too long

[mleech]

 

If the sending machine sets DF in the IP header, then any interstitial
machine that must fragment will drop the packet as well. 

Best to stick to MTU-sized payloads with UDP, since IP fragmentation is
handled poorly in many cases--either due to policy, or bad
implementations. 

On 2015-09-25 15:17, Andy Walls wrote: 

>> From: David Halls Subject: [Discuss-gnuradio] UDP Sink Size Limit - ERROR: 
>> send
> 
> error:send_to: Message too long
> 
>> Date: Fri, 25 Sep 2015 09:05:56 +
> 
>> Dear All, When I increase my packet length in a transmission flow graph to 
>> over 16,000 bits, I get the following error "ERROR: send error:send_to: 
>> Message too long​"
> 
> This looks like the underlying sendto() system call is returning
> EMSGSIZE. From man sendto:
> 
> EMSGSIZE
> The socket type requires that message be sent atomically, and
> the size of the message to be sent made this impossible.
> 
>> this is from the UDP block which I am using in order to send the transmitted 
>> bits to the destination in order to perform BER. I am sending the packets in 
>> bursts, one packet every two seconds.
> 
>> I currently have the Payload size set to 147.2k and Send Null Pkt as EOF set 
>> to true.
> 
>> Is this some fundamental limit, or can I overcome the issue?
> 
> 16,000 bits is 2000 bytes. The default MTU is usually 1500 bytes (for
> IP header, UDP header, and payload together). Try modifying the MTU on
> your machine's network interface to something larger, say 4000.
> 
> The MTU of the receiving machine or other network hardware might still
> be only 1500, so the the UDP packet could get IP fragmented. I'm not
> sure how well UDP works when fragmented.
> 
> -Andy
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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] RFNoc and data rates

[mleech]

 

Since you'd be decimating on the FPGA, your latency would be dominated
by the rate at which you send FFTs to the host. In the scenario
descibed, that would be about 0.01second, plus the inherent group delay
of the filters in the radio, which if you're running at full ADC
bandwidth won't be much. 

Define "instantaneous". Are you switching between "sky" and "reference",
and want to be sure that you have no cross-contamination between the two
virtual "channels"? You'll always have *some*. When I've done similar
things, I always discard some samples during the switching interval,
because both analog and digital bits and pieces make samples delivered
during that time ambiguous. 

On 2015-09-24 03:48, Simon Olvhammar wrote: 

> Thanks!
> One concern that I have however is how the iir filter will affect delays in 
> the flow graph. In the current (non RFNoC) application; when I switch the 
> input RF to another source I would like to to see an almost instantaneous 
> change in the samples of the file sink. Which I pretty much do right now with 
> all averaging done in python. Could the iir filter affect this aspect? What 
> delay time could I expect from the x310:s A/D converter down to file sink?
> 
> Simon
> 
> On 09/24/2015 02:14 AM, Marcus D. Leech wrote:
> On 09/23/2015 06:13 PM, Simon Olvhammar wrote: What would be a good choice 
> for N in this case? However, this seems very promising and I thank you for 
> your help! Cheers Simon Whatever rate you're comfortable receiving integrated 
> FFTs at. You'd adjust the 'alpha' value for the IIR filter and N 
> appropriately. Let's say you're running the FFT input at full 
> bandwidth--200Msps, and you have an FFT size of 2048. That's 97.7e3 
> FFTs/second being produced in the FFT machinery in RFNoC, including the 
> complex-to-mag part. Run that through a single-pole-IIR filter with an alpha 
> value of, let's say, 0.01 (or the integer/fixed-point equivalent). Then set 
> your 'N' in keep-one-in-N to be about 100. You'll get roughly 97.7e1 
> FFTs/second into your host instead of 97.7e3 FFTs/second. At those low rates, 
> even a purely-Python-based secondary long-term integrator should be able to 
> keep up just fine. On 09/23/2015 11:40 PM, Marcus D. Leech wrote: On 
> 09/23/2015 04:19 PM, Simon Olvhammar wrote: Hi Marcus,
No, we also have some spectrometers for atmospheric measurements. Regarding the 
keep 1 in N. It occurs to me then that by using this I would loose (N-1)/N 
percent of the FFT data for a given amount of observation time? Or am I missing 
something? Simon Since you're integrating prior to decimation here, there 
should be no loss of information. Den 2015-09-23 kl. 21:40, skrev Marcus D. 
Leech: On 09/23/2015 03:06 PM, Marcus D. Leech wrote: On 09/23/2015 02:49 PM, 
Simon Olvhammar wrote: Hello, Thank you for your answers. Yes we do alot of 
averaging to expose the signal, in some applications we even average over 
several months.
 Are these astronomical spectral features? They usually aren't that
wide, even with doppler spreading.
___ Discuss-gnuradio mailing
list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
___ Discuss-gnuradio mailing
list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
___ Discuss-gnuradio mailing
list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
___ Discuss-gnuradio mailing
list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
___ Discuss-gnuradio mailing
list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1] 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

 

Links:
--
[1] 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] Chips from Nooelec R820T2

[mleech]

 

There will be an RTL2832U, made by RealTek. Its job is to digitize the
output from the tuner, and down-sample, and put it on the USB bus. 

There's also an R820T2, which is the downconverter/tuner that converts
to a real IF around (AFIR) 3.57MHz. 

There'll also be a voltage regulator or two, and probably a EEPROM chip.


On 2015-09-22 14:06, Pedro Gabriel Adami wrote: 

> Dear all,
> 
> I have a Nooelec R820T2 and inside of it there are two chips: 2838 and 2832U. 
> I'd like to know what is the function of each one. I've looking for this, but 
> I'd like to hear from you in general terms. Thank you.
> 
> -- 
> 
> Cheers, Pedro Gabriel Adami 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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] GNU Radio installation script

[mleech]

 

Hrrrm, I was pretty-sure that I'd made that update some time ago. 

I'll have to check my master copy when I get home. 

On 2015-09-22 11:08, Peter Mathys wrote: 

> As noted elsewhere the failure to find libzmq1-dev is expected (what is 
> needed is libzmq-dev) and does not affect the outcome of the installation. 
> However, the UHD installation most likely fails because of the switch from 
> the cheetah to the mako template engine which has not (yet?) made its way 
> into the build-gnuradio script. Install the mako template engine using
> 
> sudo apt-get install python-mako
> 
> Then run the build-gnuradio script again (perhaps with the -v option).
> 
> -Peter-
> 
> On 9/22/2015 6:25 AM, Mike Gilmer wrote:
> I've gotten further along but it still failed. Here's the output 
> +++ Failed to find package 'libzmq1-dev' 
> in known package repositories <-- I noted this in my previous post SOME 
> THINGS MAY NOT BUILD AS A RESULT Checking for package libzmq Checking for 
> package libzmq-dev Checking for package python-requests Done checking 
> packages Checking for library libusb ...Found library libusb Checking for 
> library libboost ...Found library libboost Checking for library libcppunit 
> ...Found library libcppunit Checking for library libfftw ...Found library 
> libfftw Checking for library libgsl ...Found library libgsl Done This script 
> will fetch Gnu Radio version 3.7/maint from the repositories, along with 
> compatible extras. Is this OK?y Fetching various packages (Gnu Radio, UHD, 
> gr-osmosdr, gr-iqbal, etc) via the Internet ===> THIS MAY TAKE QUITE SOME 
> TIME <= Fetching Gnu Radio via GIT...Done Fetching UHD via 
> GIT...Fetching rtl-sdr (rtl-sdr, gr-osmosdr,
gr-iqbal, hackrf, bladeRF and airspy) via GIT Done Starting function uhd_build 
at: Tue Sep 22 00:10:59 EDT 2015 Building UHD... => THIS WILL TAKE 
SOME TIME <= UHD build apparently failed Exiting UHD build 
++ Again, I appreciate the help! -Mike On 
Mon, Sep 21, 2015 at 11:48 PM, Mike Gilmer  wrote: I'm 
running 14.04 and yes I have Internet access (that was part of the 
aforementioned "drama") I ran the update/upgrade and reran the script and now 
things are "different" This seems like it may take a while. I'll report back 
when it's done. Hmm.. so far one error - it couldn't find libzmq1-dev; I don't 
know what that'll mean Thanks! Mike On Mon, Sep 21, 2015 at 11:27 PM, James 
Humphries  wrote: Hi Mike, Did you update your 
package manager? Usually helps when I get errors. sudo apt-get update && sudo 
apt-get upgrade Also, make sure build-essential is installed (Do this after 
update
and upgrade). sudo apt-get install build-essential -Trip On Mon, Sep 21, 2015 
at 11:13 PM, Mike Gilmer  wrote: All, I recently asked 
the list some questions about getting GNU Radio up and running on a Windows 
machine (using cygwin). It became obvious there would be a lot of hurdles, for 
which the community would not be able to offer much help. So... I have 
installed Ubuntu on a PC ( in a dual boot configuration with Win7 ) <-- this is 
its own drama LOL I tried to follow the "Installing GNU Radio step(s) outlined 
on https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR/23 [1] 
using the script via wget http://www.sbrac.org/files/build-gnuradio [2] && 
chmod a+x ./build-gnuradio && ./build-gnuradio and I get a bunch of errors : 
Checking for package libfontconfig1-dev Failed to find package 
'libfontconfig1-dev' in known package repositories SOME THINGS MAY NOT BUILD AS 
A RESULT Checking for package libxrender-dev Failed to find package 
'libxrender-dev' in
known package repositories SOME THINGS MAY NOT BUILD AS A RESULT However, the 
descruiption etc.. It appears that a major step is missing or broken. Can 
someone help me on this? Thanks! Mike 
___ Discuss-gnuradio mailing list 
Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]
 ___ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3] 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]

 

Links:
--
[1] https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR/23
[2] http://www.sbrac.org/files/build-gnuradio
[3] 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] GNU Radio installation script

[mleech]

 

Yes, although, that will get you a not-terribly-recent GR and UHD... 

On 2015-09-22 10:45, West, Nathan wrote: 

> On Mon, Sep 21, 2015 at 11:13 PM, Mike Gilmer  wrote:
> 
>> All,
>> I recently asked the list some questions about getting GNU Radio up
>> and running on a Windows machine (using cygwin). It became obvious
>> there would be a lot of hurdles, for which the community would not be
>> able to offer much help. So...
>> 
>> I have installed Ubuntu on a PC ( in a dual boot configuration with
>> Win7 ) <-- this is its own drama LOL
>> 
>> I tried to follow the "Installing GNU Radio step(s) outlined on
>> https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR/23 [1]
>> using the script via
>> wget http://www.sbrac.org/files/build-gnuradio [2] && chmod a+x
>> ./build-gnuradio && ./build-gnuradio
> 
> It's worth noting that you're looking at an old version of that page. In the 
> current version the #1 suggested way to install GNU Radio is through your 
> distribution's package manager. sudo apt-get install gnuradio will get you 
> running in a few minutes. 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]
 

Links:
--
[1] https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR/23
[2] http://www.sbrac.org/files/build-gnuradio
[3] 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] GNU Radio installation script

[mleech]

 

The failure in libzmq1 is expected--Ubuntu changed package names
mid-stream, so there's no way to tell which of two possible
package-names to use, so it tries for both. 

The UHD failure is unexpected, so running: 

build-gnuradio -v 

Will give more details about errors as it builds. 

On 2015-09-22 08:25, Mike Gilmer wrote: 

> I've gotten further along but it still failed. Here's the output
> 
> +++
> Failed to find package 'libzmq1-dev' in known package repositories
> <-- I noted this in my previous post
> SOME THINGS MAY NOT BUILD AS A RESULT
> Checking for package libzmq
> Checking for package libzmq-dev
> Checking for package python-requests
> Done checking packages
> Checking for library libusb ...Found library libusb
> Checking for library libboost ...Found library libboost
> Checking for library libcppunit ...Found library libcppunit
> Checking for library libfftw ...Found library libfftw
> Checking for library libgsl ...Found library libgsl
> Done
> This script will fetch Gnu Radio version 3.7/maint from the
> repositories, along with compatible
> extras.
> Is this OK?y
> Fetching various packages (Gnu Radio, UHD, gr-osmosdr, gr-iqbal, etc)
> via the Internet
> ===> THIS MAY TAKE QUITE SOME TIME <=
> Fetching Gnu Radio via GIT...Done
> Fetching UHD via GIT...Fetching rtl-sdr (rtl-sdr, gr-osmosdr,
> gr-iqbal, hackrf, bladeRF and airspy) via GIT
> Done
> Starting function uhd_build at: Tue Sep 22 00:10:59 EDT 2015
> Building UHD...
> => THIS WILL TAKE SOME TIME <=
> 
> UHD build apparently failed
> Exiting UHD build
> ++
> 
> Again, I appreciate the help!
> 
> -Mike
> 
> On Mon, Sep 21, 2015 at 11:48 PM, Mike Gilmer  wrote:
> I'm running 14.04 and yes I have Internet access (that was part of the 
> aforementioned "drama") I ran the update/upgrade and reran the script and now 
> things are "different" This seems like it may take a while. I'll report back 
> when it's done. Hmm.. so far one error - it couldn't find libzmq1-dev; I 
> don't know what that'll mean Thanks! Mike On Mon, Sep 21, 2015 at 11:27 PM, 
> James Humphries  wrote: Hi Mike, Did you update 
> your package manager? Usually helps when I get errors. sudo apt-get update && 
> sudo apt-get upgrade Also, make sure build-essential is installed (Do this 
> after update and upgrade). sudo apt-get install build-essential -Trip On Mon, 
> Sep 21, 2015 at 11:13 PM, Mike Gilmer  wrote: All, I 
> recently asked the list some questions about getting GNU Radio up and running 
> on a Windows machine (using cygwin). It became obvious there would be a lot 
> of hurdles, for which the community would not be able to offer much help. 
> So... I
have installed Ubuntu on a PC ( in a dual boot configuration with Win7 ) <-- 
this is its own drama LOL I tried to follow the "Installing GNU Radio step(s) 
outlined on https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR/23 
[1] using the script via wget http://www.sbrac.org/files/build-gnuradio [2] && 
chmod a+x ./build-gnuradio && ./build-gnuradio and I get a bunch of errors : 
Checking for package libfontconfig1-dev Failed to find package 
'libfontconfig1-dev' in known package repositories SOME THINGS MAY NOT BUILD AS 
A RESULT Checking for package libxrender-dev Failed to find package 
'libxrender-dev' in known package repositories SOME THINGS MAY NOT BUILD AS A 
RESULT However, the descruiption etc.. It appears that a major step is missing 
or broken. Can someone help me on this? Thanks! Mike 
___ Discuss-gnuradio mailing list 
Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]

 

Links:
--
[1] https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR/23
[2] http://www.sbrac.org/files/build-gnuradio
[3] 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] 2Rx 1Tx overflow error

[mleech]

 

I would load it at the time the block is instantiated, in its "make"
method, and load it into instance-specific data. 

On 2015-09-22 06:27, Chad R wrote: 

> Good day Marcus
> 
> I am using the most recent version of UHD. The problem I was encountering was 
> due to the USB buffer not clearing before the next data being loaded. This 
> was solved by adding a pause after running the GNURadio program. 
> 
> This however meant I could not run my program in "real time" so I have been 
> looking at implementing it in the GNURadio way, I have some questions that I 
> ask you or anyone in the mailing list could help with.
> 
> First what I am trying to implement is a Compressive Sensing(CS) algorithim. 
> The block I am trying to create will take in a vector of length N, multiply 
> it my a MxN matrix and output a vector of length M where M << N.
> 
> Now for the questions.
> 
> 1) Am i right in saying that with the different block types, the N and M 
> refers to ports and not data type sizes. So in my case, one input vector and 
> one output vector, a synchronous block will be fine? 2) The MxN matrix I'm 
> using will be loaded from a file. I however only want to load it once instead 
> of every time the CS block receives data. This leads me to think that I 
> shouldn't load the matrix in the block code? However where could I load it 
> that it will be globally accessible by the block code?
> 
> Again thank you in advance for your help 
> 
> On Mon, Sep 14, 2015 at 4:00 PM, Marcus D. Leech  wrote:
> 
> Again, could you confirm which UHD version you're using, did you upgrade to 
> the latest?
> 
> Also, you're probably better-off doing things "in the Gnu Radio way", rather 
> than loading into a vector and doing DSPish things
> "out of band".
> 
> You might want to learn how to write Python blocks, since 64ksps is not a 
> very taxing rate, Python blocks should be fine.
> 
> https://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules#Tutorial-3-Writing-a-signal-processing-block-in-Python
>  [1] 
> 
> On 09/14/2015 09:28 AM, Chad R wrote: 
> 
> My complete code is:
> 
> class Tx1_Rx2(gr.top_block):
> def __init__(self, nsamps):
> gr.top_block.__init__(self, "Tx1_Rx2")
> ##
> # Variables
> ##
> self.samp_rate = samp_rate = 64e3
> 
> ##
> # Blocks
> ##
> self.source = uhd.usrp_source(
> ",".join(("", "")),
> uhd.stream_args(
> cpu_format="fc32",
> channels=range(2),
> ),
> )
> self.source.set_subdev_spec("A:A A:B", 0)
> self.source.set_time_now(uhd.time_spec(time.time()), uhd.ALL_MBOARDS)
> self.source.set_samp_rate(samp_rate)
> self.source.set_center_freq(100e6, 0)
> self.source.set_gain(0, 0)
> self.source.set_antenna("RX2", 0)
> self.source.set_bandwidth(samp_rate, 0)
> self.source.set_center_freq(100e6, 1)
> self.source.set_gain(0, 1)
> self.source.set_antenna("RX2", 1)
> self.source.set_bandwidth(samp_rate, 1)
> self.sink = uhd.usrp_sink(
> ",".join(("", "")),
> uhd.stream_args(
> cpu_format="fc32",
> channels=range(2),
> ),
> )
> self.sink.set_subdev_spec("A:A A:B", 0)
> self.sink.set_samp_rate(samp_rate)
> self.sink.set_center_freq(100e6, 0)
> self.sink.set_gain(0, 0)
> self.sink.set_antenna("TX/RX", 0)
> self.sink.set_bandwidth(samp_rate, 0)
> self.sink.set_center_freq(100e6, 1)
> self.sink.set_gain(0, 1)
> self.sink.set_antenna("TX/RX", 1)
> self.sink.set_bandwidth(samp_rate, 1)
> self.vector = blocks.vector_sink_c(1)
> self.vector2 = blocks.vector_sink_c(1)
> self.header = blocks.head(gr.sizeof_gr_complex*1, int(nsamps))
> self.header2 = blocks.head(gr.sizeof_gr_complex*1, int(nsamps))
> self.signal = analog.sig_source_c(samp_rate, analog.GR_COS_WAVE, 1, 1, 0)
> self.const_signal = analog.sig_source_c(0, analog.GR_CONST_WAVE, 0, 0, 0)
> 
> ##
> # Connections
> ##
> self.connect((self.const_signal, 0), (self.sink, 1)) 
> self.connect((self.signal, 0), (self.sink, 0)) 
> self.connect((self.header2, 0), (self.vector2, 0)) 
> self.connect((self.header, 0), (self.vector, 0)) 
> self.connect((self.source, 0), (self.header2, 0)) 
> self.connect((self.source, 1), (self.header, 0)) 
> 
> def get_samp_rate(self):
> return self.samp_rate
> 
> def set_samp_rate(self, samp_rate):
> self.samp_rate = samp_rate
> self.signal.set_sampling_freq(self.samp_rate)
> self.sink.set_samp_rate(self.samp_rate)
> self.sink.set_bandwidth(self.samp_rate, 0)
> self.sink.set_bandwidth(self.samp_rate, 1)
> self.source.set_samp_rate(self.samp_rate)
> self.source.set_bandwidth(self.samp_rate, 0)
> self.source.set_bandwidth(self.samp_rate, 1)
> 
> def receive_data(self):
> data = np.array(self.vector.data())
> return data
> 
> def receive_data2(self):
> data = np.array(self.vector2.data())
> return data
> 
> if __name__ == '__main__':
> N = 1

Re: [Discuss-gnuradio] Examples of GNURadio

[mleech]

 

Try: 

uhd_fft 

On 2015-09-18 09:03, Chiara wrote: 

> Hi all,
> 
> I've installed GNURadio 3.7.8 on Ubuntu 14.04 LTS and I've got two URSP B210.
> 
> I think I've got some problems in transmission because when I run the uhd 
> example and try to capture the signal sent, I don't see anything.
> I know that there could be some examples of GNURadio like usrp_siggen.py and 
> usrp_fft.py but I don't find them anywhere..Could someone help me? Did I 
> probably do a wrong installation?
> 
> Thank you very much,
> Chiara
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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] PLL not locked and GCD problem

[mleech]

 

The "No E4000 tuner found" comes from rtl_test -t which is useful ONLY
for E4000 tuners, and you have a R820T tuner. 

On 2015-09-18 08:38, Pedro Gabriel Adami wrote: 

> Hello,
> 
> I'm tuning a frequency inside of the range of the device, that is, 107.9MHz 
> and 95.3MHz. When I blacklist the 2838 to discover only the 2832U, I see the 
> same message: "PLL not locked" and "No E4000 tuner found, aborting".
> 
> Is it a problem? What could be the solution?
> 
> Thanks a lot.
> 
> Cheers, 
> 
> 2015-09-17 15:50 GMT-03:00 :
> 
> The PLL not locked error is just because you've (or someone) has asked for a 
> frequency tuning on the device that isn't possible, so the hardware is saying 
> "can't do that". 
> 
> The GCD messsage is a warning. Given the message you should just have used an 
> interpolation of 1 and a decimation of 2. 
> 
> Others can comment on the overall-sanity of your flowgraph. 
> 
> On 2015-09-17 14:43, Pedro Gabriel Adami wrote: 
> 
> Hello,
> 
> I'm trying to run the flowgraph available on the website of John Petrich 
> (http://www.w7fu.com/index_files/Page774.htm [2]). I'm using the RTL-SDR 
> 2832U and I have already made the configurations to blacklist and fix the 
> bugs of Ubuntu 14.04 LTS.
> 
> But when I run the flowgraphs, these messages appear and I can't hear the FM 
> station I choose.
> 
> Generating: "/home/aluno/Downloads/RTL_WBFM_RX_QT_GUI_08262015.py"
> 
> Executing: "/home/aluno/Downloads/RTL_WBFM_RX_QT_GUI_08262015.py"
> 
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-27-g28fa5a12
> 
> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.8
> built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy 
> Using device #0 Realtek RTL2838UHIDIR SN: 0001
> Found Rafael Micro R820T tuner
> [R82XX] PLL not locked!
> [R82XX] PLL not locked!
> INFO: Rational resampler has user-provided taps but interpolation (512) and 
> decimation (1024) have a GCD of 512, which increases the complexity of the 
> filterbank. Consider reducing these values by the GCD.
> Using Volk machine: sse4_1_64_orc
> INFO: Audio sink arch: alsa
> aU
> 
> I'm not sure but I think that this "PLL not locked" and the INFO about 
> Rational Resampler might be the problem. Can anyone help me, please?
> 
> PS: I'm attaching the two flowgraphs from his website.
> 
> Thanks a lot.
> 
> -- 
> Cheers, 
> 
> Pedro Gabriel Adami 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]

-- 

Atenciosamente, Pedro Gabriel Adami 

Links:
--
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[2] http://www.w7fu.com/index_files/Page774.htm
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Wx issues with StaticText under F22

[mleech]

 

One of my "customers" (for multimode and simple_ra) has reported that at
least on his system, the StaticText fields that are updated (at a coupla
Hz, max) expand every time they're updated, eventually leading to an OOM
issue with OpenGL. 

The Wx versions are here: 

python-matplotlib-wx-1.4.3-3. 
fc22.x86_64
wxGTK3-3.0.2-9.fc22.x86_64
wxPython-3.0.2.0-5.fc22.x86_64
wxGTK3-gl-3.0.2-9.fc22.x86_64
wxBase-2.8.12-16.fc22.x86_64
wxBase3-3.0.2-9.fc22.x86_64
wxGTK-2.8.12-16.fc22.x86_64
wxGTK3-media-3.0.2-9.fc22.x86_64 

On F22. I'm running F20, and I don't see this issue. Anyone else? 

 ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PLL not locked and GCD problem

[mleech]

 

The PLL not locked error is just because you've (or someone) has asked
for a frequency tuning on the device that isn't possible, so the
hardware is saying "can't do that". 

The GCD messsage is a warning. Given the message you should just have
used an interpolation of 1 and a decimation of 2. 

Others can comment on the overall-sanity of your flowgraph. 

On 2015-09-17 14:43, Pedro Gabriel Adami wrote: 

> Hello,
> 
> I'm trying to run the flowgraph available on the website of John Petrich 
> (http://www.w7fu.com/index_files/Page774.htm [2]). I'm using the RTL-SDR 
> 2832U and I have already made the configurations to blacklist and fix the 
> bugs of Ubuntu 14.04 LTS.
> 
> But when I run the flowgraphs, these messages appear and I can't hear the FM 
> station I choose.
> 
> Generating: "/home/aluno/Downloads/RTL_WBFM_RX_QT_GUI_08262015.py"
> 
> Executing: "/home/aluno/Downloads/RTL_WBFM_RX_QT_GUI_08262015.py"
> 
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-27-g28fa5a12
> 
> gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.8
> built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy 
> Using device #0 Realtek RTL2838UHIDIR SN: 0001
> Found Rafael Micro R820T tuner
> [R82XX] PLL not locked!
> [R82XX] PLL not locked!
> INFO: Rational resampler has user-provided taps but interpolation (512) and 
> decimation (1024) have a GCD of 512, which increases the complexity of the 
> filterbank. Consider reducing these values by the GCD.
> Using Volk machine: sse4_1_64_orc
> INFO: Audio sink arch: alsa
> aU
> 
> I'm not sure but I think that this "PLL not locked" and the INFO about 
> Rational Resampler might be the problem. Can anyone help me, please?
> 
> PS: I'm attaching the two flowgraphs from his website.
> 
> Thanks a lot.
> 
> -- 
> Cheers, 
> 
> Pedro Gabriel Adami 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[2] http://www.w7fu.com/index_files/Page774.htm
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] VOLK: fast way to log10()?

[mleech]

 

Sure, but if the flow-graph basically is decimated 10:1 by the time it
reaches the log10, improvements in log10 are going to have very little
impact. It is, I would assert, boldly and perhaps brashly,
 that log10 operations almost never need to be done at "line rate",
since they are an artifice imposed by wanting to use standard
engineering units. There's very little need to do internal DSP math in
 standard engineering units... 

On 2015-09-16 12:39, Martin Braun wrote: 

> On 15.09.2015 20:35, Marcus D. Leech wrote:
> 
>> Ordinarily, one does a log10 to convert into engineering units at the back 
>> of, for example, a power-measurement chain. There's usually no reason to do 
>> that in the middle of a flow-graph, where things can stay in linear units.
> 
> That's true, but it's also useful to accelerate operations at the end of
> a flowgraph :)
> 
> The rest of the thread is already discussing the technical details, but
> if there's a good way to implement log10 kernels, I'm sure they'd come
> in handy.
> 
> M
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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 Structure

[mleech]

 

Since most SDRs out there have fully reconfigurable-by-the-end-user FPGA
and firmware images, I don't think the notion of "compromise"
 has much meaning in this context, further because access to the devices
is freely available to ordinary user-level processes, they can ask the
radio to do whatever they want. 

Most SDRs that we discuss here are used in R&D, and only a very few in
"services" where type-acceptance is required. Presumably, in the
fullness of time, getting type acceptance would require the integrator
to demonstrate some kind of "protection" for the radio. But SDRs as we
know them here are just "dumb" components. It's a bit like asking a
mixer or RF amplifier or synthesizer to "tamper-proof itself". 

My personal opinion is that asking general-purpose hardware to enforce
some arbitrary notion of regulatory compliance in this area is silly,
unproductive, and ultimately doomed to failure, quite apart from the
wide-reaching implications for the industry in general. 

My "day job" is at a company where we "tamper proof" software on
general-purpose computers at the behest of the Media Industry. It
amounts to building perpetual-motion machines--it cannot be done in the
strictest theoretical sense. In a practical sense, you can keep the 
casually-curious out of your "stack", but you cannot protect against the
determined--they have infinite access to the hardware and software, and
will eventually find a way around any "safeguards" you put in place. So,
in the first instance, the "lockdown" software is utterly unnecessary,
and in the second instance, it is woefully inadequate... 

On 2015-09-09 14:51, Logan Wu wrote: 

> Hello,
> 
> Recently I read a paper on cognitive radio security (Secure
> reconfiguration of software-defined radio). It highlights that the
> operating system of cognitive radio node may be compromised as the
> malware can exploit software vulnerabilities. I am wondering if the FPGA
> and firmware are part of the OS? And can they be compromised during
> runtime by malware?
> 
> Thank you,
> Logan
 ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Using the UHD API for Python Programming

[mleech]

 

time_spec_t() is a helper function in class "uhd", it is not a method in
a uhd.usrp_source/sink. 

self.cmd_time = uhd.time_spec_t(0.1) 

Would be the correct idiom. 

On 2015-08-31 15:31, Tibisay Sanchez wrote: 

> my line is
> 
> self.cmd_time = self.uhd_usrp_source_0.uhd.time_spec_t(.1)
> 
> but it shows an error when it calls uhd.time_spec_t(.1)
> 
> it says usrp_source_sptr' object has no attribute 'uhd_time_spect_t'.
> 
> I need both LO are align to synch the phase
 ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Follow up: Failure to build GNU Radio on various Ubuntu builds

[mleech]

 

I have had similar problems with cheap USB cables that work for
low-speed devices, but utterly fail for higher-speed transfers. 

You might as well update to at least Ubuntu 14.04 or even 15.04, Gnu
Radio (via build-gnuradio) is known to work in that environment. 

On 2015-08-18 10:42, Mark wrote: 

> I managed to resolve a problem with the install. 
> 
> Commands, FIND_USRP_DEVICES and UHD_USRP_PROBE failed to get my B100 to 
> respond with the model and daughter board and FPGA information. Yet at other 
> times it would work, albeit very briefly. 
> 
> Whilst trying to keep this follow up mail brief, the problem was caused by 
> the USB lead I was using. Although a new lead and just 2m in length, it must 
> be unable to handle the bus communications between the USRP and my PC. 
> However, for the past few months it's been fine when using my B100 on Windows 
> 8.1 when casually running SDR# or HDSDR. 
> 
> Whilst working in Ubuntu, when I ran the LSUSB command, the USRP was listed. 
> This was puzzling, for me anyway, as beyond that the USRP would not function 
> or rather I could not get it to intermittently communicate with my PC, as 
> mentioned above. 
> 
> Whilst switching back to my Windows partition, I checked the USB lead with 
> known working applications in Windows 10; HDSDR and SDR#, since by this time 
> I felt my USRP B100 may have been faulty. My USRP wouldn't work in those 
> applications either, though it had previously worked perfectly well on the 
> same now suspect USB lead. The commands, FIND_USRP_DEVICES and UHD_USRP_PROBE 
> on a Windows platform (from Command line) wouldn't work with the suspect 
> faulty cable attached (the command, UHD_USRP_PROBE,being particularly 
> problematic in returning runtime errors). 
> 
> Again, without going into more tests and irregular driver responses in 
> Windows 10, with the UHD driver throwing up errors, I changed the USB cable 
> with another cable in desperation and the whole system came alive and has 
> remained so over the past day or so. 
> 
> I swapped the cable with a 1.5m filtered USB cable I've owned for years and 
> this confirmed the problem. I swapped it back again, to the suspect cable, 
> and the irregular functions reoccurred. However, the suspect USB lead works 
> fine with any other equipment I have such as printer and an USB expansion 
> port. I wasn't using an expansion USB device when these errors were occurring 
> BTW, just the suspect one USB lead between the PC and the USRP B100. 
> 
> All it is left for me to do is now go back to my Ubuntu partition and try to 
> reinstall GNURadio again on a fresh install of Ubuntu (as I have done so many 
> times this past week trying to get it to work) and hopefully get some more 
> positive results. 
> 
> I will start with Ubuntu 12.04 LTS 64 bit as that was the last known Ubuntu 
> distro that worked two years ago when running many successful installs of 
> GNURadio on my other PC's and laptop. This includes successfully installing 
> GNURadio on Windows 7 at the time. However, in terms of Ubuntu, I will again 
> use Marcus's excellent build-gnuradio script, as I did two years ago and work 
> on from there. I'm hoping Marcus's script will fetch the required 
> dependencies and build to a successful outcome this time around again. 
> 
> Else, if you can advise on any other approach to installing GNURadio, on more 
> recent Ubuntu distro's, so that it will also reliably work with my B100 USRP, 
> I should be grateful again for your help. I really want to learn and work 
> with GNURadio so that I can better understand its function since with various 
> academic commitments I have had so little time over the past couple of years 
> and more since investing in the Ettus USRP concept back in 2012. 
> 
> Again, your patient help is very much appreciated. 
> 
> Mark
 ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RX/TX transceiver

[mleech]

 

There's enough leakage between the TX and RX paths (inevitable) that
your RX will see your TX side transmissions. 

On 2015-08-18 03:26, Marius Cachelin wrote: 

> Hi All,
> 
> I have some issues when using UHD sink and source blocks in same flow graph.
> 
> When I transmit data with UHD sink, I use tx_sob and tx_eob. I don't get any 
> underflow error. 
> 
> But, the problem is that I can see all data sent by the TX path, in the RX 
> path. 
> 
> I don't understand how this can be possible because when I use tx_sob and 
> tx_eob, I can't be in RX and TX mode in same time.
> 
> I use a N210 USRP with a WBX daugtherboard.
> 
> Thanks.
> 
> Marius 
> 
> -- 
> 
> CACHELIN MARIUS
> _Ingénieur Systèmes, Réseaux et Télécommunications_
> marius.cache...@gmail.com 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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] UHD build apparently failed - build-gnuradio script

[mleech]

 

Given that you have an instance in /usr/lib/uhd/utils, that means you
have an install from your distros package manager, and that needs to
 be removed before you do a source-based installed. 

Also, the usual location from a source install is:
/usr/local/lib/uhd/utils/uhd_images_downloader.py 

It would be useful to see the log output from when the UHD build section
was doing a "make install", to see where it put
uhd_images_downloader.py, because
/usr/local/share/uhd_images_downloader.py is not the usual location. 

On 2015-08-07 11:21, Yoda Master wrote: 

> Hello Marcus,
> first sorry, i miss version, it`s 8.1, but i think that don`t change
> anything.
> With verbose i catch where he failed, but stuck on this:
> 
> Done building/installing UHD
> Done function uhd_build at: Fri Aug 7 10:12:54 CDT 2015
> Starting function firmware at: Fri Aug 7 10:12:54 CDT 2015
> Could not find images downloader: uhd_images_downloader.py in
> any of /usr/local/share /usr/local/lib /usr/local/lib64
> 
> i have it:
> $ locate uhd_images_downloader.py
> /home/y0d4/Downloads/uhd/host/utils/uhd_images_downloader.py.in
> /usr/lib/uhd/utils/uhd_images_downloader.py
> /usr/local/share/uhd_images_downloader.py
> 
> but script don`t see it...
> in script i see:
> dirlist="/usr/local/share /usr/local/lib /usr/local/lib64"
> prog=uhd_images_downloader.py
> 
> can i force him path of this python script?
> 
> thank you.
 ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Filterbank

[mleech]

 

This is a filterbank (analog) of your own design? 

You'll want to use the GPIO interface: 

http://files.ettus.com/manual/page_gpio_api.html 

The B2xx GPIO API is the same as X3xx, and the example code: 

gpio.cpp in the source tree 

Can be modified to use the B2xx GPIO facilities. 

Now, I'm not certain how one accesses that from Gnu Radio, since not all
of the UHD API is fully exposed in gr-uhd. Perhaps Martin has a comment
on this. 

On 2015-08-07 01:09, Jakub Jebbjeb wrote: 

> How to switch receiving Filterbank from Gnuradio in USRP B200. I plan to add 
> this Filterbank and switch it using onboard pin connector.
> 
> Jakub
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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 B210 GPIO

[mleech]

 

The B2xx GPIO J504 GPIO has the same API as X3xx. 

On 2015-08-05 13:26, Samith Abeywickrama wrote: 

> Hi, I want to control an antenna multiplxer via J504 gpio port. Actually I 
> want to have logic 1 and logic 0 in order to switch the multiplxer. But it is 
> difficult to find gpio example for B210. I have new version of b210 (green 
> board) and 3.8.005 uhd version. I m very much thankful to if you can help me 
> with gpio example. Ettus research says that B210 is supported for gpio in 
> j504 port but in UHD there is only one example for x300. 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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] About physcially acceptable, applicable signal input range for GNU Radio.

[mleech]

 

Jeon: 

Gnu Radio, per se, knows nothing of voltage. It just sees digital
samples as delivered by the hardware. What those samples mean in terms
of voltage amplitude as delivered to the antenna port is completely
opaque to Gnu Radio. 

The LFRX will easily tolerate an input signal with a voltage swing up to
+/- 1V. You would have to see what amplitude, in terms of
floating-point, is produced in your flow-graph. 

On 2015-07-30 01:37, Jeon wrote: 

> I am building a communication system which uses light. For the system, I've 
> buiult a custom analog circuit and connected it to LFRX with 
> SMA-BNC-Alligator clip.
> 
> A simple dry run gives the following: 
> 
> As you can see, data is transmitted with on off keying.
> (Please ignore some ripples and fluctuation, it's due to 60 Hz fluorscent 
> light interference. I'll fix it later.)
> 
> I wonder that such input range (+- 50 mV) is quite acceptable for GNU Radio 
> to manipulate.
> 
> Since it's my first time to physically implement a communication system, I 
> only have mathematical and theoretical knowledge, but have little experience 
> and sense about dBm, rx sensitivity and so.
> 
> But as I can see the waveform not so bad, I think I can manipulate it by 
> equalizing or something...
> 
> PS: In addition, that 60 Hz interference, would it be better if I filter out 
> that at the analog circuit with high pass filter? Or is it just ok to use 
> high pass filter block in GNU Radio. I think the former is better to reduce 
> the computational cost of GNU Radio. And it is more proper to filter out 
> before it passes through the ADC... 
> 
> Regards, 
> Jeon. 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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] multiple sources synchronization ?

[mleech]

 

The "use the signal itself" method is something that I've used in the
past for Dicke-switched type systems. The idea was originally described
by Ken Tapping of the DRAO observatory. 

The gr-ra_blocks OOT module that I designed includes an "Oblivious
Slicer" block that will produce a difference value based on a block of
samples, using "oblivious slicing". 

https://github.com/patchvonbraun/gr-ra_blocks 

The technique works well for well-differentiated signals (large
difference between reference and "sky"), but not otherwise. 

On 2015-07-22 04:01, Marcus Müller wrote: 

> Hi Jean-Michel!
> 
> There's nothing in your system that would make both RTL dongles and the 
> soundcard start sampling at the same time, so naturally there's a large time 
> offset between these. You will need to time align these signals first, before 
> you can use the sound card signal to determine in which state (reference or 
> unknown signal) your switch is; this is at least as hard as the problem of 
> aligning the RTL dongles themselves.
> To be honest, I'd rather write an estimator that tells me, only from the 
> signal, whether each RTL dongle is observing the reference or the signal.
> 
> How do you frequency-synchronize both dongles? Have you modified them to use 
> a common oscillator, or do you also plan to do that based on the observation 
> of the 50MHz tone?
> 
> Best regards,
> Marcus
> 
> On 22.07.2015 09:51, jean-michel.fri...@femto-st.fr wrote:
> 
>> Possibly a stupid question, but might help me better understand how the 
>> gnuradio scheduler works: my objective is to make a low cost 
>> phase-referenced radiofrequency interferometer using two DVB-T dongles. 
>> Since I have observed that the PLL inside each dongle induces slow phase 
>> drift, I want to use an external RF switch to monitor a known (50 MHz) 
>> reference oscillator feeding both dongles, and then monitor the unknown 
>> signal. Current switching rate is about 50 Hz triggered by an external 
>> generator (which also synchronizes other events of the experiment, not 
>> relevant to this post). My idea for synchronizing the post-processing of 
>> phase extraction was to record on the one hand the two DVB-T dongle data 
>> flow (this I know works), and on the other hand the sound card microphone 
>> connected to the switch trigger signal. This process is summarized in the 
>> grc flowchart at http://jmfriedt.sequanux.org/damien_grc.png [1] However, 
>> the sound card output shows a result completely out of sync with
the phase measurements. I understand that the sound card and DVB-T dongles do 
not share the same clock sources, but considering the huge decimation factor 
(48*32 kHz for the DVB-T, 48 kHz for the sound card, and a phase output 
recorded at about 0.5 to 5 kHz, not shown on this grc chart), I would have 
expected the trigger signal to be more or less synchronized with the DVB-T 
outputs, which is not at all the case. Is the gnuradio scheduler unable to 
interleave two data sources as different as a sound card and the USB data flow 
from the two DVB-T dongles ? Is there a way I might tune my flowchart to 
achieve the expected result ? Thanks, JM
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]
 

Links:
--
[1] http://jmfriedt.sequanux.org/damien_grc.png
[2] 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] isolate channels from wideband

[mleech]

 

I just use the built-in firdes stuff, rather than using an external
designer. 

On 2015-07-21 14:38, Marcus Müller wrote: 

> Hi Rich, hello Markus,
> 
> On 21.07.2015 19:51, Richard Bell wrote:
> 
>> GNU Radio has channelizers built-in, but I've not used them yet, so I don't 
>> know how far they take you into this kind of task.
> 
> the Polyphase channelizer is actually an implementation derived from that 
> school of thought, and it works amazingly well.
> In fact, in preparation of a presentation at a certain ham conference, I 
> tried using it to get 20 PMR/LPD channels out of a 1MS/s signal in real time, 
> and then just shuffle them around, before feeding them back into the inverse 
> synthesizer PFB.
> 
> It's pretty easy:
> Design a single low pass filter, as if you just wanted to filter out the 
> channel which is centered exactly at your RF center frequency, i.e. 0Hz, with 
> the full sampling rate [2], using the gr_filter_design tool. Play around with 
> the different window types[1], and bear in mind that the suppression outside 
> your desired passband needs to be high enough so that the sum of the energy 
> in all other channels don't hurt your channel too much, but don't overdo it 
> (60dB suppression should be enough).
> Now you get a long filter. Copy and paste the filter coefficients from 
> gr_filter_design to your PFB filter taps property.
> Set your channelizers number of channels according to your plans -- 40, if 
> you want to get all the 40 25kHz channels in 2MHz. You get a block with 40 
> outputs!
> Explaining things like channel mapping is best done by pointing you at the 
> official documentation: [3 [1]]
> 
> Greetings!
> Marcus
> 
> [1] Hamming is not always the best choice, I'd try that, Blackman-harris, and 
> Kaiser. I personally like harris in this case -- we want to get a full 
> channel, two adjacent channels are usually not occupied, and as soon as we 
> pass the stopband frequency, we're basically at -100dB.
> [2] assuming you want to use 2MS/s for your 2MHz wide band, 2MHz sampling 
> rate, and assuming 25kHz wide channels, 12.5kHz cut off frequency, 25kHz 
> start of stoppband. I get something like 440 taps.
> [3] 
> https://gnuradio.org/doc/doxygen/classgr_1_1filter_1_1pfb__channelizer__ccf.html
>  [1]
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]
 

Links:
--
[1]
https://gnuradio.org/doc/doxygen/classgr_1_1filter_1_1pfb__channelizer__ccf.html
[2] 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] isolate channels from wideband

[mleech]

 

I use the PFB channelizer for incoherent de-dispersion for pulsar
monitoring in radio astronomy. It's quite efficient for producing N
equally-spaced channels. 

For randomly-spaced, individual frequency-xlating FFT filters might be
better. 

On 2015-07-21 13:51, Richard Bell wrote: 

> I would add, this task you are trying to do is an advanced DSP topic. What 
> you're looking for is a channelizer and this is optimally implemented using a 
> polyphase filter bank. If you need a good reference on this, fred harris' 
> book on Multirate Signal Processing for Comms Systems is a good.
> 
> http://www.amazon.com/Multirate-Signal-Processing-Communication-Systems/dp/0131465112
>  [3]
> 
> GNU Radio has channelizers built-in, but I've not used them yet, so I don't 
> know how far they take you into this kind of task.
> 
> Rich 
> 
> On Tue, Jul 21, 2015 at 9:17 AM, Martin Braun  wrote:
> 
>> Or, given a regular channel spacing, you can use a polyphase filterbank
>> to split it into multiple narrow-band channels.
>> 
>> Cheers,
>> Martin
>> 
>> On 21.07.2015 09 [1]:10, Stephen Harrison wrote:
>>> A simple way in GNURadio is to use the frequency xlating fir filter to
>>> select individual channels.
>>> 
>>> On Tue, Jul 21, 2015 at 8:39 AM, Markus Heller >> > wrote:
>>> 
>>> Dear list,
>>> 
>>> I'd like to understand how to receive the 2m band as one wideband input
>>> (144-146 MHz) and afterwards split the sample stream into various
>>> channels (relay inputs, relay outputs for various relay frequencies).
>>> 
>>> I do know how to receive all of the 2m band, but I don't know how to do
>>> the splitting.
>>> 
>>> How would I do that?
>>> 
>>> Thanks in advance!
>>> 
>>> br
>>> markus
>>> dl8rds
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org 
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]
>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]
>>> 
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]
 

Links:
--
[1] tel:21.07.2015%2009
[2] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[3]
http://www.amazon.com/Multirate-Signal-Processing-Communication-Systems/dp/0131465112___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC seg fault

[mleech]

 

Well, no matter how "bad" a script is, it shouldn't be able to cause a
segfault 

On 2015-07-17 11:16, Jason Matusiak wrote: 

>> You could try renaming ~/.grc.
> 
> Interesting, I didn't realize that that file existed, thanks. Sadly, it
> of course didn't help me (my luck for today). But at least that shows
> that the problem isn't with a bad script causing a crash when trying to
> open...
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio