Re: Getting GPS data into stream
Hey Marcus, as you say, for a lot of science you don't get high rates – so I'm really less worried about that. More worried about Excel interpreting some singular data point as date; or, as soon as we involve textual data, all the funs with encodings, quoting/delimiting/escaping… (not to mention that an Excel set to German might interpret different things as numbers than a Northern American one). I wish there was just one good CSV standard that tools adhered to. Alas, that's not the case, and especially Excel has a habit of autoconverting input and losing data at that point. So, looking for an alternative that has these well-defined constraints and isn't as focused on hierarchical data (JSON, YAML, XML), far too verbose but excellent to query with command line tools (XML), completely impossible to correctly parse as human or parser in its full beauty (YAML)… Just some tabular data notation that's textual, appendable, and not a party of guesswork for the reading tool. We could just canonalize calling all our files marcusdata.utf8.textalwaysquoted.iso8601.headerspecifies_fieldname_parentheses_type.csv but even that wouldn't solve the issue of excel seeing an unquoted 12.2021 and deciding the field being about christmases past. So, maybe we just do some rootless JSON format that starts with a SigMF object describing the file and its columns, and then basically is just a sequence of JSON arrays [ 1.212e-1, 0, "Müller", 24712388823 ] [ 1.444e-2, 1, "📡🔭 \"👽\"!", 111 ] [ 2.0115-1, 0, "Cygnus-B", 0 ] (I'm not even sure that's not valid JSON; gut feeling tells me we should be putting [] around the whole document, but we don't want that for streaming purposes. ECMA-404 doesn't seem to *forbid* it.) That way, we get the metadata in a format that's easy to skip by simpler tools, but trivial to parse with the right tools (I've grown to like `jq`), and the data into a well-defined format. Sure, you can't dump that into Excel, still, but you know what, if it comes down to it, we can have a python script that takes these files and actually converts them to valid XLSX without the misconversion footguns, and that same tool could also be run in a browser for those having a hard time executing python on their machines. Cheers, Marcus On 03.05.23 23:05, Marcus D. Leech wrote: On 03/05/2023 16:51, Marcus Müller wrote: Do agree, but really don't like CSV, too underspecified a format, too many ways that comes back to bite you (aside from a thousand SDR users writing emails that their PC can't keep up with writing a few MS/s of CSV…) I like CSV because you can hand your data files to someone who doesn't have a complete suite of astrophysics tools, and they can slurp it into Excel and play with it. How important is plain-textness in your applications? I (and many others in my community) tend to throw ad-hoc tools at data from ad-hoc experiments. In the past, I used a lot of AWK to post-process data, and these days, I use a lot of Python. Text-based formats lend themselves well to this kind of processing. Rates are quite low, typically. Like logging an integrated power spectrum a few times a minute, for example. There are other observing modes where text-based formats aren't quite so obvious--like pulsar observations, where filterbank outputs might be recorded at 10s of kHz, and then post-processed with any of a number of pulsar tools. In all of this, part of the "science" is extracted in "real-time" and part in post-processing. Best, Marcus smime.p7s Description: S/MIME Cryptographic Signature
Re: QAM constellation script
On Wednesday, 3 May 2023 19:20:10 EEST Marcus Müller wrote: > Hi George, > > that's a multiplicative voice scrambler! > > The pre-Second World war voice scrambler system "SIGSALY" [1] was kind > of similar; > just that the scrambling sequence came out of a noisy vacuum tube, not > Python's random.random(), and that the combination method was taking > samples and adding them modulo 6, instead of multiplying the phase > (which is inherently modulo 2π). > That was a really nice description, thank you for taking the time to write that. The original project is also interesting, even if we call it differently. So to me this looks like a basic CDMA access scheme, is there really any advantage to using it as opposed to standard FDMA as traditionally used on QO100? From an amateur radio operator perspective. Adrian
Re: QAM constellation script
Hi Adrian, for CDMA, two things need to be different: 1. you need at least one orthogonal other sequence used by another user / data stream – that MA in CDMA is multiple access :) 2. In classical CDMA, you would need your data to be a constant that you multiply with your sequences – if you multiply a signal that changes during the duration of your sequence, you lose all guarantees that another signal using another orthogonal sequence is still orthogonal. > is there really any > advantage to using it as opposed to standard FDMA as traditionally used on > QO100? From an amateur radio operator perspective. Hm, I think the point was distributing the signal energy across a larger range. That can be done for several reasons – inhibiting detection through an adversary being one (and the classical origin story of Frequency-Hopping Spread Spectrum), although one that doesn't apply to amateur radio. The other one is that in classical FDMA, you take a x kHz wide signal, and put it on one of a defined set of x kHz wide channels. If something else disturbs that channel, bad luck. In spread-spectrum systems, you gain robustness agains narrowband interferers. There's a couple other "side-benefits" you might be getting from a wider bandwidth; from the ability to more easily transport a higher-resolution time information (nice if you want to do ranging!) to the fact that if I take some fixed transmit power and distribute it across a wider band, I still get the same energy per bit that I transmit, but at a lower spectral power density – and often, that's what is regulated. (that is of course what allows to make signals harder to detect: pushing the PSD of your signal below noise floor) Cheers, Marcus
Re: QAM constellation script
Hey, On 04.05.23 11:38, Adrian Musceac wrote: On Thursday, 4 May 2023 12:11:47 EEST you wrote: Hi Adrian, for CDMA, two things need to be different: 1. you need at least one orthogonal other sequence used by another user / data stream – that MA in CDMA is multiple access :) I was assuming multiple pairs of users would use orthogonal codes to avoid interference between themselves. Problem is you need to come up with a sequence that's (approximately) orthogonal to the first 10240 values from random(). For the first such sequence: easy. To find the third sequence in that code, you would already need to incorporate the two existing sequences to find a third orthogonal one. To find the Nth sequence, you need to incorporate all N-1 previous ones. A 10240-dimensional space should have 10240 base vectors – so complexity of finding a good set of CDMA sequences from the random.random() starting point is 10240!; not a nice number. 2. In classical CDMA, you would need your data to be a constant that you multiply with your sequences – if you multiply a signal that changes during the duration of your sequence, you lose all guarantees that another signal using another orthogonal sequence is still orthogonal. I'll have to try and parse this later because I have a hard time understanding how the data payload could change during chipping. Because you intuitively would start with a single symbol and multiply it with the *whole* sequence. What George's code does is different: It takes each sample of the audio signal and multiplies it with a corresponding random sample. The other one is that in classical FDMA, you take a x kHz wide signal, and put it on one of a defined set of x kHz wide channels. If something else disturbs that channel, bad luck. In spread-spectrum systems, you gain robustness agains narrowband interferers. Won't shared used of the spectrum by both narrow band transmissions and spread transmissions manifest in a rise of the noise floor and SNR degradation for both types of users? Yes! But in one case, "A 10 kHz wide interferer in a user's channel" means no communication for that specific user, but in the spread spectrum case, it just means a slightly reduced SNR. This is a question I asked myself before but in the case of LoRa. LoRa's interesting because they combine multiple "mechanisms" of spreading, and because the despreading is technically especially interesting (and maybe more similar to what I'd call "pulse compression" in wideband radar). Cheers, Marcus
Re: QAM constellation script
Sorry,, I meant to send the previous email to the list. On Thursday, 4 May 2023 13:01:10 EEST Marcus Müller wrote: > Because you intuitively would start with a single symbol and multiply it > with the *whole* sequence. What George's code does is different: It takes > each sample of the audio signal and multiplies it with a corresponding > random sample. > I understand now. I wouldn't use a random number generator for this. Still, pretty interesting. Tough I can foresee objections from narrow-band users of QO100 :) Cheers, Adrian
Re: QAM constellation script
Hi Marcus,
In QO100 there are Doppler shifts (that is the reason of the 200 Hz shift in
flowchart).I have already implement a flowchart of calculating it using the
middle BPSK beacon of QO100 using the frequency error of costal loop.My ground
station is equipped with GPSDO.I have already do spread spectrum experiments
with direct sequence of 1 M in QO100.Also initially I used FreeDV (which uses
CODEC2) instead of USB in narrow band of SS.I use USB as it is more forgiving
to frequency shifts due to Doppler.I have also implemented digital voice using
CODEC2,HDLC, BPSK/QPSK in QO100 (thanks t\o GNURadio!!!).My QO100 ground
station setup (90 cm for Rx and 3W@80 cm Tx ) permits me a few dB less signal
than maximum allowed (beacon level) for a 2.7 kHz bandwidth in NB transponder.
Once more : THANKS for the detailed answer!!!
George SV1BDS
On Wednesday, May 3, 2023 at 07:20:13 PM GMT+3, Marcus Müller
wrote:
Hi George,
that's a multiplicative voice scrambler!
The pre-Second World war voice scrambler system "SIGSALY" [1] was kind
of similar;
just that the scrambling sequence came out of a noisy vacuum tube, not
Python's random.random(), and that the combination method was taking
samples and adding them modulo 6, instead of multiplying the phase
(which is inherently modulo 2π).
So, that should work quite nicely for spreading; it's not as great for
the secretive purposes the (later) Allies developed the original scramblers:
1. We're re-using the same 10240 length sequence as scrambling signal –
that's very fine for the spreading, but from a cryptographic point
of view, if the secrecy of a message depended on an eavesdropper not
knowing the sequence, not great, because it's easy with a bit of
statistics to recover an approximative spreading sequence.
2. Since the bandwidth of the scrambled signal is much higher than the
unscrambled message signal, an envelope detector on the whole
bandwidth can probably (I didn't try) recover a pretty intelligible
version of the audio signal (in the end, if the power of the audio
signal is low, due to the multiplications, so is the power of the
signal you transmit; it's kind of similar to AM, but instead of
modulating a carrier, we modulate a white noise source). Of course,
knowing the spreading sequence (i.e., knowing how to seed
random.seed()) gives a large processing gain and thus much better
SNR at the receiver's output than plain power detection.
But you're no trying to send secret messages – you're just trying to use
a wide band of spectrum, and for that, your solution works fine, if your
synchronization between transmitter and receiver is good enough in time
and frequency.
There's a bit of a hurdle there: No two oscillators are /exactly/ the
same, and there's also things like Doppler – so you need to use your
preamble (fh==False case) to not only know at which time you need to
start your random multiplication, but also to know by how many Hertz
your receiver is tuned off the "correct" frequency. If your receiver
doesn't have the exact same frequency as the transmitter, you see that
by a frequency shift in the baseband, so a multiplication with an exp(2j
· π · f_error · t), and that means that the phase of every sample gets
shifted by an additional f_error/f_sample more, and the receiver might
no longer work. To combat that, you need frequency recovery (which could
very nicely be done on a preamble, it's just not inherently trivial to
do it with a chirp), and because your receiver's oscillator might still
drift over time, maybe adding a pilot tone every so and so many seconds
might help.
In practice, what you'd probably do is take your idea and change a few
things about it. I'll illustrate the design process with sensible
example values below. Sensible in the sense that all the things are
available technologies in the open source space, and not too hard to get
to work on normal hardware:
It seems you're directly modulating analog audio. Instead, since ca the
1980s, you'd usually use a voice encoder / decoder pair (i.e., a
vocoder) to transform the voice into bits, then add error correction to
them, then spread these – that's a lot easier, and you get the chance to
use the energy you transmit for the bandwidth the "useful" information
in your voice actually has, and the energy necessary to make it have the
least error in the presence of noise, instead of having to transport the
full audio bandwidth! Then, you could design a system to use the simple
Direct-Sequence Spread Spectrum (DSSS) method.
DSSS is rather easy: you take a transmit symbol, and repeat it by a
spreading factor F, and then flip the sign of the symbols ("chips")
according to a fixed pseudorandom bit sequence that receiver and
transmitter both share. You send the signal with the full sample rate,
meaning that you increase the bandwidth by F (that's the spreading). At
the receiver, you flip in
Re: QAM constellation script
Hi, I have already make a proposal that with fh=False a multi user CDMA can be used.Each user will have a unique time in sawtooth shifting, the same time he can see all other Tx signals.Each Tx will be seen as 'constant frequency' as all users shift frequency the same rate.I do not claim that is the most efficient way, but that is technically possible. George SV1BDS On Thursday, May 4, 2023 at 11:04:42 AM GMT+3, Adrian Musceac wrote: On Wednesday, 3 May 2023 19:20:10 EEST Marcus Müller wrote: > Hi George, > > that's a multiplicative voice scrambler! > > The pre-Second World war voice scrambler system "SIGSALY" [1] was kind > of similar; > just that the scrambling sequence came out of a noisy vacuum tube, not > Python's random.random(), and that the combination method was taking > samples and adding them modulo 6, instead of multiplying the phase > (which is inherently modulo 2π). > That was a really nice description, thank you for taking the time to write that. The original project is also interesting, even if we call it differently. So to me this looks like a basic CDMA access scheme, is there really any advantage to using it as opposed to standard FDMA as traditionally used on QO100? From an amateur radio operator perspective. Adrian
Re: QAM constellation script
> Tough I can foresee objections from narrow-band users of > QO100 :) Those should be on the narrowband transceiver on a slightly different band! Cheers, Marcus smime.p7s Description: S/MIME Cryptographic Signature
RE: Re: Getting GPS data into stream
You are confusing data representation with data presentation. The flaws in Excel are NOT issues with the data format. So long as the data format clearly and consistently represents that content, then the representation is "good". If you want to overcome limitations in Excel's presentation (import, interpretation), then that's an Excel issue. You can overcome it by manually doing the import and explicitly asserting the data type of each column, or you can create something more custom. Realize that more and more your data is likely to be consumed by some other data science tool (R, Python/numpy/pandas, etc.) and you quickly see how pushing Excel issues into the data representation layer is a losing proposition. --- Jim Melton -Original Message- Sent: Thursday, May 4, 2023 01:40 To: discuss-gnuradio@gnu.org Subject: [EXTERNAL] Re: Getting GPS data into stream Hey Marcus, as you say, for a lot of science you don't get high rates – so I'm really less worried about that. More worried about Excel interpreting some singular data point as date; or, as soon as we involve textual data, all the funs with encodings, quoting/delimiting/escaping… (not to mention that an Excel set to German might interpret different things as numbers than a Northern American one). I wish there was just one good CSV standard that tools adhered to. Alas, that's not the case, and especially Excel has a habit of autoconverting input and losing data at that point. So, looking for an alternative that has these well-defined constraints and isn't as focused on hierarchical data (JSON, YAML, XML), far too verbose but excellent to query with command line tools (XML), completely impossible to correctly parse as human or parser in its full beauty (YAML)… Just some tabular data notation that's textual, appendable, and not a party of guesswork for the reading tool. We could just canonalize calling all our files marcusdata.utf8.textalwaysquoted.iso8601.headerspecifies_fieldname_parentheses_type.csv but even that wouldn't solve the issue of excel seeing an unquoted 12.2021 and deciding the field being about christmases past. So, maybe we just do some rootless JSON format that starts with a SigMF object describing the file and its columns, and then basically is just a sequence of JSON arrays [ 1.212e-1, 0, "Müller", 24712388823 ] [ 1.444e-2, 1, "📡🔭 \"👽\"!", 111 ] [ 2.0115-1, 0, "Cygnus-B", 0 ] (I'm not even sure that's not valid JSON; gut feeling tells me we should be putting [] around the whole document, but we don't want that for streaming purposes. ECMA-404 doesn't seem to *forbid* it.) That way, we get the metadata in a format that's easy to skip by simpler tools, but trivial to parse with the right tools (I've grown to like `jq`), and the data into a well-defined format. Sure, you can't dump that into Excel, still, but you know what, if it comes down to it, we can have a python script that takes these files and actually converts them to valid XLSX without the misconversion footguns, and that same tool could also be run in a browser for those having a hard time executing python on their machines. Cheers, Marcus On 03.05.23 23:05, Marcus D. Leech wrote: > On 03/05/2023 16:51, Marcus Müller wrote: >> >> Do agree, but really don't like CSV, too underspecified a format, too many >> ways that >> comes back to bite you (aside from a thousand SDR users writing emails that >> their PC >> can't keep up with writing a few MS/s of CSV…) > I like CSV because you can hand your data files to someone who doesn't have a > complete > suite of astrophysics tools, and they >can slurp it into Excel and play with it. > >> >> How important is plain-textness in your applications? > I (and many others in my community) tend to throw ad-hoc tools at data from > ad-hoc > experiments. In the past, I used a lot >of AWK to post-process data, and these days, I use a lot of Python. > Text-based > formats lend themselves well to this kind >of processing. Rates are quite low, typically. Like logging an > integrated power > spectrum a few times a minute, for example. > > There are other observing modes where text-based formats aren't quite so > obvious--like > pulsar observations, where filterbank >outputs might be recorded at 10s of kHz, and then post-processed with any > of a number > of pulsar tools. > > In all of this, part of the "science" is extracted in "real-time" and part in > post-processing. > > >> >> Best, >> Marcus >> > > CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are confidential, may contain proprietary, protected, or export controlled information, and are intended for the use of the intended recipients only. Any review, reliance, distribution, disclosure, or forwarding of this email and/or attachments outside of Sierra Nevada Corporation (SNC) without express written approval of the sender, except to the extent required
Re: Getting GPS data into stream
Sorry again, never mind... I found the problem. The source code for reading the data does not include the fact that I am reading complex data and also three streams. Change the one line to: data=np.fromfile(file=fh, dtype=np.float32, count=3*2*int(header_info['nitems']), sep='', offset=0) and everything seems to work as expected. Now I just have to figure out how the data is ordered in that blob ;) Best, Fabian Am 04.05.23 um 19:19 schrieb Fabian Schwartau: Hi everyone, I think I got hit by https://github.com/gnuradio/gnuradio/issues/5568. Exactly the same error message. Is there any update on that issue or a workaround? Attached are my files. Best, Fabian Am 03.05.23 um 21:01 schrieb Marcus D. Leech: On 03/05/2023 14:59, Fabian Schwartau wrote: Sorry, forget it. Wrong sink... You probably want: https://wiki.gnuradio.org/index.php/File_Meta_Sink Am 03.05.23 um 20:52 schrieb Fabian Schwartau: OK, I think I found an easier way (at least for me), without having to write my own module - never done that. I used the "Tags Strobe" block in combination with the "Python Module" for my gps_get_position() function. Anyway, where can I find a definition of the format of the "Tagged File Sink"? I need to read this with antoher program, without gnuradio, but in python. Best, Fabian Am 03.05.23 um 20:04 schrieb Marcus Müller: Hi Fabian, I'd write a block that copies a stream in- to output. It might query gpsd every time the work() function is called, or have a FIFO into which data from gspd is being pushed by a separate thread (or by reading from a socket or however gspd works, I must admit I'm not sure). You then take that info, and encode the long, lat, uncertainty as (double, double, double) PMT tuple. You then use add_item_tag to add that PMT to the first sample in your output buffer. You'd feed the result into a metadata file sink block: That saves things in a serialized format ready for retrieval. Best, Marcus On 5/3/23 19:52, Fabian Schwartau wrote: Hi everyone, I am trying to record some data from an SDR and would like to sync/tag the data with the current gps position from gpsd. I am kind of stuck and don't know how a possible solution for that might look like in grc. I have a python function that gets the current position as a tuple, but how do I get this into my data stream, which I would like to write to a CSV file or similar? I am not asking for a solution of my problem, just point me in the right direction ;) Best, Fabian
Re: Getting GPS data into stream
On 04/05/2023 12:09, Jim Melton wrote: You are confusing data representation with data presentation. The flaws in Excel are NOT issues with the data format. So long as the data format clearly and consistently represents that content, then the representation is "good". If you want to overcome limitations in Excel's presentation (import, interpretation), then that's an Excel issue. You can overcome it by manually doing the import and explicitly asserting the data type of each column, or you can create something more custom. Realize that more and more your data is likely to be consumed by some other data science tool (R, Python/numpy/pandas, etc.) and you quickly see how pushing Excel issues into the data representation layer is a losing proposition. --- Jim Melton For myself, I'm not actually committed to any particular text format, but .csv was helpful for some of the "customers" of my apps, because they're used to doing "casual" science extraction using Excel. For relatively low-rate/low-volume data, I find that text formats let me explore it for first-order sanity-checking, and it also allows for processing with a number of different tools without having to bring in great lumbering packages and libraries. I can process my .csv data with AWK, Ad-Hoc Python, GnuPlot and Octave and R without too much fuss--because the columns are regular and in known places, and typically floating-point or integers. When you move towards data that has much higher rates/volumes, and has more exotic semantics, like pulsar processing, you start to abandon text. But 99% of my "user community" are amateur science types, whose experiments are somewhat ad-hoc, and are usually confined to simple observing modes where low-rate textual logging makes considerable sense... -Original Message- Sent: Thursday, May 4, 2023 01:40 To: discuss-gnuradio@gnu.org Subject: [EXTERNAL] Re: Getting GPS data into stream Hey Marcus, as you say, for a lot of science you don't get high rates – so I'm really less worried about that. More worried about Excel interpreting some singular data point as date; or, as soon as we involve textual data, all the funs with encodings, quoting/delimiting/escaping… (not to mention that an Excel set to German might interpret different things as numbers than a Northern American one). I wish there was just one good CSV standard that tools adhered to. Alas, that's not the case, and especially Excel has a habit of autoconverting input and losing data at that point. So, looking for an alternative that has these well-defined constraints and isn't as focused on hierarchical data (JSON, YAML, XML), far too verbose but excellent to query with command line tools (XML), completely impossible to correctly parse as human or parser in its full beauty (YAML)… Just some tabular data notation that's textual, appendable, and not a party of guesswork for the reading tool. We could just canonalize calling all our files marcusdata.utf8.textalwaysquoted.iso8601.headerspecifies_fieldname_parentheses_type.csv but even that wouldn't solve the issue of excel seeing an unquoted 12.2021 and deciding the field being about christmases past. So, maybe we just do some rootless JSON format that starts with a SigMF object describing the file and its columns, and then basically is just a sequence of JSON arrays [ 1.212e-1, 0, "Müller", 24712388823 ] [ 1.444e-2, 1, "📡🔭 \"👽\"!", 111 ] [ 2.0115-1, 0, "Cygnus-B", 0 ] (I'm not even sure that's not valid JSON; gut feeling tells me we should be putting [] around the whole document, but we don't want that for streaming purposes. ECMA-404 doesn't seem to *forbid* it.) That way, we get the metadata in a format that's easy to skip by simpler tools, but trivial to parse with the right tools (I've grown to like `jq`), and the data into a well-defined format. Sure, you can't dump that into Excel, still, but you know what, if it comes down to it, we can have a python script that takes these files and actually converts them to valid XLSX without the misconversion footguns, and that same tool could also be run in a browser for those having a hard time executing python on their machines. Cheers, Marcus On 03.05.23 23:05, Marcus D. Leech wrote: On 03/05/2023 16:51, Marcus Müller wrote: Do agree, but really don't like CSV, too underspecified a format, too many ways that comes back to bite you (aside from a thousand SDR users writing emails that their PC can't keep up with writing a few MS/s of CSV…) I like CSV because you can hand your data files to someone who doesn't have a complete suite of astrophysics tools, and they can slurp it into Excel and play with it. How important is plain-textness in your applications? I (and many others in my community) tend to throw ad-hoc tools at data from ad-hoc experiments. In the past, I used a lot of AWK to post-process data, and these days, I use a lot of Python. Text-ba
Re: Qt widgets Improvement
hello everyone, thanks a lot for accepting my proposal for gsoc 2023 for the project "Qt widgets improvements" . I am enthusiastic about contributing my best and becoming a valuable member of the GNU Radio community. Thank you once again for this opportunity. Best regards, Rohit Bisht On Sat, 1 Apr 2023 at 18:54, Rohit Bisht wrote: > Hi, > > I submitted my proposal for the GNU Radio project with the QT Widgets > Improvements project and would like to get some feedback . I understand > that I am submitting this proposal close to the deadline, and I apologize > for any inconvenience this may have caused. > > I have put a lot of effort and thought into this proposal, and I truly > believe that I can contribute to this project and make a meaningful impact. > I would greatly appreciate your time and consideration in reviewing my > proposal and provide any improvements to it. > > Thank you for your understanding and support. > > Sincerely, > Rohit Bisht > > On Wed, 1 Feb 2023 at 16:34, Rohit Bisht wrote: > >> Thanks Volker for this example it will be very helpful . >> >> Btw which widget would be good to start with? >> >> Thanks >> Rohit >> >> On Tue, Jan 31, 2023, 1:52 PM Volker Schroer wrote: >> >>> Hi Marcus, >>> >>> thanks for the clarification. >>> >>> Maybe this helps: >>> >>> Qt Gui sink is an example how to use the designer together with >>> gnuradio. You'll find it in qt-gui/lib. >>> >>> An example for an oot using the designer can be found in >>> >>> github.com/dl1ksv/gr-display >>> >>> -- Volker >>> > Hi Volker, >>> > >>> > I might have gotten my Qt jargon mixed up here :) Yeah I meant QT >>> > Designer. Sorry for the confusion! >>> > >>> > Cheers, >>> > Marcus >>> > >>> > On 30.01.23 17:29, Volker Schroer wrote: >>> >> Hi, >>> >> >>> >> but I think in this case the qt-designer is the tool to to design the >>> >> widget. I'm curious how, to integrate qt-creator in the build process. >>> >> >>> >> -- Volker >>> >> >>> >> Am 30.01.23 um 17:11 schrieb Marcus Müller: >>> >>> Hi everyone! >>> >>> >>> >>> Sadly, the reply chain on this email thread got broken, so it's >>> probably >>> >>> hard for you all to see, but: >>> >>> This is about a specific GSoC proposal, which does not at all imply >>> that >>> >>> you need Qt for every flowgraph. >>> >>> Exactly as Rohit describes, this is about making it easier to build a >>> >>> GUI for GNU Radio flowgraphs *should you decide you want graphical >>> >>> visualizations*. >>> >>> And if you do so, gr-qtgui is based on Qt, anyways. >>> >>> >>> >>> Cheers, >>> >>> Marcus >>> >>> >>> >>> On 30.01.23 17:02, Jim Melton wrote: >>> I'd propose that nothing you do *requires* Qt. There are many uses >>> for >>> GUI-less flowgraphs. Qt is a heavyweight framework; it should not be >>> required in order to build GRC flowgraphs. >>> >>> --- >>> Jim Melton >>> >>> >>> -Original Message- >>> From: discuss-gnuradio-bounces+jim.melton=sncorp@gnu.org >>> On Behalf >>> Of >>> Marcus D. Leech >>> Sent: Sunday, January 29, 2023 12:30 >>> To: discuss-gnuradio@gnu.org >>> Subject: [EXTERNAL] Re: Qt widgets Improvement >>> >>> On 29/01/2023 14:20, Rohit Bisht wrote: >>> > >>> > I'd like to start with "integrating gnu with qt creator" because it >>> > would make it easier to write code in the integrated qt environment >>> > and speed up build, run, and testing. I believe adjusting the cmake >>> > file and fixing paths to missing library files would be the way to >>> go >>> > (though I'll require more directions on that). >>> > >>> > Then "adding new widgets" followed by "improving them" . >>> I guess it depends on what you think the dominant design doctrine >>> should be "gorgeous UI with the DSP as a kind of afterthought", >>> or "robust DSP with the UI as a kind of afterthought". I don't >>> think that Qt designer is a particularly productive way to design >>> the DSP bits of a DSP application. >>> >>> The whole "form is more important than function" is a bit of >>> leftover >>> brain-death promulgated by Steve Jobs, and it was as >>> wrong-headed then as it is now, IMHO. >>> >>> >>> >>> >>> CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments >>> are >>> confidential, may contain proprietary, protected, or export >>> controlled >>> information, and are intended for the use of the intended recipients >>> only. Any review, reliance, distribution, disclosure, or forwarding >>> of >>> this email and/or attachments outside of Sierra Nevada Corporation >>> (SNC) without express written approval of the sender, except to the >>> extent required to further properly approved SNC business purposes, >>> is >>> strictly prohibited. If you are not the intended recipient of this >>> email, please notify the sender immediately, a
