wHi Kevin, Thank you for your response! I have looked at those examples and specifically those blocks already and I have looked at the C++ API reference. But still, as you said, each block requires a lot of studying, and currently I am just trying to find an easier to prepend a known pattern at the transmitter. Perhaps I’ll go with the more complex examples eventually. Thanks for you help anyway! Best regards, Lannan
> On Jul 24, 2020, at 10:57 PM, Kevin McQuiggin <mcqui...@me.com> wrote: > > Hi Lannan: > > I am at about the same stage as you are with packetization and am researching > quite similar requirements. I spent the last few days reading and > experimenting with some success. > > There are several blocks that can help you add length tags and headers to > your data stream. Look at the examples in your gnuradio installation such as > > /(opt or usr)/local/share/gnuradio/examples/digital/packet > > And give the several flowgraphs there a try. There is also good associated > reading in the gnuradio manual at: > > https://www.gnuradio.org/doc/doxygen/page_packet_comms.html > <https://www.gnuradio.org/doc/doxygen/page_packet_comms.html> > > I used these materials and the principles in the example flow graphs to now > having my QPSK transceiver almost running. I expect that with a bit more > effort it will be running fine early next week, as I am taking the weekend > off. > > The examples have stuff that you may not need like CRCs and forward error > correction, but you could leave those out if you wish. Focus on the packet > length tagging and header creation, and then on the header/payload demuxing > process. > > I have a loopback test flowgraph and am just working the bugs out of header > and payload recovery. It is quite detailed and the blocks need some study > because, for example, some of the packet blocks want lengths of items in > bits, while others want that info in bytes. I made errors by assuming byte > count when it turned out that the block wanted bit count. Stuff like that. > You have to read about the details of each block. > > Hope this helps, > > Kevin > > > > > > >> On Jul 24, 2020, at 2:54 PM, lannan jiang <jln...@live.com >> <mailto:jln...@live.com>> wrote: >> >> Hi everyone, >> >> Two days ago I asked something about boundary alignment, and I have been >> trying many stuff in GRC to solve this. I am stuck on this for days and any >> help will be appreciated. Below is a description of what I wish to do. >> >> 1) My transmission and receiving chain are like this: signal source -> >> constellation modulator -> Adalm Pluto Tx-> Antenna -> Adalm Pluto Rx -> >> Polyphase Clock Sync -> CMA equalizer -> Costas Loop -> decoding. As for >> modulation scheme, I am using QPSK. >> 2) Now I just want to transmit one byte output from the signal source, >> and following with one byte of a known pattern, and then one byte output >> from the signal source, etc. Then at the receiver, because i already know >> the known pattern, I need to sync to the known pattern in order to align the >> bytes, which will allow me to hear clean audio at the receiver. >> 3) There are three things I am looking for: >> a. I have been looking for a SIMPLE way to prepend a known pattern >> at the transmitter, and send it with the output bytes of a signal source. >> Is there any block that might work to do this in GRC? >> b. I have been trying to see if i can write an embedded python block >> to prepend a known pattern, but I am having a hard time trying to understand >> the input_items of the block, and how i can add a known pattern iteratively. >> c. If i can successfully send the known pattern with my data to the >> receiver, is there any easy way to parse at the receiver? >> >> Thank you in advance! >> Lannan >> >> >> >
smime.p7s
Description: S/MIME cryptographic signature
