Re: [Discuss-gnuradio] SSH using gr-ieee 802.11 transceiver : (the youtube demo)

[Bastian Bloessl]

Hi,

On 07/12/2017 07:36 AM, sumit kumar wrote:

Hi,

Actually I am trying the same set-up :) However I face some issues. Such 
as , when I configure my TP Link dongle (ath9k) in ad-hoc mode, it 
switches to 802.11b, instead of 802.11g. Could you suggest any such 
dongle where I can force change the modulation method.


Try forcing the dongle to a specific rate after you switched it to ad 
hoc mode. If that doesn't work, I would use the 5GHz band (there it 
doesn't downgrade to 11b). Make sure to use a channel that doesn't 
require DFS.



Regarding, ARP entries, I had the idea (couldn't  go ahead becz dongle 
switch to 802.11b) : First establish adhoc connection between two 
dongles(so that ARP tables are updated). Then copy mac address of one 
dongle(say dongle A) to the transmitter of my openairinterface wifi 
transceiver, then power off the dongle A and turn on my own cloned 
transceive >
However I was trying to send ACK for the pings generated from dongle B 
(the other dongle) before the layer 2 trails are exhausted. I am trying 
all this inside a RF cage.


That's a question for the people from openairinterface.



How do you manage to work without sending ACK. Also I believe , you did 
that video demo over the air. How did you manage without CSMA :)


Sending ACKs is not the same as CSMA. The transceiver doesn't send ACKs, 
if some packet is lost, TCP resends the segment. (ARQ happens on 
transport layer not on link layer).


Best,
Bastian




Best,
Bastian



Regards

Sumit


* It reminds me of tunnel application which I ran on GNU Radio
long back (2012 I guess). There was an application tunnel.py


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



-- 
Dipl.-Inform. Bastian Bloessl

CONNECT Center
Trinity College Dublin

GitHub/Twitter: @bastibl
https://www.bastibl.net/




--
Sumit Kumar




--
Dipl.-Inform. Bastian Bloessl
CONNECT Center
Trinity College Dublin

GitHub/Twitter: @bastibl
https://www.bastibl.net/

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Daemonizing a flowgraph

[Marcus Müller]

If you can, update to the most current UHD – we've worked on the logging
infrastructure, and you can simply disable that.

This will probably require building both UHD, and as soon as you've done
that, GNU Radio from source.

Best regards,
Marcus

On 07/11/2017 10:39 PM, devin kelly wrote:
> Hello,
>
> I have a flowgraph that I made with  GRC and modified.  All I want to
> do with the flowgraph is make it run as a daemon.  I understand that
> if there are overflows or underflows I'll miss them, that's OK.
>
> I added some basic python code to daemonize my flowgraph:
>
>
> # Fork once
> try:
> pid = os.fork()
> except OSError:
> print 'error forking'
>
> if pid > 0:  # if parent, return
> return
>
> os.umask(0)
>
> # Reset the session ID
> try:
> os.setsid()
> except OSError:
> sys.exit(1)
>
> # Fork twice, giving up ownership of first parent's SID
> try:
> pid = os.fork()
> except OSError:
> print 'error forking'
>
> if pid != 0:  # if parent, return
> sys.exit(0)
>
> # Change PWD
> try:
> os.chdir('/')
> except OSError:
> return
>
> # Close open files
> sys.stdin.close()
> sys.stdout.close()
> sys.stderr.close()
>
> with open('/dev/null', 'r+') as devnull:
> sys.stdin = devnull
> sys.stdout = devnull
> sys.stderr = devnull
>
> tb = top_block_cls(options)
> tb.start()
> time.sleep(60.0)
> tb.stop()
> tb.wait()
>
> When I run this, it works at first (I get my prompt back, you can see
> me trying to open the file).  But then the UHD hijacks my
> stdout/stderr and resumes as if nothing happened.
>
> $ ./flowgraph.py -t
> 30
>  
>
> linux; GNU C++ version 4.8.4; Boost_105500; UHD_003.009.005-0-g32951af2
>
> $ vim flowgraph.py -- X300 initialization
> sequence...  
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Initialize Radio0 control...
> -- Performing register loopback test... pass
> -- Initialize Radio1 control...
> -- Performing register loopback test... pass
>
> How do I stop the UHD from doing this?
>
> Thanks for any help,
> Devin
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Daemonizing a flowgraph

[Marcus Müller]

Oh, by the way, maybe you, instead, simply would want to run your whole
flowgraph using `nohup`, or simply in a `screen` or `tmux` session :)


On 07/12/2017 09:22 AM, Marcus Müller wrote:
>
> If you can, update to the most current UHD – we've worked on the
> logging infrastructure, and you can simply disable that.
>
> This will probably require building both UHD, and as soon as you've
> done that, GNU Radio from source.
>
> Best regards,
> Marcus
>
> On 07/11/2017 10:39 PM, devin kelly wrote:
>> Hello,
>>
>> I have a flowgraph that I made with  GRC and modified.  All I want to
>> do with the flowgraph is make it run as a daemon.  I understand that
>> if there are overflows or underflows I'll miss them, that's OK.
>>
>> I added some basic python code to daemonize my flowgraph:
>>
>>
>> # Fork once
>> try:
>> pid = os.fork()
>> except OSError:
>> print 'error forking'
>>
>> if pid > 0:  # if parent, return
>> return
>>
>> os.umask(0)
>>
>> # Reset the session ID
>> try:
>> os.setsid()
>> except OSError:
>> sys.exit(1)
>>
>> # Fork twice, giving up ownership of first parent's SID
>> try:
>> pid = os.fork()
>> except OSError:
>> print 'error forking'
>>
>> if pid != 0:  # if parent, return
>> sys.exit(0)
>>
>> # Change PWD
>> try:
>> os.chdir('/')
>> except OSError:
>> return
>>
>> # Close open files
>> sys.stdin.close()
>> sys.stdout.close()
>> sys.stderr.close()
>>
>> with open('/dev/null', 'r+') as devnull:
>> sys.stdin = devnull
>> sys.stdout = devnull
>> sys.stderr = devnull
>>
>> tb = top_block_cls(options)
>> tb.start()
>> time.sleep(60.0)
>> tb.stop()
>> tb.wait()
>>
>> When I run this, it works at first (I get my prompt back, you can see
>> me trying to open the file).  But then the UHD hijacks my
>> stdout/stderr and resumes as if nothing happened.
>>
>> $ ./flowgraph.py -t
>> 30   
>>   
>>
>> linux; GNU C++ version 4.8.4; Boost_105500; UHD_003.009.005-0-g32951af2
>>
>> $ vim flowgraph.py -- X300 initialization
>> sequence...  
>>
>> -- Determining maximum frame size... 1472 bytes.
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- Initialize Radio0 control...
>> -- Performing register loopback test... pass
>> -- Initialize Radio1 control...
>> -- Performing register loopback test... pass
>>
>> How do I stop the UHD from doing this?
>>
>> Thanks for any help,
>> Devin
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cmake warning with -DENABLE_PERFORMANCE_COUNTERS-On (gr-ieee80211)

[Marcus Müller]

Hi Sumit,
> Then I manually set all of them to True, as I did last time, but no luck.
Again, what you did last time didn't make sense. See my previous answer
regarding the preferences check using gnuradio-config-info.

Best regards,
Marcus

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to process file sink from UHD Source USRP

[Sinta Novtafiani]

So, how can i get the information of frequency, power, time that usrp
received? Is there any tools in gnuradio companion which can get those
data? If you have any reference it may be helpfull for me. Thankyou.

Besr Regard,
Sinta.

On Jul 11, 2017 4:24 PM, "Marcus Müller"  wrote:

> You're just saving samples from the USRP – there's no info like
> "frequency" or "time" attached to those. It's just a very long row of
> complex numbers.
>
> Best regards,
>
> Marcus
>
> On 07/11/2017 01:23 AM, Sinta Novtafiani wrote:
>
> Hello Marcus,
>
> Thankyou for your advice. I just want to know data actual of my program
> like frequency, time and power then save as file txt so i can read the data
> anytime. But i have problem, when i read the raw binary file use those
> source code above, its appears float data in one coloumn and i don't know
> which one frequency, time, or power because i didn't got header of the
> data. I have to convert .dat file into format that can read anywhere or
> convert to numerical data in matrix because the data will process
> furthermore
>
> On Jul 10, 2017 2:09 PM, "Marcus Müller"  wrote:
>
>> Dear Sinta,
>>
>> I've had this discussion several times before, so let me please shortly
>> mention that you've signed up to the mailing list via Nabble, which is a
>> very suboptimal thing for you (you might miss answers posted by us). Please
>> sign out of nabble, and sign up directly to
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio; enough of that
>> :)
>>
>> This is more of a collection of thoughts for future readers than direct
>> criticism on your approach:
>>
>> Well, I really don't know why you would want a text file containing float
>> samples. It doesn't make sense from a precision point of view, it doesn't
>> make sense from a storage size point of view, and it doesn't even make
>> sense from a usability point of view – I don't really believe you'll get a
>> "feeling" for data if you scroll around in a 1mio lines text file :)
>>
>> That being said, there's probably very legitimate reason you'd want a CSV
>> file (for example, get a couple data points only to import them into a
>> spreadsheet software). You probably want to look into the "Head" block that
>> limits the number of items going through.
>>
>> Also, you could just as well in your Python code not save all of `data`,
>> but only let's say `data[:100]`.
>>
>> Best regards,
>>
>> Marcus
>> On 07/10/2017 08:54 AM, Sinta Novtafiani wrote:
>>
>> Hello Nicholas,
>>
>> Thankyou for your reply. I've try that way and its work. I have a
>> problem, my file that generate from file sink is big. And it cause text
>> edtior become not reponding when i open file that have converted to txt.
>> Did you know how to control file size from file sink?
>>
>> I use this code below to convert binary file into txt
>>
>> data=scipy.fromfile(open('filename'), dtype=scipy.float32)
>> scipy.savetxt('filename.txt', data)
>>
>> On Mon, Jul 10, 2017 at 1:52 AM, Nicolas Cuervo > > wrote:
>>
>>> Hello Sinta,
>>>
>>> This specific question is handled in the GNURadio FAQ [1]. Please try to
>>> use the scipy.fromfile() method and check if the output agrees with your
>>> expectations.
>>>
>>> Regards,
>>> - Nicolas
>>>
>>> [1] https://wiki.gnuradio.org/index.php/FAQ#What_is_the_file
>>> _format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a
>>> _file_sink.3F
>>>
>>> On Mon, Jul 10, 2017 at 5:25 AM, Sinta Novtafiani 
>>> wrote:
>>>
 I got UHD Source receiver with frequency sweeper, its working fine but
 i need
 to read and actually process the data to make graph out of it without
 using
 QT GUI, i try to open with hex editor but dont seem to understand the
 pattern of the file that i need to process, im making python program to
 convert it to numbers but the number that comes up doesnt seem relevant
 with
 the one i see at QT GUI.
 
 



 --
 View this message in context: http://gnuradio.4.n7.nabble.co
 m/How-to-process-file-sink-from-UHD-Source-USRP-tp64518.html
 Sent from the GnuRadio mailing list archive at Nabble.com.

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

>>>
>>>
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> ___ Discuss-gnuradio mailing
>> list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/
>> listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to process file sink from UHD Source USRP

[Marcus Müller]

So, this is a bit of a bigger question. The center frequency is
something that *you* configure, so errr... you might just as well save
it as part of the file name, or so.

A precise reception time requires setting the precise time in the USRP.
But, as soon as you've done that, you can use the time tags that the
USRP source emits, e.g. to save the tags as metadata along with the
samples (or separately). "Power" is not anything the USRP measures. You
need to estimate that from the samples, so you seem to be asking the
wrong questions.

Maybe you'd want to make sure that you both understand what you're
trying to build, and how you can even get the data you want at all,
before considering how to safe it. I'd encourage you to both discuss
that with your peers and supervisors, as well as with the mailing list –
but the latter really requires that you write down a concise, clear,
unambigous, as-mathematically-precise-as-possible system purpose.

Best regards,

Marcus


On 07/12/2017 11:52 AM, Sinta Novtafiani wrote:
> So, how can i get the information of frequency, power, time that usrp
> received? Is there any tools in gnuradio companion which can get those
> data? If you have any reference it may be helpfull for me. Thankyou.
>
> Besr Regard,
> Sinta.
>
> On Jul 11, 2017 4:24 PM, "Marcus Müller"  > wrote:
>
> You're just saving samples from the USRP – there's no info like
> "frequency" or "time" attached to those. It's just a very long row
> of complex numbers.
>
> Best regards,
>
> Marcus
>
>
> On 07/11/2017 01:23 AM, Sinta Novtafiani wrote:
>> Hello Marcus,
>>
>> Thankyou for your advice. I just want to know data actual of my
>> program like frequency, time and power then save as file txt so i
>> can read the data anytime. But i have problem, when i read the
>> raw binary file use those source code above, its appears float
>> data in one coloumn and i don't know which one frequency, time,
>> or power because i didn't got header of the data. I have to
>> convert .dat file into format that can read anywhere or convert
>> to numerical data in matrix because the data will process
>> furthermore 
>>
>> On Jul 10, 2017 2:09 PM, "Marcus Müller"
>> mailto:marcus.muel...@ettus.com>> wrote:
>>
>> Dear Sinta,
>>
>> I've had this discussion several times before, so let me
>> please shortly mention that you've signed up to the mailing
>> list via Nabble, which is a very suboptimal thing for you
>> (you might miss answers posted by us). Please sign out of
>> nabble, and sign up directly to
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> ;
>> enough of that :)
>>
>> This is more of a collection of thoughts for future readers
>> than direct criticism on your approach:
>>
>> Well, I really don't know why you would want a text file
>> containing float samples. It doesn't make sense from a
>> precision point of view, it doesn't make sense from a storage
>> size point of view, and it doesn't even make sense from a
>> usability point of view – I don't really believe you'll get a
>> "feeling" for data if you scroll around in a 1mio lines text
>> file :)
>>
>> That being said, there's probably very legitimate reason
>> you'd want a CSV file (for example, get a couple data points
>> only to import them into a spreadsheet software). You
>> probably want to look into the "Head" block that limits the
>> number of items going through.
>>
>> Also, you could just as well in your Python code not save all
>> of `data`, but only let's say `data[:100]`.
>>
>> Best regards,
>>
>> Marcus
>>
>> On 07/10/2017 08:54 AM, Sinta Novtafiani wrote:
>>> Hello Nicholas,
>>>
>>> Thankyou for your reply. I've try that way and its work. I
>>> have a problem, my file that generate from file sink is big.
>>> And it cause text edtior become not reponding when i open
>>> file that have converted to txt. Did you know how to control
>>> file size from file sink?
>>>
>>> I use this code below to convert binary file into txt
>>>
>>> data=scipy.fromfile(open('filename'), dtype=scipy.float32)
>>> scipy.savetxt('filename.txt', data)
>>>
>>> On Mon, Jul 10, 2017 at 1:52 AM, Nicolas Cuervo
>>> mailto:nicolas.cue...@ettus.com>>
>>> wrote:
>>>
>>> Hello Sinta,
>>>
>>> This specific question is handled in the GNURadio FAQ
>>> [1]. Please try to use the scipy.fromfile() method and
>>> check if the output agrees with your expectations.
>>>
>>> Regards,
>>> - Nicolas
>>>
>>> [1] 
>>> https://wiki.gnuradio.o

Re: [Discuss-gnuradio] How to process file sink from UHD Source USRP

[Derek Kozel]

Hello Sinta,

To add to Marcus' answer here is the documentation of the metadata files
that GNU Radio's file sink can create. You should experiment with this and
the tag debug tool to see what tags are in your data stream.
https://gnuradio.org/doc/doxygen/page_metadata.html
https://gnuradio.org/doc/doxygen/page_stream_tags.html

Regards,
Derek

On Wed, Jul 12, 2017 at 10:58 AM, Marcus Müller 
wrote:

> So, this is a bit of a bigger question. The center frequency is something
> that *you* configure, so errr... you might just as well save it as part of
> the file name, or so.
>
> A precise reception time requires setting the precise time in the USRP.
> But, as soon as you've done that, you can use the time tags that the USRP
> source emits, e.g. to save the tags as metadata along with the samples (or
> separately). "Power" is not anything the USRP measures. You need to
> estimate that from the samples, so you seem to be asking the wrong
> questions.
>
> Maybe you'd want to make sure that you both understand what you're trying
> to build, and how you can even get the data you want at all, before
> considering how to safe it. I'd encourage you to both discuss that with
> your peers and supervisors, as well as with the mailing list – but the
> latter really requires that you write down a concise, clear, unambigous,
> as-mathematically-precise-as-possible system purpose.
>
> Best regards,
>
> Marcus
>
> On 07/12/2017 11:52 AM, Sinta Novtafiani wrote:
>
> So, how can i get the information of frequency, power, time that usrp
> received? Is there any tools in gnuradio companion which can get those
> data? If you have any reference it may be helpfull for me. Thankyou.
>
> Besr Regard,
> Sinta.
>
> On Jul 11, 2017 4:24 PM, "Marcus Müller"  wrote:
>
>> You're just saving samples from the USRP – there's no info like
>> "frequency" or "time" attached to those. It's just a very long row of
>> complex numbers.
>>
>> Best regards,
>>
>> Marcus
>>
>> On 07/11/2017 01:23 AM, Sinta Novtafiani wrote:
>>
>> Hello Marcus,
>>
>> Thankyou for your advice. I just want to know data actual of my program
>> like frequency, time and power then save as file txt so i can read the data
>> anytime. But i have problem, when i read the raw binary file use those
>> source code above, its appears float data in one coloumn and i don't know
>> which one frequency, time, or power because i didn't got header of the
>> data. I have to convert .dat file into format that can read anywhere or
>> convert to numerical data in matrix because the data will process
>> furthermore
>>
>> On Jul 10, 2017 2:09 PM, "Marcus Müller" 
>> wrote:
>>
>>> Dear Sinta,
>>>
>>> I've had this discussion several times before, so let me please shortly
>>> mention that you've signed up to the mailing list via Nabble, which is a
>>> very suboptimal thing for you (you might miss answers posted by us). Please
>>> sign out of nabble, and sign up directly to
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio; enough of that
>>> :)
>>>
>>> This is more of a collection of thoughts for future readers than direct
>>> criticism on your approach:
>>>
>>> Well, I really don't know why you would want a text file containing
>>> float samples. It doesn't make sense from a precision point of view, it
>>> doesn't make sense from a storage size point of view, and it doesn't even
>>> make sense from a usability point of view – I don't really believe you'll
>>> get a "feeling" for data if you scroll around in a 1mio lines text file :)
>>>
>>> That being said, there's probably very legitimate reason you'd want a
>>> CSV file (for example, get a couple data points only to import them into a
>>> spreadsheet software). You probably want to look into the "Head" block that
>>> limits the number of items going through.
>>>
>>> Also, you could just as well in your Python code not save all of `data`,
>>> but only let's say `data[:100]`.
>>>
>>> Best regards,
>>>
>>> Marcus
>>> On 07/10/2017 08:54 AM, Sinta Novtafiani wrote:
>>>
>>> Hello Nicholas,
>>>
>>> Thankyou for your reply. I've try that way and its work. I have a
>>> problem, my file that generate from file sink is big. And it cause text
>>> edtior become not reponding when i open file that have converted to txt.
>>> Did you know how to control file size from file sink?
>>>
>>> I use this code below to convert binary file into txt
>>>
>>> data=scipy.fromfile(open('filename'), dtype=scipy.float32)
>>> scipy.savetxt('filename.txt', data)
>>>
>>> On Mon, Jul 10, 2017 at 1:52 AM, Nicolas Cuervo <
>>> nicolas.cue...@ettus.com> wrote:
>>>
 Hello Sinta,

 This specific question is handled in the GNURadio FAQ [1]. Please try
 to use the scipy.fromfile() method and check if the output agrees with your
 expectations.

 Regards,
 - Nicolas

 [1] https://wiki.gnuradio.org/index.php/FAQ#What_is_the_file
 _format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a
 _file_sink.3F

 On Mon, Jul 10

Re: [Discuss-gnuradio] Decoding 2FSK Compensating for carrier jitter/skewing (CFO)

[HLL]

On Wed, Jul 12, 2017 at 1:56 AM, Cinaed Simson 
wrote:
>
> It seems odd that a device with a maximum power 116 dBm would have such
> a weak signal.
>
As I mentioned earlier, I'm not really sure what is the frequency of the
device is, I just scanned the 300 + area and I found a few that correlate
with the device transmission
This one was taken on 440.15M; I Also have another similar capture,
captured at 419.562M

>
> Maybe the antenna was to close? The distance of the receiving antenna
> was roughly 0.1 of the carrier wavelength from transmitting antenna.
>
I guess it was, distance was around 8-15 cm or so, as the wavelength is
68.15cm, When capturing I didn't considered it (or even known it is a
factor)
The antenna used is the stock RTL SDR one.

If you can recommend some hackish (DIY or even retail) antenna to better
receive that signal that would be grate.

>
> Also, the documents indicate the channel width is from 7 kHz to 16 kHz -
> the sampling rate of 8 kHz may have been to small.
>
Well, As  Andy mentioned, it's not FSK, so the documentation may be talking
about other version of the device.
I Downsampled the capture to 8khz after centering because that was much
more then 2 times of bandwidth I've seen on the FFT on active burst


> But in any case, there's a lot of good information in this thread and
> it's going to take me a while to digest all of it.
>
If that helps, I kindda made a quick graph that does similar thing to
Andy's graph, and I got similar results:

[image: Inline image 1]

now it seems that a large CFO glitch translates to short glitchs in the
digital signal

Graph:
[image: Inline image 2]


>
>
>
> On 07/10/2017 05:55 PM, Andy Walls wrote:
> > From: HLL
> > Date: Mon, 10 Jul 2017 20:44:01 +0300
> >> Hi,
> >> Thank you very much!!
> >> I Need to thoroughly go over your response and understand it all, but
> >> thanks :)
> >>
> >> I also noticed the 2 different in bit timings, I thought it's
> >> something electrically, since I noticed the "long" lows and highs are
> >> on some specific timings and the shorts have another timing.
> >>
> >> Before experimenting with the graph (and the said OOT modules). I'm
> >> going over it and trying to understand it,
> >> what the rotator does, and what it it's role?
> >
> > It performs a (cyclic) frequency shift of the signal spectrum.  It is
> > called a rotator because the DFT of a sampled signal "lives" on the
> > unit circle of the z-plane.  The rotator block rotates the entire z-
> > plane about its origin by a certain number of radians, thus effectively
> >  shifting the spectrum of the signal.
> >
> > I use the rotator block to shift the audio frequency bins of +350 Hz
> > and +940 Hz down to -295 Hz and +295 Hz respectively.  Then I filter
> > off what were the negative audio frequency bins, the DC spike from the
> > FM CFO, and a lot of the spectrum which is just noise.
> >
> >> The part with 2 pll carrier tracking is used for locking the carrier
> >> of the low and high freq as I understand (I.E. The cheap digital PWM
> >> or clock devider)
> >
> > Yes, but they both track *and* downconvert the tracked tone to DC.
> >
> > This is a coherent FSK receiver design, which is probably overkill for
> > this application, but I used it to handle uncertainty in the actual
> > audio tone bins used for the mark and space frequencies.
> >
> >> what is the role of the complex conjugates (mirror over the real
> >> axis?),
> >
> > The complex conjugate is to handle a quirk of the GNURadio PLL block
> > before the subtraction.  When the PLL carrier tracking block does it's
> > downconversion of the tracked tone to DC, it doesn't have a phase angle
> > of 0 degrees (a purely real number), instead it has a phase angle of
> > something a bit less than pi/4 radians.
> >
> > The complex conjugate is so when I do the following subtract, I will
> > get constellation points on opposite sides of the circle in the I-Q
> > plane.
> >
> >
> >>  subtract,
> >
> > This is standard for a coherent FSK demodulator and for certain non-
> > coherent FSK demodulators.  Google images should show a number of block
> > diagrams doing this.
> >
> >
> >>  c-to-f and add part?
> >
> > Well, after the subtraction you have I-Q plane constellation points of
> > about A*exp(j*pi/4) and A*exp(j*5*pi/4), and a fuzzy trajectory line
> > going approximately straight between those points.  I needed to convert
> > those to real values.
> >
> > I could have taken the complex magnitude and the complex argument and
> > somehow tried to assign the proper sign to the complex magnitude, but
> > that was work. :)  Since the two constellation points and the
> > trajectory is restricted to quadrants I and III of the I-Q plane, it
> > was easier to just add combine the real and imaginary parts to get a
> > real number.
> >
> >
> >>   Are you "subtracting" the (locked) `0` square wave from the `1`
> >> square wave, why?
> >
> > No.
> >
> > Let's pretend GNURadio's quirky almost pi/4 an

Re: [Discuss-gnuradio] Daemonizing a flowgraph

[Dan CaJacob]

Marcus' suggestions are great. In the past, I have also used supervisord to
"daemonize" a flowgraph. If it ever dies, supervisord brings it right back
if that's what you want. It's like systemd for python, kinda.

On Wed, Jul 12, 2017 at 3:30 AM Marcus Müller 
wrote:

> Oh, by the way, maybe you, instead, simply would want to run your whole
> flowgraph using `nohup`, or simply in a `screen` or `tmux` session :)
>
> On 07/12/2017 09:22 AM, Marcus Müller wrote:
>
> If you can, update to the most current UHD – we've worked on the logging
> infrastructure, and you can simply disable that.
> This will probably require building both UHD, and as soon as you've done
> that, GNU Radio from source.
>
> Best regards,
> Marcus
>
> On 07/11/2017 10:39 PM, devin kelly wrote:
>
> Hello,
>
> I have a flowgraph that I made with  GRC and modified.  All I want to do
> with the flowgraph is make it run as a daemon.  I understand that if there
> are overflows or underflows I'll miss them, that's OK.
>
> I added some basic python code to daemonize my flowgraph:
>
>
> # Fork once
> try:
> pid = os.fork()
> except OSError:
> print 'error forking'
>
> if pid > 0:  # if parent, return
> return
>
> os.umask(0)
>
> # Reset the session ID
> try:
> os.setsid()
> except OSError:
> sys.exit(1)
>
> # Fork twice, giving up ownership of first parent's SID
> try:
> pid = os.fork()
> except OSError:
> print 'error forking'
>
> if pid != 0:  # if parent, return
> sys.exit(0)
>
> # Change PWD
> try:
> os.chdir('/')
> except OSError:
> return
>
> # Close open files
> sys.stdin.close()
> sys.stdout.close()
> sys.stderr.close()
>
> with open('/dev/null', 'r+') as devnull:
> sys.stdin = devnull
> sys.stdout = devnull
> sys.stderr = devnull
>
> tb = top_block_cls(options)
> tb.start()
> time.sleep(60.0)
> tb.stop()
> tb.wait()
>
> When I run this, it works at first (I get my prompt back, you can see me
> trying to open the file).  But then the UHD hijacks my stdout/stderr and
> resumes as if nothing happened.
>
> $ ./flowgraph.py -t
> 30
>
> linux; GNU C++ version 4.8.4; Boost_105500; UHD_003.009.005-0-g32951af2
>
> $ vim flowgraph.py -- X300 initialization
> sequence...
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Initialize Radio0 control...
> -- Performing register loopback test... pass
> -- Initialize Radio1 control...
> -- Performing register loopback test... pass
>
> How do I stop the UHD from doing this?
>
> Thanks for any help,
> Devin
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

Dan CaJacob
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] polar code example

[Alex Rivadeneira]

Dear Jose 

Can you tell me if you solved the problem with the POLAR code configurator
block? because I have the same problem in the gnuradio installed with
pybombs.

Thanks 

Alex 



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/polar-code-example-tp58407p64520.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] polar code example

[Marcus Müller]

Hi Alex,

I hope you do get an answer, but that mail from Jose is from the
beginning of 2016 – not extremely likely.

Anyway, have you seen the other answers that Jose got?
If not: That's Nabble's fault. I never tire to repeat:
Nabble is just a terrible, terrible web frontend to use the official GNU
Radio Mailing list.

It's not the official mailing list archive. It never was, and it never
will be. The official way to sign up for the mailing list is

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

and there's a link to the official mailing list archive, too.

I'd recommend deleting your Nabble account, and directly signing up
under the above address with your email account. It's really easier to
use a proper email client (eg. GMail's web frontend) and simply the
mails than Nabble. Nabble breaks discussion threads, it makes answers
invisible, and it has cost us hours and hours of unnecessary work so
far. PLEASE, don't use Nabble.

Best regards,

Marcus


On 07/12/2017 01:52 PM, Alex Rivadeneira wrote:
> Dear Jose 
>
> Can you tell me if you solved the problem with the POLAR code configurator
> block? because I have the same problem in the gnuradio installed with
> pybombs.
>
> Thanks 
>
> Alex 
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/polar-code-example-tp58407p64520.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-scan giving false alarms

[Marcus Müller]

Dear GNU Beginner,

we've started to actively get rid of Nabble:

http://support.nabble.com/How-to-get-Mailing-List-OUT-of-Nabble-td7598247.html

I'm very sorry there's problems with you signing up to the mailing list
directly with your email address, but I'm positive we can sort them out.
In the meantime, please be warned that I'm optimistic Nabble will stop
working as frontend to the mailing list relatively soon.

Best regards,
Marcus

On 07/11/2017 08:15 PM, GNUBeginner wrote:
> Hello Everyone,
>
> Could anyone please tell me why gr-scan gives three different frequency
> finding results (2410 MHz, 2412 MHz, 2414 MHz) when I inject only 2412 MHz
> signal with -30 dBm power level?
>
> Thanks
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/gr-scan-giving-false-alarms-tp64519.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] polar code example

[Alex Homero Rivadeneira Erazo]

Hi Marcus

Based on your suggestion I have deleted my Nabbles account.

Respect to my problem with the POLAR code configurator block, I checked the
discussion threads, but anyone gave a solution.

Note that this problem does not happen with a gnuradio installed with the
distribution's package manager (standard installation). However, the
problem with this installation method is that gnuradio is not up to date
and it does not have all the blocks that I need in my work. That is why I
used pybombs to install gnuradio which has the blocks that I need. Now the
problem is that gnuradio with pybombs does work with the POLAR code
configurator block. When I drop the POLAR code configurator block on the
canvas, the gnuradio program turns down.

At this moment, I am installing gnuradio from source. If you have other
ideas please tell me.

Thanks

Best regards,

Alex



On Wed, Jul 12, 2017 at 9:43 AM, Marcus Müller 
wrote:

> Hi Alex,
>
> I hope you do get an answer, but that mail from Jose is from the
> beginning of 2016 – not extremely likely.
>
> Anyway, have you seen the other answers that Jose got?
> If not: That's Nabble's fault. I never tire to repeat:
> Nabble is just a terrible, terrible web frontend to use the official GNU
> Radio Mailing list.
>
> It's not the official mailing list archive. It never was, and it never
> will be. The official way to sign up for the mailing list is
>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> and there's a link to the official mailing list archive, too.
>
> I'd recommend deleting your Nabble account, and directly signing up
> under the above address with your email account. It's really easier to
> use a proper email client (eg. GMail's web frontend) and simply the
> mails than Nabble. Nabble breaks discussion threads, it makes answers
> invisible, and it has cost us hours and hours of unnecessary work so
> far. PLEASE, don't use Nabble.
>
> Best regards,
>
> Marcus
>
>
> On 07/12/2017 01:52 PM, Alex Rivadeneira wrote:
> > Dear Jose
> >
> > Can you tell me if you solved the problem with the POLAR code
> configurator
> > block? because I have the same problem in the gnuradio installed with
> > pybombs.
> >
> > Thanks
> >
> > Alex
> >
> >
> >
> > --
> > View this message in context: http://gnuradio.4.n7.nabble.
> com/polar-code-example-tp58407p64520.html
> > Sent from the GnuRadio mailing list archive at Nabble.com.
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Regards,

Alex Homero Rivadeneira E.
Cell: 438 397-8330
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] polar code example

[Marcus Müller]

Hi Alex,

that does indeed sound like a bug. Things shouldn't be crashing!

So, what's the distribution you're working with? Maybe I can help you a
bit with the debugging. If you're, at the moment, building GNU Radio,
make sure that the CMake parameters contain
-DCMAKE_BUILD_TYPE=RelWithDebInfo , so that we get debugging symbols :)

Best regards,

Marcus


On 07/12/2017 05:11 PM, Alex Homero Rivadeneira Erazo wrote:
> Hi Marcus 
>
> Based on your suggestion I have deleted my Nabbles account.
>
> Respect to my problem with the POLAR code configurator block, I
> checked the discussion threads, but anyone gave a solution.
>
> Note that this problem does not happen with a gnuradio installed with
> the distribution's package manager (standard installation). However,
> the problem with this installation method is that gnuradio is not up
> to date and it does not have all the blocks that I need in my work.
> That is why I used pybombs to install gnuradio which has the blocks
> that I need. Now the problem is that gnuradio with pybombs does work
> with the POLAR code configurator block. When I drop the POLAR code
> configurator block on the canvas, the gnuradio program turns down.
>
> At this moment, I am installing gnuradio from source. If you have
> other ideas please tell me. 
>
> Thanks
>
> Best regards,
>
> Alex 
>
>
>
> On Wed, Jul 12, 2017 at 9:43 AM, Marcus Müller
> mailto:marcus.muel...@ettus.com>> wrote:
>
> Hi Alex,
>
> I hope you do get an answer, but that mail from Jose is from the
> beginning of 2016 – not extremely likely.
>
> Anyway, have you seen the other answers that Jose got?
> If not: That's Nabble's fault. I never tire to repeat:
> Nabble is just a terrible, terrible web frontend to use the
> official GNU
> Radio Mailing list.
>
> It's not the official mailing list archive. It never was, and it never
> will be. The official way to sign up for the mailing list is
>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
>
> and there's a link to the official mailing list archive, too.
>
> I'd recommend deleting your Nabble account, and directly signing up
> under the above address with your email account. It's really easier to
> use a proper email client (eg. GMail's web frontend) and simply the
> mails than Nabble. Nabble breaks discussion threads, it makes answers
> invisible, and it has cost us hours and hours of unnecessary work so
> far. PLEASE, don't use Nabble.
>
> Best regards,
>
> Marcus
>
>
> On 07/12/2017 01:52 PM, Alex Rivadeneira wrote:
> > Dear Jose
> >
> > Can you tell me if you solved the problem with the POLAR code
> configurator
> > block? because I have the same problem in the gnuradio installed
> with
> > pybombs.
> >
> > Thanks
> >
> > Alex
> >
> >
> >
> > --
> > View this message in context:
> http://gnuradio.4.n7.nabble.com/polar-code-example-tp58407p64520.html
> 
> > Sent from the GnuRadio mailing list archive at Nabble.com.
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
>
>
>
>
> -- 
> Regards, 
>
> Alex Homero Rivadeneira E.
> Cell: 438 397-8330

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] polar code example

[Alex Homero Rivadeneira Erazo]

Hi Marcus

At this moment, I am installing the gnuradio 3.7.12git-171-get72c77bc from
source, which is the same that I installed with pybombs . Unfortunately, I
just already built the gnuradio with "make && make test". The gnuradio that
I had with the standard installation was gnuradio 3.7.9

Thanks

Best regards,

Alex




On Wed, Jul 12, 2017 at 11:13 AM, Marcus Müller 
wrote:

> Hi Alex,
>
> that does indeed sound like a bug. Things shouldn't be crashing!
>
> So, what's the distribution you're working with? Maybe I can help you a
> bit with the debugging. If you're, at the moment, building GNU Radio, make
> sure that the CMake parameters contain -DCMAKE_BUILD_TYPE=RelWithDebInfo
> , so that we get debugging symbols :)
>
> Best regards,
>
> Marcus
>
> On 07/12/2017 05:11 PM, Alex Homero Rivadeneira Erazo wrote:
>
> Hi Marcus
>
> Based on your suggestion I have deleted my Nabbles account.
>
> Respect to my problem with the POLAR code configurator block, I checked
> the discussion threads, but anyone gave a solution.
>
> Note that this problem does not happen with a gnuradio installed with the
> distribution's package manager (standard installation). However, the
> problem with this installation method is that gnuradio is not up to date
> and it does not have all the blocks that I need in my work. That is why I
> used pybombs to install gnuradio which has the blocks that I need. Now the
> problem is that gnuradio with pybombs does work with the POLAR code
> configurator block. When I drop the POLAR code configurator block on the
> canvas, the gnuradio program turns down.
>
> At this moment, I am installing gnuradio from source. If you have other
> ideas please tell me.
>
> Thanks
>
> Best regards,
>
> Alex
>
>
>
> On Wed, Jul 12, 2017 at 9:43 AM, Marcus Müller 
> wrote:
>
>> Hi Alex,
>>
>> I hope you do get an answer, but that mail from Jose is from the
>> beginning of 2016 – not extremely likely.
>>
>> Anyway, have you seen the other answers that Jose got?
>> If not: That's Nabble's fault. I never tire to repeat:
>> Nabble is just a terrible, terrible web frontend to use the official GNU
>> Radio Mailing list.
>>
>> It's not the official mailing list archive. It never was, and it never
>> will be. The official way to sign up for the mailing list is
>>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> and there's a link to the official mailing list archive, too.
>>
>> I'd recommend deleting your Nabble account, and directly signing up
>> under the above address with your email account. It's really easier to
>> use a proper email client (eg. GMail's web frontend) and simply the
>> mails than Nabble. Nabble breaks discussion threads, it makes answers
>> invisible, and it has cost us hours and hours of unnecessary work so
>> far. PLEASE, don't use Nabble.
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 07/12/2017 01:52 PM, Alex Rivadeneira wrote:
>> > Dear Jose
>> >
>> > Can you tell me if you solved the problem with the POLAR code
>> configurator
>> > block? because I have the same problem in the gnuradio installed with
>> > pybombs.
>> >
>> > Thanks
>> >
>> > Alex
>> >
>> >
>> >
>> > --
>> > View this message in context: http://gnuradio.4.n7.nabble.co
>> m/polar-code-example-tp58407p64520.html
>> > Sent from the GnuRadio mailing list archive at Nabble.com.
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> --
> Regards,
>
> Alex Homero Rivadeneira E.
> Cell: 438 397-8330 <(438)%20397-8330>
>
>
>


-- 
Regards,

Alex Homero Rivadeneira E.
Cell: 438 397-8330
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] polar code example

[Marcus Müller]

That might still give us enough debug info. Which Linux distro are we
talking about (or, is it Linux at all?)

Best regards,

Marcus


On 07/12/2017 05:30 PM, Alex Homero Rivadeneira Erazo wrote:
> Hi Marcus
>
> At this moment, I am installing the gnuradio 3.7.12git-171-get72c77bc
> from source, which is the same that I installed with pybombs .
> Unfortunately, I just already built the gnuradio with "make && make
> test". The gnuradio that I had with the standard installation was
> gnuradio 3.7.9
>
> Thanks 
>
> Best regards,
>
> Alex
>
>
>
>
> On Wed, Jul 12, 2017 at 11:13 AM, Marcus Müller
> mailto:marcus.muel...@ettus.com>> wrote:
>
> Hi Alex,
>
> that does indeed sound like a bug. Things shouldn't be crashing!
>
> So, what's the distribution you're working with? Maybe I can help
> you a bit with the debugging. If you're, at the moment, building
> GNU Radio, make sure that the CMake parameters contain
> -DCMAKE_BUILD_TYPE=RelWithDebInfo , so that we get debugging
> symbols :)
>
> Best regards,
>
> Marcus
>
>
> On 07/12/2017 05:11 PM, Alex Homero Rivadeneira Erazo wrote:
>> Hi Marcus 
>>
>> Based on your suggestion I have deleted my Nabbles account.
>>
>> Respect to my problem with the POLAR code configurator block, I
>> checked the discussion threads, but anyone gave a solution.
>>
>> Note that this problem does not happen with a gnuradio installed
>> with the distribution's package manager (standard installation).
>> However, the problem with this installation method is that
>> gnuradio is not up to date and it does not have all the blocks
>> that I need in my work. That is why I used pybombs to install
>> gnuradio which has the blocks that I need. Now the problem is
>> that gnuradio with pybombs does work with the POLAR code
>> configurator block. When I drop the POLAR code configurator block
>> on the canvas, the gnuradio program turns down.
>>
>> At this moment, I am installing gnuradio from source. If you have
>> other ideas please tell me. 
>>
>> Thanks
>>
>> Best regards,
>>
>> Alex 
>>
>>
>>
>> On Wed, Jul 12, 2017 at 9:43 AM, Marcus Müller
>> mailto:marcus.muel...@ettus.com>> wrote:
>>
>> Hi Alex,
>>
>> I hope you do get an answer, but that mail from Jose is from the
>> beginning of 2016 – not extremely likely.
>>
>> Anyway, have you seen the other answers that Jose got?
>> If not: That's Nabble's fault. I never tire to repeat:
>> Nabble is just a terrible, terrible web frontend to use the
>> official GNU
>> Radio Mailing list.
>>
>> It's not the official mailing list archive. It never was, and
>> it never
>> will be. The official way to sign up for the mailing list is
>>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>>
>> and there's a link to the official mailing list archive, too.
>>
>> I'd recommend deleting your Nabble account, and directly
>> signing up
>> under the above address with your email account. It's really
>> easier to
>> use a proper email client (eg. GMail's web frontend) and
>> simply the
>> mails than Nabble. Nabble breaks discussion threads, it makes
>> answers
>> invisible, and it has cost us hours and hours of unnecessary
>> work so
>> far. PLEASE, don't use Nabble.
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 07/12/2017 01:52 PM, Alex Rivadeneira wrote:
>> > Dear Jose
>> >
>> > Can you tell me if you solved the problem with the POLAR
>> code configurator
>> > block? because I have the same problem in the gnuradio
>> installed with
>> > pybombs.
>> >
>> > Thanks
>> >
>> > Alex
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> http://gnuradio.4.n7.nabble.com/polar-code-example-tp58407p64520.html
>> 
>> 
>> > Sent from the GnuRadio mailing list archive at Nabble.com.
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org 
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>>
>>
>>
>>
>> -- 
>> Regards, 
>

Re: [Discuss-gnuradio] polar code example

[Alex Homero Rivadeneira Erazo]

I am using ubuntu 16.04 LTS.

At the end of the make test, I have obtained some failures:

97% tests passed, 6 tests failed out of 218

Total Test time (real) = 142.49 sec

The following tests FAILED:
 48 - qa_ctrlport_probes (Failed)
 59 - qa_cpp_py_binding (Failed)
 76 - qa_cpp_py_binding_set (Failed)
124 - qa_filterbank (Failed)
154 - qa_ofdm_txrx (Failed)
197 - qa_fading_model (Failed)
Errors while running CTest
Makefile:61: recipe for target 'test' failed
make: *** [test] Error 8

Best regards,

Alex

On Wed, Jul 12, 2017 at 11:46 AM, Marcus Müller 
wrote:

> That might still give us enough debug info. Which Linux distro are we
> talking about (or, is it Linux at all?)
>
> Best regards,
>
> Marcus
>
> On 07/12/2017 05:30 PM, Alex Homero Rivadeneira Erazo wrote:
>
> Hi Marcus
>
> At this moment, I am installing the gnuradio 3.7.12git-171-get72c77bc
> from source, which is the same that I installed with pybombs .
> Unfortunately, I just already built the gnuradio with "make && make test".
> The gnuradio that I had with the standard installation was gnuradio 3.7.9
>
> Thanks
>
> Best regards,
>
> Alex
>
>
>
>
> On Wed, Jul 12, 2017 at 11:13 AM, Marcus Müller 
> wrote:
>
>> Hi Alex,
>>
>> that does indeed sound like a bug. Things shouldn't be crashing!
>>
>> So, what's the distribution you're working with? Maybe I can help you a
>> bit with the debugging. If you're, at the moment, building GNU Radio, make
>> sure that the CMake parameters contain -DCMAKE_BUILD_TYPE=RelWithDebInfo
>> , so that we get debugging symbols :)
>>
>> Best regards,
>>
>> Marcus
>>
>> On 07/12/2017 05:11 PM, Alex Homero Rivadeneira Erazo wrote:
>>
>> Hi Marcus
>>
>> Based on your suggestion I have deleted my Nabbles account.
>>
>> Respect to my problem with the POLAR code configurator block, I checked
>> the discussion threads, but anyone gave a solution.
>>
>> Note that this problem does not happen with a gnuradio installed with the
>> distribution's package manager (standard installation). However, the
>> problem with this installation method is that gnuradio is not up to date
>> and it does not have all the blocks that I need in my work. That is why I
>> used pybombs to install gnuradio which has the blocks that I need. Now the
>> problem is that gnuradio with pybombs does work with the POLAR code
>> configurator block. When I drop the POLAR code configurator block on the
>> canvas, the gnuradio program turns down.
>>
>> At this moment, I am installing gnuradio from source. If you have other
>> ideas please tell me.
>>
>> Thanks
>>
>> Best regards,
>>
>> Alex
>>
>>
>>
>> On Wed, Jul 12, 2017 at 9:43 AM, Marcus Müller 
>> wrote:
>>
>>> Hi Alex,
>>>
>>> I hope you do get an answer, but that mail from Jose is from the
>>> beginning of 2016 – not extremely likely.
>>>
>>> Anyway, have you seen the other answers that Jose got?
>>> If not: That's Nabble's fault. I never tire to repeat:
>>> Nabble is just a terrible, terrible web frontend to use the official GNU
>>> Radio Mailing list.
>>>
>>> It's not the official mailing list archive. It never was, and it never
>>> will be. The official way to sign up for the mailing list is
>>>
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>> and there's a link to the official mailing list archive, too.
>>>
>>> I'd recommend deleting your Nabble account, and directly signing up
>>> under the above address with your email account. It's really easier to
>>> use a proper email client (eg. GMail's web frontend) and simply the
>>> mails than Nabble. Nabble breaks discussion threads, it makes answers
>>> invisible, and it has cost us hours and hours of unnecessary work so
>>> far. PLEASE, don't use Nabble.
>>>
>>> Best regards,
>>>
>>> Marcus
>>>
>>>
>>> On 07/12/2017 01:52 PM, Alex Rivadeneira wrote:
>>> > Dear Jose
>>> >
>>> > Can you tell me if you solved the problem with the POLAR code
>>> configurator
>>> > block? because I have the same problem in the gnuradio installed with
>>> > pybombs.
>>> >
>>> > Thanks
>>> >
>>> > Alex
>>> >
>>> >
>>> >
>>> > --
>>> > View this message in context: http://gnuradio.4.n7.nabble.co
>>> m/polar-code-example-tp58407p64520.html
>>> > Sent from the GnuRadio mailing list archive at Nabble.com.
>>> >
>>> > ___
>>> > Discuss-gnuradio mailing list
>>> > Discuss-gnuradio@gnu.org
>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>>
>> --
>> Regards,
>>
>> Alex Homero Rivadeneira E.
>> Cell: 438 397-8330 <%28438%29%20397-8330>
>>
>>
>>
>
>
> --
> Regards,
>
> Alex Homero Rivadeneira E.
> Cell: 438 397-8330 <(438)%20397-8330>
>
>
>


-- 
Regards,

Alex Homero Rivadeneira E.
Cell: 438 397-8330
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.o

[Discuss-gnuradio] Debugging polar code crashes (was: Re: polar code example)

[Marcus Müller]

Those test failures aren't great, but I think they might be bugs in the
tests.

So, OK, can't remember what you need to do under Ubuntu to get the full
Python debugging capability in GDB, but I wrote a (slightly dated, since
the python commands have improved) tutorial on debugging crashing Python
applications [1].
The idea is to simply execute your minimal crashing example using

gdb --args python2 /path/to/flowgraph.py
(gdb) run

(gdb) backtrace

and figure out why where how things crash. If you got a backtrace, and
don't immediately see how to proceed (hint: print a few local variables,
if possible, using gdb's "print" command), share it with the mailing list

Best regards,
Marcus

[1]https://wiki.gnuradio.org/index.php/TutorialsGDB
On 07/12/2017 05:50 PM, Alex Homero Rivadeneira Erazo wrote:
> I am using ubuntu 16.04 LTS.
>
> At the end of the make test, I have obtained some failures:
>
> 97% tests passed, 6 tests failed out of 218
>
> Total Test time (real) = 142.49 sec
>
> The following tests FAILED:
> 48 - qa_ctrlport_probes (Failed)
> 59 - qa_cpp_py_binding (Failed)
> 76 - qa_cpp_py_binding_set (Failed)
> 124 - qa_filterbank (Failed)
> 154 - qa_ofdm_txrx (Failed)
> 197 - qa_fading_model (Failed)
> Errors while running CTest
> Makefile:61: recipe for target 'test' failed
> make: *** [test] Error 8
>
> Best regards,
>
> Alex
>
>
>
>
>
>
> On Wed, Jul 12, 2017 at 11:46 AM, Marcus Müller
> mailto:marcus.muel...@ettus.com>> wrote:
>
> That might still give us enough debug info. Which Linux distro are
> we talking about (or, is it Linux at all?)
>
> Best regards,
>
> Marcus
>
>
> On 07/12/2017 05:30 PM, Alex Homero Rivadeneira Erazo wrote:
>> Hi Marcus
>>
>> At this moment, I am installing the
>> gnuradio 3.7.12git-171-get72c77bc from source, which is the same
>> that I installed with pybombs . Unfortunately, I just already
>> built the gnuradio with "make && make test". The gnuradio that I
>> had with the standard installation was gnuradio 3.7.9
>>
>> Thanks 
>>
>> Best regards,
>>
>> Alex
>>
>>
>>
>>
>> On Wed, Jul 12, 2017 at 11:13 AM, Marcus Müller
>> mailto:marcus.muel...@ettus.com>> wrote:
>>
>> Hi Alex,
>>
>> that does indeed sound like a bug. Things shouldn't be crashing!
>>
>> So, what's the distribution you're working with? Maybe I can
>> help you a bit with the debugging. If you're, at the moment,
>> building GNU Radio, make sure that the CMake parameters
>> contain -DCMAKE_BUILD_TYPE=RelWithDebInfo , so that we get
>> debugging symbols :)
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 07/12/2017 05:11 PM, Alex Homero Rivadeneira Erazo wrote:
>>> Hi Marcus 
>>>
>>> Based on your suggestion I have deleted my Nabbles account.
>>>
>>> Respect to my problem with the POLAR code
>>> configurator block, I checked the discussion threads, but
>>> anyone gave a solution.
>>>
>>> Note that this problem does not happen with
>>> a gnuradio installed with the distribution's package manager
>>> (standard installation). However, the problem with this
>>> installation method is that gnuradio is not up to date and
>>> it does not have all the blocks that I need in my work. That
>>> is why I used pybombs to install gnuradio which has the
>>> blocks that I need. Now the problem is that gnuradio with
>>> pybombs does work with the POLAR code configurator block.
>>> When I drop the POLAR code configurator block on the canvas,
>>> the gnuradio program turns down.
>>>
>>> At this moment, I am installing gnuradio from source. If you
>>> have other ideas please tell me. 
>>>
>>> Thanks
>>>
>>> Best regards,
>>>
>>> Alex 
>>>
>>>
>>>
>>> On Wed, Jul 12, 2017 at 9:43 AM, Marcus Müller
>>> mailto:marcus.muel...@ettus.com>>
>>> wrote:
>>>
>>> Hi Alex,
>>>
>>> I hope you do get an answer, but that mail from Jose is
>>> from the
>>> beginning of 2016 – not extremely likely.
>>>
>>> Anyway, have you seen the other answers that Jose got?
>>> If not: That's Nabble's fault. I never tire to repeat:
>>> Nabble is just a terrible, terrible web frontend to use
>>> the official GNU
>>> Radio Mailing list.
>>>
>>> It's not the official mailing list archive. It never
>>> was, and it never
>>> will be. The official way to sign up for the mailing list is
>>>
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> 
>>>
>>> and there's a link to the official mailing list archive,
>>> too.
>>>
>>> I'd recommend deleting your Nabble account, and directly
>>> 

Re: [Discuss-gnuradio] Chunks to symbols with 16 QAM modulation

[Rafik ZITOUNI]

Dear Cinaed,

Thanks for your answer.

I tried with my Tx and it works fine with a constellation, but with my
receiver symbols or  constellation_decoder, digital.qam_16()[1] gives me an
error.

line 164, in __init__
self.digital_constellation_decoder_cb_0_0 =
digital.constellation_decoder_cb(digital.qam_16()[1])

Best,




2017-07-12 2:26 GMT+02:00 Cinaed Simson :

> On 07/11/2017 05:13 AM, Rafik ZITOUNI wrote:
> > Dear gnuradio users,
> >
> > I am trying to use digital_chunks_to_symbols to reconstruct block by
> > block my QAM modulator.
> >
> > Please could you give me an idea how to set the constellation points in
> > Symbol Table field?  I can do it with BPSK, QPSK and 8PSK using
> > constellation[0].points, constellation[1].points and
> > constellation[2].points, but how can I do it with 16 QAM ?
>
> Try
>
>  Symbols:digital.qam_16()[1]
>  Constellations: digital.qam_16()[0]
>
> -- Cinaed
>
>
> >
> > For my 16 QAM receiver, could you please tell me if it's possible to
> > have a constellation points view?
> >
> > Best,
> >
> > --
> > **Rafik
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Rafik
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OOT Block to Automatically adjust Transmit Gain

[Tellrell White]

Hello Guys 
I'm currently in the process of creating a block in python that does two 
things; takes in  a certain number of input items, and once it reaches a 
certain number of input items 2) it sends a command to the UHD USRP sink block 
to adjust its gain by a certain amount. 

I have a few questions. 1) Is it even possible to create a single block that 
can accomplish both these tasks? 2) How exactly do I make this block issue the 
command to adjust the gain after it receives a certain number of values??Below 
is some code that I currently have constructed for this purpose. I'm pretty new 
to python so I'm sure this code is probably not the most efficient way but any 
suggestions are welcome.
Tellrell 
import numpy as np
from gnuradio import gr
import pmt
from random import uniform

class blk(gr.sync_block):
    def __init__(self, initial_gain=5, stop_gain=15, step=0.5)# only default 
arguments here
    gr.sync_block.__init__(
    self,
    name='Gain Sweeper',
    in_sig=[np.complex32],
    out_sig=[np.complex32]
    )
    self.message_port_register_in(pmt.intern('msg_in'))
    self.set_msg_handler(pmt.intern('msg_in'),self.handle_msg)
    self.message_port_register_out(pmt.intern('msg_out'))
    self.gain = initial_gain
    self.step = step
    self.stop = stop_gain


    def handle_msg(self, pdu, a= 00):
    self.message_port_pub(pmt.intern('msg_out'),pmt.cons
    (pmt.intern("gain"),pmt.to_pmt(self.gain)))
    self.gain+=self.step
    
    return 1


    def work(self, input_items, output_items):
    in0 = input_items[0]
    out = output_items[0]
    
    while i <= 1:
 sample = in0[i]
 if i == 1:
    sample = 0

    return len(output_items[0])



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Decoding 2FSK Compensating for carrier jitter/skewing (CFO)

[Cinaed Simson]

On 07/12/2017 03:56 AM, HLL wrote:
> 
> 
> On Wed, Jul 12, 2017 at 1:56 AM, Cinaed Simson  > wrote:
> 
> It seems odd that a device with a maximum power 116 dBm would have such
> a weak signal.
> 
> As I mentioned earlier, I'm not really sure what is the frequency of the
> device is, I just scanned the 300 + area and I found a few that
> correlate with the device transmission
> This one was taken on 440.15M; I Also have another similar capture,
> captured at 419.562M

At least the ones in the US operate between at 4 frequencies between
450-470 MHz.

The frequency band will vary with country.

> 
> 
> Maybe the antenna was to close? The distance of the receiving antenna
> was roughly 0.1 of the carrier wavelength from transmitting antenna.
> 
> I guess it was, distance was around 8-15 cm or so, as the wavelength is
> 68.15cm, When capturing I didn't considered it (or even known it is a
> factor)

The wavelength for 450 is 1.5 meters. I really don't know where the
boundary is between near field and far field - but I would guess far
field the other side of a full wave length.


> The antenna used is the stock RTL SDR one.

It's quarter wave antenna I believe for around 800-900 MHz.

> 
> If you can recommend some hackish (DIY or even retail) antenna to better
> receive that signal that would be grate.

Let me think about it. I use a RTL dongle from NooElec which has a SMA
connector.

> 
> 
> Also, the documents indicate the channel width is from 7 kHz to 16 kHz -
> the sampling rate of 8 kHz may have been to small.
> 
> Well, As  Andy mentioned, it's not FSK, so the documentation may be
> talking about other version of the device.
> I Downsampled the capture to 8khz after centering because that was much
> more then 2 times of bandwidth I've seen on the FFT on active burst

Actually, that should read 7-12.5 kHz. If I was doing it, and the
documents indicated it uses a channel between 7-12.5 KHz, then I would
sample at 64 kHz.

-- Cinaed


> 
> 
> But in any case, there's a lot of good information in this thread and
> it's going to take me a while to digest all of it.
> 
> If that helps, I kindda made a quick graph that does similar thing to
> Andy's graph, and I got similar results:
> 
> Inline image 1
>  
> now it seems that a large CFO glitch translates to short glitchs in the
> digital signal
> 
> Graph:
> Inline image 2
> 
> 
> 
> 
> 
> On 07/10/2017 05:55 PM, Andy Walls wrote:
> > From: HLL
> > Date: Mon, 10 Jul 2017 20:44:01 +0300
> >> Hi,
> >> Thank you very much!!
> >> I Need to thoroughly go over your response and understand it all, but
> >> thanks :)
> >>
> >> I also noticed the 2 different in bit timings, I thought it's
> >> something electrically, since I noticed the "long" lows and highs are
> >> on some specific timings and the shorts have another timing.
> >>
> >> Before experimenting with the graph (and the said OOT modules). I'm
> >> going over it and trying to understand it,
> >> what the rotator does, and what it it's role?
> >
> > It performs a (cyclic) frequency shift of the signal spectrum.  It is
> > called a rotator because the DFT of a sampled signal "lives" on the
> > unit circle of the z-plane.  The rotator block rotates the entire z-
> > plane about its origin by a certain number of radians, thus
> effectively
> >  shifting the spectrum of the signal.
> >
> > I use the rotator block to shift the audio frequency bins of +350 Hz
> > and +940 Hz down to -295 Hz and +295 Hz respectively.  Then I filter
> > off what were the negative audio frequency bins, the DC spike from the
> > FM CFO, and a lot of the spectrum which is just noise.
> >
> >> The part with 2 pll carrier tracking is used for locking the carrier
> >> of the low and high freq as I understand (I.E. The cheap digital PWM
> >> or clock devider)
> >
> > Yes, but they both track *and* downconvert the tracked tone to DC.
> >
> > This is a coherent FSK receiver design, which is probably overkill for
> > this application, but I used it to handle uncertainty in the actual
> > audio tone bins used for the mark and space frequencies.
> >
> >> what is the role of the complex conjugates (mirror over the real
> >> axis?),
> >
> > The complex conjugate is to handle a quirk of the GNURadio PLL block
> > before the subtraction.  When the PLL carrier tracking block does it's
> > downconversion of the tracked tone to DC, it doesn't have a phase
> angle
> > of 0 degrees (a purely real number), instead it has a phase angle of
> > something a bit less than pi/4 radians.
> >
> > The complex conjugate is so when I do the following subtract, I will
> > get constellation points on opposite sides of the circle in the I-Q
> > plane.
> >
> >
> >>  subtract,
>

Re: [Discuss-gnuradio] Decoding 2FSK Compensating for carrier jitter/skewing (CFO)

[Cinaed Simson]

Would you compare the sha512sum of your raw data file with mine?

8cbb5adfc64b2c31c3b77e3ff3ba3f1867b8c9a87712e649bdae2b2c991c2bb0088cd888f37288e1e5eb5c9c0bb96ac39a484237a06523631c133c621f546322

-- Cinaed


On 07/12/2017 04:50 AM, HLL wrote:
> Images didn't go through, here they are:
> Inline image 1
> 
> Graph:
> Inline image 2
> 
> On Wed, Jul 12, 2017 at 1:56 PM, HLL  > wrote:
> 
> 
> 
> On Wed, Jul 12, 2017 at 1:56 AM, Cinaed Simson
> mailto:cinaed.sim...@gmail.com>> wrote:
> 
> It seems odd that a device with a maximum power 116 dBm would
> have such
> a weak signal.
> 
> As I mentioned earlier, I'm not really sure what is the frequency of
> the device is, I just scanned the 300 + area and I found a few that
> correlate with the device transmission
> This one was taken on 440.15M; I Also have another similar capture,
> captured at 419.562M
> 
> 
> Maybe the antenna was to close? The distance of the receiving
> antenna
> was roughly 0.1 of the carrier wavelength from transmitting antenna.
> 
> I guess it was, distance was around 8-15 cm or so, as the wavelength
> is 68.15cm, When capturing I didn't considered it (or even known it
> is a factor)
> The antenna used is the stock RTL SDR one.
> 
> If you can recommend some hackish (DIY or even retail) antenna to
> better receive that signal that would be grate.
> 
> 
> Also, the documents indicate the channel width is from 7 kHz to
> 16 kHz -
> the sampling rate of 8 kHz may have been to small.
> 
> Well, As  Andy mentioned, it's not FSK, so the documentation may be
> talking about other version of the device.
> I Downsampled the capture to 8khz after centering because that was
> much more then 2 times of bandwidth I've seen on the FFT on active burst
> 
> 
> But in any case, there's a lot of good information in this
> thread and
> it's going to take me a while to digest all of it.
> 
> If that helps, I kindda made a quick graph that does similar thing
> to Andy's graph, and I got similar results:
> 
> 
> now it seems that a large CFO glitch translates to short glitchs in
> the digital signal
> 
> Graph:
> 
> 
> 
> 
> 
> 
> On 07/10/2017 05:55 PM, Andy Walls wrote:
> > From: HLL
> > Date: Mon, 10 Jul 2017 20:44:01 +0300
> >> Hi,
> >> Thank you very much!!
> >> I Need to thoroughly go over your response and understand it
> all, but
> >> thanks :)
> >>
> >> I also noticed the 2 different in bit timings, I thought it's
> >> something electrically, since I noticed the "long" lows and
> highs are
> >> on some specific timings and the shorts have another timing.
> >>
> >> Before experimenting with the graph (and the said OOT
> modules). I'm
> >> going over it and trying to understand it,
> >> what the rotator does, and what it it's role?
> >
> > It performs a (cyclic) frequency shift of the signal
> spectrum.  It is
> > called a rotator because the DFT of a sampled signal "lives"
> on the
> > unit circle of the z-plane.  The rotator block rotates the
> entire z-
> > plane about its origin by a certain number of radians, thus
> effectively
> >  shifting the spectrum of the signal.
> >
> > I use the rotator block to shift the audio frequency bins of
> +350 Hz
> > and +940 Hz down to -295 Hz and +295 Hz respectively.  Then I
> filter
> > off what were the negative audio frequency bins, the DC spike
> from the
> > FM CFO, and a lot of the spectrum which is just noise.
> >
> >> The part with 2 pll carrier tracking is used for locking the
> carrier
> >> of the low and high freq as I understand (I.E. The cheap
> digital PWM
> >> or clock devider)
> >
> > Yes, but they both track *and* downconvert the tracked tone to DC.
> >
> > This is a coherent FSK receiver design, which is probably
> overkill for
> > this application, but I used it to handle uncertainty in the
> actual
> > audio tone bins used for the mark and space frequencies.
> >
> >> what is the role of the complex conjugates (mirror over the real
> >> axis?),
> >
> > The complex conjugate is to handle a quirk of the GNURadio PLL
> block
> > before the subtraction.  When the PLL carrier tracking block
> does it's
> > downconversion of the tracked tone to DC, it doesn't have a
> phase angle
> > of 0 degrees (a purely real number), instead it has a phase
> angle of
> > something a bit less than pi/