[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Control Port Thrift Issues
|
From: |
Marcus Müller |
|
Subject: |
Re: [Discuss-gnuradio] Control Port Thrift Issues |
|
Date: |
Thu, 14 Sep 2017 19:31:36 +0200 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
OK, so we'll tackle this headon :)
So, we'll need to talk about the specific GNU Radio version you're
compiling, the exact-as-possible thrift version. Maybe also the
OS/distro version.
Admittedly, I'm at GRCon right now, and it might be minimally
non-trivial to just set up a container/VM to reproduce, but maybe
looking at the code alone suffices!
Best regards,
Marcus
On 09/14/2017 02:17 PM, Mark Koenig wrote:
> Hi Marcus,
>
> I do believe I need control ports active. I am using GNUradio as the
> framework for some code that I believe uses control ports.
>
> Mark
>
>
> On 9/14/17, 3:10 AM, "Discuss-gnuradio on behalf of address@hidden"
> <address@hidden on behalf of address@hidden> wrote:
>
> Send Discuss-gnuradio mailing list submissions to
> address@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> or, via email, send a message with subject or body 'help' to
> address@hidden
>
> You can reach the person managing the list at
> address@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnuradio digest..."
>
>
> Today's Topics:
>
> 1. How to create uhd's time_spec_t from Python (Piotr Krysik)
> 2. Re: Control Port Thrift Issues (Marcus M?ller)
> 3. Re: How to create uhd's time_spec_t from Python (Marcus M?ller)
> 4. Re: Synchronisation (John Shields)
> 5. [SOCIS '17] GRC C++ Output: Week 7 (H?kon V?gsether)
> 6. Time sinks out of sync after adding and removing noise in
> simple FSK simulation (James Wanga)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 13 Sep 2017 19:08:36 +0200
> From: Piotr Krysik <address@hidden>
> To: GNURadio Discussion List <address@hidden>
> Subject: [Discuss-gnuradio] How to create uhd's time_spec_t from
> Python
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=utf-8
>
> Hi All,
>
> time_spec_t is a class representing time in UHD. It uses time_t (long
> int) for representing full seconds and double for parts of a second.
> This format of time is usable to tell USRPs when to do certain tasks. It
> is also very usable for operations on time without loosing precision.
>
> In c++ time_spec_t can be constructed from time represented by a double
> (not precise if number of full seconds is large) or from time_t and
> double. Both constructors are exposed by SWIG in Python.
>
> When I construct time_spec from double everything is fine:
>
> >>> from gnuradio import uhd
> >>> uhd.time_spec(10)
>
> But when I construct from int and float I get an error:
>
> >>> uhd.time_spec(10,0.1)
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
> 1576, in __init__
> this = _uhd_swig.new_time_spec_t(*args)
> NotImplementedError: Wrong number or type of arguments for overloaded
> function 'new_time_spec_t'.
> Possible C/C++ prototypes are:
> uhd::time_spec_t::time_spec_t(double)
> uhd::time_spec_t::time_spec_t(time_t,double)
> uhd::time_spec_t::time_spec_t(time_t,long,double)
>
> Somehow Python's integer is not recognized as compatible with time_t
> parameter in the second constructor
> (uhd::time_spec_t::time_spec_t(time_t,double) ).
>
> My question:
> Is there a way to use time_spec_t's constructor
> uhd::time_spec_t::time_spec_t(time_t,double) from Python interface
> exposed by GNU Radio? In my opinion there should be, otherwise why to
> expose it through SWIG.
>
> --
> Best Regards,
> Piotr Krysik
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 13 Sep 2017 19:54:47 +0200
> From: Marcus M?ller <address@hidden>
> To: address@hidden
> Subject: Re: [Discuss-gnuradio] Control Port Thrift Issues
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="windows-1252"
>
> Hi Mark,
>
> We can look at that in-depth, but in spirit of keeping this as
> time-effective as possible for you: Do you *need* controlport (it's a
> system to remotely access statistics and specifics knobs and levers in
> GNU Radio)? Many (most) users don't really.
>
> Best regards,
>
> Marcus
>
>
> On 09/13/2017 04:41 PM, Mark Koenig wrote:
> >
> > I am seeing an error during ?Make? and it has to do with the
> > controlport and thrift?.not sure what is going on. Any help would be
> > appreciated.
> >
> >
> >
> > Thanks
> >
> >
> >
> > Mark
> >
> >
> >
> >
> >
> > After running ?Make? I see the following error:
> >
> >
> >
> > [ 11%] Building CXX object
> >
> gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/controlport/thrift/rpcserver_booter_thrift.cc.o
> >
> >
> /usr/local/truearrow_6_0_0_0/deploypkg/target/src/gnuradio/gnuradio-runtime/lib/controlport/thrift/rpcserver_booter_thrift.cc:
> > In member function ?bool thrift_application_base<TserverBase,
> > TserverClass>::application_started()?:
> >
> >
> /usr/local/truearrow_6_0_0_0/deploypkg/target/src/gnuradio/gnuradio-runtime/lib/controlport/thrift/rpcserver_booter_thrift.cc:117:78:
> > error: ?class apache::thrift::transport::TServerSocket? has no member
> > named ?getPort?
> >
> > int used_port =
> > ((apache::thrift::transport::TServerSocket*)thetransport)->getPort();
> >
> >
>
> > ^
> >
> > make[2]: ***
> >
> [gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/controlport/thrift/rpcserver_booter_thrift.cc.o]
> > Error 1
> >
> > make[1]: ***
> > [gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/all] Error 2
> >
> > make: *** [all] Error 2
> >
> >
> >
> > I don?t get any errors during cmake, my ouput is below.
> >
> >
> >
> > -- ######################################################
> >
> > -- # Gnuradio enabled components
> >
> > -- ######################################################
> >
> > -- * python-support
> >
> > -- * testing-support
> >
> > -- * volk
> >
> > -- * doxygen
> >
> > -- * sphinx
> >
> > -- * gnuradio-runtime
> >
> > -- * gr-ctrlport
> >
> > -- * * thrift
> >
> > -- * gr-blocks
> >
> > -- * gnuradio-companion
> >
> > -- * gr-fec
> >
> > -- * gr-fft
> >
> > -- * gr-filter
> >
> > -- * gr-analog
> >
> > -- * gr-digital
> >
> > -- * gr-dtv
> >
> > -- * gr-atsc
> >
> > -- * gr-audio
> >
> > -- * * alsa
> >
> > -- * * oss
> >
> > -- * gr-channels
> >
> > -- * gr-noaa
> >
> > -- * gr-pager
> >
> > -- * gr-qtgui
> >
> > -- * gr-trellis
> >
> > -- * gr-uhd
> >
> > -- * gr-utils
> >
> > -- * gr-video-sdl
> >
> > -- * gr-vocoder
> >
> > -- * gr-fcd
> >
> > -- * gr-wavelet
> >
> > -- * gr-wxgui
> >
> > -- * gr-zeromq
> >
> > --
> >
> > -- ######################################################
> >
> > -- # Gnuradio disabled components
> >
> > -- ######################################################
> >
> > -- * gr-comedi
> >
> > --
> >
> > -- Using install prefix: /usr/local/truearrow_6_0_0_0/deploypkg/target
> >
> > -- Building for version: 3.7.10.1 / 3.7.10.1
> >
> > -- Configuring done
> >
> > -- Generating done
> >
> > -- Build files have been written to:
> > /usr/local/truearrow_6_0_0_0/deploypkg/target/src/gnuradio/build
> >
> >
> >
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170913/73fcdd25/attachment.html>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 13 Sep 2017 20:13:01 +0200
> From: Marcus M?ller <address@hidden>
> To: address@hidden
> Subject: Re: [Discuss-gnuradio] How to create uhd's time_spec_t from
> Python
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=windows-1252
>
> Hi Piotr,
>
> uhd.time_spec.from_ticks(full_ticks_as_int, ticks_per_second_as_float)
> does the trick for me, usually. You can make one time_spec with
> from_ticks(12, 1.0f) that is exactly 12 full seconds, and then add a
> second one that has 0 full_secs, and a double fractional seconds.
>
> Personally, I'm not overly happy about the fractional part of the
> time_spec being double ? that means that we waste a lot of the bits of a
> double on exponents that never occur, and also that we're getting
> different resolutions around 1.0000001 and 1.9000001. But it's like it
> is, and it, in practice, works pretty well :)
>
> Best regards,
>
> Marcus
>
>
> On 09/13/2017 07:08 PM, Piotr Krysik wrote:
> > Hi All,
> >
> > time_spec_t is a class representing time in UHD. It uses time_t (long
> > int) for representing full seconds and double for parts of a second.
> > This format of time is usable to tell USRPs when to do certain tasks. It
> > is also very usable for operations on time without loosing precision.
> >
> > In c++ time_spec_t can be constructed from time represented by a double
> > (not precise if number of full seconds is large) or from time_t and
> > double. Both constructors are exposed by SWIG in Python.
> >
> > When I construct time_spec from double everything is fine:
> >
> >>>> from gnuradio import uhd
> >>>> uhd.time_spec(10)
> > But when I construct from int and float I get an error:
> >
> >>>> uhd.time_spec(10,0.1)
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in <module>
> > File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
> > 1576, in __init__
> > this = _uhd_swig.new_time_spec_t(*args)
> > NotImplementedError: Wrong number or type of arguments for overloaded
> > function 'new_time_spec_t'.
> > Possible C/C++ prototypes are:
> > uhd::time_spec_t::time_spec_t(double)
> > uhd::time_spec_t::time_spec_t(time_t,double)
> > uhd::time_spec_t::time_spec_t(time_t,long,double)
> >
> > Somehow Python's integer is not recognized as compatible with time_t
> > parameter in the second constructor
> > (uhd::time_spec_t::time_spec_t(time_t,double) ).
> >
> > My question:
> > Is there a way to use time_spec_t's constructor
> > uhd::time_spec_t::time_spec_t(time_t,double) from Python interface
> > exposed by GNU Radio? In my opinion there should be, otherwise why to
> > expose it through SWIG.
> >
> > --
> > Best Regards,
> > Piotr Krysik
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 13 Sep 2017 19:44:41 +0000
> From: John Shields <address@hidden>
> To: address@hidden
> Cc: Derek Kozel <address@hidden>, GNURadio Discussion List
> <address@hidden>, Discuss-gnuradio
> <address@hidden>
> Subject: Re: [Discuss-gnuradio] Synchronisation
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> 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, address@hidden 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 <address@hidden
> >>> <mailto:address@hidden>> 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
> >>>>> <address@hidden <mailto:address@hidden>> 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
> >>>>> address@hidden <mailto:address@hidden>
> >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
> >>>>>
> >>>>> --
> >>>>> Very Respectfully,
> >>>>> Dan CaJacob
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Discuss-gnuradio mailing list
> >>>>> address@hidden <mailto:address@hidden>
> >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Discuss-gnuradio mailing list
> >>>> address@hidden <mailto:address@hidden>
> >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
> >>>
> >>>
> >>> _______________________________________________
> >>> Discuss-gnuradio mailing list
> >>> address@hidden <mailto:address@hidden>
> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
> >>>
> >>
> >> _______________________________________________
> >> Discuss-gnuradio mailing list
> >> address@hidden <mailto:address@hidden>
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170913/99e78475/attachment.html>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 13 Sep 2017 23:20:45 +0200
> From: H?kon V?gsether <address@hidden>
> To: GNURadio Discussion List <address@hidden>
> Subject: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 7
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> I was on holiday the previous week, but I have created a poster which I
> have included in my latest blog post. You can read more at:
>
> https://grccpp.wordpress.com/
>
> Best regards,
> H?kon V?gsether
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170913/e4f0a7b9/attachment.html>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 14 Sep 2017 00:08:47 -0700
> From: James Wanga <address@hidden>
> To: address@hidden
> Subject: [Discuss-gnuradio] Time sinks out of sync after adding and
> removing noise in simple FSK simulation
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="utf-8"
>
> Hello.
>
> I?m quite new to both SDR and Gnuradio an have been learning by exploring
> naive simulations. I recently decided to simulate an FSK modulation scheme
> with a constant source, a noice source and 2 time sinks. The first time sink
> is pre-modulation and the second is post-modulation. When I first start the
> simulation, both time sinks display the same waveform as expected. When I add
> a strong noise signal in real time via a GUI entry the post-modulation time
> sink displays a randomly changing waveform again, as expected. However, when
> I reduce the noise source to 0, the post-modulated sink stabilizes to match
> the pre-modulated sink except that it is translated arbitrarily to the left
> or right. this causes an arbitrary byte to be spit out when the bits are
> repacked. I?m sure I?m missing some basic concept that will make this make
> sense. can someone point me to my oversight? Thank you.
>
> I?ve attached screenshots of my flow graph and the sink outputs.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170914/5101167b/attachment.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Screen Shot 2017-09-13 at 11.39.16 PM.png
> Type: image/png
> Size: 371830 bytes
> Desc: not available
> URL:
> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170914/5101167b/attachment.png>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Screen Shot 2017-09-13 at 11.37.36 PM.png
> Type: image/png
> Size: 396655 bytes
> Desc: not available
> URL:
> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170914/5101167b/attachment-0001.png>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Screen Shot 2017-09-13 at 11.37.08 PM.png
> Type: image/png
> Size: 369829 bytes
> Desc: not available
> URL:
> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170914/5101167b/attachment-0002.png>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Screen Shot 2017-09-13 at 11.36.41 PM.png
> Type: image/png
> Size: 164211 bytes
> Desc: not available
> URL:
> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170914/5101167b/attachment-0003.png>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ------------------------------
>
> End of Discuss-gnuradio Digest, Vol 179, Issue 13
> *************************************************
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio