 Welcome to the Minecraft Developer Sync on September 2nd. So, we went through the Jira tickets last time, so this time we're just going to go ahead and go around the screen here and get updates on everyone. I mean, blockers or exciting news that you have to share. So, I won't go first this time, since apparently I'm just a spoiler. Yeah, we'll let Chris Vera go first. You've got to unmute yourself there. Freakin. From the ground ground. So, I did submit a PR with all the stuff the work I've done so far on the upload API endpoint. So that is done and I'm working on the script now that will take the day's utterances and move them over. I'm also doing some work in documentation on the Lakewood Tagger document. I did some work yesterday and I'll probably do some more today to get us to a point where we can have another discussion on the design. And I am going to probably spend the next work day or some of the next work day on a patent so that I have something that just to talk about in tomorrow's meeting. All right, that's what I like to hear. No blocker. Everything's cruising along. Okay, great. Derek. Okay, so yeah, I've been mostly working on MK to dash 49 ticket, which is the full assembly of the first rev 3D printed design for the SJ21, which is hopefully I'm still long track to finish that this by the end of this week. I think it's going to be close, but I think I think I can get it done. And then the other things I've been working on are getting ready to assemble laser cut closures for Chris and can myself starting out. The update from Kevin on that. I think the last time we talked was like, oh, we might have stuff like on route, but he ran into an issue a short on one of the boards, I think they gave him pause. So he was going through some more robust testing. He hasn't actually shipped the boards yet. So probably not with shipping time and stuff, probably not going to get those until next week. Yeah, so that's where I'm at. And it looks like Michael was kicked over. So, so one of the things Michael asked us that we can go ahead and share the laser cut. Kevin had some recommendations to make things a little easier playing on this one, like those changes. But then I think we can share that out with the community. But we need to kind of tidy up our, our system, our part numbers. So figure out what we're going to call like the laser cut versus the 3D printing direction. Yeah. I, to be honest, I hate that stuff. I just like, like, you know, Rev one dash, you know, August, whatever, you know, I just, I'm terrible about part numbers, but Yeah, we should figure out the best for that. Yeah, I did you talking about that because I have the ticket that I gave you. Yeah, yeah, yeah. All right, well, we can, we can meet about that. It should be a short meeting. Yeah, I'm happy to adopt whatever. You've got a month. I, I, whenever I on it's up to me. Yeah, we've got a system outlined in the, in the work on repo. So I think we'll just go ahead and use that and see how it, how it stands up to actual real world use case scenario. And question about your 3D print model, is that a FDM model or is that a Yes. Yeah, the idea, well, the idea is to start with the FDM, like, because that's the, what, you know, most people will have access to their community, but also do as much thinking as possible to align it towards injection molding as well to try and not make it that much different. So one thing I'm doing here tonight was going ahead and adding some draft and like that that I think, like, at least on the major drafts that will probably be needed for injection molding. Go ahead and put those in place. You know, there are some accommodations you have to make. Generally, I'd like to be close to the same as possible. Just from the standpoint of getting some early devices out there, I would love to. We've talked on regular, regularly about making soft molds and doing resin casting and just it's never become something we do. I kid it up for all that here. So I would very much like to see if we can do these and resin in soft mold resin cast because we could get, you know, dozens and dozens of devices off the off the line and even if it's just for early adopters and what not, it would be great to have something that approximates the final injection molded device. Yeah, I think that becomes that becomes a bit of a labor, you know, labor versus, you know, 3D printing issue because the casting processes does take some time. So we can find a place to do that. Also, in the size that we are going to be, we are going to cast the size can be. But yeah, there's this outfit Johnny found that can print our whole enclosure in FDM. So, you know, it's going to have this triations and such it's not going to be super smooth. Really reasonable price. So that's how you guys are going to look at it to just farm them out. You know, print farm and get it for like 30 bucks a set, which is like almost five times cheaper than the most online services like ShakeWay. All right. Cool. Yeah, we should weigh those two options for sure. Okay, let's see. Yes. Yeah, then most of you can continue with the 2008 release stuff, which is all in place. Hit a little snag yesterday. Doing the final testing on one of the mark one. The date time skill didn't update cleanly. But I think it was a one off. So I've just been sort of retesting that to make sure it's good. But I, there's nothing in the updates that would actually cause that. I think it was just a network issue. It does raise it raised again with me that, you know, in the longer term we need a way of recovering from those sorts of things better. Everything in the error log. This one was actually a one of the Python packages didn't update, didn't install one of the new dependencies didn't install. Because that's still showing a merge conflict in my error log. So that would be like, if you, you know, if you change something on your device or you're editing the skills on the device or No. No, the version he has is the TV version. So there might be some problem with that. Oh yeah. Yeah. Yeah. Anyway, I think, yeah, I think that'll be a different issue. Anyway, so the 28 should be ready to push the button. Pretty soon. And everything else is in place as a PR up for switching the marketplace over to 20 late as well. And given there's only one skill that's been removed from 20 to 20 late. That's a pretty innocuous change on the, on the front end. So we could merge that anytime. I think. Yeah. And the exciting thing is that the, the Mozilla web thing skills has been completely rewritten by community member James MF who did that rather integration blog post a while ago. And so he's rewritten it with full common IOT support, which also raises that, you know, we still haven't released officially released the common IOT framework and waiting on the, there's a control skills that goes along with it, which has some, I think Python 3.6 specific code in it, which therefore doesn't run on all of our supported devices. So there's the final little piece in the common IOT framework that we have to get out there to actually have support for that. But everything else is like all of the changes are already in core and everything. But there is more community interest in that framework at the moment. The home assistant is already ported across that they're, you know, waiting to switch until it's actually supported and that sort of stuff. I created an ethic for fully releasing common IOT and things that we should look at that at some point. But it will mean bumping out supported Python version from, yeah, like 3.5, 3.7 to 3.6 to 3.8, which I think we need to do anyway as well. Yeah, I think that's it. So as part of your 208 release process, do you actually, so clearly you're testing it on a mark one. Do you test it on all the versions of the mark one, like all the software versions. So going back to the first, you know, if somebody's had a mark one sitting on their shelf since they ordered it. Tomorrow is the first day they plug it in. And I test it from like the original 202 release. But I am not currently testing it from older like you could do that. Are they serial? So like in order to get to the 208 release, does the device have to first get to the 202? And to get to the 202, does it first have to get to the 1908? Or does it, can it go from like, you know, 1702 all the way to 2008? It should be able to jump. Yeah. So we use 10 packages for the mark one. You know, Microsoft Core is just a package. So, you know, it doesn't ask to update and uses the latest table image and jump. Okay. Yeah. It would probably be a good idea to test more than just in this reason. But it seems like we haven't had any problems. Yeah, well, and, you know, we've been supporting the mark one for a long time now. And, you know, I am very much a believer in continuing to support hardware that still works. And, you know, that's one of the great things about open source is that, you know, you don't have someone like a certain company just like arbitrarily turning your devices into bricks. But at the same time, you know, you need to, we're going to obviously put a lot more time and effort into the mark two. And, and there's less time going to be going into the mark one. So, yeah. Yeah, I think it's going to be a process. Yeah, yeah. Yeah. Yeah. I mean, for the for sure, you know, we did that needs to be. If we're going to obsolete, you know, piece of hardware, we have to let people know that we'll have time to not do it just because they haven't updated it a year. Okay, well, thanks. That sounds good. And so can your on deck. Okay, so file the bug is, as you know, on the screen and captured the log output shows where that error is, I didn't have a chance to fix that one there was a couple other ones. I fixed regarding the timing issues with the bring up sequence that I spoke with Chris the about Chris that monkey patch I gave you is pretty self explanatory right just says, at this point if I don't have. I handle the bus. Go ahead and give me one right and save it. That takes care of kind of the bring up timing issue. If you want to incorporate that or if you have a different approach to that's that issue. There was something else that I saw in the log files and I fixed but I can't remember it. And then on the power up issue. I've I've isolated it down to. Well, it could be a couple of things. It could be power related like the power we're providing to the daughter board but I doubt it. It probably is firmware, but it could also be the issues that they are very sensitive about regarding like, when you tell them something's not working on their forums. I'll go back two or three kernel versions to where they're sure it's working which means there's, you know, they're not keeping up with the software there's some differences in the USB ports are handled on the pie for that being said, I'm working on a solution for it. Brute force approach for now, since I don't really know what the problem is, but I did have it with the firmware version that it came out of the box with that the factory reset run on it. At boot time would solve the problem, which is a bit of a brute force approach. I tried to rewrite that code a little bit to, instead of doing a factory reset on the board, just resetting the USB device at that level. I tried that via the level USB drivers and via their actual, I figured out how they communicate using I octals and stuff going over the USB channel, which will be the same way we'll do it for our board. I tried to create some code that would reset the device at both levels. At the one level the USB level didn't work at the device level it bricked it for a while. That turned out to be a problem where reorganized the USB priority of the devices and then it kept writing the wrong place and getting a pipe error and all this foolishness. I'm trying to isolate it to you, whether it's firmware or whether it's the interface software between the card and the host. But in either case, I do know that, I mean, the brute force approach right now is if you flash the, you know, the firmware upon boot load, which is an extra, I don't know, 10 seconds in the boot up process. It never, it never appears. So, you know, I'm just not sure what the problem is yet. I don't think that's the solution. I'm trying to get it at reset device level. But, you know, I suspect when we have our board will have similar issues. I don't know how much I want to spend on this. You're talking about the firmware of the US, the USB chip or the sound card or the re speaker, the re speaker. Talk about the XMOS chip. Well, if the re speaker boards firmware is the equivalent to the XMOS chip, then that answer would be yes. Yes, that is the answer. Okay. Yeah, I assume it's just like some shell, you know, we actually we actually found an error in the reference design that XMOS gave us and and Kevin was having some problems with this so he had to redo the way the power supplies bring up because the XMOS chip is very sensitive to the order in which the power supplies come online and holding its reset line low. So, so, so it's sometimes it works and sometimes it doesn't in the first reason of the board. So in this, the most recent brain, he's added another chip in there that guarantees that reset will, you know, remain low until the power supplies are stable in the right way. So, we might not actually see this problem in the tool. Yeah, I mean, it could be that right. That's why I say it's, you know, it's in the bring up. I don't know if it's voltage. The other thing is with powered us be sometimes downstream devices have trouble. So I don't really know what the problem is I know how I can brute force fix it which is to wedge in a, you know, firmware update every time we reboot the device. You know, and like I said, I'm working on potentially being able to reset it at a device level. The USB I optimal doesn't work but they're down low. One does. It just borks the whole thing, because you have to kind of tell the USB stack that I'm resetting this. It could also be the suspend in the pie for with these USB devices there's a suspend mode it goes into where it goes in a low and it could be giving it trouble from that perspective I really don't know. Now that being said, you know, I don't know how far we want to go into this like I said I have a solution for if it comes up and it doesn't work. I can give you commands to get it to work. You know, and I don't know if we want to wedge that in our boot processor not at this point, but I would be interested in taking a look at when Chris has done seeing if the yes no issue is just their their skill or whether it's endemic across all skills. I could switch over to that too if you want me to look at that. Okay. Well, we'll see how this goes. I'll check in again on Friday if you figured it out today then you know, just get in touch with guys. Yeah. I didn't. Right. So, I told kid in this but I just want to remind everyone actually I'm sending an email which part is a complex. When we get a board a respect or migrating B2.0 board, we flash it around, you know, I have been, you know, Charlie was flashing it over to a different firmware from the stock. 40 it's on their repo. It's the 48k one channel firmware. And the reason we do so is because that one had much better playback audio than the stock handle higher bit rate playback and sounded way better. One sound kind of like garbage. So, anyway, but the rescuer people of that were actually fairly responsive when we asked questions about this, you know, back 10 months ago. So can I come forward those previous correspondences you want to reach out to them. Anything would be helpful. The concern is I don't understand the architecture of the speaker board guts yet. So, I know it has an XMOS chip on there. I know I can get to that XMOS chip using USB control packets that go over the USB line. I don't know if it has another processor on that board that's coordinating all of that and taking those commands and translating the XMOS and then doing the ins and outs and timing or if this is done in hardware, I assume it's done in software and firmware. So when we say firmware, I don't know that it has. In other words, I have the 48k and the one K the one channel and the six channel. I have all that firmware here as well. It's actually included in the pie for under the USB for microwave subdirectory and actually the code to send out the commands to the hardware is there as well. But a lot of times there's a heart there's a there's a small microprocessor driving or gluing the commands over USB to the XMOS chip. I don't know if that's the case here. So I'll have to look at it. So yeah, any correspondence you have can only be helpful. Yeah, I think that'll be useful and also can you know that it's reportedly an open source system so there's the link I just pasted in the chat over there is an overview of the board so you can see the system diagram there. Very good yeah I didn't have that one where the hell this come from. And also, I just emailed that same link as well as the github repo that has the firmware, which, as you mentioned, can is already in our image. It's in the folder already but I give you the report to us. Yeah, I mean I visited the repo I've actually modified their, what is it called dfu.py downloader. That's that's the code I basically took off that has the download capability but if you dig around in there. It also shows you how to do a bunch of stuff reset the device reset at the factory mode. Take it offline take it online get status send status all that stuff. So, yeah, and like I said I was actually able to kind of pseudo brick it by sending out a reset device. So, yeah, just don't know yet still still big and that's where I'm at. Okay, well I sent you the wrong link but in that page you can find the right one. Sorry. I actually pasted the wrong link in there, but from the links that I gave you can get to the right, the right ones. Yeah, which is the micro h point overboard. I think it's a circular board is that right there. Yeah, that's it. That's it. Yeah. The micro respeaker micro v2. Yeah, I have that I just haven't had a chance to dig into the schematics and the other thing I haven't really had a chance to do yet is look at our schematics and the GPIO mappings and make sure that we're not doing something silly like sending the GPIO port and not, you know, honoring the previous bit state and maybe accidentally setting something so I haven't had a chance just reading and documentation for me at this point just getting up the speed on stuff. Okay. So, for my part. Let's see, we can talk about any updates on the mark to hardware yet to the status on that is that Kevin's got his enclosure it's all put together. He's got some some demo videos of running. We're right now. Basically, we're in the process of tuning things at this point that literally tuning because the audio isn't very good. So he's running some tests on that. And then once he gets the boards over to us, we can start working on the enclosure and the skills and whatnot to turn it into an actual microp device. You know, he's got the whole system up and running on the, you know, on the Raspberry Pi playing, you know, full screen videos and, you know, watching YouTube videos and playing music and all that kind of stuff. So, so the hardware is all working, which is great. So now it's job is to support our system. I don't really have anything other than that. Oh, that's not true. I have one more thing I wanted to talk about. So Ken assigned me a ticket this morning, I think, and he said he assigned it to me because I didn't know where it where it should go and, you know, wanted to make sure we talked about. So that's that's totally fine. That makes that makes sense. And it had their desired result, which is that, you know, I gave it some thought and I realized that I also kind of have had this question. And I kind of came up with my own solution. And I'd like to discuss it with you guys. So the, so the issue is, so I've been coming up with some issues in terms of, you know, either ideas for the upcoming sprint or bugs that might be in the current hardware or software. And the question is where to put these right. So if it's an urgent bug, I've been assigning it to the person I think who is, you know, most responsible for that. And then either putting it in the current sprint or the next sprint. Right. And so the question is so, you know, whether to put it in the current sprint or the next sprint is kind of, you know, it's a judgment call. But, but I think everyone gets notifications when you get a new ticket assigned to you. So you can take a look at those and either decide whether it's appropriate or not for the sprint it was given when I put something in the next sprint. So currently we're on 13, I believe. And so the next one would be 14. That doesn't mean that I think it's necessarily going to be done in sprint 14. It just means that it can be part of our process of evaluating, you know, well, our sprint planning process for next Monday. Right. So, so just in terms of setting expectations there if I stuck it in that sprint for with your name on it. It doesn't mean that I think you need to get it done in that sprint, but we should talk about it. And then there's some things that are just obviously going to be backlog issues like oh I've got this great idea and we should do this you know but it's not, it's not a burning need. And those things you don't have to put into a sprint, they'll just go in the backlog and we'll find them, you know, when we're setting up our sprints. So, or, but I do think it is useful to assign them to epics. So if you don't assign it to a sprint then maybe you should assign it to an epic or, you know, both obviously that's applicable. But almost everything we do these days, there's an epic for it. And if there isn't, then maybe think about making one. So that's what I wanted to say about that any thoughts or comments. One comment for me is that about Monday, which is Labor Day. We're planning on meeting Monday and having our sprint planning or should I move that. That is an excellent question. I don't know the answer to whether or not it's an official holiday but I suspect it is. Okay, so then we won't be meeting Monday. But we, a lot of places are giving Friday off as well. I don't think that's an official holiday. I know my kids get the day off, which is great. So, so our Debsink might be a little noisier than usual on Friday. Is there anybody who's planning on not being around for that? I'll be here. Awesome. Okay. Alright, is there anything else that we should talk about? I just concur with your assessment that things should have either an epic or being a sprint. Otherwise, I'll just get lost. And at some point, you know, when we get all that free time, we should, you know, keep doing that deer pruning and add things that haven't, you know, just been thrown in there, make sure that they've got ethical stuff. And I just think when we, when we create epics to it, like coming back to that document that Chris started, we've got to try and do some good thinking around how we construct those epics and make sure that they're like tangible projects with a tangible outcome and contained and all that sort of thing. Yeah. Great. Thanks. So, yeah, the backlog has 606 issues in it right now. So, and I'm pretty sure a very large portion of those don't have epics so. Right. Yeah. Okay, well, that'll be a fun project. Maybe when we get a new hire. Here's our backlog, have some fun. All right. Thanks everybody. I'll see you on Friday. All right, thank you guys. Oh, don't we have a meeting tomorrow too? Oh, probably. Because I was commenting to my.