[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sending a file through a LimeSDR mini with a loopback cable using PS

From: Barry Duggan
Subject: Re: Sending a file through a LimeSDR mini with a loopback cable using PSK modulation
Date: Thu, 11 Nov 2021 20:32:26 -0600
User-agent: Zoho Mail


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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]