mac: problems using tags generated by IEEE802.15.4 OQPSK PHY

[ffierling]

Two related issues here:

1. Foo Burst Tagger in IEEE802.15.4 OQPSK PHY does an splendid job of marking the last sample of a packet with tx_eob and the first sample of the next packet with tx_sob. Unfortunately it's unable to do this until the second packet has flushed the last half-sine pulse of the first packet through. The problem can be reproduced by sending a single packet. You'll be able to trigger on a tx_sob, but no tx_eob will be forthcoming until a subsequent packet has flushed out the modulator pipeline.

2. Thanks to the Offset in OQPSK it's not possible to separate the end of one packet from the beginning of the next without mangling a symbol, as shown below:

Symbol Values: The 1200 (base 4) is the last four symbols of the last nibble (0xB) of packet CRC. The 3021 is the start of the next packet's pad (0xF).

The problem manifests as low receiver LQI values when the last symbols of the CRC are mangled by separation.

Ideally, IEEE802.15.4 OQPSK PHY would output pads of 0+0j I/Q samples both before the preamble and after the last symbol of the CRC, but that's a major project. I've an expedient solution for 2.: add a pad after the CRC. Is there a better fix?

Is there a way to fix the first issue?

[bastibl]

Hi, I just pushed a commit that updates the flow graph. Now, it padds some zeros between consecutive frames. I added it just before I and Q are shifted. This should (also) solve problem two. For problem one, there seems to be no nice solution with plain GNU Radio. AFAIS, it would now require a custom block after the IQ shift that drops the last two padded samples (these are the ones stuck until the next frame arrives) and adapts the packet length tag (subtract 2).

[ffierling]

I like how you use the pdu_length tag and value to define packet boundaries. It should be noted though, this fix will break any flowgraphs that depend on UHD tx_sob and tx_eob tags.

[bastibl]

Arg, I don't have a USRP and couldn't test it :-( Two things: AFAIK, these tags only suppress warnings, but don't actually do anything. But, independent from that, what I wanted to do was to use the USRP in tagged stream mode. You can either send a normal stream (with tx_sob and tx_eob), or set the TSB name in the USRP block to switch to tagged stream mode (where one tag in the beginning indicates the length). I just pushed a patch that (hopefully) does this.

[ffierling]

I read somewhere the tx_eob tag switches a USRP into rx mode immediately, but don't have personal experience.

[bastibl]

That would make sense. I didn't find a clear statement for that. I think, at least, some years back it only suppressed the underrun. But it might just recently have been added:

https://github.com/EttusResearch/uhd/blob/13c32cefcd6ea45e20e2eca97159ca26603ca533/host/cmake/debian/changelog#L596

(So it might really make sense to use SOB/EOB or TSB mode but both do the same thing.)

[ffierling]

I've not been able to find in GNU Radio documentation any recommended practice for tagging packet boundaries during signal processing. Isn't there a problem with the SOB/EOB approach inside an interpolation block? For example, the SOB should follow the first sample output by an interpolator and the EOB should be on the last, but the interpolator has no way of knowing this without being hard-wired for SOB/EOB, which strikes me as inelegant. Decimation of a SOB/EOB tag stream would be equally ugly. I can think of only one scenario where the TSB approach is a bit tricky, when you're splitting, then recombining a stream of samples and even there order is easily preserved.

Thoughts?

[ffierling]

The TSB approach won't work on the receive side, because a receiver can't know how many samples it's going to receive from The Real World. Perhaps what's needed are blocks to facilitate switching from one method to the other. Or a hybrid approach where the standard practice is set SOB tag value to the length if it's known, otherwise let a downstream block figure it out after the EOB is detected?

[bastibl]

Yes, you cannot directly tag samples after the antenna. You need a physical layer that detects the frame, synchronizes on the frame, and decodes the frame at least to a level that it knows its length. Then you can add tags to create a tagged stream or convert it to a PMT. Whatever you prefer. See the documentation on PMT, Tagges Streams, and packet-based operation: https://gnuradio.org/doc/doxygen/page_usage.html

When you search in GRC, you'll find many, many blocks that convert from one method to another. stream to tagged stream, PDU to tagged stream, etc. etc.

[ffierling]

I read the excellent documentation you point to before I hacked up a Tagged File Sink to recognize tx_sob and tx_eob tags. There's an argument for marking packet boundaries with tx_sob and tx_eob, pdu_length=size, even the burst=true and burst=false in Tagged File Sink, if only for legacy support. It would also be useful to tag out-of-band info, like significant changes in power levels (eg to mark when the carrier was detected and lost), but only if everyone's agreed on the same keys, values and meanings for tags.

It seems to me there's an opportunity here to improve GNU Radio if everyone agreed upon a standard practice. How would one promote such a standard? Raise the point on the discuss-gnuradio mailing list?

[ffierling]

BTW, nicely done:

[bastibl]

I'm not sure I understand you correctly. If you propose to introduce a set of standard tags to annotate the signal with metadata to describe common features, you could propose that on discuss-gnuradio or if you want to make it more verbose and formal, you could make a GREP:

[ffierling]

Yes, that's what I meant. Thanks.