from:"John Shields"

Re: [Discuss-gnuradio] cant see any signals with limesdr on osmocom source

2017-12-13 Thread John Shields

I am not sure if I understand the problem. The first shot shows a 
spectrum centred around 2.4766GHz, but the second has an display of 
2.399 to 2.401 GHz - since these ranges (from my point of view) don't 
overlap, I am not sure how this relates to not being able to see a 
signal in one versus the other?


    Kind Regards,

 John


On 13/12/17 08:18, ogün levent wrote:

Hi there
I am trying to use limesdr with gnuradio on ubuntu 16.04 When I use 
osmocom_fft tool from the cli eveything seems ok but when i switch 
back to gnuradio and connected osmocom source and gui fft sink I cant 
see any wifi signal. What could be the problem ? You can check from 
the photos below.


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] Python synchronisation of 2xUSRP N200 with SBX in one UHD container.

2017-09-18 Thread John Shields


On 18/09/17 21:27, Marcus D. Leech wrote:

On 09/18/2017 05:21 PM, John Shields wrote:

On 18/09/17 20:52, Marcus D. Leech wrote:

On 09/18/2017 03:49 PM, John Shields wrote:

Thanks,
    I have attached the GRC. I should note that before I 
run, I wait until GPS is locked as evinced by the 
query_gpsdo_sensor utility:


    GPS Locked
    Trying to align the device time to GPS time...
    GPS and UHD Device time are aligned.
    last_pps: 1505763709 vs gps: 1505763709.
    Printing available NMEA strings:
    GPS_GPGGA: 
$GPGGA,194149.00,4331.1729,S,17234.2461,E,2,09,1.5,32.2,M,8.5,M,,*7B
    GPS_GPRMC: 
$GPRMC,194149.00,A,4331.1729,S,17234.2461,E,0.2,0.0,180917,,*20

    GPS Epoch time at last PPS: 1505763710.0 seconds
    UHD Device time last PPS:   1505763710.0 seconds
    UHD Device time right now:  1505763710.01897 seconds
    PC Clock time:  1505763710 seconds

    Done!

    Kind Regards,

   John

p.s. In Jan 2016, Nigel wrote that one of the steps needed to align 
included 'Use integer_N_ mode for PLL' when I tried to use the 
method you recommended, I got an error so ceased that line of 
investigation for the moment - is integer_N_mode tuning required?


Integer-N will help, but my understanding of the ADF4351 is that the 
re-synch feature, enabled through timed commands, will also work.


Also, the "uhd_fft" command has a --phase-relations option that will 
plot relative-phase between two input channels.  You might look at 
that.





Thanks Marcus,

    I can see that uhd_fft has a phase-relations 
option but, as far as I can tell from looking at the source, it 
doesn't synch the channels so, just to make sure I understand the 
point of your e-mail, uhd_fft uses a QT widget to display relative 
phase and I could investigate modifying my FG to use that method to 
display relative phase between the two channels?



Yes, or add features to uhd_fft to do full phase-synch dancing.

It already has --clock-source --time-source and --sync   options. You 
could modify it to add the timed-commands thing.






Thanks, sorry for being so thick!

  Slainte,

  John


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

Re: [Discuss-gnuradio] Python synchronisation of 2xUSRP N200 with SBX in one UHD container.

2017-09-18 Thread John Shields


On 18/09/17 20:52, Marcus D. Leech wrote:

On 09/18/2017 03:49 PM, John Shields wrote:

Thanks,
    I have attached the GRC. I should note that before I run, 
I wait until GPS is locked as evinced by the query_gpsdo_sensor utility:


    GPS Locked
    Trying to align the device time to GPS time...
    GPS and UHD Device time are aligned.
    last_pps: 1505763709 vs gps: 1505763709.
    Printing available NMEA strings:
    GPS_GPGGA: 
$GPGGA,194149.00,4331.1729,S,17234.2461,E,2,09,1.5,32.2,M,8.5,M,,*7B
    GPS_GPRMC: 
$GPRMC,194149.00,A,4331.1729,S,17234.2461,E,0.2,0.0,180917,,*20

    GPS Epoch time at last PPS: 1505763710.0 seconds
    UHD Device time last PPS:   1505763710.0 seconds
    UHD Device time right now:  1505763710.01897 seconds
    PC Clock time:  1505763710 seconds

    Done!

    Kind Regards,

   John

p.s. In Jan 2016, Nigel wrote that one of the steps needed to align 
included 'Use integer_N_ mode for PLL' when I tried to use the method 
you recommended, I got an error so ceased that line of investigation 
for the moment - is integer_N_mode tuning required?


Integer-N will help, but my understanding of the ADF4351 is that the 
re-synch feature, enabled through timed commands, will also work.


Also, the "uhd_fft" command has a --phase-relations option that will 
plot relative-phase between two input channels.  You might look at that.





Thanks Marcus,

    I can see that uhd_fft has a phase-relations 
option but, as far as I can tell from looking at the source, it doesn't 
synch the channels so, just to make sure I understand the point of your 
e-mail, uhd_fft uses a QT widget to display relative phase and I could 
investigate modifying my FG to use that method to display relative phase 
between the two channels?



                        Kind Regards,


  John




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

Re: [Discuss-gnuradio] Python synchronisation of 2xUSRP N200 with SBX in one UHD container.

2017-09-18 Thread John Shields


Thanks,
    I have attached the GRC. I should note that before I run, I 
wait until GPS is locked as evinced by the query_gpsdo_sensor utility:


            GPS Locked
            Trying to align the device time to GPS time...
            GPS and UHD Device time are aligned.
            last_pps: 1505763709 vs gps: 1505763709.
            Printing available NMEA strings:
            GPS_GPGGA: 
$GPGGA,194149.00,4331.1729,S,17234.2461,E,2,09,1.5,32.2,M,8.5,M,,*7B
            GPS_GPRMC: 
$GPRMC,194149.00,A,4331.1729,S,17234.2461,E,0.2,0.0,180917,,*20

            GPS Epoch time at last PPS: 1505763710.0 seconds
            UHD Device time last PPS:   1505763710.0 seconds
            UHD Device time right now:  1505763710.01897 seconds
            PC Clock time:  1505763710 seconds

            Done!

            Kind Regards,

   John

p.s. In Jan 2016, Nigel wrote that one of the steps needed to align 
included 'Use integer_N_ mode for PLL' when I tried to use the method 
you recommended, I got an error so ceased that line of investigation for 
the moment - is integer_N_mode tuning required?




On 18/09/17 16:27, Marcus D. Leech wrote:

On 09/18/2017 12:41 AM, John Shields wrote:

Thanks, as always, Marcus,
   Here is the relevant code 
I am executing:


    self.uhd_usrp_source_0.set_clock_source('gpsdo', 0)
    self.uhd_usrp_source_0.set_time_source('gpsdo', 0)
    self.uhd_usrp_source_0.set_clock_source('mimo', 1)
    self.uhd_usrp_source_0.set_time_source('mimo', 1)
    self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
    # now put in code to make sure that both usrps have seen at least 
1 pps - pulse

    # self.save_last_pps=self.uhd_usrp_source_0.get_last_pps(0)
    # as the USRPs have been running for hours will tackle the 'spin 
until get_last_pps changes' code later


    # inserted code to synch LO and, by way of the mechanism, align 
the CORDICs
self.tune_time=self.uhd_usrp_source_0.get_time_now(0)+uhd.time_spec_t(0.1) 
# tune in 100 msecs from 'now'

    self.uhd_usrp_source_0.set_command_time(self.tune_time)
    self.uhd_usrp_source_0.set_center_freq(freq, 0)
    self.uhd_usrp_source_0.set_center_freq(freq, 1)
    self.uhd_usrp_source_0.clear_command_time()

    self.uhd_usrp_source_0.set_gain(rf_gain+.45, 0)
    self.uhd_usrp_source_0.set_antenna('RX2', 0)

    self.uhd_usrp_source_0.set_gain(rf_gain, 1)
    self.uhd_usrp_source_0.set_antenna('RX2', 1)

    when I run the FG, I get variable results - I attach 2 
screenshots which show the averaged phase difference is 74-odd 
degrees for one run and the next run the result is 101-odd degrees. 
Clearly, I am doing something wrong but, for the life of me, I cannot 
figure it out. For completeness, I will later put this code, when it 
works into the set_freq function but I don't have this parameter 
changeable in the FG.


  Kind Regards,

  John

Mayhaps you could share the flow-graph from which this is derived? 
(Done in GRC I assume?)



self.uhd_usrp_source_0.set_clock_source('gpsdo', 0)
    self.uhd_usrp_source_0.set_time_source('gpsdo', 0)
    self.uhd_usrp_source_0.set_clock_source('mimo', 1)
    self.uhd_usrp_source_0.set_time_source('mimo', 1)
    self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
    # inserted code to align CORDICs ?


    # inserted code to synch LO
self.tune_time=self.uhd_usrp_source_0.get_time_now(0)+uhd.time_spec_t(0.1) 
# tune in 100 msecs from 'now'

self.uhd_usrp_source_0.set_command_time(self.tune_time)
    self.uhd_usrp_source_0.set_center_freq(freq, 0)
    self.uhd_usrp_source_0.set_center_freq(freq, 1)
    self.uhd_usrp_source_0.clear_command_time()


    self.uhd_usrp_source_0.set_gain(rf_gain, 0)
    self.uhd_usrp_source_0.set_antenna('RX2', 0)

    self.uhd_usrp_source_0.set_gain(rf_gain, 1)
    self.uhd_usrp_source_0.set_antenna('RX2', 1)


While there is a discussion on the web re: the tune_time which 
seems to suggest, I could just put in the, uhd.time_spec_t(0.1), 
there is a comment from Josh saying to make sure the time is in the 
future so that is why I added the time now.



In that same thread there were comments to the effect that 
stream_cmds have not been swig-ed as the control of streaming is 
part of the scheduler so:


questions:

    1) have I got the correct code to synch the LO i.e. by tuning 
both devices at the same exact time?
Yes.  That will have the effect of asserting the "phase resynch" pin 
on the SBX's synthesizer at the exact same time.




    2) based on the comment about strea

Re: [Discuss-gnuradio] Python synchronisation of 2xUSRP N200 with SBX in one UHD container.

2017-09-17 Thread John Shields


Thanks, as always, Marcus,
   Here is the relevant code I 
am executing:


        self.uhd_usrp_source_0.set_clock_source('gpsdo', 0)
    self.uhd_usrp_source_0.set_time_source('gpsdo', 0)
    self.uhd_usrp_source_0.set_clock_source('mimo', 1)
    self.uhd_usrp_source_0.set_time_source('mimo', 1)
    self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
    # now put in code to make sure that both usrps have seen at least 1 
pps - pulse

    # self.save_last_pps=self.uhd_usrp_source_0.get_last_pps(0)
    # as the USRPs have been running for hours will tackle the 'spin 
until get_last_pps changes' code later


    # inserted code to synch LO and, by way of the mechanism, align the 
CORDICs
self.tune_time=self.uhd_usrp_source_0.get_time_now(0)+uhd.time_spec_t(0.1) 
# tune in 100 msecs from 'now'

    self.uhd_usrp_source_0.set_command_time(self.tune_time)
    self.uhd_usrp_source_0.set_center_freq(freq, 0)
    self.uhd_usrp_source_0.set_center_freq(freq, 1)
    self.uhd_usrp_source_0.clear_command_time()

    self.uhd_usrp_source_0.set_gain(rf_gain+.45, 0)
    self.uhd_usrp_source_0.set_antenna('RX2', 0)

    self.uhd_usrp_source_0.set_gain(rf_gain, 1)
    self.uhd_usrp_source_0.set_antenna('RX2', 1)

    when I run the FG, I get variable results - I attach 2 screenshots 
which show the averaged phase difference is 74-odd degrees for one run 
and the next run the result is 101-odd degrees. Clearly, I am doing 
something wrong but, for the life of me, I cannot figure it out. For 
completeness, I will later put this code, when it works into the 
set_freq function but I don't have this parameter changeable in the FG.


  Kind Regards,

      John




On 18/09/17 03:20, Marcus D. Leech wrote:

On 09/15/2017 05:38 PM, John Shields wrote:

Hi,

    One has O/B GPSDO, the other connected by MIMO cable on Ubuntu  
with UHD_003.010.002.000


    From the /manual/page_sync.html page there is information on how 
to align the CORDICs and LOs of SBX.


    I have modified the python generated by a GRC FG and here are the 
relevant changes I made:



    self.uhd_usrp_source_0.set_clock_source('gpsdo', 0)
    self.uhd_usrp_source_0.set_time_source('gpsdo', 0)
    self.uhd_usrp_source_0.set_clock_source('mimo', 1)
    self.uhd_usrp_source_0.set_time_source('mimo', 1)
    self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
    # inserted code to align CORDICs ?


    # inserted code to synch LO
self.tune_time=self.uhd_usrp_source_0.get_time_now(0)+uhd.time_spec_t(0.1) 
# tune in 100 msecs from 'now'

    self.uhd_usrp_source_0.set_command_time(self.tune_time)
    self.uhd_usrp_source_0.set_center_freq(freq, 0)
    self.uhd_usrp_source_0.set_center_freq(freq, 1)
    self.uhd_usrp_source_0.clear_command_time()


    self.uhd_usrp_source_0.set_gain(rf_gain, 0)
    self.uhd_usrp_source_0.set_antenna('RX2', 0)

    self.uhd_usrp_source_0.set_gain(rf_gain, 1)
    self.uhd_usrp_source_0.set_antenna('RX2', 1)


While there is a discussion on the web re: the tune_time which seems 
to suggest, I could just put in the, uhd.time_spec_t(0.1), there is a 
comment from Josh saying to make sure the time is in the future so 
that is why I added the time now.



In that same thread there were comments to the effect that 
stream_cmds have not been swig-ed as the control of streaming is part 
of the scheduler so:


questions:

    1) have I got the correct code to synch the LO i.e. by tuning 
both devices at the same exact time?
Yes.  That will have the effect of asserting the "phase resynch" pin 
on the SBX's synthesizer at the exact same time.




    2) based on the comment about stream synch being controlled by 
the scheduler, what do I need to do re: synching the CORDICs?

That should happen as a side effect of tuning at the same time.



    3) I have noticed that sometimes when I print out the 
real_seconds of time_now, it has a low number (likely the number of 
seconds the USRPs have been running.


    -- Setting references to the internal GPSDO
    -- 1) catch time transition at pps edge
    -- 2) set times next pps (synchronously)

    I presume that I am reading the time_now before it is synched 
at the next pps where the value of time goes to 1505510864.0 . If 
the answer to 1) is that my code is correct, how do I make sure that 
the pps edge has occurred before I get_time_now ?
Do a get_time_last_pps, saved that value.  Spin doing 
get_time_last_pps until it is different from the saved value. Pause a 
few 10s of milliseconds on each

  spin.




    4) the sync document a

[Discuss-gnuradio] Python synchronisation of 2xUSRP N200 with SBX in one UHD container.

2017-09-15 Thread John Shields


Hi,

    One has O/B GPSDO, the other connected by MIMO cable on Ubuntu  
with UHD_003.010.002.000


    From the /manual/page_sync.html page there is information on how to 
align the CORDICs and LOs of SBX.


    I have modified the python generated by a GRC FG and here are the 
relevant changes I made:



        self.uhd_usrp_source_0.set_clock_source('gpsdo', 0)
    self.uhd_usrp_source_0.set_time_source('gpsdo', 0)
    self.uhd_usrp_source_0.set_clock_source('mimo', 1)
    self.uhd_usrp_source_0.set_time_source('mimo', 1)
    self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
    # inserted code to align CORDICs ?


    # inserted code to synch LO
self.tune_time=self.uhd_usrp_source_0.get_time_now(0)+uhd.time_spec_t(0.1) 
# tune in 100 msecs from 'now'

        self.uhd_usrp_source_0.set_command_time(self.tune_time)
    self.uhd_usrp_source_0.set_center_freq(freq, 0)
        self.uhd_usrp_source_0.set_center_freq(freq, 1)
        self.uhd_usrp_source_0.clear_command_time()


    self.uhd_usrp_source_0.set_gain(rf_gain, 0)
    self.uhd_usrp_source_0.set_antenna('RX2', 0)

    self.uhd_usrp_source_0.set_gain(rf_gain, 1)
    self.uhd_usrp_source_0.set_antenna('RX2', 1)


While there is a discussion on the web re: the tune_time which seems to 
suggest, I could just put in the, uhd.time_spec_t(0.1), there is a 
comment from Josh saying to make sure the time is in the future so that 
is why I added the time now.



In that same thread there were comments to the effect that stream_cmds 
have not been swig-ed as the control of streaming is part of the 
scheduler so:


questions:

    1) have I got the correct code to synch the LO i.e. by tuning both 
devices at the same exact time?


    2) based on the comment about stream synch being controlled by the 
scheduler, what do I need to do re: synching the CORDICs?


    3) I have noticed that sometimes when I print out the real_seconds 
of time_now, it has a low number (likely the number of seconds the USRPs 
have been running.


    -- Setting references to the internal GPSDO
    -- 1) catch time transition at pps edge
    -- 2) set times next pps (synchronously)

        I presume that I am reading the time_now before it is synched 
at the next pps where the value of time goes to 1505510864.0 . If 
the answer to 1) is that my code is correct, how do I make sure that the 
pps edge has occurred before I get_time_now ?


    4) the sync document also implies that the phase offset will drift 
(due to thermal and other characteristics) so phase-coherent 
applications will need re-calibration. is this done by somehow stopping 
the stream(s), doing a set_freq and whatever the answer to 2) above is 
and then restarting. I am trying to collect complex visibilities over a 
long period of time ( i.e. fringe stopping) so wonder if the drift is 
slow enough whether I need to do the "calibration" mentioned in the sync 
doc?



  Kind Regards,


   John



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

Re: [Discuss-gnuradio] Synchronisation

2017-09-13 Thread John Shields


Thanks both,
All good now - I get a roughly constant phase delta 
and when I re-run the FG, I get a different phase delta ( I don't need 
to power cycle the USRPs). Now I will put in the synchronisation code 
and the phase offset should be close to zero.


  Kind Regards,

 John

On 12/09/17 21:12, mle...@ripnet.com wrote:


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 <mailto:sla1nte2...@gmail.com>> 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
mailto:sla1nte2...@gmail.com>> 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

Re: [Discuss-gnuradio] Synchronisation

2017-09-12 Thread John Shields


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 <mailto:sla1nte2...@gmail.com>> 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
mailto:sla1nte2...@gmail.com>> 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

Re: [Discuss-gnuradio] Synchronisation

2017-09-11 Thread John Shields

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 
mailto:sla1nte2...@gmail.com>> 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

--
Very Respectfully,

Dan CaJacob


___
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] Core Dump with Simple_ra and an upgraded Ubuntu system from 14.04 to 16.04 LTS today.

2017-07-17 Thread John Shields

On 17/07/17 14:04, Marcus Müller wrote:

I'd resort to making sure there's nothing old in /usr/local/lib*
anymore. Basically, move every file that hasn't been created there
since the recompile to a backup location, figure out what's missing
after that, and rebuild.

Best regards,

Marcus

On 07/17/2017 03:43 PM, Marcus D. Leech wrote:

On 07/17/2017 03:41 AM, John Shields wrote:

On 17/07/17 05:53, Marcus D. Leech wrote:

On 07/17/2017 12:47 AM, John Shields wrote:

Even after I re-installed pyephem (for python 2)
the issue continues i.e. logger_tp undefined and malloc error. GRC
is sane in that I can instantiate a USRP source and display it's FFT.

Since the logger issue is a new one (which is to
say that my Sunday build did not have the issue) - could I have
gotten an inconsistent code set from the system? I would hope not
but cannot fathom what changed to give the logger issue? As for
the malloc, I presume that somewhere in the universe someone used
the Ubuntu upgrade from 14.04 LTS to 16.04 LTS and could still run
GNURadio/simple_ra?

If you cd into your simple_ra directory and do:

git log

What is the first git hash that shows up?

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

Hi Marcus,

It shows: commit
e113d01251c90a9b93a228c2dd7cb8a609c6bb8e

I decided that perhaps I should get and install the
latest gr-ra_block and simple_ra (as of 20 minutes ago). I could
pre-install the gr-ra_blocks fine but when I tried a make on the
latest simple_ra I got :

john@i7ubuntu:~$ git clone https://github.com/patchvonbraun/simple_ra
Cloning into 'simple_ra'...
remote: Counting objects: 37, done.
remote: Total 37 (delta 0), reused 0 (delta 0), pack-reused 37
Unpacking objects: 100% (37/37), done.
Checking connectivity... done.
john@i7ubuntu:~$ cd simple_ra
john@i7ubuntu:~/simple_ra$ make
Using
.:/usr/local/lib/python2.7/dist-packages:/home/john/simple_ra/trunk:/home/john/bin
for compile...

grcc -d . simple_ra_receiver.grc
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.010.001.001-79-g7ac01c7f

Unhandled exception in thread started by Thread.__bootstrap of 140677736593152)>>git describe --abbrev=8 --dirty --always --tags
>tmprev.tmp

sed -e s/@@REV@@/`cat tmprev.tmp`/ tmprec.py
cp tmprec.py simple_ra_receiver.py
rm -f tmprev.tmp tmprec.py
john@i7ubuntu:~/simple_ra$

and the first commit in that directory is: commit
75051fdbb02aedf730905b74d9ef78ba49db56e6

Kind Regards,

John

No idea what's going on there. I just did this myself on my system,
and it worked just fine.

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

So, taking Marcus' advice - there were a couple of old libraries
libairspy.so.1.08, libhackrf.so.0.4.0 and libvolk.so.1.2.2 all from May
31 2016 so I removed them as there were current builds of 1.0.9,0.5.0
and 1.3 respectively in the same directory.

Still the malloc problem existed though a reinstall of simple_ra removed
the tp_logger issue.

As I mentioned before, I could get a basic UHD source to work OK so I
replaced the osmocom source in simple_ra grc with UHD equivalent and
re-generated and make install and the application comes up fine with one
UHD source (with address from either of my devices - one with GPSDO and
one without).

Then I went back and re-enabled the osmocom source but for only 1
channel, it also worked on either N200 though I got 10.2 (the device
with the GPSDO) gives a warning : WARN: Block (fix_cc0) max output
buffer set to 8192 instead of requested 67273792

Not sure if any of this makes any sense ?

Kind Regards,

John

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

Re: [Discuss-gnuradio] Core Dump with Simple_ra and an upgraded Ubuntu system from 14.04 to 16.04 LTS today.

2017-07-17 Thread John Shields

Thank Marcuses,

I will work along the lines recommended by
Marcus M and let you know.

While I hate to think of it, I might
need to do a clean install of 16.04 LTS and start my world over - which
is sub-optimal.

Kind Regards,

John

On 17/07/17 14:04, Marcus Müller wrote:

Best regards,

Marcus

On 07/17/2017 03:43 PM, Marcus D. Leech wrote:

On 07/17/2017 03:41 AM, John Shields wrote:

On 17/07/17 05:53, Marcus D. Leech wrote:

On 07/17/2017 12:47 AM, John Shields wrote:

Even after I re-installed pyephem (for python 2)
the issue continues i.e. logger_tp undefined and malloc error. GRC
is sane in that I can instantiate a USRP source and display it's FFT.

If you cd into your simple_ra directory and do:

git log

What is the first git hash that shows up?

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

Hi Marcus,

It shows: commit
e113d01251c90a9b93a228c2dd7cb8a609c6bb8e

grcc -d . simple_ra_receiver.grc
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.010.001.001-79-g7ac01c7f

Unhandled exception in thread started by Thread.__bootstrap of 140677736593152)>>git describe --abbrev=8 --dirty --always --tags
>tmprev.tmp

sed -e s/@@REV@@/`cat tmprev.tmp`/ tmprec.py
cp tmprec.py simple_ra_receiver.py
rm -f tmprev.tmp tmprec.py
john@i7ubuntu:~/simple_ra$

and the first commit in that directory is: commit
75051fdbb02aedf730905b74d9ef78ba49db56e6

Kind Regards,

John

No idea what's going on there. I just did this myself on my system,
and it worked just fine.

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

Re: [Discuss-gnuradio] Core Dump with Simple_ra and an upgraded Ubuntu system from 14.04 to 16.04 LTS today.

2017-07-17 Thread John Shields

On 17/07/17 05:53, Marcus D. Leech wrote:

On 07/17/2017 12:47 AM, John Shields wrote:

Even after I re-installed pyephem (for python 2) the
issue continues i.e. logger_tp undefined and malloc error. GRC is
sane in that I can instantiate a USRP source and display it's FFT.

Since the logger issue is a new one (which is to say
that my Sunday build did not have the issue) - could I have gotten an
inconsistent code set from the system? I would hope not but cannot
fathom what changed to give the logger issue? As for the malloc, I
presume that somewhere in the universe someone used the Ubuntu
upgrade from 14.04 LTS to 16.04 LTS and could still run
GNURadio/simple_ra?

If you cd into your simple_ra directory and do:

git log

What is the first git hash that shows up?

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

Hi Marcus,

It shows: commit e113d01251c90a9b93a228c2dd7cb8a609c6bb8e

grcc -d . simple_ra_receiver.grc
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.010.001.001-79-g7ac01c7f

Unhandled exception in thread started by Thread.__bootstrap of 140677736593152)>>git describe --abbrev=8 --dirty --always --tags
>tmprev.tmp

sed -e s/@@REV@@/`cat tmprev.tmp`/ tmprec.py
cp tmprec.py simple_ra_receiver.py
rm -f tmprev.tmp tmprec.py
john@i7ubuntu:~/simple_ra$

and the first commit in that directory is: commit
75051fdbb02aedf730905b74d9ef78ba49db56e6

Kind Regards,

John

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

Re: [Discuss-gnuradio] Core Dump with Simple_ra and an upgraded Ubuntu system from 14.04 to 16.04 LTS today.

2017-07-16 Thread John Shields


On 17/07/17 03:08, Marcus D. Leech wrote:

On 07/16/2017 11:03 PM, John Shields wrote:

Hi Marcus,
An update - i reinstalled python-wxgtk2.8 and that 
dependency was satisfied when I re-ran Marcus' build_gnuradio script.


When I run the same command as before, I now get:


john@i7ubuntu:~$ ./simp_10.sh
linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_003.010.001.001-79-g7ac01c7f


Exception in thread Thread-8:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
  File "/usr/lib/python2.7/threading.py", line 754, in run
self.__target(*self.__args, **self.__kwargs)
  File "/home/john/simple_ra/simple_ra_receiver.py", line 757, in 
_tod_value_probe

self.set_tod_value(val)
  File "/home/john/simple_ra/simple_ra_receiver.py", line 1564, in 
set_tod_value
self.set_cal_result(sra.calib_onoff_auto(self.tod_value, 
self.cdevn, self.cdevrate, self.cdevinit, self.cdevoff, self.cdevoff, 
"\r", self.cinterval, self.contime))
  File "/home/john/simple_ra/simple_ra_receiver.py", line 1586, in 
set_cal_result

self.set_cr(self.cal_result if self.cex == True else "OFF")
  File "/home/john/simple_ra/simple_ra_receiver.py", line 1764, in set_cr
self.set_cal_sig4log(1 if (self.cr == "ON" or self.cal_enable == 
True ) else 0)
  File "/home/john/simple_ra/simple_ra_receiver.py", line 1966, in 
set_cal_sig4log
self.set_tp_log_status(sra.log_tp_data(logger_tp.real, 
logger_tp.imag, self.freq+self.sky_off, self.idecln, self.dbw, 
self.longitude, self.prefix, 
self.lrate,self.ira,self.tplog_ena,self.expname,self.cal_sig4log,self.stype,self.logger_det_a*self.dc_gain,self.logger_det_b*self.dc_gain))

NameError: global name 'logger_tp' is not defined

gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.11.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf 
rfspace airspy redpitaya

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO Found an internal GPSDO: 
Jackson-Labs, FireFly , Firmware Rev 0.926

-- Setting references to the internal GPSDO
-- Using subdev spec 'A:0'.
-- Using LO offset of 7.34e+06 Hz.
python2: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top 
(av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && 
prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 
0)' failed.

Aborted (core dumped)

So while I still have the malloc assert, I seem to have gained an 
issue with logger_tp.


 Not sure what else I should try?

Kind Regards,

  John



On 16/07/17 10:37, Marcus Müller wrote:


Hi John,

you could find the exact libosmosdr*.so that is used at runtime. Of 
course, searching your filesystem for any libosmosdr* would be 
clever, but it might be that you have multiple prefixes or so, so we 
might as well make sure that at the time python actually starts 
loading libraries, nothing looks in the wrong places:


I'm sure we could come up with cooler ways of doing that, but for 
now, why not simply run


strace -e trace=open -o opened_files.txt python2 simple_ra 
--aperture 2.4 --ant RX2 --srate 10.0e6 --dbw 8.0e6 --freq 
1420.4057e6 --gain 37.5 --dcg 1000 --lrate 30 --integ 30 --devid 
uhd='a',type=usrp2,addr=192.168.10.2,lo_offset=7.34e6,subdev=A:0 
--longitude 172.570925 --latitude -43.519023


and then something like

grep osmosdr opened_files.txt

Then, simply check the file modification date of that file :)

Best regards,
Marcus

On 07/16/2017 11:44 AM, John Shields wrote:

Thanks Marcus,
I used the other Marcus' build_gnuradio 
script and I believe that it rebuilt gr-osmosdr. How would I check?


I built 3.7.11.1 on July 7th on 14.04 LTS 
and today, I rebuilt again on 16.04.


   Kind Regards,

John

On 16/07/17 09:28, Marcus Müller wrote:


Hi John,

looks like the the problem /might/ (not sure) be that something 
tries to access a different version of the python libraries than 
you use now – so, seeing that simple_ra doesn't come with any code 
that needs to be compiled itself, it does look like there might be 
a remnant of your 14.04-time GNU Radio installation *somewhere* on 
the system.


Soo, checking the usual suspects: did you also recompile 
gr-osmosdr after you rebuilt GNU Radio and UHD?


Best regards,

Marcus


On 07/16/2017 09:53 AM, John Shields wrote:

Hi,

   While I usually regret it, I decided to update my Ubuntu 
system from 14.04 LTS to 16.04 LTS and it seemed to go fine. I 
rebuilt GNURadio and UHD and that seemed to go fine but when I 
run Simple_ra with:


simple_ra --ape

Re: [Discuss-gnuradio] Core Dump with Simple_ra and an upgraded Ubuntu system from 14.04 to 16.04 LTS today.

2017-07-16 Thread John Shields


On 17/07/17 03:08, Marcus D. Leech wrote:

On 07/16/2017 11:03 PM, John Shields wrote:

Hi Marcus,
An update - i reinstalled python-wxgtk2.8 and that 
dependency was satisfied when I re-ran Marcus' build_gnuradio script.


When I run the same command as before, I now get:


john@i7ubuntu:~$ ./simp_10.sh
linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_003.010.001.001-79-g7ac01c7f


Exception in thread Thread-8:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
  File "/usr/lib/python2.7/threading.py", line 754, in run
self.__target(*self.__args, **self.__kwargs)
  File "/home/john/simple_ra/simple_ra_receiver.py", line 757, in 
_tod_value_probe

self.set_tod_value(val)
  File "/home/john/simple_ra/simple_ra_receiver.py", line 1564, in 
set_tod_value
self.set_cal_result(sra.calib_onoff_auto(self.tod_value, 
self.cdevn, self.cdevrate, self.cdevinit, self.cdevoff, self.cdevoff, 
"\r", self.cinterval, self.contime))
  File "/home/john/simple_ra/simple_ra_receiver.py", line 1586, in 
set_cal_result

self.set_cr(self.cal_result if self.cex == True else "OFF")
  File "/home/john/simple_ra/simple_ra_receiver.py", line 1764, in set_cr
self.set_cal_sig4log(1 if (self.cr == "ON" or self.cal_enable == 
True ) else 0)
  File "/home/john/simple_ra/simple_ra_receiver.py", line 1966, in 
set_cal_sig4log
self.set_tp_log_status(sra.log_tp_data(logger_tp.real, 
logger_tp.imag, self.freq+self.sky_off, self.idecln, self.dbw, 
self.longitude, self.prefix, 
self.lrate,self.ira,self.tplog_ena,self.expname,self.cal_sig4log,self.stype,self.logger_det_a*self.dc_gain,self.logger_det_b*self.dc_gain))

NameError: global name 'logger_tp' is not defined

gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.11.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf 
rfspace airspy redpitaya

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO Found an internal GPSDO: 
Jackson-Labs, FireFly , Firmware Rev 0.926

-- Setting references to the internal GPSDO
-- Using subdev spec 'A:0'.
-- Using LO offset of 7.34e+06 Hz.
python2: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top 
(av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && 
prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 
0)' failed.

Aborted (core dumped)

So while I still have the malloc assert, I seem to have gained an 
issue with logger_tp.


 Not sure what else I should try?

Kind Regards,

  John



On 16/07/17 10:37, Marcus Müller wrote:


Hi John,

you could find the exact libosmosdr*.so that is used at runtime. Of 
course, searching your filesystem for any libosmosdr* would be 
clever, but it might be that you have multiple prefixes or so, so we 
might as well make sure that at the time python actually starts 
loading libraries, nothing looks in the wrong places:


I'm sure we could come up with cooler ways of doing that, but for 
now, why not simply run


strace -e trace=open -o opened_files.txt python2 simple_ra 
--aperture 2.4 --ant RX2 --srate 10.0e6 --dbw 8.0e6 --freq 
1420.4057e6 --gain 37.5 --dcg 1000 --lrate 30 --integ 30 --devid 
uhd='a',type=usrp2,addr=192.168.10.2,lo_offset=7.34e6,subdev=A:0 
--longitude 172.570925 --latitude -43.519023


and then something like

grep osmosdr opened_files.txt

Then, simply check the file modification date of that file :)

Best regards,
Marcus

On 07/16/2017 11:44 AM, John Shields wrote:

Thanks Marcus,
I used the other Marcus' build_gnuradio 
script and I believe that it rebuilt gr-osmosdr. How would I check?


I built 3.7.11.1 on July 7th on 14.04 LTS 
and today, I rebuilt again on 16.04.


   Kind Regards,

John

On 16/07/17 09:28, Marcus Müller wrote:


Hi John,

looks like the the problem /might/ (not sure) be that something 
tries to access a different version of the python libraries than 
you use now – so, seeing that simple_ra doesn't come with any code 
that needs to be compiled itself, it does look like there might be 
a remnant of your 14.04-time GNU Radio installation *somewhere* on 
the system.


Soo, checking the usual suspects: did you also recompile 
gr-osmosdr after you rebuilt GNU Radio and UHD?


Best regards,

Marcus


On 07/16/2017 09:53 AM, John Shields wrote:

Hi,

   While I usually regret it, I decided to update my Ubuntu 
system from 14.04 LTS to 16.04 LTS and it seemed to go fine. I 
rebuilt GNURadio and UHD and that seemed to go fine but when I 
run Simple_ra with:


simple_ra --ape

Re: [Discuss-gnuradio] Core Dump with Simple_ra and an upgraded Ubuntu system from 14.04 to 16.04 LTS today.

2017-07-16 Thread John Shields


Hi Marcus,
An update - i reinstalled python-wxgtk2.8 and that 
dependency was satisfied when I re-ran Marcus' build_gnuradio script.


When I run the same command as before, I now get:


john@i7ubuntu:~$ ./simp_10.sh
linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_003.010.001.001-79-g7ac01c7f


Exception in thread Thread-8:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
  File "/usr/lib/python2.7/threading.py", line 754, in run
self.__target(*self.__args, **self.__kwargs)
  File "/home/john/simple_ra/simple_ra_receiver.py", line 757, in 
_tod_value_probe

self.set_tod_value(val)
  File "/home/john/simple_ra/simple_ra_receiver.py", line 1564, in 
set_tod_value
self.set_cal_result(sra.calib_onoff_auto(self.tod_value, 
self.cdevn, self.cdevrate, self.cdevinit, self.cdevoff, self.cdevoff, 
"\r", self.cinterval, self.contime))
  File "/home/john/simple_ra/simple_ra_receiver.py", line 1586, in 
set_cal_result

self.set_cr(self.cal_result if self.cex == True else "OFF")
  File "/home/john/simple_ra/simple_ra_receiver.py", line 1764, in set_cr
self.set_cal_sig4log(1 if (self.cr == "ON" or self.cal_enable == 
True ) else 0)
  File "/home/john/simple_ra/simple_ra_receiver.py", line 1966, in 
set_cal_sig4log
self.set_tp_log_status(sra.log_tp_data(logger_tp.real, 
logger_tp.imag, self.freq+self.sky_off, self.idecln, self.dbw, 
self.longitude, self.prefix, 
self.lrate,self.ira,self.tplog_ena,self.expname,self.cal_sig4log,self.stype,self.logger_det_a*self.dc_gain,self.logger_det_b*self.dc_gain))

NameError: global name 'logger_tp' is not defined

gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.11.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace 
airspy redpitaya

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO Found an internal GPSDO: Jackson-Labs, 
FireFly , Firmware Rev 0.926

-- Setting references to the internal GPSDO
-- Using subdev spec 'A:0'.
-- Using LO offset of 7.34e+06 Hz.
python2: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top 
(av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && 
prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 
0)' failed.

Aborted (core dumped)

So while I still have the malloc assert, I seem to have gained an issue 
with logger_tp.


 Not sure what else I should try?

Kind Regards,

  John



On 16/07/17 10:37, Marcus Müller wrote:


Hi John,

you could find the exact libosmosdr*.so that is used at runtime. Of 
course, searching your filesystem for any libosmosdr* would be clever, 
but it might be that you have multiple prefixes or so, so we might as 
well make sure that at the time python actually starts loading 
libraries, nothing looks in the wrong places:


I'm sure we could come up with cooler ways of doing that, but for now, 
why not simply run


strace -e trace=open -o opened_files.txt python2 simple_ra --aperture 
2.4 --ant RX2 --srate 10.0e6 --dbw 8.0e6 --freq 1420.4057e6 --gain 
37.5 --dcg 1000 --lrate 30 --integ 30 --devid 
uhd='a',type=usrp2,addr=192.168.10.2,lo_offset=7.34e6,subdev=A:0 
--longitude 172.570925 --latitude -43.519023


and then something like

grep osmosdr opened_files.txt

Then, simply check the file modification date of that file :)

Best regards,
Marcus

On 07/16/2017 11:44 AM, John Shields wrote:

Thanks Marcus,
I used the other Marcus' build_gnuradio 
script and I believe that it rebuilt gr-osmosdr. How would I check?


I built 3.7.11.1 on July 7th on 14.04 LTS and 
today, I rebuilt again on 16.04.


   Kind Regards,

John

On 16/07/17 09:28, Marcus Müller wrote:


Hi John,

looks like the the problem /might/ (not sure) be that something 
tries to access a different version of the python libraries than you 
use now – so, seeing that simple_ra doesn't come with any code that 
needs to be compiled itself, it does look like there might be a 
remnant of your 14.04-time GNU Radio installation *somewhere* on the 
system.


Soo, checking the usual suspects: did you also recompile gr-osmosdr 
after you rebuilt GNU Radio and UHD?


Best regards,

Marcus


On 07/16/2017 09:53 AM, John Shields wrote:

Hi,

   While I usually regret it, I decided to update my Ubuntu system 
from 14.04 LTS to 16.04 LTS and it seemed to go fine. I rebuilt 
GNURadio and UHD and that seemed to go fine but when I run 
Simple_ra with:


simple_ra --aperture 2.4 --ant RX2 --srate 10.0e6 --dbw 8.0e6 
--freq 1420.4057e6 --gain 37.5 --dcg 1

Re: [Discuss-gnuradio] Core Dump with Simple_ra and an upgraded Ubuntu system from 14.04 to 16.04 LTS today.

2017-07-16 Thread John Shields


Hi Marcus,
Found the issue with command line you gave, namely 
simple_ra is not the python file so I changed the line to 
simple_ra_receiver and changed some of the command parameters as and got 
it to run:


john@i7ubuntu:/usr/local/lib$ ls libgnuradio-osmosdr*.* -l -a
lrwxrwxrwx 1 root root  37 Jul 16 06:26 
libgnuradio-osmosdr-0.1.5git.so -> libgnuradio-osmosdr-0.1.5git.so.0.0.0
lrwxrwxrwx 1 root root  37 Jul 16 06:26 
libgnuradio-osmosdr-0.1.5git.so.0 -> libgnuradio-osmosdr-0.1.5git.so.0.0.0
-rw-r--r-- 1 root root 1120544 Jul 16 06:26 
libgnuradio-osmosdr-0.1.5git.so.0.0.0
lrwxrwxrwx 1 root root  37 Jul 16 06:26 libgnuradio-osmosdr.so -> 
libgnuradio-osmosdr-0.1.5git.so.0.0.0


I run my Ubuntu system on utc rather than NZtime so this shows that 
osmosdr was indeed rebuilt last night (Sunday here) around 6 pm.


Kind Regards,

John



On 16/07/17 10:37, Marcus Müller wrote:


Hi John,

you could find the exact libosmosdr*.so that is used at runtime. Of 
course, searching your filesystem for any libosmosdr* would be clever, 
but it might be that you have multiple prefixes or so, so we might as 
well make sure that at the time python actually starts loading 
libraries, nothing looks in the wrong places:


I'm sure we could come up with cooler ways of doing that, but for now, 
why not simply run


strace -e trace=open -o opened_files.txt python2 simple_ra --aperture 
2.4 --ant RX2 --srate 10.0e6 --dbw 8.0e6 --freq 1420.4057e6 --gain 
37.5 --dcg 1000 --lrate 30 --integ 30 --devid 
uhd='a',type=usrp2,addr=192.168.10.2,lo_offset=7.34e6,subdev=A:0 
--longitude 172.570925 --latitude -43.519023


and then something like

grep osmosdr opened_files.txt

Then, simply check the file modification date of that file :)

Best regards,
Marcus

On 07/16/2017 11:44 AM, John Shields wrote:

Thanks Marcus,
I used the other Marcus' build_gnuradio 
script and I believe that it rebuilt gr-osmosdr. How would I check?


I built 3.7.11.1 on July 7th on 14.04 LTS and 
today, I rebuilt again on 16.04.


   Kind Regards,

John

On 16/07/17 09:28, Marcus Müller wrote:


Hi John,

looks like the the problem /might/ (not sure) be that something 
tries to access a different version of the python libraries than you 
use now – so, seeing that simple_ra doesn't come with any code that 
needs to be compiled itself, it does look like there might be a 
remnant of your 14.04-time GNU Radio installation *somewhere* on the 
system.


Soo, checking the usual suspects: did you also recompile gr-osmosdr 
after you rebuilt GNU Radio and UHD?


Best regards,

Marcus


On 07/16/2017 09:53 AM, John Shields wrote:

Hi,

   While I usually regret it, I decided to update my Ubuntu system 
from 14.04 LTS to 16.04 LTS and it seemed to go fine. I rebuilt 
GNURadio and UHD and that seemed to go fine but when I run 
Simple_ra with:


simple_ra --aperture 2.4 --ant RX2 --srate 10.0e6 --dbw 8.0e6 
--freq 1420.4057e6 --gain 37.5 --dcg 1000 --lrate 30 --integ 30 
--devid 
uhd='a',type=usrp2,addr=192.168.10.2,lo_offset=7.34e6,subdev=A:0 
--longitude 172.570925 --latitude -43.519023


linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_003.010.001.001-79-g7ac01c7f


gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.11.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf 
rfspace airspy redpitaya

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO Found an internal GPSDO: 
Jackson-Labs, FireFly , Firmware Rev 0.926

-- Setting references to the internal GPSDO
-- Using subdev spec 'A:0'.
-- Using LO offset of 7.34e+06 Hz.
python2: malloc.c:2394: sysmalloc: Assertion `(old_top == 
initial_top (av) && old_size == 0) || ((unsigned long) (old_size) 
>= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & 
(pagesize - 1)) == 0)' failed.

Aborted (core dumped)


When I fed the failure message to professor GOOGLE, I got talk of 
snap and xevilteddy but the commands for 32-bit didn't seem to work 
for my 64-bit i7 system.



Any idea(s) about how I can get rid of this message?


   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





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




___
Discuss-gnuradi

Re: [Discuss-gnuradio] Core Dump with Simple_ra and an upgraded Ubuntu system from 14.04 to 16.04 LTS today.

2017-07-16 Thread John Shields


Thanks Marcus,
I used the other Marcus' build_gnuradio script 
and I believe that it rebuilt gr-osmosdr. How would I check?


I built 3.7.11.1 on July 7th on 14.04 LTS and 
today, I rebuilt again on 16.04.


   Kind Regards,

John

On 16/07/17 09:28, Marcus Müller wrote:


Hi John,

looks like the the problem /might/ (not sure) be that something tries 
to access a different version of the python libraries than you use now 
– so, seeing that simple_ra doesn't come with any code that needs to 
be compiled itself, it does look like there might be a remnant of your 
14.04-time GNU Radio installation *somewhere* on the system.


Soo, checking the usual suspects: did you also recompile gr-osmosdr 
after you rebuilt GNU Radio and UHD?


Best regards,

Marcus


On 07/16/2017 09:53 AM, John Shields wrote:

Hi,

   While I usually regret it, I decided to update my Ubuntu system 
from 14.04 LTS to 16.04 LTS and it seemed to go fine. I rebuilt 
GNURadio and UHD and that seemed to go fine but when I run Simple_ra 
with:


simple_ra --aperture 2.4 --ant RX2 --srate 10.0e6 --dbw 8.0e6 --freq 
1420.4057e6 --gain 37.5 --dcg 1000 --lrate 30 --integ 30 --devid 
uhd='a',type=usrp2,addr=192.168.10.2,lo_offset=7.34e6,subdev=A:0 
--longitude 172.570925 --latitude -43.519023


linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_003.010.001.001-79-g7ac01c7f


gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.11.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf 
rfspace airspy redpitaya

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO Found an internal GPSDO: 
Jackson-Labs, FireFly , Firmware Rev 0.926

-- Setting references to the internal GPSDO
-- Using subdev spec 'A:0'.
-- Using LO offset of 7.34e+06 Hz.
python2: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top 
(av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && 
prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 
0)' failed.

Aborted (core dumped)


When I fed the failure message to professor GOOGLE, I got talk of 
snap and xevilteddy but the commands for 32-bit didn't seem to work 
for my 64-bit i7 system.



Any idea(s) about how I can get rid of this message?


   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



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

[Discuss-gnuradio] Core Dump with Simple_ra and an upgraded Ubuntu system from 14.04 to 16.04 LTS today.

2017-07-16 Thread John Shields


Hi,

   While I usually regret it, I decided to update my Ubuntu system from 
14.04 LTS to 16.04 LTS and it seemed to go fine. I rebuilt GNURadio and 
UHD and that seemed to go fine but when I run Simple_ra with:


simple_ra --aperture 2.4 --ant RX2 --srate 10.0e6 --dbw 8.0e6 --freq 
1420.4057e6 --gain 37.5 --dcg 1000 --lrate 30 --integ 30 --devid 
uhd='a',type=usrp2,addr=192.168.10.2,lo_offset=7.34e6,subdev=A:0 
--longitude 172.570925 --latitude -43.519023


linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_003.010.001.001-79-g7ac01c7f


gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.11.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace 
airspy redpitaya

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO Found an internal GPSDO: Jackson-Labs, 
FireFly , Firmware Rev 0.926

-- Setting references to the internal GPSDO
-- Using subdev spec 'A:0'.
-- Using LO offset of 7.34e+06 Hz.
python2: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top 
(av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && 
prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 
0)' failed.

Aborted (core dumped)


When I fed the failure message to professor GOOGLE, I got talk of snap 
and xevilteddy but the commands for 32-bit didn't seem to work for my 
64-bit i7 system.



Any idea(s) about how I can get rid of this message?


   kind Regards,


  John



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

Re: [Discuss-gnuradio] simple_ra and Ubuntu 16.04 LTS

2016-05-31 Thread John Shields


On 31/05/16 07:40, Marcus Müller wrote:
That shouldn't be necessary. If I remember correctly, my automated 
test builds based on PyBOMBS go through without installing an old 
version of SWIG.

Hence, we'd be interested in where things fail on your machine with swig3.
Best regards,
Marcus

Am 31. Mai 2016 01:53:54 MESZ, schrieb John Shields 
:


On 30/05/16 22:29, Marcus D. Leech wrote:

On 05/30/2016 06:27 PM, John Shields wrote:

oops, it was not simple_ra that I tried to re-compile against
the new GNURadio etc., it was gr-ra_blocks.

  Sorry,

  John


Which is a pre-req for simple_ra




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

Thanks Marcus,
16.04 comes with swig 3.0 so I removed
that and installed swig 2.0 and it seems to work.

 Kind Regards,

   John



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

-- Sent from my Android device with K-9 Mail. Please excuse my brevity. 
Marcus, Here is the full trace - again this was with 
gr-ra-blocks and swig 3.0. When, with your advice, I swapped it out for 
swig 2.0 , everything worked. Also, as mentioned in the 
previous e-mail, GNURadio (using your script) did work correctly even 
with swig 3.0 john@i7Ubuntu:~/gr-ra_blocks/trunk$ cmake . -- The CXX 
compiler identification is GNU 5.3.1 -- The C compiler identification is 
GNU 5.3.1 -- Check for working CXX compiler: /usr/bin/c++ -- Check for 
working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler 
ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX 
compile features -- Detecting CXX compile features - done -- Check for 
working C compiler: /usr/bin/cc -- Check for working C compiler: 
/usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C 
compiler ABI info - done -- Detecting C compile features -- Detecting C 
compile features - done -- Build type not specified: defaulting to 
release. -- Boost version: 1.58.0 -- Found the following Boost 
libraries: --   filesystem --   system -- Found PkgConfig: 
/usr/bin/pkg-config (found version "0.29.1") Checking for GNU Radio 
Module: RUNTIME  * INCLUDES=/usr/local/include  * 
LIBS=/usr/local/lib/libgnuradio-runtime.so;/usr/local/lib/libgnuradio-pmt.so 
GNURADIO_RUNTIME_FOUND = TRUE Checking for GNU Radio Module: BLOCKS  * 
INCLUDES=/usr/local/include  * 
LIBS=/usr/local/lib/libgnuradio-blocks.so;/usr/local/lib/libgnuradio-runtime.so;/usr/local/lib/libgnuradio-pmt.so 
GNURADIO_BLOCKS_FOUND = TRUE CMake Warning (dev) at 
/usr/local/lib/cmake/gnuradio/GrTest.cmake:45 (get_target_property):   
Policy CMP0026 is not set: Disallow use of the LOCATION target property. 
  Run "cmake --help-policy CMP0026" for policy details.  Use the 
cmake_policy   command to set the policy and suppress this warning.   
The LOCATION property should not be read from target "test-ra_blocks".  
Use   the target name directly with add_custom_command, or use the 
generator   expression $, as appropriate. Call Stack (most 
recent call first):   lib/CMakeLists.txt:71 (GR_ADD_TEST) This warning 
is for project developers.  Use -Wno-dev to suppress it. -- -- Checking 
for module SWIG -- Command "/usr/bin/swig2.0 -swiglib" failed with 
output: -- Found SWIG version 2.0.12. -- Found PythonLibs: 
/usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.11+") -- 
Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found 
suitable version "2.7.11+", minimum required is "2") -- Found Doxygen: 
/usr/bin/doxygen (found version "1.8.11") -- Configuring done -- 
Generating done -- Build files have been written to: 
/home/john/gr-ra_blocks/trunk john@i7Ubuntu:~/gr-ra_blocks/trunk$ make 
Scanning dependencies of target gnuradio-ra_blocks [  4%] Building CXX 
object lib/CMakeFiles/gnuradio-ra_blocks.dir/slicer_impl.cc.o [  8%] 
Building CXX object 
lib/CMakeFiles/gnuradio-ra_blocks.dir/vector_power_impl.cc.o [ 12%] 
Building CXX object 
lib/CMakeFiles/gnuradio-ra_blocks.dir/synch_folder_impl.cc.o [ 16%] 
Building CXX object 
lib/CMakeFiles/gnuradio-ra_blocks.dir/synch_detect_impl.cc.o [ 20%] 
Building CXX object 
lib/CMakeFiles/gnuradio-ra_blocks.dir/synch_clock_impl.cc.o [ 24%] 
Linking CXX shared library libgnuradio-ra_blocks.so [ 24%] Built target 
gnuradio-ra_blocks Scanning dependencies of target test-ra_blocks [ 28%] 
Building CXX object 
lib/CMakeFiles/test-ra_blocks.dir/test_ra_blocks.cc.o [ 32%] Building 
CXX object lib/CMakeFiles/test-ra_blocks.dir/qa_ra_blocks.cc.o [ 36%] 
Linking CXX exe

Re: [Discuss-gnuradio] simple_ra and Ubuntu 16.04 LTS

2016-05-30 Thread John Shields


On 30/05/16 22:29, Marcus D. Leech wrote:

On 05/30/2016 06:27 PM, John Shields wrote:
oops, it was not simple_ra that I tried to re-compile against the new 
GNURadio etc., it was gr-ra_blocks.


  Sorry,

  John


Which is a pre-req for simple_ra




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

Thanks Marcus,
16.04 comes with swig 3.0 so I removed that and 
installed swig 2.0 and it seems to work.


 Kind Regards,

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

Re: [Discuss-gnuradio] simple_ra and Ubuntu 16.04 LTS

2016-05-30 Thread John Shields


On 30/05/16 22:05, John Shields wrote:

Hi,
   Since I moved from 14.04 LTS to 15.10 a couple of weeks ago, I have 
been experiencing segmentation faults on i965_dri (graphics rendering).


   In order to (hopefully) move away from this issue, yesterday I 
upgraded to 16.04 LTS and rebuilt GNURadio (3.7.9.2) and UHD using 
Marcus' script - only new

   issue thrown up was:

  Checking for package python-wxgtk2.8
  Failed to find package 'python-wxgtk2.8' in known package 
repositories

  SOME THINGS MAY NOT BUILD AS A RESULT

   (16.04 appears to have 3.0 version )

   I have seen this sort of diagnostic before on (Failed to find 
package 'libzmq1-dev' in known package repositories) but things seemed 
to work OK so continued.


   I can get into GRC etc.

   I decided that I should re-compile simple_ra gr-ra_blocks and 
followed the instructions I usually do: cd/trunk; cmake . ; make etc.


   at the cmake level, I got the following warnings:

 GNURADIO_BLOCKS_FOUND = TRUE
 CMake Warning (dev) at 
/usr/local/lib/cmake/gnuradio/GrTest.cmake:45 (get_target_property):
 Policy CMP0026 is not set: Disallow use of the LOCATION target 
property.
 Run "cmake --help-policy CMP0026" for policy details.  Use the 
cmake_policy

 command to set the policy and suppress this warning.

 The LOCATION property should not be read from target 
"test-ra_blocks".  Use
 the target name directly with add_custom_command, or use the 
generator

 expression $, as appropriate.

 Call Stack (most recent call first):
 lib/CMakeLists.txt:71 (GR_ADD_TEST)
 This warning is for project developers.  Use -Wno-dev to suppress 
it.


  --
  -- Checking for module SWIG
  -- Command "/usr/bin/swig2.0 -swiglib" failed with output:

  -- Found SWIG version 2.0.12.
  -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so 
(found version "2.7.11+")
  -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so 
(found suitable version "2.7.11+", minimum required is "2")

  -- Found Doxygen: /usr/bin/doxygen (found version "1.8.11")
  -- Configuring done
  -- Generating done
  -- Build files have been written to: /home/john/gr-ra_blocks/trunk

when I did a make, I got:

   [ 48%] Generating ra_blocks_swig.tag
   Scanning dependencies of target ra_blocks_swig_swig_2d0df
   [ 52%] Building CXX object 
swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/ra_blocks_swig_swig_2d0df.cpp.o

   [ 56%] Linking CXX executable ra_blocks_swig_swig_2d0df
  Swig source
  /bin/sh: 1: /usr/bin/swig2.0: not found
swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/build.make:134: recipe 
for target 'swig/ra_blocks_swig_swig_2d0df' failed

  make[2]: *** [swig/ra_blocks_swig_swig_2d0df] Error 127
  make[2]: *** Deleting file 'swig/ra_blocks_swig_swig_2d0df'
  CMakeFiles/Makefile2:274: recipe for target 
'swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/all' failed
  make[1]: *** [swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/all] 
Error 2

  Makefile:138: recipe for target 'all' failed
  make: *** [all] Error 2

   I wonder if I have made an error some way along, but cannot imagine 
what.


   Any ideas?

  Kind Regards,

 John

oops, it was not simple_ra that I tried to re-compile against the new 
GNURadio etc., it was gr-ra_blocks.


  Sorry,

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

[Discuss-gnuradio] simple_ra and Ubuntu 16.04 LTS

2016-05-30 Thread John Shields


Hi,
   Since I moved from 14.04 LTS to 15.10 a couple of weeks ago, I have 
been experiencing segmentation faults on i965_dri (graphics rendering).


   In order to (hopefully) move away from this issue, yesterday I 
upgraded to 16.04 LTS and rebuilt GNURadio (3.7.9.2) and UHD using 
Marcus' script - only new

   issue thrown up was:

  Checking for package python-wxgtk2.8
  Failed to find package 'python-wxgtk2.8' in known package 
repositories

  SOME THINGS MAY NOT BUILD AS A RESULT

   (16.04 appears to have 3.0 version )

   I have seen this sort of diagnostic before on (Failed to find 
package 'libzmq1-dev' in known package repositories) but things seemed 
to work OK so continued.


   I can get into GRC etc.

   I decided that I should re-compile simple_ra and followed the 
instructions I usually do: cd/trunk; cmake . ; make etc.


   at the cmake level, I got the following warnings:

 GNURADIO_BLOCKS_FOUND = TRUE
 CMake Warning (dev) at 
/usr/local/lib/cmake/gnuradio/GrTest.cmake:45 (get_target_property):
 Policy CMP0026 is not set: Disallow use of the LOCATION target 
property.
 Run "cmake --help-policy CMP0026" for policy details.  Use the 
cmake_policy

 command to set the policy and suppress this warning.

 The LOCATION property should not be read from target 
"test-ra_blocks".  Use

 the target name directly with add_custom_command, or use the generator
 expression $, as appropriate.

 Call Stack (most recent call first):
 lib/CMakeLists.txt:71 (GR_ADD_TEST)
 This warning is for project developers.  Use -Wno-dev to suppress it.

  --
  -- Checking for module SWIG
  -- Command "/usr/bin/swig2.0 -swiglib" failed with output:

  -- Found SWIG version 2.0.12.
  -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so 
(found version "2.7.11+")
  -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so 
(found suitable version "2.7.11+", minimum required is "2")

  -- Found Doxygen: /usr/bin/doxygen (found version "1.8.11")
  -- Configuring done
  -- Generating done
  -- Build files have been written to: /home/john/gr-ra_blocks/trunk

when I did a make, I got:

   [ 48%] Generating ra_blocks_swig.tag
   Scanning dependencies of target ra_blocks_swig_swig_2d0df
   [ 52%] Building CXX object 
swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/ra_blocks_swig_swig_2d0df.cpp.o

   [ 56%] Linking CXX executable ra_blocks_swig_swig_2d0df
  Swig source
  /bin/sh: 1: /usr/bin/swig2.0: not found
  swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/build.make:134: 
recipe for target 'swig/ra_blocks_swig_swig_2d0df' failed

  make[2]: *** [swig/ra_blocks_swig_swig_2d0df] Error 127
  make[2]: *** Deleting file 'swig/ra_blocks_swig_swig_2d0df'
  CMakeFiles/Makefile2:274: recipe for target 
'swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/all' failed
  make[1]: *** [swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/all] 
Error 2

  Makefile:138: recipe for target 'all' failed
  make: *** [all] Error 2

   I wonder if I have made an error some way along, but cannot imagine 
what.


   Any ideas?

  Kind Regards,

 John


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

Re: [Discuss-gnuradio] OpenGL running out of memory

2016-05-29 Thread John Shields


Thanks Marcus,

Will give that a try.

Kind Regards,

   John

On 29/05/16 08:27, Marcus Müller wrote:

Hi John,

you could try and disable OpenGL acceleration for WX Gui. That's usually
not a good thing, and it doesn't always help if your system randomly
hangs in WX things, but if it solves this:

find (or create) your ~/.gnuradio/config.conf and add

[wxgui]
style = nongl

Best regards,
Marcus


On 29.05.2016 02:22, John Shields wrote:

Hi,
 Have GNURadio 3.7.9.2 installed on Ubuntu 15.10. I have been
running simple_ra but don't believe that is germane to the problem at
hand.

 I am running simple_ra_receiver under debug (have seen
segmentation errors in libc in the past and trying to narrow down)
but, again, don't think this is a factor in the symptom.

 Traceback (most recent call last):
   File
"/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/plotter_base.py",
line 209, in _on_paint
 for fcn in self._draw_fcns: fcn[1]()
   File
"/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/plotter_base.py",
line 65, in draw
 GL.glCallList(self._grid_compiled_list_id)
   File "/usr/lib/python2.7/dist-packages/OpenGL/error.py", line 208,
in glCheckError
 baseOperation = baseOperation,
OpenGL.error.GLError: GLError(
 err = 1285,
 description = 'out of memory',
 baseOperation = glCallList,
 cArguments = (2L,)
)

The graphics screen is frozen (grey) but the rest of the threads
run OK.
In terms of system memory, shows 1.9GiB of 15.6 so I don't believe
the system is running out of physical memory.

Cannot find anything relating to this issue vis-a-vis GNURadio.

Any ideas of what is going wrong or a workaround I could implement
to avoid?

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




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

[Discuss-gnuradio] OpenGL running out of memory

2016-05-28 Thread John Shields


Hi,
Have GNURadio 3.7.9.2 installed on Ubuntu 15.10. I have been 
running simple_ra but don't believe that is germane to the problem at hand.


I am running simple_ra_receiver under debug (have seen segmentation 
errors in libc in the past and trying to narrow down) but, again, don't 
think this is a factor in the symptom.


Traceback (most recent call last):
  File 
"/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/plotter_base.py", 
line 209, in _on_paint

for fcn in self._draw_fcns: fcn[1]()
  File 
"/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/plotter_base.py", 
line 65, in draw

GL.glCallList(self._grid_compiled_list_id)
  File "/usr/lib/python2.7/dist-packages/OpenGL/error.py", line 208, in 
glCheckError

baseOperation = baseOperation,
OpenGL.error.GLError: GLError(
err = 1285,
description = 'out of memory',
baseOperation = glCallList,
cArguments = (2L,)
)

   The graphics screen is frozen (grey) but the rest of the threads run OK.
   In terms of system memory, shows 1.9GiB of 15.6 so I don't believe 
the system is running out of physical memory.


   Cannot find anything relating to this issue vis-a-vis GNURadio.

   Any ideas of what is going wrong or a workaround I could implement 
to avoid?


   Kind Regards,

 John





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

Re: [Discuss-gnuradio] GNURadio segmentation fault

2016-05-22 Thread John Shields


On 22/05/16 11:06, Marcus D. Leech wrote:

On 05/22/2016 05:19 AM, Marcus Müller wrote:

Hi John,

I don't really know about the memory usage you see, but:
Did you rebuild GNU Radio (and UHD and basically everything you did not
install directly through Ubuntu's apt-get)? Upgrading a distro often
changes the libc version used, and that might mean that the ABI of the
very core functionality has changed, and your program is calling
functions with the wrong parameters or functions that don't exist.

That would be my first guess.
Now, you said you upgraded in an attempt to remedy those failures, so
I'm fully aware that might not be the /right/ guess, but segfaults in
libc usually only happen if you call some system functionality with a
non-existing / too short buffer or invalid pointer to a structure or
something like that, and the most common cause for that (aside from
actual bugs, but I'm not aware of anything currently, but I haven't
really used simple_ra much) would be an ABI mismatch. Now, this isn't
going to fix if something in simple_ra actually segfaults:

So, my first attempt would really be a make clean; make; (sudo) make
install .
If that fails, run your simple_ra application through GDB. The trick
here would probably be (Marcus L., you shout if I say something stupid,
right?) to modify the simple_ra script; at the very end, replace

simple_ra_receiver.py --frequency ...

by

gdb -ex run --args python2 simple_ra_receiver --frequency ...

to let gdb run the python flow graph for you. Then, at some point gdb
should catch the segfault and drop you to a command prompt; "bt" or
"backtrace" is the command you want to do to see the cascade of calls
going on (it might be helpful to have installed the "xyz-dbg" packages
for Ubuntu's python and libc packages, and build your GNU Radio with
debug symbols enabled, i.e. using -DCMAKE_BUILD_TYPE=RelWithDebInfo when
calling cmake) when the segfault happened. Often, that's already
sufficient to narrow down the bug. If it isn't: the lines of the
backtrace start with a #number; that number is the frame number, and you
can change into each frame, do a "list" (if debug symbols are present)
and get the source code where the program currently is, use "print" to
print variables (really invaluable if you've e.g. got a "for" loop that
keeps on writing past the end of a buffer and you don't know why).

Best regards,
Marcus


It's conceivable that this is simple_ra's fault.  While it's 
almost-entirely written in GRC with some helper Python, there are some 
custom blocks
  used from gr-ra_blocks, written in C++.  I'd be interested to know 
if the failure is actually from one of those...




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

Thank you Marcus'.

I used Marcus(L) build script to get UHD/GNURadio so I will do the :make 
clean etc. that is suggested. You can see from the syslog that, the 
upgrade to 15.10 did, indeed, bump the revision of libc.


That was a good tip re: modifying the simple_ra run script to put GDB in 
first.


Will run in that mode and let you know what I get.

   Kind Regards,

 John

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

[Discuss-gnuradio] GNURadio segmentation fault

2016-05-22 Thread John Shields


Dear All,
 I have been running GNURadio fairly constantly for a 
couple of weeks now using simple_ra although, I don't believe it is a 
problem with that application as HTOP doesn't indicate memory issues etc.


 I run GNURadio version 3.7.9.1 on an Intel® Core™ i7-2600 
CPU @ 3.40GHz × 8.


 I have been running Ubuntu 14.04 LTS for years now but on 
encountering the issue recently with continuous GNURadio use, I upgraded 
to 15.10 but the problem still occurs.


 Here is what they syslog(s) say:

 previous (for years!) 14.04LTS

May  7 15:01:34 i7Ubuntu kernel: [59309.794629] python2[3772]: 
segfault at 0 ip 7f8e53be91c0 sp 7ffe66518cc8 error 6 in 
libc-2.19.so[7f8e53b51000+1bb000]


May 11 02:06:54 i7Ubuntu kernel: [97164.418968] python2[2735]: 
segfault at 0 ip 7fbc2dce61c0 sp 7ffdd22fa0a8 error 6 in 
libc-2.19.so[7fbc2dc4e000+1bb000]


upgraded to 15.10

May 21 22:22:12 i7Ubuntu kernel: [643331.441347] python2[24419]: 
segfault at 0 ip 7faee89160e0 sp 7ffc3857e748 error 6 in 
libc-2.21.so[7faee8876000+1c]


May 22 05:36:28 i7Ubuntu kernel: [21018.530748] python2[2408]: 
segfault at 0 ip 7ff267bcb882 sp 7ffdfe2d0b90 error 6 in 
i965_dri.so[7ff267814000+5b2000]


 I get no other symptoms i.e. no D's or anything bad 
reported by UHD.


 I also don't get problems with any other applications to 
indicate some memory issue though I wouldn't expect the regular apps to 
use as much memory - mind you when running simple_ra uses less than 10% 
of the memory.


 Any ideas on how I can narrow the cause down?

   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

2016-05-03 Thread John Shields


Thanks Marcus,
The cable is cat-5e and the length is 52 meters 
(give or take).


Based on your calculations, it seems that I am 
setting myself for high likelihood of a dropped packet if I were to run 
for 4 or 5 days continuously.


I have moved the N200 over to another cable to 
see if the situation improves but I think that the best solution is to 
move the Ubuntu box into the shack rather than move house/shack closer :)


   Slainte,

   John

On 03/05/16 19:12, mle...@ripnet.com wrote:


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 <mailto: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

2016-05-03 Thread John Shields


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 <mailto: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

2016-05-03 Thread John Shields


Thanks Marcus,

Have put answers in-line.

   Kind Regards,

   John

On 03/05/16 08:20, Marcus Müller wrote:

On 03.05.2016 09:52, John Shields wrote:

On 03/05/16 02:58, Marcus D. Leech wrote:

On 05/02/2016 10:40 PM, John Shields wrote:

the system runs along happily for several maybe even up to 20 odd
hours but, as below, I start to see one or more Ds. In one run of 23
hours, I had 10 Ds and eventually a segmentation fault - not sure if
it is coincident with issuing of the final 'D'. Sometimes the D is
not accompanied by UHD errors

here is the terminal output from the last run:

linux; GNU C++ version 4.8.4; Boost_105400;
UHD_003.010.git-156-g2d68f228

Using Volk machine: avx_64_mmx_orc
gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 3.7.9.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf
rfspace airspy redpitaya
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO Found an internal GPSDO
-- Setting references to the internal GPSDO
-- Using subdev spec 'A:0'.
-- Using LO offset of 1e+07 Hz.
WARNING: Overriding original sample rate of 1e+07 with 2e+06
-- Loaded /home/john/.uhd/cal/rx_iq_cal_v0.2_E2R10Z1XS.csv
D
UHD Error:
 Control packet attempt 0, sequence number 10594:
 RuntimeError: no control response, possible packet loss

UHD Error:
 Control packet attempt 1, sequence number 10595:
 RuntimeError: no control response, possible packet loss

UHD Error:
 Control packet attempt 2, sequence number 10596:
 RuntimeError: no control response, possible packet loss

UHD Error:
 An unexpected exception was caught in a task loop.
 The task loop will now exit, things may not work.
 RuntimeError: link dead: timeout waiting for control packet ACK
Terminated


00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
00 [VGA controller])
...
 Kernel driver in use: i915

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
...
 Kernel driver in use: r8169

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
...
 Kernel driver in use: r8169


06:00.0 Ethernet controller: Qualcomm Atheros AR8151 v2.0 Gigabit
Ethernet (rev c0)
...
 Kernel driver in use: atl1c

by looking at the Realtek card, the PHY chip is the RTL8168B
(single-chip Gigabit NIC Ethernet Controller for PCI Express)

not sure if there is general knowledge of this Taiwanese NIC/Chip re:
dropping packets or other performance issues? I note these boards are
rev 1.0!

They are certainly not the greatest NICs in the world when it comes to
CPU efficiency, but I'm not aware of any specific prolems. Can you
actually just try with the atheros interface? That would rule them out
as possible source of problems.

Yes, I will give the on-board Atheros a try.

re: relatively high CPU for 8 cores running simple_ra - the '8' is
actually only 4 real cores (2 logical cores per physical) but as can
be seen from below,
I don't believe I splashed out on a graphics card and just took the
motherboard's capability. Perhaps my Scottish accent can be detected?
Will look into getting something along those lines if it improves the
graphics performance.

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
00 [VGA controller])
..
 Kernel driver in use: i915

That's an Intel HD 4000 or so, right? At any rate, they should have
enough horsepower to update a few plots via OpenGL. What indeed could be
happening is that hardware rendering is not used (the wx GUI toolkit
seems to be a little special sometimes, but then, who or what isn't?).
So two things:

1. could you share what "glxinfo | grep renderer" says? (or was it
glxinfo64? If both are present, send both :) )
2. there was a way to dis/enable wx OpenGL usage per config file. My
brain feels a bit holey these days; I'd have to research that.


john@i7Ubuntu:~$ glxinfo | grep renderer
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Desktop

not sure if it is significant or not but I had to install glxinfo ( sudo 
apt-get install mesa-utils)




General question: After things crashed, using the N210 works if you
re-start simple_ra (or any other UHD sample streaming program), or do
you need to power-cycle the N210?
no Marcus, I just restart simple_ra and it goes off running fine - no 
need to touch the N200.


Best regards,
Marcus

___
Discuss-gnuradio mailing list
D

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

2016-05-03 Thread John Shields


On 03/05/16 02:58, Marcus D. Leech wrote:

On 05/02/2016 10:40 PM, John Shields wrote:

Hi,
   I am using Ubunutu 14.04 LTS with GNURadio 3.7.9.1 and have a USRP 
N200 with SBXv3. I have been using the aptly-named and highly useful 
Simple_ra though I believe this is orthogonal to the issues I am seeing.


when I run simple_ra with :

 simple_ra  --srate 2e6 --freq 848e6 --gain 37 --dcg 1 --devid 
uhd=a,type=usrp2,addr=192.168.20.2,lo_offset=10e6,subdev=A:0 
--longitude 172.57027 --latitude -43.51944 --spde


the system runs along happily for several maybe even up to 20 odd 
hours but, as below, I start to see one or more Ds. In one run of 23 
hours, I had 10 Ds and eventually a segmentation fault - not sure if 
it is coincident with issuing of the final 'D'. Sometimes the D is 
not accompanied by UHD errors


here is the terminal output from the last run:

linux; GNU C++ version 4.8.4; Boost_105400; 
UHD_003.010.git-156-g2d68f228


Using Volk machine: avx_64_mmx_orc
gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 3.7.9.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf 
rfspace airspy redpitaya

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO Found an internal GPSDO
-- Setting references to the internal GPSDO
-- Using subdev spec 'A:0'.
-- Using LO offset of 1e+07 Hz.
WARNING: Overriding original sample rate of 1e+07 with 2e+06
-- Loaded /home/john/.uhd/cal/rx_iq_cal_v0.2_E2R10Z1XS.csv
D
UHD Error:
Control packet attempt 0, sequence number 10594:
RuntimeError: no control response, possible packet loss

UHD Error:
Control packet attempt 1, sequence number 10595:
RuntimeError: no control response, possible packet loss

UHD Error:
Control packet attempt 2, sequence number 10596:
RuntimeError: no control response, possible packet loss

UHD Error:
An unexpected exception was caught in a task loop.
The task loop will now exit, things may not work.
RuntimeError: link dead: timeout waiting for control packet ACK
Terminated


I have a fairly powerful cpu Intel® Core™ i7-2600 CPU @ 3.40GHz × 8, 
15.6 GiB of memory and run 64-bit os and have the USRP on it's own 
subnet and NIC.

Apart from setting:
net.core.rmem_max = 5000
net.core.wmem_max = 1048576

I have not 'tuned' any os settings. When the application is running, 
the 8 cores are between 40-50% utilised.


When I restart simple_ra after the error, it runs again fine until it 
hits an issue n-hours in the future.


Any ideas of how I can narrow down the cause of this?

  Kind Regards,

   John




Do you happen to know what kind of NIC you have?

Also, 2MSPS should not be chewing up much of your CPU--what kind of 
graphics card do you have?  Is this a real, or virtual, machine setup?


There Intel 82579LM is known for dropping packets under certain 
circumstances that shouldn't cause it to drop packets.  This is basically
  fatal to the way UHD does network I/O--since it uses UDP, with no 
retry mechanism (and, indeed, it's easy to see that at higher sample
  rates in particular, any TCP-like mechanism is going to cause 
heartburn for real-time flows).


If you do a:

lspci -v

It should show you what the Ethernet interface(s) are.

If this is a *server* motherboard, the underlying graphics subsystem 
may be just a framebuffer, in which case, your CPU is working really

  hard to render even simple graphics.




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Sorry, but forgot to answer the question re: real or virtual setup - I 
run real.


 Slainte,

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

2016-05-03 Thread John Shields


On 03/05/16 02:58, Marcus D. Leech wrote:

On 05/02/2016 10:40 PM, John Shields wrote:

Hi,
   I am using Ubunutu 14.04 LTS with GNURadio 3.7.9.1 and have a USRP 
N200 with SBXv3. I have been using the aptly-named and highly useful 
Simple_ra though I believe this is orthogonal to the issues I am seeing.


when I run simple_ra with :

 simple_ra  --srate 2e6 --freq 848e6 --gain 37 --dcg 1 --devid 
uhd=a,type=usrp2,addr=192.168.20.2,lo_offset=10e6,subdev=A:0 
--longitude 172.57027 --latitude -43.51944 --spde


the system runs along happily for several maybe even up to 20 odd 
hours but, as below, I start to see one or more Ds. In one run of 23 
hours, I had 10 Ds and eventually a segmentation fault - not sure if 
it is coincident with issuing of the final 'D'. Sometimes the D is 
not accompanied by UHD errors


here is the terminal output from the last run:

linux; GNU C++ version 4.8.4; Boost_105400; 
UHD_003.010.git-156-g2d68f228


Using Volk machine: avx_64_mmx_orc
gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 3.7.9.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf 
rfspace airspy redpitaya

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO Found an internal GPSDO
-- Setting references to the internal GPSDO
-- Using subdev spec 'A:0'.
-- Using LO offset of 1e+07 Hz.
WARNING: Overriding original sample rate of 1e+07 with 2e+06
-- Loaded /home/john/.uhd/cal/rx_iq_cal_v0.2_E2R10Z1XS.csv
D
UHD Error:
Control packet attempt 0, sequence number 10594:
RuntimeError: no control response, possible packet loss

UHD Error:
Control packet attempt 1, sequence number 10595:
RuntimeError: no control response, possible packet loss

UHD Error:
Control packet attempt 2, sequence number 10596:
RuntimeError: no control response, possible packet loss

UHD Error:
An unexpected exception was caught in a task loop.
The task loop will now exit, things may not work.
RuntimeError: link dead: timeout waiting for control packet ACK
Terminated


I have a fairly powerful cpu Intel® Core™ i7-2600 CPU @ 3.40GHz × 8, 
15.6 GiB of memory and run 64-bit os and have the USRP on it's own 
subnet and NIC.

Apart from setting:
net.core.rmem_max = 5000
net.core.wmem_max = 1048576

I have not 'tuned' any os settings. When the application is running, 
the 8 cores are between 40-50% utilised.


When I restart simple_ra after the error, it runs again fine until it 
hits an issue n-hours in the future.


Any ideas of how I can narrow down the cause of this?

  Kind Regards,

   John




Do you happen to know what kind of NIC you have?

Also, 2MSPS should not be chewing up much of your CPU--what kind of 
graphics card do you have?  Is this a real, or virtual, machine setup?


There Intel 82579LM is known for dropping packets under certain 
circumstances that shouldn't cause it to drop packets.  This is basically
  fatal to the way UHD does network I/O--since it uses UDP, with no 
retry mechanism (and, indeed, it's easy to see that at higher sample
  rates in particular, any TCP-like mechanism is going to cause 
heartburn for real-time flows).


If you do a:

lspci -v

It should show you what the Ethernet interface(s) are.

If this is a *server* motherboard, the underlying graphics subsystem 
may be just a framebuffer, in which case, your CPU is working really

  hard to render even simple graphics.




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

Thanks very much, as always, Marcus.

To the NICs : the command gave the following (edited to remove USB, IDE 
etc.)


00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 
[VGA controller])

Subsystem: Gigabyte Technology Co., Ltd Device d000
Flags: bus master, fast devsel, latency 0, IRQ 47
Memory at f740 (64-bit, non-prefetchable) [size=4M]
Memory at e000 (64-bit, prefetchable) [size=256M]
I/O ports at f000 [size=64]
Expansion ROM at  [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express 
Gigabit Ethernet controller

Flags: bus master, fast devsel, latency 0, IRQ 44
I/O ports at e000 [size=256]
Memory at f7b0 (64-bit, non-prefetchable) [size=4K]
Expansion ROM at dfb0 [disabled] [size=128K]
Capabilities: [40] Power Management version 2
Capabilities: [48] Vital Pr

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

2016-05-02 Thread John Shields


Hi,
   I am using Ubunutu 14.04 LTS with GNURadio 3.7.9.1 and have a USRP 
N200 with SBXv3. I have been using the aptly-named and highly useful 
Simple_ra though I believe this is orthogonal to the issues I am seeing.


when I run simple_ra with :

 simple_ra  --srate 2e6 --freq 848e6 --gain 37 --dcg 1 --devid 
uhd=a,type=usrp2,addr=192.168.20.2,lo_offset=10e6,subdev=A:0 --longitude 
172.57027 --latitude -43.51944 --spde


the system runs along happily for several maybe even up to 20 odd hours 
but, as below, I start to see one or more Ds. In one run of 23 hours, I 
had 10 Ds and eventually a segmentation fault - not sure if it is 
coincident with issuing of the final 'D'. Sometimes the D is not 
accompanied by UHD errors


here is the terminal output from the last run:

linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-156-g2d68f228

Using Volk machine: avx_64_mmx_orc
gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 3.7.9.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace 
airspy redpitaya

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO Found an internal GPSDO
-- Setting references to the internal GPSDO
-- Using subdev spec 'A:0'.
-- Using LO offset of 1e+07 Hz.
WARNING: Overriding original sample rate of 1e+07 with 2e+06
-- Loaded /home/john/.uhd/cal/rx_iq_cal_v0.2_E2R10Z1XS.csv
D
UHD Error:
Control packet attempt 0, sequence number 10594:
RuntimeError: no control response, possible packet loss

UHD Error:
Control packet attempt 1, sequence number 10595:
RuntimeError: no control response, possible packet loss

UHD Error:
Control packet attempt 2, sequence number 10596:
RuntimeError: no control response, possible packet loss

UHD Error:
An unexpected exception was caught in a task loop.
The task loop will now exit, things may not work.
RuntimeError: link dead: timeout waiting for control packet ACK
Terminated


I have a fairly powerful cpu Intel® Core™ i7-2600 CPU @ 3.40GHz × 8, 
15.6 GiB of memory and run 64-bit os and have the USRP on it's own 
subnet and NIC.

Apart from setting:
net.core.rmem_max = 5000
net.core.wmem_max = 1048576

I have not 'tuned' any os settings. When the application is running, the 
8 cores are between 40-50% utilised.


When I restart simple_ra after the error, it runs again fine until it 
hits an issue n-hours in the future.


Any ideas of how I can narrow down the cause of this?

  Kind Regards,

   John




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

Re: [Discuss-gnuradio] Two minor problems on Mac OS X

2016-01-14 Thread John Shields


Hi  Ma,
  Answer to Q1 is to issue command:  gnuradio-config-info --v

  if you are interested in GRC verions, the command is 
gnuradio-companion --v


 Kind Regards,

  John


On 14/01/16 22:21, MA wrote:

Thanks.
1- So, how should we determine a gnuradio installation's version? (Is 
it specified anywhere?)

2- Please take a look at this screenshot:
http://imgur.com/s285JXK
Notice the difference between the text in output window or blocks list 
and the main part of GRC. The blocks on the main section are 
pixelated. Is this because of X window? (It does not feel native, and 
the strange thing is that other sections' fonts look normal)


Mehdi

On Fri, Jan 15, 2016 at 1:35 AM, Michael Dickens 
mailto:michael.dick...@ettus.com>> wrote:


Hi Mehdi - The first item looks correct; it's a default string
that can be overridden by the user mostly for the purpose of
package managers. I'm not sure if I understand the 2nd item. When
I run GRC it looks fine. Can you send me a screenshot off-list &
I'll work with you there to see what can be done. - MLD
On Thu, Jan 14, 2016, at 03:54 PM, MA wrote:

I've compiled the 3.7.9 (from the tar.gz file on the website) on
OS X 10.11.2
Everything is OK and I even tested it with a SDR receiver to make
sure it's working as expected.
There are two minor problems:
1- The version string (shown on grc's "About" dialog and its
welcome screen) is "v3.7.x-xxx-xunknown".
Why is that? Is it a problem?
How can I be certain that it's the 3.7.9? (I had 3.7.7.1
previously, but I've deleted that)
2- The fonts are almost blurred on the grc. My MacBook's screen
is Retina. Is this because of that? Can it be improved?


___
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] Limit on file_sources in GRC ?

2012-06-22 Thread John Shields


On 23/06/12 14:00, Marcus D. Leech wrote:

Ubuntu 12.04 LTS, GNU Radio 3.6.1git-2-g2c7ea132 (on i7).

I have a simple GRC flow with a couple of file sources - these are 
FIFOs. I have a separate application which will simulate various 
antenna configurations and it attempts to open both of these FIFOs in 
O_WRONLY|O_NONBLOCK . As the FIFO's are Write, the other end needs to 
be 'reading' in order that I don't get "No such device or address". I 
accomplish this by starting the GRC flow.The separate application 
attempts to open the FIFO's if unsuccessful 10 times.


With either of the source files, only, enabled in GRC, I can get that 
FIFO open first time from the application but cannot get them both to 
open.


Is there a limit on the # of file sources in GRC which is leading to 
this behaviour?


  Kind Regards,

   John

The problem isn't, per se, Gnu Radio.  The semantics of opening for 
write are such that there *must* be a reader available.  Not so with
  opening for read, provided that you've opened NONBLOCK. Opening for 
read will block until there's a writer if it isn't opened NONBLOCK.


So the problem is that you can't guarantee which *order* things will 
happen in -- that is, your opening for write may not correspond to the
  reader that Gnu Radio has opened (and is waiting to proceed). I'd 
say keep trying to open all of your writer FIFOs at once, and figure out

  which one(s) have succeeded.  Pause a little between each iteration.








Thanks Marcus - will give that a try. I was hoping I didn't need to send 
data to the first FIFO opened so that the second one would/could succeed 
so this is good news; 1 TPB helps, I guess.


Kind Regards,

John

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

[Discuss-gnuradio] Limit on file_sources in GRC ?

2012-06-22 Thread John Shields


Ubuntu 12.04 LTS, GNU Radio 3.6.1git-2-g2c7ea132 (on i7).

I have a simple GRC flow with a couple of file sources - these are 
FIFOs. I have a separate application which will simulate various antenna 
configurations and it attempts to open both of these FIFOs in 
O_WRONLY|O_NONBLOCK . As the FIFO's are Write, the other end needs to be 
'reading' in order that I don't get "No such device or address". I 
accomplish this by starting the GRC flow.The separate application 
attempts to open the FIFO's if unsuccessful 10 times.


With either of the source files, only, enabled in GRC, I can get that 
FIFO open first time from the application but cannot get them both to open.


Is there a limit on the # of file sources in GRC which is leading to 
this behaviour?


  Kind Regards,

   John

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

Re: [Discuss-gnuradio] shift param in FFT block in GRC

2012-06-12 Thread John Shields


On 12/06/12 21:00, Martin Braun wrote:

On Tue, Jun 12, 2012 at 08:19:21PM +1200, John Shields wrote:

When I add a FFT block in the GRC (gr_fft_vxx if I understand things
correctly) I am offered a boolean parameter 'shift'. When I attempt
to discern the code, there is a comment:

// apply a fft shift on the data  - for the fwd FFT and
// apply an ifft shift on the data  - for reverse.

What does this parameter do?

It applies an FFT shift on the data for the forward FFT and an IFFT
shift on the data for reverse FFT.

Did that help?

If not, a quick Google search for 'fft shift' explains that this moves
the DC carrier to the centre of the spectrum (instead of the far left).

MB



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

Thanks Martin,
  Yes it does help. I had seen some 'funky stuff' 
in Marcus' Simple_RA and wondered why. Now  I think I know.


 Kind Regards,

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

[Discuss-gnuradio] shift param in FFT block in GRC

2012-06-12 Thread John Shields

When I add a FFT block in the GRC (gr_fft_vxx if I understand things 
correctly) I am offered a boolean parameter 'shift'. When I attempt to 
discern the code, there is a comment:


   // apply a fft shift on the data  - for the fwd FFT and
   // apply an ifft shift on the data  - for reverse.

What does this parameter do?

Kind Regards,

John

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

Re: [Discuss-gnuradio] GRC - converting complex stream to vector for FFT

2012-06-05 Thread John Shields


On 06/06/12 18:40, Josh Blum wrote:


On 06/05/2012 11:38 PM, John Shields wrote:

Hi Josh,
It turns out I was using the block I think you were recommending. Here is a
picture of the flowgraph with the red arrow which would appear to be an issue
as, with it present, the flow graph will not execute.


vec length should be 1, thats referring to the input size.

set num items to be the fft length


Kind Regards,

John
Sorry Josh - had it backwards. When reversed, as you suggest, it works 
like charm.


 Thanks very much,

Slainte,

  John

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

Re: [Discuss-gnuradio] GRC - converting complex stream to vector for FFT

2012-06-02 Thread John Shields


Thanks, Josh. Will give it a whirl.

   Kind Regards,

 John



On 03/06/12 05:33, Josh Blum wrote:


On 06/02/2012 01:00 AM, John Shields wrote:

I have complex multiplied a couple of 1 msps complex values and I wish
to do a 2048 FFT so am trying to convert to 2048-length vector but I
cannot find a suitable block in the 'stream conversion' group of GRC. By
making vec length 2048 I get the correct kind of connector on the output
of the block (dark blue) but the input is also dark blue and I just want
complex (Re, Im) alternating.

   Can someone point me in the right direction?


I think you are looking for the stream to vector block? It will turn a
stream of X into a vector of type X, which you can pass into a FFT block.

-josh


 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




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

[Discuss-gnuradio] GRC - converting complex stream to vector for FFT

2012-06-02 Thread John Shields

I have complex multiplied a couple of 1 msps complex values and I wish 
to do a 2048 FFT so am trying to convert to 2048-length vector but I 
cannot find a suitable block in the 'stream conversion' group of GRC. By 
making vec length 2048 I get the correct kind of connector on the output 
of the block (dark blue) but the input is also dark blue and I just want 
complex (Re, Im) alternating.


  Can someone point me in the right direction?

Kind Regards,


 John

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

Re: [Discuss-gnuradio] Decimating FIR Filter Taps and gr.firdes.complex_band_pass incompatibility - Marcus SARA SID SDR

2010-09-26 Thread John Shields

Thanks very much Marcus. I eventually figured out that in the variable block, I 
needed to include:

gr.firdes.complex_band_pass (gain,sampling_freq,low_cutoff_freq,

high_cutoff_freq, transition_width, window = WIN_HAMMING,beta = 6.76)

and when I plugged in some variables based on the b/w and centre frequency, the 
Decimating FIR filter block went good!

Of course, no idea if my guesses are real-world.

Look forward to getting the latest and greatest.



   Slainte,



 John


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

[Discuss-gnuradio] Decimating FIR Filter Taps and gr.firdes.complex_band_pass incompatibility - Marcus SARA SID SDR

2010-09-25 Thread John Shields

In the April/May 2010 SARA Journal, Marcus Leech had an article entitled
"Building an SDR SID Receiver in an Afternoon" which was highly
information and inspirational. While my sound card only goes to 48 KHz
sampling, I decided to try his implementation and in terms of entry into
GRC, things have gone well except for the taps and their variables and a
non-cooperative import box.

While the screenshot in the article shows variables of ID: c1..4_taps
and value of gr.firdes.complex_b... the text hints are band_pass and the
variable blocks do accept this though it is displayed as value:
 , however, the Decimating FIR Filters complain
about:

Problem 1

>>> Param - Taps(taps):
Expression "[]" is invalid for
type complex vector.

no matter which "type" I specify for the filter.

Problem 2

import :notchfilt 

 >>> Param - Import(import):
Bad import syntax: "notchfilt".

have tried notchfilter etc. but without success. Not sure if this is
related to Problem 1?

   Kind Regards,

John




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

[Discuss-gnuradio] GNRU Radio Build issues on native Ubuntu (Jaunty)

2010-09-23 Thread John Shields

Have given up on WUBI (Lucid) environment and build/install according to
gnuradio../wiki/gnuradio/UbuntuInstall on a native Ubuntu(Jaunty)

Decided to install boost_1_37_0 as _1_44_0 which I used previously as it
was the latest version, did not conform to instructions on above wiki. 

This allowed me (Under Installing GNU Radio section) to ./configure
--with -boost=$BOOST_PREFIX which had been an issue on the other
computer with Boost_1_44_0.

Unfortunately, the next command, make 
bombs out with:

/usr/include/boost/program_options/detail/parsers.hpp:75: undefined
reference to
`boost::program_options::detail::cmdline::set_additional_parser(boost::function1, std::allocator >, std::basic_string, std::allocator > >, std::basic_string, std::allocator > const&, 
std::allocator >)'
collect2: ld returned 1 exit status
make[4]: *** [gnuradio-config-info] Error 1
make[4]: Leaving directory `/home/john/gnuradio/gnuradio-core/src/lib'
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory `/home/john/gnuradio/gnuradio-core/src/lib'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/home/john/gnuradio/gnuradio-core/src'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/john/gnuradio/gnuradio-core'
make: *** [install-recursive] Error 1

Has anyone experienced something similar?

Kind Regards,

John


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

[Discuss-gnuradio] Build issues on native Ubuntu (Jaunty)

2010-09-23 Thread John Shields

Have given up on WUBI (Lucid) and build/install according to
gnuradio../wiki/gnuradio/UbuntuInstall

Decided to install boost_1_37_0 as _1_44_0 did not conform to
instructions on above wiki. 

This allowed me (Under Installing GNU Radio section) to ./configure
--with -boost=$BOOST_PREFIX which had been an issue on the other
computer.

Unfortunately, the next command, make 
bombs out with:



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

Re: [Discuss-gnuradio] Is WUBI (Lucid) a viable environment for GNU-Radio (3.2.2) ?

2010-09-21 Thread John Shields

Thanks Eric, will do though I used the sealed one given by Ettus but 
stranger things have happened.


I had also wondered about whether the USB ports on my laptop were running 
fast enough and before I posted, have confirmed "Enhanced" in the Host 
Controller description.


I wonder if U is underun and O is overrun? I briefly looked at the source 
but am not familiar with GNU_Radio and it's classes.


Thanks again for your suggestion,

   Regards,

John



- Original Message - 
From: "Eric Blossom" 

To: "John Shields" 
Cc: 
Sent: Wednesday, September 22, 2010 3:31 AM
Subject: Re: [Discuss-gnuradio] Is WUBI (Lucid) a viable environment for 
GNU-Radio (3.2.2) ?




On Tue, Sep 21, 2010 at 08:24:53PM +1200, John Shields wrote:
I recently purchased a USRP and have a fresh install of WUBI (HP 
Pavillion DV5 , Windows Home Vista) and used 
gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall to install things.


I passed 'make check' correctly

I have my username in the group usrp

j...@ubuntu:~/gnuradio$ ls -lR /dev/bus/usb | grep usrp
crw-rw 1 root usrp 189, 132 2010-09-21 11:14 005

when I execute ./usrp_benchmark_usb.py I get:


Testing 2MB/sec... gr_vmcircbuf_createfilemapping: createfilemapping is 
not available
/home/john/.gnuradio/prefs/gr_vmcircbuf_default_factory: Permission 
denied

uUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuOuUuOuUuOuUuOuUuOuUuOuUuOuU^Z


and it hangs so I kill it

[1]+  Stopped ./usrp_benchmark_usb.py

I cannot repeat this operation as I get

Testing 2MB/sec... usrp_open_interface:usb_set_alt_interface: failed
could not set alt intf 0/0: Connection timed out
open_nth_cmd_interface: open_cmd_interface failed
usrp: failed to load firmware /usr/share/usrp/rev4/std.ihx.
Traceback (most recent call last):
  File "./usrp_benchmark_usb.py", line 106, in 
main ()

  snip.


Just to rule out a flakey cable, can you try using a different USB 2 
cable?


Eric 



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

[Discuss-gnuradio] Is WUBI (Lucid) a viable environment for GNU-Radio (3.2.2) ?

2010-09-21 Thread John Shields

I recently purchased a USRP and have a fresh install of WUBI (HP Pavillion DV5 
, Windows Home Vista) and used gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall 
to install things. 

I passed 'make check' correctly

I have my username in the group usrp

j...@ubuntu:~/gnuradio$ ls -lR /dev/bus/usb | grep usrp
crw-rw 1 root usrp 189, 132 2010-09-21 11:14 005

when I execute ./usrp_benchmark_usb.py I get:


Testing 2MB/sec... gr_vmcircbuf_createfilemapping: createfilemapping is not 
available
/home/john/.gnuradio/prefs/gr_vmcircbuf_default_factory: Permission denied
uUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuOuUuOuUuOuUuOuUuOuUuOuUuOuU^Z


and it hangs so I kill it

[1]+  Stopped ./usrp_benchmark_usb.py

I cannot repeat this operation as I get

Testing 2MB/sec... usrp_open_interface:usb_set_alt_interface: failed
could not set alt intf 0/0: Connection timed out
open_nth_cmd_interface: open_cmd_interface failed
usrp: failed to load firmware /usr/share/usrp/rev4/std.ihx.
Traceback (most recent call last):
  File "./usrp_benchmark_usb.py", line 106, in 
main () 

  snip.


unless I move the USRP to a new USB port in which case I get the first symptom 
again

I have seen similar posts elsewhere re: issues with USB ports, Python  and 
VirtualBox

so my question is has anyone been able to run GNURADIO on WUBI?

Kind Regards,


Slainte,

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

46 matches

Mail list logo