search

bastibl / gr-ieee802-15-4

IEEE 802.15.4 ZigBee Transceiver
https://www.wime-project.net
GNU General Public License v3.0
270 stars 87 forks source link

SUN PHY Blocks #33

Closed ffierling closed 6 years ago

ffierling commented 6 years ago

Adds the following blocks that allow SUN PHY PDUs to be generated:

PDU Wrapper

PN9 Whitener

SUN PHR Prefixer

Example flowgraph excerpt:

sun_phy_flowgraph
ffierling commented 6 years ago

This PR implements the SUN O-QPSK PHY? (AFAIS, there are three SUN PHYs) I think, the PR implements only a part. Is this part already helpful?

Correct, 802.15.4-2015 has three SUN PHYs: FSK, OFDM and O-QPSK. SUN PHR Prefixer should work with all these PHYs, but doesn't support Mode Switch, as that has been deprecated.

PN9 Whitener is used in numerous 802.15.4 PHYs:

PDU Wrapper is not PHY-specific, it's an improved Access Code Prefixer, that allows prefixes and suffixes of up to 16 bytes each. I had to write this block because SUN FSK preambles alone are 8 bytes long. I also needed to stuff a pad byte because the stock GFSK Mod block chops off the last few symbols if you don't flush out its pipeline.

This is (part of?) a transmitter. What about the receiver?

Think of these as general purpose blocks for processing PDUs. The rest of the transmitter is just a GFSK Mod block and a Tagged Stream Multiply Length Tag. I didn't think it added value, but if you want to postpone a merge until I get the whole transceiver done, that's fine.

Did you test that with hardware? If so, which devices/chips?

Tested with:

Please add an example flow graph. (It's hard to understand the role of the blocks with a screenshot of parts of the flow graph)

See above. Will include my transceiver later.

What is the role of the wrapper and why is it needed? Aren't there any upstream blocks for that?

Yes, you can add prefixes and suffixes upstream with Tag Stream Mux and Vector Source blocks, but putting it in a replacement for Access Code Prefixer seemed more elegant to me.

Why don't you do the operations in one block. AFAIS, the blocks are tuned for that use-case and cannot be reused. So there's no benefit from modularity. Splitting it only increases complexity, irritates people in which order they are used, and requires more maintainance.

We miscommunicated then, because I understood from issue 29 that modularity was the best approach.

The history has to be cleaned up (rewrite into logical commits and rebased on top of current master)

Sorry, I'm a noob to git. I'll figure out how to do this.

bastibl commented 6 years ago

Oh, I didn't know that the Whitener can be used in multiple PHYs. So it makes sense to keep that as a separate block.

You don't need a complete transceiver, but something that already works. For example a transmitter flow graph that is able to produces frames that can be decoded by any of those chips. The VSA and SDR are not important. So if you have a transmitter for $phy that produces frames that can be received by $chip, that's fine. (But please state what your blocks do and what you tested it with. The chips that you mentioned, for example, support many PHY modes and I guess these blocks do not support all of them.)

Sorry, I'm still not convinced of the PDU wrapper. How about you use (or, if it's not generic enough, extend) the access code prefixer and use the Burst Shaper to append some zeros to flush the queues (or do as you suggested). Having yet another block (with seemingly arbitrary size limitation of 16 byte) seems unnecessary to me.

If you want, you can just keep the PR open and (force) push you changes to the branch. Thanks for working on this.

ffierling commented 6 years ago

Sorry, I'm still not convinced of the PDU wrapper. How about you use (or, if it's not generic enough, extend) the access code prefixer and use the Burst Shaper to append some zeros to flush the queues (or do as you suggested). Having yet another block (with seemingly arbitrary size limitation of 16 byte) seems unnecessary to me.

A PDU suffix is needed because the GFSK Mod block, for example, has to be flushed at its input with bytes and Burst Shaper only handles floats and complex.

I agree, PDU Wrapper and Access Code Prefixer have overlapping functionality, but it's Access Code Prefixer, with its two configurable ints, that has the arbitrary size limitation. PDU Wrapper accepts a vector of 16 bytes and is easily recompiled for whatever vector lengths you think appropriate by changing one variable. I think we should just replace Access Code Prefixer with PDU Wrapper. Unless it's acceptable to have a "suffixer" in Access Code Prefixer.

bastibl commented 6 years ago

OK, but why has the size to be hardcoded. Why can't it just accept any vector?

ffierling commented 6 years ago

Oh! Now I understand your point. I'll dynamically allocate the buffers then.