 Hello everyone. This is the Circuit Python weekly meeting for September the 26th, 2022. This is the time of the week where we get together to talk about all things Circuit Python. My name is Tim, and I am sponsored by Adafruit to work on Circuit Python. Circuit Python is a version of Python that is designed to run on tiny computers called microcontrollers. The Circuit Python development is primarily sponsored by Adafruit, so if you want to support them and Circuit Python, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafruit.it slash discord. Behold the meeting in the Circuit Python Dev text channel, as well as the Circuit Python voice channel. This meeting typically occurs on Mondays at 2pm Eastern, 11am Pacific time, except when that coincides with a US holiday. In the notes doc there is 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 those notifications, ask us to add you to the at Circuit Pythonistas role on Discord. There is a notes document that accompanies the meeting and recording. The notes document contains time stamps to go along with the video so that you can use the doc to view only the parts of the video that interest you most. The meeting tends to run 30-90 minutes, so this gives you an option to skip around if you like. After each meeting, we post a link to the next meeting's notes document in the Circuit Python Dev channel on the Adafruit Discord. It checks the pinned messages to find the latest notes doc 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. That document tends to go up within a day or so after this meeting concludes, so you are free to start filling that stuff in early. You don't have to wait until Mondays to put your status updates and your hug reports in. You can put those in throughout the week as they come to mind. This meeting is going to be held in five parts. The first part is community news. This is a look at all things Circuit Python and Python on hardware in the community. It's a preview of our Python for Microcontrollers newsletter. The second part is the state of Circuit Python, the libraries in Blinka. This is a statistical overview of the entire project. It's a chance to look at the project by the numbers separate from what we're all up to. The third part and first of our two round robins is hug reports. Hug reports is an opportunity to highlight the good things that folks are doing. Take some time to recognize the awesome folks in our community and beyond. The fourth part is status updates. Status updates is an opportunity to sync up on what we've been up to. Take a couple of minutes to talk about what you've been doing since the last week and what you'll be up to in the next week until the next meeting. The fifth and final parts is in the weeds. In the weeds is an opportunity for more long form discussion. These discussions can come out of status updates or they can be something identified ahead of time as too long for status updates. So that covers how the meeting will go. So with that, I will get started on community news. And in the news pipeline this week, we've got first item is mainline Python 3.14 is predicted to be faster than T++. So in about a month, there will be a new yearly release of Python. This will be version 3.11. The main feature for this version is a significant increase in speed. People are testing the new version and their results are stunning. Extrapolating, keeping at this pace, it's estimated that Python 3.14 will be faster than T++. To be exact, the loop time will be 0.232 seconds. So it will be done just before you want to do the calculation. And there's a link here that goes to towards data science dot com with an article explaining and expanding upon this. Next up, we have Adafruit Penguin. This is a newly released tool and guide that shows you how to use any font inside of Eagle CAD software. Autodesk's Eagle software, this is the PCB design software favored around Adafruit. It has a problem. The circuit boards it produces, while perfectly functional, are somewhat ugly, with vintage plotter-like text and no support for custom fonts. Penguin is a Python script that substitutes true-type fonts for Eagle's ugly plotter-stroke text. It's open-source software and you can learn more at a recently published guide on the Adafruit learning system. There's a link to that in the note stock. Next up is a Tandy TRS-80 model 100 retrofit. This is a project detailing the retrofitting of a vintage Tandy TRS-80 model 100 portable device. This project is using a Raspberry Pi. The first step is to utilize the keyboard. The Raspberry Pi Pico, excuse me, Raspberry Pi Pico, is running circuit Python and being used to decode the keyboard matrix. Next up, actually, we'll be using a Raspberry Pi computer and a modern color display. If you're interested in this project, there is a link over to GitHub with more information about that. Next up is Aguana, a programming environment for MicroPython. Aguana is an evolving IDE for MicroPython on Windows. Aguana contains a code editor based on the ACE project, a terminal with REPL, a file manager, a downloader, ESP tool, and allows you to work with MicroPython via Wi-Fi and USB. There are links to GitHub as well as Robostart's website if you'd like to learn more about this new MicroPython IDE called Aguana. And rounding out the community news this week in continuing with IDE news, there have been two new features added to the Circuit Python online IDE. Two features that River Wing has promised for the Circuit Python online IDE have been added. One of them is a file modification indicator. The other is a true serial mode indicator showing whether the microcontroller is in REPL or running a script. There are links to Twitter and github.io, the page where the IDE is hosted directly. So if you'd like to learn more about those new features or if you'd like to give that Circuit Python online IDE a try, you can follow those links from the Notestock. And thank you to, I think it was Jeff perhaps for posting those in the chat for us. And that wraps up our newsletter items for this week. So as a reminder to folks, all of these items and many more came from the Circuit Python weekly newsletter. This is a Circuit Python community run newsletter that's emailed every Tuesday. The complete archives are available on AdafruitDaily.com. It highlights the latest Python on hardware related news from around the web, including Circuit Python, Python and MicroPython developments. If you contribute your own news or projects, you can edit next week's draft on github. You can submit a pull request with your changes. Or if you are not so familiar with github, you could also tag a tweet with hashtag CircuitPython on Twitter or email cpnews at Adafruit.com. And of course, a hard report to Anne for gathering all of these newsletter items and getting the newsletter published for us week to week. The next up is the state of Circuit Python, the libraries in Blinka. This is a statistical overview of the entire project by the numbers. It gives us a chance to look at the health of the project separate from what we're all up to. We'll talk about the project overall and then separately discuss the core, the libraries and Blinka. First up, I will talk about the overall section this week. This week across all Circuit Python repos, we had 34 pull requests merged by 17 authors, which is amazing. That feels certainly higher than normal, at least to my recollection. A couple of the names that were newer folks, perhaps less frequent contributors, or maybe even just people that I don't happen to recognize. But these folks may be new or less frequent. So thank you to them. Bill 88t, Alex Sporn, RTW Fruity, S-OL, Schnurma, and W-T-U-E-M-U-R-A. I don't know the pronunciation on that one, I apologize. But thank you to all of those folks as well as all of the rest of our contributors across Circuit Python and the libraries and related repos this week. We had 11 total reviewers this week, and that does look mostly like the usual suspects. So thank you to all of our reviewers for continuing to help us get PRs reviewed and merged. We had 27 closed issues by 11 people and 14 opened by 11 people. So we're down a decent chunk of issues for the week. And so next up, we will talk about the core a bit. And if you're available, Jeff, I'll pass it over to you to tell us about that. Happy to. So the core is the part of Circuit Python that's implemented in C. And you typically put it on your device as a UF2 file. And within the last week, we had 11 pull requests merged from eight authors, and already nice Bill 88t again, S-OL, W-T-U-M-U-R-A, or however that's pronounced, and Sneaky Maker Cat as less common reviewers. And I just want to jump back up to reviewers, really appreciate seeing Liz in that list, BlitzCityDIY. So I know you're getting up to speed and happy to see you in that list. Anyway, back to the core. We've got 19 open pull requests. And the first seven of those have been open for a long time. They are waiting for the next step. And if you are waiting on us, core developers, please give us a ping on those so we can help you. Other than that, we've got a bunch of pull requests that are under 20 days. So that's pretty good, including a couple that are open zero days. Issues wise, we have 17 closed issues by nine people and eight open by seven people. So we're down a little bit on issues. And it's always nice to see that. We have a total of 570 open issues. But we organize those according to milestones. And right now the milestone to keep your eye on is the 800 milestone. We have 33 open issues we would like to resolve before we release a stable version of CircuitPython 8. And we've got four issues not assigned to milestones. So somebody needs to take a look at those probably me or Dan, and assign them. And happy to see the milestone counts back. Hug report to whoever that was that re added them early hug report. So anyway, narrative wise, our focus is on moving towards the stable release of version eight, which is what it's been for quite some time. And last week, Dan and Catney and I all met and went through the open issues that were tagged 800. We transferred some of them to 8xx, which is a new milestone. Those are minor bugs or improvements that we don't want to hold version eight for. And others we move to long term, which means Adafruit doesn't prioritize them right now. Although we're happy for anyone to pick up one of those issues and work on them. Yeah, so stay tuned to help us test out 80 report problems. If you run into them, help us fix the issues and we will get there when we get there. And that is how things are going on the core. Thank you, Tectric. Excellent. Thanks, Jeff. Next up, I'll send it over to Catney to tell us about the libraries. Thanks, Tim. This section applies to all the Adafruit Circuit Python libraries, which is everything that starts with Adafruit underscore circuit Python underscore as well as a few extras like our community bundle and our cookie cutter. So this week, across all those repositories, we had 19 pull requests merged from nine different authors, including a couple of the names that were read off above, and eight different reviewers. I want to point out that two of those merged pull requests were 54 days old and 163 days old. So I'm really excited to see that we're still tracking away at the older PRs. And we're keeping up with new ones. Very, very good. So that leaves us with 37 open pull requests. In terms of issues, we had nine closed by two people and four open by three people, leaving us with 596 open issues. 133 of those are good labeled good first issue. If you're interested in contributing to Python on the Python Circuit Python on the Python side of things, check out circuit python.org slash contributing. You'll find all the information posted here and more, including open pull requests, the list of open issues. And some library infrastructure issues as well. If you are interested in reviewing, check out the open pull requests, see whether there's anything you have hardware for test it if you do. If you do not take a look at the code, see what you can see. If there's syntax issues or cleanup to be done, leave a comment, let us know. And once you're comfortable with that, we can talk about leveling you up to the review team. If you're interested in contributing code or documentation, check out the open issues. There are many of them. But you can, they're listed out by repositories so you can sort of go through them and the titles are all available there so you can go through them and see if anything strikes your fancy. If you are new to everything, good first issue is is a good label to start with. We also have a guide on contributing to Circuit Python using git and GitHub, as well as the fact that we're always available on Discord to help out. So don't let the process intimidate you if you are interested in contributing, we are here to help. In terms of library updates in the last seven days, there is one new library, Adafruit Circuit Python BLE beacon, and a number of updated libraries that are listed in the notes, but I won't read them off individually. That's what I've got. Awesome. Thank you, Catney. Next up, we will hear from maker Melissa telling us about the Blinka Hello. So Blinka is our Circuit Python compatibility layer for MicroPython Resort by another Cigaboard computers. And this week we had four pull requests merged by two authors and one reviewer. There are currently six open pull requests. There was one closed issue by one person and two open by one person. And that leaves a net of 84 open issues. There were 12,680 pie wheels downloads in the last month. And we are currently at 91 ports. And that's it. Awesome. Thanks, Melissa. Next up, we will get started on the first of our round robins, the Hug Reports section. Hug Reports is a chance to highlight folks in the Circuit Python 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're text only or missing the meeting, but have hug reports in the notes document, then I will read them off as we get to you in the list. So my Hug Reports this week, thank you to C Grover for making and sharing a palette filter library that makes it easier to manage transparency color indexes inside of display I.O. palette objects. That's a super neat utility that I think we'll be able to get lots of interesting stuff done with. And then Hug Report to TC Franks. Thank you that they have submitted many, many different typing PRs that have been on a tear of typing PRs lately as well as other improvements across the library. So definitely appreciate their contributions. Next up is C Grover, who is text only. So I'll read theirs. Hug Report to Tectric for the speedy review and merge of a community bundle submittal. Hug Report to Fome Guy, me for testing the palette filter library. And Hug Report to Paul Cutler and Todd Bot for the first in a hopefully long series of the bootloader podcasts walked away from today's episode with a couple of cool nuggets. Thank you C Grover for putting those hug reports in. And next up is Dan. Hey, thanks. First thanks to Snakey Maker Cat for their first two PRs, which we're adding file name support, direct file name support for web file and mp3 decoder. Thanks to Jeff for taking a break from Pico W to fix some 8-0-0 bugs. That's very much appreciated. Thanks. As Jeff mentioned, Catney and Jeff and I had a bug and triage meeting last week and that was really helpful. We're reducing the number of things we really need to do. We think we have to do for 8-0-0. Thanks to Jeff for making great progress on the Pico W implementation. That's looking at very nicely, it seems. And thanks to MicroDev finally for a bunch of PRs and reviews of other PRs and some other and other contributions of various kinds. Okay. Next in next up is David Galada, who's not speaking. So I'll read Hug Report to Todd Bot and Paul Cutler for the new bootloader podcast. Hug Report to Jeff for the progress on the Pico W. Hug Report to AnikData for the HTTP server example. Hug Report to Maker Melissa for treating my circuitpython.org PR, probably reviewing or testing maybe. Hug Report to AT Maker's bill for helping produce his USB filter hardware slash software. And lastly, Hug Report to Phil B for making it possible to use the papyrus font on PCBs made with Eagle. So next up is DJ Devon 3 who's not present. So I will read. They have a Hug Report to me, a foamy guy for hosting the meeting. Hug Report to C Grover and foamy guy for advancing circuitpython graphical capabilities. It's been a lot of fun seeing all sorts of new possibilities take shape. Hug Report for Todd Bot and Paul Cutler for hosting their first episode of the bootloader podcast. We shared some interesting stuff that DJ Devon had no idea about. Hug Report to Lady Aida for designing a really neat step switch breakout. The footprint alone should help Synthaholics with their PCB designs. Hug Report to Jepler for launching the Pico W demo during show and tell. Really exciting development. And lastly, Hug Report to Neerdoc and Todd Bot for helping with some code that got my step sequencer working. Python zip isn't for zipping files. The zip class is exactly what I was looking for. And so next up is Jeff. Hello. Yeah, first I'd like to give a hug report to the Pico SDK and MicroPython authors who I don't know individually for all the groundwork on the Pico wireless networking that I built on. And this isn't written in the document right this second. But thanks to everybody who's giving me some recognition for this. I really appreciate that in this work people notice what I'm doing and thank me for it. That's I know that's why we do hug reports, but it's really nice to hear. And I want to particularly thank some community members who've given me feedback on the unprogress PR and on the related issue and the two that I spotted when I was just reviewing it really quickly. This is not an exhaustive list for Anik data and Bill 88 T. And finally to Tectric thank you for fixing the milestone reporting for state of Circa Python, even if you are the one that broke it in the first place. I think without looking that that code is probably in a better place than it was before you started breaking things so keep it up. That's what I've got. Thank you. Excellent. Thanks, Jeff. Next up we'll hear from Katnie. Hello. So my first hug report is to Argonne Blue from Discord, who recently became a community helper on the Adafruit Discord server and has been helping out in so many places. They're filling out that role in so many ways. And I continue to be impressed. The thing that sparked this was that they have thoughtful and very informed answers in many, many different genres, many different topics that are not similar. So I'm always kind of blown away when they pop up again in another channel with another great answer. To Nerodoc for helping me out with some questions that potentially eliminated me needing to do a PR. I did look back and do it. I think I do need to do a PR. But there was some stuff that I had completely forgotten about and was looking at it completely wrong. So Nerodoc absolutely helped that out. To Tammy makes things for always being available for a chat, whether it's needed or simply wanted. And a group hug to everyone else. This community is amazing. I'm so glad to be a part of it. I'm so glad to have joined. I'm so glad to now be leading it. I appreciate everything everybody does. So thank you very much. For great stuff. Thank you, Ketney. Next up is maker Melissa. Yeah, I wanted to give a tag report to Jipler for trying to help me figure out the serial port speed and whether it was always the same and certified one and group hug to everyone else. Awesome. Thanks to Michael Melissa. Next up is Mark gambler who is lurking or text only. So they have a hug. Mark does for Nerodoc for random answers to a few questions all last week and anecdote for one as well. And then next up is Tammy makes things. Thanks. So I just have a group hug to everybody for being awesome. Well, thank you, Tammy. And next up and rounding out the hug report section is tech trick. Yep. So a group hug. Sorry. Well, I guess we'll start there. A group hug to everyone. A hug report to you for me guy and the cat me for helping me navigate issues as a reviewer. You and the community at large has been always pretty great and awesome at providing support to me across all parts of the contribution process. So much appreciated. A hug report to Nerodoc for teaching me that the RP 2040 can use blinker and stopping me from giving bad wrong advice to someone on GitHub on a GitHub issue. So thank you. And to TC Franks, as mentioned earlier for keeping up with the type imitation PRs. It's super awesome to see that number of missing type annotation PRs dwindle down closer and closer to zero every week. Right. Thank you, tech trick. And that finishes up the hug reports section. So next up, we will do the status updates. Status updates is our time to sync up on what we're doing. I will start and we'll go through the list alphabetically to give everyone a chance to participate. 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 much for status updates, then we can move it down to the final section in the weeds. So I'll get started on our status updates. My status updates for this week. I implemented an option for a horizontal line in the middle of the flip clock sprites inside the generator. There's now a new lag you can pass to enable and disable the horizontal line that kind of looks like the fold in the middle of the clock. I resolved the remaining pilot and pre-commit issues to get that library prepared to add to the bundle. I tested out and showed off sea grover's palette filter library on deep dive last week. And I updated the MPY file size actions task. That's a open PR on the cookie cutter. We've also been doing some testing on one of my own forks of one of the libraries. That has been updated now based on feedback from last week's meeting to compare the size with the current main branch rather than the MPY file that is currently in the released bundle when it makes those comparisons to post comments on the PRs. So that changes now in as well as one other change that adds a summary section with some of the high level stats and differences about the changed library. Next up is sea grover who is text only. So I will read shifting back to the Eurorack range slicer module refactoring converting it to a state driven approach will also investigate async IO and its impact on time critical events submitted a palette filter library to the community bundle. Its primary purpose is to convert a range of color values based on a visible spectrum algorithm your replacement color value or to transparency. Planning to develop additional display palette tools perhaps a palette optimizer to reduce palette size by calling unused or duplicate palette index entries stuff like that. The line is beginning to blur between bitmap tools and palette tools. And the last thing that sea grover's got is that fall yard work continues removing more lawn pouring concrete and moving a ridiculously large pile of decorative rock. The goal is to reduce water consumption and waste by another 50% sounds nice. Next up we will hear from Dan. Okay, thanks. So I was off for a few days last week away from away from work. I came back on Sunday and reviewed a bunch of pending PRs and kind of contribute to stuff that that kind of stuff. What I'm doing starting after the meeting is I'm going to be testing power consumption during deep sleep. We have kind of a lot of variation in how much power boards use when they go into deep sleep. And I added a feature to turn to flip pins into certain states to hold pins and in certain states. When you go into deep sleep, but it's not getting the power down to the level that I might expect on some board. So I'm going to investigate that. And the other thing to do is probably just to make an 808 beta one because it's been several weeks, or maybe even a month or a couple of months. I don't know. And we may as well catch up. Sometimes I like wait for a big thing to go in. But it's probably it's actually not worth it because it just makes the release notes longer and longer and longer. So maybe I'll make a release sometime this week. Okay. Alright, thanks, Dan. Next up is David Galata. It's not speaking. So I will read. Finishing the external display PR for circuit python.org based on the results of the vote during last week's meeting. Long exchange with AT makers built replicate his USB filter, which is a trinket doing USB host in Arduino to convert essentially over you, you are back to a circuit Python board. In this case, the QDPI RP 2040. That trinket will read data coming from the USB device and send it over to the circuit Python QDPI or any circuit Python device. Installing Eagle and Arduino 2.0 to be ready to adapt and replicate documenting the let's see documenting ingest some of my research notes before closing all the tabs. We've got some stuff for USB host in circuit Python and alternative P2S no PS2 IO support in circuit Python. PS2 dev how to pretend to be a PS2 keyboard with Arduino. So if anybody is interested in any of those things, David has compiled some notes together and put links over to just inside the notes doc. Next up is DJ Devin three who's not present. So I'll read a Laura messengers still on the back shelf. No progress on that one this week. Designed a new version 1.2 of the stacks step sequencer called the tr cowbell. It now has a Stemma connector Stemma breakout nine GPIO breakout. It runs on the Raspberry Pi Pico. Learn let's see learned how to use a font as a solder mask layer so that the font is exposed copper. Got a hardware test functioning thanks to Todd by giving a hint to use a zip class watching all the little lights sequentially running made me giddy and to do a happy dance. It's got papyrus font on the back. It was tested with and runs on circuit Python beautifully. Pretty sure I ironed out all the major hardware bugs and ordered 20 PCBs they should arrive in about two weeks. There are some very nice photos of this board this custom board with all of its artwork in the note stock as well if anybody is interested in PCB artwork. There's some great stuff over there to check out. The last thing from DJ Devin mentions Hurricane Ian is on its way to Florida and it looks like it might be looks like DJ Devin might be getting hit along with millions of other Floridians. I'm on the east coast east coast so less of a worry but still might lose power and be out of commission for an unspecified amount of time as a deal with cleanup. Pretty sure the Ruiz brothers are in the same boat hunker down and stay safe course to everyone in Florida or anywhere where there is implement weather certainly. Next up is Jeff. All right. So last week I published a draft pull request for Pico W Wi-Fi support. There is no SSL or HTTPS support yet. There is no support for servers yet and it needs stability improvements. But we are ready for you to test and report your results. Grab the UF2 from the actions of the pull request and leave your comments at the issue 6558 on the circuit Python repository. Besides that I made pull request for several issues blocking the 80 over lease. I need to go back and check the status of all those and make sure there's not something I need to finish on them. I have completed the code and text for my next guide a Tandy 1000 keyboard to USB converter using circuit Python and QDPI RP 2040. And I investigated using Python to pre process static craft out of libraries before MPY compiling. And while doing that, I ran into a project called AST monkey, which will essentially let you parse a whole Python module into a high level representation, make changes to it, and then write it back out. And that AST is abstract, abstract syntax tree. I hope I said that right. Anyway, the code had some bugs and I was able to fix some of them. So I put out a pull request for that. This week, I will finish and publish the guide. I want to get it done before the end of the month because Tandy aficionados designate this month as the month of sept handy. My last 800 bug that is assigned to me is a reported SDIO problem on the grand central M four. So I need to test reproduce and fix that. And then I will return to the P go W work. First up bug fixes. If any of the well, some of the time it will fail after doing a certain number of things and then it won't work until you power cycle it and that's a clear bug probably in my code. Some of the other stuff, I will work on replicating it in micro Python. And if a similar problem exists in both platforms, then it's time to say to upstream, Can you look at this? Once that is merged? Oh, and I need to add support for servers. Once that's merged, I am going to investigate into the feasibility of support for SSL including HTTPS connections. Based on my quick survey, it looks like the Pico SDK does not have support for this. And micro Python support is limited to having a certificate for one single server that you just put in a file on the drive. And that's quite different from what we do with the ESP 32, where we have the whole set of certificates very similar to what your desktop browser would have. And if we can't do that with the Pico because of the flash size, we'll have to either punt or come up with some kind of plan B. But that I need to investigate before I throw in the towel on that. But those are the hurdles that come ahead. Anyway, and for the future, the next keyboard on deck is the next non ADB keyboard. And there was a guy previously done a decade ago on Arduino by Lady Eater herself. So I've kind of got a really direct path to to the endpoint because I'll be able to study that code and just reimplement it in circuit Python on the RP 2040. So it should be fun. But it'll be three or four weeks till that guide comes out because other stuff is going to be in the front burners for a while. That's it. Excellent. Thanks, Jeff. Next up is catney. All right. So last week, tested the MCP 9600 breakout temperature sensor frequency options due to a vague comment in the simple test that said frequency must be set for this to work. And then the next comment said if you receive if you get IO errors, try changing the frequency. It didn't explain what frequencies to try, or what the context was. And I vaguely remembered it. And I think I had no idea what was going on with it, but I was told that. So I added that comment verbatim with no background understanding. So the point is I did not have anything to bring to the table when told to find out what other frequencies worked. It turns out, on the M4, no other frequencies worked, except for the default because the chip couldn't go over 100 kilohertz. And the circuit python on M4 doesn't support very far under 100 kilohertz. So the more we looked into it, Carter helped me out. We realized that it may be just a pie issue, raspberry pie issue. So we ended up removing the comment altogether, adding a warning in the guide about the pie clock stretching with a link to our pie clock stretching guide page. In the process of this, I also realized the documentation and guide explanation for the delta temperature feature were atrocious. Yes, I wrote both. And so I updated both of them to be significantly more informative and clear. Next up, I was supposed to do the stomach QT revision of the quad alphanumeric backpack next, but needed verification on where the update was supposed to go. So instead, I started on the LTR 329 and LTR 303 breakout guide. Same chip 303 has an it pin got through a couple of pages there. The LTR 329 was delivered, but the 303 was not yet in stock. Find out where I was supposed to put the QT revision. So I put aside the LTR guide and started on the QT revision of the alphanumeric backpack, and I'm about two thirds of the way through that. So this week, the backpack QT update needs updated wiring diagrams, and then the applicable pages updated with those diagrams. And then that I believe is it for that. I will be testing a circuit Python issue 6676 because I am 98% certain the issue reported was something I did in my last project. And I have no issues with it. So I'm going to go back and test it with a smaller script because my also my code was pretty complicated. Test it with a smaller script and see whether or not the issue is still present as possible. We fixed it, close the issue if it's resolved. Then I'm going to pick back up with the LTR 3x guide. And the LTR 303 breakouts are on my porch. Following that, I'll be adding the Metro mini v2 to the Metro mini guide. And beyond that, my next quest is a mystery. That's what I've got. So thank you, Catney. Next up is maker Melissa. Hello. Last week, I fixed the BLE connectivity issues in the code editor. I started working on the USB workflow after that, though it's proving to be a little more troublesome than I thought it'd be. And I'm helping, I helped rent troubleshoot while whippersnapper little FS partition was no longer working. We got that all working good on the ESP32 boards. This week, I am working on trying to wrap up the USB workloads actually pretty close now, but I'm currently stuck on finding a reliable way to detect if the user hits cancel on the file dialogue. After that, fix the BLE upload issues, and then I'll get all the recent changes bundled up and made live. And other than that, I finally finished a huge sorting project with all my electronics and 3d printing stuff. And I'm working on moving it all out of my office by the end of the week. That's it. Excellent. Thanks, Melissa. Next up is Paul Kotler. Tim. Last week, I recorded an episode of the podcast with Jim Muzerad from MicroPython. That was fun talking to him. This week, thanks to thanks for everyone's comments and listening to the new show, the bootloader with Todd bot that's out today. And then later this week, I'll be taking the circuit Python show on the road, I'll be driving about 90 miles east to Wisconsin for a special Halloween episode. So keep your eyes open for that. I'll be at the community help desk this Thursday with tech trick and next week I'll be out because I'm having very minor hand surgery. Thanks. Alright, thanks, Paul. Definitely hope for a speedy recovery there of your hand. Next up is Tammy makes things. Hi, so last week, last week, I didn't work on a circuit Python stuff a whole lot. My day job was ridiculous, because two weeks ago we had no internal meetings week in my company. And so last week turned into all of the internal meetings week, and I had like 32 meetings, which is a lot of meetings. But I worked a bit on the issue I was running into with circuit and extended attribute files on Mac OS Ventura beta. I discovered that Mac OS has an x at her command, which removes or manipulates the extended attributes on files. And the x at her Python module installs its own x at her script with different command line arguments. So I need to test whether getting the x at her modules version of the commands out of my search path helps the issue that I've been seeing. And if not, I'll move forward with the fix that I'm working on. So I'm going to do that this week. I'm also carving out some time for PR reviews and figuring out that issue. And I think I finally have a workaround for the Mac OS Ventura issue that broke my OBS and is currently preventing me from streaming. So hopefully I can get that fixed. And that's what I got. Alright, thanks, Tammy. Next up in rounding out the status updates is Tectric. Yep. So last week, I set up OBS and prepared for the Community Help Desk stream this Thursday. Shout out to I think Catney, who helped me figure out the file format needed so that if slash when my computer decides to shut down and stop recording that I won't lose everything, I think I fixed an issue again caused by me worried about wasn't reporting open issues for the milestones. I finalized and added my first library to the Adafruit Circuit Python bundle, which is the new BLE Beacon library for working with Bluetooth Beacons. Currently, it allows for use with iBeacons. I added the ability to Blinka for to update the Dunder version attribute before uploading to PyPI similar to the libraries. Additionally, Blinka also now builds up your Python wheel, which should cut down on both the install and setup time when you're installing via pip. I continued working on the GitHub action for creating my py files for releases, the intended uses for personal projects where you can release it and it will compile all of your code so and attach it to the release similar to the way the libraries do it. And in terms of personal projects, I wrote some of my first real dash scripts for uploading firmware and software to a QPyS2, which is going to be helpful for my Circuit Python Nukia project. When I start making a bunch, it'll be really easy to automate the build process if I can do that. This week, as mentioned, I'm hosting the Community Help Desk this Thursday to help people get set up for Hacktoberfest. I walk through the whole process. So from signing up for Hacktoberfest to looking at some or pointing to some guides for getting started with Git and GitHub and whatnot. So if you're interested, tune in, I'll try to go over every day. Reviewing all of the outstanding type annotation PRs is also on my list this week. I'm going to continue working on that GitHub action for adding my py files to releases. And if there's time, I'm hoping to revive some of the work I previously did to add the image transfer functionality to the Blue Fruit Connect library. I almost deleted all my progress during the cleanup of my repositories and a totally intentional reinstall of my operating system. But luckily, the microcontroller I previously used for testing had the code. So working as intended. Nice. Thank you, Tektrick. I've definitely been saved by that more than once myself as well. All right, so that is it for status updates this week. So next up in our final section is called in the weeds. In the weeds is an opportunity for more long form discussions. These can either have come out of status updates, or they can be identified by folks ahead of time. You have any in the weeds topics, please make sure they get added down at the bottom of the note stock. It looks like we do have a couple if anyone else has any more than please do go ahead and add those now. So we're not waiting around once we get to the end. The first in the weeds topic is from David, who's not speaking. So I'll read this one. Should we have a camera? Should we have camera as a feature on CircuitPython.org? And if so, what board? Please have a look at this issue, speak out or put comment on it once speak out or put a comment on it. And once the dust settles, then David will make a PR for it. So that is over on CircuitPython.org. See if we can get this one. Chat there. And I don't know if anybody else has thoughts on this. The first thing that comes to mind for me, though, is that I'm not aware of any devices that have a camera built in. So I would probably lean towards not including camera as a feature listed on CircuitPython.org unless or until we do have a device where the camera is built in. But that's just my take on it. And I could also be wrong about that device not existing. So so there are a couple of devices with a camera built in. There's an as yet unreleased Adafruit device. There is there are two development kits from expressive. And then there's a third development kit from expressive that has a standard header for a camera. But that's a total of about four boards. Three, if you don't count the unreleased one, two, if you don't count the the one that only has a header. And I think, you know, having fewer than 1% of boards have a feature means we probably shouldn't list that feature yet. So for now, I would defer any action on that personally. That's just my two cents. And this presence board was mentioned, it's there's a separate camera and there's a carrier board for this presence. Oh, that's true. I do have that board. It does have support in CircuitPython. And I've never tried it. So three boards, yeah, are manufactured and have a camera option. Right. I mean, it's partly you can tell because there are built in modules in most cases. It's gonna be my question was, are there built in modules specific to the camera functionality? I did test out one. Yeah, but I don't recall there are now there are now three different ones. So for RP2040 or for Grand Central M4, there's image capture for expressive boards in version eight, there's ESP32 camera, and then the presence board has a different API. So there are three APIs for camera, which isn't great, but that's the way it is right now. But those at least are shown presumably as the built in library. So people do have a way to discover which devices they can work on today, even if we don't have that listed as a feature specifically. Anybody else have any thoughts or ideas around the camera feature for circuit python.org? Not for now. Okay. Next up, I will pass it over to tech trick who's got other in the weeds topic or second in the weeds topic, I should say. Great. Thanks. Yeah. So I just it's relating to a PR I submitted. And it's really just checking if there's any kind of issue with this PR, which is API breaking. It's for the mini MQTT library. What it does is it sets the init function to use I think, without looking at it, I think all keyword only arguments provided. The idea there is that there are currently just a lot of arguments provided. So forcing them to be keyword only prevents mixing up some of them, especially ones where I think there's like a couple timeout ones. So you want to make sure that you put put them where they go where you want them to go. As a note, I believe I checked the libraries and the guides that use it. And I couldn't find any uses where they were being used with positional arguments. I know the guides in particular are currently using keyword or keyword argument only or keyword arguments. So I didn't know if it was used anywhere else, or if this is going to be a problem. So I just kind of wanted to ask more publicly. Okay, so there are also other libraries that rely on this library, I think. Yeah, I'm looking at it right now, though, like looking at a guide that's Adafruit IO and it's not there. So maybe I'm mistaken or maybe this guide is kind of old. So maybe it does now. But we would need to make sure that the implementation in the libraries for which it is a dependency are also not going to break. And you said you you look that up. Yeah, I looked it up. The Pia has been out for a little bit. So I did it a little bit ago. But when I looked at the libraries, I believe that they were not that that they all use keyword arguments. So they're all specifying their their arguments already. So I would say this is fine, then. The big key is that when you release it, you need to do a major version change, which is how we indicate that it's basically a breaking change, or that there's some vastly new feature or something like that. But in this case, you you for for breaking changes, you always want to do a major version bump. So if it's, you know, for dot two dot one at the moment, do a five dot Oh, dot Oh. And put in the notes, why it's a breaking change, and perhaps even put in the release title that it's a, you know, API breaking change. And then that's about the best we can do. Is there documentation in it that needs to be updated? No, I don't believe so. I think all of the arguments are specified. Yeah, I don't think there's I think that that was the only new change. Okay. Well, I say I say do it. Do it as I just suggested and then keep an eye out for, you know, for things that break. Yeah, no, I can definitely do that. And that way, you know, we're at least we're aware of it. So it's not a surprise. But I would say I would say go for it. Okay. Yeah, I'll triple check to make sure that nothing's going to get on, especially the libraries aren't going to break. But yeah, if so, I'll do that then. Thanks. Sweet. Thank you. All right. Yep. Thank you. Yeah. Yeah. I have a question. Is it possible to load a previous version of a library from PyPy? Well, from PyPy, you need to specify, I think you do like equals equals in the name, if I recall right. So like ordinarily, it would be like, you know, pip install Adafruit, Circle Python, mini MQTT, you would do like pip install Adafruit, Circle Python, mini MQTT, equals equals, and then the version you want. And that would match the release tag that you can find on the releases pages on GitHub. Speaking of the releases pages page on GitHub, the MPY file will also be uploaded to there as well. So that may not be easier, depending on your familiarity with PyPy. You can just download the MPY from the old release page and then copy that to your device as well. Yeah, because I have a couple of projects that use the current version of mini QTT before all these changes started to happen. So I just wanted to make sure I could temporarily. Absolutely. Both using PyPy and Circle Python. And obviously you can go to the releases page and download previous versions as well. So you'll have access to all of that. It's not going anywhere. Okay, so good. That's all I wanted to know. Thank you. Next up, and our last in the weeds topic is from Dan. Thanks. So it was brought up, an issue came up 6930, which is like noting that there, the BLE implementation in the expressive is partial because it's only peripheral. Preferably peripherals. And if you try to use that as a central, you get a not implemented error. This is implemented. This is mentioned like in a learn guide, but it's not really mentioned anywhere else. And I think the user said it wasn't in the read the doc. So this is kind of an example, a specific example of a more general problem that there are limitation known limitations on certain boards, even if they do have certain modules listed in certain Python.org. And the question is, where would we put these kinds of limitations? They could go and read the docs. They could go only in the learn guys. They could go on the board page on circuitpython.org. All of those places, when someone buys a board, sometimes they say, I was thought I bought a board to do X. And it turns out it doesn't do that. And they would have had to sort of study something, maybe the learn guy, most specifically, but in general, they might not know. Or another example, which is kind of comes up is that people buy an M zero, a sandy 21 board, and they find out that it just doesn't have enough RAM to do what they want. That's kind of a more general problem. But how might we document these kinds of limitations? And where might they go? Maybe they need to go in multiple places. Right now it's basically done by hand in the learn guides. I was wondering whether people have any ideas about this. I do think read the docs definitely makes sense, but I don't think it's necessarily like as an alternative to the learn guides. I think it should definitely be noted there as well, because the learn guides are typically linked from the product pages. And I think there's lots of folks who know and are familiar with how to find and read the learn guides, but maybe not quite as familiar with how to find and read the read the docs pages. But I do think read the docs would be a great place to list it. So in this case it would be in the inline doc strings inside the core, I think. So should it be obvious on the board page that there is this limitation, or would you have to click on the module? Suppose in this example you'd have to know to click on underscore BLEIO to find out that in fact it's only half of the BLE implementation. It seems to me that it would be good for it to be, I mean it could be in the product description, we don't have a lot of control over the product descriptions. I mean we do. We just need to. We obviously can't edit them. Yeah, yeah, but we need to inform the folks who can. Yeah. I think the product description would be a really important place to put it, because that's people aren't going and reading the support matrix, right? Like when they go to buy a board, like they're reading the product description and it says, you know, oh BLE supported and then it doesn't make it clear what's going on with that. And like I know what you're talking about. I've run into this on Discord folks complaining about that. Like, oh it said that BLE was supported, but it looks like it's not. You know, I'll use Wi-Fi, but that's disappointing and I'm like, oof. Yeah, so I think it should be multiple places and maybe there needs to be some kind of. I mean, it couldn't be in read the docs. It can be on CircuitPython. Or it can be in the product description. The product description is not maintained, right? It's maintained it by hand, like a lot of times. So. And if we, for instance, we did implement, say, BLE central, we'd have to change a lot of product descriptions. Maybe that's just something. Well, I don't know that we need to get that specific. Yeah. Like there's a couple boards that in the product description, it literally says BLE is supported. Also it supports CircuitPython. That's unclear. Yeah, I agree. So we could reword that. Or like CircuitPython BLE is currently in beta. Like yeah, we would have to go back. But like those, I don't think it has to apply to all of the BLE boards. Like not the product description changes. I mean, just specifically to the ones that are kind of misleading at the moment. Okay. I don't think they all are. All right. Because there's a lot of copy pasting. Yeah, exactly. I mean, I think there's some kind of internal thing about maybe the product description should be more, they should have mirrored paragraphs or something. We don't really know. Yeah. I mean, that's tough. Yeah, it is right. It's not going to happen. To change up that whole system. Just like it's tough to change up any whole system that we're dealing with at the moment. Yeah, it might also be in the board on the CircuitPython.org page for the board. Yeah. And I do agree with that. That we have control over and that we could add. It's often per port. It could be per board. So there could be a file, a text file per port or per board that gets sucked in to the CircuitPython.org dash or build process and put in as a separate gray box or something like that. Or at the end of the description or something. I don't know. So I think it's worth thinking about. Yeah. I mean, I'll end up opening an issue maybe, but that's a good, I'm glad. Yeah, I'm glad that this seems to make sense to you. We do need something like this. I think as we have more and more things that are not. Not fully implemented. Right. And the same thing is true of like ESP30US3O. The I2C doesn't work all the time. That would be nice. Yeah. And like C3 as well with what we don't have going on there. Exactly. Exactly. So all right, so I'll think about this a little bit and maybe it'll happen eventually. Okay. In some way. Okay. Thank you. Anybody else have anything? Suggestions. All right. That was the kind of discussion I wanted to generate. All right. Extend. I'll just read Seagrover's remark. Seagrover suggests we need a pretty pins or badges approach to included features and circuit Python modules. I think it would be great. Visual things are great. So I'm starting to keep in mind, I suppose. All right. And Naradak says in general, the shop page should also say circuit Python support is in alpha. There might be missing features and instability on C3 and S3 and C3 and the like, such as it used to say on the Feather STM32. Yeah. And I agree with that. And we can inform. There are people who maintain the new products pages and we can just send them emails about this. So we can do that at least to start. Yeah. Okay. All right. Thank you. All right. For sure. Yeah. Thanks, Dan. Let's see. Let's get back to the dot stock here. So that was our last in the weeds topic. So we will wrap it up as a reminder to everyone. This has been the circuit Python weekly meeting for September 26th. Thank you to everyone who participated. If you want to support Adafruit and circuit Python and those of us that work on circuit Python, consider purchasing hardware 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 made available on major podcast services. It will also be featured in the Python for Microcontrollers newsletter. You can visit adafruitdaily.com to subscribe to that. The next meeting will be held at the usual time next Monday, which is the 3rd of October at the standard 2 p.m. Eastern 11 a.m. Pacific. So we hope to see you there. It will be on the Adafruit Discord, same as this meeting, adafru.it slash discord. And if you'd like to get notified about the meetings or any changes to the upcoming days or times, you can ask to be added to the circuit Pythonistas role on Discord. We'll always make sure to ping that role with any changes to the meeting. But as a reminder, we are set for the normal time next week Monday at 2 p.m. Eastern time. So we hope to see you all next week. Thank you, everyone, for participating. Thanks, everyone.