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>
>> 
>> 

Reply via email to