Using 2 SDRs for back and forth traffic

[aewag]

Hey, we are currently implementing the flowchart for our local setup. Idea is to have two Plutos on two dedicated machines and they communicate with each other using the IEEE802.15.4 PHY. We are using the example transceiver_qpsk flowchart. We have tested it with one SDR as receiver and one 802.15.4 capable dev board, which worked like expected.

Currently we are stuck with the setup using 2 SDRs. Sent messages from one Pluto are received all at once at the other Pluto. So not every second one message, but every ~7 seconds ~7 messages (at the time of receiving several messages at least one message is lost).

If anyone has an idea how and where to start for debugging, I would be very grateful.

Thank you, Alex

[aewag]

To see what happens at the receiver I set VERBOSE2 at the packet sink block. An example output looks like this:

Found 3 0 in chip sequence
Found 4 0 in chip sequence
Found 5 0 in chip sequence
Found 6 0 in chip sequence
Found 7 0 in chip sequence
Found first SFD
Found sync, 0x7a
Header Search bitcnt=0, header=0x00000000
Packet Build count=1327, ninput=2048, packet_len=28
packetcnt: 0, payloadcnt: 0, payload 0x41, d_packet_byte_index: 2
packetcnt: 1, payloadcnt: 1, payload 0x88, d_packet_byte_index: 2
packetcnt: 2, payloadcnt: 2, payload 0x4, d_packet_byte_index: 2
packetcnt: 3, payloadcnt: 3, payload 0xaa, d_packet_byte_index: 2
packetcnt: 4, payloadcnt: 4, payload 0x1a, d_packet_byte_index: 2
packetcnt: 5, payloadcnt: 5, payload 0xff, d_packet_byte_index: 2
packetcnt: 6, payloadcnt: 6, payload 0xff, d_packet_byte_index: 2
packetcnt: 7, payloadcnt: 7, payload 0x44, d_packet_byte_index: 2
packetcnt: 8, payloadcnt: 8, payload 0x33, d_packet_byte_index: 2
packetcnt: 9, payloadcnt: 9, payload 0x81, d_packet_byte_index: 2
packetcnt: 10, payloadcnt: 10, payload 0x0, d_packet_byte_index: 2
Samples Processed: 2048
Packet Build count=0, ninput=4096, packet_len=28
packetcnt: 11, payloadcnt: 11, payload 0x17, d_packet_byte_index: 2
packetcnt: 12, payloadcnt: 12, payload 0x2a, d_packet_byte_index: 2
packetcnt: 13, payloadcnt: 13, payload 0x48, d_packet_byte_index: 2
packetcnt: 14, payloadcnt: 14, payload 0x65, d_packet_byte_index: 2
packetcnt: 15, payloadcnt: 15, payload 0x6c, d_packet_byte_index: 2
packetcnt: 16, payloadcnt: 16, payload 0x6c, d_packet_byte_index: 2
packetcnt: 17, payloadcnt: 17, payload 0x6f, d_packet_byte_index: 2
packetcnt: 18, payloadcnt: 18, payload 0x20, d_packet_byte_index: 2
packetcnt: 19, payloadcnt: 19, payload 0x57, d_packet_byte_index: 2
packetcnt: 20, payloadcnt: 20, payload 0x6f, d_packet_byte_index: 2
packetcnt: 21, payloadcnt: 21, payload 0x72, d_packet_byte_index: 2
packetcnt: 22, payloadcnt: 22, payload 0x6c, d_packet_byte_index: 2
packetcnt: 23, payloadcnt: 23, payload 0x64, d_packet_byte_index: 2
packetcnt: 24, payloadcnt: 24, payload 0x21, d_packet_byte_index: 2
packetcnt: 25, payloadcnt: 25, payload 0xa, d_packet_byte_index: 2
packetcnt: 26, payloadcnt: 26, payload 0x8c, d_packet_byte_index: 2
packetcnt: 27, payloadcnt: 27, payload 0x8c, d_packet_byte_index: 2
Adding message of size 28 to queue
Found 0 in chip sequence
MAC: correct crc. Propagate packet to APP layer.Found 1 0 in chip sequence

Found 2 0 in chip sequence
Found 3 0 in chip sequence
Found 4 0 in chip sequence
Found 5 0 in chip sequence
Found 6 0 in chip sequence
Found 7 0 in chip sequence
Found first SFD
Found sync, 0x7a
Header Search bitcnt=0, header=0x00000000
Packet Build count=3635, ninput=4096, packet_len=28
packetcnt: 0, payloadcnt: 0, payload 0x41, d_packet_byte_index: 2
packetcnt: 1, payloadcnt: 1, payload 0x88, d_packet_byte_index: 2
packetcnt: 2, payloadcnt: 2, payload 0x6, d_packet_byte_index: 2
packetcnt: 3, payloadcnt: 3, payload 0xaa, d_packet_byte_index: 2
packetcnt: 4, payloadcnt: 4, payload 0x1a, d_packet_byte_index: 2
packetcnt: 5, payloadcnt: 5, payload 0xff, d_packet_byte_index: 2
packetcnt: 6, payloadcnt: 6, payload 0xff, d_packet_byte_index: 2
Samples Processed: 4096
Packet Build count=0, ninput=2048, packet_len=28
packetcnt: 7, payloadcnt: 7, payload 0x44, d_packet_byte_index: 2
packetcnt: 8, payloadcnt: 8, payload 0x33, d_packet_byte_index: 2
packetcnt: 9, payloadcnt: 9, payload 0x81, d_packet_byte_index: 2
packetcnt: 10, payloadcnt: 10, payload 0x0, d_packet_byte_index: 2
packetcnt: 11, payloadcnt: 11, payload 0x17, d_packet_byte_index: 2
packetcnt: 12, payloadcnt: 12, payload 0x2a, d_packet_byte_index: 2
packetcnt: 13, payloadcnt: 13, payload 0x48, d_packet_byte_index: 2
packetcnt: 14, payloadcnt: 14, payload 0x65, d_packet_byte_index: 2
packetcnt: 15, payloadcnt: 15, payload 0x6c, d_packet_byte_index: 2
packetcnt: 16, payloadcnt: 16, payload 0x6c, d_packet_byte_index: 2
packetcnt: 17, payloadcnt: 17, payload 0x6f, d_packet_byte_index: 2
packetcnt: 18, payloadcnt: 18, payload 0x20, d_packet_byte_index: 2
packetcnt: 19, payloadcnt: 19, payload 0x57, d_packet_byte_index: 2
packetcnt: 20, payloadcnt: 20, payload 0x6f, d_packet_byte_index: 2
packetcnt: 21, payloadcnt: 21, payload 0x72, d_packet_byte_index: 2
packetcnt: 22, payloadcnt: 22, payload 0x6c, d_packet_byte_index: 2
packetcnt: 23, payloadcnt: 23, payload 0x64, d_packet_byte_index: 2
packetcnt: 24, payloadcnt: 24, payload 0x21, d_packet_byte_index: 2
packetcnt: 25, payloadcnt: 25, payload 0xa, d_packet_byte_index: 2
packetcnt: 26, payloadcnt: 26, payload 0x4, d_packet_byte_index: 2
packetcnt: 27, payloadcnt: 27, payload 0x3a, d_packet_byte_index: 2
Adding message of size 28 to queue
Found 0 in chip sequence
MAC: correct crc. Propagate packet to APP layer.Found 1 0 in chip sequence

Found 2 0 in chip sequence
Found 3 0 in chip sequence
Found 4 0 in chip sequence
Found 5 0 in chip sequence
Found 6 0 in chip sequence
Found 7 0 in chip sequence
Found first SFD
Found sync, 0x7a
Header Search bitcnt=0, header=0x00000000
Packet Build count=1716, ninput=2048, packet_len=28
packetcnt: 0, payloadcnt: 0, payload 0x41, d_packet_byte_index: 2
packetcnt: 1, payloadcnt: 1, payload 0x88, d_packet_byte_index: 2
packetcnt: 2, payloadcnt: 2, payload 0x7, d_packet_byte_index: 2
packetcnt: 3, payloadcnt: 3, payload 0xaa, d_packet_byte_index: 2
packetcnt: 4, payloadcnt: 4, payload 0x1a, d_packet_byte_index: 2
Samples Processed: 2048
Packet Build count=0, ninput=1024, packet_len=28
packetcnt: 5, payloadcnt: 5, payload 0xff, d_packet_byte_index: 2
packetcnt: 6, payloadcnt: 6, payload 0xff, d_packet_byte_index: 2
packetcnt: 7, payloadcnt: 7, payload 0x44, d_packet_byte_index: 2
packetcnt: 8, payloadcnt: 8, payload 0x33, d_packet_byte_index: 2
packetcnt: 9, payloadcnt: 9, payload 0x81, d_packet_byte_index: 2
packetcnt: 10, payloadcnt: 10, payload 0x0, d_packet_byte_index: 2
packetcnt: 11, payloadcnt: 11, payload 0x17, d_packet_byte_index: 2
Found a not valid chip sequence! 27590856

Above the valid package there are like ~6 or more valid packages all at once.

[bastibl]

That's a peculiarity of the Pluto, which uses fixed size buffers. It looks like the frames are so short that seven of them fit in one buffer before it is transmitted. IIRC, you can adjust the buffer size in the Sink block. If you have fixed sized frames you can add padding, such that each (padded) frame fills exactly one transmit buffer. If you have frames with variable length, you'd have to add padding depending on the length of the frame. I'm not sure if this is supported out of the box, i.e., you might have to write a simple block for that.

[aewag]

That's a peculiarity of the Pluto, which uses fixed size buffers. It looks like the frames are so short that seven of them fit in one buffer before it is transmitted. IIRC, you can adjust the buffer size in the Source block. If you have fixed sized frames you can add padding, such that each (padded) frame fills exactly one transmit buffer. If you have frames with variable length, you'd have to add padding depending on the length of the frame. I'm not sure if this is supported out of the box, i.e., you might have to write a simple block for that.

This explains the behavior I have seen at the packet sink log output. Thank you! I will try to test it and come back.

[aewag]

Your workaround for fixed messages did the trick. Either changing the Buffer Size of the PlutoSDR Sink according to the size of one message or padding the stream with 0s works. Our solution for padding a message with a fixed size was using the Stream Mux Block with the supposed stream and a constant source as input. Thank you for your help! By now I didn't write a block yet, but I will give it a try as having the possibility for variable message size would be really helpful. I will add a comment if it lead to something usable.

[aewag]

Sorry for the late reply in that issue. I was experimenting quite a bit with the blocks. A block is written, that does the padding for different lengths, but i experience a strange behavior: The work function gets only called after another second tagged stream arrives at the block. So the message before gets pushed to the output, but is now delayed.

I tried to look into your padding blocks and there the same issue seems to be happening. Screenshot of the GRC:

I write packets to the UDP source, the first Tag Debug block immediately prints to the terminal, but the second Tag Debug prints after I send another packet.

Is this something you experienced as well? Also maybe something Gnuradio specific I miss?

[bastibl]

That's a common issue with GNU Radio. The first Tag Debug blocks sees the start of the frame. The Packet Pad2 block is a Tagged Stream block that only continues when it gets the whole frame. The problem is usually a filter in the modulator (or in this case the Delay block) that are not flushed at the end of the packet. The last two samples of the packet, therefore, stall until the next frame adds more data. This is when the Packet Pad2 block gets the whole frame and continues to send it out.

[aewag]

Thank you for your answer! I wasn't really sure where this weird behavior is coming from and where to llok further. I changed the PHY Hier block a bit and disabled each of the blocks, one after another. Disabling the Burst Shaper block did lead to the expected behavior with a tagged stream running through the whole flowchart (also possible: setting the number of padding to 0).

It seems to match with this mail on the mailing list: https://gnuradio.blogspot.com/2019/01/discuss-gnuradio-burst-shaper-block.html

Do I understand it correctly that in the current PHY Hier block the burst shaper block is only used to postpad some 0s at the end of a tagged stream? If so, I would try to exchange that block with a tagged stream block that does the same job.

[bastibl]

This is really weird. I'm not yet sure what exactly is going on, but you could try:

• change the tag name of the transmitter from pdu_length to packet_len
• replace the burst shaper with a packet pad2 block
• add 8 samples at the end

If that works for you, I'll change the flow graphs.

[aewag]

That works! Nice.

But just for my understanding: Padding only works with a multiple of 8. Is this connected to any buffer sizes (padding with, for example, 10 samples does not work in the current flowchart)?

Regarding the issue with the fixed buffer sizes of the pluto sdr: I now have a block that appends 0s until the tagged stream length matches the buffer size to enforce immediate transmission. That block could match quite well to your padding blocks in your gr-foo module. Do you think it makes sense to include it? If so, i would add it and create a PR.

[bastibl]

Happy it works. I just pushed an update. As I said, I'd have to look further into it to figure out what exactly caused frames to stall.

If I understand you correctly, the block reads the length tag and then adds padding as needed to fit the a given buffer size? That sounds pretty cool. I wonder what's the best place to put that block. In GNU Radio, in gr-iio, or in gr-foo. I'd be happy to add it to gr-foo, but the other repos might be more visible. I'd guess such a block would be useful to many users.

[aewag]

Just moved from Gnuradio 3.7 to 3.8. Workaround is running like expected.

Yep, that is basically what the block does. In GRC you can specify the desired buffer size and the block then pads every incoming tagged stream until the length matches the buffer size.

[bastibl]

Great. I guess we can close the issue. Think about what you want to do with the block. Feel free to open a PR against gr-foo.