Hi!
Here are my answers:
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
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>
>
> ?
> 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
>