WEBVTT 00:00.000 --> 00:15.960 Good morning people, welcome! 00:15.960 --> 00:22.080 So we are officially starting the embedded Devroom 2025. 00:22.080 --> 00:28.360 So this year there is a small change, so my main co-host is this year World Minor, giving 00:28.360 --> 00:31.980 the warm welcome. 00:31.980 --> 00:37.640 So the previous co-host is still with us, he is still in the community, but he is now leading 00:37.640 --> 00:42.920 the Android Devroom, so I encourage you to visit that Devroom as well. 00:42.920 --> 00:49.040 My name is Chris, I work for a company named NET, who manufactures the video conferencing 00:49.040 --> 00:50.040 equipment. 00:50.040 --> 00:55.560 Yeah, my name is Walt Miner, I work for automotive grade Linux and the Linux Foundation as 00:55.560 --> 00:58.520 the community manager there. 00:58.520 --> 01:02.560 So we hope that you have a great time, although this year we have a small room with no 01:02.560 --> 01:15.160 windows, but that means that the density of knowledge is going to be higher. 01:15.160 --> 01:16.160 Test test? 01:16.160 --> 01:17.520 Okay, yeah. 01:17.520 --> 01:24.480 So good morning, my name is Manolis from the US Space Foundation, first time on the embedded 01:24.560 --> 01:31.360 track, I was mainly in Walt with radio stuff, but this year we jumped to the embedded. 01:31.360 --> 01:39.320 Today I will present you the Saturn's Combs, which is this board, it's a kit that 01:39.320 --> 01:45.600 will come in case in board that is suitable for kit missions. 01:45.600 --> 01:52.600 So how many of you are familiar with the Saturn's? 01:52.600 --> 01:55.080 Okay, keep people here. 01:55.080 --> 02:01.920 So in the nutshell, Saturn's is perhaps the biggest project of free space foundation, 02:01.920 --> 02:08.680 it's a network of ground stations that follow a modular setup based on software-ifying 02:08.680 --> 02:19.000 radio, their purpose is to receive and demodulate and decode satellite signals, and then 02:19.000 --> 02:25.800 post the telemetry data to our cloud infrastructures to for visualizing and getting them. 02:25.800 --> 02:32.680 The entire stock is open hardware and open source, and the telemetry results are also 02:32.680 --> 02:35.480 published with open licenses. 02:35.560 --> 02:41.640 So right now, we cover mainly the VHSF and UHSF bands, we have a few stations for railbunt 02:41.640 --> 02:45.960 and as a bunch, and we are responding to our next one too. 02:45.960 --> 02:54.760 So having that experience from the ground stations, that we have around 400, if I recall correctly 02:54.760 --> 03:01.040 around the world, we wanted to expand to the space segment. 03:01.040 --> 03:08.720 So together with these are, which go found, we go found the project Saturn's comes, 03:08.720 --> 03:14.880 which is a receiver with two dedicated interface, one for the UHSF and one for the S-bunt. 03:14.880 --> 03:22.680 It based on the S-DM headed to H7, a microcontroller and has also a Zinc FPGA for doing DSP. 03:22.680 --> 03:26.960 So we use the FPGA as a compressor, let's say. 03:26.960 --> 03:34.320 It's suitable for low-weth orbit Gibbs atomizations up to 600 kilometers, and the entire stock 03:34.320 --> 03:35.920 is open source and upper hardware. 03:35.920 --> 03:41.520 Right from the design phase of the project, everything is open and you can go and check 03:41.520 --> 03:48.720 the development process, the decision making, why it's just that part of the fire, not the 03:48.720 --> 03:50.600 other and all that stuff. 03:50.600 --> 03:56.520 Everything is there and you can go and follow the story, let's say. 03:56.520 --> 04:00.920 One unique feature of this transmitter that we provide seamless integration with Saturn's, 04:00.920 --> 04:07.680 so if you get this transceiver on your satellite, you have the guarantee that you can use 04:07.680 --> 04:12.480 any of the Saturn stations to get your data. 04:12.480 --> 04:19.540 So this is the transceiver of the bottom side, the top side as it starts right now on the 04:19.540 --> 04:24.840 latest version, 0.3.2. 04:24.840 --> 04:32.080 And we are very, very proud that we, for the development of this project, only open source 04:32.080 --> 04:33.080 tools were used. 04:33.080 --> 04:38.920 So for the, for the hardware design we use a kick-up, for the similar simulations we use 04:38.920 --> 04:49.880 a Cooks, ZFRTOS, for the main MCU, we try to also use a latex for the FPGA staff. 04:49.880 --> 04:57.360 We haven't done yet with great success, but we are going to, we are planning to do this. 04:57.360 --> 05:02.760 So regarding the added capabilities, we mainly, as I said before, we cover the huge FNS 05:02.760 --> 05:08.600 bond, mainly the commercial bonds, but upon request, we can tune the system and provide 05:08.600 --> 05:11.040 also the amateur radio bonds. 05:11.040 --> 05:21.160 At the x power it's quite high, in terms of, of the needs of cube set missions and it has 05:21.160 --> 05:24.280 a great resolution of 1 dB. 05:24.280 --> 05:31.880 One thing that is that we are very proud of, I know that you don't understand, maybe so 05:31.880 --> 05:39.580 if you don't understand, but we have put a lot of effort to minimize the noise, the noise 05:39.580 --> 05:45.460 figure of the system, which currently stands for 1.4 dB, which is super impressive. 05:45.460 --> 05:57.860 So just to have an idea, this is the UHF, the UHF front end, on the bottom side you can 05:57.860 --> 06:06.820 say the transmission path, which is actually very simple with a power amplifier and an analog 06:06.820 --> 06:11.060 amplifier to cut off and kind of want the missions. 06:11.060 --> 06:19.020 And on the upper side, it's the receiving path, which is much more complicated, because 06:19.020 --> 06:27.060 we implement on board a hardware mechanism for automatic gain control. 06:27.060 --> 06:36.620 So this is the H1 path, quite similar approach with the UHF, but with the MNS, the 06:36.620 --> 06:43.100 difference, because the transceiver module that we use, the transceiver IC that we use, 06:43.100 --> 06:46.300 doesn't support the commercial asment bugs. 06:46.300 --> 06:51.700 We have an RF mixer that down converts or up converts the frequency to the target one that 06:51.700 --> 06:56.460 so we can receive the singles. 06:56.460 --> 07:04.340 Of course, actually communication board, it provides some interfaces for the satellite to connect 07:04.420 --> 07:07.100 with other subsystems on board. 07:07.100 --> 07:15.780 So we have two can, one SPI, one I square c, three yards, one equivalent, that goes 07:15.780 --> 07:20.540 to the zinc FPGA, two antenna deployment mechanisms, and all these are available through 07:20.540 --> 07:27.480 the PC 104 connector, the big one connector, that is quite standard in the Kibserti 07:27.800 --> 07:30.320 industry right now. 07:30.320 --> 07:43.080 So the board itself has already flown in space, so we, we've flown in, we fly in this with 07:43.080 --> 07:51.560 Ariane 6, with a maiden flight of Ariane 6, back in July, on board the Kirium 1 satellite. 07:52.520 --> 08:02.360 Unfortunately, things didn't go well, it didn't go so well, and for many days, we didn't receive anything 08:02.360 --> 08:09.800 from the satellite, and then we have some good friends, Cisbasa and Tamoyan, that actually 08:09.800 --> 08:20.840 have access to this small antenna, 25 mm this, and we pointed this to the satellite, and eventually 08:20.920 --> 08:28.200 this doesn't, it doesn't, it doesn't, it's not so visible, but eventually we find out that 08:28.200 --> 08:36.040 the, the board was active and it was transmitting, so after doing some analysis and getting 08:37.080 --> 08:42.200 scratches from a telemetry, we identified that they would of course was that the antennas didn't 08:42.200 --> 08:48.120 deploy, so yeah, it was a successful failure, let's say. 08:51.480 --> 08:59.640 So our next big issue is the phasma, which is right now perhaps the biggest ongoing project 08:59.640 --> 09:09.960 free space, phasma is a two, two, three YouTube satellite, so we will launch two satellites, 09:09.960 --> 09:18.840 one of the other, to do spectrum monitoring from from orbit, okay, so to identify the spectrum 09:18.920 --> 09:26.120 occupancy from orbit, so we will use two satellites, on its satellite, one for the on board 09:26.120 --> 09:34.840 computer and communication subsystem, and one to do the actual spectrum monitoring, so this 09:34.840 --> 09:45.160 mission is correct to be launched on this October, so yeah, the interesting stuff right now, 09:45.640 --> 09:54.680 so what about the software, so we have decided, because we need, we envision that this board 09:54.680 --> 10:03.720 will be available for other teams to to use it and as, as the communication subsystem, so we, 10:04.760 --> 10:11.080 we, we, we said that we, we should implement it, implement it as, as abstract as possible, 10:11.080 --> 10:21.560 so we use zefiartos as our main artist for the firmware, but someone else will perhaps like to 10:21.560 --> 10:29.800 to implement it on freeartos or whatever arthos slikes, so for this reason we completely 10:29.800 --> 10:36.440 are structured, the hardware control from the main logic of the firmware, so we implement the 10:36.520 --> 10:47.240 lip settings comes, which sees an abstract class that controls the hardware components, interacts 10:47.240 --> 10:55.160 with a hardware and they have the value sensor at the board has, and with this interface, someone 10:56.040 --> 11:03.880 can implement the logic of a satellite without having to re-implement everything for scraps, 11:04.840 --> 11:13.160 so to do that, we decided to use C++ and more specifically the 17 version of the standard, 11:13.960 --> 11:21.560 and designed the the lip settings comes as an abstract class using which pure virtual methods, 11:21.560 --> 11:30.520 so with this way, if someone was to implement it, the logic on different arthos, for example, 11:31.480 --> 11:39.240 it is has to implement only the pure virtual methods that are provided by the platform, 11:39.240 --> 11:46.680 which actually corresponds to hardware specific stuff, so for example, this example of the GPIO, 11:46.680 --> 11:56.760 there is a pure virtual method called enable or get, so this has between only this method 11:57.240 --> 12:04.200 should be implemented by the user, and this of course, many mice, the effort of integration 12:04.200 --> 12:13.960 or whatever, so I thought about zf, and a good question will be, why is zf, okay, so 12:15.080 --> 12:20.120 it is more than sexy, we all know that, it has a huge community, 12:20.680 --> 12:35.320 it uses C-make, which someone may like, someone not, but C-make makes things much more easier, and modular, 12:35.320 --> 12:42.520 and at least for me, it uses device-free, and I know please don't suit me, device-free, 12:42.520 --> 12:47.320 about a device-free, but I have few slides later on, so we can discuss. 12:51.080 --> 13:03.160 Why not Linux? Good question, but at that point, we were not sure that the STM-87 could cope with this. 13:04.040 --> 13:21.640 Only DSP stuff, this is our second processing stuff, again on zinc hustling, but because the zinc, 13:21.640 --> 13:30.680 if you enable the zinc, it consumes at least a what of power, you don't want to have it continuously running, 13:30.760 --> 13:40.120 so you enable the zinc at the specific time, you want, okay, so regarding the zf, 13:40.120 --> 13:48.200 we use a lot of modular stuff, so even if you don't fly a satellite, you can still use this project, 13:48.200 --> 13:58.680 as an example, to take some code snippets, let's say, from one of the available modules, 13:58.680 --> 14:05.640 that we use, as you say, the majority of the difficulty, like modules like the LFS, 14:06.520 --> 14:13.000 the executive place, with MCBoot are there, so go get some ideas. 14:14.600 --> 14:20.520 So, with the guy in the advisory, yeah, so there is a book, advisory for dummies, 14:21.480 --> 14:31.000 I'm just kidding, there isn't. So, yeah, advisory, it's a pain in the ass, okay, you all know that, 14:31.640 --> 14:40.120 but for our case, it was a game changer, because we could, you know, every mission of this 14:40.120 --> 14:46.440 gives a mission, it's a bit different, it requires different IO, requires different interfaces, 14:46.440 --> 14:55.480 so we didn't want to pollute the code base with a different, with different branches, 14:56.520 --> 15:04.920 mission x, mission y, mission blah, blah, so we decided to use extensively the advisory, 15:05.480 --> 15:13.800 in order to support all these different configurations, and we are quite proud, because right now, 15:13.800 --> 15:24.520 we, doesn't, yeah, we support right now 34, if I call correctly, different hardware configurations, 15:24.520 --> 15:30.040 with zero code modification, you just use the overlay that we provide, the orange combination 15:30.040 --> 15:38.840 of overlays, and you have it. So, yeah, advisory for us was super, super, super nice. 15:39.800 --> 15:51.080 Okay, hand, the other point, I mentioned about C++, and some argue, okay, C++, I'm a bit 15:51.080 --> 15:59.720 skeptical, you should, to my opinion, you should, so C++ provides better code organizations 15:59.720 --> 16:06.680 through polymer fees, of course, it can provide much safer abstraction layers, oppose to the 16:06.760 --> 16:15.880 weak or function pointers, so if you, if you forget to implement a weak function, you will not 16:15.880 --> 16:23.880 get any kind of compiler error, okay, you'll know that. On contrary, on pure virtual methods, 16:23.880 --> 16:27.960 if you don't provide the implementation of pure virtual method, you will get a directly 16:27.960 --> 16:34.280 a compilation error, okay, so at compile time, you know that you have done something wrong, 16:35.240 --> 16:40.280 and another very interesting idiom is the right resource allocation is also in the 16:40.280 --> 16:53.080 realization, which you can do very nice stuff in order to gracefully clean up whatever, whatever 16:53.080 --> 17:02.360 steps of your code, or your program, if something occurs, so for example, if an error occurs and 17:03.320 --> 17:10.680 an exception of race, for example, if you have implemented correctly the right and do the proper 17:10.680 --> 17:21.960 stuff in the constructor, you are sure that everything will go well, so very, very nice example, 17:21.960 --> 17:26.760 it's a critical section, so if you enter the critical section, you have to disable the interrupts, 17:26.840 --> 17:32.520 and when you leave it, you have to enable it. If you, if you go with the if the nulls away, 17:32.520 --> 17:40.040 it is very, very easy to forget to enable the interrupts, but with the right idiom, it's not an issue. 17:43.640 --> 17:50.760 Another interesting point is that you can minimize the use of pointers, so we have tried a lot 17:51.080 --> 17:57.080 in Saturn's conflict, we have a few pointers still, but the majority of the code uses references, 17:57.080 --> 18:06.360 and this is another option, another compile time check, if you don't initialize the reference, 18:06.360 --> 18:13.560 you get a compile lesson here, templates, of course, we all hate them, but we all like them, 18:14.200 --> 18:24.440 and another nice feature of the recent standards is the concept expression, so you can do a lot 18:24.440 --> 18:33.560 of stuff with concept expression and do compile time checks or compile time code execution with 18:33.640 --> 18:44.440 context expression, so this another interesting feature of the language itself, and the last one 18:44.440 --> 18:52.200 to note this, exceptions, so how many of you use the exceptions from your projects on a bad 18:52.200 --> 19:05.480 device is one, two, three, okay, so let's talk about the challenges, which is plus plus, so 19:05.480 --> 19:11.640 a big challenge is that the standard to play the language, standard to play the area for 19:11.720 --> 19:23.560 plus plus, is use dynamic memory, so the majority of the components of the STL gives dynamic memory 19:23.560 --> 19:34.200 location, for space, this is a no-go period, okay, another thing of the language is the 19:34.280 --> 19:42.440 artistic Y, random type, random type information, which is actually dynamic cast or type ID, 19:43.400 --> 19:49.880 if you are familiar with C++, so this we can live with this without this, so you can disable 19:49.880 --> 19:57.560 by providing to the compiler the appropriate option, and because it produces very advanced 19:57.640 --> 20:08.280 fitness, but for exceptions we know that the also produce larger fitness, but not so large, 20:08.280 --> 20:15.720 for our case, because we are on the space domain, we can afford, I'll say, a more expensive 20:16.600 --> 20:21.720 micro-controller with larger plus, so for our case at least this was not an issue, 20:22.680 --> 20:32.760 okay, we talk about dynamic memory location with STL, so why to use C++, if I know that 20:32.760 --> 20:39.240 the majority of the containers of the STL use dynamic memory are the case, so a solution could 20:39.240 --> 20:48.840 be not use STL or write C++, but of course this defeats the purpose of using C++, 20:49.080 --> 20:54.520 and very clever guy, he comes in and says he will implement a hip manager, 20:56.920 --> 21:06.440 no, yes, of course not, okay, we have the issue of fragmentation, but we have ETL CPP, 21:06.440 --> 21:15.400 how many of you know the ETL, those were used the exceptions, okay, so ETL is a fantastic 21:16.280 --> 21:28.440 and provides the ETL, provides the STL with fixed memory model, okay, the memory, 21:28.440 --> 21:35.880 the memory requirements of each container, it's it's not combined, so I strongly suggest 21:35.880 --> 21:44.920 go check the library and use it on your projects, and now we come back to the discussion about 21:45.240 --> 21:53.960 exceptions, so unfortunately in the keeps at the main, we don't have, we don't, we are not so 21:53.960 --> 22:04.040 lucky as these guys in 1984 that went out there and serviced satellite, we will ignore it, 22:04.040 --> 22:13.080 so the software itself should be able to identify and kind of errors at a cure, at runtime, 22:13.160 --> 22:19.400 recover program and also log them, so this is super critical for satellite software, 22:20.440 --> 22:27.160 and as I said we use exceptions, and we have a unified, we have a unified 22:28.760 --> 22:36.520 error handling and logging system that logs any kind of exception plus errors at a cure at 22:36.520 --> 22:43.960 runtime and logs in different 40 different buckets, SWO, we have a ring buffer, we can store them 22:43.960 --> 22:51.960 also on the on board the precision storage and on the bugs backup SRAM, so our exceptions have 22:53.400 --> 22:59.480 four different five different civic levels and based on the civic level of the exception 23:00.120 --> 23:07.640 we take different actions, so for example, I square C is a well known buggy 23:09.240 --> 23:14.360 communication protocol, while in space because it's a very successful with noise, 23:14.360 --> 23:20.760 so we know that I square C transactions may fail, so we assign to such an exception 23:20.760 --> 23:26.840 a low security level, while on the radio staff that is super critical for us, we assign a higher 23:27.800 --> 23:33.080 level, so depending on where the exception occurs, this is called snippet to the exception 23:33.080 --> 23:40.120 for exception handling, based on this weight of the exception, we have different strategies to mitigate 23:40.120 --> 23:51.880 them, one strategy could be just to solve it, the other one could be this catastrophic exception, 23:51.880 --> 24:01.800 I should reboot this at light, the subsystem itself, okay, and then you will argue that hey, 24:01.800 --> 24:08.520 I know that exceptions are bad because they not only produce larger films, but also they are slow, 24:09.560 --> 24:19.480 correct, good, exceptions are slow when the cure only, and I have some code snippets 24:20.360 --> 24:28.200 that proves that, so we should think that exception is something rare to cure, we are not the 24:28.200 --> 24:38.600 other developers, okay, so in our case we should design the software like the exception occurs rare, 24:39.240 --> 24:46.520 and if occurs, okay, yeah, I'm willing to pay the price of the slower execution of the exception, 24:46.600 --> 24:54.360 because I know that occurs one percent of the time, more or less, even less, so exceptions provide 24:55.080 --> 25:03.960 so many goodies that is very hard to to to to meet them, so if you have to take something from 25:03.960 --> 25:13.400 this presentation, please use exceptions, okay, so that's all from my side, you can find us on 25:13.400 --> 25:22.200 matrix, you can find whatever we discussed here on our GitLab repositories, and we have also a 25:22.200 --> 25:32.040 booth, so if you want to talk more about exceptions or whatever, please comment, give us a visit, okay, 25:32.040 --> 25:36.440 thank you. 25:37.320 --> 25:45.000 Thank you for a great talk, unfortunately we don't have a time for questions, but you can 25:45.000 --> 25:47.000 catch the speaker, maybe in the corridor.