Evaluate if we need the package gr-flowgraph at all #42

Open alexxcons opened 3 years ago

In GitLab by @alexxcons on Mar 21, 2019, 09:55

Theoretically gnuradio already has methods which do exactly the same than we do in gr-flowgraph (parse xml file, create all blocks, links all blocks, evaulate variables... )

check if gnuradio can handle our self-build blocks (check on local computer, using gnuradio-companion)
If possible, dump the package gr-flowgraph, and directly use gnuradio code instead

In GitLab by @alexxcons on Mar 21, 2019, 09:58

marked this issue as related to #12

In GitLab by @alexxcons on Mar 21, 2020, 19:35

Email zum Thema von R.Steinhagen:

GNURadio hat ab 3.8 eine 'C++ generation' feature, dass i.W. über die yml templates gesteuert wird. z.B.
[..]
cpp_templates:
includes: [ '#include <gnuradio/audio/source.h>' ]
declarations: 'audio::source::sptr ${id};'
make: 'this->${id} = audio::source::make(${samp_rate}, ${device_name}, ${ok_to_block});'
link: ['gnuradio-audio']
translations:
"'": '"'
'True': 'true'
'False': 'false'
[..]
Siehe auch: https://github.com/gnuradio/gnuradio/issues/2297 Viele der Module sind schon dafür vorbereitet bzw. im master gemerged.... die restlichen sollten bald auch da sein. Wichtig ist, dass wir unsere diesbzgl. auch vorbereiten.

Daraus kann man (ähnlich wie das GRC mit python macht) die stubs generieren, die man braucht um die grc Files einzulesen und mit den statischen Werten im grc File zu initialisieren und Sinks/Sources im flow-graph zu connecten.

Die Idee wäre daraus -- ähnlich wie bei dem bestehendem gr-flowgraph -- eine look-up Funktion für jeden Block zu generieren, aber halt automatisch und nicht händisch wie das bisher geschieht. Ungeachtet davon muss FESA aber für die benötigten und konfigurierbaren Module (z.B. input gain, Soll-ist-Vergleich, Fitter, ...) beigebracht bekommen zur Laufzeit Modulparameter zu ändern. Da wird's wohl immer noch handgestrickten Code (wegen FESA) geben müssen. Aber die Initialisierung sollte mit obigen automatisch geschehen können. Diese Modul würde dann immer neu gebaut, wenn eines unserer anderen Module neugebaut werden würde... deshalb CI/CD und alle GSI Module im gleichen Repo, damit das etwas einfacher ist.

Bzgl. Time-Line... wir werden damit vermutlich noch nicht vor Ende der Strahlzeit richtig anfangen können, da davor noch ein paar UI und CMW-Themen erst einmal fertig gemacht werden müssen.

In GitLab by @alexxcons on Apr 27, 2021, 14:29

Added tag "external", since it would be good to hear the opinion of an gnuradio expert on this issue.

@alexxcons This was 6 months ago, but if you're still looking for opinions I'd be happy to talk.

If your goal (gr-flowgraph has no Readme) is to generate a C++ application from a flowgraph then yes, GNU Radio can do that natively. Depending on the blocks you are using you may have to add some of the C++ bindings that are currently missing, but this is straightforward and only missing for a few core blocks now.

@dkozel thanks for your feedback and offer. Your advice would be much appreciated -- especially, as we are about to modernise and want to migrate to GR v3.10! :+1:
Maybe also face-to-face via Gitter or matrix.io. Let us know your preference.

Sorry for the minimalistic README.md. The gr-digitizers repo contains primarily some common data sources wrapping the Picoscope's SDK) and some filter, special data reduction, and measurement error handling blocks that are not part of the main GR branch (maybe eventually?). The initial concept has been documented here and the spec here.

If your goal (gr-flowgraph has no Readme) is to generate a C++ application from a flowgraph then yes, GNU Radio can do that natively.

Actually, we are looking into the opposite of having a running a pre-compiled application (embedded back-end server) where we can exchange the GRC flow-graph definitions ideally during run-time w/o the need for a restart/recompilation. Sort of similar to what gnuradio-companion does but w/o the UI components and w/o Python.

The signals (GR sinks) are timing-synchronised by our servers down to the ns-level and then exported via our existing and new OpenCMW middle-ware. The existing solution requires a lot of proprietary boiler-plate code that we'd like to eliminate but is required for stringing up and initialising the individually GR's own or custom blocks.

I fully support what @RalphSteinhagen said, it would be great to have a talk ! (And I will take care for a README.md in the next days :sweat_smile: )

This sounds like good timing! I'd be very interested in hearing about your setup and use-case. We're also in very active planning and trials for the GNU Radio 4.0 update and some parts of that may end up being particularily useful to you.

I am very accessible on Matrix: @dkozel:gnuradio.org and via email dkozel@gnuradio.org. Lets take this to one of those and setup a call.

fair-acc / gr-digitizers

Evaluate if we need the package gr-flowgraph at all #42