GNU Radio, One Step at a Time: November 2020

Monday, November 30, 2020

Re: how to auto detect peak frequency in QT FFT sink

Hi Kyle,

is there any document for how to use the block in gr-fhss-utils especially for fft peak block. what is the two output of fft peak?

From: Kyle A Logue <kyle.a.logue@aero.org>
Sent: Friday, November 20, 2020 12:26 AM
To: james jordan <james.jordan.999@hotmail.com>; discuss-gnuradio@gnu.org <Discuss-gnuradio@gnu.org>
Subject: Re: how to auto detect peak frequency in QT FFT sink

cmake version is too low so i can not build gr-fhss

gr-fhss has a 3.7 and a 3.8 version if you check the tags on github

how to store max result to a gui label?

qt-number-sink maybe

From: james jordan <james.jordan.999@hotmail.com>
Sent: Wednesday, November 18, 2020 22:07
To: Kyle A Logue <kyle.a.logue@aero.org>; discuss-gnuradio@gnu.org <Discuss-gnuradio@gnu.org>
Subject: Re: how to auto detect peak frequency in QT FFT sink

Hi Kyle,

Thanks. my cmake version is too low so i can not build gr-fhss. i try to use fft->max but how to store max result to a gui label?

From: Kyle A Logue <kyle.a.logue@aero.org>
Sent: Thursday, November 19, 2020 4:05 AM
To: james jordan <james.jordan.999@hotmail.com>; discuss-gnuradio@gnu.org <Discuss-gnuradio@gnu.org>
Subject: Re: how to auto detect peak frequency in QT FFT sink

2 things that come to mind:

stream -> fft -> argmax
in sandia fhss utilities they have an FFT Peak block that does what you want

https://github.com/sandialabs/gr-fhss_utils

Kyle Logue

Senior Engineering Specialist

⚝ The Aerospace Corporation

From: Discuss-gnuradio <discuss-gnuradio-bounces+kyle.a.logue=aero.org@gnu.org> on behalf of james jordan <james.jordan.999@hotmail.com>
Sent: Monday, November 16, 2020 19:09
To: discuss-gnuradio@gnu.org <Discuss-gnuradio@gnu.org>
Subject: how to auto detect peak frequency in QT FFT sink

Hi all,

i want to see the fft of the signal and also want to detect the peak frequency if there is a peak signal.

how to achieve this?

Re: GNURADIO doesn't find USRP B205

Also you have two UHD versions on your system.

3.15 for your uhd_usrp_probe and 3.13 is what Gnu Radio is linked against.

Sent from my iPhone

> On Nov 30, 2020, at 12:37 PM, jean-michel.friedt@femto-st.fr wrote:
>
> you forgot to highlight in your message the answers given by libuhd:
>
>> Set the environment variable 'UHD_IMAGES_DIR' appropriately or follow the below instructions to
>> download the images package.
>>
>> Please run:
>>
>> "/usr/lib/arm-linux-gnueabihf/uhd/utils/uhd_images_downloader.py"
>
> JM
>

Re: GNURADIO doesn't find USRP B205

you forgot to highlight in your message the answers given by libuhd:

> Set the environment variable 'UHD_IMAGES_DIR' appropriately or follow the below instructions to
> download the images package.
>
> Please run:
>
> "/usr/lib/arm-linux-gnueabihf/uhd/utils/uhd_images_downloader.py"

JM

GNURADIO doesn't find USRP B205

Hi,

I've connected a B205mini with a Raspberry Pi4 (Raspbian OS).

The Raspberry has discovered as follows.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

pi@raspberrypi:~ $ uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700; UHD_3.15.0.HEAD-0-gaea0e2de
[INFO] [B200] Loading firmware image: /usr/local/share/uhd/images/usrp_b200_fw.hex...
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
serial: 31CB597
name: B205i
product: B205mini
type: b200

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

But using the USRP in a source block the following error occurs.

(also if I made a dedicated entry of the serial number as device address)

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Generating: '/home/pi/top_block.py'

Generating: '/home/pi/top_block.py'

Executing: /usr/bin/python2 -u /home/pi/top_block.py

qt5ct: using qt5ct plugin
[32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 8.2.0; Boost_106700; UHD_3.13.1.0-3
[33;1m[WARNING] [B200] [39;0mEnvironmentError: IOError: Could not find path for image: usrp_b200_fw.hex

Using images directory: <no images directory located>

Set the environment variable 'UHD_IMAGES_DIR' appropriately or follow the below instructions to download the images package.

Please run:

"/usr/lib/arm-linux-gnueabihf/uhd/utils/uhd_images_downloader.py"
Traceback (most recent call last):
File "/home/pi/top_block.py", line 164, in <module>
main()
File "/home/pi/top_block.py", line 152, in main
tb = top_block_cls()
File "/home/pi/top_block.py", line 75, in __init__
channels=range(1),
File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line 122, in constructor_interceptor
return old_constructor(*args)
File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line 2782, in make
return _uhd_swig.usrp_source_make(*args)
RuntimeError: LookupError: KeyError: No devices found for ----->
Device Address:
serial: ""

>>> Done

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I would be vry pleased to get some hints to solve the problem.

Regards,

Jens

DL1WW

GR-Radar FMCW Detection

Hello,

I am attempting to use gr-radar with an sdr to design a monostatic FMCW ranging system. The FMCW detector has three messages it receives and sends out one message. Has anybody been able to successfully integrate this with the rest of the gr-radar blocks? If so, which blocks did you use to pass the messages in?

Thank you,

Alex

Sunday, November 29, 2020

Post on Gnu Radio Companion filtering

Evening, everyone! Long time listener, first-time caller and all that.

I've been using Gnu Radio Companion for the past, few years. I've been compiling notes on how to use use it along the way. I've started posting on my website how GRC works (to the best of my ability, as I'm not a programmer). I did a few posts on the various ways to make a frequency demodulator in GRC, and my latest is on basics of filtering with GRC.

Frequency demodulator posts:
http://www.site2241.net/november2019.htm
http://www.site2241.net/may2020.htm
http://www.site2241.net/august2020.htm

Post on filtering: http://www.site2241.net/december2020.htm

I'm putting together more explainers as I go, time permitting.

Comments, questions and corrections are welcome!

Gary

Saturday, November 28, 2020

Re: Help Wanted: GR Ham Radio group

Hi Ray,

Thank you for your response! I've been retired for 18 years, but I've
been busier since I've been working with GNU Radio than I was before.

I look forward to your participation (and learning what a GOLF-Tee is ;).

73,
Barry Duggan KV4FV
https://github.com/duggabe

On 11/28/20 5:10 PM, Ray Roberge wrote:
> Barry,
>
> My plan was to start in January to help with your new group and with the
> Documentation (by adding working examples with notes).
>
> I just finished one job and will be finishing another in the next few
> weeks. [ Even being semi-retired I'm busier than before! ]
>
> I know this doesn't answer your call for a volunteer, but I wanted you
> to know your not alone in this group effort.
>
> FYI: For Ham stuff I'm the SDR lead for the upcoming AMSAT GOLF-Tee
> satellite. I also have a bunch of SDRs: Ettus E110, E310, N210,
> B205mini, X310, Airspy HF+, Hack RF, ALALM Pluto and RTL-SDRs. I've
> used them all in Ham Radio and professionally. Like you, I'm a retired
> Engineer (Radar Systems Engineer).
>
> Perhaps in February I can do a talk and a show and tell on some GOLF-Tee
> progress (Ettus E310 will be in space, ADALM Pluto in my test Ground
> station).
>
> So hopefully, help by others and myself is on the way.
>
> 73,
> Ray Roberge
> WA1CYB
> rr@ieee.org
> rayroberge@yahoo.com
>
> p.s. If you want me to run any of your documentation flowgraphs with
> hardware just let me know.
>
>
>
> ************************************************************************************
> 1. Help Wanted: GR Ham Radio group (Barry Duggan)
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 28 Nov 2020 09:23:41 -0600
> From: Barry Duggan <barry@dcsmail.net <mailto:barry@dcsmail.net>>
> To: Discuss Gnuradio <discuss-gnuradio@gnu.org
> <mailto:discuss-gnuradio@gnu.org>>
> Subject: Help Wanted: GR Ham Radio group
> Message-ID: <dc770999-967f-3572-ac2b-71f05202681e@dcsmail.net
> <mailto:dc770999-967f-3572-ac2b-71f05202681e@dcsmail.net>>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> The GNU Radio Amateur Radio monthly meeting group has had two meetings
> so far, with a third scheduled for 12 December. For this group to
> continue, I need help!
> * More people are needed to present a topic and lead discussion about it.
>
> * I need someone to take the lead for this group. I have my hands full
> with Documentation!
>
> FYI: for next meeting, see
> https://wiki.gnuradio.org/index.php/Talk:HamRadio#Saturday_12_December_2020_16:00_UTC
>
> 73,
> --
> Barry Duggan KV4FV
> https://github.com/duggabe
>
>

Re: Help Wanted: GR Ham Radio group

Hi Michael,

Thank you for your response! Are you currently using GNU Radio in your
ham operations? Is there a topic you would like to present?

I look forward to hearing from you.

73,
Barry Duggan KV4FV
https://github.com/duggabe

P.S. Please CC: discuss-gnuradio@gnu.org in your response (or Reply All).

On 11/28/20 10:53 AM, Michael Chen wrote:
> Hi,Barry,
>
> I would like to do something to help.
>
> Michael Chen, BD5RV/4
> AMSAT-China: http://www.camsat.cn
> -----------------------------------
> Twitter: http://twitter.com/bd5rv
> Email: michael.bd5rv@gmail.com <mailto:michael.bd5rv@gmail.com>
> Skype: michael-bd5rv
>
>
> On Sat, Nov 28, 2020 at 11:24 PM Barry Duggan <barry@dcsmail.net
> <mailto:barry@dcsmail.net>> wrote:
>
> The GNU Radio Amateur Radio monthly meeting group has had two meetings
> so far, with a third scheduled for 12 December. For this group to
> continue, I need help!
> * More people are needed to present a topic and lead discussion
> about it.
>
> * I need someone to take the lead for this group. I have my hands full
> with Documentation!
>
> FYI: for next meeting, see
> https://wiki.gnuradio.org/index.php/Talk:HamRadio#Saturday_12_December_2020_16:00_UTC
>
> 73,
> --
> Barry Duggan KV4FV
> https://github.com/duggabe
>

Help Wanted: GR Ham Radio group

The GNU Radio Amateur Radio monthly meeting group has had two meetings
so far, with a third scheduled for 12 December. For this group to
continue, I need help!
* More people are needed to present a topic and lead discussion about it.

* I need someone to take the lead for this group. I have my hands full
with Documentation!

FYI: for next meeting, see
https://wiki.gnuradio.org/index.php/Talk:HamRadio#Saturday_12_December_2020_16:00_UTC

73,
--
Barry Duggan KV4FV
https://github.com/duggabe

Thursday, November 26, 2020

Re: Variable delay

Also note that there's already a message port for the delay_impl.cc
that Mike added earlier this year on master:

If you want to use message passing to build an asynchronous feedback,
that's what you'd want to do. We don't port all features that are added
on master automatically back to 3.8 – but if you want to cherry-pick
that onto maint-3.8, Hassan, and make a pull request out of it, that
would be a nice contribution to GNU Radio!

Best regards,
Marcus

On 25.11.20 18:55, Paul Boven wrote:
> Hi Hassan,
>
> On 11/25/20 6:27 PM, Hassan Khalili wrote:
>> I have a delay block in my flowgraph. Is it possible to change the
>> delay programmatically based on a stream output further down (in a
>> feedback fasion)? Or do I have to implement my own delay block with an
>> additional input for a delay stream?
>
> You can use a variable in the delay block, and then update it using e.g.
> ZMQ or XMLRPC messages. Direct feedback in a GNU Radio flowchart is not
> possible, you can't have loops in a flowchart.
>
> Regards, Paul Boven.
>

Wednesday, November 25, 2020

Re: Variable delay

Hi Hassan,

On 11/25/20 6:27 PM, Hassan Khalili wrote:
> I have a delay block in my flowgraph. Is it possible to change the delay
> programmatically based on a stream output further down (in a feedback
> fasion)? Or do I have to implement my own delay block with an additional
> input for a delay stream?

You can use a variable in the delay block, and then update it using e.g.
ZMQ or XMLRPC messages. Direct feedback in a GNU Radio flowchart is not
possible, you can't have loops in a flowchart.

Regards, Paul Boven.

Variable delay

Hi all,

I have a delay block in my flowgraph. Is it possible to change the delay programmatically based on a stream output further down (in a feedback fasion)? Or do I have to implement my own delay block with an additional input for a delay stream?

Kind regards,

Hassan

Information from UHF/VHF satellite ground station operators

Hi everybody,

I'm looking for some input from satellite ground station operators. Could you help me by filling the short questionnaire below:

Link: https://forms.gle/7EpcUmvdr1Xcvk1o6

Regards,

Moses.

Re: Issue in pack repack block? (former Issue in file sink block)

The decimation factor is 220 = 1056 kHz/4,8 Khz (I incorrectly let 1 in my flowgraph screen copy)
You don't need the signal source at 16.9 Khz ! (The signal is center on 0Hz so it is already translated at 0. )

Regards

On 25/11/2020 12:57, Maitry Raval wrote:

Hello sir,

Thank you for your guidance. I have understood your suggestion and based on that I have implemented below task.

QPSK modulated transmission

pattern: 1100

symbol rate: 4.8 ksps

Receive and record the same with 1056 ksps sampling rate

so, samples per symbol = 1056/4.8= 220

after low pass filtering with decimation =55

Samples/symbol=4

Please find attached grc file for the reference. With this, I have received 11101110 instead of 1100. I think, we are very near to final solution. but there is something still went wrong.

Kindly guide. thank you for your support.

With Best Regards,
Maitry Raval,
R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com

From: "Christophe Seguinot" <christophe.seguinot@orange.fr>
To: "Maitry Raval" <maitry.raval@azistaaerospace.com>
Cc: "discuss-gnuradio" <discuss-gnuradio@gnu.org>
Sent: Tuesday, November 24, 2020 6:30:35 PM
Subject: Re: Issue in pack repack block? (former Issue in file sink block)

Hi

Sorry my last email was sent before completion.....

I Think we are on the way to a working solution. Your error is in the decimation which can not be done at the end of the demodulation flowgraoh. May be you confused "sample per second" and "symbol per second" !

CMA equalizer is using " sps : Number of samples per symbol of the input signal" (copy of block documentation)

the output of CMA equalizer and Costas loop (as well as all blocks found after these ones) is fixed to 1 sample par sample. The output of Costas Loop give one symbol per sample, if you decimate it, you select 1 symbol each 220 transmitted symbols!

Let say:

RFComm operate at a sampling rate Fs (1056 kHz or K sample per second)

QPSK bit rate is Db=2.4 kbps and symbol rate Ds=Db/2 (1.2 kbauds=k symbol per second) NOT 528ksps as you said)

So you input signal must use Fs and it correspond to a Fs/Dd = sps sample per symbol (880)

This sps is very high

its too much for the polyphase clock sink

Its also indicates that your bandwidth is 1.056 MHz while your signal bandwidth is Ds(1+alpha) (close to 1500 Hz) alpha being the emitter rool-off factor

and as a consequence, the samples signal contains your narrow band modulated signal and a wider band noise whose power can be high.

Solution

you must decimated your incoming signal to get a reasonable sps (4 is generally enough)

you must filter this incoming signal to reduce noise level

this can be achieved in one step using a decimating low pass filter with decimation Dc=220, this will give you a sampling rate of Fs/Dc=4800 Hz which is 4*Db=sps*Db

The flowgraph belowuses a wide transition bandwith in order to reduce the number of taps (100 approximately). The transition bandwidth can be decreased.

In the present flowgraph sampling rates are:

1056 kHz at the input (880 sps )

4800 Hz at low pass filter output and Polyphase block (4 sps)

1200 Hz at CMA equalizer and after ( 1 s psp)

Regards

On 24/11/2020 12:47, Maitry Raval wrote:

Hello sir,

As I assume, for my SDR which is ADRV9361-Z7035, the minimum sample rate I can set is 526 KSPS for reception as ad9361 ADC min sample rate is 25 msps and max decimation rate = 48 , so minimum sample rate for reception for this SDR will be 526 ksps.

that's why I have to receive modulated signal with higher sample rate in SDR and then need to down convert to the required data rate for demodulation.

Please guide, Is this the right assumption ?

In parallel, I can do one thing, that I will transmit QPSK modulated signal with higher symbol rate let's say 1 Msps or data rate 2 mbps and receive via SDR with the same data rate.

( Here for QPSK demodulation in GNU radio, I am assuming the setting of data rate will be : sample rate = 4 msps, samples/symbol=4, this will set 1 msps or 2 Mbps ).

In short, I will try by putting same data rate set with my external transmitter and SDR with GNU radio to verify weather the exact data will be received or not?

Kindly guide.

With Best Regards,
Maitry Raval,
R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com

From: "Christophe Seguinot" <christophe.seguinot@orange.fr>
To: "Maitry Raval" <maitry.raval@azistaaerospace.com>
Cc: "discuss-gnuradio" <discuss-gnuradio@gnu.org>
Sent: Tuesday, November 24, 2020 4:42:57 PM
Subject: Re: Issue in pack repack block? (former Issue in file sink block)

Hi

Think we are on the way to a working solution. Your error is in the decimation which can not be done at the end of the demodulation flowgraoh.

CMA equalizer is using " sps : Number of samples per symbol of the input signal" (copy of block documentation)

the output of CMA equalizer and Costas loop (as well as all block found after these ones) is 1 sample par sample. The output of Costas Loop give one symbol per sample, if you decimate it, you get 1 symbol each 220 transmitted symbols!

Let say:

RFComm operate at Fs (1056) ksps

QPSK bit rate is Db=2.4 kbps and symbol rate Ds=Db/2 (1.2 kbauds=k symbol per second) NOT 528ksps as you said)

So you input signal must use sps=Fs,

On 24/11/2020 11:08, Maitry Raval wrote:

Dear Sir,

Sorry for the misunderstanding.

Please find below answers.

What is your 10011000111101.txt file ?

is it the modulator input sequence of bits: Ans: No, the .txt file is the modulated signal recorded via external transmitter. Please check the attached testing diagram for your reference). and then I have recorded in the file named 10011000111101.txt file.

is it the modulated signal recorded in the mpsk_stage6.grc (output of constellation modulator): Ans: It is the modulated signal recorded via external transmitter.

if 2: the polyphase clock sync has "output SPS"=2, then this should be adjusted accordingly in the CMA equalizer

Ans: Yes, I understand.

What is the (bypassed) decimation filter with a 220 decimation factor !

Ans: As transmitted data rate is 2.4 kbps . and SDR's minimum rate is 526 ksps. so, I have received and record samples with sample rate of 1056 ksps. ( with sample rate=1056 ksps, samples/symbol=4, data rate will be 528 ksps for qpsk) after that, before demodulation, we need to decimate upto 2.4 kbps. that's why there is a use of decimating filter with 220 decimation)

I would suggest for rapid debugging:

1- implement in a single flowgraph :

the modulator (with a file source of bits)

the demodulator

a comparison of input and output bits

Ans: Done, and input/output bits matches.

2- then add a channel model to simulate a TX/Rx connection

2bis- then optionnally separate flowgraph in 2 :Modulator , demodulator

the modulator records modulated signal (tx.txt)

the demodulator input is this modulated tx.txt signal

Compare output bits to incoming bits

Ans: Both activities done, separate flow graph in 2 and compared output bits to incoming bits and matched.

3- If 2 (2-bis) works, test the same with random bit sequence

Ans: Tested. Input and output bits matched.

4- remove channel and replace file sink in modulator by a real modulator i.e. SDR Sink and replace file source in demodulator by a real SDR source (you can have both in the same flowgraph

Ans: In this task, instead of SDR sink, I have used my external transmitter with QPSK modulation at 2.4 kbps. stored modulated samples with fmcomm source with sample rate of 1056 ksps. after that, I have used qpsk demod grc file to demodulation and store the data in file.

In this implementation, I have not received the transmitted sequence. Please guide.

With Best Regards,
Maitry Raval,
R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com

From: "Christophe Seguinot" <christophe.seguinot@orange.fr>
To: "Maitry Raval" <maitry.raval@azistaaerospace.com>
Cc: "discuss-gnuradio" <discuss-gnuradio@gnu.org>
Sent: Monday, November 23, 2020 6:06:52 PM
Subject: Re: Issue in pack repack block? (former Issue in file sink block)

I'm completely lost:

What is your 10011000111101.txt file ?

is it the modulator input sequence of bits

is it the modulated signal recorded in the mpsk_stage6.grc (output of constellation modulator)

if 1: you cannot demodulate a sequence of bits, it make no sense

if 2: the polyphase clock sync has "output SPS"=2, then this should be adjusted accordingly in the CMA equalizer

What is the (bypassed) decimation filter with a 220 decimation factor !

I would suggest for rapid debugging:

1- implement in a single flowgraph :

the modulator (with a file source of bits)

the demodulator

a comparison of input and output bits

2- then add a channel model to simulate a TX/Rx connection

2bis- then optionnally separate flowgraph in 2 :Modulator , demodulator

the modulator records modulated signal (tx.txt)

the demodulator input is this modulated tx.txt signal

Compare output bits to incoming bits

3- If 2 (2-bis) works, test the same with random bit sequence

4- remove channel and replace file sink in modulator by a real modulator i.e. SDR Sink and replace file source in demodulator by a real SDR source (you can have both in the same flowgraph

...

Regards

On 23/11/2020 12:13, Maitry Raval wrote:

Hello,

Yes, I understand both the points. and we are working on the installation of GR 3.8.

In parallel, I have done implementation of QPSK demodulation( please find attached grc file ) , I have followed below points.

1. QPSK( without differential encoding) and with filter=1 modulated carrier transmission with carrier frequency of 2 GHz with data rate of 528 ksps.

2. Receive and record the same with fmcomm source block and file sink with 1.056 Msps ( as samples/symbol will be 4)

3. offline qpsk demodulation with the attached GRC file to receive the transmitted binary sequence in file sink and convert it to binary.

But, when I have done that, the data of the output file is some random not as transmitted. as of now i am doing transmitter and receiver interfacing via RF cable( bench test) , so I don't think there may ne any noise related issue.

I think , there is an issue of sync between transmitter and receiver/recorded via FMComm source block.

Kindly guide as I want to use external transmitter for QPSK modulation and GNU radio with SDR for QPSK demodulation and data storage.

Please help what I am missing over here/

With Best Regards,
Maitry Raval,
R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com

From: "Christophe Seguinot" <christophe.seguinot@orange.fr>
To: "Maitry Raval" <maitry.raval@azistaaerospace.com>
Cc: "discuss-gnuradio" <discuss-gnuradio@gnu.org>
Sent: Monday, November 23, 2020 2:54:56 PM
Subject: Re: Issue in pack repack block? (former Issue in file sink block)

Hi

Your File source is miss configured. For a new.txt 12 bits sequence, use length=12 (I don't know how GR interpret length=0)

>> the starting bit of the sequence is random from the transmitted 12 bit sequence

Yes in any receiver, first received bits are corrupted and unusable (the receiver takes some time to synchronize carrier frequency and do symbol timing recovery) . if you know a part of the transmitted bits let call if a starting_sequence, you can use correlation of starting_sequence and output to find out the starting_sequence inside output bits..

regards

On 23/11/2020 07:07, Maitry Raval wrote:

Dear Sir,

Thank you for the response.

GNU 3.8 version debugging is under process. In parallel, I have implemented the attached GRC file as per given suggestion from your end.

After that, I have received the output file same as transmitting sequence. I have checked it in https://mothereff.in/binary-ascii.

But, only issue is that, the stored starting bits are different ( please find attached stored output file for transmitting sequence: 1001100011101. ) you will see a starting bits are different, if we convert that to binary

We will get a invalid data.

also , the starting bit of the sequence is random from the transmitted 12 bit sequence. so, when we transmit more bits (long transmitting sequence or any random sequence) it is very hard to find the starting bit.

Is it because of the GNU radio version we are using or any other issue or the use of ASCII to binary converter? I don't understand , please guide.

Thank you for your support in advance.

With Best Regards,
Maitry Raval,
R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com

From: "Christophe Seguinot" <christophe.seguinot@orange.fr>
To: "Maitry Raval" <maitry.raval@azistaaerospace.com>
Sent: Friday, November 20, 2020 4:59:54 PM
Subject: Re: Issue in pack repack block? (former Issue in file sink block)

HI,

As I don't use Widows, I could not realy at this.

Its seems this error is not related to GR but see here 53 last posts) if ti can help or ask on the discuss list

https://forum.qt.io/topic/110540/qt-qpa-plugin-could-not-find-the-qt-platform-plugin-windows-in-qtlib-plugins-platforms/15

regards

On 20/11/2020 08:40, Maitry Raval wrote:

Dear Sir,

I have done the installation of 3.8 GNU radio version in order to implement the same that you are saying in the previous mail. But, it seems to have problem in QT GUI initialization with 3.8 version of GNU radio. I have attached the snapshot for your reference. Please guide.

With Best Regards,
Maitry Raval,
R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com

From: "Christophe Seguinot" <christophe.seguinot@orange.fr>
To: "Maitry Raval" <maitry.raval@azistaaerospace.com>
Sent: Friday, November 13, 2020 2:38:37 PM
Subject: Re: Issue in pack repack block? (former Issue in file sink block)

I forget to mention that I was not able to use an online ascii2bin decoder (i tested https://www.rapidtables.com/convert/number/ascii-to-binary.html).

I used okteta (Linux tool).

On 13/11/2020 08:46, Maitry Raval wrote:

Dear Sir,

I have tried as per given suggestion from you by using unpack =1 followed by repack with k=1, I=8 with MSB endianness . Please find attached for your reference.but didnot get the expected result.

Please guide.

With Best Regards,
Maitry Raval,
R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com

From: "Christophe Seguinot" <christophe.seguinot@orange.fr>
Cc: "Maitry Raval" <maitry.raval@azistaaerospace.com>
Sent: Thursday, November 12, 2020 9:06:44 PM
Subject: Re: Issue in pack repack block? (former Issue in file sink block)

May be you should replace your repack block with:

on unpack with k=1 (i did that to recover bits)

and a repack with k=1, l=8, and MSB Endianness

On 12/11/2020 16:17, Christophe Seguinot wrote:

Hi,

I've been investigating the pack /unpack /repack block since the problem raised by Maitry where not originating from modulation/demodulation (which I tested and was correct).

Maitry did some test using repetitive pattern of bits such as 1100, 1010,, and lead to the conclusion that its file sink was correct (*).

I did similar test with small repetitive pattern but found that only some of them give correct file sink (see explanation further)

From this it seems that somewhere in its flowgraph bytes to bit or bits to bytes conversion.

The attached flowgraph (GR 3.8 and 3.9, not compatible with GR 3.7) illustrates my investigation. Running this flowgraph shows that whatever conversion is in use give the same series of bytes and bits.

However, in order to obtain this I had to set endianness to MSB for both repack blocks (all other blocks set to LSB). Il all endianness are set to LSB, repack blogk reverse bit ordering compared to pack/unpack blocks, OR uses symmetric pattern as Maitry does (*).

I was expecting that unpack(8) and repack(8,1) should give the same result

What am I missing or misunderstanding ?

Or is this a bug?

Maitry, please try to set Endianness to MSB in your repack block. Not sure it cans solve your issue!

Regards,

On 11/11/2020 09:30, Maitry Raval wrote:

Dear sir,

Thank you for your response.

As I have a final application to use only demodulation and data storage using GNU radio as my transmitter is external. after that also I am facing an issue for stored data which is random not as transmitted. so request you to please guide me further in this demodulation.

Thank you in advance

With Best Regards,
Maitry Raval,
R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com

From: "Christophe Seguinot" <christophe.seguinot@orange.fr>
To: "Maitry Raval" <maitry.raval@azistaaerospace.com>
Cc: "discuss-gnuradio" <discuss-gnuradio@gnu.org>
Sent: Wednesday, November 11, 2020 1:53:34 PM
Subject: Re: Issue in file sink block

Hi

I've been investigating but did not yet found the origin of this problem. I'm working under GR 3.9/Ubuntu 20.04

the bit sequence is correctly demodulated, whatever the source (txt or random) is. There is a 58 sample delay between bit source and demodulated bit. (so modulation/demodulation is OK)

however, the received bytes don't match the emitted bytes.

I'm further investigating if "pack bits" and "unpack bits" block are used correctly (I'm not familiar to them)

Regards

On 11/11/2020 04:25, Maitry Raval wrote:

Hello,

I think there is some misunderstanding here, I am using the attached grc file which includes all the ok blocks such as polyphase clock sync, costas loop, CMA equilizer etc for demodulation. Please check the attached file. for the attached grc, I am facing the below issue.

I understand that I have use online ASCII to binary converter and for that I am using below online converter.

https://www.rapidtables.com/convert/number/ascii-to-binary.html

But I am facing an issue, while I am transmitting repetitive pattern such as 1100, 1010 , the data stored in the file after mod-demod is almost similar( only some initial bits are changed) . Please check the screenshot attached.

But when I am transmitting some random pattern instead of repetitive using file source, I am not receiving the same pattern, while I am converting the stored ASCII to binary using converter.

Please help.

With Best Regards,
Maitry Raval,
R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com

From: "Cinaed Simson" <cinaed.simson@gmail.com>
To: "Maitry Raval" <maitry.raval@azistaaerospace.com>
Cc: "discuss-gnuradio" <discuss-gnuradio@gnu.org>
Sent: Wednesday, November 11, 2020 12:51:54 AM
Subject: Re: Issue in file sink block

Hi Maitry - okay, then Marcus has already updated you - DPSK Mod is depreciated.

That is, it has bugs which can't or won't be fixed and is no longer supported.

-- Cinaed

On 11/9/20 7:43 PM, Maitry Raval wrote:

Hello,

I understand that I have use online ASCII to binary converter and for that I am using below online converter.

https://www.rapidtables.com/convert/number/ascii-to-binary.html

But I am facing an issue, while I am transmitting repetitive pattern such as 1100, 1010 , the data stored in the file after mod-demod is almost similar( only some initial bits are changed) . Please check the screenshot attached.

But when I am transmitting some random pattern instead of repetitive using file source, I am not receiving the same pattern, while I am converting the stored ASCII to binary using converter.

I have sent the GRC file in previous mail. Kindly let me know, where is the problem?

Waiting for your positive response.

With Best Regards,
Maitry Raval,
R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com

From: "Cinaed Simson" <cinaed.simson@gmail.com>
To: "discuss-gnuradio" <discuss-gnuradio@gnu.org>
Sent: Monday, November 9, 2020 1:15:51 PM
Subject: Re: Issue in file sink block

Hi Maitry - if by update you mean dumping a binary file as binary instead of hexadecimal, then on Linux use

xxd -b <infile> <outfile>

-- Cinaed

On 11/8/20 8:13 PM, Maitry Raval wrote:

Hello experts,

Any updates?

With Best Regards,
Maitry Raval,
R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com

From: "Aditya Arun Kumar" <adityaarunkumarphi@gmail.com>
To: "Maitry Raval" <maitry.raval@azistaaerospace.com>
Cc: "discuss-gnuradio" <discuss-gnuradio@gnu.org>
Sent: Wednesday, November 4, 2020 11:46:32 AM
Subject: Re: Issue in file sink block

Ok, thanks.

On Wed, Nov 4, 2020 at 11:28 AM Maitry Raval <maitry.raval@azistaaerospace.com> wrote:

Hello,

Please ignore the previous grc file. please find attached the correct grc file.

With Best Regards,
Maitry Raval,
R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com

From: "Maitry Raval" <maitry.raval@azistaaerospace.com>
To: "Aditya Arun Kumar" <adityaarunkumarphi@gmail.com>
Cc: "discuss-gnuradio" <discuss-gnuradio@gnu.org>
Sent: Wednesday, November 4, 2020 9:06:09 AM
Subject: Re: Issue in file sink block

Hello,

Please find attached grc file for reference. I have done trial and error by converting the output file into online ascii to binary converter, but it provides random output.

Please guide which binary viewer I need to use in check the data in 1 and 0 format(binary) ?

With Best Regards,
Maitry Raval,
R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com

From: "Aditya Arun Kumar" <adityaarunkumarphi@gmail.com>
To: "Derek Kozel" <derek@bitstovolts.com>
Cc: "Maitry Raval" <maitry.raval@azistaaerospace.com>, "Marcus Müller" <mmueller@gnuradio.org>, "discuss-gnuradio" <discuss-gnuradio@gnu.org>
Sent: Tuesday, November 3, 2020 5:49:05 PM
Subject: Re: Issue in file sink block

Or maybe use a gr-baz any sink to view bits?

On Tue, Nov 3, 2020 at 5:43 PM Derek Kozel <derek@bitstovolts.com> wrote:

Hello Maitry,

The File Sink is not producing a text file, it is the raw binary data.
You need to look at the contents of the file using a binary viewer.

Regards,
Derek

On 03/11/2020 11:12, Maitry Raval wrote:
> Hello sir,
>
> Please find attached screenshot for the grc file same as given in PSK guided tutorials. also, I have attached output txt file for your reference. still , did not receive binary data stored via file sink.
>
> Please guide, where am I doing wrong.
>
>
> With Best Regards,
> Maitry Raval,
> R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com
>
> ----- Original Message -----
> From: "Marcus Müller" <mmueller@gnuradio.org>
> To: "discuss-gnuradio" <discuss-gnuradio@gnu.org>
> Sent: Monday, November 2, 2020 8:47:28 PM
> Subject: Re: Issue in file sink block
>
> Again, the file sink is fine.
>
> On 02.11.20 04:39, Maitry Raval wrote:
>> Hello,
>>
>> I understand, I think, I need to use PSK demod using below link.
>> https://wiki.gnuradio.org/index.php/Guided_Tutorial_PSK_Demodulation
>>
>> But, as I have a requirement of storing the demod data in file , how is it possible using file sink or any other way, please guide.
>>
>> With Best Regards,
>> Maitry Raval,
>> R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com
>>
>> ----- Original Message -----
>> From: "Marcus Müller, CEL" <mueller@kit.edu>
>> To: "discuss-gnuradio" <discuss-gnuradio@gnu.org>
>> Sent: Saturday, October 31, 2020 9:06:22 PM
>> Subject: Re: Issue in file sink block
>>
>> Hi Maitry,
>>
>> I doubt it's the file sink. That tutorial used DPSK Mod, and that's
>> among the buggy packet_encoder tooling that we deprecated a long time
>> ago, and finally banished two-ish years ago. It just dropped data.
>>
>> See the more modern packet examples that come with your GNU Radio 3.8.
>>
>> Cheers,
>> Marcus
>>
>> On 31.10.20 09:34, Maitry Raval wrote:
>>> Hello ,
>>>
>>> I am using GNU radio along with ADRV9361-Z7035 Board for data reception
>>> and demodulation. I have faced an issue of using file sink block along
>>> with QPSK demod blocks. when I am attaching dpsk/PSK demod block with
>>> file sink, I have not received data in binary format. it gives some
>>> trunk values. when I am doing wrong, please guide us.
>>> I have taken a reference of below link.
>>> https://courses.washington.edu/ee420/projects/lab2_gnuradio.pdf
>>>
>>> The only difference is that I am using receiving section only. as I am
>>> transmitting from other source. so I have attached fmcommsource block
>>> with dpsk demod followed by file sink.
>>>
>>> Please guide
>>>
>>> With Best Regards,
>>> Maitry Raval,
>>> R& D engineer|Azista Industries Pvt Ltd|
>>> 079-40605800|www.azistaaerospace.com
> >

--

S. Aditya Arun Kumar
Security Researcher, Comms

+919123517465

--

S. Aditya Arun Kumar
Security Researcher, Comms

+919123517465