 Welcome it is December 1st. This is the Microsoft DevSync meeting. We're just going to go through again real quick and get everyone's status updates and take any notes about things we might need to have meetings about offline. So I'll start with Chris there. Yeah, so I got some testing done today. I didn't have to make a change to my query, but everything's going to be looking pretty good now. I also made some changes to the API and I'm going to provide to Ken. Ken, can you talk about that because it's not quite the API that's in the document so for various reasons, but it should still serve you for this. So yeah, I need to test that API point a little bit more, but other than that, I'm ready for something different to do. Obviously, I'm waiting on some voter views and I'll have to put a list of the production and everything. But yeah, as far as coding and construction is concerned. Great. Let's talk about that right after this meeting. Derek, how's it going? So yeah, we're working today on changes to the SJ240. I talked about there's still a couple things left to finish up. And then there's this new single button in the middle of the top piece and changing a few things in the back because the power is running up to the back. The other thing I was doing is today we've got parts going out to our, hopefully our partner on the assembly side of things. This is just the, what would be the first couple hundred developer units of what we call the DevKits back in the original Kickstarter days. And so this is not a 3D, but fully 3D design, although I want to get one so that it's possible for that as well. So I'm going to go ahead and sit in the laser cut all the parts necessary are going to go out today. And so first tomorrow, I am going to start looking at, I haven't done anything yet, but I'll start looking at packaging and basically going to stuff for Sprint 18 regarding the fulfillment and all that. And one of the things out of the game is packaging and manual and stuff like that that we want to include with these kits. So we'll be starting to look at that tomorrow. Okay. As well as Johnny and Josh are going to have a meeting to talk about ordering the kit on the schedule for today. I'm going to send those parts as quick as possible so that, you know, we can get this conversation started and we may be talking about sending parts to the assembly as opposed to pulling them here and sending them somewhere else after this. Right. Yeah. See if I'm shipping it or nothing else. All right. Yeah, the anchor image is all working. Thanks to the systems. We've been working with core to migrate and a previous configuration over the Wi-Fi connectors and didn't light up yet. And so that'll be tomorrow and then start to get for all those smaller tickets and like to be there for all that for the self. And but yeah, very good step forward. I think once the Wi-Fi connectors in there then we can get it out to everyone and start using it on a daily basis. Other than that, most of them are catching up on the PRs and things. So we have a new method in the GUI to close the skill, the UI for the skill and make that easier. And so getting back to some of the skill settings because we talked about before. And yeah. Is there a document or will there be somewhere on how to acquire devices up to Bandicoot? And you guys are done with it. Yeah, so I'm actually thinking we think to approach this. But like the majority of the team, I think we have a central, we have to use the central management functionality. And, you know, so for like Derek, for example, I don't think you want to mess around. You know, while they're messing around with hand scores back in system and pushing individual containers and all that sort of stuff. You just want like a device that sits there. And when there's something ready to be updated, then one of the dead things hit the button and pushes that out. And that also then helps us to test that process. I think it's going to be used for retail consumers. Yeah, we'll have some documentation on how to do stuff manually. Okay, sounds good. Great. So I'm just going to cross the board here. So Emily, did you get what you needed from Kevin? Have you been able to look on the PCBA quotes? I think and he said I'll have it for me early tomorrow, hopefully. Okay. All right. Josh. Josh is next. Thanks. I built a financial model for the next two years. And then had some discussions with that and then have been working with one of the lawyers surrounding discovery. Right. Okay, thanks. And Ken. So real quick, get that I hear that. Automated pushes to the devices happens every night at midnight. Is that turned on? We have to manually push. So, in other words, it's marked to push. No, at the automatic. There will happen every hour. Yeah. You have to put your device. I am a demo. And since we're a voice system, I don't need a screen. Hey, Mike, set the volume to 90%. 90%. Hey, Mike, set the volume to 30%. Hey, Mike, set the volume to 50%. Hey, Mike, set the volume to 50%. Hey, Mike, set the volume to 99%. Hey, Mike, set the time. And Mark, hearing today. Hey, Mike, set the time. You are a little slow. You look a bit sluggy, like myself. Anyway. So I have the code ready. And I've got everything working end to end for the first time. This is a kiddy image, by the way, but now there's no. I've refactored out the market to skill. to worry about that. I have two lines together to change in these root systems, mark-tube scale, so it doesn't mess with the I2C bus. I can't validate that the fix, which is in Michael's fix, is working 100% because I don't have an FJ201 with working led. So while this one came up and didn't have sound, and so then I pressed the activate button and 30 seconds or 60 seconds later, it matched with that sound, I couldn't see the visual where it goes red for like until it's ready and then it goes black. So I'm assuming that once I have a working FJ201 that'll work fine, none of this code will change once the new I2S stuff is done as well because that's completely different path and it's essentially the volume and I'm assuming that the only thing that would change here would be the actual command to the XMARC chip and the volume volume. So I'm gonna go ahead and put this pull request together, put it into the mark-tube branch and then load it or update my image with it on my panic or build. If that doesn't work, I have a workaround for the 2T image, the front 2T image, and then you can just go in and switch to the mark-tube code line and do a get pull and then run the object. So we have options there. It was quite a bit of work actually because when I turned off or reset the XMARC chip, you can't just yank out the rug, not underneath the size and the audio service and the listener and all of that. And so I actually have to turn off, have to stop the voice service, stop the audio service, give them a little bit of time, reset the hardware, give it a little bit of time, bring up the audio service, bring up the voice service and then it'll work. So it's actually a 60-second process, that's it. I haven't optimized those timings but I'm sure that they save through work. So yeah, and it's just a workaround, I'm assuming, until the I2S is out, someone can spend a lot more time on it. In fact, a lot of the stuff that you can. But we will have working, frozen hardware once I get this all addressed in. And that's it, and I approved the pull request for somebody, I've been pretty voluminous and I didn't have an opportunity to go through. Everything, I'm assuming you know what you're doing with the rubber pull request before. So that's my update for today and I will work with Chris tomorrow after I get this committed and start moving on to the machine learning aspect. Okay, thanks Ken. Yeah, I appreciate the demo. And the, yeah, and the update, the more extensive modifications you had to make there. If it's not a change that you can make generically that you think we should push to core, I'd at least like to make a note of what you had to do in terms of starting and stopping these other services because it seems like there's, you know, feels like one of those things where there's 10 drills going in lots of places where maybe there should only be one place where the audio gets started and stopped. Well, what I have to do is actually run the stopmicrof.sh command and startmicrof.sh command from within the script. So it's actually a really nasty hack. It's actually down in the GPIO interrupt switch handle for the action. And whereas you used to simply say start loosening and take off that process, you now go to like all that you've done, which is basically shuts down the services, then resets to hardware and then brings them back up. So it's your standard microf start and stop, except you can give them a particular service name. So that's what I do. Okay. All right. Well, I think we should make a note of that it seems like there might be room for improvement there, even if we don't need to do it right away. Yeah. Yeah. And again, once we have the new Westgate 201 and everything's working, I go in and I change a couple of lines together to fall through to what it used to do and remove this hack and everything back. Oh, I don't mean that there's a problem with your hack. I expect your hack to be a hack. I'm saying with the underlying architecture, it seems like maybe there's a problem that we had in that you have to do the hack. Yeah. I mean, you could look at it like, well, it should be covered when the microphone handle it loses the false audio. But, you know, that's, there's a lot of, like you said, there's a lot of tentacles down there Yeah. between false audio and ALSA. And so this is a very rudimentary, nasty hack. Yeah. Okay. Yeah. All right. Great. Well, I guess that's everybody, except for me. And I don't have much of an update. I've been preoccupied with business stuff. So, so I guess that'll be it for today. Are there any other issues that people want to bring up or things that we need to talk about? Any word from Kevin on the progress of putting those together? Can you speak to him, too, once again? Not as of right now. So, I'll, I'll ping him and see what's up. And I was going to ask what's the, what's the ETA on a, on a QT image that is loaded through Panticore and runs with updates? It sounded like it's really close to done. Yeah. So, I think it's worth, is writing for the BlackRock Connect, unless you want to, unless you put it in a Panticore, you know, in which case the parent thing could work for you. But, tomorrow. Was it, did it come up by default into the pairing, the pairing stuff? Yeah. It's the same as, it's basically the exact same thing it's able to send you to the real user pool. Yeah. I don't know if that image wants to be here. It could change. The same thing as a butterfly could be. I thought I saw it in the chat. Panticore said that right now it falls through to the old pool, the network manager. I want to, the question I'm asking, I'm being too specific. The question I'm asking is how long until we can turn it on and replicate the end user experience that we're expecting to ship out of the box. Even if it's just rudimentary, it's just starting to. So that should mean tomorrow. Okay. So, and then do we have a process in place that if I ship the unit tomorrow to, let's just say that magic, that getting stuff magically comes up first time, I ship a unit tomorrow to John Dorr, right? That it will turn on and just run through the whole thing and then John Dorr can leave this sitting on his desk and it will continue to update and prove itself. Yeah. Okay. And do we have to define the process of like, what's the workflow going to look like? Can it put in a patch for whatever and it flows through this entire process from start to finish? There shouldn't be any patch. The tickets that we have outstanding with Panicor are designed so that we don't have to patch anything. And once I push this full retry through the market through depository tomorrow, that should be the way to do it but coming out of Panicor. Let me read it, let me read it finally. I was just like, hey, what was the final plan? Anything that goes into our, anything that goes into our normal repose. So like, if we make a change to Micropor or make a change to the size, then make a change to the limit, anything like that. And that will get packaged up every night for the next meal. We're trying to build everything from source rather than pre-packaged things. So any change will actually get reflected as soon as possible. And then the other place where we may need to make changes is in the packaging of Panicor itself, which is through essentially Docker file. So if we wanted to change something about how C-groups work or something like that in some of the underlying Linux stuff then we would change it there. But yeah, so any change that can make to Micropor, for example, that will, we can either trigger it straight away or it will get built up in the next night. All that stuff is working. And here's my next question is, so one day that I start to answer, I can take place on my desk here and make it a Mark II up in my kitchen. You cut out a little bit there, but is there a one-page shape that explains how to do it? Is that what the question was? Yeah, for me as an end-user of the system, I can grab an image somewhere, flashes to this guy, go set it in my kitchen, connect it to Wi-Fi, associate my account, and each skills will work. Yeah, so there shouldn't be the need for any instructions that should be flashing and configuring the device and then we manage the updates. Yeah, that'll be done tomorrow at this time. That's, yeah. I don't want to be a naysayer, but I say no. Well, it sounds like it's ready today, except that... I mean, I'll break it. I'm sure that I'll break it within five minutes in touch, so don't worry about that. I think it's a high level of why I would say such a horrendous thing. So there's a bunch of jurists that could doubt the panic work. They have to do, you've got rules, they have to do with permission and routes and stuff like this. There may be even a couple of other ones out there. I'm not sure. And until such time as they've had a chance to complete those jurists tickets, which I didn't get the feeling that's what they were committing to today. They were committing to having a working bill, or the gooey message box and stuff that was working and maybe the Wi-Fi setup was working. So that's how I felt like they were kind of leaving it, that that would be working tomorrow. That would be great progress by the way. Now I think we're gonna need to be gently nudge regarding some of the jurist tickets. And we're gonna have to do that. And then I'm gonna have to test it and make sure that that's working. So I would be cautiously optimistic that the answer to your scenario, Josh, would be maybe by the end of business Friday. But obviously if it could happen before that, I'm just saying I would think that Friday would be probably the earliest we could say, yeah, we've gone through this process, we've pushed the new image to panic work, we've verified everything. Okay, and then I'm gonna put the limit up on the work because we haven't put that card in hours yet. I'm sorry, what was that for? Like things like the buttons and stuff, they're not gonna lift tomorrow, if you're sure, because we're gonna have to close that. I'm gonna push that full request, if not tonight, first thing in the morning. And so on they go, it'll be part of the bill. Cool, okay. So let me rewind this conversation in a minute. And I know that we're at it, this is not supposed to be here. Cool. Ken, you told me that the LEDs were not, the way you phrase it where they were not working, but I suspect what you meant is they are not exhibiting the production behavior that we're expecting when it comes to resetting the bus. They're actually, are they gliding up and spinning in a circle? No, what I meant is I have either a defective SK-201 with a bad AT-tiny from the... Okay, so you did speak accurately, they're not working. My next question is, how are we pushing up the AT-tiny from the... Okay, I can answer that one. On the rev three boards, there is no way to push updates to the AT-tiny. So on the rev four board, they can be pushed via the Raspberry Pi. Okay, so I just, on the rev three board, I would have to pin some things out and push it back. Well, you need one of these one time, it's a one pin programmer that you get from the people who make the tiny chips. Yeah, it's not worth doing at this point. So, all right, I think I understand where we are. Good work, folks. It seems like we're about to break through. Like, Tim, you definitely are like, hey, let's do all this for our fans. When are the Europeans? I'll show you. You're, you know, the rugby, you're in the strum, and you've got the ball, and you're charging, you just can feel the whole thing giving way, right? And it's an open field to the post, to run these goal posts. I love it when Josh tries to make sports analogies. He knows as much about sports as I do. Yeah, well, I do know you're supposed to have a quarterback if you're playing football, which the Denver Broncos appear to have forgotten. See, I do, I do read four newspapers every day. Okay, well, it sounds fantastic and, yeah, this is awesome. Yeah, agreed. I think if we can get a working unit fully up and updating by the end of the week, I think that would be amazing. I would be so, I'll put one in my kitchen and then we'll start pushing data back and Chris Sawyer can get the data pipeline fixed for the part, and we can move on to, and then, you know, flip in the, flip in the, you know, start running it for about real life back in the time to see what it's like, hey. Yeah. So. All right, go team. Back in the team. If we can buy $5 with that additional cost, then. Maybe you could afford to buy some batteries for that headset so we can hear you. Don't break up when you get more than five feet away. No, it's not, it's a phone call. It's not a, it's not a thing. Okay, sorry, I'm, I'm excited. Awesome. All right, well, thanks, that'll be it for today and we'll pick it up again tomorrow. All right, see you everybody tomorrow and go team.