The packet format block is not a GNURadio “in tree” block but rather a “python embedded” block. It’s a block created specifically for this tutorial that requires no installation.
https://wiki.gnuradio.org/index.php/Embedded_Python_Block <end transmission> > On Nov 14, 2021, at 05:18, Evgeny Hahamovich <evgym...@gmail.com> wrote: > > > Paul M., glad my flowchart worked for you :) > > Paul A., Thanks for the detailed reply. > Can you clarify what is the embedded Python block when you write "The access > code is created in the embedded Python block" ? > > Evgeny > >> On Fri, Nov 12, 2021 at 4:32 AM Barry Duggan <ba...@dcsmail.net> wrote: >> Hi! >> >> Here are my answers: >> >> 1. The access code is created in the Embedded Python block, and is >> 225,90,232,147 (at the end of the preamble). It is necessary for the >> receiver >> https://wiki.gnuradio.org/index.php/Correlate_Access_Code_-_Tag_Stream >> >> 2. The sync header (preamble) is the 16 decimal 85 bytes (giving alternating >> 1's and 0's. More frequent messages will hold the synchronization better >> than long delays. >> >> 3. Don't clip or saturate the signal going into the SDR. >> >> --- >> Barry Duggan KV4FV >> https://github.com/duggabe >> >> On Thu, 11 Nov 2021 11:50:36 -0500, Paul Atreides wrote: >> >> Answers below. >> Barry, can you fill in where my understanding is weak here? >> >> <end transmission> >> >> > On Nov 11, 2021, at 09:44, Evgeny Hahamovich <evgym...@gmail.com> wrote: >> > >> > ? >> > Indeed it works great out of the box :) Thanks Paul for fixing this! >> My pleasure, thanks for testing it! >> > >> > But when I upgraded the setup by replacing the ZMQ with LimeSDR (Tx on one >> > LimeSDR is transmitting to an Rx of another LimeSDR through an >> > attenuator), the Rx wasn't able to recover the message. I simplified the >> > flow by removing the resamplers and using a single sampling rate and added >> > a squelch block to the Rx to stop the idle signals and it's working well >> > this way. My Tx and Rx flowcharts are attached. >> Any time you introduce the ?real world? of hardware there are many new >> variables. Things like DC offset, dynamic range, etc. can really effect your >> outcome. >> Sounds like you stripped it down pretty aggressively. I think you need to >> get more familiar with your analog environment and play with it a bit. This >> part is not as ?drag and drop? as some of the digital parts. >> > >> > There are some questions that are still open... >> > 1. There is an access code for Rx. Where was it created? Do I need it? >> The access code is created in the embedded Python block. The code is >> commented, copy and paste the values into a Python IDE and display them as >> bits, you?ll see the sync word there. As to whether or not you need it, I >> think that?s up to you and your implementation. Generally I?d say yes, but >> you should read up on the use of sync words/access codes to understand their >> uses better. >> > 2. The Tx should send some sync header before the data, that would be used >> > by the Rx while locking on the clock frequency and this data won't be >> > recovered. I don't see such sync data here, am I correct? >> Answered above. I think it?s a difference of terminology. Again, the >> embedded block is commented and answers this question. >> > I increased the delay between every 2 messages to 5 sec and timed the >> > detected messages, it seems that part of them are not detected. Actually, >> > I am surprised that anything at all gets detected! How is the clock >> > locking so fast?! >> I think this speaks to the ?conclusions? section on the wiki that Barry >> wrote up extremely well. Read that, it will explain what your seeing. >> > 3. (a side question) Why do you multiply the signal by 1/2 before >> > transmitting? Are you aiming to get to +-1 levels to avoid clipping? >> I didn?t write the flowgraph, but I know what your talking about. There is >> probably a fundamental DSP principle here that eludes me at the moment as I >> don?t have it in front of me, but avoiding clipping sounds correct, maybe >> Barry can answer this? >> > >> > >> > Evgeny >> > >> >> <snip> >> >>
