Re: [Discuss-gnuradio] Help understanding AX.25 encoding and tagged streams

2017-08-15 Thread Cinaed Simson 
On 08/14/2017 07:14 AM, Jack White wrote:
> Hello, knowledgeable ones,
> 
> I need to put together testbed satellite uplink using AX.25 encoding and
> GMSK modulation. The flowgraph source is an Ettus USRP X310 with a
> WBX-120 daughterboard.
> 
> The flowgraph is a modification of one used with a USRP B210. That radio
> had handle different sample rates to the X310, so some level of
> resampling is required - in this case from the proposed 614.4ksps to
> 400ksps.
> 
> I understand the premise of constructing the AX.25 packet, but I'm
> having real difficulty understand tagged streams and how the tagging and
> the PDU format is affecting my transmission.>
> 
> ​
> ​
> ​
> The disabled low-pass filter and the enabled and encircled rational
> resampler are my additions. The AX.25 line coding hierarchical block is
> below.
> 
> 
> ​
> ​So, when I run the flowgraph and try to set a command from the
> groundstation, I get a huge load of buffer underrun errors in the GRC
> log:
> 
> 
> UUU
> UU
> 
> If I try sending the command again, I get a tP error, followed by more
> underruns.
> 
> In my head, it looks like the USRP is expecting a combined sample of a
> certain length, but it doesn't get it. The buffer is more than half
> full. Then the next packet comes in, of the same length, and you get one
> buffer filled with half of one packet and half of another.
> 
> The USRP /is/ transmitting something, because I checked the transmitting
> antenn400k/614.4a on a spectrum analyser.
> 
> Can anyone help me understand the flowgraph, especially the tagged
> streams and PDU input, and get this working?
> 
> Cheers,

I don't really understand what you're doing but I have a couple of drive
by comments.

The produce of 2 rationals is always rational - and the quotient of two
rationals is always rational.

I would replace the 2 serial rational resamplers with one, namely,

  (8/1)*(40/614400)=(8/1)*400/614.4) = 5.208/1

or

  15.625/3

That is, interpolate by 15.625 decimate by 3.

Since the sampling rate of the sink is 40 Hz, then the sampling rate
coming out of the GFSK Mod needs to be 76800 Hz.

And the baud rate out of the GFSK Mod would then be 76800 Hz/8 sps = 9600.

If reducing the 2 serial rational resamplers to one doesn't help,  I
would poke the front side of GFSK Mod - add a throttle in front of the
GFSK and set it to 76800 Hz - see what happens- not recommend for
general use.

And I would add a Message Debug to Tagged Stream Multiply Length Tag and
set the Length scalar to 1 - 512 times the packet_length seems high -
but then I don't know the packet_length either.

-- CInaed

> 
> -- 
> Jack White
> white.n.j...@googlemail.com 
> 07875 813 745
> 
> 
> ___
> 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 add code to a gnuradio_companion variable setter

2017-08-15 Thread Kai Garrels 
Hi, 

thanks for all the hints I received.

Based on that, I managed to do a rude hack with the XML file and an embedded 
python module.
It works, but it just doesn't feel right :)

What I try to achieve; control an external radio via TCP commands based on the 
frequency (or other) variable in the flowgraph.

So I will investigate an OOT python block based on messages, sounds really more 
reasonable.

Which GUI blocks can send messages?

PS:
Yes, I struggled with GRC's real name. I use an alias "grc", and was not sure 
if everybody knows what I mean.
And then typos...




> Am 15.08.2017 um 18:00 schrieb discuss-gnuradio-requ...@gnu.org:
> 
> 
> Message: 5
> Date: Mon, 14 Aug 2017 22:27:52 +0200
> From: Marcus M?ller mailto:muel...@kit.edu>>
> To: mailto:discuss-gnuradio@gnu.org>>
> Subject: Re: [Discuss-gnuradio] How to add code to a
>   gnuradio_companion variable setter
> Message-ID: <9d9a14e0-aed9-9204-022f-9a5f8b832...@kit.edu 
> >
> Content-Type: text/plain; charset="utf-8"; format=flowed
> 
> Hi kai,
> 
> short version:
> 
> 1. make an out-of-tree module
> 2. add new block ? python or cpp, doesn't matter, should be of type 
> "noblock" if you really just want to do anything.
> 3. modify the XML file describing that block for the GNU Radio 
> Companion, so that it has a parameter with a 
> methodname($parametername) field.
> 4. do what you want in yourblock.methodname(parameter)
> 5. build and install that module
> 
> You'll find an intro on how to use gr_modtool to generate out-of-tree 
> modules in the "Guided Tutorials" on http://tutorials.gnuradio.org 
>  .
> 
> BUT: I **Really** would discourage trying to do what you're doing. Use 
> message passing instead. What is it that you want to build? I'm almost 
> certain what you're trying to achieve can be done in different, less 
> "complicated" manners.
> 
> Best regards,
> Marcus
> 
> PS: we say "GRC" or "GNU Radio companion", because it's the "graphical 
> companion to GNU Radio"; "gnu radio_companion" just seems wrong :)
> 

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

Re: [Discuss-gnuradio] Profiling Gnuradio message based blocks

2017-08-15 Thread Marcus Müller 

Dear Jeff,

from the top of my head:

the perf counters count the time a block spends in its work(), how many 
items were consumed and produced in calls to work(), as well as things 
as buffer fillage and such.


Well, all these things don't apply to message passing, since there's no 
call to work or ring buffers involved.


So, you'd need to formulate exactly what you'd want to measure, and in 
your block's constructor add the RPC variable, and make sure your 
message handler function does the benchmarking.


In general, you should probably add these variables to gr::block's 
constructor and have a "start_perf_counters_msg_handling" or so method 
(similar to the start_perf_counters() method) that you call before 
entering the message handling code in tpb_thread_body.


But note: this code is very ugly. Personally, tpb_thread_body shouldn't 
be doing the message handling, that should've been incorporated in 
block_executor. Now that you try to add perf counters, that introduces 
additional complexity, but that's still manageable. But it's yet another 
"bolt-on" for the current scheduler that makes it less beautiful :/ . 
Gotta rewrite that stuff (someday).


Cheers,

Marcus


On 08/15/2017 03:51 PM, Jeffrey Grasty wrote:

Hi,

I am trying to profile some message based blocks with performance 
monitor.  The message blocks appear in the gr-perf-monitorx; however, 
they do not appear in runtime table.  This questions asks same thing: 
https://lists.gnu.org/archive/html/discuss-gnuradio/2017-01/msg00121.html


It looks like a fix for this was incorporated in 3.7.10.2 
(https://github.com/gnuradio/gnuradio/pull/1119). I am running 
3.7.12.  Is there a configuration setting to enable profiling of 
message based blocks I am missing?


Thanks,

Jeff


___
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] git clone failure

2017-08-15 Thread Derek Kozel 
Hello Raj,

The repository is still there but the SSL certificate needs to be
updated/fixed.

As a temporary measure you can tell git to ignore the error, or you can use
GitHub's repository.
https://stackoverflow.com/a/21407163/825508

Thanks for sharing the problem.

Derek

On Tue, Aug 15, 2017 at 2:31 PM, Raj Bhattacharjea  wrote:

> I'm seeing a certificate error when I run:
> git clone --recursive http://git.gnuradio.org/git/gnuradio.git
>
> The error is:
> fatal: unable to access 'https://git.gnuradio.org/git/gnuradio.git/':
> SSL: certificate subject name (gnuradio.org) does not match target host
> name 'git.gnuradio.org'
>
> This is the recommended way to clone according to the wiki:
> https://wiki.gnuradio.org/index.php/Download
>
> But my guess is these instructions are stale, and github is now the
> official home of the repo. Do these instructions need to be updated, or am
> I doing something wrong?
>
> --
> Raj Bhattacharjea, PhD
> Georgia Tech Research Institute
> Information and Communications Laboratory
> http://www.prism.gatech.edu/~rb288/
> 404.407.6622 <(404)%20407-6622>
>
> ___
> 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

[Discuss-gnuradio] Profiling Gnuradio message based blocks

2017-08-15 Thread Jeffrey Grasty 
Hi,

I am trying to profile some message based blocks with performance monitor.
The message blocks appear in the gr-perf-monitorx; however, they do not
appear in runtime table.  This questions asks same thing:
https://lists.gnu.org/archive/html/discuss-gnuradio/2017-01/msg00121.html

It looks like a fix for this was incorporated in 3.7.10.2 (
https://github.com/gnuradio/gnuradio/pull/1119). I am running 3.7.12.  Is
there a configuration setting to enable profiling of message based blocks I
am missing?

Thanks,

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

[Discuss-gnuradio] git clone failure

2017-08-15 Thread Raj Bhattacharjea 
I'm seeing a certificate error when I run:
git clone --recursive http://git.gnuradio.org/git/gnuradio.git

The error is:
fatal: unable to access 'https://git.gnuradio.org/git/gnuradio.git/': SSL:
certificate subject name (gnuradio.org) does not match target host name '
git.gnuradio.org'

This is the recommended way to clone according to the wiki:
https://wiki.gnuradio.org/index.php/Download

But my guess is these instructions are stale, and github is now the
official home of the repo. Do these instructions need to be updated, or am
I doing something wrong?

-- 
Raj Bhattacharjea, PhD
Georgia Tech Research Institute
Information and Communications Laboratory
http://www.prism.gatech.edu/~rb288/
404.407.6622
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] doubts about burst tranmission using tag SOB and EOB

2017-08-15 Thread Marcus D. Leech 
I'll note that the "Message Burst Source" is now deprecated.  Not sure 
what it has been replaced with.   I've taken the liberty of cross-posting to

  discuss-gnuradio.


On 08/02/2017 02:05 PM, Yang Liu via USRP-users wrote:

Dear all,

I tried to achieve burst transmission on usrp X310, the brief tx 
flowgraph is in the below:


message_burst_source -> signal processing blocks --> usrp_sink

New message will be inserted into the message queue of 
message_burst_source.


Since message_burst_source will attach SOB and EOB tag to the data 
stream, usrp will know the start and end of each burst. After reading 
'Busrt Transmission' section in this link: 
https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html, my 
understanding is that because of these two tags, even the two message 
arrives at usrp at a different time, usrp will not complain about 
underrun. However, according to results from my experiments, as the 
time difference between two contiguous message increases, underflow 
will show up and become more and more severe. For a real burst 
transmission, time gap between two message should be expected. 
Therefore, I feel confused about the using of SOB and EOB tags here. 
Can they help to remove "underrun" under burst transmission? If not, 
is there any other methods that can make burst transmission with usrp 
possible without triggering underrun?


Thanks a lot for your help,
Yang



___
USRP-users mailing list
usrp-us...@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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