Re: [Discuss-gnuradio] linking Gnuradio and Gpredict ?

[Darren Long]

Hi Mike

Alex (the gqrx and Gpredict author) suggested using pyephem to me once when I
asked about this.  I did have a little play with it, but haven't done anything
interesting or useful.

http://rhodesmill.org/pyephem/

Darren, G0HWW

On 24/11/14 10:15, Mike Willis wrote:
> I know this is going back a bit but I would like to do the same thing for my
> Gnuradio satellite ground station. I was actually tempted to compile satellite
> tracking into a Gnuradio block. One you could simply use in a flowchart 
> without
> any of the messing about with XMLRPC but like my new hexagonal wheel project,
> with active compensatory suspension, it might be better to use what’s already 
> there.
> 
>  
> 
> Did anyone do this? And, how difficult would it be in practice to develop a
> native block that either contains predict, or accesses it? Possibly not very
> difficult at all and maybe already done?
> 
>  
> 
> Mike
> 
>  
> 
>  
> 
> 
> 
> On 22/07/13 12:31, M Dammer wrote:
> 
>  
> 
> Is it possible to link Gnuradio and Gpredict ? I want to use Gpredict as
> 
> tracker controlling the antenna position and to pass doppler corrected
> 
> frequency data to Gnuradio.
> 
>  
> 
> In a word, yes.
> 
>  
> 
> Can be very simple. I did it by using an XML Server in the flow graph,
> 
> and wrote a quick XML client (actually I "stole" most of it from an
> 
> example), and sent the doppler info from predict via a variable.
> 
>  
> 
> doppler info was received from predict using some code to query predict
> 
> using UDP. I think I just used nc to send the UDP query to predict,
> 
> recovered the shift from the reply, and sent it back to the XML Server
> 
> running within the flow graph.
> 
>  
> 
> Unfortunately I can't find my actual code right now, but I literally
> 
> copied an example, and added the UDP Predict clients bit. It went
> 
> something like this pseudo code (Yes, this is a mix of shell,and
> 
> python, and you need to re-write the getting doppler from predict yourself, 
> but
> you get the idea, and should give you enough)
> 
>  
> 
> import time
> 
> import sys
> 
> from socket import *
> 
> import xmlrpclib
> 
> import binascii
> 
>  
> 
> s = xmlrpclib.Server("http://192.168.39.74:8081"; 
> ;)
> 
> infinite=1
> 
> while infinite == 1;
> 
>   # Grab predict doppler using UDP
> 
>   DOPPLER=`nc -u -s 2 $PREDICTHOST GET_DOPPLER $NORAD_NUMBER`
> 
>   s.set_doppler_shift($DOPPLER)
> 
>   time.sleep(1)
> 
>  
> 
> The variable (lets call it doppler_shift) exists in the flowgraph,
> 
> and was multiplied appropriately and applied to the centre frequency of
> 
> a FIR filter.
> 
>  
> 
> You can pretty much pass any information you want in and out of a flow
> 
> graph using a XML Server/Client pair. I've done TX/RX switching, and
> 
> am currently working on telemetry decoding/display
> 
>  
> 
>  
> 
> Iain
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> 
> ___
> 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] GRC - python code generation quirk for Function Probe with empty BlockID

[Darren Long]

Hi,

I've been pottering around in GRC trying to get a pair of function
probe's to update the QT fosphor GUI sink's centre frequency by calling

self.set_freq(float(subprocess.check_output(['/usr/bin/rigctl', '-m',
'2', 'f']).strip()))

at 5Hz and

self.set_samp_rate(self.samp_rate)

at 20Hz.

This seems to work, except for the fact that the GRC python generator
generates the following lines of code instead of that I've shown above:

val = self..set_freq(float(subprocess.check_output(['/usr/bin/rigctl',
'-m', '2', 'f']).strip()))

and

val = self..set_samp_rate(self.samp_rate)

Note the pair of dots in those lines.  This occurs because the Block ID
in the function probe is empty, in that I want the block ID to refer to
the top block, i.e. self.  I can't put "self" as the Block ID, as the
generated code is "self.self" which Python moans about.  leaving the
BlockID empty creates the pair of dots.

I wonder if GRC could/should be modified to suppress the extra generated
dot if the Block ID is empty?  It would certainly help me to avoid
editing generated code :)

Cheers,

Darren, G0HWW

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

Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration

[Darren Long]

On 27/10/13 21:02, Alexandru Csete wrote:

On Sun, Oct 27, 2013 at 8:45 PM, Darren Long  wrote:


I'd like to be able to use this with my KX-3 perhaps as slowly as 48kHz :)
Daren,

Do what exactly?
The purpose with gr-fosphor is to visualize more data that what is
possible with snapshot-type FFT. This ensures that no data is lost
between to screen updates. But for such low bandwidth you can just
plot everything without loosing any information. You could do some
history buffering and averaging to get the look and feel of gr-fosphor
but it will not give you the same real time effect. It will be the
plain old "FFT averaging" concept that we know  and you don't even
need a GPU to do that.

Alex


Well, the fosphor waterfall itself isn't of much use at high rates as 
the signals just whizz of the screen before you get a chance to look at 
them.  The magic, as you point out, is in the fosphor FFT plot, which is 
awesome!  All I would like is for the waterfall to not be jerky at 
moderate sample rates. I find that a waterfall presents a better target 
than an FFT plot for a click-to-tune function, but a jerky one is not good.


Cheers,

Darren

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

Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration

[Darren Long]

On 27/10/13 17:46, Sylvain Munaut wrote:
Since the whole idea being fosphor is to never just "drop" data, to 
slow down the waterfall, multiple FFT results must be "aggregated" 
with either min/max/avg functions and that's a bit more tricky to 
implement. Cheers, Sylvain 


Actually, with the chunk size hack, the waterfall is just about OK at 
192kHz sample rate, but it is still a little jerky.  Could we have a 
buffering option to buffer the waterfall for some time before scrolling?


I'd like to be able to use this with my KX-3 perhaps as slowly as 48kHz :)

Cheers,

Darren


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

Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration

[Darren Long]

Yep, I concur.  It is blazingly fast at rendering with the HackRF :)

Can we control any options on the sink?  For example frequency scale, 
waterfall rate, etc.  A callback would be nice too.  I'd like to use the 
fosphor sink in my gr-kx3 script that I use to control my HF  transceiver.


This is very cool.  Thanks.

Darren

On 27/10/13 17:12, Sylvain Munaut wrote:

Hi,


However, it seems to be quite laggy, with 'chunks' of 'water' 'falling' at
about 1 second intervals and not flowing smoothly.

Yes, the FCD will not quite provide enough data for it ... It's more
aimed at very wideband SDR :p

It currently processes data in chunks of 128 * 1024 which for the FCD
is pretty big.

In lib/base_sink_c_impl.cc , look for "128*1024", there should be 4
matches, and replace them all by 16*1024 (you can't process less than
that).
It should improve the frame rate for very low sample rate.

Cheers,

 Sylvain



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

Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration

[Darren Long]

Good call.  I applied the 4 patches and now I can run osmocom_fft with 
the -F option succesfully.


$ osmocom_fft -F  -a "fcd=1"
linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.005.004-0-unknown

gr-osmosdr v0.1.x-xxx-xunknown (0.1.1git) gnuradio 3.7.1
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf 
netsdr

Using FUNcube Dongle V2.0 (hw:3)
Opened: hw:3
Using Volk machine: sse4_2_64_orc
Dongle sucessfully initialized
Result of Action :+
FCDAPP 20.03
 Lna gain enabled
 Mixer gain enabled
If gain set to: 15
If gain set to: 15
[+] Selected device: GeForce GTX 760
---

However, it seems to be quite laggy, with 'chunks' of 'water' 'falling' 
at about 1 second intervals and not flowing smoothly.


Looks nice though :)

Cheers,

Darren


On 27/10/13 15:23, Sylvain Munaut wrote:

Hi,


Set Frequency to: 7.1e+06 Hz, corrected to: 710 Hz
[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not
been called
[xcb] Aborting, sorry about that.
python2: ../../src/xcb_io.c:179: dequeue_pending_request: Assertion
`!xcb_xlib_unknown_req_in_deq' failed.
Aborted (core dumped)

Your GNURadio is too old.

At the very least you need those patches: http://gnuradio.org/redmine/issues/596
And preferrably those as well : http://gnuradio.org/redmine/issues/601

Note that they're only changin python files and text template files so
you can "monkey patch" manually your installation, no need to
recompile everything.

Cheers,

Sylvain



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

Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration

[Darren Long]

Good thinking.  Next hurdle is an error:


darren@betty:~$ osmocom_fft  -F -a fcd=1 -f 7.1M
linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.005.004-0-unknown

gr-osmosdr v0.1.x-xxx-xunknown (0.1.1git) gnuradio 3.7.1
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf 
netsdr

Using FUNcube Dongle V2.0 (hw:3)
Opened: hw:3
Using Volk machine: sse4_2_64_orc
Dongle sucessfully initialized
Result of Action :+
FCDAPP 20.03
 Lna gain enabled
 Mixer gain enabled
If gain set to: 15
If gain set to: 15
Set Frequency to: 7.1e+06 Hz, corrected to: 710 Hz
[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has 
not been called

[xcb] Aborting, sorry about that.
python2: ../../src/xcb_io.c:179: dequeue_pending_request: Assertion 
`!xcb_xlib_unknown_req_in_deq' failed.

Aborted (core dumped)


Cheers,

Darren

On 27/10/13 15:07, Sylvain Munaut wrote:

Hi Darren,



I can't get osmocom_fft to run, due to a problem inporting fosphor. It runs
OK without the -F argument.   Not sure what is wrong yet. Everything seemed
to build and install OK. Please see the output below.  Also, should there be
any new blocks in grc?

You need to install in the same prefix as gnuradio itself is installed
for it to work.

So if the PPA install GR in /usr you'll need to use
-DCMAKE_INSTALL_PREFIX=/usr  on the cmake line


Cheers,

 Sylvain



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

Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration

[Darren Long]

Hi Sylvain,


I can't get osmocom_fft to run, due to a problem inporting fosphor. It 
runs OK without the -F argument.   Not sure what is wrong yet. 
Everything seemed to build and install OK. Please see the output below. 
 Also, should there be any new blocks in grc?


Cheers,

Darren


darren@betty:~$ osmocom_fft -F -a fcd=1 -f 7.1M
linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.005.004-0-unknown

gr-osmosdr v0.1.x-xxx-xunknown (0.1.1git) gnuradio 3.7.1
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf 
netsdr

Using FUNcube Dongle V2.0 (hw:3)
Opened: hw:3
Using Volk machine: sse4_2_64_orc
Dongle sucessfully initialized
Result of Action :+
FCDAPP 20.03
 Lna gain enabled
 Mixer gain enabled
If gain set to: 15
If gain set to: 15
Traceback (most recent call last):
  File "/usr/bin/osmocom_fft", line 512, in 
main ()
  File "/usr/bin/osmocom_fft", line 508, in main
app = stdgui2.stdapp(app_top_block, "osmocom Spectrum Browser", 
nstatus=1)
  File "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", 
line 38, in __init__

wx.App.__init__ (self, redirect=False)
  File 
"/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 
7981, in __init__

self._BootstrapApp()
  File 
"/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 
7555, in _BootstrapApp

return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", 
line 42, in OnInit

self._max_noutput_items)
  File "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", 
line 64, in __init__

self.panel = stdpanel (self, self, top_block_maker, max_nouts)
  File "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", 
line 86, in __init__

self.top_block = top_block_maker (frame, self, vbox, sys.argv)
  File "/usr/bin/osmocom_fft", line 178, in __init__
from gnuradio import fosphor
ImportError: cannot import name fosphor

On 27/10/13 13:17, Sylvain Munaut wrote:

Hi Darren,


I've managed to get the demo program running, but
I've not been able to do anything else yet.

Mmm, really ? What issue did you have ? Did it build at all ?



100 Frames time: 227558 us
BW estimated: 230.397520 Msps

That's the best figure I saw.  I think that puts me at the top of the chart
:)

Yes :)

At this point the time is mostly dominated by the data copy from
memory to device and faster GPU don't help much.

Cheers,

 Sylvain



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

Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration

[Darren Long]

Hi Alex,

The benchmark utility source is in gr-fosphor/lib/fosphor

I had to run make manually, but in order to get it to build I had to 
bodge it.  The changes I made are in the diff below.


===
diff --git a/lib/fosphor/Makefile b/lib/fosphor/Makefile
index a1ea187..3500d64 100644
--- a/lib/fosphor/Makefile
+++ b/lib/fosphor/Makefile
@@ -1,6 +1,7 @@
 UNAME=$(shell uname)
 CC=gcc
-CFLAGS=-Wall -Werror -O2 `pkg-config freetype2 glfw3 --cflags` -g
+#CFLAGS=-Wall -Werror -O2 `pkg-config freetype2 glfw3 --cflags` -g
+CFLAGS=-Wall  -O2 `pkg-config freetype2 glfw3 --cflags` -g
 LDLIBS=`pkg-config freetype2 glfw3 --libs` -lm
 ifneq ($(AMDAPPSDKROOT), )
 CFLAGS+=-I$(AMDAPPSDKROOT)/include
diff --git a/lib/fosphor/cl_platform.h b/lib/fosphor/cl_platform.h
index cf3376d..cd2dc29 100644
--- a/lib/fosphor/cl_platform.h
+++ b/lib/fosphor/cl_platform.h
@@ -39,7 +39,7 @@
 #endif

 #ifdef CL_VERSION_1_2
-# define clCreateFromGLTexture2D clCreateFromGLTexture
+// DML Hack # define clCreateFromGLTexture2D clCreateFromGLTexture
 #endif

 #ifndef CL_DEVICE_COMPUTE_CAPABILITY_MAJOR_NV

=

I then ran make in gr-fosphor/lib/fosphor.  Then I recorded some stuff 
with grc and then invoked the benchamrk utility:


darren@betty:~/src/gr-fosphor/lib/fosphor$ ./main 
~/grdata2013.10.27.12.10.20.dat



Hope that helps.

Darren



On 27/10/13 14:35, Alexandru Csete wrote:

How do you run the benchmark or test? I have now rebuilt with glfw
support but I can't find any programs.


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

Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration

[Darren Long]

Very nice.  I've only just changed to using the gqrx repository instead 
of building everything from source, but I couldn't resist having a go at 
getting this working.  I've managed to get the demo program running, but 
I've not been able to do anything else yet. Hopefully Alex will be able 
to add this to his repo.


I have some scores for you from some pretty modern hardware:

CPU: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
GeForce GTX 760

100 Frames time: 227558 us
BW estimated: 230.397520 Msps

That's the best figure I saw.  I think that puts me at the top of the 
chart :)

There's more output below.

Cheers,

Darren


BW estimated: 227.594064 Msps
100 Frames time: 232501 us
BW estimated: 225.499248 Msps
100 Frames time: 232839 us
BW estimated: 225.171904 Msps
100 Frames time: 229223 us
BW estimated: 228.724000 Msps
100 Frames time: 229405 us
BW estimated: 228.542528 Msps
100 Frames time: 229270 us
BW estimated: 228.677104 Msps
100 Frames time: 23 us
BW estimated: 227.951312 Msps
100 Frames time: 228716 us
BW estimated: 229.231024 Msps
100 Frames time: 231187 us
BW estimated: 226.780912 Msps
100 Frames time: 230105 us
BW estimated: 227.847280 Msps
100 Frames time: 229035 us
BW estimated: 228.911728 Msps
100 Frames time: 229381 us
BW estimated: 228.566448 Msps
100 Frames time: 234282 us
BW estimated: 223.785008 Msps
100 Frames time: 234854 us
BW estimated: 223.239968 Msps
100 Frames time: 242539 us
BW estimated: 216.166480 Msps
100 Frames time: 270473 us
BW estimated: 193.841168 Msps
100 Frames time: 231250 us
BW estimated: 226.719136 Msps
100 Frames time: 228782 us
BW estimated: 229.164880 Msps
100 Frames time: 229060 us
BW estimated: 228.886752 Msps
100 Frames time: 237378 us
BW estimated: 220.866288 Msps
100 Frames time: 274509 us
BW estimated: 190.991184 Msps
100 Frames time: 237262 us
BW estimated: 220.974272 Msps
100 Frames time: 229115 us
BW estimated: 228.831824 Msps
100 Frames time: 230812 us
BW estimated: 227.149360 Msps
100 Frames time: 229306 us
BW estimated: 228.641200 Msps
100 Frames time: 229414 us
BW estimated: 228.533584 Msps
100 Frames time: 229513 us
BW estimated: 228.435008 Msps
100 Frames time: 233862 us
BW estimated: 224.186896 Msps
100 Frames time: 232496 us
BW estimated: 225.504096 Msps
100 Frames time: 229579 us
BW estimated: 228.369312 Msps
100 Frames time: 228273 us
BW estimated: 229.675872 Msps
100 Frames time: 229214 us
BW estimated: 228.732992 Msps
100 Frames time: 230658 us
BW estimated: 227.301024 Msps
100 Frames time: 230274 us
BW estimated: 227.680064 Msps
100 Frames time: 242634 us
BW estimated: 216.081824 Msps
100 Frames time: 268012 us
BW estimated: 195.621088 Msps
100 Frames time: 231125 us
BW estimated: 226.841760 Msps
100 Frames time: 228356 us
BW estimated: 229.592384 Msps
100 Frames time: 228372 us
BW estimated: 229.576304 Msps
100 Frames time: 229648 us
BW estimated: 228.300704 Msps
100 Frames time: 229693 us
BW estimated: 228.255984 Msps
100 Frames time: 227860 us
BW estimated: 230.092144 Msps
100 Frames time: 228298 us
BW estimated: 229.650720 Msps
100 Frames time: 228683 us
BW estimated: 229.264080 Msps
100 Frames time: 229944 us
BW estimated: 228.006832 Msps
100 Frames time: 228245 us
BW estimated: 229.704048 Msps
100 Frames time: 230125 us
BW estimated: 227.827488 Msps
100 Frames time: 228555 us
BW estimated: 229.392480 Msps
100 Frames time: 228161 us
BW estimated: 229.788608 Msps
100 Frames time: 229833 us
BW estimated: 228.116928 Msps
100 Frames time: 227558 us
BW estimated: 230.397520 Msps
100 Frames time: 228776 us
BW estimated: 229.170896 Msps
100 Frames time: 242487 us
BW estimated: 216.212816 Msps
100 Frames time: 259483 us
BW estimated: 202.050992 Msps
100 Frames time: 236207 us
BW estimated: 221.961232 Msps
100 Frames time: 251341 us
BW estimated: 208.596304 Msps
100 Frames time: 246232 us
BW estimated: 212.924384 Msps
100 Frames time: 254159 us
BW estimated: 206.283456 Msps
100 Frames time: 240016 us
BW estimated: 218.438784 Msps
100 Frames time: 245845 us
BW estimated: 213.259584 Msps
100 Frames time: 258373 us
BW estimated: 202.919040 Msps
100 Frames time: 238460 us
BW estimated: 219.864112 Msps
100 Frames time: 231817 us
BW estimated: 226.164608 Msps
100 Frames time: 229923 us
BW estimated: 228.027648 Msps
100 Frames time: 229264 us
BW estimated: 228.683104 Msps
100 Frames time: 231963 us
BW estimated: 226.022272 Msps
100 Frames time: 229228 us
BW estimated: 228.719008 Msps
100 Frames time: 228258 us
BW estimated: 229.690960 Msps
100 Frames time: 229043 us
BW estimated: 228.903744 Msps
100 Frames time: 229686 us
BW estimated: 228.262928 Msps
100 Frames time: 230051 us
BW estimated: 227.900768 Msps
100 Frames time: 231663 us
BW estimated: 226.314960 Msps
100 Frames time: 230079 us
BW estimated: 227.873024 Msps
100 Frames time: 229936 us
BW estimated: 228.014736 Msps
100 Frames time: 231120 us
BW estimated: 226.846672 Msps
100 Frames time: 229336 us
BW estimated: 228.611280 Msps
100 Frames time: 229634 us
BW estimated: 228.314608 Msps
100 Fr

Re: [Discuss-gnuradio] gnuradio-companion & hamlib bodging

[Darren Long]

Hi again,

I've got my gnuradio 'pan-adapter' for my KX3 transceiver pretty much
working now: http://www.g0hww.net/2012/10/gnuradio-hamlib-and-kx3.html

 but there seems to be a memory leak occurring when I call

self.wxgui_waterfallsink2_0.set_baseband_freq(self.rig_freq)

to update the waterfall's baseband centre frequency with the result of
polling the transceiver (using pexpect with hamlib's rigctl).

To be clear, the leak only occurs when set_baseband_freq() is called. if
that line is commented out, there is no leak.

Is this a known issue?

Cheers,

Darren

On 28/10/12 17:55, Darren Long wrote:
> Never mind.  I've bodged it directly in the generated python.
>
> Darren
>
> On 28/10/12 14:35, Darren Long wrote:
>> Hi,
>>
>> In gnuradio-companion,  I'm tring to control my KX3 transceiver using
>> hamlib's rigctl utility.
>>
>> I've bodged a call to:
>> float(pexpect.run("rigctl -m 229 -r /dev/ttyUSB0 -s 38400 f"))
>> in a variable block's value, and then used that to set the wxgui
>> waterfall sink's baseband frequency, which works but i'm trying to
>> figure out 2 more things.
>>
>> 1) Can i do something similar to set the KX3's vfo frequency? a similar
>> command to rigctl can be used if i can bodge the call  into Freq Set
>> Varname somehow.
>>
>> 2) Somehow i need to accommodate physical knobulation of the VFO on the
>> radio, and keep the waterfall scale in sinc with the radio, i.e. by
>> polling the same command i've used above.  Is there any chance i can do
>> that via similar bodging in gnuradio-companion, or, am I actually going
>> to have to write actually write some code?
>>
>> Cheers,
>>
>> Darren, G0HWW
>>
>> ___
>> 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] gnuradio-companion & hamlib bodging

[Darren Long]

Never mind.  I've bodged it directly in the generated python.

Darren

On 28/10/12 14:35, Darren Long wrote:
> Hi,
>
> In gnuradio-companion,  I'm tring to control my KX3 transceiver using
> hamlib's rigctl utility.
>
> I've bodged a call to:
> float(pexpect.run("rigctl -m 229 -r /dev/ttyUSB0 -s 38400 f"))
> in a variable block's value, and then used that to set the wxgui
> waterfall sink's baseband frequency, which works but i'm trying to
> figure out 2 more things.
>
> 1) Can i do something similar to set the KX3's vfo frequency? a similar
> command to rigctl can be used if i can bodge the call  into Freq Set
> Varname somehow.
>
> 2) Somehow i need to accommodate physical knobulation of the VFO on the
> radio, and keep the waterfall scale in sinc with the radio, i.e. by
> polling the same command i've used above.  Is there any chance i can do
> that via similar bodging in gnuradio-companion, or, am I actually going
> to have to write actually write some code?
>
> Cheers,
>
> Darren, G0HWW
>
> ___
> 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] gnuradio-companion & hamlib bodging

[Darren Long]

Hi,

In gnuradio-companion,  I'm tring to control my KX3 transceiver using
hamlib's rigctl utility.

I've bodged a call to:
float(pexpect.run("rigctl -m 229 -r /dev/ttyUSB0 -s 38400 f"))
in a variable block's value, and then used that to set the wxgui
waterfall sink's baseband frequency, which works but i'm trying to
figure out 2 more things.

1) Can i do something similar to set the KX3's vfo frequency? a similar
command to rigctl can be used if i can bodge the call  into Freq Set
Varname somehow.

2) Somehow i need to accommodate physical knobulation of the VFO on the
radio, and keep the waterfall scale in sinc with the radio, i.e. by
polling the same command i've used above.  Is there any chance i can do
that via similar bodging in gnuradio-companion, or, am I actually going
to have to write actually write some code?

Cheers,

Darren, G0HWW

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

[Discuss-gnuradio] gnuradio-companion & hamlib bodging

[Darren Long]

Hi,

In gnuradio-companion,  I'm tring to control my KX3 transceiver using
hamlib's rigctl utility.

I've bodged a call to:
float(pexpect.run("rigctl -m 229 -r /dev/ttyUSB0 -s 38400 f"))
in a variable block's value, and then used that to set the wxgui
waterfall sink's baseband frequency, which works but i'm trying to
figure out 2 more things.

1) Can i do something similar to set the KX3's vfo frequency? a similar
command to rigctl can be used if i can bodge the call  into Freq Set
Varname somehow.

2) Somehow i need to accommodate physical knobulation of the VFO on the
radio, and keep the waterfall scale in sinc with the radio, i.e. by
polling the same command i've used above.  Is there any chance i can do
that via similar bodging in gnuradio-companion, or, am I actually going
to have to write actually write some code?

Cheers,

Darren, G0HWW

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

Re: [Discuss-gnuradio] Porting cgran AIS to the new cmake build system

[Darren Long]

Hi Chris,

Might I be so bold to suggest that in your efforts, you consider using
the gr-osmosdr abstraction (http://sdr.osmocom.org/trac/wiki/GrOsmoSDR)
so that the RTL-SDR could be used too. In fact it supports  UHD, FCD and
RTL-SDR, and works well in gqrx for example.

Sorry for being cheeky :P

Darren

On 17/07/12 22:43, Christian Gagneraud wrote:
> On 17/07/12 22:24, Nick Foster wrote:
>> Christian,
>>
>> Are you using the version found here?
>>
>> https://github.com/bistromath/gr-ais
>>
>> If not, please use this version, as it is significantly more up-to-date
>> than the one on CGRAN. I'm going to change the CGRAN page to point to
>> the Github repository.
>
> Interesting.
>
> Would you be interested in getting it ported to the new build system?
> If so, I'll redo the work on your tree.
> As well, I realised that ais_received.py is tailored for the USRP.
> I'm currently using a funcube dongle, so I might as well contribute
> with a dedicated script, once i start to get things working.
>
> Chris
>
>
>>
>> --n
>>
>> On Tue, Jul 17, 2012 at 1:42 PM, Christian Gagneraud > > wrote:
>>
>> On 17/07/12 21:31, Josh Blum wrote:
>>
>>
>>
>> On 07/17/2012 01:27 PM, Christian Gagneraud wrote:
>>
>> Hi,
>>
>> I tried to build https://cgran.org/wiki/AIS against
>> gnuradio-3.6, and i
>> fails.
>> As 3.6 brings in a new build system, I decided to give it a
>> go on the
>> AIS module. I based everything on gr-howto-write-a-block
>>
>> [...]
>>
>> ImportError:
>> /usr/local/lib/python2.7/site-__packages/ais/_ais_swig.so:
>> undefined symbol: _Z14ais_make_shiftv
>>
>>
>> Just a guess, but
>>
>> In gnuradio we explicitly export the library symbols. If you
>> arent doing
>> that for libgnuradioais, make sure that the visibility flag is
>> being set
>> to default. You can read more here:
>> http://gcc.gnu.org/wiki/__Visibility
>> 
>>
>>
>> Hi Josh,
>>
>> Actually, I've just discovered this was needed! So, yes that was it.
>> No it's complaining about usrp stuff, but it's another story. I
>> don't have a USRP, I'm using a FUNcube dongle.
>>
>> BTW, should I make this package install in
>> lib/python2.7/site-packages/__gnuradio/ais instead of
>> lib/python2.7/site-packages/__ais
>> Same with the include dir: include/gnuradio/ais instead of
>> include/ais?
>>
>> I would like to be able to use gnuradio-companion, and pick up the
>> AIS block from the selection list, but it's not there. This might be
>> due to the current install dir. Any comment?
>>
>> Chris
>>
>>
>>
>>
>>
>> -josh
>>
>> _
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
>> 
>>
>>
>>
>> --
>> Christian Gagneraud,
>> Embedded systems engineer.
>> Techworks Marine
>> 1 Harbour road
>> Dun Laoghaire
>> Co. Dublin
>> Ireland
>> Tel: + 353 (0) 1 236 5990 
>> Web: http://www.techworks.ie/
>>
>>
>>
>> _
>> 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] GMSK AX25 link to TCP with N200

[Darren Long]

Me too, please.

Darren

On 07/06/12 00:20, John Malsbury wrote:
> PS - The decoder I built was tested with live recordings of a stensat
> beacon from the phonesat group, so I think it will certainly work in
> your case - if only with minor modifications.
>
> -John
>
> On Wed, Jun 6, 2012 at 4:18 PM, John Malsbury  > wrote:
>
> Adam,
>
> I apologize if I'm misunderstanding your question.  But the packet
> decoder in GNU Radio is not an AX.25, just a general purpose
> decode.  I've hacked together an AX.25 receiver with the N200.  I
> can send the files to you tomorrow.
>
> -John
>
>
>
> On Wed, Jun 6, 2012 at 3:52 PM, Adam Gunderson
> mailto:agunder...@ssel.montana.edu>>
> wrote:
>
> Hello,
>
> We are currently trying to setup a ground station for GMSK
> modulated AX25 packets at 9600 and 19200. 
>
> Our current setup that works is the USRP N200 through GNU
> radio audio sink and to a Kantronics 9612+ TNC
> (gmsk_demod.png, quadrature demod -> audio sink). What we want
> to do is replace the hardware TNC with GNU radio packet
> decoding blocks and send the packets over TCP. 
>
> We first tested the loopback through all the gmsk mod/demod
> and packet encoder/decoder blocks, (gmsk_loopback.png) and
> this works fine. 
>
> However, when we send our received AX.25 packets through GMSK
> demod -> packet decoder -> TCP sink (gmsk_demod.png) we do not
> see anything on the TCP server side, which tested fine in
> loopback. 
>
> We are assuming the hangup is in the packet decoder block as
> it is not recognizing AX.25 packets or possibly at the end of
> the GMSK demod block. 
>
> Do we need to look into writing our own packet decoder
> block? If we need to do this, is there a good guide on how to
> edit existing blocks, or look at their work() functions?
>
> Do we need to also implement a derandomizer block before we
> even can start making sense of the bit stream?
>
> If we were able to get a byte stream with the framed AX.25
> packets as an output from GNU radio to our TCP server we can
> deframe them there instead of in GNU radio, but we cannot get
> any output with this current setup.
>
> We have also looked at trying to get the GMSK Spacecraft
> Groundstation project to work but the versions must be out to
> date because the files located
> on https://www.cgran.org/wiki/GMSKSpacecraftGroundstation won't make.
>
> Thanks
>
> -Adam
>
> -- 
> Adam K. Gunderson
> Space Science and Engineering Lab
> Montana State University
> agunder...@ssel.montana.edu
> 
>
> 
>
> ___
> 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] Multiple USRP N210s: LEDs and Ethernet lights on after program termination

[Darren Long]

I've noticed that when stopping a GRC sketch and starting another, I get 
unknown stream ID reports from my B100, requiring a restart of the USRP to 
recover. This used to happen a while back, but was fixed. Perhaps the fix has 
been broken or the issue is similar.

Darren

Sent from my iPhone

On 30 May 2012, at 16:23, Ryan Wolfarth  wrote:

> Hi Josh,
> 
> Thanks for your quick reply!  We are actually using rx_samples_to_file as a 
> first attempt at benchmarking the systems data transfer speed.  We give a 
> proper crtl+c whenever we terminate the program, but the problem persists.  
> We tried rx_timed_samples per your recommendation and found that the port and 
> USRP terminated properly.  The program doesn't seem to be modified from 
> previous releases, so my first blind guess is that there could be an issue 
> with the interface on one side of our network card (Intel 82576 Gigabit 
> controller).  
> 
> Due to the simplicity of our data collection scheme, we will probably modify 
> rx_samples_to_file to respond to an external trigger.  So if we could get the 
> example working properly that would be a great starting point.  Do you have 
> any more ideas?
> 
> Thanks again,
> Ryan
> 
> On Tue, May 29, 2012 at 11:09 PM, Josh Blum  wrote:
> 
> 
> On 05/29/2012 05:36 PM, Ryan Wolfarth wrote:
> > Hi list,
> >
> > We've setup 4 USRP N210 rev4s with a Dell PowerEdge R510 server to collect
> > RF data for GPS related experiments.  The server works great and we seem to
> > be able to write 20 Msps from each device simultaneously to a RAID array
> > with no overflows.  However, after each collection program is terminated,
> > the Ethernet and debugging LEDs (C, D, blinking E, and F) remain on.  We
> > tested this with a single device with the same result.  Does anybody know
> > the cause of this and if we should be worried?  We're running UHD 3.4.2
> > (downloaded 2 days ago).  All N210s were updated with the firmware/image
> > downloaded from the same version and compiled from source using GNU ZPU
> > Tools and Xilinx ISE 13.1 respectively.  The server is running 64-bit
> > Ubuntu 12.04.  Any help is appreciated!
> >
> 
> http://files.ettus.com/uhd_docs/manual/html/usrp2.html#front-panel-leds
> 
> I would only really be worried about C which means the device is still
> sending samples out of the ethernet port. This can happen if the
> streaming isnt properly shutoff like ctrl+c or destructors not being called.
> 
> Additionally, (if it is still streaming) the USRP isnt getting an ICMP
> destination unreachable from the host when the socket on the host
> closes. Its possible that due to your network setup that this packet
> doesnt get generated and/or delivered.
> 
> If it is the deconstructor issue, sometimes its useful in gr python apps
> to set the top block object to None to help python garbage collect it.
> 
> tb.stop()
> tb = None
> 
> I would also see if things shutoff as expected when your run one of the
> included examples such as rx_timed_samples
> 
> Hope that helps!
> -josh
> 
> ___
> 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] building carrier sense in the FPGA and UHD

[Darren Long]

In the amateur radio world, AX.25 "packet radio" terminal node
controllers supported  KISS mode, which left the CSMA and HDLC framing
in the TNC but offloaded the state-machine for connection management to
the host CPU stack. 

KISS merely provided a way to forward the frame metadata and payload
over the serial link between the TNC and the host.  With buffering at
each end of the serial link to the TNC, knowing exactly when a specific
frame of data has been transmitted on air is impossible and this causes
some grief in the Linux kernel's internal implementation of the state
machines for connected mode AX.25, specifically when scheduling
retransmissions.

To be fair, we are talking about fairly large buffers and fairly low
bit-rates on tx here - 1200 baud typically, but nugatory retransmission
due to channel state backoff without backpressure is a bugger.

I assume that we would want a control plane that can provide that kind
of feedback, and would want some way of tagging transmission data units
as requiring some kind of notification of transmission on-air. 

I'm very new in the gr world so can't talk with authority on anything
other than provide vague waffle such as this for your consideration.

Cheers,

Darren, G0HWW

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

[Discuss-gnuradio] Fwd: Re: uhd b100 problems

[Darren Long]

First attempt at posting to the list - didn't spot the need to reply to
all and replied direct by accident.  Obviously my point has been
obsoleted already by the post by Marcus, but it is quoted below anyway.

Cheers,

Darren

 Original Message 
Subject:Re: [Discuss-gnuradio] uhd b100 problems
Date:   Fri, 17 Feb 2012 22:14:47 +
From:   Darren Long 
To: dave k 



I have been having similar issues intermittently, although just
reloading the firmware works for me without the need to cycle power.  
It seems to have improved in the last week or so with updated code. I
use the build-gnuradio script, so not really sure what update improved
it for me as everything gets updated in one go.

Darren


On 17/02/12 22:08, dave k wrote:
> iam having alot of troubles with my b100. i have to powercycle almost 
> everytime to get my flowgraphs running. if i dont i get this
> Got a data packet with unknown SID 4294967293
>
> UHD Error:
> Got a data packet with unknown SID 4294967293
>
> UHD Error:
> Got a data packet with unknown SID 4294967293
>
> UHD Error:
> Got a data packet with unknown SID 4294967293
>
> UHD Error:
> Got a data packet with unknown SID 4294967293
>
> UHD Error:
> Got a data packet with unknown SID 4294967293
>
>
>
> any ideas?
>
> ___
> 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