Re: XML Client Issue - Gnuradio 3.8

[Vitt Benv]

HI,
thanks to you Glen and Marcus!
Searching I see that there's an opened issue about that, and I'll try to
tweak manually the GRC generate source to the correct Python3 syntax.
Anyway, thanks again,

Vittorio

Il giorno mar 21 apr 2020 alle ore 23:30 Marcus D. Leech <
patchvonbr...@gmail.com> ha scritto:

> On 04/21/2020 01:04 PM, Vitt Benv wrote:
>
> Good evening,
>
> I'm experiencing this error while using a XMLRPC Client block:
>
> #
> Executing: /usr/bin/python3 -u /home/vic/remote-trx/local_6.py
>
>   File "/home/vic/remote-trx/local_6.py", line 192
> self.xmlrpc_client_0 = xmlrpclib.Server('http://'192.168.1.80':12100')
>^
> SyntaxError: invalid syntax
> #
>
> I'm on version 3.8, and I suppose that this issue it's related to this
> Gnuradio version; in version 3.7 all runs fine (the counterpart of this
> flowgraph sits on a Gnuradio 3.7 and there isnt any problem)
>
> Any suggestion / workaround ???
>
> Thanks in advance,
>
> Vittorio I3VFJ
>
> Not a GR 3.7->3.8 issue, per-se, but because the quoting rules in Python 3
> are slightly different than Python 2.
>
>
>

XML Client Issue - Gnuradio 3.8

[Vitt Benv]

Good evening,

I'm experiencing this error while using a XMLRPC Client block:

#
Executing: /usr/bin/python3 -u /home/vic/remote-trx/local_6.py

  File "/home/vic/remote-trx/local_6.py", line 192
self.xmlrpc_client_0 = xmlrpclib.Server('http://'192.168.1.80':12100')
   ^
SyntaxError: invalid syntax
#

I'm on version 3.8, and I suppose that this issue it's related to this
Gnuradio version; in version 3.7 all runs fine (the counterpart of this
flowgraph sits on a Gnuradio 3.7 and there isnt any problem)

Any suggestion / workaround ???

Thanks in advance,

Vittorio I3VFJ

Re: Variables and messages - never the twain shall meet?

[Vitt Benv]

Good afternoon David and list!
Recently I had your same problems developing an application ( a SDR
transceiver, mainly for satellite ops, based on ADALM Pluto).
The main headache was " how I can *click* on the waterfall and *tune*
there?...", clearly invoking some variable interaction then yor same
problem!
Next, studying much deeper how manage messages I found a nice solution: a
block that "manipulate" the input message and send several different
messages ( RX chain / TX chain) around the flowgraph.
Please, take a look to https://sourceforge.net/projects/qo100-pluto/ .
Please use the last version.
It isn't currently finished but it's working!
Actually this work has another goal: "split" the transceiver in two parts:
a REMOTE, low noise site + antennas + PA + allthestuff connected via LTE
link to a LOCAL where all the magic happen ( demod / tuning /voice
compressor and so on). The main effort is related to minimize the request
bandwidth on LTE link ( $ )
Hope that could help!

73's de I3VFJ, Vittorio

Il giorno lun 20 apr 2020 alle ore 02:27 David Hagood <
david.hag...@gmail.com> ha scritto:

> It seems to me that there is a fundamental design flaw in how the UI
> elements of GnuRadio Companion work.
>
> Several modules, like the Qt Frequency blocks, can output messages when
> you click them, to inform *somebody* as to where you clicked. This would
> be great for setting a new frequency, but...
>
> All the Qt UI elements, like ranges and check boxes, only work on
> variables, and cannot accept nor generate messages. So if you want your
> UI to have a range box to set center frequency, it has to modify a
> variable.
>
> BUT: Since there seems to be no way to have a message be received and
> update a variable, there is no way to have the Qt Frequency display
> message update a variable that is controlled by a Qt Range object.
>
>
> I've tried to write my own block to handle the messages and update the
> variable, BUT:
>
> 1) You cannot access variables inside the block from the UI elements -
> they all fail with a "type null is unacceptable for the variable", so
> you cannot save the flow graph.
>
> 2) If you do an ugly thing and pass "self" (the flowgraph object) to the
> block, you can access the variables in the flowgraph, but setting the
> variable directly does not call any update functions (i.e. the
> set_ setter method is not called).
>
> 3) If you have the block call the set_ function directly, and
> if the update manipulates any Qt object (which is needed so that the UI
> will update), it fails because the message handler is in a different
> thread from the flowgraph UI, and Qt won't allow the call to happen.
>
> 4) There is the function probe, which
>
> 4a) is ugly because it is polling code
>
> 4b) does not seem to be able to set a flowgraph level variable to the
> return value of the function, making it useless for this purpose anyway.
>
>
> Now, if ALL UI elements could handle messages, then you could at least
> write a block that could parse the messages from UI elements, and create
> new messages as needed to "make things happen". Or if there were a way
> to add a message handler to the flowgraph and specialize it's code, you
> could handle messages that way. Or if there were a block that would
> accept messages and set variables at the flowgraph level based upon the
> message (with any callbacks happening correctly), that would work.
>
>
> I don't see how a non-trivial application can be created without having
> some solution to this, so am I missing something? or is this something
> that will be fixed sometime in the misty future with all the UI elements
> have been re-written to handle messages?
>
>
>
>

Fwd: Frequency Xlating Fir Filter issue passing message

[Vitt Benv]

Sorry, this is for the list... replayed only to Marcus 

-- Forwarded message -
Da: Vitt Benv 
Date: sab 21 mar 2020 alle ore 16:11
Subject: Re: Frequency Xlating Fir Filter issue passing message
To: Marcus D. Leech 


Good afternoon,
yes Marcus, just a "quick look"!
It's clear to me how freq.xlatinf.filter works, and I'm quite shure that
I'm working on BB signal...
But it's my mistake, I want to apologize to the list: I was passing on the
output port the wrong type ( int vs float) and (worst, shame on me) the
wrong variable... acc, this "social containment" for the COVID19 has bad
effects!
So, anyway, tnx for ur replay and, again sorry for the noise ;-)

Vittorio

Il giorno ven 20 mar 2020 alle ore 22:49 Marcus D. Leech <
patchvonbr...@gmail.com> ha scritto:

> On 03/20/2020 05:10 PM, Vitt Benv wrote:
>
> Good evening,
>
> I'm trying to make a multimode receiver using a PlutoSDR; all the 
> demodulation and visualization parts work correctly.
> Now I would like to use a click'n-point tuning and as a result I have tried 
> to understand something more about the use of controlports.
> I followed some tutorials and made a custom block (myblock.py "Message 
> splitter") which receives the message generated by double clicking on the 
> waterfallas an input and
> generates a message to be sent to the Frequency Xlating Fir Filter block, 
> which consists of an offset between the center frequency (fx) and the 
> frequency generated by the double click.
> I state that by controlling this block with a slider (fx_tune) everything 
> works correctly, but using the outgoing message the set frequency is 
> completely incorrect.
> In the embedeed block I perform an output of the variables involved directly 
> on the console and everything "apparently" is correct.
> Any ideas / suggestions?
> Attached is the .grc file, the source of the "Message splitter" block and a 
> printscreen of the blocks (I have eliminated what is unnecessary and already 
> functional).
> Thanks in advance,
>
> Vittorio, I3VFJ
>
>
> Quick look suggests that you're confused about how the freq-xlating-filter
> works.  The center frequency is the *baseband* frequency, not
>   the RF frequency that your hardware is tuned to.  Gnu Radio, internally,
> deals with basebanded signals, typically, and the RF frequencies
>   are purely hardware-on-the-outside thing.
>
>
>

Frequency Xlating Fir Filter issue passing message

[Vitt Benv]

Good evening,

I'm trying to make a multimode receiver using a PlutoSDR; all the
demodulation and visualization parts work correctly.
Now I would like to use a click'n-point tuning and as a result I have
tried to understand something more about the use of controlports.
I followed some tutorials and made a custom block (myblock.py "Message
splitter") which receives the message generated by double clicking on
the waterfallas an input and
generates a message to be sent to the Frequency Xlating Fir Filter
block, which consists of an offset between the center frequency (fx)
and the frequency generated by the double click.
I state that by controlling this block with a slider (fx_tune)
everything works correctly, but using the outgoing message the set
frequency is completely incorrect.
In the embedeed block I perform an output of the variables involved
directly on the console and everything "apparently" is correct.
Any ideas / suggestions?
Attached is the .grc file, the source of the "Message splitter" block
and a printscreen of the blocks (I have eliminated what is unnecessary
and already functional).
Thanks in advance,

Vittorio, I3VFJ
"""
Embedded Python Blocks:

Each time this file is saved, GRC will instantiate the first class it finds
to get ports and parameters of your block. The arguments to __init__  will
be the parameters. All of them are required to have default values!
"""

#import numpy as np
from gnuradio import gr
import pmt
global param_1

class my_block(gr.sync_block):  # other base classes are basic_block, 
decim_block, interp_block
"""my msg splitter"""

def __init__(self, LO_1=1.0):
gr.sync_block.__init__(self, 
 name = "Message splitter",
 in_sig = None,
 out_sig = None)
self.message_port_register_in(pmt.intern('msg_in'))
self.message_port_register_out(pmt.intern('LO_1'))
#self.message_port_register_out(pmt.intern('LO_2'))
self.set_msg_handler(pmt.intern('msg_in'), self.handle_msg)
# if an attribute with the same name as a parameter is found,
# a callback is registered (properties work, too).
self.param_1= LO_1
#self.param_2= LO_2

def handle_msg(self, msg):
print ("in--> ", (msg), pmt.cdr(msg))
#freq_in_tag = pmt.car(msg)
freq_in_value = pmt.to_double(pmt.cdr(msg))
new_freq = freq_in_value - self.param_1 + 0.5
#new_freq = freq_in_value
#new_msg = pmt.set_cdr(msg, pmt.from_double(new_freq))
x = pmt.string_to_symbol("freq")
y = pmt.from_double(new_freq)
new_msg = pmt.cons(x, y)
print ("out--> ", new_msg, freq_in_value)

self.message_port_pub(pmt.intern('LO_1'), msg)
#self.message_port_pub(pmt.intern('LO_2'), new_msg)


def work(self, input_items, output_items):
output_items[0][:] = input_items[0]
return len(output_items[0])


wrong.grc
Description: Binary data

Re: [Discuss-gnuradio] cheap sdr platform

[Vitt Benv]

Take a look also at LimeSDR... there is a "mini" version for about 150$.
If I recall right it's a fullduplex 12 bit ADC/DDC, ranging 1MHz / 6GHz
with 20 MSPS, with USB port.

https://www.crowdsupply.com/lime-micro/limesdr-mini#details-top

victor

Il 29 set 2017 10:21, "w xd"  ha scritto:

> Hello guys,
>
>   Have some suggestion on the cheaper SDR platform for us
> to use with the GNURADIO software? As a student, I cannot buy the expensive
> usrp ,but I want to learn the knowledge by the hardware and software. Any
> recommend? For example,use the hardware to do some experiments about
> LTE/WIFI.
>
>
>
> ___
> 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] New GR-SQL Module

[Vitt Benv]

Nice!! just what I was looking on... got big IQ files and look in deeper as
second-pass analysis.
Next days, I'm abroad now, I'll make some tests.
Tnx GhostOp !!!👍

Victor

Il 24 set 2017 20:11, "Ghost Op"  ha scritto:

> Hi everyone,
>
> Back from GRCon2017 (one of the best conferences I've been to) and had
> some time for some more module development.  During the conference in
> one of the working sessions there was a suggestion for a module that
> would allow you to query really large IQ files with a SQL-like syntax.
>
> Made sense, 500 GB file but you only want a minute or two of the
> sample rather than having to go through the whole thing.  So I put one
> together and posted up on github
> (https://github.com/ghostop14/gr-sql).
>
> Basic to start.  Has a command-line tool called grsql (the readme has
> some examples) to extract portions to a new file, and a flowgraph
> block to play excerpt directly.
>
> Basic syntax:
>
> Get the total time length of a file:
> grsql "select TIMELENGTH FROM '/tmp/myrecording_593MHz_6.2MSPS.raw'
> ASDATATYPE complex SAMPLERATE 6.2M"
>
> Extracting data from 45.2 seconds to 80 seconds into the save to a new
> file:
> grsql "SELECT * FROM '/tmp/myrecording_593MHz_6.2MSPS.raw' ASDATATYPE
> complex SAMPLERATE 6.2M STARTTIME 45.2 ENDTIME 80.0 SAVEAS
> '/tmp/extracted.raw'"
>
> In the flowgraph block, saveas doesn't apply but you can play specific
> time ranges back directly from the flowgraph without needing to
> extract from the file (if you're looking for a signal in the
> recording).
>
> If you're working on some blind analysis, if you extract a sample to a
> new file, you may want to use the gr-filerepeater block up on my
> github too.  It'll let you put delays between replays so that any
> blocks looking for signal continuity won't get too "confused" by going
> directly from the end of a sample immediately to the first sample
> creating a weird signal discontinuity as it "jumps".  gr-filerepeater
> will let it go "quiet" for a specified period of time so the blocks
> can settle before trying to decode / demod again.
>
> Anyway it's alpha/beta but it works.  If you run into any bugs or are
> working with some big files and want any particular features, drop me
> a note.  If all looks pretty solid and there's interest I can set up a
> pull to integrate it into pybombs for an easier install.
>
> Mike
>
> ___
> 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] Time syncing between SDRs on different computers

[Vitt Benv]

In my experience "rf inserting" 1pps into early receiver (sampler) stages,
maybe "coding" timing with 1pps && 10Hz, all derived from gps reference.
This "affect" the signal under analysis but that can be do only
periodically... for multilateration ;-)

Victor

Il 16 ago 2017 19:45,  ha scritto:

> No.
>
> On Thu, 2017-08-17 at 01:52 +1000, vk4...@tech-software.net wrote:
> > Are you trying to do MultiLateration using software defined radio ?
> >
>
> ___
> 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] GNURadio and 802.15.4

[Vitt Benv]

try  ' arp -s 'ip number'  'mac-address'

victor

Il 28 giu 2017 4:16 PM, "Markley da Silva Mendes" 
ha scritto:

> Good Morning,
>
> I'm using GNU Radio to get a signal 802.15.4 (Zigbee), besides capturing a
> signal, I want to send a command to light a led (I'm using my module in a
> Galileo intel). But I'm having difficulty in saying that this prototype
> does not have an ip address but a mac address.
> I would like to know if GNU Radio provides some block to try to solulate
> my problem (I'm using block gr-802-15-4).
>
> Thanks in advance
>
> ___
> 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] Which block for Fast PSK demodulation under some doppler shift?

[Vitt Benv]

Hi Mehmeto,
in my opinion and in my experience with LEO sats, it's usefull to retune
the receiver using doppler correction info coming from external app.
In the past I used to query old beloved Predict via socket to control a
ICOM PR1000 receiver with a little utility that I wrote ( google "pcrsat" ).
It worked fine to demodulated 1200BPSK or CW telemetry also on heavy
doppler (ovehead pass).

Ciao,
Victor


2017-04-28 13:40 GMT+02:00 Mehmeto :

> Dear All,
>  I have a situation where I need to demodulate a wide bandwidth signal (70
> Mbps QPSK modulated, having 35 MHz IF bandwidth and sampled at 105 MSPS )
> in
> our lab. However, the signal generator will also add some amount of doppler
> shift at a rate of 1 kHz/s. Which PSK demodulation blocks are suitable for
> fast demodulation under some doppler shift. I
>  I know that I can not use the Costas Loop or any other block that uses a
> feedback loop because of their speed limitations.
>  I am considering to add a preamble to simplify things since I know high
> speed Satellite downlinks use Preamble. I guess the use of preambles make
> demodulation easier.
>
> Please advise.
>
>
>
> --
> View this message in context: http://gnuradio.4.n7.nabble.
> com/Which-block-for-Fast-PSK-demodulation-under-some-
> doppler-shift-tp63700.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] The PLL for the burst signal

[Vitt Benv]

H
​i Vicfield!
another info for you: are you palying with a "real" EPIRB signal or with a
"test" signal?

In the first case be sure that the signal cannot reach the open space:
the signal "trigs" an expensive and complicated stuff, actulally it's
starts a S&R process with a lot of people involved...
In the second case, if I recall right, the signal it's sent at full power
but "reversed". I dont recall if bit-order reversed or bit-complemented,
sorry!
In this manner it's possible to do tests ( and this is part of my job ;-)
) on EPIRB. For this I had a Futronic GMDSS testset.
Hope that this ca help you...

Ciao,

Victor

Il 24 apr 2017 18:07, "Vicfield Medici"  ha scritto:

> Hi,
>
> Really thank you all.
> I was read the specification of EPIRB and researched something about that,
> but it’s seems some error about that. I will attach the GRC what I tried.
>
>
> > So, a PSK that can only take values of +1.1 and -1.1, relative to the
> > "idle" carrier. Bit rate is 400b/s, so that makes it a 800 S/s PSK
> > symbol rate (Manchester-encoding happening in between).
>
> Marcus, thanks for your advice.
> I set the baud rate for 400 bits/sec.,
> but does it related about the PLL or Time Synchronization?
> I thought the Manchester decode is the part of line code
> and I should take that later?
>
>
> > About frequencies pay attention that there are more than a single
> (406.025
> > MHz)
> > frequency.
> > In my direct experience there's also 406.028 / 406.039 MHZ in use. So
> also
> > tuning
> > has to be on the right frequency.
>
> > Current NTIA spectrum documents are here:
> > https://www.ntia.doc.gov/page/federal-government-spectrum-us
> e-reports-225mhz-6ghz
>
> Thanks a lot, Vitt and Ron.
> In fact, I just testing the file was recoded with my PC,
> so I guess it’s not a trouble now, but still thanks.
>
>
> Here is the GRC I tested below, it refer the GRC from  here
> 
>  by
> Andy Walls.
>
> Again, Thanks and appreciated for any help.
>
> Thanks,
> Vicfield.
>
> 512K_test_.grc  >
>
> BTW, how can I upload the file like "Download Attachment"?
>
>
>
> --
> View this message in context: http://gnuradio.4.n7.nabble.co
> m/The-PLL-for-the-burst-signal-tp63604p63620.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] The PLL for the burst signal

[Vitt Benv]

Hello!
About frequencies pay attention that there are more than a single (406.025
MHz) frequency.
In my direct experience there's also 406.028 / 406.039 MHZ in use. So also
tuning has to be on the right frequency.

Take a look also at
https://www.ntia.doc.gov/files/ntia/publications/compendium/0406.00-0406.10_01MAR14.pdf
, but I suppose that also this document isn't up-to-date...

2017-04-23 17:07 GMT+02:00 Marcus Müller :

> Had to google that; for the others: http://www.epirb.com/
>
> Emergency Position Indicating Radio Beacon ; 406 MHz, bursty, wikipedia
> says:
>
> > The digital distress message generated by the beacon varies according
> to the above factors and is encoded in 30 hexadecimal characters. The
> unique 15-character digital identity (the 15-hex ID) is hard-coded in
> the firmware of the beacon. The 406.025 MHz carrier signal is modulated
> plus or minus 1.1 radians with the data encoded using Manchester
> encoding, which ensures a net zero phase shift aiding Doppler location
>
> So, a PSK that can only take values of +1.1 and -1.1, relative to the
> "idle" carrier. Bit rate is 400b/s, so that makes it a 800 S/s PSK
> symbol rate (manchester-encoding happening in between).
>
> Cheers,
> Marcus
>
> [1]
> http://www.cospas-sarsat.int/images/stories/SystemDocs/
> Current/cs_t.001_oct_2013.pdf
>
> On 04/23/2017 04:48 PM, Vicfield Medici wrote:
> > Hi,
> >
> > When trying to decode the signal, I always use the PLL Carrier Tracking
> to
> > solve the error
> > about phase shifting, and it’s always doing a good job.
> >
> > But I start trying to decode the EPIRB signal, I just got a sample with
> only
> > one burst,
> >  and PLL seems not work anymore even I tuned the parameter in many ways.
> >
> > Does the PLL Carrier Tracking can’t handle the discontinuous signal
> somehow?
> > Or it’s my misunderstanding?
> >
> > I really want to know how to take that, thanks for any help.
> >
> > Regards,
> >
> > Vicfield
> >
> >
> >
> >
> > --
> > View this message in context: http://gnuradio.4.n7.nabble.
> com/The-PLL-for-the-burst-signal-tp63604.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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] intermittent pulse detection

[Vitt Benv]

Hi Dirk,
in my experience SDR is a nice stuff but sometimes analog tech can help:
try to lower total NF using a tuned LNA in front of you receiver... RTL
dongles or other sampler are a bit deaf and noisy, and your signal seems
very feeble.

... my 2 eurocent... !

Victor

2017-02-10 0:01 GMT+01:00 Dirk Gorissen :

> Hi Marcus,
>
> Thanks again. And yes, Id be happy to do a writeup if I get things
> working with GnuRadio. I did a writeup of the first version I did of
> my project (*) and happy to do a part two of the improved version when
> finished (asap). Replies inline.
>
> >Well, if you have a let's say 2 kHz uncertainty in the frequency of your
> pulse, I'd really start very simple. Looking at your plots, I think we can
> sufficiently suppress the noise simply by low-pass filtering:
>
> Just note that the plots are posted are with the transmitter pretty
> much sitting next to the antenna so this is a *very* strong signal, in
> reality its much weaker.
>
> >* Use a Low Pass filter (real taps) with a cutoff of 1 kHz – that will
> let everything from -1 kHz to +1 kHz around your center frequency through.
> You can use the "freq xlating FIR" block to first shift by a given
> frequency and >then apply the filter; might make things easier.
> >* Detect power by putting your complex samples through a complex mag^2
> block.
>
> Thanks. I did this and the following observations
> - I went SDR -> Freq Xlating FIR filter with 4x decimation -> low pass
> filter block with 128x decimation and 1khz cutoff -> complex to mag2
>
> - The Freq Xlating block was giving me an error unless I filled in
> something for the Tap, some googleing led me to fill in
> firdes.low_pass_2 and I just used the same filter settings as the
> filter block. That made it happy but to be honest Im not sure why and
> if that was the right thing to do.
>
> - I did the decimation somewhat arbitrarily in two steps as I read
> somewhere that is better computationally, perhaps it should be more
> even though
>
> - With the above I could see the peaks (yay!) but it gets harder as
> the signal gets weaker. I plugged in the peak detector block (peak
> detector 2 seems broken btw) but found its usage very unintuitive and
> I didnt get it to mark the peaks in the way I wanted. Even though they
> were pretty big it wouldn't catch many of them, but perhaps its a
> plotting refresh rate thing. Its not clear to me over what window the
> average is taken (I was expecting that as an option).
>
> - Also, Im not 100% sure what sample rate I should be setting (or how
> to count number of samples (e.g., peak look ahead)) in blocks that are
> downstream from decimation. If the source sample rate is 1msps, and I
> have decimated by 4x, say, that means I have 4x less samples coming
> through per second so I should be setting 0.250msps as the sample rate
> in downstream blocks (filters, display, fft, ...) right?
>
> >If the output of that looks somewhat OK, then you could e.g. low-pass
> filter the result to get rid of noise pulses that are too short, for
> example :)
>
> Ok, so low-pass filter the real valued mag^2 values. I tried this but
> was not obvious how to choose the right cutoff frequency & transition
> width other than just trial and error. Also, as the signal gets weaker
> the peaks get narrower.
>
> I still feel like I should be cross correlating with the known signal,
> or some kind of matched filter setup, or exploiting the regularity of
> the pulse somehow to give me more sensitivity, but unsure how best to
> proceed there. I stumbled across a post about the correlate_and_sync
> block. That seemed somewhat similar to my problem (though I guess I
> have no preamble) but raised more questions than it solved.
>
> >By the way, it might be cool to put up a short recording (ie. a file
> generated using the GNU Radio file sink) somewhere (zipped, e.g. on Google
> Drive). I haven't worked with that myself, but maybe putting it on
> >SigIDwiki[1] might be beneficial for people encountering the wildlife
> tracker signal later on.
>
> Good idea. I quickly captured a file with raw IQ samples (File sink)
> in case anybody is interested. It starts with the transmitter very
> close to antenna, moves progressively further until out of range and
> then back. Its only about a minute or two tops but at 1msps it ended
> up as 813 MB though.
>
> https://drive.google.com/drive/folders/0B5dKo9igl8W4dWpiMmlEYWx3b0k?
> usp=sharing
>
> >We surely could use a few more "oh, GNU Radio is awesome because it works
> for everyone" articles (like [2]), but what we far more severely lack is
> stories of people that actually made progress, but also struggled,
> >because they didn't know GR for years before writing a blog post. One of
> the problems that we face (and that was a very prominent theme at the Panel
> at FOSDEM [3]) is that we don't really know how to help people
> >that are just approaching GNU Radio, and aren't already familiar with a
> lot of the stuff that we've gotten us

Re: [Discuss-gnuradio] plot_data options in gr-utils

[Vitt Benv]

Hi ,
take a look at my [ https://sourceforge.net/projects/automodrecog/ ] and
tale a look at pyplot docs... not Gnuradio but it work!

My app generate a plot as analysis's result and creates a PNG image
embedeed into an html form.

Bye,

I3VFJ, Vittorio

2016-06-01 15:15 GMT+02:00 Adellain TSIAHINA :

> Hello all,
>
> I'm using gnuradio and I would write my own python scripts to plot the
> data (the data are saved in a binary file which contains the stream - saved
> with file sink in grc).
> I spent a day trying to use the scripts in gr-utils such as plot_data but
> I don't know exactly how to use it (the options...), would you have an
> example ?
>
> Many thanks in advance !
>
> Adellain
>
>
>
> ___
> 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] QT graphical sink: how set dimension?

[Vitt Benv]

Yes Marcus, I'm doing some experiments with this old but nice SDR receiver
built by ja7tdo, just for fun or a little more!
It's connected via sound card (Audiophile @192Ksps) and it's tuned (AD9850
+ multiplier) via a FTDI USb chip used in bit-bang mode... quite
complicated but very cheap. Tuning range 100 Khz / 70 Mhz with some
octave/2 BPF in front of the mixer.

So, tnx for direction, maybe time it's come to dive deep into Gnuradio
stuff. I'll try next days to follow Tutorials and try to write my OOT block!

tnx a lot,

Victor

2016-03-31 15:24 GMT+02:00 Marcus Müller :

> Hi Victor,
>
> am I interpreting this correctly: You have a device that you want to
> control via a GUI slider?
>
> I think a relatively elegant way to have the control interface would be:
>
> 1. Making an OOT module; the Guided Tutorials[1], Chapter 3, explain how.
> 2. use gr_modtool add to add a python class of the "noblock" type
> 3. that class would mainly have a method, let's call it set_fx(value) that
> calls; edit the python file from step 2. to include that. Here's where your
> soft66-control program is being called
> 4. write a GRC XML descriptor; In essence, copy and paste over the XML
> file from one of the existing things, for example e the constant
> source. remove all sinks and sources, and only leave one  that has a
> , which calls your set_fx()!
> 5. install your module
>
> This way, you'd end up having an actual block you can use in GRC.
>
> I assume you're actually getting/sending samples to your soft66? How does
> that interface with GNU Radio?
>
> Maybe it would make sense to have a Sink/Source block (like, for example,
> the USRP sink and source blocks) that encapsulates both the sampling
> interface and the control interface?
>
> Best regards,
> Marcus
>
>
> [1] http://s.hostalia.de/gr
>
> On 31.03.2016 15:14, Vitt Benv wrote:
>
> ... wrong click, I apologize!
>
> ..​
>
> def set_base_fx(self, base_fx):
> self.base_fx = base_fx
> ​  ​
> cmd_string = str(int(self.base_fx))
> ​  #​
> print cmd_string
> ​  ​
> exit_code = subprocess.call(["soft66-control","-t",cmd_string])
>
>  Qt.QMetaObject.invokeMethod(self._base_fx_line_edit, "setText",
> Qt.Q_ARG("QString", eng_notation.num_to_str(self.base_fx)))
> self.qtgui_freq_sink_x_0.set_frequency_range(self.base_fx,
> self.samp_rate)
>
>
> ...
>
> this to set the center frequency of my old soft66 sdr receiver.
>
> So in future features with trust / hope...!
>
> tnx again,
> so long.
>
> Victor
>
> 2016-03-31 15:11 GMT+02:00 Vitt Benv :
>
>> Right Marcus I'd found it and it's what I was looking for, tnx!
>>
>> About "Python modules", yes, it's a nice features that I'll explore.
>>
>> At present I edit top_block.py to paste my code ( only 2 lines...) as:
>>
>> ​..​
>>
>> def set_base_fx(self, base_fx):
>> self.base_fx = base_fx
>> ​  ​
>> cmd_string = str(int(self.base_fx))
>> ​  #​
>> print cmd_string
>> ​  ​
>> exit_code = subprocess.call(["soft66-control","-t",cmd_string])
>>
>> Qt.QMetaObject.invokeMethod(self._base_fx_line_edit, "setText",
>> Qt.Q_ARG("QString", eng_notation.num_to_str(self.base_fx)))
>> self.qtgui_freq_sink_x_0.set_frequency_range(self.base_fx,
>> self.samp_rate)
>>
>> 2016-03-31 15:03 GMT+02:00 Marcus Müller < 
>> marcus.muel...@ettus.com>:
>>
>>> Hi Victor,
>>>
>>> On 31.03.2016 14 <31.03.2016%2014>:57, Marcus Müller wrote:
>>> > I know there's the Qt Tab widget (look under "GUI widgets"), but I
>>> > haven't played around with that.
>>> I sent that and realized that typing that took me as long as it would
>>> have taken me to play around :)
>>>
>>> So, yeah, it's pretty simple: You add a QT GUI Tab widget, give it an ID
>>> (instead of the default qtgui_tab_widget_0) that you can easily
>>> remember, eg "tabber", and then in your graphical blocks, use
>>> tabber@0, tabber@1 and so on for different tabs.
>>>
>>> If you want to have the widgets grid-layouted inside the tabs, just
>>> combine the two syntaxes; for example:
>>> tabber@0:0,1,1,1
>>>
>>> Cheers,
>>> Marcus
>>> >
>>> > Regarding protected python code:
>>> > Well, the problem is that the python code Generator class re-generates
>>&

Re: [Discuss-gnuradio] QT graphical sink: how set dimension?

[Vitt Benv]

... wrong click, I apologize!

..​

def set_base_fx(self, base_fx):
self.base_fx = base_fx
​  ​
cmd_string = str(int(self.base_fx))
​  #​
print cmd_string
​  ​
exit_code = subprocess.call(["soft66-control","-t",cmd_string])

 Qt.QMetaObject.invokeMethod(self._base_fx_line_edit, "setText",
Qt.Q_ARG("QString", eng_notation.num_to_str(self.base_fx)))
self.qtgui_freq_sink_x_0.set_frequency_range(self.base_fx,
self.samp_rate)


...

this to set the center frequency of my old soft66 sdr receiver.

So in future features with trust / hope...!

tnx again,
so long.

Victor

2016-03-31 15:11 GMT+02:00 Vitt Benv :

> Right Marcus I'd found it and it's what I was looking for, tnx!
>
> About "Python modules", yes, it's a nice features that I'll explore.
>
> At present I edit top_block.py to paste my code ( only 2 lines...) as:
>
> ​..​
>
> def set_base_fx(self, base_fx):
> self.base_fx = base_fx
> ​  ​
> cmd_string = str(int(self.base_fx))
> ​  #​
> print cmd_string
> ​  ​
> exit_code = subprocess.call(["soft66-control","-t",cmd_string])
>
> Qt.QMetaObject.invokeMethod(self._base_fx_line_edit, "setText",
> Qt.Q_ARG("QString", eng_notation.num_to_str(self.base_fx)))
> self.qtgui_freq_sink_x_0.set_frequency_range(self.base_fx,
> self.samp_rate)
>
> 2016-03-31 15:03 GMT+02:00 Marcus Müller :
>
>> Hi Victor,
>>
>> On 31.03.2016 14:57, Marcus Müller wrote:
>> > I know there's the Qt Tab widget (look under "GUI widgets"), but I
>> > haven't played around with that.
>> I sent that and realized that typing that took me as long as it would
>> have taken me to play around :)
>>
>> So, yeah, it's pretty simple: You add a QT GUI Tab widget, give it an ID
>> (instead of the default qtgui_tab_widget_0) that you can easily
>> remember, eg "tabber", and then in your graphical blocks, use
>> tabber@0, tabber@1 and so on for different tabs.
>>
>> If you want to have the widgets grid-layouted inside the tabs, just
>> combine the two syntaxes; for example:
>> tabber@0:0,1,1,1
>>
>> Cheers,
>> Marcus
>> >
>> > Regarding protected python code:
>> > Well, the problem is that the python code Generator class re-generates
>> > the python code from scratch each time and doesn't even try to read
>> > what's there already. That really makes debugging the code generation
>> > easier; there's no chance some modification might damage the "stub"
>> code.
>> > However, it means that modifications don't survive, indeed.
>> >
>> > In many circumstances, there might be an elegant workaround: If you've
>> > got a relatively recent GNU Radio, your GRC will contain "Python
>> > Module", which you can use to have python code that gets automatically
>> > written to a different .py file when the Python code is generated; that
>> > way, you can have your own functions that you can call e.g. in your
>> > block properties.
>> >
>> > But I think your idea is pretty interesting, anyway. Maybe there's
>> > already thoughts on that or similar concepts; I just don't know :)
>> >
>> > Best regards,
>> > Marcus
>> >
>> > On 31.03.2016 14:18, Vitt Benv wrote:
>> >> Tnx Marcus, you are right, I'm speaking about "graphical" properties.
>> >> I was aware about "GUI Hint" and I tried this but only to put widgets
>> >> in rows x columns positions but now I know about the subsequent
>> >> parameter: I'll test those.
>> >>
>> >>  Now I miss only Tabs as Notebook was used, but never mind, I'll try
>> >> another way!
>> >>
>> >> About GRC I think it's a good "starting point" but then some extra
>> >> code does the job.
>> >>
>> >> A useful feature in GRC could be to have some kind of protection on
>> >> added code between builds... if I recall right there was an IDE
>> >> (WxGlade... maybe...) who understood a simple tag as:
>> >>
>> >> 
>> >> ### PROTECTED CODE ###
>> >>
>> >> ... added code
>> >>
>> >> ###
>> >> 
>> >>
>> >> so that in subsequent build that wasn't overwritten ( actually it
>> >> happened several times, sgrunt!).
>> >&

Re: [Discuss-gnuradio] QT graphical sink: how set dimension?

[Vitt Benv]

Right Marcus I'd found it and it's what I was looking for, tnx!

About "Python modules", yes, it's a nice features that I'll explore.

At present I edit top_block.py to paste my code ( only 2 lines...) as:

​..​

def set_base_fx(self, base_fx):
self.base_fx = base_fx
​  ​
cmd_string = str(int(self.base_fx))
​  #​
print cmd_string
​  ​
exit_code = subprocess.call(["soft66-control","-t",cmd_string])

Qt.QMetaObject.invokeMethod(self._base_fx_line_edit, "setText",
Qt.Q_ARG("QString", eng_notation.num_to_str(self.base_fx)))
self.qtgui_freq_sink_x_0.set_frequency_range(self.base_fx,
self.samp_rate)

2016-03-31 15:03 GMT+02:00 Marcus Müller :

> Hi Victor,
>
> On 31.03.2016 14:57, Marcus Müller wrote:
> > I know there's the Qt Tab widget (look under "GUI widgets"), but I
> > haven't played around with that.
> I sent that and realized that typing that took me as long as it would
> have taken me to play around :)
>
> So, yeah, it's pretty simple: You add a QT GUI Tab widget, give it an ID
> (instead of the default qtgui_tab_widget_0) that you can easily
> remember, eg "tabber", and then in your graphical blocks, use
> tabber@0, tabber@1 and so on for different tabs.
>
> If you want to have the widgets grid-layouted inside the tabs, just
> combine the two syntaxes; for example:
> tabber@0:0,1,1,1
>
> Cheers,
> Marcus
> >
> > Regarding protected python code:
> > Well, the problem is that the python code Generator class re-generates
> > the python code from scratch each time and doesn't even try to read
> > what's there already. That really makes debugging the code generation
> > easier; there's no chance some modification might damage the "stub" code.
> > However, it means that modifications don't survive, indeed.
> >
> > In many circumstances, there might be an elegant workaround: If you've
> > got a relatively recent GNU Radio, your GRC will contain "Python
> > Module", which you can use to have python code that gets automatically
> > written to a different .py file when the Python code is generated; that
> > way, you can have your own functions that you can call e.g. in your
> > block properties.
> >
> > But I think your idea is pretty interesting, anyway. Maybe there's
> > already thoughts on that or similar concepts; I just don't know :)
> >
> > Best regards,
> > Marcus
> >
> > On 31.03.2016 14:18, Vitt Benv wrote:
> >> Tnx Marcus, you are right, I'm speaking about "graphical" properties.
> >> I was aware about "GUI Hint" and I tried this but only to put widgets
> >> in rows x columns positions but now I know about the subsequent
> >> parameter: I'll test those.
> >>
> >>  Now I miss only Tabs as Notebook was used, but never mind, I'll try
> >> another way!
> >>
> >> About GRC I think it's a good "starting point" but then some extra
> >> code does the job.
> >>
> >> A useful feature in GRC could be to have some kind of protection on
> >> added code between builds... if I recall right there was an IDE
> >> (WxGlade... maybe...) who understood a simple tag as:
> >>
> >> 
> >> ### PROTECTED CODE ###
> >>
> >> ... added code
> >>
> >> ###
> >> 
> >>
> >> so that in subsequent build that wasn't overwritten ( actually it
> >> happened several times, sgrunt!).
> >>
> >> Tnx again, ciao ^__^
> >>
> >> Victor
> >>
> >> 2016-03-31 13:40 GMT+02:00 Marcus Müller :
> >>> Hi Victor,
> >>>
> >>> what specifically are you referring to when you say "dimension" of your
> >>> graphical sinks; do you mean the "logical" size (in points of the FFT)
> >>> or the "graphical" size (in pixels of the widget, or the window)?
> >>>
> >>> You can specify the heights of the widgets manually, but that would
> >>> require you to interfere with Qt taking care of window layout (and is
> >>> not a good idea most of the time); if possible, prefer to use a
> relative
> >>> grid layout as explained below.
> >>>
> >>> The equivalent to WX' Notebook, there's the QT "GUI Hint" property.
> It's
> >>> pretty awesome, if you want to have a grid kind of layout; its format
> is
> >>>
> >>> 

Re: [Discuss-gnuradio] QT graphical sink: how set dimension?

[Vitt Benv]

Tnx Marcus, you are right, I'm speaking about "graphical" properties.
I was aware about "GUI Hint" and I tried this but only to put widgets
in rows x columns positions but now I know about the subsequent
parameter: I'll test those.

 Now I miss only Tabs as Notebook was used, but never mind, I'll try
another way!

About GRC I think it's a good "starting point" but then some extra
code does the job.

A useful feature in GRC could be to have some kind of protection on
added code between builds... if I recall right there was an IDE
(WxGlade... maybe...) who understood a simple tag as:


### PROTECTED CODE ###

... added code

###


so that in subsequent build that wasn't overwritten ( actually it
happened several times, sgrunt!).

Tnx again, ciao ^__^

Victor

2016-03-31 13:40 GMT+02:00 Marcus Müller :
> Hi Victor,
>
> what specifically are you referring to when you say "dimension" of your
> graphical sinks; do you mean the "logical" size (in points of the FFT)
> or the "graphical" size (in pixels of the widget, or the window)?
>
> You can specify the heights of the widgets manually, but that would
> require you to interfere with Qt taking care of window layout (and is
> not a good idea most of the time); if possible, prefer to use a relative
> grid layout as explained below.
>
> The equivalent to WX' Notebook, there's the QT "GUI Hint" property. It's
> pretty awesome, if you want to have a grid kind of layout; its format is
>
> row,column, row_span, column_span
>
> So, if you want something like
>
> +---+---+
> | Time  | Freq  |
> | Plot  | Plot  |
> +---+---+
> |Slider |
> +---+
>
> The GUI hints would be
>
> time plot: 0,0, 1,1  (first (=0.) row, first column, one row high x one
> column wide)
> freq plot: 0,1, 1,1 (first row, second column, 1x1 )
> slider: 1,0,1,2 (second row, first column, 1 high x 2 wide)
>
> Generally, it's possible (though not directly from GRC without writing
> your own Python) to embed your Visualization into your own Qt
> Application; there's a few projects out there that do that, but I don't
> think we really have a best practice guide for that just yet :)
>
> Cheers,
> Marcus
> On 31.03.2016 12:45, Vitt Benv wrote:
>> Good morning,
>> I'm exploring QT graphical, to begin lo leave WX widget
>> I'm looking for good infos about resizing / fix the dimensions of my
>> two graphical sinks ( frequency / spectrogram), Googled around but no
>> clear infos :-(
>> Moreover in WX there's a Notebook container, very useful with crowded
>> GUI there's an equivalent in QT?
>> Tnx in advance for any answer.
>>
>> Victor, I3VFJ
>>
>> ___
>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] QT graphical sink: how set dimension?

[Vitt Benv]

...resent, my mistake!


Good morning,
I'm exploring QT graphical, to begin lo leave WX widget
I'm looking for good infos about resizing / fix the dimensions of my
two graphical sinks ( frequency / spectrogram), Googled around but no
clear infos :-(
Moreover in WX there's a Notebook container, very useful with crowded
GUI there's an equivalent in QT?
Tnx in advance for any answer.

Victor, I3VFJ

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

[Discuss-gnuradio] QT graphical sink: how set dimension?

[Vitt Benv]

Good morning,
I'm exploring QT graphical, to begin lo leave WX widget
I'm looking for good infos about resizing / fix the dimensions of my
two graphical sinks ( frequency / spectrogram), Googled around but no
clear infos :-(
Moreover in WX there's a Notebook container, very useful with crowded
GUI there's an equivalent in QT?
Tnx in advance for any answer.

Victor, I3VFJ

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

Re: [Discuss-gnuradio] Handling of IQ files

[Vitt Benv]

Happy to read you replay Henry!
Feel free to rip/change/upgrade my work, but let me know about ur progress, pse!
Remember that it's fairly resource hungry ( file larger that 250 Mb
crashes the app also on my I7/16Gb), but it's a starting point.
I think that with GNURADIO it's possible to refine this task... I've a
lot to study!

Victor I3VFJ

2016-03-21 20:45 GMT+01:00 Henry Barton :
> I like the concept of your program. It looks just like what I’m trying to
> write.
>
> Sent from Windows Mail
>
> From: Vitt Benv
> Sent: ‎Sunday‎, ‎March‎ ‎20‎, ‎2016 ‎4‎:‎16‎ ‎PM
> To: discuss-gnuradio@gnu.org
>
> Hi,
> this [ https://sourceforge.net/projects/automodrecog/ ] is my little
> effort about handling IQ files.
> The input IQ file is recorded with HDSDR, very nice piece of sw, that
> as a good recording scheduler. By the way the file provided can be
> played with it. I do also some tests with IQ file produced by R&S
> EM100 receiver.
> I wrote this [horrible] application for personal use and it's very raw
> IMO
> I'm interested on HF monitoring and the main goal is to find SSB
> emission along time, not quite simple task.
>
> In brief:
> - read params from input file
> - split it in smaller chunk and save FFT for each chunk
> - sum (maxhold) or avg (average) all the FFTs
> - find relevant ( over threshold) carrier and try to "pack" them to
> find "bandwidth" associated
> - build a report as .html page with a .png file that represent the result.
>
> The most difficult part is to estimate the best "threshold", and at
> the moment I'm almost stuck there and moreover RL reclaims my
> presence :-)
>
> ... my euro "cent" on the subject.
>
> Victor I3VFJ
>
> ___
> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Handling of IQ files

[Vitt Benv]

Hi,
this [ https://sourceforge.net/projects/automodrecog/ ] is my little
effort about handling IQ files.
The input IQ file is recorded with HDSDR, very nice piece of sw, that
as a good recording scheduler. By the way the file provided can be
played with it. I do also some tests with IQ file produced by R&S
EM100 receiver.
I wrote this [horrible] application for personal use and it's very raw IMO
I'm interested on HF monitoring and the main goal is to find SSB
emission along time, not quite simple task.

In brief:
- read params from input file
- split it in smaller chunk and save FFT for each chunk
- sum (maxhold) or avg (average) all the FFTs
- find relevant ( over threshold) carrier and try to "pack" them to
find "bandwidth" associated
- build a report as .html page with a .png file that represent the result.

The most difficult part is to estimate the best "threshold", and at
the moment I'm almost stuck there and moreover RL reclaims my
presence :-)

... my euro "cent" on the subject.

Victor I3VFJ

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

Re: [Discuss-gnuradio] Distance Measurement

[Vitt Benv]

Remember: signals moves at rough 3.3 microseconds per km...
Il 13/lug/2015 10:37 "Sylvain Munaut" <246...@gmail.com> ha scritto:
>
> Hi,
>
>
> > So, I want to measure the time delay on the Scope Sink, or in Matlab the
> > samples delay that are between the trasmitted signal and the received
> > signal. If I could have this information I could know the distance by
the
> > formula v=d/t, where v is the speed of the light, d= distance and t=
time
> > delay of the two signals.
>
>
> Did you actually _do_ the math you're talking about ?
>
> You're sampling at 400 kHz. So for the delay to change by 1 _single_
> sample, you'd need to move the antenna 750 meters appart !
>
>
> Cheers,
>
>   Sylvain
>
> ___
> 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 send random values to selector every n-times

[Vitt Benv]

Thanks Sreeraj,

just a quick test without success :-(

I've tested the example in the tutorial and it work, so I've to read
carefully the section to understand how put hand on my code.

Next days I'll be away for my job so next tests maybe done during next
weekend.

I'll report results ;-)

Byebye,

Victor

2014-12-08 15:11 GMT+01:00 sreeraj r :

> Hi,
>
> Please go through the tutorial [1].
>
> Short version,
>
> 1. Use one 5in-1out selector block
> 2. Use on "Function Probe" block
> 3. Set the "Poll Rate" based on your delay
> 4. Generate python file using "Generate flowgraph" button
> 5. Set your selector's input index in the function probe
>
> Sample function probe
>
> >>def _fn_probe_probe():
> >>while True:
> >>try:
> >>
>  self.blks2_selector_0.set_input_index(random.randint(0,4))
> >>except AttributeError:
> >>pass
> >>time.sleep(1.0 / (0.3))
>
> 6.Run your python code
>
>
> [1]
> https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_Python#315-Modifying-the-GRC-Generated-Python-File
>
> Sreeraj
>
> On Sun, Dec 7, 2014 at 10:59 PM, Vitt Benv  wrote:
>
>> Hi everybody,
>> I need to "switch" randomly 5 different signal generator via selector
>> block every [say] 3 seconds
>>
>> So , in GRC, I've a vector_source with values coming from
>> [random.randint(0, 4) for p in range(0,4)]. This put some random values
>> displayed right.
>>
>> Now how I can scan the vector, a values at time sending this index to
>> selector, every n-seconds ???
>>
>> I'm not with a USRP , simple sound card.
>>
>> Tnx in advance for any answer!
>>
>> Victor
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> Regards
> Sreeraj Rajendran
> http://radioninja.in/
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] how send random values to selector every n-times

[Vitt Benv]

Hi everybody,
I need to "switch" randomly 5 different signal generator via selector block
every [say] 3 seconds

So , in GRC, I've a vector_source with values coming from
[random.randint(0, 4) for p in range(0,4)]. This put some random values
displayed right.

Now how I can scan the vector, a values at time sending this index to
selector, every n-seconds ???

I'm not with a USRP , simple sound card.

Tnx in advance for any answer!

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