Martin, Bingo! That worked.
Can you put those two numbers, 4 and 8 into words. I'm still having a heck of a time understanding what is going on with this block. v/r, Rich On Wed, Mar 18, 2015 at 9:54 AM, Martin Braun <martin.br...@ettus.com> wrote: > On 17.03.2015 14:46, Richard Bell wrote: > >> Each byte going into the HPD is an unpacked byte. There is only 1 bit >> represented per byte. Receiving the full payload of 1024 bits requires >> 1024 bytes of input. What does this imply for the HPD parameters? >> >> By setting it up with >> header_length = 1 (symbol) >> items per symbol = 32 (the header length) >> > > Try this: > > Make the header_length 4 and items per symbol 8. Then, the message from > the parser will match the number of items. > > "Items per symbol" is something that would be mainly useful for non-atomic > modulations, such as OFDM. It might do the trick here, too. > > M > > > >> It produces the correct number of samples at the header output. Is it >> possible for this to be working if the parameters were not set >> correctly? I'm so confused. >> >> Yes I've spit the messages out with a message debug port. The packet >> length it reads is 128. >> >> On Tue, Mar 17, 2015 at 2:21 PM, Martin Braun <martin.br...@ettus.com >> <mailto:martin.br...@ettus.com>> wrote: >> >> On 17.03.2015 14:14, Richard Bell wrote: >> >> Martin, >> >> Thanks for your detailed response. I need some clarification on >> a few >> points. I also need to clarify something. >> >> I am using the HPD on demodulated detected data. There are no >> floats at >> this point. Everything is binary. The data type of all blocks is >> byte. >> >> >> My bad, >> >> my mind colour-mapped the type wrongly to floats. >> >> I am adding artificial zeros in myself, after I form the packets, >> to >> simulate a burst transmission. I send a packet, dead time (0's), >> I send >> another packet, so on. That is the source of the zeros coming >> out of the >> payload port. >> >> OK, with that in mind, if my packet is setup accordingly: >> >> packet_structure: [32 bit header | 128 byte = 1024 bit payload] >> >> what are you calling an item here? >> >> >> 'Item' is GNU Radio nomenclature here. In your case, one item is one >> byte from the input buffer. >> >> Question is, how many bits are in one byte in your input buffer? Is >> your 1024 bit payload really 128 bytes long on the input buffer? >> >> Also, have you used the message debug block to see what your parser >> returns? >> >> M >> >> I am looking for the unit tests your mentioned. I was not aware >> of them. >> >> v/r, >> Rich >> >> On Tue, Mar 17, 2015 at 1:52 PM, Martin Braun >> <martin.br...@ettus.com <mailto:martin.br...@ettus.com> >> <mailto:martin.br...@ettus.com >> >> <mailto:martin.br...@ettus.com>__>> wrote: >> >> On 17.03.2015 11:48, Richard Bell wrote: >> >> [...] >> My issue might stem from a misunderstanding of the HPD >> parameters. This >> block seems to have been written for OFDM, but I'm >> using it for >> single >> carrier QPSK. If someone wouldn't mind looking over my >> parameters with >> singe carrier in mind to confirm I've set it up >> correct, I would be >> grateful. My header is 32 bits long and the payload is >> 160 bytes >> or 1280 >> bits long. The documentation for this block is not very >> clear on >> how the >> parameters relate to the system. >> >> >> Richard, >> >> the block has some added features to handle OFDM, but it >> wasn't >> written specifically for it. If you haven't read the unit >> tests for >> this code, you should definitely go there for some input. >> (The reason OFDM was considered as a special case is >> because this >> makes a CP remover block unnecessary, but that's another >> story). >> >> The output of the header port is perfect. It is the >> exactly what I >> expect. I'm showing 3 headers worth of samples in the >> sink plot, >> and we >> see exactly 3 headers with tags on the first sample of >> each >> header. In >> the payload length portion of the header, the value 160 >> exists >> for the >> payload length. My second question is, when generating >> the >> header using >> packet_header_default, is the payload represented in >> bytes or bits? >> >> >> Whatever your payload parser generates should be the number >> of >> *items* read through the HPD. What are bits, bytes? The HPD >> doesn't >> know any of this. It can only relate to the item size >> you've given it. >> >> Now if you look at the payload out sink plot, you will >> see payloads >> separated by zeros. Each payload portion (the non-zero >> portion) >> is the >> exact length as my payload should be, 160 bytes or 1280 >> bits. >> But you >> can see zeros are allowed through after the 1280th bit >> and a second >> payload shows up without a tag. This leads me to >> believe the HPD >> block >> is interpreting the payload length to be 4 times larger >> then I >> intend it >> to be. What parameters am I mixing up to create this? >> >> >> Yeah, I can see how that's happening. Your payload is being >> (probably correctly) interpreted as 160 bytes, then the HPD >> is given >> the number 160 as a payload length. However, the HPD needs >> to know >> the number of *items* per payload. 4 == sizeof(float), >> which you are >> using. >> >> The reason the OFDM code has no issues here is because it >> uses its >> own packet header parser, which returns the number of OFDM >> symbols. >> That really was the intention of the packet header parser >> architecture. >> >> Now, how come the packet header parser is reporting 160? Is >> that >> actually correct? It seems that if your payload is 40 >> floats, 160 >> bytes seems a lot. You'd be storing 4 bytes per float, when >> typically, you have 1 or 2 bits. >> >> However, as a quick hack, edit the packet_header_default to >> add a >> scaling factor (or just divide by 4 before sending the >> packet). That >> should fix it temporarily. A more long-term solution would >> be to add >> a scaling factor to the packet_header_default for these >> cases -- >> maybe you want to write and upstream this? >> >> I've played with the ofdm_tx/rx.grc example and >> confirmed that >> it will >> keep the zeros from showing up at the payload out port. >> This >> confirms my >> misuse of the block. The hard part is porting the OFDM >> example >> parameters to a single carrier use. Am I correct in >> setting >> symbol to 1 >> since there are no OFDM symbols? >> >> >> Here's what should work: >> >> header length: Whatever you have now >> items per symbol: >> gi: 0 >> output format: items >> >> Now make sure the header_parser tells the HPD the number of >> floats >> it needs to consume per payload. >> >> The value reported by the payload is the same unit as the >> header length. >> >> M >> >> PS: The reason you see zeros between packets is because the >> ringbuffers get initialized with zeros to start with. >> Eventually, >> you might see residue from other packets. >> >> ___________________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >> <mailto: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> >> >> <https://lists.gnu.org/__mailman/listinfo/discuss-__gnuradio >> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>> >> >> >> >> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
