 Hello, everyone. This is the Circuit Python Weekly for June 1st, 2021. It's the time of week where we get together to talk about all things Circuit Python. I'm Jeff, 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. Development of Circuit Python is primarily sponsored by Adafruit, so if you want to support them and Circuit Python, consider purchasing your hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafruit.com. 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, which is exactly what's happening to us today. If you want to be notified about changes to the meeting, the best way to do it is to check the calendar that's available on GitHub and add it to your favorite calendar app, although we also call your attention to it on Discord if you are a member of the Circuit Pythonista's role. This meeting is recorded. We're recording the audio from the voice channel and the video of the text channel. If for any reason you prefer not to have your voice recorded, you are still welcome to participate. The meeting will be posted to YouTube and the audio will be released as a podcast. If the podcast isn't available on your favorite podcast service, please let us know. There's a notes document to accompany the meeting and recording. If you wish to participate but can't make it to the meeting, that's where you leave your hug reports and status updates. The notes document will be augmented with timestamps to go along with the video, so if you're watching or listening to us later, you can use that to skip around to the parts that interest you the most. The meeting tends to run 60 to 90 minutes so that we find is helpful. A link to the new notes document is posted in the Circuit Python Dev channel every week shortly after the previous meeting. And of course, if you're listening or watching, it's in the notes. It's in the doobly-doo. So the meeting is held in five parts. The first is community news where we take a look at all things Circuit Python and Python on hardware. This week it is a little look back at the Python on my controller's newsletter. The second part is the state of Circuit Python, the libraries and Blinka, where we look at the numbers that tell us the health of the project. The next part and the first round robin section is hug reports, an opportunity to highlight the good things folks are doing and taking the time to recognize the awesome folks around us in the community. The fourth part is status updates where we sync up on what we've been up to. We invite everyone to take a couple of minutes to talk about what you've been doing in the last week since the last meeting and what you'll be up to in the next week. And the final part is in the weeds. If we need a longer term discussion, then status updates can accommodate. This is the place for it. Add your topics and we will take them in the order that they are presented. And with that, I will switch over to the notes document, take a timecode and get us started on community news. Normally this is a preview, but as we are on Tuesday, if you're a subscriber, the newsletter is already in your email box, but we'll cover it anyway. So top is that the Python on hardware was listed in Gartner's embedded software and systems report. MicroPython and by extension, CircuitPython are on the so-called slope of enlightenment. Their advice to users is to adopt MicroPython to accelerate development and reduce development costs, especially if your time to market is critical. Next up, CircuitPython 630 release candidate zero is out now. We added support for new boards, like a lot of these tricky boards, many corrections to existing boards, and the addition of a consistent board dot LED property to most boards. And finally, a timing fix that affected certain samples of RP2040 boards. There are release notes on GitHub and of course we covered it on the Adafruit blog. Next up, CircuitPython snakes its way to the Arduino Nano RP2040 Connect, which is the blue board from that favorite blue company that you know of. But if you don't want to program it in the Arduino environment, we can do it with CircuitPython now. And I'm not sure whether that's in the pre-release or in 630, you'd have to check. Next up, we are the Python languages back in the second position of the Tyobi Programming Popularity Index. And beyond that, looking at longer-term trends, C is losing popularity. So maybe just maybe Python could reach first place in the index in the first half of next year. And last up, LaMour Lady Ada appeared in the Microsoft Build keynote with Kevin Scott, CTO of Microsoft, and the topic was machine learning on the edge with Adafruit and Microsoft Loeb. That was a fun video. If you ever want to operate a bakery, I think that's the way to do it. The CircuitPython Weekly newsletter is a community-run newsletter emailed every Tuesday. The complete archives are on adafruitdaily.com slash category slash CircuitPython. Also, head to the front page of adafruitdaily.com if you want to subscribe. It highlights the latest Python on hardware-related news from around the web, including CircuitPython, Python, and MicroPython. To contribute your own user project, edit next week's draft on GitHub and submit a pull request with the changes. You can also tag a tweet with hashtag CircuitPython on Twitter or email cpnews at adafruit.com. Next up is the state of CircuitPython, the libraries and Blinka. Now these numbers generally cover one week, but since we are eight days out from the last meeting, I also pulled in some statistics from the previous day's report. So for the seven days ending last night or early this morning, we had 43 pull requests merged. Although if you look at the one day earlier report, we had 56, which is just a phenomenal number. And that came from over 21 authors, I think actually about 26 authors, but over the eight days, including some names that I don't recognize or don't see often. We have Emerge Reanimator, MikeJC58, Y-Wing83, and Z-Lite, and BJ Neuer, which I'm sure I didn't pronounce right just now. So thank you, especially to the authors who are new or who are infrequent and dipping their toes in. We love to have you helping us out and improving CircuitPython. The next stat up is the 13 reviewers. Reviewers are the people who check things over, maybe give it a test, maybe read the source code changes, just as an extra step so that we can provide high quality software. And without them, we can't bring in pull requests and we can't improve it thing. So this is super important stuff. If you are interested in getting started reviewing, the thing to do is check out open pull requests, test them if you can, provide feedback, and once you've been doing that for a while, just let one of us know you'd like to become a reviewer with the power to affirmatively accept a pull request. And then the next overall statistic and the last one is that we had 22 closed issues by 10 people and 21 opened by 19 people. So first we had a net decrease in issues, which is always nice to see. The number tends to trend up overall, but this week we were down. And also having a couple dozen people opening and closing issues shows that we have a lot of people who are interested in what is going on. And with that, I will pass it to Scott to tell us about the core statistics. Hello, totally blanked on having to do this. So let me scroll, scroll, scroll. I'm in the right dock. I don't want to read the wrong ones. For the core, we had 18 pull request merge from 11 different authors. So thank you to all of those authors. I won't read the new folks. We had five reviewers. So thank you all of those reviewers. We have 21 open pull requests. There is one that is greater than 200 days old. That's 251 days old and we have a few that are getting up there. But I think I did knock out one of the real old ones. So that's good. And a lot of these ones aren't too old. So as always, I think the call to action here on the core side is there are some PRs, some pull requests that have just like lingered a bit. So if you want to help us out on the core side, please take a look at those. There's a couple I know that are just for boards. And those are pretty easy to do. So if somebody wanted to pick those up and either close them or finish them, that would be amazing. We always want to keep our pull request down. I think our pull request countdown. Issues wise, we had 10 close issues by five people and 10 opens by 10 people. So lots of people involved as Jeff was saying. And we have total of 457 open issues. That number grows slightly over time, which is not the end of the world. We do have five active milestones. We use milestones to triage issues as they come in and kind of prioritize them. So we have 56 open issues under the 7.0 milestone, which theoretically we want to finish before we do 7.0 stable. But I suspect a lot of those we won't actually do. We'll probably add some additional seven milestones to move those two. We have three bug fixes for 6x. So we should check those as well. Those are the priority ones. And then we have this longer term bucket of 373 open issues. These are the ones that are good ideas, but we have no immediate plans to do or at least aren't a priority. And then we also have seven issues not assigned to milestones. So those are the ones that need to be triaged still. So we want to make sure and look at all the issues as they come in. I'll be particularly worried about issue counts if that not assigned to milestone number goes up. Because we should at least take a look at what people are reporting and respond to those. So yeah, that's good. Overall, Dan did the 6.3 RC0, which is great. And I suspect that we'll do a 6.3 stable this week. And then once 6.3 is stable, we should be able to do a 7.0 pre-release, which will be really great. Thanks to Dan for taking on the releasing. And that's it for the core. Thank you, Scott. Next, I will hand it to Catney to tell us about the libraries. Thanks, Jeff. So this applies to all of the Adafruit Circuit Python libraries, which is every library that begins with Adafruit underscore circuit Python underscore, as well as a few other things, including the community bundle. So across all of the libraries, we had 24 pull requests merged by 12 authors and 13 reviewers. And it's great to see that there are one, two, three, four, five, six, seven PRs it looks like that were open longer than two weeks. And so we're starting to get caught up. It's slowly happening. And that leaves us with 48 open pull requests. We had 10 issues closed by six people and nine opened by eight people, leaving us with 310 open issues. If you're interested in contributing to Circuit Python on the Python side of things, consider going to circuitpython.org slash contributing. You'll find all of this information and more including open pull requests, open issues, and some library infrastructure issues. Take a look at the open issues, see if there's anything that you're interested in doing. Let us know that you want to work on it and get started. If you want to start reviewing, take a look at open PRs, see whether there's anything you can comment on. Make a comment and once you're comfortable with that, we can work on leveling you up to joining the actual review team. But commenting on PRs is an excellent way to get started. All of this happens on using Git and GitHub. If you are new to that, we have a guide, contribute to Circuit Python using Git and GitHub. And we're always available to answer questions. We want to make sure that you are able to contribute in a way that works for you and we want to help you whatever that means. So in terms of library updates in the last seven days, we had one new library, Adafruit Circuit Python dash display, and a number of updated libraries which I will not read off. Overall, we are seeing a push to get through some of the older PRs. Early hug report to Jose David for handling that. He's been going through all of the open pull requests and tagging people and helping people out and getting things moving forward, which is excellent to see. Because every week we say we really need to get caught up and then we don't. And it's actually happening now. So that's excellent. And it's good that we're always seeing weekly updates to the community bundle. We always wanted that to be exactly what it's turning out to be, but without folks to contribute to it, it sat for quite a long time. And now we're seeing a lot of contributions to it, which is really great. And that's where we are at the libraries. All right. Will you be talking about the branch naming stuff later on in the meeting today? Yes. Okay, great. Then we won't do that now. And I will pass it to Melissa to tell us about Blinka. Hello. For Blinka we had one pull request merged by one author and one reviewer. There are three open pull requests at this point, which just goes to my going down. There are were two closed issues by one person and two opened by two people, leaving a net of 55 open issues. And there were 5,637 PI PI downloads in the last week. And we currently are supporting 75 boards. And that's it. Thanks, Melissa. And with that, we are ready to move on to hug reports. This is the first round robin section. And as I mentioned earlier, it's the time for us to highlight the positive things that all the community members are doing to help each other. So I will start things off and then we will go down in the order that people are in the notes document and wrapping around to the top when I get to the bottom of the alphabet. So my first hug report, brother, is for community moderators. There were some moderation issues, particularly this morning, but also over the last week, since I've said thank you to them, they really keep the community running well, talking to the people who are willing to be talked to and showing out the people who just aren't doing it right. Next, a hug to Catney and to Scott for running meetings while I was out for a couple of Mondays. And finally, a hug to Dan for some code reviews and merges over the weekend. Next up is Jerry. And then after that, I'll read notes from Jose David. Hi. So, yeah, hug to Nara doc for doing some being really incredibly helpful and patient on discord. It's a fun to watch the interactions and the amount of help provided. To Carter and Jose David for commiserating with me on this TCA 9548 a issue. It's going to get us all. All right. Up after this is Catney, but now I have notes from Jose David who has a hug to you Jerry for helping on the TCA 9548 and BME 280 PRs and for always answering the call when more testing is needed. Next, a hug report for the summary for participating in the DPS 310 PR giving tips and solutions. And last, a hug for doctor on discord for being present and keeping the discord chat moving and very dynamic. All right. You're up Catney. And then after that, I have more notes to read. All right. So my first hug report is to Dan for taking care of some moderation issues on discord and to the community moderators as a whole on discord for being there to keep our community amazing. I have a hug report for Jose David and Lisa Mara for working through the DPS 310 PR and to Jose David for agreeing to update the DPS 310 learn guide to match the PR. And one I didn't enter is once again I want to thank Jose David for taking on going through all of the open library PRs and making sure that we get caught up. All right. Keith the EE who is text only writes a hug report to Jose David for sitting down and helping me walk through some API and documentation decisions for the SGP 40. All right. Next is maker Melissa. And after that is Scott. Let's see. I've lost the tab here. Here it is. Okay. I want to give a hug report to Catney for taking on learning how to add a board to the Arduino CI checks and group hug to everyone else. All right. Thank you. Scott. Tanu. You are up. And then after that I have notes from attic data. Thanks Jeff. Group hug generally. Whenever I step away I took I took Friday and Monday off. I'm always amazed at all of the activity that happens just over those short periods of time. And so I just want to say thank you to everyone who's involved here and on the discord and on GitHub. You all make this community awesome. And I really, really truly appreciate how well the community does every day. It's just amazing and it wouldn't be anything without all of us. So thank you all. Thank you, Scott. And I guess I should give a belated hug report to you. I asked for your feedback on a PR and you're like, no, I'm out. It's my vacation. And thanks for enforcing those boundaries. I think I just queued it up on my tabs to do that today. Yeah. That's great. Appreciate it. Because I also managed to enforce those boundaries pretty well on my own recent trip. And it's just good to reassure each other that's the right thing to do when you're unplugged, be unplugged. So yeah. 100%. And that goes for even the people that are not paid by anybody to work on circuit python. You should always feel free to take time for yourself away from this community. That's that's the nice thing about seeing all these awesome folks is like no one person is critical. You can, everyone can take time off as needed. All right. And it's important. People should. That has been a public service announcement. All right. I'll read anecdote is hug report and then it will be Dan who is up after that. So after I take time codes and stuff. So anecdote has a group hug. And let's see. So we'll have Dan and then I'll have notes from David. I cannot hear you, Dan. All right. I'll just go ahead and read Dan's notes. Dan has a hug for me and DJ I X 123 for making MP Y cross run natively on Mac OS M one and a hug to AT makers bill for testing user supplied hid descriptors. Next notes from David cloud who has a hug for Dan H for the dynamic USB learn guide. And now without warning, it is foamy guy. All righty. Thanks, Jeff. For this week hugs. Definitely second what a couple of folks have mentioned to the discord moderators for handling some of the issues that have popped up in the last few days to you, Jeff, for working on repurposing the requirement screenshot tool to work with library examples. To fed a to for hanging out during my stream over the weekend and especially for sharing some knowledge and helpful tips and utilities around server configuration and SSL. To mark gambler for reviewing an RS bone. The user on GitHub for testing a PR in the HID library that I put in over the weekend. And then lastly is thanks to Scott for shouting out my weekly streams on show until last week. That was really cool. I appreciate it. Thanks. Very nice. And that wraps up hug reports. So the next section is status updates. It is a similar round Robin. We're inviting you to let us know what you've been up to since the last time you checked in, maybe a week ago, maybe longer. And what you hope to get up to in the near future. This focuses on circuit Python, but if you have anything else. That is going on that you want to let us know about, please feel free to do that. So I will start and then we will go around the alphabet again, same as last time. So over the last week, I built MPY cross for M one max. With, as mentioned before, a quick correction and improvement from community member. DJI X 12123. This was fun as I don't own any max, let alone one that can run the M one software, but GitHub actions can do it. And Dan kindly tested it. And we have that now. So that's great. I also added to the action CI. Steps to build most of the ports on windows. So it builds one board for. At my Sam D one board for STM 32, one board for Pico. So one board of each kind except for the ESP 32 S2. Just to verify that we don't have these problems crop up. Where it stops building because we don't have many community members who use windows to build. It's mostly Mac and Linux. But we do want to support that for one key user. So it's good to do that. And then last and the big thing is I started adapting the ESP 32 S2 camera capture code into circuit Python. There is an example that goes with the Kaluga dev kit. And it works with a calendar with a calendar with a calendar called OV 26 40. But the low level capture code should adapt to the camera that we already have working with circuit Python, the OV 76 70. So I've got a bunch of code integrated and written. And I need to wire up this board, which as I mentioned a little bit below is a vexing process. It just seems to take a long time and you make mistakes. And anyway, so that's this week. Number one is the code is written. I'm going to test it and see if it works. And besides that, I also this week will be checking my feedback on learn system and responding to user questions, community questions about the stuff that I have on learn. Next up, we will go to Jerry. And after that I have some notes to read for Mosaic of Eid. So there's a bunch of testing on this TCA 9548 a issue where the only on the RP 2040 it just doesn't work reliably. Works fine on them for really kind of scratching my head. I did post in the issue some screenshots from the logic analyzer, which shows that it's definitely not working right. It's definitely missing. There's a command needed to send it to switch to multiplexer. And it's not getting there sometimes. But at this point, I have no idea why. So anybody has any suggestions? Happy to hear them. And then I was playing around with the in the along with the data box that came with the fun house had ended a long time ago. And it's what do you call it? HCS R04. Sonic sensor. And I tried it on RP 2040. Just for fun. And it doesn't work quite right there either. Basically, every other value is wrong. Is there a correct distance and a really short distance and a correct one. So it looks like I posted the issue in the HCS R04, but it might be a circuit pipeline issue. So I did. I did post a note to the issue saying that there may still be some lingering issues in the RP 2040 pulse in. So if that's an own issue, then hopefully it'll get fixed at some point. And then there's a forum post. The interesting one that came up where someone wanted to run an airlift on a RP 2040 Pico using micro Python. I thought, oh, wow. Now we have Blinka that should just plug and work. Not so much. I ran into a funny thing that I hadn't really thought about much that micro Python doesn't support timed up monotonic. It has time dot time and time dot other things, but not time to monotonic. So any libraries that use that won't work. So I did a quick change, quick fix to the library to fix the calls to time to monotonic, but then ran into a more serious issue with SPI. So and I haven't gotten anywhere with that yet. So keep looking at it, but anybody's been playing with that. And I don't even know if it's, if it was expected that an airlift would work under micro Python on a Pico. So be nice if it did. All right. Thank you, Jerry. Next I have notes from Jose David and up after that will be Catney. So last week, Jose David was reviewing PRs working on the BME 280 and DPS 310 memory optimization and doing some small doc updates. And next week's plans are to be in PR land for one more week and doing reviews if needed. Catney, you are up and then followed by maker Melissa. All right. So last week, published the Neo key trinky guide started the rotary trinky guide, finished up the analog in template and tested a new page replace feature on learn that is sort of going hand in hand with the templates because there are pages in learn that get mirrored into other guides. And so you write a single page and then it just gets mirrored into a different guide. So every time you want to update that page, you don't have to update it in 30 places. You can update it in one place and it automatically updates. However, we've decided we want to replace some of those pages with templates and that would have been a nightmare. So our one of our learn developers put together a page replacement feature that you replace the page and it actually replaces the links and all the mirrors automatically. So it's seamless to the user that I want to put a template in place of an existing page and no one else will know, which is great. And then this week so far reviewed the DPS 310 PR. That's looking good. It was just a matter of making sure that the learn guide got updated as well and continued working on the rotary trinky guide and did the final testing for the page replacement feature. So the rest of the week finished the rotary trinky guide, do some pretty pins, pin diagrams for the SAMD 21 boards. And then somebody posted to GitHub. I want to say on the Clue library that they wanted to be able to use the simple text display feature in the Clue library on the Fun House. And notice that it wasn't available in the Fun House library and so they factored it out into its own thing and then asked whether we would be willing to do that. So what I'm going to be doing is creating an Adafruit Circuit Python simple text display helper library that handles that simple text display. It just makes it super easy to display sensor information on a display and so any of the boards that we have that have sensors on them and displays built in will benefit from it. And it just happened to be that the Clue library is the only one I've written so that's the only one it went into. And as for your question earlier, we are starting the move of all of the Circuit Python repositories from master branch to main branch. We're going to start small on less used libraries. As Dylan put it, she was the only one who has made any commits in the last three years on some of them. So that means it's mostly Adabot. So we're starting there. The things we need to be aware of are references to master in documentation and the fact that the learn system has embedded code from library repositories and those all reference master as well. And we have some set of steps in place to handle that. But inevitably there's going to be something we didn't think of. So if you run into issues, please let us know. The very last thing we're going to do after making sure everything else is in place is delete the master branch so that we don't run into the same confusion that we had on the Circuit Python core repo. But we want to make sure that we get everything else in place before we do that. And the thing that will be different is that as a contributor you need to be working from main and not master. And that's the reason why we're deleting master because we don't want there to be confusion with that. In theory you should be working on your own fork and on a branch so you should never be pushing directly to main. But when you make a PR you want to make sure that the code that you were working with is up to date. And all of the up to date code will now be in main. The contribute to get and GitHub, I'm sorry, contribute to Circuit Python using get and GitHub guide has a section on using GitHub to tell whether or not a library has been moved to main or not. And so check out that guide if you want to make sure that you're working with the latest. It shows you how to verify whether or not we've gotten to that library yet. But this is something we plan to do over the next three to four weeks. So it's coming quickly. And we will be super careful with the really high traffic libraries but that is the overall plan. Dylan is starting on that I think today. All right. I'm happy to see that happening and I feel like when we did it with the Circuit Python core there was a minimum of trouble and most of the trouble stemmed from still having the master branch remaining. So I'm happy to see that the window of that time is going to be smaller and that we plan to remove it. And I think people will do fine. It's mostly a matter of the order in which we do things. And I want it to throw an error if somebody tries to do something with master because I don't want there to be situations where folks are trying to use both. So that will eliminate that. Right. Next up is maker Melissa. Then after that it's tenured. Hello. So this last week I went through circuit python.org and did some board updates on there. I started working on a new learn guide for speech recognition. I went through my guide feedback and made updates were applicable. And I also went through the Google assistant and eating guides and redid the steps for the Google setup on the calendar guide as well. So it's very completely changed. I have cat me with adding some Arduino boards to check when peers are submitted. And this week I am working on a learn guide for this the speech recognition thing. And I'm going to take a look at some of the Raspberry Pi shell script peers and issues. And that's it. Thank you. All right. Scott is up next and then I will read Hello. So I took Friday and Monday off which meant I had a nice long weekend got outside went for hike saw some friends and made some progress on the fiber deserts project last night to which is exciting for work. This week I am working on the BLE workflow. I added different advertisements based on whether the board is bonded or not. I've added a one second wait for enabling BLE so if you're on a USB powered board it will not broadcast by default. You'll have to click it after there's a one second wait for safe mode and then it'll be a one second wait for BLE after that as well. I'm working on the USB and BLE file system sharing. I think the way I'm going to do it is USB code will win versus BLE. So if USB is connected it will show up as a drive and people will be able to edit it unless but if not then BLE will work. User code access will follow the existing API so nothing will change there. I think this does mean that it is backwards compatible which is nice. So I'm going to polish that up today. I filed an issue with Antonio and talked with him earlier about the app crashes if multiple packets are used for a single response and I'm hoping to get them a build of circuit path on this week so we can start iterating on the multi packet stuff and then also on the connection stuff as well. I have test scripts already for the stuff but the test scripts don't do some of the like reconnect stuff that the real version is doing so I can't get very far in my test script without the test script failing so I have to debug that as well so I can use that for testing all the different APIs. And I'm taking time off in June here so a week from tomorrow will be my last day for just over a week so I'm off the 10th through the 18th and back on the 21st the 18th is a Friday so there's the weekend there too. So my last deep dive will be on this Friday and then the two Fridays after that there will be no deep dive so heads up to that and as a reminder if folks do want to be notified about my deep dive we have a deep diver's role on Discord now that people can be added to to get notified about all of those updates. That's it for me. Alright. I will head back to the top of the alphabet and read the notes from Anikdata who says they are off the grid no internet for most of the next week or so. Dan you are next and then I'll read notes from David. Okay hold on. Let me find my well the good news is we can hear you now. Yeah I was micromarphone was set to the wrong thing. Okay so there were in dynamic usb descriptor news Bill is working on some various hid devices that need their own descriptor and so I found a couple of bugs which cancelled each other out which I fixed. I'm still working on native keypad support for simple keypads where there's one key per IO line and also matrix keypads where there's rows and columns and also I'll be working on shift register support in some cases also. So that's all still under development and I mostly been working on the API right now but I'll do one thing all the way down and publish it as a draft PR soon. As Scott mentioned I release 630 release candidate zero we haven't had any issues on that I think I will release 630 later today or tomorrow and then we'll be able to do a 7 00 alpha immediately so that we have another unstable release which we can point to more easily. And finally I've been working on a PR to the Pico SDK to handle some Adafruit RP2040 boards that don't where the crystal oscillator is a little unreliable about starting up and so we have a workaround which is just a way longer and that support is going into the main Raspberry Pi Pico SDK. Okay, thanks. Thank you Dan. I have notes from David and then FOMI guy will get to wrap up status updates. So David writes as far as CircuitPython just chatting with Cgrover about the thermal cam, maybe a CP fatigue and non-CircuitPython successfully used WLED an ESP32 Wi-Fi LED animation with NeoPixel and .star in 5V but failed with the 12V LED strip I planned to reuse playing with Docker on a Pi 4 with IoT stack. There is a link to GitHub.io in the notes document and last acquired a 3 meter by 1.4 meter reflective plastic to do the green screen trick with LEDs which is something that our own JP demoed a couple of months ago. It's a neat trick. And now I will take a time code and pass it on to FOMI guy. All righty, thanks Jeff. Last week I implemented guest user functionality on my design.io web page so it allows people to make designs without having to have a user account first if they would like to do it that way. I did some research into consumer codes. I was looking for the brightness up and down for a screen. I was looking to find those codes and I did end up finding some. And perhaps most exciting to me personally at least is I over the weekend I think I found a working solution for installing the stubs from PIP. It took a little bit of kind of massaging to figure out the right way to get it to copy the files but I think I have a working solution so for this week I need to I need to validate that that it will actually work with a test listing on Pi Pi. Everything I did so far was just locally. So I'll try to get that done and then as long as that works the next step is kind of like getting prepared a repo or whatever we need for how we will deploy that stubs. I need to also this week write some code that will use a rotary encoder to send those brightness codes the up and down brightness consumer codes and then I'm also going to be working on a 3D design this week that will hold a phone or a tablet and it will have a way to kind of attach a crank arm onto the side of it so that it can crank the rotary encoder and send the brightness codes from that so that's what I got for this week. Thanks. Alright and Scott remarks in the text channel quote I think we can just build and deploy from Adafruit Slash Circuit Python. So I guess talk to Scott about how best to do that. Nice I will do that. Because that rounds up status updates and we head out into the weeds and I will pass the baton to Dan to introduce his topic. Okay this is about we have alternate names for the sort of the standard files in oh sorry there's some junk that got pasted in here. Alright let me fix this up later. So boot.py can also be called boot.text or settings.py or settings.text that can even be called settings.text.text and some other things like that and we never really documented the settings.py thing I think or maybe only one place and in fact I had a user over the weekend who had an innocuous settings.py which was not meant to be boot.py and which was interfering with their boot.py so considering that we don't document that you can do this and we haven't recommended that people do that I propose in 7.0 that we just drop settings.py as an alias for boot.py and then the sort of the second consideration is we added all the .text stuff because we thought people were going to be editing on windows where the default setting was not to show the file extensions using say notepad or something but we highly disrecommend using notepad and we recommend other editors now that are better at showing extensions and I'd rather just document how to turn on showing extensions so I'm proposing also that we drop support for .text and have people fail early rather than later when their programs don't run and maybe even drop support for the double extension stuff too which will save a tiny bit of space but mainly it's just another thing to have to explain to people so I'd like to feed back on both of those proposals I'm on board for both we document that in one place which it's a short paragraph and a guide the no not settings.high settings.high is not documented that I'm aware of I'm talking about the .text and we never documented the double extension thing either so I don't see a reason to keep it I would much rather just teach people to do it right we did it a long time ago I think I was even the one who proposed some of this and it was solving a problem that doesn't exist okay I will submit a PR for these and it will save a tiny bit of space I think the double extensions was added by a community member so maybe just CC them on it okay I'll see about that the only double extension I'd consider keeping is like code.pi.text yeah and it prints a message as opposed to working site only but people don't even know how the people are using Mew I think it's kind of better and Katnie I'll try to see if I can write up something about turning on showing extensions and put that in the guide somewhere yeah we'll find where the file names are documented like I said it's a small section and then you can just put it there instead okay alright thanks okay alright I guess I'm done alright in that case Jerry you are up next okay well I don't even know if it's an issue or not so I've noticed many comments in the forums and on discord I think about the encoder the new ITC rotary encoder I believe it's the same for the trinky that when you turn it the counts are sort of counter intuitive at least a lot of people think they are that they decrease when you turn clockwise Katnie that doesn't mean much and they increase when you go the other way so my question is is this an issue or a feature and does anybody else care I was very careful to make sure that when Jeff redid rotary encoder most recently in the regular rotary encoder in the latest PR that they turned in the same direction that they all turned in the same direction right so if the ITC one is backwards I think maybe we should change the library or something which I think it's in the seesaw well so I mean I don't think the library has anything to do with it can you just reverse the pins no because it's all a monolithic thing you can solder in the encoder but you can't flip it around and solder it the other way so it's just too late in the library could you just multiply by negative one does it know these comments are correct I believe that it is not the intuitive way not the way people expect it to be is that I know that the Stenma QT rotary encoder increases when you turn it counterclockwise and I think some of the others increase when you turn them clockwise although I don't know which boards have an integrated encoder are there other boards that had an integrated rotary encoder before now I don't know I don't think so the trinky turns is the trinky go the wrong way I thought it went the right way I'm pretty sure it goes the right way I just did a bunch of examples with it and I don't recall thinking it was weird right so clockwise increases yeah there's a circuit python library that supports the seesaw right so yeah so multiplying by negative one sounds like a good idea why don't we just tell those people to multiply by negative one I guess well I mean because it gives you a network okay that's fine we're not even multiplying just negative minus minus just negate it it just comes up Jeff you found an issue with it before that I haven't seen any comments on and I confirm the same issue that it does actually miscount but yeah you could wiggle the dial in a certain way and it will either count it I think it counts up without actually moving a detent over I'm very tempted to go interfere down in the seesaw library but it's not what I need to be doing so I'm trying not to I don't feel like I've ever seen a rotary implementation that actually works 100% of the time my next question was you know is that just a fact of life with rotary encoders so that's my no rotary encoders should work right and it's totally possible to make them work right and I think the one in the core works pretty well right now it's still it doesn't with your reverse direction it loses account but right if you go a single step from a non known position you don't know which direction it goes yeah I think it might be possible to check for that by making sure that by checking to see whether you're in a detent position which is when both are grounded or high I can't remember which grounded but if you do that there's there I think that you then introduce the possibility of getting false counts because there might be bouncing going on so I think it's a trade off but I haven't tried that in detail there is a user who's interested in this but we haven't and he tried a bazillion ways to fix it and didn't succeed right well when I insist that encoders work I mean I know they're used in industrial servo motors and they accurately keep position are they optical encoders rather than yeah but the quadrature waveforms have the same properties whether they're optical or mechanical right but the frequencies are different yeah the frequencies are really low for mechanical so it should be easier not with bounces I don't think the optical ones have as much of a bounce problem bounces don't matter to the extent that they're like wavering between two neighboring codes you have to make sure and get all of them though right to be correct are you saying that optical encoders also handle the reversing they don't lose a pulse on reversing usually they don't the motor controllers don't really care about that if they the ones on industrial servos can't long term lose position or all of your machine parts would be wrong yeah I mean isn't that why it's common to have end stop so that you can reset your position it's true that there are home switches that let you accurately find a repeatable position but you say your part program runs for 8 hours you can't slowly lose position over that 8 hours as you know way more of your steel or aluminum or whatever it is well sometimes they add hardware debounding and they may use other things I mean they're absolute anti-turn position keeping devices as well but it should be possible to make it work we put a lot of time into it already so I push back on putting any more time into it well yeah I'm trying not to I just feel it should be possible I think we should fix the reversing direction thing up to wazoo so yeah I think that if there's an easy fix for that in the library I think we should fix it now rather than because the product just came out so we need to fix some guides and have some people rewrite their code now the number of people who are affected is very small yeah there are at least two sites that you'll want to change because there's one property that gives the total number of counts and there's another that gives an incremental number of counts I think which was a little strange but check and make sure that there may be two different methods or properties and do the negation and both of them there's a count and there's a delta account so it's a little different the last time you got it yeah that thing that Jerry just said alright I think we've exhausted that topic in which case it is time to wrap up the meeting thank you everyone for joining us for the circuit python weekly meeting on June 1st 2011 the next meeting will be back on Monday as usual that makes it June 7 2011 at the usual time of 2pm Eastern and I think that is 11am Pacific thanks for joining us today and we hope to see you soon again thanks everyone