And since then, only new features have been added.
So, this is how SGR++ works in the inside.
You first have the source, which is your SGR device or file,
or it can really be anything.
Then you've got a pre-processing step,
which just pre-process is the IQ with various algorithm that can be useful,
like decimation, for example, increase dynamic range,
or spectrum inversion, if you're receiving from,
for example, a downconverter, which has spectrum inversion,
so we can correct for it.
And the IQ correction, to correct for IQ balance and DC offset,
stuff like that.
The next step is channelization, where various signals are downconverted,
and prepared for use by each decoder, or even recorder,
or anything, any module.
And then, these modules, if they output audio,
they output it to a sync system, where other modules can actually use
the outputs from these modules.
An example of that would be the code for example,
it can redirect you from an audio stream.
So, I'm going to go through each of the steps
that you saw in the log diagram of the software,
and the first of that is resource,
and most importantly, the device handling.
Over the years, there has been two common implementations,
which are either a full abstraction,
or a very basic abstraction, where all the software
moves to do is start, stop, and tune the radio.
The full abstraction has mostly been done
through a library called SOPSDR,
which you can see in the list pretty much everything uses,
because it just makes, as yard development easy.
You don't need to have all the hardware,
and implement everything native you yourself.
But the downside of that is that it's some hardware
that can be quite challenging to implement in that way.
For example, you can have SGRs like the SGR plays,
which have different signal paths,
which will have different gains.
So if you change some setting,
it can affect other setting,
and that's usually very hard to represent in a full abstraction scheme.
Then you have the basic abstraction with GUI,
which is one of the earliest ways of doing device abstractions in SGR.
And more specifically, it's the external standard,
which was introduced by the WinRat software in 2006,
and then continues to be used by HGSDRs in 2009.
But the issue with the standard is that it's Win32 only,
and by Win32, I don't just mean Windows.
I actually mean 32 bit Windows.
So you miss out on quite a lot of performance,
which is unacceptable.
And so SGR sharp, which was introduced in 2012,
uses its own software-specific API for it.
So does SGR in general,
and obviously, so does SGR++.
So obviously, when you try to implement everything yourself
without the standard, you accumulate quite a lot of hardware,
and that's what it takes if you want to support everything,
and make sure everything is actually stable and working.
So yeah, they get ready to have quite a lot of space
taken up by SGR hardware.
So where it's specifically in SGR++,
it's through what's called source modules.
They have to implement some functions.
Some of the mandatory ones are obviously
start, stop, and sample stream.
And optionally, they can implement the tune function.
An example of a module that wouldn't need a tune function
is a file player, because obviously you can't tune a pre-recorded file.
It can also display a menu.
This is required for pretty much all of them.
So technically, you don't need it.
Then there's select and deselect with just allows
to, for example, close device driver
to avoid hoarding control of hardware for no reason.
Obviously, sometimes you need to use SGR hardware remotely.
For example, if you have an antenna outdoors,
you can't run a 30-meter length of coax.
So sometimes it's easier to just put a Raspberry PiR or something,
and run the data through Ethernet.
And so that's why SGR++ server was created.
It allows for use source modules remotely.
For that, it takes a sample stream,
and does compression on it.
There's actually two types of compression,
whether SGR++ server does.
It does both lossless compression
with the ZSTD compression library.
And also, cycling lossy standard,
which is dynamic range compression,
where it's dynamically scales the data
to fit in lower bit depth samples.
Obviously, since this uses GIOi,
it needs a GIOi server.
And as you are plus plus,
it's emulates the GIOi library
that's as you are plus plus uses,
which is IMGIOi.
And so it's manages to forward the GIOi elements.
You can kind of think of it as a binary HTML,
but a bit more efficient than that,
so that it can display any menu remotely to the clients.
And on the client site, obviously,
it does the exact top of it,
and the SGR++ server client is implemented
just as any source module in SGR++,
which is pretty easy to implement,
pretty much anything with this architecture.
Now let's get into more
how the digital signal processing is done.
The first very important objects are streams.
They encapsulate two buffers,
and some signaling and input output functions.
The way data is moved around the software
is by GIOi copy buffers,
so simply writing thread rights to a buffer.
And then when it's ready,
it tells the stream to swap the buffers
and then the reader can read the buffer.
And that avoids the performance sources
and countered with ring buffers,
that are used in things like GIOi,
and other frameworks.
So here I've put kind of a function that are needed.
We've got obviously read and to read samples
and swap to write them.
But there's also flash to signal
that the reading thread is done processing the samples.
And then since the processing is done multiple threads,
there's the stop reader and stop writer functions,
which allows to signal to processing threads
because we are blocking on read or swap,
that they need to stop what we're doing.
Next the other important signal processing block is blocks.
They encapsulate a worker thread process function
and manage that specific threads.
And the streams that are used by the block,
then you have hierarchial blocks,
which are simply multiple blocks that can be connected
in any way inside of it.
And then you've got a special kind of hierarchial block,
which are chains,
which allow to bypass any number of blocks within them.
The only limitation is that all the blocks
have the same input and output types.
And so that's going to be used,
for example, in the pre-processing section
of the processing chain,
where it first starts with the decimation,
which is only power of two,
then the optional spectrum inversion
and then the IQ correction.
And so instead of using a hierarchical block,
this is actually currently done in a single thread,
which kind of limits the maximum sample rate
you can use,
but does increase the efficiency,
which is quite important.
Next we have channelization,
again, single thread.
The first step in, in,
sorry, channelization is frequency shifting,
the raw IQ down to DC,
so you shifted by the offset of your signal,
then you need to resample it.
This is done in two steps.
We first have a power of two decimation,
which is implemented quite efficiently
in SGR++ using pre-planned decimation plans,
which allow to have the most efficient possible combination of tabs.
It's not just a series of half-band filters.
It's much more advanced than that.
And then to take up the rest of the resampling,
there's just a standard polyphase resampler,
and at the end,
since the sample rate that the module expects
is usually not equal to a bandwidth.
There's an additional filter to filter down the signal
to the bandwidth that the module desires.
And this has quite high performance.
It achieves an out-of-band attenuation
of over 100 dBs, which is quite good compared to other software.
I just noticed my microphone fell off.
Sorry.
Well, I guess I'll just do that.
So, yeah, next.
Sorry.
Yeah, so next, there are the modules,
and this is implemented with dynamic libraries.
So this could be GLLs on Windows,
or SO on Linux, die-lib on macOS.
And so they simply have to implement some functions.
The most important and mandatory one are
create instance and delete instance.
These are the functions that will create
the module instance class.
And it also has an info struct,
which stuff like the module offer,
the module version, the module name,
and a lot of stuff like that,
is pretty useful to display to a user.
And then we have the optional init and end.
This can be used, for example.
Again, if you have a device driver
to initialize it or terminate it.
And the way this works,
instead of using an API, a fixed API,
the SGR++ Core is actually its own dynamic library.
And so what happens is that the module can simply link to it
any library and then they load it.
They link themselves to the Core, which is pretty handy.
Obviously this means that the API compatibility
can easily be broken.
So updates to the Core have to be done carefully.
But it means that for example,
you can write some code in VSGR++ code
and then copy-paste it with no changes to a module
and it will still work perfectly.
And that's shown here.
What the module assesses,
it's simply a class with a constructor,
which is given a name that the user gets to type in,
a structure, obviously,
a post-init function that is called when
every module has been loaded,
which can be useful, for example,
if a module wants to load the output stream of another one,
it's going to have to wait for that module to be loaded,
then there's enable and disable,
which I'll show in the demo,
which it just signals the module that the user
decides to disable the module.
This has an effect that depends exactly on the module.
For example, for the radio,
it just deletes the VFO and stops the DSP.
So in order to just save on processing power.
And obviously there's an enabled load function
to query the states.
Next, the last part of the DSP are
sinks, which take the audio that modules output
and do something with it.
And since there can be any number of sinks,
there's something called providers,
which is a silly name to just say,
like factories in object oriented programming.
They're just in charge of creating and deleting
the instances of each sink for each module.
They register themselves to the sink manager,
which just manages the assets name
indicate to the sinks and the audio streams.
So yeah, and you create exactly one stream,
one sinks per audio stream.
It has been requested to actually have multiple sinks per stream,
which can be useful.
For example, if you want to listen to audio
from a digital signal, because you want to check
what the quality is like, but you also want to send it
to an external decoder.
It can be useful to have two sinks.
And that's not true.
It's impossible with this scheme, but it will be in the future.
And the sink instances themselves are abstracted very similarly
to how sources are done.
It's also just mandatory functions, which
starts up and the sample stream.
And then, optionally, the sink can display your menu.
I say optionally, because, for example,
we enjoyed the sink on Android.
It doesn't actually have any setting,
because it's quite annoying to query what
sample rate you can use and what device you can output.
So at the moment, it literally doesn't
implement the menu function.
All right, so now let's do a demo.
And hopefully, it doesn't crash.
All right.
So this is VCR++ software.
It's a version that's a few months old, actually.
But it's just what I run on this PC.
And nothing really new has been added.
Here you can see your SGR device, which is
represented in source menu.
You can choose which device type you want.
Here, obviously, I have selected RGLs.
Because that's what's on my PC.
That's very pretty much anything you've ever
want, air spy, radar, attack, RF.
Probably heard of all these.
Some lesser known one, like for Perseus, which is
kind of old.
But the important thing to see is that you've got
all you're setting that are tailored exactly
to the device.
You don't have some weird abstractions where
sometimes you'll have multiple signal paths
inside the SGR that are represented by antenna
ports, which doesn't make sense.
I don't have an SGR that's in.
Demonstrate that here.
But yeah, and you can see that the module just
implements its GUI here.
It goes down to here.
And after that, that's the same for every module.
So if I was to select something like air spy,
you'll see you'll still have the IQ
correction and inverse IQ and all the stuff.
So that's what source.
And so I'll select my RGLs.
And now I can start it and go to somewhere where
we're sure to see some stuff.
And obviously, we don't see anything.
Because, not very good.
Okay, here's lonely FM signal.
And so I can just pick white band of FM selected
and receive the signal.
And obviously, it's a copy.
So let me just, all right.
So yeah, now we're receiving the FM signal.
And so we can go down to a radio module.
And as I said, it's a module.
It's not actually implemented in records.
It's own kind of plugin.
And it's modeled after the same layout
as your sharps.
So you have your mode selector here.
The band width, which you can adjust either by
drag and dropping like this.
Or just typing in directly.
Then you've got the emphasis, which for your option
be set to 50, but it doesn't matter.
Vend some other options.
I can be going or disabling stereo,
which for broadcast FM obviously you will even on.
That's a lot of interesting stuff.
But not really the subject of the stock.
Then you have another module, which is where we
quarter, and this is what makes use of binding directly
to the IQ stream.
Or binding to the output of a module.
So here we have the radio module.
And you can actually select its audio stream here.
And that's what will be recorded if I press record here.
It's just going to record the audio from the station.
Or I can put it in base band mode, and where it will just
record the raw IQ from the SDR.
And yeah, that's cool.
It works.
So next, that's another module.
You can have some that don't actually use any DSP.
And that's the case of a frequency manager,
which is just a useful module to display some bookmarks here.
So here I have the ones for the radio station back in the
station.
So obviously we're not receiving them here.
But if I were in the edge, we'd see a signal there.
And I can just click on it.
And it's automatically sets of parameters for it.
And here you can add some, for example, if I were here.
I can just click add, name it, set of parameters.
I want some stuff like that.
And that just doesn't use any DSP.
It's just a utility module that creates menu.
And that's about it.
Then just some miscellaneous settings.
And yeah, and now we arrived at the sync menu, which was what I was
talking about, at the end.
So here we have a radio that is currently
demodulating some FM.
And you can see that I can select multiple types of things.
We have non-vatches just a null sync.
It doesn't go anywhere.
It's not really useful.
But if you don't want to have audio from something,
then you've got audio, which is just your sound card.
Next, you have network, which just allows you to output the audio samples
to a network socket.
You can do it with your UDP or TCP.
And set the sample rate you wanted that.
And that's about it.
You just got the new audio stuff, just something I'm working on,
which isn't really important right now.
Obviously, theme, I put it on dark to not burn your readiness.
But if somehow you enjoy it, you can also set it to that.
But I will judge you.
So yeah, and now the module manager, which is kind of the main feature
of SDR++, is let's say I want just to decode something else.
Let's say my antenna was better, and I was actually receiving more than a single station,
which I mean, okay, yeah.
I was sure it should be a few more.
So let's try to just add another radio.
We can just select radio here at the bottom and type in the name.
I'm just going to say radio 2.
Click plus, and now we can see a new VFO has appeared.
And so I can just stick it on that signal and go grab the menu,
which by the way, if you've used SDR++ before,
but you don't know about it, you can just drag and drop menus like this.
I'm not going to bother bringing up to the top because I'm a trackpad and it's a bit annoying.
But yeah, you've got a completely separate FMD modulator here that works on this station.
And you can then route the audio differently.
So here I would have this one on the network, this one I could send to audio.
It's we just up to you what you want to do with it.
And now let's say I don't want it anymore, I can just click minus and it goes away.
Now let's talk about the enable and disable thing I was talking about in the module section.
You'll notice that unlike other menus, the radio just shows a checkbox here.
And what's that useful for is if you click it, there's no more VFO, the DSP is completely stopped.
And that just allows you to disable the module without deleting its completely, which can be annoying,
because you just have to recreate it the next time you want to use it.
Here you just click the checkbox and you've got your module again.
I really often use it just for example, if I use VM70 module, which is a feature of SDR++.
If I have it installed on this one, yes, I do.
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.
Here we go.
That's the frequency that the amateur radio booth uses for the M17 simplex.
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.
Okay.
Yeah.
Well, yes, if anyone has an M17 radio, they can try saying something.
I'll just drop again because it's going to, it's going to just die.
So if you just say something and, well, I'll just grab mine if I can find it.
All right, I've got mine.
Or you can just, yeah.
So I'm just going to transmit forward for the free.
Just go to type of frequency.
Okay.
Put it to one watts.
And so, yeah, that's what I thought.
I'm going to remove the antenna because it's going to overload instantly at such a short range.
All right.
And so now if I transmit here, and I'm on SM, that's it.
Okay.
All right, just got to fix the frequency because this radio is a tiny bit broken.
Okay.
And here we're receiving actually my M17 signal.
And so you can see it shows my, my call sign, the broadcast tab, the data type and everything.
And that's used quite a lot by the M17 team to actually test radios and make sure of your
compliance.
And so, yeah, you can, if you're done using it, just click the checkbox and it's gone.
You don't have to think about it and you can just reenable it the next time.
And so, yeah, I think that was a tour of Asia++.
I would have lots to show the server features, but the Wi-Fi here is completely overloaded.
So, I literally can't even load emails, so it's not going to do IQ over internet.
So, yeah, I think, I think this part of the demo is done.
Let's go back to the slide.
All right, so a future.
So, the first thing I want to talk about is things that won't change, because there are things
that from feedback I've heard were done right, which was the layout, which again was just stolen from
SDR sharps.
So, it makes sense, but it was decent.
General workflow of how things work with software, the OS support and the hardware support.
The hardware support, especially, is nice, because you used to be locked into
ecosystems with SDR sharps, which only allowed its own SDRs.
And then cut off support for others, which wasn't really nice.
And I don't think that's cool.
So, I'll always support any hardware that manufactures one supported, or they want to
add support themselves, they can do it to its no difference.
That's what will change.
First, the GUI, which is done with the library called DRAM GUI, will be replaced with a custom GUI library.
Obviously, people would say, well, why not use QT, why not use WX, why not use insert name here?
Well, because they're all trying to be frameworks and not library.
And so, you end up having to write hundreds of lines of boilerplate for any silly little thing.
And I don't like that.
And so, I decided to write my own custom GUI library, which is, it's not done yet.
It's going to take a bit longer, but I hope to introduce its soon.
Next, as you're a++, we'll move from being single input multiple output to multiple input multiple outputs.
And what I mean by that is, it will both be able to use SDRs with multiple channels, like the blade or F,
that was shown by Sebastian and the previous talk, or use multiple SDRs at once,
and then move the Fos between them seamlessly.
I'll also go from being received only to being received and transmit.
Transly we aren't really good open source options for transmit.
They either don't have great hardware supports, or are really unstable, as your angel.
Sorry.
I had to use it for Q100, and yeah, it's really motivated me to implement transmit and try to do it.
In a way that's user-friendly and pretty stable.
And also, the DSP library is going to be completely rewritten, because as I said at the beginning,
I just did it during COVID for fun, and the structure didn't end up being really optimal.
But now with four years of trial and error, I think it can be rewritten in a way that's a lot more efficient.
And so yeah, we'll use the lessons learned from 1.0 to do SDR++ 2.0.
Before ending this talk, I have to think of a Patreon supporter of the project.
There are a lot more than that, but those are the ones that accepted to be in the credits.
Obviously, they've been paying for some of the hardware that was needed for my food and university tuition events,
so thanks a lot to them, and thanks for your attention.
All right, so any questions now?
Yes?
Many of you already support this, or don't know if you can do this in filing, because you intend to support it,
so you can see that.
Okay, so the question is, do I intend to support SIGMF for FIWANT put?
So I'm not sure if I'm going to support it first party, because I don't really know the format right now,
and the priority is make the file player a bit better, because right now it's really happy, it hasn't changed since 2021.
So the priority is first to rewrite the file player, and then maybe more formats can be added.
But again, since SDR++ is modular in such a way that there's no difference between user plugins and official plugins.
So anyone could write SIGMF source, and it would just show up like any other.
All right, I have a question.
Yes?
Can you get my laptop support?
Oh, so the question is, can we have macOS support?
It's already supported, both on M1 and X86.
Okay, I have a question, yes?
Sorry, I can't.
Okay, so if I have to send a question, is can SGR++ be added to home brew?
Well, if someone wants to do it, sure, but I don't have a mac.
All the development to support macOS was done blind.
Like just trying and seeing if it builds in the C.I.
And when asking people to try it out, so maybe if I get a mac,
I'll be able to add support for it.
But I think someone has already added it to mac ports.
I think I'm not sure, but yeah, if I do get a mac at some point, I will add it.
Yes?
Okay, yes?
Okay, so the question is why does the 90 builds
says November 2022?
So it's just because I'm misusing GitHub.
It's not really meant to have a continuously updating release.
And so it still says the date where I started doing 90 builds instead of scheduled releases.
So that's not really something I can fix, but.
Yes, it's really, it's 90.
If you look at the date on the files, you'll see it's, it's really just one.
Yeah.
Okay.
Other questions?
Yes?
I actually didn't know about the output one.
So there's been some sort of discussion.
What do you mean if you had any questions?
I'd like to ask you a question.
Okay, so the question is where any plan to add the last-less compression to recordings?
Yes.
We're working with another developer that also needs recording to maybe publish a new compressed format.
I did try flack.
I assume that's what you want.
Flack does work, but for IQ, it's not really, it's a bit slow to record IQ.
Like if you try to record something like a blade RF at 61 mega samples per second,
it's not going to be able to handle it.
So yeah, but it's definitely planned.
It's super useful for archival.
And combined with dynamic range compression, it can really help a lot to save signals and stuff.
Yeah.
Okay.
Other questions?
Yes?
If I send your vector or unit and I just hope it goes as an excuse for you in the video.
So let me try to understand your question.
Send what for GDP.
You mean through the network sync?
Yeah.
So yeah, you can just send them straight.
So I'm going to repeat the question actually since it's recorded.
So the question was, can the network sync be used to output to GNU radio?
Yes, absolutely.
But it depends what you want to do.
If you want to send audio to GNU radio, yes, just use the network sync.
But there's actually a better way to do it.
I don't know if I have it installed in this one.
It's the IQ-Exporter module, which, okay, I have right here.
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.
Or you can output a VFO and now it spawns a VFO, which you can drag around.
And sorry, wrong menu.
This one, you can set which sample rate you want.
You can set if it's TCP server.
It's pcln to dp.
The size, the sample type and everything.
And this will substrate to GNU radio.
Okay.
Two people.
I guess.
Yes?
Yes.
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?
Yes.
So the question is will transmit support?
So what's re-transmitting IQ?
Yes.
It will just allow you to send IQ to VSDR or send, have a transmit VFO to send some stuff.
Modules can do pretty much what they want.
You have to think of VSDR plus plus more as a framework than software.
And it has to let modules do whatever they want with hardware.
Yes.
So yes.
It will work.
Yes.
And I think.
The question to this feature of sending IQ can be sent to multiple.
With UDP, you can use UDP broadcast.
Yes.
No.
I mean, to intents, essentially, multiple IQ reports.
Oh, yes.
Yeah.
It's.
Yeah.
Like if I just say.
So I assume that's what you mean.
Yeah.
I can just add the second IQ exporter.
And if it works, I don't know why I don't see.
Oh, wait.
It's in based bandia.
You can just add as many as you want.
And it will just export all your signals.
Yeah.
Yes.
Can you ingest or plug this in?
So can you ingest IQ streams on the network?
You mean?
Do you want to plug this?
Oh, no.
No.
It's only outputs raw samples and input raw samples.
But I think, I don't know.
If you want to import samples, we have a network.
I think I have it on this one.
No.
I don't have it.
Let me check.
It must be here.
Yeah.
Networks source.
No.
That's kind of an example of adding a source.
It's just add the module.
And now magically, you just have a network source.
So yeah, you can take samples.
But it's only ints and flows raw things.
Yes.
You can use FFMPEG or any other command line, too.
Okay.
Other questions?
Yes.
The one thing you can see just the problem.
By default, it's five milliseconds.
It can be, basically, it depends on the size of a buffer that you send for the DSP chain.
The DSP chain is pretty much instance.
But if you buffer up five milliseconds, that's going to be your latency.
It's pretty much, you can't hear.
It's like, I've had multiple times the audio just from the radio talking into it.
And listening, it's really not much.
It's, of course, it's going to be worse than the hardware radio,
but it's not anything crazy.
Yes?
Can you repeat?
No, it's reduction.
Yes, I plan to implement it.
I just have to get it to work, because I don't want to just use a pre-made library.
Everything, as we are plus plus, is written from scratch.
And I want to continue that.
It's a bit, so if you don't want to wait for me to do it,
there are multiple people who have written modules that have noise reduction.
But yes, it will be supported.
Not AI, just deterministic noise reduction is.
Someone has already made one.
I will prompt.
I will write one, but I mean, including natively, it makes no difference.
If it wasn't included, the only difference is you don't need to download it.
You don't need to download it.
On MacOS, no, no, you should just be able to add it to you open up the bundle.
Probably need to talk to the module after they might not have planned for MacOS.
Okay.
Yes?
Yes, write it.
You can just, it's power of two, but it's not, as I said, it's not just a dumb,
but you have been filter.
It's actually a special plan for each decimation.
Yes?
Okay.
I have a questions.
We have just four minutes left.
Yes?
Do you plan to have a sub-order button that wasn't helpful?
I mean, what people can do?
I'll only do this regular flight now.
You can talk about it.
Okay.
So the question is, do I plan to have an official repository of modules?
I've been thinking about it.
The issue is vetting for security, because modules are dynamic libraries.
They're not just scripts.
They run raw executable code.
So you have to be careful about what you install.
And I'm not sure at this time I want to be responsible for the security of thousands of computers.
So yeah, I will consider it.
That will see.
Okay.
Another question?
Or, yes?
You say you're going to develop a new graphical interface?
Yes.
And are you going to make it something kind of more friendly like the icons or buttons?
So not only the menu text menu.
Okay.
So the question is, I'm going to do a new GUI system.
Not really.
It's just going to be a new GUI library.
But the menus you see here, nothing will change.
It's just going to be a new library with the same layout.
Because it's just a brand new people like it.
It's copy, as I said, from SDR sharp.
It's pretty intuitive.
So I don't think there's much reason changing it.
So yeah, it's just purely back and stuff.
Users just see if we'll look a bit different, but that's about it.
Okay.
So yes?
Can you go with the module?
What do you do?
Okay.
So I don't want to bore with the map.
But basically, when you do decimation,
it's not efficient to do it in a single stage, generally.
So usually do it in multiple stages.
The industry standard for a while has just been to combine half-band decimation.
And just add as many as you want.
But if you do the map, you can actually compute the filters
for each decimation stage in such a way that you allow
some signal to leak through from higher Nyquist zones into lower ones.
If you know that they are going to be removed by lower stages,
running at lower sample rates.
And so from that, you can run an optimization algorithm,
which given a yes-free ratio for SDR++, it's 95%.
So that means that you're guaranteed that in the 95% of a bandwidth.
You won't have any ALS over 100, well, under 100 dB, I should say.
And yeah, it's numerically optimized.
And if you look at the source code, you can see the plans and how they're built.
I haven't published the source code of the tool that generates them
because it was a collaboration with AirSpy.
And they're planning to re-sacentific paper about how it works.
So I don't want to be an asshole and publish very stuff before they do.
But you'll probably hear about it in the future, yes.
And I think someone else had a question?
Yes?
You can't do it to you next time.
No, but I guess you can just use netcats.
I guess that could be a feature.
But I try to have the modules be cross-platform.
And you next time obviously would be only on macOS and unix.
I guess it's possible, but we'll see.
Open the feature request.
And I think we're out of time.
Yes.
We are out of time.
Unfortunately.
I guess.
Thank you very much.
If you have any other questions, just send me an email or go on the Discord server for the
Atlas Plus.
Yeah.
Thank you.