Chaps - this is great. I knew there was a way to do it. I would classify my
python skills as "above script kiddie, but not all the way to novice"!
I understand what the proposed solutions are and i can comprehend what is
needed to do it, but i don't have experience of implementation in code so
therefore i apologise for having to ask for a little further help. I have
read up on XMLRPC and understand the premise, but i think a lot of
perseverance and trial and error will be necessary to make it work with my
current skills. As i would be keen to make progress within a reasonable
amount of time, any example code / structure would be most welcome - as i
think my immediate goal to be able to control the parameters is very
achievable, but without a guiding hand i may get a bit lost.
Really appreciate the help. :)
On Fri, 9 Aug 2019 at 15:53, Albin Stigö wrote:
> You could implement your flowgraph in python and then use some python
> library for rpc and write a thin layer between...
>
> You can also implement a flowgraph in C++.
>
> I'm currently playing around with RPC over DBUS (only control, no data)
> for an application I'm writing in C++.
>
>
> --Albin
>
>
>
> On Fri, Aug 9, 2019, 10:35 Müller, Marcus (CEL) wrote:
>
>> Hi Alex,
>>
>> we do have two approaches for that
>>
>> 1. the XMLRPC thing, which is a python-world block that basically would
>> allow you to do the same you can do with e.g. a Qt GUI Range slider
>> (i.e. change Python variables at runtime)
>> 2. Ctrlport and the thrift backend, the latter of which is notoriously
>> hard to get right.
>>
>> I **really** think RPC is big in GNU Radio's future; we'll work on that
>> fundamentally. The problem is you're trying to solve a technical
>> challenge now, not then.
>>
>> So, check out the XMLRPC, see if it suits you.
>>
>> If it doesn't: What I'd recommend is to
>>
>> 1. use GRC to construct your flow graph as desired, assuming you're
>> doing that so far. Hint: if you use "Parameter" blocks instead of
>> "Variable" blocks, you get arguments to your top block's constructor)
>> 2. Take the resulting python file, and use it as a Python module
>> (rather than running it as executable itself), containing a class named
>> like the "id" you set in the options block (the instance of
>> gr.top_block).
>> 3. Write a simple application that imports that module, and modifies
>> the state of the top block (see the "main" function at the end of the
>> generated Python file) as dictated through RPC from your receiving end.
>>
>> For 3: I do like zeroMQ, it has good Python integration and for your
>> application, the REQuest/REPly socket pattern would probably work very
>> well. You can encode RPC commands however you like, for example simple
>> JSON like {"tune", [2.4e9, 1e6]} or so.
>>
>> Or, you can directly use a python RPC thing. I've not personally tried
>> that, but zerorpc.io looks fine for this kind of thing. Quite possible,
>> all you'd need to build on the Pi would be
>>
>> #!/usr/bin/env python
>> import zerorpc
>> import myfg #replace with the generated .py
>>
>> server = zerorpc.Server(myfg.myfg(sensible_arguments_if_any))
>> server.bind("tcp://0.0.0.0:1337") #bind to all interaces on port 1337
>>
>> # could be tcp://127.0.0.1:1337 instead, if you're doing e.g. port
>> forwarding through `ssh -R 127.0.0.1:1337:1337!
>> # There's even ZMQ brokers and stuff, but that'd lead too far.
>> s.run()
>>
>>
>> And locally, you could try
>>
>> import zerorpc
>> client = zerorpc.Client()
>> client.connect("tcp://yourPisAdddress:1337")
>> client.start()
>> client.set_samp_rate(4e6) #or whatever methods your top block has
>>
>> Best regards,
>> Marcus
>>
>> On Thu, 2019-08-08 at 23:16 +0100, Alex Pane wrote:
>> > Hi,
>> >
>> > I have created a simple tcp based iq stream using ZMQ blocks to use a
>> HackRF remotely over an ethernet network.
>> >
>> > I have a linux computer (Raspberry Pi) connected to the HackRF running
>> GNURadio. The HackRF source is connected to a ZMQ sink that transmits the
>> packets to a receiving linux PC running GNURadio - where a ZMQ source
>> connected to a QT sink for visualising the IQ signal stream.
>> >
>> > This works fine for a fixed frequency, sample rate and fft size etc,
>> however my problem is that i want to be able to change those parameters
>> from the receiving PC.
>> >
>> > Despite much research, i have been unable to find a way to change the
>> parameters of the remote flowgraph (client) from the receiving display end
>> (server).
>> >
>> > Is there a way to natively perform this operation within GNURadio and
>> can someone provide guidance on how to setup a flowgraph to achieve this?
>> Or is there some additional OOT block or custom python block i would need
>> to create to do this.
>> >
>> > Thanks
>> >
>> > Alex
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> ___
