 At this time, I'd like to introduce our next speaker, Nick Ortil presenting transitioning to the SOSA slash CMOS architecture. Good afternoon. Good evening. I'm Nick Rotel, VP of Engineering to RC Technologies. We deliver RF based integrated solutions for government, military, and law enforcement agencies. And these products and solutions address a wide range of significant issues. That's my contact information with the organizers that have been able to go after the conference. So I plan to cover in these few slides the journey from going from the standalone solution to a CMOS integrated solution in high level design consideration. I'm also going to cover an RF survey. This case needs to illustrate future revisions of specification and make some sense to have unfold to allow plugging cards to plug in cards to interoperability. I realized there's now proposal to accommodate this type of functionality for several of the technical committees, but that was a known mistake or was put forward in June. So apologies if some of you think this is a little old. So on the left side is a classic black box, a convection cooled standalone system. So it contains two tuner, two software defined radios and their survey solution contains power supply removal media processors and so on. On the top of the box is the core technology, the software defined radio and the SOSA compliant free form factor. Then on the right side is just a few pictures of the journey along the way, you know, digital engineering all the way to the other side. The taking a look from a functional block diagram perspective, standalone product on the left and the SOSA system most compliant on the right. You notice that it's a far few functional block diagram components on the right. Their reasons are pretty straightforward. Chassis provides power communications buses and various other plugging cards provide things like stores and so on. Therefore, for us, the effort was to focus on really our core technologies and not all the other things we needed in the system. I think if I know you're probably difficult reading a little word that's okay, it's really the colors to look at, the number of blocks you color, so they're a few trends that you want to look at. Taking a look at this from a physical point of view, you can see the high level of assembly on the left and the number of parts, you can see the several hundreds, it goes to the box. And essentially, in this list of CMOS form factor, quite a few of your components, essentially three-layered board stack and standardized connector and so on. So it makes it pretty, made it pretty straightforward for installation. Really what I want to talk about though is a use case. So here we have, well, I should back up and just say, so as we did a use case analysis, we started looking through all the use cases we have. You know, many can be accommodated with standards and lost cards, no question about it. But it's, RF survey gets a little more complicated, a little straight in the moment, a little different use cases. There may be some accommodation that's going to be made in order to process and signal. So in this case, pretty straightforward, we're going to set up a perimeter. We're going to look for things coming in, RF things coming in and out of the perimeter. In this case, you just pick something that's kind of in a public domain now of consuming way this is. So, you know, in a standalone sense, you'd have a box or two, a classic black box or two in an antenna. We would allow you to locate the signals and controllers. In CMOS sense, you'd have a chassis, a few cards, and then, of course, an antenna. So functionally, about the same, not a lot of difference there. So we've established the perimeter, pretty straightforward, you can identify the drone and controller on both systems, not that challenging to do, done every day. However, I think here's where we start to get into a little more complexity. So as the environment starts to ramp up in complexity, let's just say there's multiple pieces of the drones in the area, you not only want to maintain real-time detection, identification, location, but you might want to also simultaneously transmit as well and have some other features of the system, such as automatic gain control, other things. That's when you start tasking the present system. Easily, you will exceed a gigabyte a second isn't on data. This is a process in addition to other tasks that are going on, like visualizing, learning, detecting, storing, transmitting. And so that's where latency will start coming into this thing, and the concept of real-time might be less than you're willing to put up with. So one way to alleviate this would be to allow for pick interoperability. And so what do we mean by that? Actually, have the cards be able to talk to each other directly off the bus. You can relieve a lot of the processing that way. Certainly offloading the chassis can even double the throughput of the system if we have to think of these as little modules. So we'll have two cards, three cards potentially put together, interfacing with each other directly to process the high data rates. There's other use cases as well that this could be useful in. There are use cases, and I put this in the paper where you can have two chassis that are separated by quite a distance. And there's reasons that you'd want each chassis to kind of be independent from each other, but then again talk to each other to exchange information. And again, go into some serious latency if you can't accommodate things like 8 million ECI and so on. We think this could be accomplished by maintaining like and maintaining the main chassis larger system with things like resources requirements and interfaces, the ICDs. And then I just as an example of this, the show that has been done in other places, I just put in a consumer computer card to show that yes, they maintain their ICIDs and interfaces. However, they do also allow for a little bit of user experience by camping. And obviously, SWAP would not be able to activate. So again, I realized that there was a proposal to accommodate this type of functionality. Probably enjoy our time frame. So that's it. So I wanted to present to the audience. Do we have any questions for Nick? Okay, nothing's coming on. Oh, wait, here we go. Here we go. Here's a question. The last slide mentions intraoperability, but you show two cards. Yeah, I just took a consumer example. I think in a previous slide, I lined up three cards, which is when you said intra or intra, what I'm talking about is interoperability between two cards or three cards or more from the front, not necessary to the back. And so I tend to think of that as a model. If you will, I can take two or three cards because you want to choose something close together. Okay, any other questions? Thank you, Nick.