WEBVTT

00:00.000 --> 00:09.000
And since then, only new features have been added.

00:09.000 --> 00:15.000
So, this is how SGR++ works in the inside.

00:15.000 --> 00:19.000
You first have the source, which is your SGR device or file,

00:19.000 --> 00:21.000
or it can really be anything.

00:21.000 --> 00:23.000
Then you've got a pre-processing step,

00:23.000 --> 00:28.000
which just pre-process is the IQ with various algorithm that can be useful,

00:28.000 --> 00:32.000
like decimation, for example, increase dynamic range,

00:32.000 --> 00:36.000
or spectrum inversion, if you're receiving from,

00:36.000 --> 00:41.000
for example, a downconverter, which has spectrum inversion,

00:41.000 --> 00:43.000
so we can correct for it.

00:43.000 --> 00:47.000
And the IQ correction, to correct for IQ balance and DC offset,

00:47.000 --> 00:49.000
stuff like that.

00:49.000 --> 00:55.000
The next step is channelization, where various signals are downconverted,

00:56.000 --> 01:02.000
and prepared for use by each decoder, or even recorder,

01:02.000 --> 01:04.000
or anything, any module.

01:04.000 --> 01:08.000
And then, these modules, if they output audio,

01:08.000 --> 01:13.000
they output it to a sync system, where other modules can actually use

01:13.000 --> 01:16.000
the outputs from these modules.

01:16.000 --> 01:19.000
An example of that would be the code for example,

01:19.000 --> 01:24.000
it can redirect you from an audio stream.

01:25.000 --> 01:30.000
So, I'm going to go through each of the steps

01:30.000 --> 01:33.000
that you saw in the log diagram of the software,

01:33.000 --> 01:36.000
and the first of that is resource,

01:36.000 --> 01:39.000
and most importantly, the device handling.

01:39.000 --> 01:42.000
Over the years, there has been two common implementations,

01:42.000 --> 01:45.000
which are either a full abstraction,

01:45.000 --> 01:49.000
or a very basic abstraction, where all the software

01:49.000 --> 01:53.000
moves to do is start, stop, and tune the radio.

01:53.000 --> 01:57.000
The full abstraction has mostly been done

01:57.000 --> 02:00.000
through a library called SOPSDR,

02:00.000 --> 02:05.000
which you can see in the list pretty much everything uses,

02:05.000 --> 02:08.000
because it just makes, as yard development easy.

02:08.000 --> 02:10.000
You don't need to have all the hardware,

02:10.000 --> 02:14.000
and implement everything native you yourself.

02:14.000 --> 02:17.000
But the downside of that is that it's some hardware

02:17.000 --> 02:20.000
that can be quite challenging to implement in that way.

02:20.000 --> 02:25.000
For example, you can have SGRs like the SGR plays,

02:25.000 --> 02:27.000
which have different signal paths,

02:27.000 --> 02:29.000
which will have different gains.

02:29.000 --> 02:31.000
So if you change some setting,

02:31.000 --> 02:33.000
it can affect other setting,

02:33.000 --> 02:37.000
and that's usually very hard to represent in a full abstraction scheme.

02:37.000 --> 02:40.000
Then you have the basic abstraction with GUI,

02:40.000 --> 02:45.000
which is one of the earliest ways of doing device abstractions in SGR.

02:45.000 --> 02:48.000
And more specifically, it's the external standard,

02:48.000 --> 02:51.000
which was introduced by the WinRat software in 2006,

02:51.000 --> 02:56.000
and then continues to be used by HGSDRs in 2009.

02:56.000 --> 02:59.000
But the issue with the standard is that it's Win32 only,

02:59.000 --> 03:02.000
and by Win32, I don't just mean Windows.

03:02.000 --> 03:04.000
I actually mean 32 bit Windows.

03:04.000 --> 03:07.000
So you miss out on quite a lot of performance,

03:07.000 --> 03:09.000
which is unacceptable.

03:09.000 --> 03:12.000
And so SGR sharp, which was introduced in 2012,

03:12.000 --> 03:15.000
uses its own software-specific API for it.

03:15.000 --> 03:17.000
So does SGR in general,

03:17.000 --> 03:20.000
and obviously, so does SGR++.

03:20.000 --> 03:24.000
So obviously, when you try to implement everything yourself

03:24.000 --> 03:28.000
without the standard, you accumulate quite a lot of hardware,

03:28.000 --> 03:31.000
and that's what it takes if you want to support everything,

03:31.000 --> 03:34.000
and make sure everything is actually stable and working.

03:34.000 --> 03:39.000
So yeah, they get ready to have quite a lot of space

03:39.000 --> 03:41.000
taken up by SGR hardware.

03:41.000 --> 03:44.000
So where it's specifically in SGR++,

03:44.000 --> 03:46.000
it's through what's called source modules.

03:46.000 --> 03:49.000
They have to implement some functions.

03:49.000 --> 03:51.000
Some of the mandatory ones are obviously

03:51.000 --> 03:54.000
start, stop, and sample stream.

03:54.000 --> 03:58.000
And optionally, they can implement the tune function.

03:58.000 --> 04:01.000
An example of a module that wouldn't need a tune function

04:01.000 --> 04:05.000
is a file player, because obviously you can't tune a pre-recorded file.

04:05.000 --> 04:07.000
It can also display a menu.

04:07.000 --> 04:10.000
This is required for pretty much all of them.

04:10.000 --> 04:12.000
So technically, you don't need it.

04:12.000 --> 04:15.000
Then there's select and deselect with just allows

04:15.000 --> 04:18.000
to, for example, close device driver

04:18.000 --> 04:23.000
to avoid hoarding control of hardware for no reason.

04:23.000 --> 04:28.000
Obviously, sometimes you need to use SGR hardware remotely.

04:28.000 --> 04:32.000
For example, if you have an antenna outdoors,

04:32.000 --> 04:35.000
you can't run a 30-meter length of coax.

04:35.000 --> 04:38.000
So sometimes it's easier to just put a Raspberry PiR or something,

04:38.000 --> 04:40.000
and run the data through Ethernet.

04:40.000 --> 04:43.000
And so that's why SGR++ server was created.

04:43.000 --> 04:47.000
It allows for use source modules remotely.

04:47.000 --> 04:49.000
For that, it takes a sample stream,

04:49.000 --> 04:51.000
and does compression on it.

04:51.000 --> 04:53.000
There's actually two types of compression,

04:53.000 --> 04:55.000
whether SGR++ server does.

04:55.000 --> 04:58.000
It does both lossless compression

04:58.000 --> 05:03.000
with the ZSTD compression library.

05:03.000 --> 05:05.000
And also, cycling lossy standard,

05:05.000 --> 05:07.000
which is dynamic range compression,

05:08.000 --> 05:11.000
where it's dynamically scales the data

05:11.000 --> 05:15.000
to fit in lower bit depth samples.

05:15.000 --> 05:19.000
Obviously, since this uses GIOi,

05:19.000 --> 05:21.000
it needs a GIOi server.

05:21.000 --> 05:23.000
And as you are plus plus,

05:23.000 --> 05:26.000
it's emulates the GIOi library

05:26.000 --> 05:28.000
that's as you are plus plus uses,

05:28.000 --> 05:29.000
which is IMGIOi.

05:29.000 --> 05:33.000
And so it's manages to forward the GIOi elements.

05:33.000 --> 05:36.000
You can kind of think of it as a binary HTML,

05:36.000 --> 05:38.000
but a bit more efficient than that,

05:38.000 --> 05:42.000
so that it can display any menu remotely to the clients.

05:42.000 --> 05:44.000
And on the client site, obviously,

05:44.000 --> 05:46.000
it does the exact top of it,

05:46.000 --> 05:49.000
and the SGR++ server client is implemented

05:49.000 --> 05:53.000
just as any source module in SGR++,

05:53.000 --> 05:57.000
which is pretty easy to implement,

05:57.000 --> 06:00.000
pretty much anything with this architecture.

06:00.000 --> 06:03.000
Now let's get into more

06:03.000 --> 06:06.000
how the digital signal processing is done.

06:06.000 --> 06:10.000
The first very important objects are streams.

06:10.000 --> 06:13.000
They encapsulate two buffers,

06:13.000 --> 06:17.000
and some signaling and input output functions.

06:17.000 --> 06:20.000
The way data is moved around the software

06:20.000 --> 06:22.000
is by GIOi copy buffers,

06:22.000 --> 06:25.000
so simply writing thread rights to a buffer.

06:25.000 --> 06:26.000
And then when it's ready,

06:26.000 --> 06:30.000
it tells the stream to swap the buffers

06:30.000 --> 06:33.000
and then the reader can read the buffer.

06:33.000 --> 06:36.000
And that avoids the performance sources

06:36.000 --> 06:39.000
and countered with ring buffers,

06:39.000 --> 06:41.000
that are used in things like GIOi,

06:41.000 --> 06:43.000
and other frameworks.

06:43.000 --> 06:45.000
So here I've put kind of a function that are needed.

06:45.000 --> 06:48.000
We've got obviously read and to read samples

06:48.000 --> 06:50.000
and swap to write them.

06:50.000 --> 06:53.000
But there's also flash to signal

06:53.000 --> 06:57.000
that the reading thread is done processing the samples.

06:58.000 --> 07:02.000
And then since the processing is done multiple threads,

07:02.000 --> 07:05.000
there's the stop reader and stop writer functions,

07:05.000 --> 07:09.000
which allows to signal to processing threads

07:09.000 --> 07:12.000
because we are blocking on read or swap,

07:12.000 --> 07:14.000
that they need to stop what we're doing.

07:14.000 --> 07:20.000
Next the other important signal processing block is blocks.

07:20.000 --> 07:24.000
They encapsulate a worker thread process function

07:25.000 --> 07:27.000
and manage that specific threads.

07:27.000 --> 07:31.000
And the streams that are used by the block,

07:31.000 --> 07:33.000
then you have hierarchial blocks,

07:33.000 --> 07:36.000
which are simply multiple blocks that can be connected

07:36.000 --> 07:39.000
in any way inside of it.

07:39.000 --> 07:42.000
And then you've got a special kind of hierarchial block,

07:42.000 --> 07:44.000
which are chains,

07:44.000 --> 07:50.000
which allow to bypass any number of blocks within them.

07:50.000 --> 07:53.000
The only limitation is that all the blocks

07:53.000 --> 07:55.000
have the same input and output types.

07:55.000 --> 07:57.000
And so that's going to be used,

07:57.000 --> 08:01.000
for example, in the pre-processing section

08:01.000 --> 08:03.000
of the processing chain,

08:03.000 --> 08:07.000
where it first starts with the decimation,

08:07.000 --> 08:09.000
which is only power of two,

08:09.000 --> 08:11.000
then the optional spectrum inversion

08:11.000 --> 08:14.000
and then the IQ correction.

08:14.000 --> 08:18.000
And so instead of using a hierarchical block,

08:18.000 --> 08:22.000
this is actually currently done in a single thread,

08:22.000 --> 08:26.000
which kind of limits the maximum sample rate

08:26.000 --> 08:27.000
you can use,

08:27.000 --> 08:31.000
but does increase the efficiency,

08:31.000 --> 08:34.000
which is quite important.

08:34.000 --> 08:36.000
Next we have channelization,

08:36.000 --> 08:38.000
again, single thread.

08:38.000 --> 08:41.000
The first step in, in,

08:41.000 --> 08:44.000
sorry, channelization is frequency shifting,

08:44.000 --> 08:47.000
the raw IQ down to DC,

08:47.000 --> 08:51.000
so you shifted by the offset of your signal,

08:51.000 --> 08:53.000
then you need to resample it.

08:53.000 --> 08:54.000
This is done in two steps.

08:54.000 --> 08:56.000
We first have a power of two decimation,

08:56.000 --> 08:59.000
which is implemented quite efficiently

08:59.000 --> 09:06.000
in SGR++ using pre-planned decimation plans,

09:06.000 --> 09:11.000
which allow to have the most efficient possible combination of tabs.

09:11.000 --> 09:15.000
It's not just a series of half-band filters.

09:15.000 --> 09:17.000
It's much more advanced than that.

09:17.000 --> 09:20.000
And then to take up the rest of the resampling,

09:20.000 --> 09:23.000
there's just a standard polyphase resampler,

09:23.000 --> 09:25.000
and at the end,

09:25.000 --> 09:29.000
since the sample rate that the module expects

09:29.000 --> 09:31.000
is usually not equal to a bandwidth.

09:31.000 --> 09:35.000
There's an additional filter to filter down the signal

09:35.000 --> 09:38.000
to the bandwidth that the module desires.

09:38.000 --> 09:43.000
And this has quite high performance.

09:43.000 --> 09:45.000
It achieves an out-of-band attenuation

09:45.000 --> 09:50.000
of over 100 dBs, which is quite good compared to other software.

09:50.000 --> 09:53.000
I just noticed my microphone fell off.

09:53.000 --> 09:55.000
Sorry.

09:55.000 --> 09:58.000
Well, I guess I'll just do that.

09:58.000 --> 10:01.000
So, yeah, next.

10:01.000 --> 10:03.000
Sorry.

10:03.000 --> 10:05.000
Yeah, so next, there are the modules,

10:05.000 --> 10:10.000
and this is implemented with dynamic libraries.

10:10.000 --> 10:13.000
So this could be GLLs on Windows,

10:13.000 --> 10:17.000
or SO on Linux, die-lib on macOS.

10:17.000 --> 10:21.000
And so they simply have to implement some functions.

10:21.000 --> 10:24.000
The most important and mandatory one are

10:24.000 --> 10:26.000
create instance and delete instance.

10:26.000 --> 10:28.000
These are the functions that will create

10:28.000 --> 10:31.000
the module instance class.

10:31.000 --> 10:34.000
And it also has an info struct,

10:34.000 --> 10:36.000
which stuff like the module offer,

10:36.000 --> 10:39.000
the module version, the module name,

10:39.000 --> 10:41.000
and a lot of stuff like that,

10:41.000 --> 10:43.000
is pretty useful to display to a user.

10:43.000 --> 10:45.000
And then we have the optional init and end.

10:45.000 --> 10:47.000
This can be used, for example.

10:47.000 --> 10:49.000
Again, if you have a device driver

10:49.000 --> 10:52.000
to initialize it or terminate it.

10:52.000 --> 10:54.000
And the way this works,

10:54.000 --> 10:59.000
instead of using an API, a fixed API,

10:59.000 --> 11:03.000
the SGR++ Core is actually its own dynamic library.

11:03.000 --> 11:06.000
And so what happens is that the module can simply link to it

11:06.000 --> 11:08.000
any library and then they load it.

11:08.000 --> 11:12.000
They link themselves to the Core, which is pretty handy.

11:12.000 --> 11:15.000
Obviously this means that the API compatibility

11:15.000 --> 11:17.000
can easily be broken.

11:17.000 --> 11:21.000
So updates to the Core have to be done carefully.

11:21.000 --> 11:23.000
But it means that for example,

11:23.000 --> 11:26.000
you can write some code in VSGR++ code

11:26.000 --> 11:29.000
and then copy-paste it with no changes to a module

11:29.000 --> 11:31.000
and it will still work perfectly.

11:31.000 --> 11:32.000
And that's shown here.

11:32.000 --> 11:34.000
What the module assesses,

11:34.000 --> 11:37.000
it's simply a class with a constructor,

11:37.000 --> 11:40.000
which is given a name that the user gets to type in,

11:40.000 --> 11:42.000
a structure, obviously,

11:42.000 --> 11:45.000
a post-init function that is called when

11:45.000 --> 11:48.000
every module has been loaded,

11:48.000 --> 11:50.000
which can be useful, for example,

11:50.000 --> 11:55.000
if a module wants to load the output stream of another one,

11:55.000 --> 11:59.000
it's going to have to wait for that module to be loaded,

11:59.000 --> 12:01.000
then there's enable and disable,

12:01.000 --> 12:02.000
which I'll show in the demo,

12:02.000 --> 12:06.000
which it just signals the module that the user

12:06.000 --> 12:08.000
decides to disable the module.

12:08.000 --> 12:12.000
This has an effect that depends exactly on the module.

12:12.000 --> 12:14.000
For example, for the radio,

12:14.000 --> 12:17.000
it just deletes the VFO and stops the DSP.

12:17.000 --> 12:21.000
So in order to just save on processing power.

12:21.000 --> 12:23.000
And obviously there's an enabled load function

12:23.000 --> 12:26.000
to query the states.

12:26.000 --> 12:29.000
Next, the last part of the DSP are

12:29.000 --> 12:34.000
sinks, which take the audio that modules output

12:34.000 --> 12:37.000
and do something with it.

12:37.000 --> 12:41.000
And since there can be any number of sinks,

12:41.000 --> 12:44.000
there's something called providers,

12:44.000 --> 12:46.000
which is a silly name to just say,

12:46.000 --> 12:49.000
like factories in object oriented programming.

12:49.000 --> 12:52.000
They're just in charge of creating and deleting

12:52.000 --> 12:57.000
the instances of each sink for each module.

12:57.000 --> 13:00.000
They register themselves to the sink manager,

13:00.000 --> 13:03.000
which just manages the assets name

13:03.000 --> 13:06.000
indicate to the sinks and the audio streams.

13:06.000 --> 13:13.000
So yeah, and you create exactly one stream,

13:13.000 --> 13:16.000
one sinks per audio stream.

13:16.000 --> 13:20.000
It has been requested to actually have multiple sinks per stream,

13:20.000 --> 13:21.000
which can be useful.

13:21.000 --> 13:25.000
For example, if you want to listen to audio

13:25.000 --> 13:28.000
from a digital signal, because you want to check

13:28.000 --> 13:31.000
what the quality is like, but you also want to send it

13:31.000 --> 13:33.000
to an external decoder.

13:33.000 --> 13:35.000
It can be useful to have two sinks.

13:35.000 --> 13:36.000
And that's not true.

13:36.000 --> 13:40.000
It's impossible with this scheme, but it will be in the future.

13:40.000 --> 13:45.000
And the sink instances themselves are abstracted very similarly

13:45.000 --> 13:48.000
to how sources are done.

13:48.000 --> 13:51.000
It's also just mandatory functions, which

13:51.000 --> 13:53.000
starts up and the sample stream.

13:53.000 --> 13:56.000
And then, optionally, the sink can display your menu.

13:56.000 --> 13:58.000
I say optionally, because, for example,

13:58.000 --> 14:01.000
we enjoyed the sink on Android.

14:01.000 --> 14:03.000
It doesn't actually have any setting,

14:03.000 --> 14:06.000
because it's quite annoying to query what

14:06.000 --> 14:09.000
sample rate you can use and what device you can output.

14:09.000 --> 14:11.000
So at the moment, it literally doesn't

14:11.000 --> 14:13.000
implement the menu function.

14:13.000 --> 14:16.000
All right, so now let's do a demo.

14:16.000 --> 14:18.000
And hopefully, it doesn't crash.

14:18.000 --> 14:26.000
All right.

14:26.000 --> 14:29.000
So this is VCR++ software.

14:29.000 --> 14:33.000
It's a version that's a few months old, actually.

14:33.000 --> 14:35.000
But it's just what I run on this PC.

14:35.000 --> 14:38.000
And nothing really new has been added.

14:38.000 --> 14:41.000
Here you can see your SGR device, which is

14:41.000 --> 14:43.000
represented in source menu.

14:43.000 --> 14:46.000
You can choose which device type you want.

14:46.000 --> 14:49.000
Here, obviously, I have selected RGLs.

14:49.000 --> 14:52.000
Because that's what's on my PC.

14:52.000 --> 14:54.000
That's very pretty much anything you've ever

14:54.000 --> 14:56.000
want, air spy, radar, attack, RF.

14:56.000 --> 14:58.000
Probably heard of all these.

14:58.000 --> 15:01.000
Some lesser known one, like for Perseus, which is

15:01.000 --> 15:02.000
kind of old.

15:02.000 --> 15:05.000
But the important thing to see is that you've got

15:05.000 --> 15:08.000
all you're setting that are tailored exactly

15:08.000 --> 15:09.000
to the device.

15:09.000 --> 15:11.000
You don't have some weird abstractions where

15:12.000 --> 15:17.000
sometimes you'll have multiple signal paths

15:17.000 --> 15:20.000
inside the SGR that are represented by antenna

15:20.000 --> 15:21.000
ports, which doesn't make sense.

15:21.000 --> 15:23.000
I don't have an SGR that's in.

15:23.000 --> 15:25.000
Demonstrate that here.

15:25.000 --> 15:28.000
But yeah, and you can see that the module just

15:28.000 --> 15:30.000
implements its GUI here.

15:30.000 --> 15:32.000
It goes down to here.

15:32.000 --> 15:35.000
And after that, that's the same for every module.

15:35.000 --> 15:38.000
So if I was to select something like air spy,

15:38.000 --> 15:40.000
you'll see you'll still have the IQ

15:40.000 --> 15:43.000
correction and inverse IQ and all the stuff.

15:43.000 --> 15:45.000
So that's what source.

15:45.000 --> 15:47.000
And so I'll select my RGLs.

15:47.000 --> 15:52.000
And now I can start it and go to somewhere where

15:52.000 --> 15:55.000
we're sure to see some stuff.

15:55.000 --> 15:58.000
And obviously, we don't see anything.

15:58.000 --> 16:01.000
Because, not very good.

16:01.000 --> 16:05.000
Okay, here's lonely FM signal.

16:06.000 --> 16:10.000
And so I can just pick white band of FM selected

16:10.000 --> 16:12.000
and receive the signal.

16:12.000 --> 16:14.000
And obviously, it's a copy.

16:14.000 --> 16:19.000
So let me just, all right.

16:19.000 --> 16:22.000
So yeah, now we're receiving the FM signal.

16:22.000 --> 16:25.000
And so we can go down to a radio module.

16:25.000 --> 16:27.000
And as I said, it's a module.

16:27.000 --> 16:29.000
It's not actually implemented in records.

16:29.000 --> 16:31.000
It's own kind of plugin.

16:31.000 --> 16:36.000
And it's modeled after the same layout

16:36.000 --> 16:38.000
as your sharps.

16:38.000 --> 16:40.000
So you have your mode selector here.

16:40.000 --> 16:43.000
The band width, which you can adjust either by

16:43.000 --> 16:45.000
drag and dropping like this.

16:45.000 --> 16:48.000
Or just typing in directly.

16:48.000 --> 16:51.000
Then you've got the emphasis, which for your option

16:51.000 --> 16:53.000
be set to 50, but it doesn't matter.

16:53.000 --> 16:55.000
Vend some other options.

16:55.000 --> 16:57.000
I can be going or disabling stereo,

16:57.000 --> 17:00.000
which for broadcast FM obviously you will even on.

17:00.000 --> 17:03.000
That's a lot of interesting stuff.

17:03.000 --> 17:05.000
But not really the subject of the stock.

17:05.000 --> 17:08.000
Then you have another module, which is where we

17:08.000 --> 17:11.000
quarter, and this is what makes use of binding directly

17:11.000 --> 17:12.000
to the IQ stream.

17:12.000 --> 17:15.000
Or binding to the output of a module.

17:15.000 --> 17:17.000
So here we have the radio module.

17:17.000 --> 17:20.000
And you can actually select its audio stream here.

17:20.000 --> 17:24.000
And that's what will be recorded if I press record here.

17:24.000 --> 17:27.000
It's just going to record the audio from the station.

17:27.000 --> 17:31.000
Or I can put it in base band mode, and where it will just

17:31.000 --> 17:34.000
record the raw IQ from the SDR.

17:34.000 --> 17:36.000
And yeah, that's cool.

17:36.000 --> 17:37.000
It works.

17:37.000 --> 17:40.000
So next, that's another module.

17:40.000 --> 17:43.000
You can have some that don't actually use any DSP.

17:43.000 --> 17:46.000
And that's the case of a frequency manager,

17:46.000 --> 17:50.000
which is just a useful module to display some bookmarks here.

17:50.000 --> 17:54.000
So here I have the ones for the radio station back in the

17:54.000 --> 17:55.000
station.

17:55.000 --> 17:57.000
So obviously we're not receiving them here.

17:57.000 --> 18:00.000
But if I were in the edge, we'd see a signal there.

18:00.000 --> 18:01.000
And I can just click on it.

18:01.000 --> 18:05.000
And it's automatically sets of parameters for it.

18:05.000 --> 18:09.000
And here you can add some, for example, if I were here.

18:09.000 --> 18:12.000
I can just click add, name it, set of parameters.

18:12.000 --> 18:13.000
I want some stuff like that.

18:13.000 --> 18:15.000
And that just doesn't use any DSP.

18:15.000 --> 18:18.000
It's just a utility module that creates menu.

18:18.000 --> 18:19.000
And that's about it.

18:19.000 --> 18:25.000
Then just some miscellaneous settings.

18:25.000 --> 18:28.000
And yeah, and now we arrived at the sync menu, which was what I was

18:28.000 --> 18:31.000
talking about, at the end.

18:31.000 --> 18:34.000
So here we have a radio that is currently

18:34.000 --> 18:36.000
demodulating some FM.

18:36.000 --> 18:41.000
And you can see that I can select multiple types of things.

18:41.000 --> 18:43.000
We have non-vatches just a null sync.

18:43.000 --> 18:45.000
It doesn't go anywhere.

18:45.000 --> 18:46.000
It's not really useful.

18:46.000 --> 18:48.000
But if you don't want to have audio from something,

18:48.000 --> 18:52.000
then you've got audio, which is just your sound card.

18:52.000 --> 18:59.000
Next, you have network, which just allows you to output the audio samples

18:59.000 --> 19:01.000
to a network socket.

19:01.000 --> 19:03.000
You can do it with your UDP or TCP.

19:03.000 --> 19:06.000
And set the sample rate you wanted that.

19:06.000 --> 19:07.000
And that's about it.

19:07.000 --> 19:10.000
You just got the new audio stuff, just something I'm working on,

19:10.000 --> 19:13.000
which isn't really important right now.

19:13.000 --> 19:17.000
Obviously, theme, I put it on dark to not burn your readiness.

19:17.000 --> 19:21.000
But if somehow you enjoy it, you can also set it to that.

19:21.000 --> 19:26.000
But I will judge you.

19:26.000 --> 19:30.000
So yeah, and now the module manager, which is kind of the main feature

19:30.000 --> 19:36.000
of SDR++, is let's say I want just to decode something else.

19:36.000 --> 19:42.000
Let's say my antenna was better, and I was actually receiving more than a single station,

19:42.000 --> 19:44.000
which I mean, okay, yeah.

19:44.000 --> 19:46.000
I was sure it should be a few more.

19:46.000 --> 19:49.000
So let's try to just add another radio.

19:49.000 --> 19:53.000
We can just select radio here at the bottom and type in the name.

19:53.000 --> 19:57.000
I'm just going to say radio 2.

19:57.000 --> 20:01.000
Click plus, and now we can see a new VFO has appeared.

20:01.000 --> 20:05.000
And so I can just stick it on that signal and go grab the menu,

20:05.000 --> 20:09.000
which by the way, if you've used SDR++ before,

20:09.000 --> 20:13.000
but you don't know about it, you can just drag and drop menus like this.

20:14.000 --> 20:19.000
I'm not going to bother bringing up to the top because I'm a trackpad and it's a bit annoying.

20:19.000 --> 20:26.000
But yeah, you've got a completely separate FMD modulator here that works on this station.

20:26.000 --> 20:29.000
And you can then route the audio differently.

20:29.000 --> 20:33.000
So here I would have this one on the network, this one I could send to audio.

20:33.000 --> 20:37.000
It's we just up to you what you want to do with it.

20:37.000 --> 20:44.000
And now let's say I don't want it anymore, I can just click minus and it goes away.

20:44.000 --> 20:50.000
Now let's talk about the enable and disable thing I was talking about in the module section.

20:50.000 --> 20:56.000
You'll notice that unlike other menus, the radio just shows a checkbox here.

20:56.000 --> 21:02.000
And what's that useful for is if you click it, there's no more VFO, the DSP is completely stopped.

21:02.000 --> 21:09.000
And that just allows you to disable the module without deleting its completely, which can be annoying,

21:09.000 --> 21:12.000
because you just have to recreate it the next time you want to use it.

21:12.000 --> 21:17.000
Here you just click the checkbox and you've got your module again.

21:17.000 --> 21:24.000
I really often use it just for example, if I use VM70 module, which is a feature of SDR++.

21:24.000 --> 21:29.000
If I have it installed on this one, yes, I do.

21:29.000 --> 21:45.000
And if I had edit, now magically I just have a new demodulator right here, which I can set hopefully someone can say something on M17.

21:45.000 --> 21:49.000
Here we go.

21:49.000 --> 21:55.000
That's the frequency that the amateur radio booth uses for the M17 simplex.

21:55.000 --> 22:04.000
And so I can go down here and look at the M17 menu, which just, I don't know if anyone has a M17 radio here.

22:04.000 --> 22:05.000
Okay.

22:05.000 --> 22:06.000
Yeah.

22:06.000 --> 22:10.000
Well, yes, if anyone has an M17 radio, they can try saying something.

22:10.000 --> 22:15.000
I'll just drop again because it's going to, it's going to just die.

22:15.000 --> 22:24.000
So if you just say something and, well, I'll just grab mine if I can find it.

22:24.000 --> 22:30.000
All right, I've got mine.

22:30.000 --> 22:35.000
Or you can just, yeah.

22:35.000 --> 22:40.000
So I'm just going to transmit forward for the free.

22:40.000 --> 22:42.000
Just go to type of frequency.

22:42.000 --> 22:45.000
Okay.

22:45.000 --> 22:46.000
Put it to one watts.

22:46.000 --> 22:49.000
And so, yeah, that's what I thought.

22:49.000 --> 23:00.000
I'm going to remove the antenna because it's going to overload instantly at such a short range.

23:00.000 --> 23:01.000
All right.

23:01.000 --> 23:06.000
And so now if I transmit here, and I'm on SM, that's it.

23:06.000 --> 23:10.000
Okay.

23:10.000 --> 23:15.000
All right, just got to fix the frequency because this radio is a tiny bit broken.

23:15.000 --> 23:16.000
Okay.

23:16.000 --> 23:19.000
And here we're receiving actually my M17 signal.

23:19.000 --> 23:26.000
And so you can see it shows my, my call sign, the broadcast tab, the data type and everything.

23:26.000 --> 23:33.000
And that's used quite a lot by the M17 team to actually test radios and make sure of your

23:33.000 --> 23:35.000
compliance.

23:35.000 --> 23:40.000
And so, yeah, you can, if you're done using it, just click the checkbox and it's gone.

23:40.000 --> 23:44.000
You don't have to think about it and you can just reenable it the next time.

23:44.000 --> 23:48.000
And so, yeah, I think that was a tour of Asia++.

23:48.000 --> 23:54.000
I would have lots to show the server features, but the Wi-Fi here is completely overloaded.

23:54.000 --> 24:01.000
So, I literally can't even load emails, so it's not going to do IQ over internet.

24:01.000 --> 24:07.000
So, yeah, I think, I think this part of the demo is done.

24:07.000 --> 24:10.000
Let's go back to the slide.

24:10.000 --> 24:18.000
All right, so a future.

24:18.000 --> 24:24.000
So, the first thing I want to talk about is things that won't change, because there are things

24:24.000 --> 24:29.000
that from feedback I've heard were done right, which was the layout, which again was just stolen from

24:29.000 --> 24:30.000
SDR sharps.

24:30.000 --> 24:32.000
So, it makes sense, but it was decent.

24:32.000 --> 24:38.000
General workflow of how things work with software, the OS support and the hardware support.

24:38.000 --> 24:42.000
The hardware support, especially, is nice, because you used to be locked into

24:42.000 --> 24:46.000
ecosystems with SDR sharps, which only allowed its own SDRs.

24:46.000 --> 24:51.000
And then cut off support for others, which wasn't really nice.

24:51.000 --> 24:53.000
And I don't think that's cool.

24:53.000 --> 24:58.000
So, I'll always support any hardware that manufactures one supported, or they want to

24:58.000 --> 25:03.000
add support themselves, they can do it to its no difference.

25:03.000 --> 25:05.000
That's what will change.

25:05.000 --> 25:13.000
First, the GUI, which is done with the library called DRAM GUI, will be replaced with a custom GUI library.

25:13.000 --> 25:20.000
Obviously, people would say, well, why not use QT, why not use WX, why not use insert name here?

25:20.000 --> 25:25.000
Well, because they're all trying to be frameworks and not library.

25:25.000 --> 25:32.000
And so, you end up having to write hundreds of lines of boilerplate for any silly little thing.

25:32.000 --> 25:33.000
And I don't like that.

25:33.000 --> 25:38.000
And so, I decided to write my own custom GUI library, which is, it's not done yet.

25:38.000 --> 25:43.000
It's going to take a bit longer, but I hope to introduce its soon.

25:43.000 --> 25:50.000
Next, as you're a++, we'll move from being single input multiple output to multiple input multiple outputs.

25:50.000 --> 25:57.000
And what I mean by that is, it will both be able to use SDRs with multiple channels, like the blade or F,

25:57.000 --> 26:05.000
that was shown by Sebastian and the previous talk, or use multiple SDRs at once,

26:05.000 --> 26:09.000
and then move the Fos between them seamlessly.

26:09.000 --> 26:17.000
I'll also go from being received only to being received and transmit.

26:17.000 --> 26:21.000
Transly we aren't really good open source options for transmit.

26:21.000 --> 26:28.000
They either don't have great hardware supports, or are really unstable, as your angel.

26:28.000 --> 26:30.000
Sorry.

26:30.000 --> 26:36.000
I had to use it for Q100, and yeah, it's really motivated me to implement transmit and try to do it.

26:36.000 --> 26:40.000
In a way that's user-friendly and pretty stable.

26:40.000 --> 26:46.000
And also, the DSP library is going to be completely rewritten, because as I said at the beginning,

26:46.000 --> 26:52.000
I just did it during COVID for fun, and the structure didn't end up being really optimal.

26:52.000 --> 26:59.000
But now with four years of trial and error, I think it can be rewritten in a way that's a lot more efficient.

26:59.000 --> 27:06.000
And so yeah, we'll use the lessons learned from 1.0 to do SDR++ 2.0.

27:06.000 --> 27:11.000
Before ending this talk, I have to think of a Patreon supporter of the project.

27:11.000 --> 27:17.000
There are a lot more than that, but those are the ones that accepted to be in the credits.

27:17.000 --> 27:26.000
Obviously, they've been paying for some of the hardware that was needed for my food and university tuition events,

27:26.000 --> 27:30.000
so thanks a lot to them, and thanks for your attention.

27:30.000 --> 27:44.000
All right, so any questions now?

27:44.000 --> 27:45.000
Yes?

27:45.000 --> 27:51.000
Many of you already support this, or don't know if you can do this in filing, because you intend to support it,

27:51.000 --> 27:52.000
so you can see that.

27:52.000 --> 27:59.000
Okay, so the question is, do I intend to support SIGMF for FIWANT put?

27:59.000 --> 28:05.000
So I'm not sure if I'm going to support it first party, because I don't really know the format right now,

28:05.000 --> 28:13.000
and the priority is make the file player a bit better, because right now it's really happy, it hasn't changed since 2021.

28:13.000 --> 28:19.000
So the priority is first to rewrite the file player, and then maybe more formats can be added.

28:19.000 --> 28:28.000
But again, since SDR++ is modular in such a way that there's no difference between user plugins and official plugins.

28:28.000 --> 28:34.000
So anyone could write SIGMF source, and it would just show up like any other.

28:34.000 --> 28:37.000
All right, I have a question.

28:37.000 --> 28:38.000
Yes?

28:38.000 --> 28:41.000
Can you get my laptop support?

28:41.000 --> 28:44.000
Oh, so the question is, can we have macOS support?

28:44.000 --> 28:49.000
It's already supported, both on M1 and X86.

28:49.000 --> 28:55.000
Okay, I have a question, yes?

28:55.000 --> 29:00.000
Sorry, I can't.

29:00.000 --> 29:06.000
Okay, so if I have to send a question, is can SGR++ be added to home brew?

29:06.000 --> 29:11.000
Well, if someone wants to do it, sure, but I don't have a mac.

29:11.000 --> 29:14.000
All the development to support macOS was done blind.

29:14.000 --> 29:17.000
Like just trying and seeing if it builds in the C.I.

29:17.000 --> 29:22.000
And when asking people to try it out, so maybe if I get a mac,

29:23.000 --> 29:25.000
I'll be able to add support for it.

29:25.000 --> 29:29.000
But I think someone has already added it to mac ports.

29:29.000 --> 29:34.000
I think I'm not sure, but yeah, if I do get a mac at some point, I will add it.

29:34.000 --> 29:35.000
Yes?

29:35.000 --> 29:37.000
Okay, yes?

29:37.000 --> 29:51.000
Okay, so the question is why does the 90 builds

29:51.000 --> 29:54.000
says November 2022?

29:54.000 --> 29:58.000
So it's just because I'm misusing GitHub.

29:58.000 --> 30:02.000
It's not really meant to have a continuously updating release.

30:02.000 --> 30:09.000
And so it still says the date where I started doing 90 builds instead of scheduled releases.

30:09.000 --> 30:14.000
So that's not really something I can fix, but.

30:15.000 --> 30:17.000
Yes, it's really, it's 90.

30:17.000 --> 30:21.000
If you look at the date on the files, you'll see it's, it's really just one.

30:21.000 --> 30:22.000
Yeah.

30:22.000 --> 30:23.000
Okay.

30:23.000 --> 30:24.000
Other questions?

30:24.000 --> 30:25.000
Yes?

30:25.000 --> 30:27.000
I actually didn't know about the output one.

30:27.000 --> 30:29.000
So there's been some sort of discussion.

30:29.000 --> 30:32.000
What do you mean if you had any questions?

30:32.000 --> 30:37.000
I'd like to ask you a question.

30:37.000 --> 30:43.000
Okay, so the question is where any plan to add the last-less compression to recordings?

30:43.000 --> 30:44.000
Yes.

30:44.000 --> 30:54.000
We're working with another developer that also needs recording to maybe publish a new compressed format.

30:54.000 --> 30:57.000
I did try flack.

30:57.000 --> 30:59.000
I assume that's what you want.

30:59.000 --> 31:07.000
Flack does work, but for IQ, it's not really, it's a bit slow to record IQ.

31:07.000 --> 31:12.000
Like if you try to record something like a blade RF at 61 mega samples per second,

31:12.000 --> 31:14.000
it's not going to be able to handle it.

31:14.000 --> 31:16.000
So yeah, but it's definitely planned.

31:16.000 --> 31:18.000
It's super useful for archival.

31:18.000 --> 31:25.000
And combined with dynamic range compression, it can really help a lot to save signals and stuff.

31:25.000 --> 31:26.000
Yeah.

31:26.000 --> 31:27.000
Okay.

31:27.000 --> 31:30.000
Other questions?

31:30.000 --> 31:31.000
Yes?

31:31.000 --> 31:38.000
If I send your vector or unit and I just hope it goes as an excuse for you in the video.

31:38.000 --> 31:43.000
So let me try to understand your question.

31:43.000 --> 31:46.000
Send what for GDP.

31:46.000 --> 31:49.000
You mean through the network sync?

31:49.000 --> 31:50.000
Yeah.

31:50.000 --> 31:52.000
So yeah, you can just send them straight.

31:52.000 --> 31:54.000
So I'm going to repeat the question actually since it's recorded.

31:54.000 --> 31:59.000
So the question was, can the network sync be used to output to GNU radio?

31:59.000 --> 32:01.000
Yes, absolutely.

32:01.000 --> 32:02.000
But it depends what you want to do.

32:02.000 --> 32:06.000
If you want to send audio to GNU radio, yes, just use the network sync.

32:06.000 --> 32:10.000
But there's actually a better way to do it.

32:10.000 --> 32:14.000
I don't know if I have it installed in this one.

32:14.000 --> 32:19.000
It's the IQ-Exporter module, which, okay, I have right here.

32:19.000 --> 32:32.000
And if you add it, right here, it will give you a menu where you can choose to either export the full base band from VSDR.

32:32.000 --> 32:37.000
Or you can output a VFO and now it spawns a VFO, which you can drag around.

32:37.000 --> 32:41.000
And sorry, wrong menu.

32:41.000 --> 32:44.000
This one, you can set which sample rate you want.

32:44.000 --> 32:47.000
You can set if it's TCP server.

32:47.000 --> 32:49.000
It's pcln to dp.

32:49.000 --> 32:51.000
The size, the sample type and everything.

32:51.000 --> 32:54.000
And this will substrate to GNU radio.

32:54.000 --> 32:55.000
Okay.

32:55.000 --> 32:57.000
Two people.

32:57.000 --> 32:58.000
I guess.

32:58.000 --> 32:59.000
Yes?

32:59.000 --> 33:00.000
Yes.

33:00.000 --> 33:01.000
Yes.

33:01.000 --> 33:02.000
Yes.

33:02.000 --> 33:15.000
So question is, will it also support to re-consume to IQ data, so if I record a data, can I read the whole chat?

33:15.000 --> 33:16.000
Yes.

33:16.000 --> 33:18.000
So the question is will transmit support?

33:18.000 --> 33:20.000
So what's re-transmitting IQ?

33:20.000 --> 33:21.000
Yes.

33:21.000 --> 33:28.000
It will just allow you to send IQ to VSDR or send, have a transmit VFO to send some stuff.

33:28.000 --> 33:31.000
Modules can do pretty much what they want.

33:31.000 --> 33:35.000
You have to think of VSDR plus plus more as a framework than software.

33:35.000 --> 33:39.000
And it has to let modules do whatever they want with hardware.

33:39.000 --> 33:40.000
Yes.

33:40.000 --> 33:41.000
So yes.

33:41.000 --> 33:42.000
It will work.

33:42.000 --> 33:43.000
Yes.

33:43.000 --> 33:44.000
And I think.

33:44.000 --> 33:51.000
The question to this feature of sending IQ can be sent to multiple.

33:51.000 --> 33:55.000
With UDP, you can use UDP broadcast.

33:55.000 --> 33:56.000
Yes.

33:56.000 --> 33:57.000
No.

33:57.000 --> 34:00.000
I mean, to intents, essentially, multiple IQ reports.

34:00.000 --> 34:01.000
Oh, yes.

34:01.000 --> 34:02.000
Yeah.

34:02.000 --> 34:03.000
It's.

34:03.000 --> 34:04.000
Yeah.

34:04.000 --> 34:07.000
Like if I just say.

34:07.000 --> 34:09.000
So I assume that's what you mean.

34:09.000 --> 34:10.000
Yeah.

34:10.000 --> 34:12.000
I can just add the second IQ exporter.

34:12.000 --> 34:19.000
And if it works, I don't know why I don't see.

34:19.000 --> 34:20.000
Oh, wait.

34:20.000 --> 34:22.000
It's in based bandia.

34:22.000 --> 34:24.000
You can just add as many as you want.

34:24.000 --> 34:26.000
And it will just export all your signals.

34:26.000 --> 34:27.000
Yeah.

34:27.000 --> 34:28.000
Yes.

34:28.000 --> 34:36.000
Can you ingest or plug this in?

34:36.000 --> 34:40.000
So can you ingest IQ streams on the network?

34:40.000 --> 34:41.000
You mean?

34:41.000 --> 34:42.000
Do you want to plug this?

34:42.000 --> 34:43.000
Oh, no.

34:43.000 --> 34:44.000
No.

34:44.000 --> 34:45.000
No.

34:45.000 --> 34:46.000
No.

34:46.000 --> 34:47.000
No.

34:47.000 --> 34:48.000
No.

34:48.000 --> 34:49.000
No.

34:50.000 --> 34:53.000
It's only outputs raw samples and input raw samples.

34:53.000 --> 34:56.000
But I think, I don't know.

34:56.000 --> 35:01.000
If you want to import samples, we have a network.

35:01.000 --> 35:04.000
I think I have it on this one.

35:04.000 --> 35:05.000
No.

35:05.000 --> 35:06.000
I don't have it.

35:06.000 --> 35:07.000
Let me check.

35:07.000 --> 35:09.000
It must be here.

35:09.000 --> 35:10.000
Yeah.

35:10.000 --> 35:14.000
Networks source.

35:14.000 --> 35:15.000
No.

35:15.000 --> 35:17.000
That's kind of an example of adding a source.

35:17.000 --> 35:19.000
It's just add the module.

35:19.000 --> 35:22.000
And now magically, you just have a network source.

35:22.000 --> 35:24.000
So yeah, you can take samples.

35:24.000 --> 35:29.000
But it's only ints and flows raw things.

35:29.000 --> 35:30.000
Yes.

35:30.000 --> 35:35.000
You can use FFMPEG or any other command line, too.

35:35.000 --> 35:36.000
Okay.

35:36.000 --> 35:37.000
Other questions?

35:37.000 --> 35:38.000
Yes.

35:38.000 --> 35:41.000
The one thing you can see just the problem.

35:41.000 --> 35:46.000
By default, it's five milliseconds.

35:46.000 --> 35:51.000
It can be, basically, it depends on the size of a buffer that you send for the DSP chain.

35:51.000 --> 35:54.000
The DSP chain is pretty much instance.

35:54.000 --> 35:59.000
But if you buffer up five milliseconds, that's going to be your latency.

35:59.000 --> 36:01.000
It's pretty much, you can't hear.

36:01.000 --> 36:07.000
It's like, I've had multiple times the audio just from the radio talking into it.

36:07.000 --> 36:09.000
And listening, it's really not much.

36:09.000 --> 36:13.000
It's, of course, it's going to be worse than the hardware radio,

36:13.000 --> 36:15.000
but it's not anything crazy.

36:16.000 --> 36:17.000
Yes?

36:23.000 --> 36:25.000
Can you repeat?

36:25.000 --> 36:27.000
No, it's reduction.

36:27.000 --> 36:29.000
Yes, I plan to implement it.

36:29.000 --> 36:35.000
I just have to get it to work, because I don't want to just use a pre-made library.

36:35.000 --> 36:38.000
Everything, as we are plus plus, is written from scratch.

36:38.000 --> 36:40.000
And I want to continue that.

36:40.000 --> 36:43.000
It's a bit, so if you don't want to wait for me to do it,

36:43.000 --> 36:47.000
there are multiple people who have written modules that have noise reduction.

36:47.000 --> 36:49.000
But yes, it will be supported.

36:49.000 --> 36:53.000
Not AI, just deterministic noise reduction is.

36:53.000 --> 36:57.000
Someone has already made one.

36:57.000 --> 36:59.000
I will prompt.

37:01.000 --> 37:06.000
I will write one, but I mean, including natively, it makes no difference.

37:06.000 --> 37:10.000
If it wasn't included, the only difference is you don't need to download it.

37:10.000 --> 37:13.000
You don't need to download it.

37:13.000 --> 37:18.000
On MacOS, no, no, you should just be able to add it to you open up the bundle.

37:18.000 --> 37:23.000
Probably need to talk to the module after they might not have planned for MacOS.

37:23.000 --> 37:24.000
Okay.

37:24.000 --> 37:25.000
Yes?

37:25.000 --> 37:27.000
Yes, write it.

37:27.000 --> 37:38.000
You can just, it's power of two, but it's not, as I said, it's not just a dumb,

37:38.000 --> 37:40.000
but you have been filter.

37:40.000 --> 37:45.000
It's actually a special plan for each decimation.

37:45.000 --> 37:46.000
Yes?

37:46.000 --> 37:47.000
Okay.

37:47.000 --> 37:48.000
I have a questions.

37:48.000 --> 37:51.000
We have just four minutes left.

37:51.000 --> 37:52.000
Yes?

37:52.000 --> 37:56.000
Do you plan to have a sub-order button that wasn't helpful?

37:56.000 --> 37:58.000
I mean, what people can do?

37:58.000 --> 38:02.000
I'll only do this regular flight now.

38:02.000 --> 38:04.000
You can talk about it.

38:04.000 --> 38:05.000
Okay.

38:05.000 --> 38:13.000
So the question is, do I plan to have an official repository of modules?

38:13.000 --> 38:15.000
I've been thinking about it.

38:15.000 --> 38:20.000
The issue is vetting for security, because modules are dynamic libraries.

38:20.000 --> 38:21.000
They're not just scripts.

38:21.000 --> 38:24.000
They run raw executable code.

38:24.000 --> 38:27.000
So you have to be careful about what you install.

38:27.000 --> 38:33.000
And I'm not sure at this time I want to be responsible for the security of thousands of computers.

38:33.000 --> 38:35.000
So yeah, I will consider it.

38:35.000 --> 38:36.000
That will see.

38:36.000 --> 38:39.000
Okay.

38:39.000 --> 38:40.000
Another question?

38:40.000 --> 38:42.000
Or, yes?

38:42.000 --> 38:47.000
You say you're going to develop a new graphical interface?

38:47.000 --> 38:48.000
Yes.

38:48.000 --> 38:58.000
And are you going to make it something kind of more friendly like the icons or buttons?

38:58.000 --> 39:02.000
So not only the menu text menu.

39:02.000 --> 39:03.000
Okay.

39:03.000 --> 39:08.000
So the question is, I'm going to do a new GUI system.

39:08.000 --> 39:10.000
Not really.

39:10.000 --> 39:14.000
It's just going to be a new GUI library.

39:14.000 --> 39:17.000
But the menus you see here, nothing will change.

39:17.000 --> 39:21.000
It's just going to be a new library with the same layout.

39:21.000 --> 39:24.000
Because it's just a brand new people like it.

39:24.000 --> 39:27.000
It's copy, as I said, from SDR sharp.

39:27.000 --> 39:28.000
It's pretty intuitive.

39:28.000 --> 39:32.000
So I don't think there's much reason changing it.

39:32.000 --> 39:35.000
So yeah, it's just purely back and stuff.

39:35.000 --> 39:38.000
Users just see if we'll look a bit different, but that's about it.

39:38.000 --> 39:40.000
Okay.

39:40.000 --> 39:42.000
So yes?

39:42.000 --> 39:44.000
Can you go with the module?

39:44.000 --> 39:45.000
What do you do?

39:45.000 --> 39:48.000
What do you do?

39:48.000 --> 39:49.000
Okay.

39:49.000 --> 39:51.000
So I don't want to bore with the map.

39:51.000 --> 39:55.000
But basically, when you do decimation,

39:55.000 --> 39:59.000
it's not efficient to do it in a single stage, generally.

39:59.000 --> 40:03.000
So usually do it in multiple stages.

40:03.000 --> 40:09.000
The industry standard for a while has just been to combine half-band decimation.

40:09.000 --> 40:11.000
And just add as many as you want.

40:11.000 --> 40:17.000
But if you do the map, you can actually compute the filters

40:17.000 --> 40:23.000
for each decimation stage in such a way that you allow

40:23.000 --> 40:29.000
some signal to leak through from higher Nyquist zones into lower ones.

40:29.000 --> 40:33.000
If you know that they are going to be removed by lower stages,

40:33.000 --> 40:35.000
running at lower sample rates.

40:35.000 --> 40:39.000
And so from that, you can run an optimization algorithm,

40:39.000 --> 40:44.000
which given a yes-free ratio for SDR++, it's 95%.

40:44.000 --> 40:49.000
So that means that you're guaranteed that in the 95% of a bandwidth.

40:49.000 --> 40:57.000
You won't have any ALS over 100, well, under 100 dB, I should say.

40:57.000 --> 41:01.000
And yeah, it's numerically optimized.

41:01.000 --> 41:05.000
And if you look at the source code, you can see the plans and how they're built.

41:05.000 --> 41:10.000
I haven't published the source code of the tool that generates them

41:10.000 --> 41:14.000
because it was a collaboration with AirSpy.

41:14.000 --> 41:17.000
And they're planning to re-sacentific paper about how it works.

41:17.000 --> 41:22.000
So I don't want to be an asshole and publish very stuff before they do.

41:22.000 --> 41:26.000
But you'll probably hear about it in the future, yes.

41:26.000 --> 41:30.000
And I think someone else had a question?

41:30.000 --> 41:31.000
Yes?

41:31.000 --> 41:38.000
You can't do it to you next time.

41:38.000 --> 41:43.000
No, but I guess you can just use netcats.

41:43.000 --> 41:45.000
I guess that could be a feature.

41:45.000 --> 41:48.000
But I try to have the modules be cross-platform.

41:48.000 --> 41:53.000
And you next time obviously would be only on macOS and unix.

41:53.000 --> 41:56.000
I guess it's possible, but we'll see.

41:56.000 --> 41:58.000
Open the feature request.

41:59.000 --> 42:01.000
And I think we're out of time.

42:01.000 --> 42:02.000
Yes.

42:02.000 --> 42:03.000
We are out of time.

42:03.000 --> 42:04.000
Unfortunately.

42:04.000 --> 42:05.000
I guess.

42:05.000 --> 42:07.000
Thank you very much.

42:07.000 --> 42:19.000
If you have any other questions, just send me an email or go on the Discord server for the

42:19.000 --> 42:20.000
Atlas Plus.

42:20.000 --> 42:21.000
Yeah.

42:21.000 --> 42:22.000
Thank you.