Hello, everyone. This is the Circuit Python Weekly Meeting for March 8th, 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. 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 adafru.it-discord. We hold the meeting in the Circuit Python Text Channel and the Circuit Python Voice Channel. This meeting typically happens on Mondays at 12 p.m. Eastern 11-8 p.m. Pacific, except when it coincides with a U.S. holiday. If the meeting time has changed, we'll notify you via Discord. If you wish to be notified about changes to the meeting, we can add you to the Circuit Python East as Discord role. There's also a calendar available that we keep updated. And just a note, particularly for those outside the U.S., we will change to our summertime hours, also known as daylight saving time next week. So if you're not aligned with those American clock changes, be aware that the meeting time changes by one hour next week. This meeting is recorded. We record the audio from the Voice Channel and the video of the Text Channel. If you'd rather not have your voice recorded, you're still welcome to participate via text. The video of the meeting will be posted to YouTube and the audio is released as a podcast. If you can't find it on your favorite podcast service, let us know. There is 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 can leave your hug reports and status updates, and I'll read them off during the meeting. The notes document also contains timestamps to go along with the video, so you can use the doc to view only the parts of the video that interest you most. A link to the notes document is posted to the CircuitPython channel on the Adafrit Discord every week. Check the pinned messages to find the latest notes doc. Now, as for the meeting structure, it's held in five parts. The first part is community news, where we take a look at all things CircuitPython and Python on hardware in the community. It's also a preview of the Python on microcontrollers newsletter. The second part is the state of CircuitPython, the libraries and Blinka, a statistical overview of the entire project. It gives us a chance to look at the project by the numbers, separate from what we're all up to. The third part is hug reports. Hug reports is an opportunity to highlight the good things folks are doing, taking the time to recognize the awesome folks in our community. The fourth is status updates. Status updates is an opportunity to sync up on what we've all been up to. Take a couple of minutes and talk about what you've been doing in the last week since the last meeting and what you'll be up to over the next week until the next meeting. And the last part is in the weeds, an opportunity for more long form discussions. These discussions can be a result of status updates or something you've identified ahead of time as too long for status updates. And that's how the meeting will go. And with that, I am ready to take the first time code of the meeting. As we transition to community news. So first up, and FOMI guy, I don't know if you were gonna be able to get the links today. And if not, maybe Katni can, but CircuitPython 6.2.0 Beta3 was released last week. It's the fourth beta release of CircuitPython 6.2.0 and has many fixes and enhancements. The big item is across most ports, it adds a second USB serial channel, but there's also a bitmap tool module and as well as the removal of the limitation of displayio.group size. So check out the release notes for a lot more and download it from circuitpython.org. Second big item, the Adafruit Feather RP2040 is available and in the Adafruit shop. And more are being fabbed all the time, so sign up to be notified when they are available. CircuitPython has been featured on the Toms hardware pie cast with of course our own Scott Shawcroft. So there's a link to YouTube and Twitter and I guess best place to pick up these links is in the notes document. Finally, some news from around the web. Got links from GitHub and Twitter and Hackaday and YouTube. We've got Getting Started with CircuitPython on the Raspberry Pi Pico with NeoPixel LEDs. A suite of tools, including CircuitPython for building an uploading firmware, deploying files to devices and testing modules, an adapter for a Raspberry Pi Pico to a Featherwing, a macro keypad that uses Raspberry Pi Pico and CircuitPython, and second appearance from Scott. He was on the Simple Electronics podcast last issue on YouTube. The CircuitPython Weekly newsletter is a community run newsletter emailed every Tuesday. The complete archives are on adafruitdaily.com slash category slash CircuitPython. It highlights the latest Python on hardware related news from around the web, including CircuitPython, Python, and MicroPython developments. To contribute your own news or 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 to cpnews at adafruit.com. And there will be a lot more in the newsletter. I looked at the draft before this meeting and good stuff like always. With that, we will transition again to the state of CircuitPython, the libraries, and Blinka. This is a statistical overview of how things are going. And it's divided into several subparts. And I will start with overall and then hand it off to some of the other folks to tell you about the portions that they kind of take charge of. So overall, we had a huge number of pull requests merged. 52 pull requests from 23 authors. And pull requests are the way that the software moves forward and changes. And having 23 authors means there were nearly two dozen people who improved CircuitPython in the last week. And that's just amazing, as well as I forget if I said the 11 reviewers. And so we also like to recognize authors who are new or infrequent contributors. And I'll call out some of those names. Thomas Six-G, Orbit Rasu, MKLHX, Tio Mitch, Adam Candy, Tyler Crumpton, Rotman, and Admiral Maggie, are names that are less familiar or I think new. Our 11 reviewers, thanks so much to them. Getting a review of the changes is always key because it makes sure that there are at least two pairs of eyes on every problem and its resolution. If you see your future potentially as a reviewer, we invite you to start by commenting on pull requests with, I tested this, I looked over the code, it makes sense. I see a problem here. I see room for improvement. And we would love to help you move up to being an official reviewer, which comes with rights and responsibilities, like the ability to merge pull requests when appropriate. On the issues front, we had 20 closed issues by 12 people and 23 opened by 19 people. So the first thing to note is again, the range of engagement that we have from all these different people. We would prefer to see the number of issues not trend up over time. So we missed that this week by increasing three issues. And with that, I will pass things over to Scott to tell us about the core of CircuitPython. Thank you, Jeff. All right, so in the core, we had eight pull requests merged from four different authors, K-Match 98 and Tio Mitch and Jerry Needle are all relatively new authors or infrequent authors. So thank you to those folks. We had three reviewers, so thank you to our reviewers. And we have 21 open pull requests, which is about normal for us. So if you are involved in any of those longer term pull requests that are open, please take a look and make sure that they're moving forward. Otherwise, thank you all to the folks that are making pull requests. Issues-wise, we had four closed issues by two people and five opened by five people. So we're not up one for the core. For a total of 419 open issues, this does tend to trend upwards slowly, but that's potentially okay. We triage all issues using the milestone system. And we have seven issues that are not assigned to milestone, which means they haven't been triaged just, but it's also like Monday morning here in Seattle at least, so we're gonna work on that. We have three different milestones for 6.x with over 50 issues under those. So we're gonna have to take a look at those. I think that's in dance plan anyway. And then we have seven issues for 7.0. So that's where we are with PRs and issues and generally things are moving. So thank you to everybody. Expect to see us kind of try to buckle down on 6.2 and get a 6.2 stable out the door. And then after 6.2, I think we're planning on going to 7.0. So it'll be a longer cycle after 6.2 and we'll get some exciting stuff in. Thank you, Scott. So next up is Katnita tell us about the libraries. Thanks, Jeff. So across the libraries, this applies to all Adafruit Circuit Python libraries and a few extra things, including the Circuit Python Community Bundle. We had 41 pull requests merged from 18 different authors, including most of the new names you wrote out and 10 reviewers. We had two pull requests merged that were or three that were over a week old, which is good. And most of them were three days or less, leaving us with 91 open pull requests, which is high, but there's a reason for that, which I will discuss later. We had 14 closed issues by 10 people and 18 open by 14 people, leaving us with 298 open issues. We have five good first issues and that number has gone down, which is excellent because folks have picked up some of the first issues and completed them. So that's how those have gone away. The way that you do that is you can go to circuitpython.org slash contributing. And there's all of this information, a list of open pull requests, a list of open issues, and a list of library infrastructure issues. And in the list of open issues, you can search by label. Good first issue is one of them. So if you're new to everything, that's one place to start. If you want something a little more complicated, bug or enhancement are both good labels to search for. But you can just scroll through that and see whether anything sparks your interest and make a comment on that issue that you'll be working on it. And we are always available to help. There is a guide on contributing to CircuitPython with Git and GitHub. And we're always available on Discord to answer questions. We want you to be able to contribute in a way that works for you and we're happy to help you learn how to do that. Let's see. So yeah, check that out. If you're interested in contributing to CircuitPython and the Python side of things, that's where you wanna start. And we had, it looks like three new libraries this week. One, eight of CircuitPython libraries, display IO layout, and it looks like two community libraries. Display IO driver for the GC9A01TFTLCD and a driver for the GameDuino 3x series of display adapters. And the reason that we have so many open pull requests right now is the same reason why the updated libraries list was very long. We went through and finally patched the libraries to deal with the, deal with the pylint update that made a check that existed the whole time actually work. And it turns out that it doesn't really mesh with how we do example code. So we needed to figure out a way to make it so that it still runs on the library code where we want it to and not in the example code where we don't. We figured that out, we patched it. The way that Adabot patches work, they don't apply to everything. If there's a difference in a file, a difference in a target file, the patch won't apply to that library. And so that requires then that we go through and do manual PRs on some libraries. And that is why our PR number count is so high. I closed probably 30 of them this morning, but that wouldn't be in this data. So anyway, we're making a lot of progress on that. And thank you early hug report to Dylan and FOMI guy for all of their work on that. And that's where we are with the libraries. Thanks, Kenny. And for the last subsection of this section, I will let Melissa tell us about the status of Blinka. Hello, Blinka is our circuit Python compatibility layer for Raspberry Pi and other single board computers. And this week we had three pull requests merged by three authors and two reviewers. For the authors, I see TWA 127, who's been a regular contributor, and Thomas 6G, which I don't recall seeing any. They looked new to me. And there's also Dan Halber, who contributes occasionally. There were seven open pull requests at this point, and there were two closed issues by one person and zero open by zero people, leaving a net of 55 open issues. There were 3,350 Pi PI downloads in the last week, and we are currently supporting 70 boards. And that's it. Thanks, Melissa. And with that, we will move on to hug reports, the first round robin section. It's a time for a little positivity and a little thankfulness for what the people around us are doing. And I will start and go through the document in the order that it is here, and just a reminder that if you don't put yourself in the notes document, we will assume you're just listening in, and we're happy to have you. So first, I wanted to give a hug report to Scott for being a sounding board and problem solver for my PIO work. That's something that's been going on for the past few weeks, and I've really caught my stride with it, and it took some help getting there. I've got like three thanks for Dan this week, helping me with getting the bootloader installed on my Adilogger, Feather M0 Adilogger for finding a really, really good clue about these problems we've been having with I squared C on the ESP32S2. And then for hug reports for Dan, Scott, and Lady Aida, and others who I think I've probably missed for reviews and tests on the PRs I've been putting in.  It's fun to see a new face coming in and in this case paying attention to some stuff that maybe we didn't pay attention to and just bringing small improvements is great. So with that, I will pass it to Jerry, and then after that, we will go on to Jose David. Hello. Let's see. Yeah, thanks to Dan and K-98 for their quick fix to the little display IOSU that popped up last week. I think it was last week. And I asked Nis for some great tips on getting E4s running on the STM boards. Something he's been very fond of doing and it's kind of fun to play around a little bit. And Jeff, you for again, once again, explained to me how to use pre-commit. It's nice to actually do it this time. And all the community moderators for all the moderating, you all make this a better place. And especially thanks to Anton for handling a tricky issue this week. Thanks, Jerry. All right, next I will hand things to Jose David. And if you would let me know how to pronounce your name, I'll try to do better in the future. Yeah, it's Jose David. Okay. Thank you. So, whole report to Scott to share as you could Python in both tones hardware than simple electronics was a really great discussion to whole report to FOMI guy for the refactor in the display text library. He took the job and run away with it when I couldn't find an exit and also her report to them to fix the transpose X, Y in the type of library. Thank you. It's nice to have you here with us today. Thank you. All right. So next up is Katni and then K match 98. All right. So first up I have a hug report for Dylan for writing up and running the patch on the libraries to move pilot to the pre-commit and updating pilot RC to FOMI guy for helping with updating the list of libraries that were skipped by the patch for various reasons. A group hug to all of our contributors during the interim pilot update. Thank you for your patience with us taking the time to find the right solution instead of a quick solution. I hug report to Andan on discord for handling a particularly involved moderation situation last week to all the community moderators for all their help keeping this community amazing to Crayola for working on a dark mode for my website theme to the Adafruit learn dev team that's the folks that work on the learn system where all of our guides are kept for being super responsive to bug reports and future requests to make her Melissa and Dan for nice chats in the last week to and for continuing to train me up on the newsletter and to SAK 917 on GitHub for picking up a good first issue and offering to pick up more. That's awesome. All right. Kmatch 98 is next and then Melissa. Okay, thanks Jeff. So first off, thanks to Dishapoo for updating the display IO group. Make it more flexible. Katnay and Dan H, thank you too for the help on the library documentation and how to make that work. Next to FOMI guy and Scott for PR reviews and constructive comments. Next to Jose and FOMI guy for the display text consolidation, things that should set the stage for the future. And last, thanks to Todd Bot for the Discord demo of a cool dial gauge and in particular some discussion on how to improve the performance of display. Thanks. All right. I will hand it to Melissa and then we will go to Scott. Hello. The... Melissa, your audio was working really well earlier but now it's not working so well. Do you mind if I... Let me try something. Please do. Let me try something. Okay, does that sound any better? Yeah, get back into it and we'll see. Okay. I wanted to start by giving a hug report to David Glaude for your work refactoring the IS-31 FL-37-31 library to FOMI guy for testing the portal-based changes to Tom Array for submitting the rock pie for Seaboard to Katnip for a nice chat and a group hug to everyone else. All right. Whatever you changed, it sure worked. Hey. All right. So on deck, I have notes from Seagrover but now I'll hand it over to Scott. Hello. First, hug report to you, Jeff, for the VM size optimization, hug report to Gambler for both Count I.O. and Parallel Bus for the RP-2040, hug report to Dave Putz for Pulse-In and a hug report for NITs for the board depth for the NRF-52840 MicroMod. I just got some and I'm gonna use them this week so it's perfect timing. That's it for me. Great. So after notes from Seagrover, Dan is next after that. So Seagrover thanks Zodius Infuser for insightful observations about DRV8830 style motor controllers. Took my Rush DC motor game up a notch or two and will require a comprehensive rewrite of my recent learning guide. And a hug to John Park for his inspirational and uber-jazzy work on two recent projects, the Pico Keyboard and Retro Reflection Workshop. Amazing. So I'll hand things to Dan and then after that to David. Thank you. Okay. Thanks to Jim Tusek who's been doing a ton of work on a sleep pull request for the NRF. It's basically done now and I have to review and test it but they did a lot of work on it. Drew diagrams, wrote up things in between. It's really a wonderful job. So thank you. Thanks to Jeff for your excellent shrinks in the firmware size that you discovered. That saves us. We can fill it up with something else again. Thanks to MicroDev who's working on the longterm process of merging from MicroPython upstream and they've started, they did some initial work and are now doing some more systematic work to make it easier to do. Thanks to K-mention98 to review the TileGrid transpose issue that came up at the last minute for the release last week. Thanks to Deshipoo for removing the really thing that I always ran into which was how many things can you put in a group? Thanks for taking that away and thanks to Scott for working on the RP2040 flash for making it variable size and for doing it very quickly and doing sort of a simple cleanup of that very quickly. All right. All right. It looks like I'll be reading David's notes and then after that is Foamy Guy. So David writes a hug for Tenut for the special guest appearance on the pie cast and apparently David could guess an answer Scott would give. I don't know the context of that so we'll all have to listen to pie cast together after this. A hug to Arturo182 for sharing an exchange on his RP20400 board trying to have a GPIO mapping compatible with the I2S hat slash bonnet. A hug report to me for the PIO learn guide. And a hug to Michael Horne for porting the Pimeroni 11 by 7 LED matrix breakout to circuit Python which is a work in progress see in the weeds. And a hug to Dan H for a chat about the issue and with maker Melissa for merging all of the PRs for IS31FL3171. So next is Foamy Guy and then it looks like I will read Hugo's notes to wrap it up. All righty, thanks Jeff. This week hug first one to Dishipu. Couple people have mentioned Dishipu removed a restriction on display or group. So now you can have as keep just keep adding things to it without having to worry about max size. And that's really cool. So it's there to Dan H and Kmash for fixing an issue that came out of that real quickly. Think over the weekends to Jose, Jose David for the enhancements in display text. I threw out an idea to make it so that anchored positioning could be used with the baseline similar to the way that it now works with XY in the recent update. And Jose got that taken care of real fast also to Scott for being on the Tom's podcast. It was a great listen. And also particularly for giving me a mention in there. I was honored to hear that to Dan H and micro dev this morning for some help with helping me figure out a way to use pre-commit and have it avoid checking on files that are not actually relevant to what I'm doing. And then lastly to Kmash for working on a fix inside the bitmap label when I found an issue that popped up from a strange font file that has some weird stuff inside of it. And that's all I got this week. Thanks. All right, I will have to scroll back and look for that pre-commit advice because I saw the conversation start and didn't see the conclusion. All right, so I have notes from Hugo who sends a hug report to FOMI guy for Saturday's stream to Kmash 98 and FOMI guy again, hug reports for educating me and setting me straight. I think on what Blitting is to Jebler, Dan H. Katney, Tanute and others who were involved in the translations and build discussion. Very interesting and enlightening. And for special consideration on International Women's Day but always thankful and grateful. My mom, the strong kick butt woman who took from nobody and put them in their place where necessary. And all the other women who made me who I am today. All the credit lies with them. All the blame rests on me.  Thank you. And that's a really heartwarming way to wrap up hug reports. That's a good idea. That's a cool idea. Charles, could you please mute? All right. With that, we will move on to status updates which is also conducted in a round robin but it's a time to let us know what you've been up to since the last meeting and what you hope to accomplish before we get a chance to meet again. And I will start and we will go in the same document order. So, last week in the Learn System I published a guide on doing PIO with Circuit Python. I think we ended up with three or four different examples and it was also, as I mentioned, a great way for me to learn about PIO because like everybody else did, it was a new thing to learn about. So that was a lot of fun. And I've just continued to get more comfortable with the PIO and the RP2040 generally and that feeds into kind of the big pull requests that I made last week which enables the Rotary IO module on RP2040 boards. That is, I believe getting close to being merged it's been tested out but Scott's gonna take a look and see whether there are any style or substance items to work on. And with that will come some improvements to the Python API, namely you will be able to call the in waiting method for a PIO program that produces output irregularly which is kind of how a quadrature encoder works. And I also spent some time looking for for more size savings and to my astonishment I found a way to get back 1,500 bytes which isn't a lot. It's enough for about one and a half chess games but it's more than we're used to finding so that will give us a little room for comfort as we work on particularly keeping the M0 builds from overflowing. And there's probably other randomness that I forgot but this list already sounds pretty long. So thanks David for explaining the joke in case you haven't seen it. There's a 1K implementation of chess that's not bad at least for a beginner chess player like me. Anyway, so this week I wrote that there is a was a PCF font problem that I wanted to look into but I actually diagnosed and solved that before the meeting and there's a pull request in for that. I've been working on a personal project which is a big LED matrix clock that receives the so-called atomic clock signal from Colorado called WWVB. That's getting really close to being a finished thing. As far as my circuit Python work goes I'm gonna be focusing on creating some more video content that will eventually come out somewhere under the Adafruit umbrella and working on some more guide stuff. And there's the third item. Oh, I'm gonna investigate whether the performance of the Pico is good enough to let us enable MP3s and or audio mixer. That's kind of an exploratory thing that I'll spend maybe a day on and then we'll decide if it's gonna work out or not. And anyway, the fun stuff I alluded to last Saturday our clothes washer died. It was 19 so it had a good life and the replacement will be delivered tomorrow so all is well but not what we expected to be spending our time or money on, right? Anyway, next up is Jerry and then Jose David. There's that button. All right, thanks. I gotta change my name. It's no fun. I always feel like I'm such a slacker going after you Jeff. Oh, don't sweat it. So yeah, I have no idea where the week went but see something I did receive some black bills and started playing with those.  So you put on the two megabyte flash when I did that I found out that the default setup was for a much larger flash. So it was a good excuse to remember how to do a core PR, a really trivial one but it was still fun to do nonetheless and a good way to get back into practice doing that. Yes, try and do some more. This week I wanna play with all those new guides that are out there for PIO and display IO and all sorts of cool stuff. So try some of those. And fun stuff is I finally got around to making an alarm. It's not really circuit Python, but it's close. My dog, which wants to go out, she goes and stands by the door. She didn't do anything, just stands there. Well, she will do something if I don't get out the door pretty soon. So I made a, took a VL 53 LOX, LOX time of flight thing and a tiny PICO board from unexpected maker which detects when the dog gets close to the door and that sends an NQTT message over to my our Raspberry Pi Home Assistant which then sends me a notification on my phone. And to my amazement, it works really well. So really had fun with that.  Other fun things, I got my second dose of COVID. Thank you to the science and all the people for letting us all folks go first. Really is nice to see things moving along here. Thanks. Thank you. All right, I'll pass it to Jose David and then to Catney. So last week I work on the proposal for the new directional label. This label will support different language. So you can write your text from right to left and left to right and top to bottom. Also you can put your text upwards and downwards. So that's an improvement. It works now with the before the refactoring of the display text. I need to port it to the new proposal. This week I will work on some tests on that improvement and retaking the old PR that they were kind of both for the old display text and doing it again for the new refactor library. For fun stuff, the temperature here that are going up above zero degrees Celsius. A lot of running this week on vacation. Thank you. Thank you. All right, so we have Catney and then K-Match 98. Thanks, Jeff. So last week we finally patched all the libraries to move Pilant to the pre-commit and deal with the duplicate code checking on examples. The first patch we ran didn't really apply itself to all the libraries. There's a flag you can build the patch with and typically if you run it with this flag, it's supposed to apply to more libraries but for whatever reason, this time it decided that it would apply itself to more libraries without the flag. So it took us a few tries. We also applied a patch that broke everything for as long as it took us to write another patch to revert it. So we had some fun with that. And then when the patches are run, they spit out a list of all of the libraries to which they were not applied. And so we took that list and a second hug report to FOMI Guy for basically taking that whole list and verifying that whatever the patch missed was updated. So that was super helpful. And I got through, I think, all of those PRs, except for one for a reason this morning. So thank you for that. Last week I continued work on the BLM badge guide and then wrote and published the Feather RP2040 guide. So this week finished up the PRs related to the patch, which I did this morning. I need to finish the RP2040 guide for the Feather. There's one page that was copied in that's a Feather generic page about battery in USB and so I need to update that to be RP2040 specific. And the pinouts page, because the RP2040 has a lot of capabilities on a lot of different pins, but there's some situations where you can't use like two different sets of pins because they would collide. Dan went through it after I wrote it, said it was all clear, but suggested providing a sort of backwards lookup. So instead of just listing the pins and what their capabilities are, list the capabilities and what the available pins are as well. I didn't have time to do that last week, so we published the guide, but I want to add that sort of reverse lookup type thing list to the pinouts page as well. Then next up is update the guide for the AMG 8833, which is a thermal camera. We revised the board to be a STEMI QT board. And so there's a series of things that need to be updated in the guide to reflect the STEMI QT revision. And then I'll continue on slash finish the BLM badge guide and then gather new product info for the cyber deck. It's a Raspberry Pi bonnet and hat that doesn't have any specific code to it, but we'll need a general guide that just says, here it is, here's what it looks like. And here's some download resources. So that is the last thing that I will be working on. That sounds like plenty. All right, so I'll pass it to Kmatch and then Melissa. Okay, thanks, Jeff. So last week submitted a switch widget to the graphical user interface library. That's fairly new. And then the process learned, I at least scratched the surface about Sphinx, the documentation and formatting system, particularly about how to use class inheritance of super and subclasses and a way to visualize it. Also, it did a little bit of work on display IO bitmap routines to break them apart so they can be used in other functions, which will be part of the work for this week. So this week I have a couple of other widgets I want to submit for review. And most importantly, I need to write down at least the few tidbits I learned about Sphinx so I can do them again next time, I hope. Also want to add a couple of bitmap tools. These are odds and ends of bitmap manipulation tools just to help folks want to do some straightforward or simple things to fill a region or draw a line. And particularly, I want to learn more about the vector IO library. It seems like it has quite a few interesting capabilities that may fit the bill in different situations. So I want to be able to understand that. So if people have questions, I can help suggest what the best alternative approaches might be. And along the lines of fun stuff, we had sort of extended cold weather here in Austin a few weeks ago. So as part of that had some repairs to make on my daughter's well system, but it should be good to go for the next 25 years after this. Okay, thanks. All right, thank you. Looks like maker Melissa has had to leave for the moment. So I will read her notes and then pass things to Scott. So Melissa writes, last week worked on Raspberry Pi, BrainCraft, DisplayDriver and AudioDriver conflicts on the latest kernel and looked into an issue with the voice bonnet on the desktop with Google Assistant. Started looking into updating the RP LiDAR to work on a new firmware that is only available on new units being shipped. Fixed some memory usage issues in portal base, added rotation to matrix portal and fixed issues with pylint code duplication errors. Manually merged several IS-31FL3731PRs, including one which had been sitting for a while and became outdated so that everything was up to date and updated the guides for that IS-31FL3731 library. This week, working on updating the RP LiDAR library, likely either update or create a new library for the update 2.13 inch e-ink displays. I think that's the slightly different resolution version. Working on a new guide to incorporate all of the 2.13 inch e-ink displays. Look into further audio video conflicts with other I2S boards. Update Blinka to work a bit better on 64-bit Raspberry Pi OS and other the heading of other fun stuff. Melissa has a new video up on her YouTube channel. Link is in the notes document if somebody wanted to put that in the chat as well. And I will pass that to Scott and then after that it will be somebody at the top of the alphabet. There's that video. Hello, so I'm getting caught up. It took Friday off. My weekend was skiing on Friday, snowshoeing on Saturday, and running in the rain on Sunday. So we did lots of outdoorsy stuff, which was great. But it does mean I'm a bit behind on everything. So today's email and poll requests day. Everybody did a lot of really cool stuff I saw. I saw all the like issue and poll request stuff go by in the Discord, but I haven't looked at my email yet. So excited to see all the cool things that happened there. Last week I created Cascade Toml for Cascading Toml Config. It's at github.com slash Adafruit slash Cascade Toml. Basically allows you to like factor out config settings and then kind of cascade them down to the final version when you need it. For example, I created a Toml quote unquote database of flash config that's at github.com slash Adafruit slash NVM dot Toml. Basically what this allows you to do is say like for a particular wind bond or giga device flash you can say Cascade Toml and it will give you like the full settings for that particular flash even when like some settings may be the same for a particular manufacturer. So that's kind of the purpose of Cascade Toml. So the next step is to tie that config into circuit Python build to generate the RP2040 stage two code for a given flash or flashes. So this will allow us to say like on this board this flash is used and get it all configured the best we can for a particular flash. A prerequisite that I wanted to do is that the existing Pico SDK has this like stage two flash initialization code written in assembly and I converted it to C because I'd rather work in C land than assembly land. So I got the basic stage two work running last week in C and so this week I'll further add some features to that C code along with the ability to actually like change its contents based on the flash settings from the Toml files and that will be a longer term way for us to handle flashes in all of the ports but for now just the RP2040 is the one that's changing. So that's my main work right now. Thanks Scott, I have notes from C Grover and then it's time for Dan. So C Grover writes continuing on the brushed DC motor quest, working on an update to the circuit Python motor library to allow selecting the decay mode of most modern motor controller chips and boards. The default coasting decay mode doesn't take full advantage of the more effective breaking decay mode available in newer controller chips. Using braking mode establishes a directly proportional relationship between throttle and motor RPM. Very handy for controlling robot velocity and calculating distance traveled. When coupled with lower PWM frequencies motor spin threshold and low speed torque are dramatically enhanced as well. We'll need some advice on what UI will work best for the motor library decay mode getter setter or perhaps just changing the default mode to breaking. Submitted an issue in advance of the PR to facilitate the discussion. Plans are to rerun tests for the menagerie of brushed DC motors in the workshop inventory to compare mode differences, submit the associated PR and rewrite the previous learning guide. Hope to receive a shipment of all available Adafruit motor controller chips and boards and N20 style motors this week to verify the tests. And unrelated ish work on the illustrations for the book of poetry continues. My drawing skills are improving, thank goodness. Still not certain what the author saw in my primitive doodles. So next we get the news from Dan and then I will read updates from David. Okay, scrolling, here we go. So last week I fixed, there were issues with the RP2040 bus IO.i2c, the i2c implementation in, on the RP2040 you can't send zero length writes, which means you can't probe easily and stuff. So that was a problem. So I fixed that and tested it. There are still some small number of sensors like the TCS34725, which is a color sensor, which just don't seem to work. And it's really not clear why they, waveforms look correct, but they don't work. So there could be more debugging done, but you can always use bitbangio.i2c instead of busio.io.i2c and that works for everything. As we mentioned, I fixed the last minute bug in groups before the beta. Then I released circuit Python 620 beta 3. I fixed a Talgrid transpose problem. I don't remember where that was before or after the release. I did some more build shrinking, not as much just for particular boards to get things to fit at the last minute while I was trying to get all the PRs in for the release. I did lots of reviews and various things. This morning, I was editing the release notes for beta 4, which isn't out yet for a little while. And I've been trying to keep up with the release notes by each time there's a PR, I add it to the release notes. I don't have to do that later. And I accidentally had published release and there was a beta 4 release for about 10 minutes, but all traces of it are gone and we can have another beta 4 that is there because everything that it labeled or built or anything. So now I'm gonna keep the release notes in an issue and I will edit the top post in the issue. And there's no danger of doing a release from that. And that means everybody can see it and it's actually added because even though it's GitHub and Markdown, the release notes doesn't have that little nice menu bar at the top and in the issue it does. So that'll be great. I was still confused about the I2C ARC2040, the short rights business. And I asked the designers of the ARC2040 and they answered me. And so I got a satisfactory answer about that and I asked them it in the documentation better than it is already. And they were planning to do that. And finally, after several days of just trying thing after thing and turning off code and then turning it back on gradually to see what broke and what didn't break. I think I have figured out how to make ESP32, on ESP32 S2 make I2C not conflict with wifi. And I have to do some more testing and I've asked the ESP32 folks, why does this work? Because it's not really clear why it works, but it does work. So, but hopefully that issue is behind us. We'll see. Okay. All right. Thank you. Next I'll read the notes from David and then we will hear from Fome Guy. So David writes, more fat and hat on a Pico with Pico to zero adapter version 0.2 by Red Robotics. It works with the Adafruit braincraft hat but I2S does not work because of non-consecutive pins. It works with the Pimeroni rainbow hat but the touch button doesn't work for an unknown reason. Also tested with the Adafruit Joy Bonnet. I squared C not working because of a missing pull up.  And there are a couple of Twitter links and a GitHub link there in the notes. And let's see. So we have Fome Guy up now and then after that Hugo. All right, thanks Jeff. Last week I did work on a couple of the libraries that needed a few small changes for the pilot and pre-commit stuff that's been discussed. I did some refactoring in the display text library because we had two different labels that were both their own classes and that had some code duplication and so pilot started flagging that. So I have a PR out there that gets rid of a bunch of the duplication by refactoring it to a base class. I dug into a display a little bit to try to gain a better understanding of tile grid and how it works. And I implemented a fix inside of there to an issue I had found, but I'm not sure if it's really the correct fix. I'm suspicious because it was only an issue on my Pi game display, not in the core on a microcontroller or even like a display on a Pi with a spy display. But I'm curious to see if that's actually a real fix or not that I found. I worked on a PR in display. Well, no, it wasn't in the display IO layout, but it was in the bundle repo to add the display IO layout library to the bundle. I finished up the display text learn guide. I'll be submitting that for review a little while later today. I'm gonna give it one more once over and I might need to make some tweaks now to talk about the new way that group works. I had some explanation about Mac size and stuff, which won't necessarily be needed for too much longer. For this week, I will be addressing any of the feedback on the display text refactor and trying to get that merged. I will be reviewing the other, there's a couple other PRs kind of behind it that need that refactor in first so that the actions will be happier. So I'll be going over those once the first one's merged. I would like to figure out how to embed information about the tiles into the TiledMap game files so that it can know like which tiles you're allowed to walk on it, for instance, maybe some other stuff. And then lastly, I'm gonna be looking at the round switch, the sliding switch that came much added to the display layout library, be testing that out this week. And that's what I got, thanks. Cool, we will round things out with me reading notes from Hugo. Last week, no forward progress on plans and issues. The main newer and faster computer died so all no work work is on the slower and older Mac book. This week, hopefully get to wrapping up progress bar. If possible, the mag tag bitmap issue, specking out and window shopping computers. Are you window shopping windows computers or Macs? That's what I need to know. All right, sorry about the jokes. That wraps up hug reports, which brings us to the final section in the weeds. So first on the list is David. Are you ready to go? Do you hear me? I do, yes, take it away. Okay. So, yeah, so this weekend, I figured out that some peer I did long ago was broken and because new hardware we're using that IS-31, FL, blah, blah, blah library. And then I was a bit annoyed because I guess I've spent a lot of time on that, even if it's very short work to do because yeah, it could be done in one hour, but it took me maybe a few at times. And yeah, so there were incoming peer from all over the place in UK where people tried to bring Pimaroni stuff to Circuit Python and that library was inflating and inflating. Then finally, Melissa solved everything by putting a peer that bring everything together and solved the issue. But okay, maybe I need to find a way to find all of my peer and see if they need some help to be published or something like that. But they are spread across maybe multiple libraries, so I don't know to search for that in Cheetah. So that question, I can tell you that when you log into GitHub, just on the front page, there's a link that you can click to see all of your open pull requests across all of GitHub. And that is a pretty useful area, yeah. So if you can't find that still, we can kind of walk through it after the meeting while I'm not on mic. But yeah, so definitely finding all of your pull requests can be done. I understand that's not the whole issue you're trying to raise, though. Well, I mean, the issue was mostly that I should have been following that peer and pushing for someone to incorporate that. Because if it stayed too long as a peer state, then you get conflict. And yeah, conflict can be solved, but you need a bit of JIT Ninjastuff, which I've done rebased in the past, but it's a fight every time. So yeah. And the son, I don't know if someone wants to discuss that, but everything has been solved already, so your notes and whatever. The only other feedback I would give about JIT being hard is just folks should always make sure that the box for allowing maintainers to edit your branches checked. Because I'm totally willing to go in and like rebase for folks if they think that's, if they don't have that experience, they don't wanna do it. Okay, and the other one is related, is that Michael Ohn, which is having a big, I guess it's big, or what I'm following that since a few years, blog about Raspberry Pi and know the Microbit wanted to use one of those devices that use that library. And for some reason, he did believe that he need to create MPI file. And that led him to believe that he need to install WSL on his windows to compile something like the MPI cross. And he made a blog post that explained that horrible story where it seems very complicated to contribute, where, yeah, I almost never do MPI files because that's automatic. And I'm never gonna compile and install that on a Windows machine. And so I was trying to figure out what went wrong. And yeah, I mean, if he came to the Discord he would have had instantaneous help. But somehow he worked on his own on a Sunday and maybe it first experience with doing that kind of work and say, okay, maybe we can learn something from this. And yeah, and you should read the blog post, it's super. I mean, it's not funny, it's like horrible, but. And oh yeah, okay, and I mean, so you've got a lot of people that are in UK around Pimaroni floating and doing stuff with their hardware which are no interested by the CP, well by the Pico and they are kind of attracted by CircuitPython. So we need to catch them. I mean, from a marketing or whatever point of view because yeah, that's the right target audience or amplifier that can bring CircuitPython to a lot more people in that time zone, that's it. Yeah, I agree with you. I think this happens for a couple of reasons. One is that we were really good at documenting how to build in quotes a library using MPY in the readme's of all the libraries. So I think that's one reason people think they have to do it. And then two, I think people coming from Sea Land expect you to have to build something. And so for anybody who's more experienced that seems like a natural thing to require. But I think it's really important that we should emphasize that no, you don't need MPY files. And in fact, Jerry, I would argue that like you don't need it on an M0, you only need it on an M0 if you can't import it. Which often is the case depending on what you're doing. Right, right, but it's not a blanket thing. It should be a get to that point where you discover you can't import it and then worry about doing an MPY. And also just you can develop on a bigger board and then test it with MPY on an M0 later. But there are also MPY, the conversion, the program to convert is available for download too, isn't it? Yeah, yeah, yeah. Yeah, it was, it's a bit high then. It's not advertised on circuitbyton.org. It was not advertised in that forum discussion on how to compile it yourself. So yeah, I found it because I know it exists. But if you don't, yeah. Well, it does seem like there are some workflow things around creating libraries or community libraries or Adafruit libraries that could use better documentation. And I feel like the place that we do that is on the learn system. But of course, as always, to get somebody allocated the time to work on that doesn't always happen right away. But it's clear, hi, Katny. Yes, I was talking about you. It's clear that there's probably stuff missing from the learn system, but also I'm not sure whether I don't see the name on the screen that Michael, whether Michael Horne would have seen it on the learn system or not, because you can't always have somebody find the right resource, but yeah. Well, no, and we provide documentation on the libraries. So it's reasonable for an individual to consider that the extent of the documentation. Just by looking at it, I mean, if documentation's provided you would not, by default, assume there should be more. So I think one other thing is that we could probably do better with linking GitHub and learn. I think that's something we kinda wanna do and we just haven't done it. And regarding Pomeroni, there were three boards in the last nine days, I think, that were submitted to CircuitPython and CircuitPython.org. So that is picking up traction potentially slowly, but still they're definitely starting to make their way here.  Michael is not another guy. So it's, yeah, we have Gadgetoid that did some stuff and I've been pushing him a bit to do stuff for their featherboard. So it's like, it's individuals. And I've been doing a few boards in the past when trying to use the clue to control my hat and fat. It's because I've got a lot of hat and fat that I don't use anymore because I don't play with Raspberry Pi anymore. So I try to use it with your stuff. Yeah, I mean, I think you're doing the right thing. Like, I think this is something that we all need to take away from this is like, as there are more and more people involved, like we all keep our eyes open for people that are using it and have questions about how to use it and can use help with guidance if they need it about what the easiest way to do something is. And I think it leads to- Maybe if you make a new blog post, then people will read the new one and that will help a lot. I don't know what you mean by new blog posts. You made a long one that make it look complex and now it can make a short one that shows how easy it is. Yeah, no, I think it's perfectly, I think it's really good to ask these questions to Michael about like, why did you think you had to do it this way? Like that's, I'm willing to do that. I've opened it. I'll watch this video as well. I'm curious. When I do see things like this on YouTube, I do try to go through the comments and stuff and try to clarify. Yep. So that's it. All right, thanks, David. We've got a second item from Jerry. So if you were ready, you can have the talking stick. Thanks, I'll try to make this quick because it looks like Dan's already answered it, but at least if anyone's curious. So there was a new guide put out this week by Brett that nicely describes, how to put an airlift on the Pico, which a lot of people have been interested in doing and it works fine. But there was a big emphatic warning statement that you must use V-SIS pin, not V-BUS, or you must use the V-SIS pin and power airlift. And I was really puzzled by that because I'd been powering mine by the V-BUS pin. And when I look at, and I just wanted to make sure that, was I confused or was there a mistake or what it was? And so as Dan explains, it looks like it's perfectly correct thing to say because the V-SIS pin is on the other side of a diode that protects your USB port on your computer or whatever you're powering it from. So that makes a lot of sense, but it does, I think there are some things you have to be careful of aware of that when you read the data sheet for the Raspberry, for the Pico, it does say V-SIS has a much broader range of voltages it can run on that are broader than what the airlift could run on. So you could get yourself into some problems with that, but at least I think I understand what Dan's saying that in general, if you're just plugging USB port into V-BUS, you're better off powering something external extra from V-SIS rather than V-BUS just in case you short something or do something bad when you're wiring it up. Is that what you're saying, Dan? Right, it's just like, don't do this because you might really hurt things. And maybe it should say that. I don't know, I don't know who personally wrote the thing whether what they, what the motivation was, but. Yeah, I think the guide was by Brent, but that's all I know. Yeah, it was.  If you, again, if you wired something up wrong, you've got V-BUS plugged into your, right back vacating it, it would be a bad thing to do. So always good to be safe, but okay, well that clarified it and I just was. Right, and also if you are powering it from a battery by V-BUS, and then you plug it in to five volts, then you might blow up the battery. I mean, there are sort of safety issues. There's like damage issues and safety issues. So I think that's why it does that. Right, and then we have our final in the weeds topic from Ketney. Take it away. All right, so in the midst of all of the Pilant patching and updating, we've run into a number of libraries that do actually have duplicate code and could use a refactor. However, we have one library that Pilant failed on the test's directory. And here is the actions run for anybody who's interested. And it raised the question because for example, when we run Pilant on examples, we ignore missing, doctoring and invalid name. And I guess I don't know the context too well of what we're expecting out of test files in the test's directory and libraries and whether or not we should be just running Pilant on it as is and expect that it should pass. And so those issues need to be addressed or whether we should be updating it to run with directives or what the thought process is there. And I don't know if anybody has input on that. So I think, go ahead, Jeff. I'll just interject that I also encountered this today on the Bitmap font library and... With tests specifically? It was either test or tests. Okay, that's fine. I'm just making sure we're on the same page. And in the PR that I filed incidentally to what I was doing, I went ahead and added like the module level doc strings and then told it to just ignore everything else because it's not code that needs to be read by other people so the doc strings aren't helpful. And that's the decision I made in the spur of the moment but it's not necessarily the one we should adopt. Scott, what are your thoughts? I agree that doc strings aren't that important. I think the daytime case is actually a particular special case because I think those tests actually originate from CPython. I think that's probably true. So I think generally we could treat tests the way that we treat examples broadly. Okay. And then four specific cases where there's weird stuff that still is not passing which I suspect daytime will have. Yeah. I would just at the top of the file say we're gonna disable these checks because we copied this code from CPython and we want it to stay the same. But we should be running... You're suggesting that we should be running pylons against the tests the same way we do examples where it doesn't compare them so there's no duplicate code check and ignore invalid name and missing doc strings? Yeah. I think starting there is a good place to start and then let's... Well, I guess we should probably open an issue to have a longer discussion about this but I think generally like I know when I write tests I have a lot of duplication that's kind of just the... That's totally fine. Yeah. In the case of a test but it would be good to... I wouldn't suggest turning the lint off completely because there is a lot of stuff that is like, oh yeah, that would be good to have consistent. Well, no, that's why I'm saying we can add the tests directory to the examples check in pre-commit so that it just runs it exactly the same way on the test directory. That's, I think it might have to be another hook which is fine but just run it exactly the same way. Yeah. Yeah, that sounds like a really good place to start. Okay, and I guess we'll file it on CircuitPython then because with the library's milestone. Yeah, either there or I think cookie cutter is the other place. Oh, yeah, okay, that makes sense. Yeah, the daytime one's gonna be a special case and you might just have to further disable stuff. Okay. Like for the invalid names of like DT is not a valid name or whatever. Like generally I think that's a good thing to push our tests to not do that but for in this case for daytime where we got it from somewhere else, like let's just leave it. Well, I'm pretty sure if we run it like we run examples, it would include invalid names. Should I make it so it doesn't? I can do that because it'll be another, I think it's another hook. Like I think it'll have to be a separate hook anyway. I think mostly the reason that we have invalid name on there is because in examples, a lot of variables are at the top level and Pilant expects those to be like all caps, like the lobals. Yep, yep. I mean, we could try not doing invalid name on tests but for the daytime ones, we'll have to explicitly. Right, I understand. So yeah, daytime is special. It is. But we're so glad to have it. I will probably involve Brent then as I believe he wrote it and just let him know that the plan is to just basically disable individual things as we go so that it passes because we're pulling it from somewhere else. Right, yeah and I think just at the top level it should work. Yep, agreed. And I will file an issue on cookie cutter then and then I will, I guess I'll talk to Dylan about getting that added because we'll have to run another patch. I should we just or should we do it individually as we go on libraries that have tests directories? Yeah, I would say like just get it in cookie cutter. So if somebody adds tests later, but I don't think a patch is needed because like the vast majority of drivers don't have them. Like I think you two covered most of them between date time and the bitmap loader. Okay, easy enough then I'll just do a find on the bundle and figure out what has what and then we'll just apply it to the individual libraries. Perfect. Okay, that was basically my question so I'm good. All right and thanks for getting those action items in the document keeps us all honest. Anyway, that brings us to the end of in the weeds. So coming back out of the weeds, it's time to wrap up the meeting. This has been the Circuit Python Weekly for March 8th, 2021. Thanks to everyone who participated. If you want to support Adafruit and Circuit Python and those of us that work on Circuit Python, consider purchasing from the Adafruit shop at adafruit.com. The video of this meeting will be released on YouTube at youtube.com slash Adafruit and the podcast will be available on major podcast services. It will also be featured in the Python for Microcontrollers newsletter. Visit adafruitdaily.com to subscribe. The next meeting will be held on Monday at 2 p.m. Eastern 11 a.m. Pacific but reminder again, the U.S. switches to daylight saving time on March 14. Remember to double check the hour in your local time zone. The new time of the meeting is 2 p.m. in the UTC minus four time zone. It is held on the Adafruit Discord which you can join 24 seven by going to adafru.it slash discord. To be notified about the meeting and any changes to the time or day, you can ask to be added to the Circuit Pythonistas role on Discord. We hope to see you all next week. Thanks everybody. Thanks everyone.


So what are the steps in the project? Here I'm borrowing a graph from Patricia Ayala. Patricia is one of our Gerstein specialists. So please don't forget that we have a huge team at Gerstein. What we see here is a topic selection and conceptualization creation of protocol are kind of, there's a lot of iteration between those steps, right? And we see that there's a lot of preliminary researching happening there. So preliminary searching is an important concept. You're not just going to be searching on the green step there, searching for studies. No, you'll be doing a lot of searching ahead of your main search to scope out the territory before you do the scoping review. And that's so that you decide and realize what has already been done, right? So here I'm comparing the steps that Patricia listed out to CAHR steps. This is something that you can take a look at later as well. And here's another great resource, Oliver and Thomas, the systematic review for policy decisions quick guide which is available freely as well. And that one's listed as one of the resources. So we're really looking at the first three steps today. And here are some more steps that are described in a bit more detail, okay? So the big thing that you need to do even before you jump into doing anything with protocols and you'll see how this actually relates to your protocols is establishing the need and what has been done. This is so hugely important. You need to search for other systematic reviews, knowledge, synthesis, scoping reviews on the topic that corresponds to your proposed research question so that you know what's been done and you don't reproduce or replicate needlessly what's been done or that you build on what has already been done and reuse some protocols. So you can be more efficient and you can be more productive while extending knowledge, right? So we have a number of these databases that include knowledge, synthesis. So from the applied health and this would also apply to our biomedical engineers. We have the Cochrane Library Epistemonicus which is a South American grassroots initiative, fantastic resource. The JBI from Australia, this one's found through the nursing databases, fantastic. And the TRIP, the TRIP Pro is a fantastic open source medical search engine and it provides evidence that is classed according to the pyramid I showed you earlier, right? So these are really good places to look at what's already been published. So let's take a look at the TRIP demo. So let's look for, for example, something that's really hot in the news and not necessarily in a good way, ivermectin and COVID-19. So ivermectin as a treatment or a prophylactic for COVID-19, just going to type in COVID, that's going to pop out what we need. Ah, look at this. So last time I did the search was a couple of months ago. I think there were 20 something studies. So now we've got 49 results and look at what TRIP does. TRIP immediately classifies these resources into systematic reviews, synopsis, guidelines. And we see that there is, and they're actually two from Australia. Wow, guidance, regulatory guidance, there's nothing there. Primary research, there are only four. While we look at all the evidence-based synthesis and the reviews in comparison to primary research, I actually know of more than four. So it's interesting that they're not indexing all of them, but that's an interesting issue. Okay, yeah. So there's more primary research here. They're at least 10, as far as I know. So seven is good, plus four, yeah. So they've got at least 10, 11 of those. But look at this. They're ongoing systematic reviews. They're 22 ongoing systematic reviews. That's fantastic. So if you're interested in this particular field, you know that it's hot and you know that there'll be at least 22 more systematic reviews coming out. So it's in your best interest at that point to find out what aspect of this field are being studied by those other teams and try not to duplicate the effort, right? So this is really important. Excellent. So they're mostly 2021. There weren't many in 2020. There's one here, but that one was, yeah, that's an evidence-based synopsis as opposed to a systematic review. So you can always jump just to the specific kind of evidence that you're interested in, right? Let's be slow. Okay. There you go. It's showing our primary research right now. So this is one way that you would do your preliminary search. Your preliminary search is really important because it gets you a sense of what is happening in the field and what others are doing. And you can do that in a variety of disciplines, right? So I showed you the four basic healthcare and applied health sciences databases, but we also have Campbell. Campbell collaboration looks at social welfare, social justice, crime, education. So it has a very broad base. We have the epicenter, which I mentioned earlier, which looks at a lot of the historical issues having to do with the rise of systematic reviews. And that looks also at political decision-making. So this is how you would get a sense of what has happened already, right? And there are a few others, I'm not going to go through all of them and there are disciplines like certain kinds of engineering that are not very well supported. So what would you do in that case if you're in one of those fields? Of course, what you would do is you'd go into one of the databases that you're going to use primarily for searching that we're going to be discussing tomorrow. For example, GeoBase or InSpec or the IEEE Explorer, any of those databases and do a quick search for some of your keywords. Does this search have to be as detailed as the search that you'll be running in your knowledge synthesis? Not at all. But it needs to foreground any work that's going on. That's very important. So now we will be looking at the step two, which is working on your research question. And this is where you ask yourself, what will you review and accomplish and what are your underlying assumptions? Okay, so everybody's probably heard of Pico and Pico is a question framework that comes from Dentistry, actually. This is the original article from which Pico comes. And it's part of evidence-based decision-making. So asking good questions. I'm just going to go straight into offering you an example with Pico and we'll work through it quickly. If you'd like to play around with Pico and other framework, I have fillable Pico organizers and other organizers that are available to you. So if you're interested in these, please send me an email after today's session and I will send you the information. So let's take a quick look at an example. Let's say this is a research question that we have. Are there all facial injury patterns that have been used or could be used as markers of future violence in the context of family violence homicide? So this is a forensic science question and something that I've worked with one of my faculty. So when you're using Pico, you're looking at the population. So how would you describe who you're studying? The issue you're studying or the intervention. So what are the treatment exposures or what can you say about the issue that you are studying for your cohort? Often in healthcare, you've got a comparison or control. So what are the alternatives to what you're doing to the intervention? And then you have outcomes. Often there is also a T or S term in Pico. So it's a Pico or Pico. And that can look at duration type of study or how often you'll be redoing your study. So that's another consideration. So here for this particular question, when we break it down, the population is easy. Victims of family violence homicides with or facial injuries. So unfortunately they're no longer with us, but we have a control. We have a comparison that's not obvious and that would be victims of family violence homicide without or facial injuries or accident victims or other homicide victims that are not coming out of the family violence pool with oral facial injuries. Because we want to compare the kinds of injuries sustained. And of course here we're looking at those who are deceased. Now the issue is assessing whether patterns of facial injuries that are observed on family violence victims can be used as any sort of a prognostication or diagnostics or advanced warning for family violence prior to homicide. So again, we want something among the lines of early warning and it's not easy to take these questions apart to fit them into PICO, right? Now PICO is great for healthcare applied healthcare. It could be great for biomedical engineering, but in education it might not be the best. So for your context, there are many others. And this part I'm going to skip through very quickly because I want to spend a few minutes on protocols. So if you're interested in these slides, you'll be able to see eclipse. You'll be able to see how it's applied to a very quick question here. You'll be able to see spider, which looks at phenomena of interest from the point of view of design of interventions. And it's really good with qualitative studies that spider. You'll be looking at SEMO. SEMO is great and a lot of psychologists, for example, love SEMO because they look at mechanisms that explain relationships between the interventions and the outcome, right? So SEMO is very interested in the mechanism. And sometimes when you don't have the interventions, the PCC is great. That comes from the Joanna Bridges Institute where you look at what's the population, what's the concept you're studying, and what's the context, right? So PCC is short and sweet, could work for you. Biner is great for almost any research question because it wants your research question to be feasible, interesting, novel. And that's where of course looking at prior work is important, ethical and relevant. And there are so many more. So I'll quickly flip through these slides because they have examples. And this is something that previous attendees really wanted to see. They wanted to see more organizers and more examples. So almost every page has an example. And here I have two real research questions that I've been working with. One is in industrial engineering and one is in psychology. And I show how I fit these into SPICE, SEMO, Eclipse and SEMO just to get you a sense of how they can be used for refining your research question. Okay, so we've got about six minutes and now what we're going to do is jump into protocols, right? So we've outlined why we need protocols because protocols help us to keep bias in check and to set out the steps of our process but they also help us to refine our research question. And once we have a protocol, more than half of the work is actually done in terms of conceptual work, right? So let's take a look at what happens with the protocol. We have a lot of help and guidance with writing protocols. There are three sets of resources. There are Prisma resources that help us with protocols for systematic reviews, like analysis and scoping reviews. There are Joanna Briggs Institute's protocols and there are actually a few others as well but I would say the Prisma and the JBIs are the primary protocols that outline step by step. I said three and then I realized that, yeah, some of the others also list protocols but very often the protocols that you'll find in let's say OSF or epistemology because are derived from either JBI or the Prisma protocols, right? Cochrane has a protocol as well, so that's really the third one but Prisma is one of the very first that you need to go to. So what is a protocol? A systematic review protocol describes your rationale, your hypothesis and the planned methods of the review but along their way as you fill out the protocol you answer a ton of questions for yourself. So that goes back to our initial question. Do I have to talk about how I decided which kind of study to make? Yes, you do and that comes in the protocol, okay? So here's the entire Prisma 2020 protocol checklist. This is the brief set of items, only 15 items for a systematic review, okay? And I'll show you the detailed one in a moment. So that's the detailed Prisma 2020 checklist that gives you a lot of elaboration. And here I've outlined two areas that we need to look at under rationale, objectives, eligibility, pardon me, criteria. Under the rationale, the protocol tells you exactly why we do pre-searches. So why we go into databases like Trip to see what has been published because the protocol asks you to describe the current state of knowledge and the uncertainties and articulate why you need to do the review. So by doing the protocol, you save yourself more. And of course here and their objectives and eligibility we have why we do PICO. We do PICO because it helps us to determine the objectives and the criteria, the inclusion, exclusion criteria and the eligibility criteria. So PICO or all the other organizers are really great at foregrounding those parts of our upcoming research. And here's a sample scoping review protocol. This is the Prisma SCR checklist. This was published in 2018. So again, it's very recent. And you'll see Andrew at Trico's name right there. So what do we do here as well? The rationale, the objectives, the eligibility criteria show us again that whether we do a systematic or scoping review we need to do pre-searches. We need to interrogate our question. And again, when we do eligibility we don't do convenient samples. We think about everything, including how far back do we want our searching to go? So do we stop at a certain year? Do we assess the entire literature? Because that's really important, okay? So we're basically at the end of our time and we've covered the three main things. First of all, definitions and typologies of knowledge synthesis. Then we've covered tools that you have to help you ask better questions. We've also covered places to go to do your pre-search so that you can fill out your protocol. And you see how every step that we've done so far feeds into a better protocol. So the rest of this just shows you more protocol examples and places where you would get protocol checklists and more support. And this is an example of Prospero where you can find protocols for systematic, not scoping reviews but systematic reviews and scoping review protocols. As examples, you can find an OSF or in fig share. So next time we're going to talk about search, that's tomorrow. And we do have a number of others who support knowledge synthesis, specifically Gerstein, but also Oisy and Roberts. And there are colleagues at UTSC who do it as well. Now, please complete the feedback form that I have included in chat. Thank you so much for any feedback you can provide me. And please feel free to join the session tomorrow.


Hey everybody, Matt here for Latent Sports Cards ripping one box of 2022, Panini Prism FIFA World Cup Soccer first off the line This is for Christopher C. Good luck Christopher Shida and Antonio Rutiger. That is Blue Shimmer Auto numbered Blue Shimmer International Inc. Gareth Bale, Blue Moussa Diaby, what we'll reach before if I mispronounce anything feel free to talk Yeah, guys, I'm gonna mispronounce the names, but I'll do my best Marquinhos Silver and France Alexis Vega that is Red Mojo to 99 Edinson Cavani, the Hortene Boyle, Yusuf Poulsen Atraf Hakimi Hyper Jude Bellingham, Jeremy Sarmiento, Huiyang Zhang Neymar Jr. National Pride Silver Insert Paul Pogba, Silver, Linel Messi, Pink Adrienne Ravio, Rafina, Lewandowski Orange, Memphis DePay That is to 25 Rodriguez, there's Mbappe, Martín Boyle, Martin Boyle It's probably Martin Boyle, Australia, rookie Silver Abdul Rahman, Garib, rookie Kiyogo Furuhashi and Blue Shimmer that is Eden Hazard Your entitlements, Red and Silver, Jarls D'Cattelere Take Jordan Pickford, Hyper, we're probably, I'm guessing There's Antoine Griezmann We're probably full for today, but Kyle will be ripping starting at five Over on the late and to channel, I'm Eric Laporte I'm Eric His first name is I'm Eric I'm Eric. I'm gonna add an AY to mine. I'm Matt. I'm Matt But yeah, so if you order and I can't get to it before 330 Kyle will be ripping over on the late and to channel and You'll be at the front of the line for that. That's Casper Kozlowski Rookie Ice, Jeremy Pino and Yusuf N. Nesiri All right, that'll do it for your box. Thank you for the purchase. Appreciate it Christopher. We'll get these right out to you


time to all of you. I am Mr. Sheshikant B. Gosavi, Assistant Professor, Department of Civil Engineering, Valchan, the Institute of Technology, Sulapur. Today we are going to discuss regarding global positioning system coordinates based on which we will have some learning outcomes. At the end of this session, students will be able to explain the coordinate systems. They will be able to compare various coordinate systems used in global positioning system. The student will also be able to convert one coordinate system into the other coordinate system. Wow, this is a wonderful picture of how the global positioning system works. The conventional nav star used to have around 24 number of satellites into the space placed in a systematic manner. And the orbits of various satellites is beautifully displayed in this picture. The total satellites were 24 plus and the distance of the satellites from the earth was around 20,200 kilometers. The inclination used to be 55 degrees and orbital period of each of the satellite was 12 hours. There were five ground control stations to enable data exchange with these satellites. Each satellite passes over a ground monitoring station every 12 hours. The GPS is supposed to have three components, ground control point, the space segment and the user segment. At the bottom, you can see the planimetric view of the whole world around which the satellite used to move. This is the classical example of how exactly the GPS functions. This is a geometrical explanation. The earth itself is a big sphere. The distance of the satellite from the earth is what we call as the range. At a given time when the instrument transmits the wave, the satellite, whatever are the waves which are sent will be received by the instrument. And based on the time traveled between the transmission and reception, gives us an idea about what should be the distance or range of each of the satellite from the earth. Each satellite will give their respective range. So, satellite number one will be having this much distance from the ground point. Satellite two will be having this much distance from the ground point. Satellite three will be having this much distance from the ground point. And therefore, intersection of all these spheres actually enables us to get exact data of coordinates of a point on earth. As has already been told, it is a spherical trigonometry which is dominant in this case. This is the principle of geolocation with GPS. So, because of the trial iteration, we are able to find out position of each of the object on earth with the help of the satellites. And then later on, GPRS or GSM technique allows us to exchange the data. Finally, the things can go into the cartography or mapping science. The Cartesian coordinate system, all of us are familiar. That is a planar coordinate system. We are very much familiar about the y coordinate and x coordinate quadrant. And then in the first quadrant, positive, positive. In the second quadrant, x axis will be positive, y will be negative and so on and so forth. This is one of the very, very well known coordinate system which we are familiar with. This is particularly true for the planar drawings. Map projection is one of the very important part of GPS coordinates. Because what we are actually doing is the spherical surface of the earth we are supposed to project onto the plane drawing sheet or the computer screen. There are several ways of doing that. You can have a shape like a cone, you can have a shape like a sphere and accordingly there will be variation in the projection system. So, projection system is very, very important for us to make our positioning of the point on earth valid in terms of geodetic coordinates. Just now I have spoken regarding geodetic coordinates. All of us are familiar that there are planar coordinates wherein x and y coordinates were there. In geodetic coordinates however, we are working on the surface of earth which is a sphere. So, here the spherical trigonometry plays major role. WJS84 is the most reliable coordinate system with the help of which we can get exact idea about how the things can be done in relevance to the respective thing. Here you can see the shape of this particular sphere. It is ellipsoid while this is the conventional spheroid. Of course, both of them are having their shapes. This is oblate and this is prolet. Oblate is the one which is used in case of the world geographic coordinate system. Here the classical coordinates like latitude, longitude, altitude in reference to WJS84 system have been shown. Here you can see 0 meridian is assumed to be over here. All of us are familiar that through the green which the geographic meridian goes with reference to which the longitudes of the various points on earth are recorded. And equatorial plane is most often taken as the respective 0 latitude plane. Above the equator towards north the respective points are assumed to be taken with positive coordinates and on the lower side with the negative coordinates. So, it will have plus in the northern side minus on the south side. Similarly with reference to the meridian towards east and towards west we will have certain coordinates. This is again another classical way of showing the word geodetic system. You can see that earth is not perfectly sphere. So, it is ellipsoid having the variation into radius almost everywhere. Along the equatorial plane the radius is largest while perpendicular to east it is smallest. So, here it is 6378.137 kilometer while towards the polar axis it is 6356.7523 kilometer. The mean radius of the earth if we will assume it to make up a sphere in that particular case comes out to be 6371.0088 kilometer. This is very important for us to know. So, a measurement is equatorial measurement, b is a polar measurement and mean earth radius which is shown here in red is another way of presenting it. There are several ways of having the coordinates. This is earth centered earth fixed coordinate system. Here the center of the earth is taken as the origin and with reference to that distance a, distance b and radius etcetera are worked out. This is the radius along the prime vertical which we can easily work out by knowing the values of a and b as well as we can work it out with reference to the angle phi. So, n phi that is radius of the prime vertical plane will be equal to a square divided by square root of a square cos square phi plus b square sin square phi. ECEF coordinate system are better version of presentation of geodetic coordinates. We have a liberty of conversion of units of geodetic coordinate system. The numerical value of latitude and longitude can occur in a number of different units of format. The classical is sex as decimal degree which is degree minute and second system 40 degree 26 minute 46 second is an example of how we can present it. A degree and decimal minute is keeping the degree same, but the minutes are converted into the decimal. So, you can see the minutes represented over here as 26.767. The decimal degree actually converts everything into decimal and present it in front of you. Coordinate system conversion is at most important. pq which is a prime vertical radius as has been shown over here. This is p, this is q. So, this pq is said to be n phi. The length iq this particular distance is e square n phi that is e square multiplied by the radius at prime vertical and r is classical coordinate system of x, y, z. So, what we are aiming at is converting x, y, z are getting the x, y, z from the geodetic coordinates of phi, l and the respective height h. These are the equations corresponding to that. If you have the knowledge of n phi, h phi and lambda you can obviously convert it to the x, y, z coordinates. Please pause the video for a while and answer following questions. Comment about what are different coordinate systems. Similarly, how can we convert the formats of coordinate systems? The answers have been given in this particular slide for your information. I have used the reference of this websites for getting the information into this online educational resource. Thank you very much.