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
discuss-gnuradio-requ...@gnu.org"
<discuss-gnuradio-bounces+mark.koenig=iubelttechnologies....@gnu.org on behalf
of discuss-gnuradio-requ...@gnu.org> wrote:
Send Discuss-gnuradio mailing list submissions to
discuss-gnuradio@gnu.org
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
discuss-gnuradio-requ...@gnu.org
You can reach the person managing the list at
discuss-gnuradio-ow...@gnu.org
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 <per...@o2.pl>
To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
Subject: [Discuss-gnuradio] How to create uhd's time_spec_t from
Python
Message-ID: <7edcc791-5aa7-908a-58ae-3e306580c...@o2.pl>
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 <marcus.muel...@ettus.com>
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Control Port Thrift Issues
Message-ID: <26b13e91-3b19-c721-4f0c-ae6c16856...@ettus.com>
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
> Discuss-gnuradio@gnu.org
> 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 <marcus.muel...@ettus.com>
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] How to create uhd's time_spec_t from
Python
Message-ID: <3153b7b2-8125-b1c4-18e8-eaaae3841...@ettus.com>
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
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 4
Date: Wed, 13 Sep 2017 19:44:41 +0000
From: John Shields <sla1nte2...@gmail.com>
To: mle...@ripnet.com
Cc: Derek Kozel <derek.ko...@ettus.com>, GNURadio Discussion List
<discuss-gnuradio@gnu.org>, Discuss-gnuradio
<discuss-gnuradio-bounces+mleech=ripnet....@gnu.org>
Subject: Re: [Discuss-gnuradio] Synchronisation
Message-ID: <92578a50-539b-e303-a287-d16fd2f77...@gmail.com>
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, 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 <sla1nte2...@gmail.com
>>> <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
>>>>> <sla1nte2...@gmail.com <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 <mailto:Discuss-gnuradio@gnu.org>
>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>>>>>
>>>>> --
>>>>> Very Respectfully,
>>>>> Dan CaJacob
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Discuss-gnuradio mailing list
>>>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing list
>>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
>> 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 <hauk...@gmail.com>
To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
Subject: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 7
Message-ID:
<caoyndbrg6dzvzj5gz+vamtrs8ej+srytyjtxy+hfu0vi_5m...@mail.gmail.com>
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 <jwa...@gmail.com>
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Time sinks out of sync after adding and
removing noise in simple FSK simulation
Message-ID: <6ef42589-cdc9-4b97-b127-32b78e611...@gmail.com>
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
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
End of Discuss-gnuradio Digest, Vol 179, Issue 13
*************************************************
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
