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