[Discuss-gnuradio] ofdm plateau_detector_fb_impl//ofdm_sync_sc_cfb_impl
Hi all,
I have a question on the synchronization of ofdm example,namely the
sch source code.
The plateau_detector_fb_impl.cc can find the plateau,and then
header_payload_demux_impl can find the head data.
STEP 1: plateau_detector_fb_impl find the plateau.
flank_start = i;
while(i < noutput_items && in[i] >= d_threshold)
i++;
if((i - flank_start) > 1) { // 1 Sample is not a plateau
out[flank_start + (i-flank_start)/2] = 1;
i = std::min(i+d_max_len, noutput_items-1);
}
STEP 2:header_payload_demux_impl can find the head data
case STATE_HEADER:
if (check_items_available(d_header_len, ninput_items,
noutput_items, nread)) {
copy_n_symbols(in, out_header, PORT_HEADER, d_header_len);
STEP 3:
memcpy((void *) out, (void *) (in + d_gi * d_itemsize),
d_items_per_symbol * d_itemsize);
I think may be the code have some errors.For example,the data is
cdef+abcdef,the cyclic prefix is cdef,and the data is abcdef.
According step1,the output will ouput 001000.Because the sch will
output a plateau in the cyclic prefix,namely the index corresponding to the
cdefa will be the plateau.The source code output 1 in the middle.Namely the
index corresponding to the middle "e" output 1.
According to the step 2 and step3, we copy the d_items_per_symbol *
d_itemsize bytes after (in + d_gi * d_itemsize) to the output.In the example,
cdef+abcdef,the d_gi is 4. (in + d_gi * d_itemsize) will correspond to the
c.Then output d_items_per_symbol is 6,then output cdef..But the true head data
is abcdef,so I think maybe the source code have some problems.Is my
understanding right?
Thank you.
Best regards,
zswx
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Packet Header Generator and Stream CRC32
Hi Martin, Thank you. 1.Why the packet length should be larger than 32 bits?Can you explain it? 2.For example,I'm using the OFDM example in gnuradio.If i want to have a working CRC,I must set the length=4?Is 4 OK? 3.Is the packet length means that the original length(for example len=a) or the length of data pass through CRC(len+4)? Best regards, zswx At 2015-07-11 07:40:38, Martin Braun martin.br...@ettus.com wrote: On 10 Jul 2015 01:38, zs zswx_...@126.com wrote: If I want to have a working CRC,what is the number of packet length at least? 32 bits. If someone don't want to use the Stream CRC32 block,Packet Header Generator still will add the crc at bit 24-31.Is it right?I suggest the code should add a function to judge before add the crc at bit 24-31. We don't want to overload this generator with options. The idea is you subclass the generator to tailor to your needs. See also the other generators. 3.For example,the OFDM example.If the transmitter don't add the crc32 block,whether the receiver will display the warning Detected an invalid packet at item %1%? No, that's precisely why we have it. However, the payload also has a crc. Cheers, M___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Packet Header Generator and Stream CRC32
Hello everyone,
I have 3 questions want to ask you,thanks.
1.I look at this in the api,
Uses the following header format: Bits 0-11: The packet length (what was stored
in the tag with key len_tag_key) Bits 12-23: The header number (counts up
everytime this function is called) Bit 24-31: 8-Bit CRC All other bits: Are set
to zero
If the header length is smaller than 32, bits are simply left out. For this
reason, they always start with the LSB.
However, it is recommended to stay above 32 Bits, in order to have a working
CRC.
Q:
If I want to have a working CRC,what is the number of packet length at least?
2.I look at the code below,
bool packet_header_default::header_formatter(
66 ---long packet_len,
67 unsigned char *out,
68
69 ---const std::vectortag_t tags
70 )
71 {
72 ---//std::coutbefored_maskstd::endl;
73 packet_len = 0x0FFF;
74
75 d_crc_impl.reset();
76 d_crc_impl.process_bytes((void const *) packet_len, 2);
77 d_crc_impl.process_bytes((void const *) d_header_number, 2);
78 unsigned char crc = d_crc_impl();
79 memset(out, 0x00, d_header_len);
80 int k = 0; // Position in out
81 for (int i = 0; i 12 k d_header_len; i += d_bits_per_byte,
k++) {
82 ---out[k] = (unsigned char) ((packet_len i) d_mask);
83
84 }
85 for (int i = 0; i 12 k d_header_len; i += d_bits_per_byte,
k++) {
86 ---out[k] = (unsigned char) ((d_header_number i) d_mask);
87 }
88 for (int i = 0; i 8 k d_header_len; i += d_bits_per_byte, k++)
{
89 ---out[k] = (unsigned char) ((crc i) d_mask);
90 }
91 d_header_number++;
92 d_header_number = 0x0FFF;
93
94 return true;
95 }
If someone don't want to use the Stream CRC32 block,Packet Header Generator
still will add the crc at bit 24-31.Is it right?I suggest the code should add a
function to judge before add the crc at bit 24-31.
3.For example,the OFDM example.If the transmitter don't add the crc32
block,whether the receiver will display the warning Detected an invalid packet
at item %1%?
Thank you so much.
Best regards,
zswx
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about the ninput_items
Hi Marcus:
Thank you so much.
1.How did the system know how many items I can consume in a work call?
2.Do you means that every times call the block,the block will throw the
ninput_items[0] items?
For example,the input steam 0 item is 1,2,3,4,5... and the
ninput_items[0]=2.
The first time call the block, 1 2 is removed.
The second time call the block,3 4 is removed.Is my understanding
right?Just to confirm it.
3.I add two files before and after Stream CRC 32 block respectively.Namely
file1.dat and file2.dat.The type is Byte.Can I use the read_char_binary.m in
matlab to look at the data?Or use other m file provided by the gnuradio?Thank
you.
Best regards,
zswx
At 2015-07-09 21:48:30, Marcus Müller marcus.muel...@ettus.com wrote:
Hi Zswx,
ninput_items[0] is really the number of items that you can consume in a work
call (on input stream 0). It's usually 1.
Best regards,
Marcus
On 07/09/2015 03:29 PM, zs wrote:
Hi,
Thank you in advance.I have a question about the ninput_items.I find the
meaning of it is vector of items available on all input buffers.
When I read the source code of crc32_bb_impl.cc,I see the code below,
int
65 crc32_bb_impl::work (int noutput_items,
66gr_vector_int ninput_items,
67gr_vector_const_void_star input_items,
68gr_vector_void_star output_items)
69 {
70 const unsigned char *in = (const unsigned char *) input_items[0];
71 unsigned char *out = (unsigned char *) output_items[0];
72 long packet_length = ninput_items[0];
I think the ninput_items[0]=1,because the item input is 1 every times.But when
I write the code std::coutninput_items[0]std::endl;,It display the
packet_length.I think the ninput_items[0]=1 no matter what pack_length is.Why
I'm wrong?
Thank you.
Best regards,
zswx
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about the ninput_items
Hi Marcus:
Thank you so much.
1.How did the system know how many items I can consume in a work call?
2.Do you means that every times call the block,the block will throw the
ninput_items[0] items?
For example,the input steam 0 item is 1,2,3,4,5... and the
ninput_items[0]=2.
The first time call the block, 1 2 is removed.
The second time call the block,3 4 is removed.Is my understanding
right?Just to confirm it.
3.I add two files before and after Stream CRC 32 block respectively.Namely
file1.dat and file2.dat.The type is Byte.Can I use the read_char_binary.m in
matlab to look at the data?Or use other m file provided by the gnuradio?Thank
you.
Best regards,
zswx
At 2015-07-09 21:48:30, Marcus Müller marcus.muel...@ettus.com wrote:
Hi Zswx,
ninput_items[0] is really the number of items that you can consume in a work
call (on input stream 0). It's usually 1.
Best regards,
Marcus
On 07/09/2015 03:29 PM, zs wrote:
Hi,
Thank you in advance.I have a question about the ninput_items.I find the
meaning of it is vector of items available on all input buffers.
When I read the source code of crc32_bb_impl.cc,I see the code below,
int
65 crc32_bb_impl::work (int noutput_items,
66gr_vector_int ninput_items,
67gr_vector_const_void_star input_items,
68gr_vector_void_star output_items)
69 {
70 const unsigned char *in = (const unsigned char *) input_items[0];
71 unsigned char *out = (unsigned char *) output_items[0];
72 long packet_length = ninput_items[0];
I think the ninput_items[0]=1,because the item input is 1 every times.But when
I write the code std::coutninput_items[0]std::endl;,It display the
packet_length.I think the ninput_items[0]=1 no matter what pack_length is.Why
I'm wrong?
Thank you.
Best regards,
zswx
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.orghttps://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] Question about the ninput_items
Hi,
Thank you in advance.I have a question about the ninput_items.I find the
meaning of it is vector of items available on all input buffers.
When I read the source code of crc32_bb_impl.cc,I see the code below,
int
65 crc32_bb_impl::work (int noutput_items,
66gr_vector_int ninput_items,
67gr_vector_const_void_star input_items,
68gr_vector_void_star output_items)
69 {
70 const unsigned char *in = (const unsigned char *) input_items[0];
71 unsigned char *out = (unsigned char *) output_items[0];
72 long packet_length = ninput_items[0];
I think the ninput_items[0]=1,because the item input is 1 every times.But when
I write the code std::coutninput_items[0]std::endl;,It display the
packet_length.I think the ninput_items[0]=1 no matter what pack_length is.Why
I'm wrong?
Thank you.
Best regards,
zswx___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ofdm frequency offset
Dear all: Thank you in advance. 1. I want to ask a question about the new ofdm example.And I know the receiver have used the SCA(schmidl and cox algorithm) algorithm.Now in my application,maybe this algorithm isn't enough.And I want to ask whether have other good frequency offset correction algorithm which have been implemented. 2.What is the algorithm used by the old version of the ofdm example?Thanks. Best regards, zs ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ofdm frequency offset
Dear Marcus Müller: Thank you so much for your kindly reply. The SCA is adequate for a correct demodulation of the signal while maybe inadequate for estimate the precise frequency shift.I don't have the synchroniztion device.In my application,I need to reconstruct one transmit signal in time domain,and remove it from the received signal.For example,y=x1+x2,and I want to remove x2 from the baseband recevied signal. Now my idea is no only used the SCA algorithm mentioned in the new ofdm example, but also use other similar finer carrier frequency estimation algorithm.I want to combined the algorithms.So I ask the question in the maillist. Thank you so much. Best regards, zs At 2015-06-24 15:54:30, Marcus Müller marcus.muel...@ettus.com wrote: Dear zs, basically, Schmidl and Cox is a very good algorithm, because it can achieve the same quality of synchronization with half of the synchronization overhead compared to other approaches, or a better performance with the same amount. I must admit that from the top of my head, there's probably not much that's better than SC in a real world OFDM receiver, but I must admit that I haven't implemented many OFDM synchronizers myself. However, you say Now in my application,maybe this algorithm isn't enough. which means that you have a mathematical measure that's not OK for SC, I guess. So in what way doesn't SC suffice? What is it about your application that makes SC insufficient or impossible to use? Best regards, Marcus On 06/24/2015 09:00 AM, zs wrote: Dear all: Thank you in advance. 1. I want to ask a question about the new ofdm example.And I know the receiver have used the SCA(schmidl and cox algorithm) algorithm.Now in my application,maybe this algorithm isn't enough.And I want to ask whether have other good frequency offset correction algorithm which have been implemented. 2.What is the algorithm used by the old version of the ofdm example?Thanks. Best regards, zs ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orghttps://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] ofdm frequency offset
Dear all: Thank you in advance. 1. I want to ask a question about the new ofdm example.And I know the receiver have used the SCA(schmidl and cox algorithm) algorithm.Now in my application,maybe this algorithm isn't enough.And I want to ask whether have other good frequency offset correction algorithm which have been implemented. 2.What is the algorithm used by the old version of the ofdm example?Thanks. Best regards, zs ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ofdm frequency offset
Dear Marcus Müller: Do you know which is the synchronization algorithm used in the old version of ofdm example?Where is the source code of the old ofdm version in gnuradio?Thanks. Any other suggestions? Thank you. Best regards, zs At 2015-06-24 15:54:30, Marcus Müller marcus.muel...@ettus.com wrote: Dear zs, basically, Schmidl and Cox is a very good algorithm, because it can achieve the same quality of synchronization with half of the synchronization overhead compared to other approaches, or a better performance with the same amount. I must admit that from the top of my head, there's probably not much that's better than SC in a real world OFDM receiver, but I must admit that I haven't implemented many OFDM synchronizers myself. However, you say Now in my application,maybe this algorithm isn't enough. which means that you have a mathematical measure that's not OK for SC, I guess. So in what way doesn't SC suffice? What is it about your application that makes SC insufficient or impossible to use? Best regards, Marcus On 06/24/2015 09:00 AM, zs wrote: Dear all: Thank you in advance. 1. I want to ask a question about the new ofdm example.And I know the receiver have used the SCA(schmidl and cox algorithm) algorithm.Now in my application,maybe this algorithm isn't enough.And I want to ask whether have other good frequency offset correction algorithm which have been implemented. 2.What is the algorithm used by the old version of the ofdm example?Thanks. Best regards, zs ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ofdm frequency offset
Dear Marcus Müller: Thank you so much.So kindly of you.Thanks.I will read the papers you mentioned. Best regards, zs At 2015-06-24 17:08:16, Marcus Müller marcus.muel...@ettus.com wrote: Hi zs, this reminds me very much of OFDM radar technologies, as your problem boils down to finding a good estimator for the spectral properties of your OFDM frame as well as the time it reached you. I think you should have a look at chapter 3, OFDM Radar Algorithms of [1]; you might find that considering the unknown timing being a result of the time it took a OFDM signal to reach you (and hence an effect of range) a useful approach. You can find some shorter information on the accuracy of these estimates in [2]. The difference in the algorithms described in [1] and your problem is that you don't a priori know the transmitted signal -- you'll have to figure that out by using something like SC to receive and decode the OFDM symbol prior to clean reconstruction; you could then use the parameters (range == timing, doppler == frequency) that the radar estimators give you to model the symbol like you received it, and subtract it from your incoming signal. Of course, the mistakes you make when decoding the incoming symbol will have an influence on the accuracy of your estimates. Best regards, Marcus [1] Braun, Martin. OFDM Radar Algorithms in Mobile Communication Networks. Diss. Karlsruhe, Karlsruher Institut für Technologie (KIT), Diss., 2014, 2014; http://nbn-resolving.org/urn:nbn:de:swb:90-388921 [2] Braun, Martin, Christian Sturm, and Friedrich Jondral. On the single-target accuracy of OFDM radar algorithms. PIMRC. 2011.; http://www.cel.kit.edu/download/PIMRC2011_BraunSchuSturmJondral.pdf On 06/24/2015 10:29 AM, zs wrote: Dear Marcus Müller: Thank you so much for your kindly reply. The SCA is adequate for a correct demodulation of the signal while maybe inadequate for estimate the precise frequency shift.I don't have the synchroniztion device.In my application,I need to reconstruct one transmit signal in time domain,and remove it from the received signal.For example,y=x1+x2,and I want to remove x2 from the baseband recevied signal. Now my idea is no only used the SCA algorithm mentioned in the new ofdm example, but also use other similar finer carrier frequency estimation algorithm.I want to combined the algorithms.So I ask the question in the maillist. Thank you so much. Best regards, zs At 2015-06-24 15:54:30, Marcus Müller marcus.muel...@ettus.com wrote: Dear zs, basically, Schmidl and Cox is a very good algorithm, because it can achieve the same quality of synchronization with half of the synchronization overhead compared to other approaches, or a better performance with the same amount. I must admit that from the top of my head, there's probably not much that's better than SC in a real world OFDM receiver, but I must admit that I haven't implemented many OFDM synchronizers myself. However, you say Now in my application,maybe this algorithm isn't enough. which means that you have a mathematical measure that's not OK for SC, I guess. So in what way doesn't SC suffice? What is it about your application that makes SC insufficient or impossible to use? Best regards, Marcus On 06/24/2015 09:00 AM, zs wrote: Dear all: Thank you in advance. 1. I want to ask a question about the new ofdm example.And I know the receiver have used the SCA(schmidl and cox algorithm) algorithm.Now in my application,maybe this algorithm isn't enough.And I want to ask whether have other good frequency offset correction algorithm which have been implemented. 2.What is the algorithm used by the old version of the ofdm example?Thanks. Best regards, zs ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ofdm frequency offset
Dear Marcus Müller: Actually my problem is: y=useful information+x*h(channel)*cfo(carrier offset due to the local oscillator between the interference and the radar)+noise. I want to turn y to new_y=useful information+noise. So I need know the channel(h) and the cfo exactly(I know the x in advance while I don't know the cfo and h.So I have to estimate them).The root question I faced is the cfo estimated from the SCA isn't enough. Thank you so much. I will read the paper you mentioned.Maybe helpful.Thanks. Best regards, zs At 2015-06-24 17:08:16, Marcus Müller marcus.muel...@ettus.com wrote: Hi zs, this reminds me very much of OFDM radar technologies, as your problem boils down to finding a good estimator for the spectral properties of your OFDM frame as well as the time it reached you. I think you should have a look at chapter 3, OFDM Radar Algorithms of [1]; you might find that considering the unknown timing being a result of the time it took a OFDM signal to reach you (and hence an effect of range) a useful approach. You can find some shorter information on the accuracy of these estimates in [2]. The difference in the algorithms described in [1] and your problem is that you don't a priori know the transmitted signal -- you'll have to figure that out by using something like SC to receive and decode the OFDM symbol prior to clean reconstruction; you could then use the parameters (range == timing, doppler == frequency) that the radar estimators give you to model the symbol like you received it, and subtract it from your incoming signal. Of course, the mistakes you make when decoding the incoming symbol will have an influence on the accuracy of your estimates. Best regards, Marcus [1] Braun, Martin. OFDM Radar Algorithms in Mobile Communication Networks. Diss. Karlsruhe, Karlsruher Institut für Technologie (KIT), Diss., 2014, 2014; http://nbn-resolving.org/urn:nbn:de:swb:90-388921 [2] Braun, Martin, Christian Sturm, and Friedrich Jondral. On the single-target accuracy of OFDM radar algorithms. PIMRC. 2011.; http://www.cel.kit.edu/download/PIMRC2011_BraunSchuSturmJondral.pdf On 06/24/2015 10:29 AM, zs wrote: Dear Marcus Müller: Thank you so much for your kindly reply. The SCA is adequate for a correct demodulation of the signal while maybe inadequate for estimate the precise frequency shift.I don't have the synchroniztion device.In my application,I need to reconstruct one transmit signal in time domain,and remove it from the received signal.For example,y=x1+x2,and I want to remove x2 from the baseband recevied signal. Now my idea is no only used the SCA algorithm mentioned in the new ofdm example, but also use other similar finer carrier frequency estimation algorithm.I want to combined the algorithms.So I ask the question in the maillist. Thank you so much. Best regards, zs At 2015-06-24 15:54:30, Marcus Müller marcus.muel...@ettus.com wrote: Dear zs, basically, Schmidl and Cox is a very good algorithm, because it can achieve the same quality of synchronization with half of the synchronization overhead compared to other approaches, or a better performance with the same amount. I must admit that from the top of my head, there's probably not much that's better than SC in a real world OFDM receiver, but I must admit that I haven't implemented many OFDM synchronizers myself. However, you say Now in my application,maybe this algorithm isn't enough. which means that you have a mathematical measure that's not OK for SC, I guess. So in what way doesn't SC suffice? What is it about your application that makes SC insufficient or impossible to use? Best regards, Marcus On 06/24/2015 09:00 AM, zs wrote: Dear all: Thank you in advance. 1. I want to ask a question about the new ofdm example.And I know the receiver have used the SCA(schmidl and cox algorithm) algorithm.Now in my application,maybe this algorithm isn't enough.And I want to ask whether have other good frequency offset correction algorithm which have been implemented. 2.What is the algorithm used by the old version of the ofdm example?Thanks. Best regards, zs ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ofdm_chanest_vcvc_impl.cc
Hi Martin: Thank you so much for your kindly reply.So kindly of you.I understand it. Best regards, zs At 2015-02-02 18:24:25, Martin Braun martin.br...@ettus.com wrote: I'll try and keep it short and simple: First: What's the difference between a cyclic shift and a non-cyclic shift? It means that sub-carriers from one end are moved the other end. So, if we have 8 subcarriers arranged like this: 0, 1, 2, 3, 4, 5, 6, 7 and do a cyclic shift, we get something like 1, 2, 3, 4, 5, 6, 7, 0 Right? OK, here's why this would never even be an issue in practice: As you know, a subcarrier has the same width as the corresponding FFT bin. But you never use all FFT bins. Best example is Wi-Fi, where you have an FFT length of 64 in the modulation/demodulation phase, but only use 52 carriers (outside of the DC carrier). So, all bins at the edge of your Nyquist zone are not used. Using the example before, it would be something like: x, x, 0, 1, 2, 3, x, x Now, if do a shift (cyclic or not) of length 1 (note that in the SC setup, you'd have multiples of 2 for the shift), you get this: x, 0, 1, 2, 3, x, x, x Now, in the implementation, I can copy the left-most 'x' to the right, but what's the point? There's no information there. So I just do a memcpy with an offset. Much simpler, does the same. So, you might be tempted to say non-cyclic or cyclic, it doesn't really matter. In practice, given what I just discussed, that's kind of correct. But, assume you have a really, really big frequency offset. Your relevant carriers will be cut off by the resampling filters (or even the analog filters) before they even hit the FFT. So, you'd have something like this: 1, 2, 3, x, x, x, x, x No shifting, cyclic or non-cyclic, can save you now. So where does this cyclic stuff come from? Well, in the pure discrete domain, when you do frequency shifts by multiplying with complex sinusoids, a frequency offset *will* be cyclic. You might even run into this in reality even, because in Schmidl Cox, before you correct the integer FO, you correct the fine FO with such a sinusoid multiplication. So, cyclic isn't wrong, per se. But it's not really required. However, if you take away a single piece of information from this, let it be this: In practice, you design your parameters such that it doesn't matter if you shift cyclically or non-cyclically. In that case, the latter is less computationally heavy. M On 02/02/2015 09:09 AM, zs wrote: Hi Martin: Thank you in advance.I have read many papers on the topic integer cfo of OFDM.They all said it make the subcarriers cyclic shift. For example: http://nutaq.com/en/blog/brief-overview-frequency-synchronization-ofdm It said Integer CFO does not introduce ICI between sub-carriers, but does introduce a cyclic shift of data sub-carriers... Is it right?And the source code ofdm_chanest_vcvc_impl.cc is right?Maybe I'm wrong.Can you explain it?Thank you. Best regards, zs At 2015-01-25 19:27:30, Martin Braun martin.br...@ettus.com wrote: On 01/25/2015 08:10 AM, zs wrote: Hi Martin: Thank you for your reply.And we know this block do Estimate channel and coarse frequency offset for OFDM from preambles.And the coarse frequency offset is a integer.And it make the subcarriers cyclic shift.Just illustration as this: No cyclic shift. There must be enough space between the out subcarriers and the Nyquist zone boundaries. Hope this clears things up! And please respond to the list. M ___ 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ofdm_chanest_vcvc_impl.cc
Hi Martin: Thank you in advance.I have read many papers on the topic integer cfo of OFDM.They all said it make the subcarriers cyclic shift. For example: http://nutaq.com/en/blog/brief-overview-frequency-synchronization-ofdm It said Integer CFO does not introduce ICI between sub-carriers, but does introduce a cyclic shift of data sub-carriers... Is it right?And the source code ofdm_chanest_vcvc_impl.cc is right?Maybe I'm wrong.Can you explain it?Thank you. Best regards, zs At 2015-01-25 19:27:30, Martin Braun martin.br...@ettus.com wrote: On 01/25/2015 08:10 AM, zs wrote: Hi Martin: Thank you for your reply.And we know this block do Estimate channel and coarse frequency offset for OFDM from preambles.And the coarse frequency offset is a integer.And it make the subcarriers cyclic shift.Just illustration as this: No cyclic shift. There must be enough space between the out subcarriers and the Nyquist zone boundaries. Hope this clears things up! And please respond to the list. M ___ 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
Re: [Discuss-gnuradio] INFO: Detected an invalid packet at item INFO: Parser returned #f
Hi Bastian:
Thank you so much.I use the ofdm example,and I think maybe the
crc is wrong as you said,thank you.
Can you give me some advices to avoid these warning?Thank you
so much.
Best regards,
zs
At 2015-01-30 00:43:12, Bastian Bloessl bloe...@ccs-labs.org wrote:
Hi,
On 01/29/2015 03:13 PM, zs wrote:
Can you tell me,for general,in which circumstance,the packet header maybe
corrupt?
This is very hard to tell since I don't know what you are doing. I guess
you use a header_formatter in your flow graph and (for whatever reason)
its header_parse method returns false.
For example with the default header it looks like this happens if the
CRC is not correct
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/packet_header_default.cc#L132
At 2015-01-29 20:44:13, Bastian Bloessl bloe...@ccs-labs.org wrote:
Hi,
On 01/29/2015 01:03 PM, zs wrote:
Detected an invalid packet at item INFO: Parser returned #f.
The answer may be RF settings are distorting your signal or others.I
want to ask a question.Which block in gnuradio give us this hint.Where
is the source code of the block?And have someone can help me to explain
this problem more details?Why will have this error/warning?
~/src/gnuradio ack-grep -C 3 an invalid packet
gr-digital/lib/packet_headerparser_b_impl.cc
80- );
81-
82- if (!d_header_formatter-header_parser(in, tags)) {
83: GR_LOG_INFO(d_logger, boost::format(Detected an invalid packet at
item %1%) % nitems_read(0));
84- message_port_pub(msg_port_id, pmt::PMT_F);
85- } else {
86- pmt::pmt_t dict(pmt::make_dict());
I guess your packet header is corrupt.
Best,
Bastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] INFO: Detected an invalid packet at item INFO: Parser returned #f
Hi all: Thank you in advance.I have searched the questionINFO: Detected an invalid packet at item INFO: Parser returned #f. The answer may be RF settings are distorting your signal or others.I want to ask a question.Which block in gnuradio give us this hint.Where is the source code of the block?And have someone can help me to explain this problem more details?Why will have this error/warning? Thank you. Best regards, zs ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] INFO: Detected an invalid packet at item INFO: Parser returned #f
Hi Bastian:
Thank you so much for your kindly reply.Can you tell me,for
general,in which circumstance,the packet header maybe corrupt?
Thank you so much.
Best regards,
zs
At 2015-01-29 20:44:13, Bastian Bloessl bloe...@ccs-labs.org wrote:
Hi,
On 01/29/2015 01:03 PM, zs wrote:
Detected an invalid packet at item INFO: Parser returned #f.
The answer may be RF settings are distorting your signal or others.I
want to ask a question.Which block in gnuradio give us this hint.Where
is the source code of the block?And have someone can help me to explain
this problem more details?Why will have this error/warning?
~/src/gnuradio ack-grep -C 3 an invalid packet
gr-digital/lib/packet_headerparser_b_impl.cc
80- );
81-
82- if (!d_header_formatter-header_parser(in, tags)) {
83:GR_LOG_INFO(d_logger, boost::format(Detected an invalid packet at
item %1%) % nitems_read(0));
84-message_port_pub(msg_port_id, pmt::PMT_F);
85- } else {
86-pmt::pmt_t dict(pmt::make_dict());
I guess your packet header is corrupt.
Best,
Bastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] INFO: Detected an invalid packet at item INFO: Parser returned #f
Hi Bastian:
Thank you so much.I use the ofdm example,and I think maybe the
crc is wrong as you said,thank you.
Best regards,
zs
At 2015-01-30 00:43:12, Bastian Bloessl bloe...@ccs-labs.org wrote:
Hi,
On 01/29/2015 03:13 PM, zs wrote:
Can you tell me,for general,in which circumstance,the packet header maybe
corrupt?
This is very hard to tell since I don't know what you are doing. I guess
you use a header_formatter in your flow graph and (for whatever reason)
its header_parse method returns false.
For example with the default header it looks like this happens if the
CRC is not correct
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/packet_header_default.cc#L132
At 2015-01-29 20:44:13, Bastian Bloessl bloe...@ccs-labs.org wrote:
Hi,
On 01/29/2015 01:03 PM, zs wrote:
Detected an invalid packet at item INFO: Parser returned #f.
The answer may be RF settings are distorting your signal or others.I
want to ask a question.Which block in gnuradio give us this hint.Where
is the source code of the block?And have someone can help me to explain
this problem more details?Why will have this error/warning?
~/src/gnuradio ack-grep -C 3 an invalid packet
gr-digital/lib/packet_headerparser_b_impl.cc
80- );
81-
82- if (!d_header_formatter-header_parser(in, tags)) {
83: GR_LOG_INFO(d_logger, boost::format(Detected an invalid packet at
item %1%) % nitems_read(0));
84- message_port_pub(msg_port_id, pmt::PMT_F);
85- } else {
86- pmt::pmt_t dict(pmt::make_dict());
I guess your packet header is corrupt.
Best,
Bastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] link error
Hi all: Thank you in advance. I have use the tool gr_modtool to create a cpp document.But an error exists: ImportError: /usr/local/lib/libgnuradio-mimo.so: undefined symbol: _ZTIN2gr4mimo21csi_int_cfo_vcvc_implE I have search the maillist,and find sudo ldconfig to solve it.But when I use the sudo ldconfig,the error also exists. Can someone help me? Best regards, zs ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] link error
Hi all: Thank you in advance. I have use the tool gr_modtool to create a cpp document.But an error exists: ImportError: /usr/local/lib/libgnuradio-mimo.so: undefined symbol: _ZTIN2gr4mimo21csi_int_cfo_vcvc_implE I have search the maillist,and find sudo ldconfig to solve it.But when I use the sudo ldconfig,the error also exists. Can someone help me?Thanks. Best regards, zs ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ofdm_chanest_vcvc_impl.cc
Hi Martin: Thank you for your reply.And we know this block do Estimate channel and coarse frequency offset for OFDM from preambles.And the coarse frequency offset is a integer.And it make the subcarriers cyclic shift.Just illustration as this: For example,we have 5 subcarriers,cfo=2. Right subcarriers:s1,s2,s3,s4,s5 Wrong subcarriers:s4,s5,s1,s2,s3 So the channel estimation coefficients will not be zeros.Is it right? Best regards, zswx At 2015-01-25 03:38:38, Martin Braun martin.br...@ettus.com wrote: On 01/24/2015 08:43 AM, zs wrote: Now the taps only have values on taps[0]---taps[63-2],and taps[62] taps[63] will be equal to zero.It means that the channel estimation have value 0.It is wrong? They will be zero, and it's not wrong. What else should be written here? There's no useful information outside the frame. M ___ 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] ofdm_chanest_vcvc_impl.cc
Hi all:
Thank you in advance.I have read the source
code:ofdm_chanest_vcvc_impl.cc.But i have a question.
void
ofdm_chanest_vcvc_impl::get_chan_taps(
const gr_complex *sync_sym1,
const gr_complex *sync_sym2,
int carr_offset,
std::vectorgr_complex taps)
{
const gr_complex *sym = ((d_n_sync_syms == 2) ? sync_sym2 : sync_sym1);
std::fill(taps.begin(), taps.end(), gr_complex(0, 0));
int loop_start = 0;
int loop_end = d_fft_len;
if (carr_offset 0) {
loop_start = carr_offset;
} else if (carr_offset 0) {
loop_end = d_fft_len + carr_offset;
}
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];
}
}
//Question:
//For example,when the carr_offset=2,then:
//loop_start =2;
//for example loop_end=64
// for (int i =2; 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];
}
}
//
Now the taps only have values on taps[0]---taps[63-2],and taps[62] taps[63]
will be equal to zero.It means that the channel estimation have value 0.It is
wrong?
if (d_interpolate) {
for (int i = d_first_active_carrier + 1; i d_last_active_carrier; i += 2)
{
taps[i] = taps[i-1];
}
taps[d_last_active_carrier] = taps[d_last_active_carrier-1];
}
if (d_eq_noise_red_len) {
// TODO
// 1) IFFT
// 2) Set all elements d_eq_noise_red_len to zero
// 3) FFT
}
}
Thank you.
Best regards,
zswx
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ofdm_chanest_vcvc_impl.cc
Hi all:
Thank you in advance.I have read the source
code:ofdm_chanest_vcvc_impl.cc.But i have a question.
void
ofdm_chanest_vcvc_impl::get_chan_taps(
const gr_complex *sync_sym1,
const gr_complex *sync_sym2,
int carr_offset,
std::vectorgr_complex taps)
{
const gr_complex *sym = ((d_n_sync_syms == 2) ? sync_sym2 : sync_sym1);
std::fill(taps.begin(), taps.end(), gr_complex(0, 0));
int loop_start = 0;
int loop_end = d_fft_len;
if (carr_offset 0) {
loop_start = carr_offset;
} else if (carr_offset 0) {
loop_end = d_fft_len + carr_offset;
}
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];
}
}
//Question:
//For example,when the carr_offset=2,then:
//loop_start =2;
//for example loop_end=64
// for (int i =2; 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];
}
}
//
Now the taps only have values on taps[0]---taps[63-2],and taps[62] taps[63]
will be equal to zero.It means that the channel estimation have value 0.It is
wrong?
if (d_interpolate) {
for (int i = d_first_active_carrier + 1; i d_last_active_carrier; i += 2)
{
taps[i] = taps[i-1];
}
taps[d_last_active_carrier] = taps[d_last_active_carrier-1];
}
if (d_eq_noise_red_len) {
// TODO
// 1) IFFT
// 2) Set all elements d_eq_noise_red_len to zero
// 3) FFT
}
}
Thank you.
Best regards,
zswx
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Latency of tcpip transmission
Hi all: Thank you in advance. Environment: gnuradio 3.7.5 The picture below shows the received signal.I will try my best to explain my problem.I use one usrp N210 to send signal and the other usrp receive the signal and then transmit the message by the tcpip to the transmitter.Then the transmitter re-send signal again.I think the way of tcpip transmission is so fast.But it has the latency as the below picture shows.Have some ideas to solve it?And have some tools in grc to solve it?Thanks so much.(the signal inside the blue circle while the latency is interval of signal). Best regards, xd ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Latency of tcpip transmission
Hi Marcus: Thank you for your reply. What is very short? Numbers, please. Also, sample rate, modulation, carrier frequency etc might be of interest. 1.Just 128 complex numbers.The receivers send the 128 complex numbers to the transmitter through the tcpip. sample rate=250e3,carrier frequency=3e9 well, you'll always receive noise. What's the problem with that? it's the same noise you will see whilst actually receiving data, and to know when to receive, you'll need some way of synchronization, anyway. 2.I know,I will always receive noise.But during the interval of the transmitter sending,the receive keep receiving.In the interval,no signal shows,only noise.As shows in the picture,latency.I want to detect this,and just receive the signal to the next block(writing in the gnuradio). Thanks. Best regards, zs At 2014-11-28 20:17:32, Marcus Müller marcus.muel...@ettus.com wrote: Hi zs/xd, On 11/28/2014 12:58 PM, zs wrote: Hi Marcus: Thank you for your reply.Sorry for my unclear introduction to my question.I apology for this. I just want to know whether someone encounter the similar question of mine.My question is this:I have two usrps.One is transmitter while the other is receiver. 1.I use the transmitter to send signals to the receiver. 2.And then receiver calculate the message (very shot).And through the tcpip,the receiver transmit the message to the transmitter. What is very short? Numbers, please. Also, sample rate, modulation, carrier frequency etc might be of interest. 3.The transmitter resend again. Because the receiver keep receiving during this processing.So in the interval of the transmitter sending,the receiver receive some noise.I don't want receive the noise. Have some ideas about this?Experts.Thank you. well, you'll always receive noise. What's the problem with that? it's the same noise you will see whilst actually receiving data, and to know when to receive, you'll need some way of synchronization, anyway. Best regards, Marcus Best regards, zs At 2014-11-28 19:21:15, Marcus Müller marcus.muel...@ettus.com wrote: Hello xd, You're expecting us to guess what you know: What are we seeing in that diagram? What are the axes and how are they scaled? Also: some information of message length, the amount of data you need to pass through network, why latency is a problem etc would always help. Generally, GNU Radio can't do magic. If your data processing/forwarding introduces latencies, there's nothing you can do. TCP/IP transmission doesn't necessarily give you any indication on how fast something happens -- generally, ack'ing protocols like TCP might be a bad choice in limiting latency. Best regards, Marcus On 11/28/2014 11:27 AM, zs wrote: Hi all: Thank you in advance. Environment: gnuradio 3.7.5 The picture below shows the received signal.I will try my best to explain my problem.I use one usrp N210 to send signal and the other usrp receive the signal and then transmit the message by the tcpip to the transmitter.Then the transmitter re-send signal again.I think the way of tcpip transmission is so fast.But it has the latency as the below picture shows.Have some ideas to solve it?And have some tools in grc to solve it?Thanks so much.(the signal inside the blue circle while the latency is interval of signal). Best regards, xd ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
