USRP b210 time stamp corrupted with two-channel receive
Hi, I am using an Ettus B210 in two-channel receive and require accurate time stamps. The B210 is connected to an external 10 MHz clock and PPS source. Setting the time on the B210 works fine, and reading back the time reports the expected time. When streaming a single channel, everything works as expected, and if I read back the time after ending the stream, the time reported by the USRP is correct. The time in the hdr metadata files is correct as well. /2022-04-29 13:39:02.117 | INFO | __main__:start:317 - Before stream start: system time 1651203542.1179564 usrp time 1651203542.0 (2022-04-29 13:39:02.00) 2022-04-29 13:39:02.118 | WARNING | __main__:start:329 - Starting recording immediately 2022-04-29 13:39:02.118 | INFO | __main__:start:331 - Calling start() 2022-04-29 13:39:02.119 | INFO | __main__:start:335 - Time after issuing start stream command: 1651203542.1197705 usrp time 1651203542.0 (2022-04-29 13:39:02.00) / When streaming two channels, the setup works fine, but after the top_block.start() command is issued, the time read back is somehow the current time stamp multiplied by 2. The time in the hdr metadata files has the first time stamp being the time stamp around calling top_block.start() multiplied by 2. It however increments properly (from the corrupted origin) when counting the samples. /2022-04-29 13:39:20.120 | INFO | __main__:start:317 - Before stream start: system time 1651203560.1199565 usrp time 1651203560.0 (2022-04-29 13:39:20.00) 2022-04-29 13:39:20.120 | WARNING | __main__:start:329 - Starting recording immediately 2022-04-29 13:39:20.120 | INFO | __main__:start:331 - Calling start() 2022-04-29 13:39:22.012 | INFO | __main__:start:335 - Time after issuing start stream command: 1651203562.012672 usrp time 3302407122.0 (2074-08-25 17:18:42.00) /Where /3302407122//= //1651203560///*2 + 2// I have tested this with both UHD 4.1 and UHD 4.2. GNU radio version: 3.8.0.0 (Python 3.8.10) Is anyone on this mailing list familiar with the issue and have a solution/workaround for this? I have attached log output and a not so small MWE Thanks, -- Edwin Peters (PhD,MEng) Research Fellow - UNSW Canberra Space Single channel recording 2022-04-29 13:38:58.358 | INFO | __main__:__init__:165 - USRPS: [{'usrp': , 'n_channels': 1, 'antenna': 'RX2', 'serial': '3136D4B', 'config': {'serial': '3136D4B', 'subdev': 'A:A', 'args': 'recv_frame_size=1032, num_recv_frames=5120', 'antenna': 'RX2'}}] 2022-04-29 13:38:58.359 | DEBUG| __main__:__init__:166 - settings: {'Fc_hz': 43700.0, 'Fs_hz': 50.0, 'gain_dB': 45, 'NID': 666, 'file_name': '', 'file_path': '/media/rf_data/recordings', 'antenna': 'RX2', 'pps_present': True, 'test_dev_null': False, 'usrps': [{'serial': '3136D4B', 'subdev': 'A:A', 'args': 'recv_frame_size=1032, num_recv_frames=5120', 'antenna': 'RX2'}]} 2022-04-29 13:38:58.359 | DEBUG| __main__:__init__:174 - USRP {'usrp': , 'n_channels': 1, 'antenna': 'RX2', 'serial': '3136D4B', 'config': {'serial': '3136D4B', 'subdev': 'A:A', 'args': 'recv_frame_size=1032, num_recv_frames=5120', 'antenna': 'RX2'}}: Setting clock source to external and time source to external 2022-04-29 13:38:58.775 | INFO | __main__:__init__:180 - Clock ref locked True 2022-04-29 13:38:58.775 | DEBUG| __main__:__init__:183 - 0 antenna RX2 gain 45 2022-04-29 13:38:58.777 | DEBUG| __main__:__init__:206 - 1 2022-04-29 13:38:59.779 | WARNING | __main__:__init__:222 - syncing time -- If this hangs, please verify that an external pps is configured 2022-04-29 13:38:59.780 | DEBUG| __main__:sync_clock:244 - USRP0 time 1.316781625 1970-01-01 10:00:01.316782 2022-04-29 13:39:00.083 | INFO | __main__:sync_clock:258 - USRP 3136D4B -- Successfully synced USRP GPS time in 1 attempts 2022-04-29 13:39:00.084 | INFO | __main__:__init__:224 - verifying time 2022-04-29 13:39:01.010 | INFO | __main__:check_clock:275 - USRP0 time 1651203541.0 2022-04-29 13:39:01.00 2022-04-29 13:39:01.010 | WARNING | __main__:check_clock:280 - All USRP clocks in sync (to the second) 2022-04-29 13:39:02.011 | DEBUG| __main__:__init__:229 - tune the USRPs 2022-04-29 13:39:02.117 | DEBUG| __main__:__init__:231 - done 2022-04-29 13:39:02.117 | INFO | __main__::353 - start recording 2022-04-29 13:39:02.117 | INFO | __main__:start:317 - Before stream start: system time 1651203542.1179564 usrp time 1651203542.0 (2022-04-29 13:39:02.00) 2022-04-29 13:39:02.118 | WARNING | __main__:start:329 - Starting recording immediately 2022-04-29 13:39:02.118 | INFO | __main__:start:331 - Calling start() 2022-04-29 13:39:02.119 | INFO | __main__:start:335 - Time after issuing start stream command: 1651203542.1197705 usrp time 1651203542.0 (2022-04-29 13:39:02.00) 2022-04-29 13:39:04.894 | WARNING | __main__::363 - verifying clock after recording 2022-04-29 13:39:05.011 | INFO | __main__:check_clock:275
Re: [Discuss-gnuradio] help
Hi Aruna, I’m not an expert, but I guess you haven’t set your DCMAKE_INSTALL_PREFIX to your GNURadio prefix. Here is what you may try: Use setup_env.sh to setup the environment Go to the gr-ieee802-11/build/ folder(I assume you have a build folder) Delete everything in the build folder In the build folder, run cmake -DCMAKE_INSTALL_PREFIX= your gnuradio install prefix .. Then run make and make install Do the same thing with gr-foo. Hope this solves your problem. Regards, Edwin Sent from Mail for Windows 10 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Calling public C++ function in OOT module using Python --GRC testcase created
Hi Michael, Since you said you did not have the problem I mentioned, I guess the change is not written into the GNURadio. So I uninstall the module, re-make it, re-installed it. After some adjustment about the vector size, it worked! Thank you so much for shedding light on me! Regards, Edwin On Wed, 1 Aug 2018 at 14:18 Michael Dickens wrote: > Hi Edwin - You're welcome for the compatibility notes. Your changes work > for me out of the box now, so: well done & keep it up! > > OK so a few things: > > (1) when I execute the GRC script you mention (as checked into your repo), > I see the following: > {{{ > Generating: > '/Users/mlk/Desktop/TMP/gr-chaos/chaotic_prefix_generator_template.py' > >>> Warning: This flow graph may not have flow control: no audio or RF > hardware blocks found. Add a Misc->Throttle block to your flow graph to > avoid CPU congestion. > > Executing: /opt/local/Library/Frameworks/ > Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python > -u /Users/mlk/Desktop/TMP/gr-chaos/chaotic_prefix_generator_template.py > > Traceback (most recent call last): > File > "/Users/mlk/Desktop/TMP/gr-chaos/chaotic_prefix_generator_template.py", > line 218, in > main() > File > "/Users/mlk/Desktop/TMP/gr-chaos/chaotic_prefix_generator_template.py", > line 206, in main > tb = top_block_cls(Init=options.Init, > Map_parameter=options.Map_parameter, spreading_gain=options.spreading_gain, > sps=options.sps) > File > "/Users/mlk/Desktop/TMP/gr-chaos/chaotic_prefix_generator_template.py", > line 87, in __init__ > self.blocks_vector_source_x_0 = > blocks.vector_source_c(chaos.chaotic_prefix_bc(0.8,3.98,50,'len_tag_key'), > False, 1, []) > File "/opt/local/Library/Frameworks/ > Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/blocks/blocks_swig1.py", > line 1531, in make > return _blocks_swig1.vector_source_c_make(*args, **kwargs) > TypeError: in method 'vector_source_c_make', argument 1 of type > 'std::vector< gr_complex,std::allocator< gr_complex > > const &' > }}} > > which doesn't have the issue you're having ... but, this leads to the next > item: > > (2) The method "chaotic_prefix_bc_impl::Logistic_map" returns as > "std::vector", while in your GRC script you've made the vector > source and file sink both complex ... correcting that helps but doesn't > solve the issue because ... > > (3) "chaotic_prefix_bc_impl::Logistic_map" is a method in a class, not a > function; it is meant to be called from some instantiation of the class, > not directly like a function as you're doing in the GRC script. You can > make it a static function inside the class & then what you're doing might > work; might take some special SWIG sauce to get working. > > Hope this is useful. - MLD > > On Wed, Aug 1, 2018, at 3:40 PM, Edwin Li wrote: > > Hi Michael, > > Wow! Thanks for pointing out the compatibility issue in my DCSK block. I > will modify that according to your suggestion. > I added chaotic_prefix_generator_template.grc > <https://github.com/lbyhp/gr-chaos/blob/master/chaotic_prefix_generator_template.grc> > to > my repository. I use it to test. > Inside there is a vector source. I tried to set the data as the output of > Logistic_map(). You will see an error: 'chaotic_prefix_bc_sptr' object has > no attribute 'Logistic_Map' > > Regards, > Edwin > > > > On Wed, 1 Aug 2018 at 12:59 Michael Dickens > wrote: > > Hi Edwin - Is there a test or example in your repo that's failing? I have > built it successfully; "make test" fails for a couple reasons but not for > the specific issue you're having. I don't see any specific use of the > method you're having issues with; hence my query. - MLD > > On Wed, Aug 1, 2018, at 2:22 PM, edwin wrote: > > Hi Michael, > > > > Thank you so much for your reply. > > > > I did add the method after building SWIG for the first time. And I have > > tried "make clean" in build/ and make again. I even tried deleting the > > entire build/ folder and CMake. Still the same problem. > > > > I created a repository if you want to have a look. > > https://github.com/lbyhp/gr-chaos > > > > Or you can tell me where to look to see whether the SWIG has made > > corresponding changes. > > > > Regards, > > > > Edwin > > > > > > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Calling public C++ function in OOT module using Python --GRC testcase created
Hi Michael, Wow! Thanks for pointing out the compatibility issue in my DCSK block. I will modify that according to your suggestion. I added chaotic_prefix_generator_template.grc <https://github.com/lbyhp/gr-chaos/blob/master/chaotic_prefix_generator_template.grc> to my repository. I use it to test. Inside there is a vector source. I tried to set the data as the output of Logistic_map(). You will see an error: 'chaotic_prefix_bc_sptr' object has no attribute 'Logistic_Map' Regards, Edwin On Wed, 1 Aug 2018 at 12:59 Michael Dickens wrote: > Hi Edwin - Is there a test or example in your repo that's failing? I have > built it successfully; "make test" fails for a couple reasons but not for > the specific issue you're having. I don't see any specific use of the > method you're having issues with; hence my query. - MLD > > On Wed, Aug 1, 2018, at 2:22 PM, edwin wrote: > > Hi Michael, > > > > Thank you so much for your reply. > > > > I did add the method after building SWIG for the first time. And I have > > tried "make clean" in build/ and make again. I even tried deleting the > > entire build/ folder and CMake. Still the same problem. > > > > I created a repository if you want to have a look. > > https://github.com/lbyhp/gr-chaos > > > > Or you can tell me where to look to see whether the SWIG has made > > corresponding changes. > > > > Regards, > > > > Edwin > > > > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Calling public C++ function in OOT module using Python --Git repository created
Hi Michael, Thank you so much for your reply. I did add the method after building SWIG for the first time. And I have tried "make clean" in build/ and make again. I even tried deleting the entire build/ folder and CMake. Still the same problem. I created a repository if you want to have a look. https://github.com/lbyhp/gr-chaos Or you can tell me where to look to see whether the SWIG has made corresponding changes. Regards, Edwin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Calling public C++ function in OOT module using Python
Hi, I've been trying to make a function in my OOT module public. The module is called chaotic_prefix_bc. I declare a pure virtual function called *Logistic_map()* in chaotic_prefix_bc.h, and overload it in chaotic_prefix_bc_impl.h and chaotic_prefix_bc_impl.cc. When I call this function in a vector source(in GNURadio) using: chaos.chaotic_prefix_bc(0.8,3.98,50,'len_tag_key').Logistic_map(0.8,3.98,50), it says 'chaotic_prefix_bc_sptr' object has no attribute 'Logistic_map'. I tried the make clean trick mentioned in the mailing list, but to no avail. I attached my code below. Please help me~ Regards, Edwin /* -*- c++ -*- */ /* * Copyright 2018 <+YOU OR YOUR COMPANY+>. * * This is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 3, or (at your option) * any later version. * * This software is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this software; see the file COPYING. If not, write to * the Free Software Foundation, Inc., 51 Franklin Street, * Boston, MA 02110-1301, USA. */ #ifndef INCLUDED_CHAOS_CHAOTIC_PREFIX_BC_IMPL_H #define INCLUDED_CHAOS_CHAOTIC_PREFIX_BC_IMPL_H #include namespace gr { namespace chaos { class chaotic_prefix_bc_impl : public chaotic_prefix_bc { private: float d_init; float d_parameter; unsigned int d_header_len; // Nothing to declare in this block. protected: int calculate_output_stream_length(const gr_vector_int _items); public: chaotic_prefix_bc_impl(float init, float parameter, unsigned int header_len, const std::string _tag_key); ~chaotic_prefix_bc_impl(); std::vector Logistic_map(float init, float parameter, unsigned int seq_len); // Where all the action really happens int work(int noutput_items, gr_vector_int _items, gr_vector_const_void_star _items, gr_vector_void_star _items); }; } // namespace chaos } // namespace gr #endif /* INCLUDED_CHAOS_CHAOTIC_PREFIX_BC_IMPL_H */ /* -*- c++ -*- */ /* * Copyright 2018 <+YOU OR YOUR COMPANY+>. * * This is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 3, or (at your option) * any later version. * * This software is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this software; see the file COPYING. If not, write to * the Free Software Foundation, Inc., 51 Franklin Street, * Boston, MA 02110-1301, USA. */ #ifdef HAVE_CONFIG_H #include "config.h" #endif #include #include "chaotic_prefix_bc_impl.h" namespace gr { namespace chaos { chaotic_prefix_bc::sptr chaotic_prefix_bc::make(float init, float parameter, unsigned int header_len, const std::string _tag_key) { return gnuradio::get_initial_sptr (new chaotic_prefix_bc_impl(init, parameter, header_len, len_tag_key)); } /* * The private constructor */ chaotic_prefix_bc_impl::chaotic_prefix_bc_impl(float init, float parameter, unsigned int header_len, const std::string _tag_key) : gr::tagged_stream_block("chaotic_prefix_bc", gr::io_signature::make(1, 1, sizeof(char)), gr::io_signature::make(1, 1, sizeof(gr_complex)), len_tag_key), d_init(init), d_parameter(parameter), d_header_len(header_len) { set_tag_propagation_policy(TPP_DONT);// dont propagate tags } /* * Our virtual destructor. */ chaotic_prefix_bc_impl::~chaotic_prefix_bc_impl() { } std::vector chaotic_prefix_bc_impl::Logistic_map(float init, float parameter, unsigned int seq_len) { //float parameter=3.62; std::vector chaotic_seq; chaotic_seq.push_back(init); float x_nn; float sum=d_init; for (int i=1;imaxabs) { maxabs=std::abs(chaotic_seq[i]); } } for (int i=0;i chaotic_float=Logistic_map(d_init, d_parameter, d_header_len); std::vector chaotic_complex; for (int i=0;i *p=_complex; memcpy((void *)out,_complex[0],d_header_len*sizeof(gr_complex)); out+=d_header_len; // Do <+signal processing+> noutput_items=d_header_len; // Tell runtime system how many output items we produced. return noutput_items; } } /* namespace chaos */ } /* nam
[Discuss-gnuradio] Tagged stream block template for python?
Dear subscribers, I just found out that you can only create *general block, sync block, decimator block and interpolator block *in python. See the official manual for reference https://www.gnuradio.org/doc/doxygen/page_python_blocks.html Is there no a tagged stream block template for python? There is a counterpart in c++. Regards, Edwin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to use the output of a hierarchical block in the symbols field in Correlation Estimator
Dear Mailing list subscribers, I'm using some self-defined packet prefix(chaotic complex numbers) in my communication system. In the receiver, I use Correlation Estimator to detect the packets. It needs to know the prefix. Since the prefix are interpolated and filtered by a root raised cosine filter, I decide to build a hierarchical block to generate the prefix for the correlation estimator. The hierarchical block alone works fine. But I can't call the block in the symbols field in correlation estimator. It shows 'module' object is not callable. It makes some sense to me. Is there a better way to do it? I prefer using existing modules since why reinvent the wheel? Thanks. Regards, Edwin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Use microphone as sound source for USRP
Hi Marcus, I doubted my way is not a good solution. Thanks for your confirmation. I'll just use the audio source. Regards, Edwin Müller, Marcus (CEL) 于2018年7月6日周五 下午3:42写道: > There's no "data rate" on these GPIO pins; you'd have to bitbang them. > Interfacing with a digital microphone won't work, as you can't ask > their binary states quick enough. > > Honest recommendation: Use anything else to connect your microphone to > your PC – if you have a microphone for which an audio driver exists, > you can directly use it in GNU Radio via the Audio Source. > > Best regards, > Marcus > > On Fri, 2018-07-06 at 13:35 -0600, Edwin Li wrote: > > Dear Mailing List Subscribers, > > > > There is an aux IO on the USRP X310 motherboard. I want to connect it > > with a microphone(Assume it outputs 12-bit digital signal that is > > compatible with the IO). I found very little information on how to > > use the IO other than the USRP manual( http://files.ettus.com/manual/ > > page_gpio_api.html). There are a few people talking about it on the > > list but their applications are very different from mine. > > > > My question is that is it possible to read values from the IO using > > GNURadio functions? How does GNURadio know the data rate of the IO? > > > > Thanks. > > > > Regards, > > Edwin > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Use microphone as sound source for USRP
Dear Mailing List Subscribers, There is an aux IO on the USRP X310 motherboard. I want to connect it with a microphone(Assume it outputs 12-bit digital signal that is compatible with the IO). I found very little information on how to use the IO other than the USRP manual( http://files.ettus.com/manual/page_gpio_api.html). There are a few people talking about it on the list but their applications are very different from mine. My question is that is it possible to read values from the IO using GNURadio functions? How does GNURadio know the data rate of the IO? Thanks. Regards, Edwin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP Underruns "UUUUU"
Hi, There are several things you can try: 1. Split the USRP sink and source to two separate flow graphs. 2. 20M sampling rate is very high. Make sure your computer can handle this rate. If not sure, just reduce the rate. 3. If any of the above does not work, you may try to run “volk_profile”. It is in “prefix/bin/” Regards, Edwin Sent from Mail for Windows 10 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM channel tap questions
Hi Bob, Thanks for your detailed explanation. I figured out the causes for non-unity channel taps in my case. One is I didn’t consider normalization. Second, it was because that the Schmidl-Cox sync has a metric plateau. Imperfect synchronization gave me the phase rotation. Regards, Edwin Sent from Mail for Windows 10 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM channel tap questions
Hi Jeff, I just found out that if I normalize these taps by the FFT number(64 in this case), they have magnitude of 1! Now my questions are: Why are there phase offset? The phase offset for each subchannel seems different. Is it because of imperfect synchronization? Regards, Edwin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM channel tap questions
Hi Jeff, Thanks for the reply. What you said about the noise makes sense. However, even if I turn the noise off, I still get the weired taps: Offset: 2112 Source: n/a Key: ofdm_sync_chan_taps Value: #[(0,0) (0,0) (0,0) (0,0) (0,0) (0,0) (35.5567,-53.2143) (-6.27313,-63.6921) (-45.255,-45.255) (-63.6921,-6.27313) (-53.2143,35.5567) (-18.5783,61.2445) (24.4919,59.1286) (56.4432,30.1695) (62.7706,-12.4858) (40.6014,-49.4729) (2.45706e-06,-64.0003) (-40.6014,-49.4729) (-62.7706,-12.4858) (-56.4432,30.1695) (-24.4919,59.1286) (18.5783,61.2445) (53.2143,35.5567) (6.36922,-0.627315) (4.52551,-4.52551) (6.27312,-63.6921) (-3.55567,-5.32143) (-6.12445,-1.85783) (-5.91286,2.44919) (-3.01695,5.64432) (1.24858,6.27706) (4.94729,4.06014) (0,0) (4.94729,-4.06014) (1.24858,-6.27706) (-3.01696,-5.64433) (-5.91286,-2.44919) (-6.12445,1.85783) (-3.55567,5.32144) (6.27312,63.6921) (4.52551,4.52551) (6.36922,0.627312) (5.32143,-3.55567) (1.85783,-6.12445) (-2.44919,-5.91286) (-5.64433,-3.01696) (-6.27706,1.24858) (-4.06014,4.94729) (-1.9985e-06,6.40003) (4.06014,4.94729) (6.27706,1.24858) (5.64432,-3.01696) (2.44918,-5.91286) (-18.5783,-61.2445) (-5.32143,-3.55567) (-6.36922,0.62731) (-4.52551,4.52551) (-0.627314,6.36921) (3.55567,5.32143) (0,0) (0,0) (0,0) (0,0) (0,0)] The piece of code you posted: for (int i = loop_start; i < loop_end; i++) { if ((d_ref_sym[i-carr_offset] != gr_complex(0, 0))) { taps[i-carr_offset] = sym[i] / d_ref_sym[i-carr_offset]; } } I believe it comes from the ofdm_chanest_vcvc_impl.cc, doesn't it? According to my understanding, it is calculating the channel taps by dividing the received symbol with the sync symbols, which are known. If the channel is perfect and there is no noise, the received symbols should be exactly the same as the sync symbols. The channel taps should be 1. Regards, Edwin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM channel tap questions
Hi all, I run the example found in the ~/prefix/share/gnuradio/examples/digital/ofdm/rx_ofdm.grc. The ofdm signals can be decoded correctly. But I don't understand the channel taps. The channel taps are shown to be Key: ofdm_sync_chan_taps Value: #[(0,0) (0,0) (0,0) (0,0) (0,0) (0,0) (64.2159,-3.65375) (47.2264,-42.4505) (8.44977,-62.8107) (-32.7931,-54.5247) (-59.9085,-21.3488) (-59.8031,23.3288) (-32.3382,55.4137) (9.05079,63.8184) (46.331,42.7923) (65.1778,2.83559) (51.1081,-38.6363) (15.815,-62.1237) (-27.1419,-57.8722) (-58.2753,-27.4043) (-62.3711,15.658) (-37.9986,51.1873) (3.2302,64.2116) (5.44772,5.36124) (6.75629,1.41069) (54.079,-33.4137) (2.19591,-6.12473) (-1.91544,-6.56722) (-5.87699,-3.166) (-6.83039,0.994718) (-4.49682,5.42143) (-0.363706,6.79664) (0,0) (6.653,1.39701) (6.73628,-2.57781) (2.83963,-6.40383) (-1.3027,-7.62756) (-5.2442,-4.20318) (-7.30496,-0.464149) (-46.0595,43.0102) (-1.1131,6.52395) (3.2,5.98481) (6.67649,1.87579) (6.12278,-2.4737) (3.20924,-5.88361) (-1.73027,-7.05576) (-5.08706,-4.94171) (-6.68616,-0.0110321) (-5.45217,3.92032) (-1.28323,7.08399) (3.24904,6.21134) (6.67752,2.90531) (7.18779,-1.51598) (36.8116,-51.7724) (0.146267,-7.00651) (-4.51996,-4.89137) (-7.37838,-1.41322) (-6.20339,3.98806) (-2.49422,6.80633) (0,0) (0,0) (0,0) (0,0) (0,0)] This is weired. The channel is just AWGN. Why are not the channel taps 1? I found the same question posted before. https://lists.gnu.org/archive/html/discuss-gnuradio/2017-05/msg00057.html. But didn't see the answer. I'm running GNU Radio Companion 3.7.12 by the way. The example can be found in the attachment. Regards, Edwin rx_ofdm.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Update 2: BPSK problem: intermittent inter-symbol interference--Answer about the burst shaper and SPS
Hi Marcus, To be honest with you, I have the burst shaper because the examples I found in /gr-digital/examples/packets have it. I guess it would be helpful if my packets are short. But I don't really have to restrict my packets to be short. All I have in mind is compare the BPSK BER curve on USRP with the theoretical one. If long packets can solve the problem. I'll go with long. It seems that you and your colleague believe the intermittent ISI comes from the burst shaper? I'll try removing the block and see what happens. I have the sample-per-symbol being 2 because I read it somewhere in the tutorial that 2 is practical. Larger number would give higher SNR but at a higher computational cost. I tried 4. There would be a higher chance of getting the intermittent ISI. Could it be the computational power that throttles the performance? But my CPU usage is only about 50% when running the simulation. However, I get quite a lot underruns if an USRP sink is activated. I use 1G Ethernet to connect the USRP. The sample rate is only 800K. Regards, Edwin Marcus Müller <muel...@kit.edu>于2017年9月1日周五 上午5:37写道: > Wow! Now, that is a flowgraph that's really pretty! Thanks! Will have a > look at it! > > On 08/31/2017 10:58 PM, Edwin Li wrote: > > Hi Marcus, > > I'm sorry. That was very inconsiderate of me. I made a new grc file, > merging the tx and rx into one. You can find it in the attachment. > > I want to make sure the system works with an ideal channel. But I still > have the intermittent ISI problem. > > Figure 1 Down sampled > signal > As you can see in Figure 1. There are 5 spots with severe ISI, while > others are good. > >Figure 2 Packet with > severe ISI > Figure 2 shows the zoom in of Figure 1. How can one packet gets so much > ISI while others are good? If my RRC filters have any error, all of the > packets should suffer the same problem, right? > Or could it be that the parameters still need some tweaking? I'm guessing, > in an ideal channel(in simulation), I can use an decimating FIR filter to > replace the polyphase clock sync, while in experiment, I must use the > polyphase clock sync as well as some kind of equalizer and tweak the > parameters until I lower the ISI below an acceptable level. > > Regards, > Edwin > > > > > > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Update: BPSK problem: intermittent inter-symbol interference and phase change
I changed the sample per symbol from 4 to 2, the number of filters in rrc filter from 128 to 32, and the intermittent ISI(there is still ISI but it is uniform across the packets) and phase change is gone(in simulation). I run the program on 2 USRPs, one as Tx one as Rx. The intermittent ISI is back. But I suppose it is caused by imperfect timing and frequency synchronization. Anyone can comment on this please? Sent from Mail for Windows 10 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM Preamble
Hi Adhitha, I haven't used the "OFDM Insert Preamble" module before. But in my understanding, in tx_ofdm.grc, "OFDM Carrier Allocator" does the job of "OFDM insert preamble". It uses "sync word" instead of "preamble". I think they are the same thing. As for FFT length, keep it the same as your other OFDM modules. Note that the length of a sync word must be the same as FFT length. Regards, Edwin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio