[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Control Port Thrift Issues
|
From: |
Mark Koenig |
|
Subject: |
Re: [Discuss-gnuradio] Control Port Thrift Issues |
|
Date: |
Mon, 18 Sep 2017 12:20:37 +0000 |
Marcus,
I am using CentOS 7.2, Thrift 0.9.2 and GNU 3.7.11.
Mark
On 9/15/17, 12:02 PM, "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. Re: Control Port Thrift Issues (Marcus M?ller)
2. Tonight: Cyberspectrum Software Defined Radio Meetup (San
Diego, Thu Sept 14th, 6:30PM PT) (Balint Seeber)
3. Re: Time sinks out of sync after adding and removing noise in
simple FSK simulation (James Wanga)
4. Re: Recent change in destructor behavior? (Dmitry Kramarev)
----------------------------------------------------------------------
Message: 1
Date: Thu, 14 Sep 2017 19:31:36 +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
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
------------------------------
Message: 2
Date: Thu, 14 Sep 2017 14:10:27 -0700
From: Balint Seeber <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Tonight: Cyberspectrum Software Defined
Radio Meetup (San Diego, Thu Sept 14th, 6:30PM PT)
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
Dear all,
Announcing the the 22nd #cyberspectrum special meetup tonight, during this
exciting week of #GRCon17, from 6:30 PM in San Diego at Qualcomm.
For those that wish to try car pooling, please meet at the GRCon hotel
lobby at 6 PM.
For those unable to attend the event in person, you can live stream it
here: https://www.youtube.com/watch?v=u1RA8eScOIs
There's also IRC: #cyberspectrum on Freenode.
Full details, including the speaker lineup/topics, are here:
https://www.meetup.com/Cyberspectrum/events/243307509/
Don't forget all our videos are here: https://www.youtube.com/
playlist?list=PLPmwwVknVIiXGzKhtimTMjhcyppeRRsnE
...and materials here: http://www.meetup.com/Cyberspectrum/about/
For updates before, and photos during the event: https://twitter.com/spe
nchdotnet
Please support Cyberspectrum by submitting a talk, requesting a
topic/presenters, or spreading the word about us!
If you would like to learn more about setting one up, please get in touch.
(Anyone on the US East Coast?)
If you're not familiar with Cyberspectrum: "The Bay Area SDR Meetup will
serve as a forum to exchange knowledge and ideas related to Software
Defined Radio (the software and hardware), and generally aim to get people
excited about all the applications that can be realised with the
technology. At each meetup, attendees will have the opportunity to present
their work/ideas to the group. Engineers, enthusiasts, hobbyists and people
of all experience levels are welcome, no matter what your software/hardware
background."
As always, if you would like to present at a future event about a project
you're working on, or something interesting you've discovered, please get
in touch!
Stay tuned and hope to see you there,
Balint
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170914/449ad444/attachment.html>
------------------------------
Message: 3
Date: Thu, 14 Sep 2017 15:06:46 -0700
From: James Wanga <address@hidden>
To: Kevin Reid <address@hidden>
Cc: address@hidden
Subject: Re: [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="us-ascii"
That's really helps me understand what's happening, thank you. I'm curious
if this can be solved by sending packets instead of raw bytes. Is it correct to
assume that sequence detection is one of the responsibilities of a packet
decoder? I'm also curious if I there is any advantage to using a clock recovery
block and binary slicer instead of the monolithic GFSK demod block? Stated
another way. Is the GFSK demod block just a quadrature demod, clock recovery,
and binary slicer rolled into one?
Another thought is, once you loose symbol timing, do I need to then
dynamically tweak the clock recovery settings (like mu) in order to realign?
James Wanga
> On Sep 14, 2017, at 7:20 AM, Kevin Reid <address@hidden> wrote:
>
>> On Thu, Sep 14, 2017 at 12:08 AM, James Wanga <address@hidden> wrote:
>> 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.
>
> This is not an effect of your simulation but an actual problem in digital
communication.
>
> When you introduce noise, the GFSK Demod loses track of the actual symbol
timing and so its estimate drifts freely. When you remove the noise, it locks
on again starting at who-knows-what symbol out of your 8-symbol groups. The
same problem would occur in a real receiver which does not share a clock with
the transmitter, because you start in the no-information state.
>
> If you want to recover properly aligned bytes (or packets, even) you need
a way to detect where one begins. This is usually done with a known sequence of
symbols at the beginning of a transmission. Unfortunately, I don't have
experience with the digital blocks available in GNU Radio so I cannot tell you
how to construct a working example.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170914/9f8c8685/attachment.html>
------------------------------
Message: 4
Date: Fri, 15 Sep 2017 03:26:22 +0000 (UTC)
From: Dmitry Kramarev <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Recent change in destructor behavior?
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"
I have the same problem with GNU Radio 3.7.11.1 when the generate options
of the top block are set to QT GUI.
After I change the generate options to WX GUI, the destructor prints
everything well.Don't know why, but it works like this on my PC.
On Tuesday, October 6, 2015 5:23 AM, Tom McDermott <address@hidden>
wrote:
My OOT module prints some statistics upon closing of the flowgraph from
GRC.This is implemented with printf(stderr) in the destructor for my module.
GRC --> IMPL constructed by Make --> constructs one of my objects.
This worked well through all versions of gnuradio until about last week.Now
the printf() never shows in the GRC console after a rebuild of 3.7.9.git,the
version that introduced per-flowgraph QSS support (which appearedbroken as of
last weekend).
printf(stderr) prior to the start of flowgraph shutown still works fine.
It's justthe one in the destructor that seems no longer to print.
Is there a recent change that would explain this, or is printf() in a
destructorbad practice?
-- Tom, N5EG
_______________________________________________
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/20170915/2f7cd29c/attachment.html>
------------------------------
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 15
*************************************************