Re: Sending a file through a LimeSDR mini with a loopback cable using PSK modulation
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 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? > > > > > On Nov 11, 2021, at 09:44, Evgeny Hahamovich > 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 > > > > > > >
I had a daughterboard UBX 160 for USRP, but after 5 months of working, it can not transmit any signal...
I had a daughterboard UBX 160 for USRP, but after 5 months of working, it can not transmit any signal... Led TX is on but on the spectrum, I can not see any data signal, I can see a weak carrier? how can repair UBX160 USRP? really it is the damage? thanks in advance
Installing Gnuradio 3.8.1 with UHD 4 with out source compiling......
I installed Gnuradio 3.8.1 in ubuntu 20.04, is it possible to install a new version of UHD like 4 instead of UHD 3.15 without source compiling... is it possible or I must compile all Gnuradio..any short way... Thanks in advance
Re: Installing Gnuradio 3.8.1 with UHD 4 with out source compiling......
You’d have to build from source since GnuRadio would have been linked against 3.15 Sent from my iPhone > On Nov 14, 2021, at 9:05 AM, sp h wrote: > > > I installed Gnuradio 3.8.1 in ubuntu 20.04, is it possible to install a new > version of UHD like 4 instead of UHD 3.15 without source compiling... > is it possible or I must compile all Gnuradio..any short way... > > Thanks in advance
Re: I had a daughterboard UBX 160 for USRP, but after 5 months of working, it can not transmit any signal...
This should have gone to the usrp-users list. But anyway: https://kb.ettus.com/Ordering_and_Fulfillment_Help#Return_Policy Sent from my iPhone > On Nov 14, 2021, at 9:00 AM, sp h wrote: > > > I had a daughterboard UBX 160 for USRP, but after 5 months of working, it can > not transmit any signal... > Led TX is on but on the spectrum, I can not see any data signal, I can see a > weak carrier? > how can repair UBX160 USRP? really it is the damage? > > thanks in advance >
Re: Sending a file through a LimeSDR mini with a loopback cable using PSK modulation
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 > On Nov 14, 2021, at 05:18, Evgeny Hahamovich 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 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? >> >> >> >> > On Nov 11, 2021, at 09:44, Evgeny Hahamovich 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 >> > >> >> >> >>
