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 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. 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 <marcus.muel...@ettus.com> To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Control Port Thrift Issues Message-ID: <25f98175-1668-5048-eff8-ce4460f1d...@ettus.com> 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 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 ------------------------------ Message: 2 Date: Thu, 14 Sep 2017 14:10:27 -0700 From: Balint Seeber <balint...@gmail.com> To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Tonight: Cyberspectrum Software Defined Radio Meetup (San Diego, Thu Sept 14th, 6:30PM PT) Message-ID: <cad39kuwsxrsxqsxdfzcjsenpcqrvmmm283emyzp3pljaqys...@mail.gmail.com> 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 <jwa...@gmail.com> To: Kevin Reid <kpr...@switchb.org> Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Time sinks out of sync after adding and removing noise in simple FSK simulation Message-ID: <bb3eeb68-4a9f-4b85-9d96-b19b24b53...@gmail.com> 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 <kpr...@switchb.org> wrote: > >> On Thu, Sep 14, 2017 at 12:08 AM, James Wanga <jwa...@gmail.com> 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 <kramare...@yahoo.com> To: GNURadio Discussion List <discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] Recent change in destructor behavior? Message-ID: <787202790.2560353.1505445982...@mail.yahoo.com> 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 <tom.n...@gmail.com> 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 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/20170915/2f7cd29c/attachment.html> ------------------------------ 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 15 ************************************************* _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio