 Hello, everyone. This is the Circuit Python Weekly for Monday, January 8th, 2024. This is time of the week where we get together to talk about all things Circuit Python. I'm Liz, and I'm sponsored by Adafruit to work on Circuit Python. Circuit Python is a version of Python designed to run on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit, so if you want to support Adafruit and Circuit Python, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join any time by going to adafruit.it-discord. We hold the meeting in the Circuit Python Dev Text Channel and the Circuit Python Voice Channel. This meeting typically happens on Mondays at 2 p.m. Eastern, 11 a.m. Pacific, except when it coincides with the U.S. holiday. In the note stock, there's a link to a calendar you can view online, or add to your favorite calendar app. We also send notifications about upcoming meetings via Discord. If you would like to receive these notifications, please ask us to add you to the Circuit Pythonista's Discord role. There is a notes document that accompanies the meeting or recording. You can contribute to this document beforehand. The final notes document includes time stamps to go along with the video, so you can use the doc to skip around and view the parts of the video that interest you most. The meeting tends to run 30 to 60 minutes. After each meeting, we post a link for the next meeting's notes document in the Circuit Python Dev Channel on the Adafruit Discord. Check the PIN's messages to find the latest note stock so you can add your notes for the following meeting. If you wish to participate but cannot attend, you can leave hug reports and status updates in the document for us to read during the meeting. This meeting is held in five parts. First is community news. This is a look at all things Circuit Python and Python on hardware in the community. It's a chosen set of items from our Python on microcontrollers newsletter. Second part is the state of Circuit Python, libraries and Balinka. This is a quantitative overview of the entire project. It's a chance to look at the project by numbers separate from our status updates. Third part is hug reports. Hug reports is an opportunity to highlight the good things folks are doing, taking the time to recognize the awesome folks in our community. The fourth part is status updates. Status updates is an opportunity to report on what we've been up to. Take a couple of minutes, talk about what you've been doing in the last week since last meeting and what you'll be up to over the next week. And the fifth part is in the weeds. In the weeds is an opportunity for more long form discussion. These discussions can come out of status updates or be something you've identified ahead of time as too long for status updates. And that covers how the meeting will go. With that, we'll get started with community news. And headlines this week. MicroPython v1.22.1 patch release. MicroPython version 1.22.1 was released to address a specific race condition in using thread in the RP2 port. It has been v1.22.0 has been out since December 27th. So the period where the issue has been in effect is short, although it was present in preview build since November 9th. And then free Python for Kids tutorial with MicroPython and BBC Microbit. Python for Kids is a free comprehensive online Python development tutorial for kids utilizing a BBC Microbit development board going step-by-step into the world of Python for microcontrollers. And project of the week is sound localization with Raspberry Pi and Python. If you have multiple microphones in known locations, you can determine the time a sound arrives at each one. You can actually determine the location that sound is coming from. This technique is referred to as sound localization via time difference of arrival. Kim Hendricks decided to put the technique to good use to track down the location of illicit fireworks launches. The build is based on the Raspberry Pi with Kim developing an autonomous recording unit complete with GPS module for determining their location and keeping everything time synchronized. By deploying a number of these units, spread out over some distance, it's possible to localize loud sounds based on the time stamps they show up in the recording in each unit. This and more is available in our weekly Python for Microcontrollers newsletter which goes out via email on Monday mornings. Visit AdafruitDaily.com to subscribe to the newsletter. Thanks Ann for putting the newsletter together. If you have any Python on hardware project to share or find content you'd like to see included, please consider contributing to the newsletter. You can open a PR on GitHub, a tag and engineer on Twitter with hashtag Sergipython. You can use hashtag Sergipython on Macedon or email cpnews at adafruit.com with a link. And that is this week's community news. Next up is the state of Sergipython libraries and Blinka. This is a quantitative overview of the entire project. It gives us a chance to look at the health of the project separate from our status updates. We'll talk about the project overall and then separately discuss the core libraries and Blinka. So first up overall, there were 12 pull requests merged. Those are by nine authors, BD Lucas, Jepler, Just Mobile Eyes, I'm Not James, Crier, How To Flow, Jen Volk, Maker Melissa and AAL Hard. There are seven reviewers, Brent, Jepler, Maker Melissa, Tectric, Dan Halpert, Lady Aida, Fome Guy and 15 closed issues by nine people, 15 opened by 14 people. And now we will hear from Dan for the core. Okay, so last week there were four pull requests merged by two authors. There were three reviewers and there are now 23 open pull requests. A bunch of those are drafts which are on whole various reasons. There were three issues closed by three people and five issues opened by five people. There are now 694 open issues and they're divided into milestones. So there are two issues open for the 10.00 milestone. Those are changes that will happen when we start working on sort of 5.10. We're not even done with nine yet. So but those are things that we anticipate changing. Usually turning off features that have been deprecated in the previous release. There are zero open issues for 8.2.x, which is nice. There are 49 open issues for 9.00. Seven more issues open for 9.xx, things that we would fix after 9.00 is out. There are 23 open issues having to do with libraries, 573 long term issues, which are sometimes just enhancements. 14 issues are open because they deal but they really support. There are 11 issues that are open because they depend on third parties doing something. So they're sort of blocked because of that. And right now we have a lot of issues that have not yet been assigned a milestone. 17, those need to be triaged and labeled with the correct milestone. But since I was out last week and Scott was out last week, not a lot happened in that way. So, but we'll be getting back on track this week and then Scott will be back Tuesday of next week. Okay. Great. Thank you so much, Dan. And next we'll hear from Fome Guy for the libraries. All right. Thanks, Liz. This section covers all of the circupython libraries, which you can find on GitHub under names like Adafruit underscore, circupython underscore, and then the name of whatever library that you are looking at. All these libraries provide Python level code that allows you to interface with either various bits of hardware like specific sensors and other things like that or provide helper functionality in order to just make it so that your user code does not have to micromanage as many of the specific complex details in order to achieve neat things. Across all those libraries this week, we had five pull requests merged by five authors, a couple of the names that stuck out to me as newer or less frequent contributors. And I think Liz mentioned some of these as well. I would say thanks again to these folks that might be newer contributors to libraries. BD Lucas one, Just Mobile Eyes, I'm Not James, and AAL Hart, thanks to those folks as well as Jeff, our other author. And then we had four reviewers who are more usual suspects, but thanks as always to Brent, myself, Tectric, and Jeff. As far as pull requests, those five pull requests, the oldest one that was merged this week was 48 days old, the newest one was just one day. That leaves us with 58 open pull requests now. The oldest of those is 501 days, and the newest is just one day. There were over the past week six issues that were closed by five people and nine new issues opened up by eight people, which leaves us now with 717 open issues across all these libraries. Of those 717, there are 19 of them that are labeled good first issue, which is a great place to look if you are interested in getting involved with contributing to CircuitPython. If that is the case, you can learn more at circuitpython.org slash contributing. This would be contributing on the Python side of things. On that webpage, which I mentioned, circuitpython.org slash contributing, you'll find a list of open PRs as well as all the open issues. If you're looking to contribute, you can get started there. If you're interested in reviewing, you can check out those open PRs on the first tab. Just take a look over the PR. Take a look for code, spelling, comments, all those sorts of things. If you have the hardware, you can go ahead and test it out. Leave a comment to how it worked out. If you're interested in getting involved more so on the contribution of code, you can look at the issues on that contributing page. Underneath issues, there is also a dropdown to filter by the different labels, which is how you can filter it down to the good first issues, which are the ones that have been identified as good for folks who maybe don't have as much experience with Python or microcontrollers or CircuitPython. So if you want to get involved but don't know where to start, head there. The other thing I would encourage you to do, if that's the case, is join us over on Discord. There's folks around on the Discord throughout the week that can help you get involved with contributing in whatever way works for you. We can walk you through, point you towards guides for the version control. They get in GitHub side of things. We can help you out with any issues that you are running into. So head over there if that sounds like something that would be interesting to you. To wrap it up for the library stats, we've got some PyPy Weekly stats for the week. There were, let's see, is that 52,103 PyPy downloads of those 323 total libraries this week. The top 10 list is noted here in the note stock if you'd like to take a look at that. And then the list of new and updated libraries here is relatively short. So I'll let you know that there was LPS 2x. I think that one is a new library, although I'm not sure what device it is. Request was updated this week and there are a couple of new libraries over in the community bundle, the Wave Builder and the MicroOSC library. So thanks to everyone who contributed those and I will send it back over to Liz. Thanks. Thank you so much. And now we'll hear from Melissa for the Blinka stats. Hello. So Blinka is our second Python compatibility layer for MicroPython Raspberry Pi and other single board computers. This week we had three pull requests merged by three authors and one reviewer, which was missile. There are currently 11 open pull requests amongst all the repositories. About half of them were within the last day or two. And there are six closed issues by two people and one open by one person, leaving a net of 78 open issues. There were 12,283 Pi PI downloads in the last week, 5,522 Pi wheels downloads in the last month, and we are at 128 supported boards. And that's it. Excellent. Thank you. And that is it for the state of Sergipython libraries and Blinka. Next up is Huggerports. Huggerports is a chance to highlight folks in the Sergipython community and beyond for doing awesome things. I'll start and then we'll go down the list alphabetically to give everyone a chance to participate. If you are a text only or missing the meeting, I'll read your notes when I get to them in the list. So I will kick things off with a group hug and then I will read for Cedar C Grover. FOMIGuy for suggesting bitmap tools to reduce a project's footprint, improved performance as well. John Park for the design and coding of the superb fader wave project. I'll be using it as a test bed for my wave builder demonstrator project and a group hug. And now we'll hear from Dan. Okay. Thanks to Jeff and everyone else who covered while both Scott and I were away. I'll talk more about that in status. Thanks to Jeremy Amour, ADCC and Romkey for continuing to stay on top of the macOS Sonoma issue where it delays rights to USB drives and continuing to submit feedback items to Apple. Though Apple is a black hole when it comes to these things. Thanks to Justin for working on refactoring the network code, which is a very an overdue thing. Okay. Thank you. Thank you. And now we'll hear from Deshi Poo. Okay. Thanks to ATE to make centimeters. I guess for work on improving the file system support and the USB C support as well. Bill88T for work on the settings and the workflow in general. And thanks to Brandon Lane for discussions on display IO and non-standard uses of e-paper displays. Thank you. Thank you. And now I'll read for DJ Devin who is text only. FOMI guy for the Friday and Saturday streams doing great things with display IO. Can't wait to integrate his soft keyboard into my project. Tanute for everything he's contributed to Serga Python and dealing with a personal matter and a group hug. And then we'll hear from FOMI guy. All right. Thanks Liz. First up for hard reports for me just group hug to everybody. Super happy to be a part of this community. Did some thinking about that over the break with the new year and stuff and just really, really excited to get going for this year and really happy to be around and have made so many friends and great connections through this community. So thanks to everybody for being awesome. Thanks to Justin for working on the connection manager API. It manages the differences in networking APIs between built-in Wi-Fi and ESP32 spy. I think that's really cool. Also, Justin created a another little utility that can generate stubs files for the board module using values that it finds from pins.c files inside the core, which I think is also a really, really cool functionality in order to have stubs that know which pins are on your specific board or potentially even just knowing which pins are valid for any board across the whole project. But both really, really cool things. Thanks to Justin for those. Thanks to Tech Trick. I should say just hug report. Nice to see Tech Trick pop back up. And thanks for doing some work going through library repo issues and PRs. I do appreciate it. Thanks. Great. Thank you. And now we'll hear from Jepler. Hello. I have a hug for Dan and Scott. They're both going through some difficult family stuff. Scott a little while before and I didn't say anything at the time. So correcting that. My sympathies and as I think you say, may their memory be a blessing. And of course a group hug because it's great to spend time with y'all. Thank you. And now we'll hear from Justin. Yeah. I just wanted to give a hug out to Fome Guy who worked on Friday during the deep dive and tried out my connection manager stuff, which hasn't been accepted necessarily by Adafruit or anything like that, but really worked through it without previously talking to me or anything like that. And it was just fun to watch him try to figure everything out and try to see if this is something that Adafruit wants to kind of go in that direction of. So thanks very much. Awesome. And now maker Melissa. I just wanted to give a group hug to everyone and that's it. Thank you. And now I'll read for Tech Trick. Group hug to everyone. Excited to be more present again soon. And it is good to see you back. And that was Huggerports. Next up is status updates. So status updates is our time to tell folks what we've been up to individually. I will start and we'll go through the list alphabetically. When I call on you, take a couple of minutes to talk about what you've been doing since the last meeting and what you'll be doing until the next meeting. This is also an opportunity to provide tips and tricks relevant to what people are working on if a discussion becomes too long for status updates, we can move it to in the weeds. And I will start. So I was able to take the past two weeks off to rest and recharge, but I did work on some electronics projects while I was out. I built a plant grow light for my mom. She has these two little plants that she'd been kind of moving around to try to get them some light because we're in the northeast and it gets dark pretty early. And this involved building a wooden flower box to hold the plants. And the lights I'm using are the Darts Star LEDs and because they have the right color temperature to promote plant growth and they're connected to a QDPI ESP32-S2 running whippersnapper firmware that turns the lights on and off at a scheduled time. It was my first time using whippersnapper for a project and it was really easy. And since this project was running at my mom's house, I can monitor it from my IO account for troubleshooting and that's one reason why I didn't do circuit Python. I kind of wanted it to be something I could easily manage without having to take anything apart if anything went wrong. And then I finally got around to starting to modify a meowsic cat piano that I found on the side of the road right before the holidays. I followed JP's guide on adding a line output and I took out the very corroded battery compartment and installed an HUSB238 so that can be powered by USB-C and I also added a power indicator LED because I was finding that to be pretty frustrating that I couldn't necessarily tell if it was actually getting power. And now I will read for C Grover, who's text only. So, wrapping up the tests for a Synthio Waveform Wavetable Graphic Visualizer widget, WaveViz, a companion to the WaveBuilder class. WaveViz accepts a Synthio readable buffer array and creates a display AO group object containing a oscilloscope-like waveform bitmap of any size or aspect ratio. The envisioned objective is to create Synth Waveforms with WaveBuilder that are saved to or retrieved from a library of sound sample files. WaveViz will be used to create thumbnails for each unique Wavetable file. The remainder of this week will be devoted to creating and testing the WaveFiles save retrieval code, hoping also to have time to assemble one of JP's fader wave PCBs. Fingers crossed that the Adafruit order of parts arrives on schedule. While testing WaveViz using a feather S2 and a 2.4 inch feather TFT wing, I occasionally saw a few miscolored pixels and edge-to-edge horizontal transparent lines. The symptoms were dependent on the bitmap's initial position and color palette, limited to just a few image origin locations. I was finally able to make it repeatable and drafted a circuit python issue. Before hitting submit, I disconnected all attached to WaveViz to confirm the error. Turns out that the unused and unselected and broken SD card on the wing slot was interfering with the display in a very specific and predictable way. Crisis averted. Very cool. And Seagrover dropped a nice picture of his progress in the chat for folks to see. And now we will hear from Dan. Okay, so I was late last week because my mother passed away on New Year's Eve Day. As you know, Scott's mother also passed away about a week before that. I hope this is not a trend. It's just an unfortunate coincidence. So I'm back, returning to continue work on 9-0-0 issues of which there are plenty to do. TAC has been working on updating the FW firmware for airlift forwards and is... I'm not sure if he's finished with that, but I have to check on that. That's a new thing to check. And the week before, in December, while a lot of people were at full holidays, I did some extra forum support, which I do from time to time to sort of see what's going on and to cover for those people who were taking time off so we would be able to help people even during that slow week. Okay. Thank you, Dan. And so sorry to hear about your mom. Next we'll hear from Deshi Poo. I didn't do much in the last month or so. I was on the commission and the plan is now to finally go and test the 9x version of CBIT Python on my boards to see what's broken, what doesn't fit anymore, especially with the new memory management changes. I'm afraid there might be some problems there. And yeah, that's it. Thank you. And now I'll read for DJ Devin, who's text-only. The Fitbit heart monitor I created to track my mom's heart rate came in handy this week, unfortunately. Had to take her to the ER twice over the weekend. Fitbit is not a medical device, but it can be useful for generic monitoring when I spend most of my time in front of a computer. I was able to catch her illness much earlier this time. Turns out we both have COVID. Sorry to hear that. Attempted to integrate FOMI guys' layers changes for his new soft keyboard library into my project, but there seems to be an issue with indexes. I can't figure out. And now we'll hear from ADCC. Thank you, Liz. Yeah, so first off, ADCC on ADCC is card columns. That's a shout back to my days with punch cards. Okay, so I enjoyed some time away from the computers for the holiday, and I hope everybody else did. Discovered, interestingly, that macOS Sonoma has two active implementations of its FAT file system drivers. The original that operates at kernel level and the new one that operates at user level. Each one is used depends on how the file system is originally mounted. A manual mount invokes the original kernel level driver while an automatic mount invokes the new user level driver. And it's that new user level driver that's broken that's giving us the delayed metadata write problems. And I'm also back to work on the Raspberry Pi 2040 Bluetooth with low energy, working through asynchronous event handling for characteristic value reads right now. BT Stack delivers a large number of events that it doesn't document. So I've been reading a lot of source code and doing a lot of experiments to get things working properly. So far, I've been able to maintain parity with the Nordic port. So that's it. Awesome, thank you so much. And now we'll hear from PomiGuy. All right, for the last couple of weeks I also took quite a bit of time off. I've been relaxing mostly with video games and building LEGO with my wife. We started a couple of different new LEGO projects and we've been working through them pretty quick, having lots of fun with that. I started to get back more into Cirque Python on Friday for the deep dive and over the past weekend. So in that time I checked out and tried the current draft state of the connection manager proposal. I took a look through that and tried it out on a device. I did some digging into a core issue that's created in GitHub that was in Vector.io specific to using the non-default rotations. So if you rotate your display by 90, 180, or 270 and you make Vector.io rectangles, they can end up being a little bit too big or too small based on the rotation. So I was digging into that. I did not come up with the solution, but I did walk away with a much better understanding of how Vector.io works and a couple of tests of things to try in order to hopefully learn more about it and get more towards the cause and the solution. The other main thing that I picked up over the weekend was my Pi Game Display library. I've been working on that off and on for a little while now trying to get it updated to be compatible with the newest version of Blinka Display.io. I've had varying levels of success, but so far I seem to be in this place where I can either get automatic refresh or manual refresh working. Once I get one working, the other doesn't and then I go and dig around for a while and fix the other and that breaks the first one. So I've gone back and forth a few times. So we're not quite there, but I am getting closer, feeling a lot better about it and I have learned a lot about how Blinka Display works, which is making it a lot easier and I didn't put it here in the notes, but I'll also mention that it's stretching my personal boundaries on working with threads and things like that. So I'm getting a lot of experience on that front, which is nice, but that's what I have got. Thank you. Great. And now we'll hear from Jepler. I can sympathize with the fun of being thrust into the world of threads when you weren't ready for it. Anyway. So last week I worked on some functionality for the Memento camera, also known as PiCam. In the examples for the library, there is now a JPEG viewer. It just cycles through all the JPEGs on the SD card and displays each one for about eight seconds. Then I started working on image filtering. So like blur, sharpen, sepia, and those kind of operations. And the first way that I approached that was using MicroLab. With MicroLab you can do bit operations. You can add two matrices of numbers together and it's supposed to be nice in performance. Unfortunately, it wasn't as performant as we wanted. It would take from one to four seconds to filter a screen-sized image on the Pi Camera. So I'm taking some inspiration and some code from the OpenMV project. They have what is called an image convolution filter. They call it morph. And you pass a convolution kernel to morph along with your image and it can blur it or sharpen it or perform some other kind of special purpose operations. And it operates on each of the image's three channels, the red, green, and blue, with the same convolution kernel. So that is in an open power quest that I think is a draft. And Lamor, in the internal meeting earlier, kind of outlined some directions to take that in so that it is a more flexible image processing thing. The OpenMV people, you know, they concentrate on things that are for computer vision and we're interested in what are the operations that people like to do on photographs. So we want things like Sepia and RedCast and BlueCast and Invert and Solarize that are more oriented towards just looking at an image and creating an artistic effect. And Morph alone doesn't cover all of that, but maybe with some additions it will. So that is kind of what is going on right now. And we'll just see where that goes. I'll probably work on it most of this week unless we get to a point sooner than that where we're like, yeah, this is done and we're happy. Thank you, Jebbler. Looking forward to it. And now we'll hear from maker Melissa. Hello. So I've been testing out Hardware on the Raspberry Pi 5. I've been updating the scripts and guides as needed. I've been working with the speaker bonnet, voice bonnet, and I'll be doing the brain graft hat next. And then I'm also continuing to get more of the Raspberry Pi setup scripts functioning with Bookworm. And that's done it. Great. Thank you. And now I'll read for Tectric. A fall semester of classes is over and while spring starts shortly, I'm excited to make more substantial contributions again. In non-starter Python work, I've been working on getting a personal website up that runs on Flask, learning a lot about web development and web servers as well. Hoping to take another look at my older PRs and resolve them. I've gone on from moving to pyproject.toml. A few PR reviews I said I'd take a look at if I signed myself to review. It please don't hesitate to ping me, so I don't miss it. Hoping to prototype a repository that uses typing stubs in an effort to remove the try except block used in libraries. I'll share what that would look like to see if it would still be helpful. I'm unsure if there's any specific reason that inline typing annotations are preferable to typing stubs, but I know if there is, for example, Moo can only understand use inline annotations. And that was stats updates. Next up is in the weeds. In the weeds is an opportunity for long-form discussions that either come out of stats updates or that folks have identified ahead of time. If you have any in the weeds topics, please make sure they get added while we're discussing other things, so we're not waiting around to see if anyone has topics. However, today there are two topics. First, by Tectric, who is not present, but I think folks here will want to discuss. I will read what he left in the document. Received an email that the Read the Docs projects need the webhooks in the repositories updated in order for triggered builds to keep working. And the text from the document, please manually, previously, manually configured webhooks from integrations did not have a secret attach to them. In order to improve security, we have deployed an update so that all new integrations will be created with a secret, and we are deprecating old integrations without a secret. You must migrate your integrations by January 31, 2024, when they will stop working. If you aren't using an integration, you can delete it. Otherwise, we recommend clicking on Resync Webhook to generate a new secret and then update the secret in your provider's settings as well. You can check our documentation for more information on how to do this. It seems enough to go to the project and click on the Resync Webhook button. It's worth noting that I'm unable to do so for subprojects I've created within the Circa Python Read the Docs project due to insufficient GitHub repository permissions. So someone full permissions on both Read the Docs and GitHub needs to do it. Happy to help in any way I can. Please ping me about anything I can do. And Jeff has just put in chat, Adafruit also got a message about a bunch of repositories. Tried this with some of the Adafruit repositories that are going to work. My assumption is that either something's not right at the organization level or my access level is not sufficient. And I see Dan's unmuted. So I would just say I was willing to take a look at this. And it is confusing that it seems to work for Techtrick and not for Jeff. So... But I have the privileges and Read the Docs admin account well again and things like that. I'm going to try to figure out what's going on. Maybe it just needs to... In worst case, we just need to generate new webhooks. And that's just a matter of a lot of clicking. So I'll do it in a way that doesn't cause carpal tunnel or something. All right. Excellent. Thank you, Dan. And the next in the weeds topic is from Deshipu. Fake file system What would you like to read? Right. So we had this discussion before Christmas. But the last meeting had a lot of in the weeds, so I didn't want to add to that. We can actually want some idea. It's not really that new. But now that we know more about the... being able to have multiple partitions on the USB drive we probably could have a fake file system in there similar to how the bootloader generates a fake file system that is not actually stored or uninstalled. It would be read only and it would contain diagnostic data basically. Data for the circuit Python, including the last exception if there was an exception when the last program stopped running. And the idea is that this could help a lot with support. Basically we could ask people to instead of linking them to the tutorial on how to get to the serial console and ask them to see the error and usually they wouldn't even copy the error. They would just tell us vaguely what the error is. We could instead just upload this file to this card and then we would have the version of the circuit Python and the exception, the full exception string in there that could really help us with the support and also on boards that don't have a display. It would help people to see the error without having to connect to the serial, which is non-trivial on Windows, for instance. And additional site advantage might be, this might be also used by Mew or Editor plugins to actually read the error and display this to the user in a friendly way. Maybe. I know that there are some editors that have this functionality. Vim has that, Emacs has that. So maybe we could even use that for this. So there is a link to the issue where there was some technical discussion on this. So on different ways this could be done. One possible downside of this, of obviously adding anything for all boards right now is a bit tricky because we don't really have that much space left as compared to the smallest board. So maybe this would be an optional thing that's not enabled on the smallest board or something like that. And another tricky thing is that it will probably use more memory because this file system has to be kept in memory, in RAM. But maybe we could only do it while the system is in the rep and not while it's running or something like that to work around that. Anyways this is just to throw this idea out there. Right, ATCC says that the big issue is with caching and in the issue there are several needs to possibly work around for that. There are certain USB events that could be sent to the file system to clear the cache. Of course we would need to do some testing, some additional testing to see how well that actually works. And personally I don't have the expertise to make that working to experiment with that. I might try it to learn about it and try something like that, but I think it's something that would be worth a try at least. That's all I have. Thank you. I think it's a very nice idea and the caching is the thing that we really have to look at. These USB events that cause the host to reread things to force it to declare that it should flush its cache. I thought we were using these events when there's an issue or PR about multiple LUNs, logical units and it didn't seem that it worked reliably on all operating systems but it might have been a different event that we were trying to use for those. I'm not sure. That was to try to get it to rescan to see that a new file system was available and I'm not sure that the event is the same or not. I have to look at that but that is really the thing that we have to see about that. But otherwise, yeah, it sounds like a great idea and it's very simple because MSC is always available and you don't need a terminal program or something to the output. Okay, that's all I have to say. All right. So I think that will do it. Thanks, everyone. And this has been the Sergipython Weekly for Monday, January 8th 2024. Thank you to everyone who participated and those in the weeds topics. If you want to support Adafruit and Sergipython and those of us that work on Sergipython, consider purchasing from the Adafruit shop at Adafruit.com The video of this meeting will be released on YouTube at youtube.com slash Adafruit and the podcast will be available on major podcast services. It will also be featured in the Python for Microcontrollers newsletter. Visit adafruitdaily.com to subscribe. Next meeting will be held next Monday as usual at 2 p.m. Eastern 11 a.m. Pacific actually is next week holiday. Yes, it is. It's Martin Luther King Day. That's right. It is Martin Luther King Day next week. So next week it will actually be on Tuesday at 2 p.m. Eastern 11 Pacific in observance of Martin Luther King Day here in the U.S. This meeting is held on the Adafruit Discord which you can join by going to adafruit.it slash discord to be notified about the meeting and any changes to the time or day such as next week. You can ask to be added to the Sergipython EASIS role on Discord. We hope to see you all next week. Thank you everyone.