 All right, welcome to the 23rd of what month is it 2020 wait, no, September. This is the Minecraft episode. Okay, so yes, we are somewhere in the middle of 2020. And earlier this week, we had planned an extra large sprint for ourselves for the next two weeks. Have you guys had any follow on thoughts to that? Any decisions to fair down the expected and more for what you're going to get done in the next two weeks? I'd like to hear about that. But let's just go around and hear what you can up to and if you've got any relevant updates. So let's start with guess. Well, I've only added a couple of tickets since we made the enormous sprint. Super sized sprint. Yeah, I just added obviously the Wolfram Alpha API went down, which they're still chasing up. Yeah, okay. Cool. But it's not, it's not a Spotify situation just so the community knows. Well, presumably we'll see you tomorrow. Anyway, I've disabled the tests that rely on that to pass so that our CI processors don't all fail. We got a good response from the mark to update that went out yesterday. So yeah, there's some good comments and a few questions and stuff. There's even questions about whether the people can buy an early SJ201 if they, depending on what the price is. And thanks to Ken for reviewing their Refactor Intent Service PR. That's now in and working on a few other things that don't really need discussion. And the road map, actually the road map is worth mentioning. I've started, so I started starting up the brainstorm notes that we put together into a publicly available, into what will be a publicly available document. But for the projects that are actually a repo like Microsoft Core, I thought that we should use my idea is that we use the project boards, which are, you know, think can ban board inside GitHub to kind of have that as a live process that is actually part of the workflow. The benefit, a big benefit being it can help me actually know which PRs should be getting our attention next and which ones are, you know, next down the line and then which ones can, can wait because, you know, they might be good but they're just not. They're not on the road map or, you know, they're not quite ready. Anyway, so I've started doing that on Microsoft Core now. There's still only a handful of cards in there, but I want to kind of get through the backlog and categorize everything so that, yeah, can have a better idea of where we're at. And it's also prompted me to close a whole bunch of old tickets, which is very useful. One, the one other thing that I want to get to pretty early this week is exposing the microflogs from the BoiComp CI test. So at the moment, you know, something goes wrong that we can't replicate locally. There's not a, there's not an easy way to figure out what's going on on that remote system. And we, at the moment, we blow away the microflogs. We take the BoiComp output, but we don't keep the logs. So I want to have a look at how we can grab those, which should help us figure out some of these CI bugs that we're seeing that we just haven't been able to replicate on any local machine. So that's me. Okay, that sounds great. I've been noticing a lot of activity in terms of responding to old PR and things like that. So do you have an estimate of how much of a backlog we still have to go through? Let's do it. Is it small? I would say medium to large. I mean, I think the biggest issue is that there's a number of pretty big PRs that could really do with some actual review. And so it's, yeah, I think there'll be plenty more that something isn't working and then someone replied and then the original user never responded. And so those we can close up. So there's probably like hundreds of tickets that are out there. I doubt that we're, I reckon we certainly be under a thousand by a margin. But yeah, I think there's, I think there's a fair bit of reviewing we could do, we could just spend multiple sprints reviewing PRs and still not get to the end of it. Yeah. Yeah, so we've known that I guess I'm, I'm asking more for the community's sake so that they can have some expectations. So, you know, what our process is and when we think we might get caught up and into a more sort of workflow that we consider to be sustainable. Right. So I think we're probably Chris is frozen. So I think you missed everything you just said sorry. You missed everything. Okay, great. So I was a large part asking for the community's benefit. So that they can get an expectation as to when we, you know, might get to into a steady state where, you know, new PRs incoming get classified very fairly quickly and put into the bucket of okay well we're going to address this right away versus. We're going to put these on our roadmap, you know, to work on this kind of thing. So it seems like we're, you know, at least three months probably, maybe five. We're being caught up. Is that a fair guess. Yeah, I think that's pretty fair. I mean, like, because, you know, there's, there's, like, three years old. And, you know, we could take the approach of the first PR gets the first review but that means that the newest PRs are not going to get reviewed for five months and they're the ones that are actually, you know, based off our current code base and more likely to get. So I'm trying to sort of take a middle ground where we, we maintain, try and maintain what's coming in now and, and slowly deal with the backlog. So. Okay. Do you feel like you're making progress with respect to the size of the backlog? Is it, is it getting smaller, or is are you trading water at this point? And this might be a problem that we don't solve until we have more developers. To be honest, I think I'm trading water and my focus is on getting some structure around the backlog so that we can understand the backlog better. Okay, that's great. Good to know. Sorry, I had a travel finding loop button. So I finished the code for the, for to get all the precise database converted over, at least for the tables we have now. I ran into two issues as I did it. And basically I'm building separate files for those and we'll address them later. So I'm taking the most prevalent naming convention and doing all the conversions for those and then I'll have to re-attack the other naming convention in a separate pass. I'm running it on my personal database right now just to make sure everything is smooth. It takes about, it takes a while because I need to go out to the precise server and look and make sure that file exists before I actually put it on the database so that we don't have dead records. So it takes about 10 minutes per thousand records to run it. And there's about a million of them on the database. So, yeah, it'll, I'll probably just be like, you know, run this thing, start off a job that does a bunch of like 10,000 or something, go do something else while it runs, you know, for the next couple of days and see how far you get. So what I, actually what I want to do is after I'm comfortable with it on my machine, I would like to get the next version of Selenium out because then I can put the next version of Selenium test and put this data on test so that, you know, Ken can make sure that it, you know, does what he needs it to do. And then we can move to production. But so yeah, that's where I am with the, conversion code that's moving along. And while that runs, I just pulled the upgrade Selenium UI to Angular 10 ticket into in progress. So I'll be working on that. While these run, that's a prerequisite really to getting any of the Tag or UI work done. And we'll hopefully clean up some of the issues we're having and get hub with insecure or risky or deprecated libraries that we've been getting. So yeah, that's, that's me. And I have, I have my, my laser cut SJ two of one now thanks to Mr Derek. So something else I may spend an extra time extra cycle on is getting an image plugged in there and see if I can get it to boot and stuff. Okay, just a quick back of the envelope calculation tells me it's going to take seven straight days of runtime for you to complete your, your process at that rate. So I don't know if that's reasonable. Yeah, it's, it's a quick, it's really just a Python notebook. So, you know, I might do something I'm the only one thing I think when I speed it up is if I just, you know, downloaded this listing of all the files and, you know, I'm going to go to the Brzei server and compare it against that and memory instead of going out to the Brzei server every single time. I have a file that would probably speed things up quite a bit. So, yeah, yeah, it's not slowing anything else down really. As of yet. My direction is to what you're going to do with your sj201 mark 2. We're going to try to get an image running on it. It shouldn't really be much different than any other specific tasks that you're going to work on. No, I was just going to try to get it running. I don't think I have any, anything assigned to me regarding that. So I just wanted to get it running so if I did get something assigned to me I would be able to use it. And I know it's down. So if I miss some things, forgive me. My short term memory is not what it once was. Oh, hey, this really cool new system that we just started using about a year ago. Well, at my age, we wear shirts with pockets and put a little notepad there and that kind of handles it too. Yeah, so. All right, let me think. First of all, Chris V the. There is not only that it is not only the case that there are files in the database which don't exist on the file system. It is the case that there are 540,000 files on the file system that don't exist in the database. Just an FYI. Okay, so that being said, it might be a good another good reason to download file system contents and do a memory somehow, and then have a list of things that didn't get matched up, you know. Okay. Anyway, so what I've been working on the variety of things the first is a couple of full requests that that I reviewed those are done. I got my sj 201 dual driver setup but my question is, because Chris said this while we were talking before this meeting. We were going over what I'm going to discuss in a minute. Am I to understand that this device will not work unless I use the amplifier because the amplifier and the sj 201 I have is not working. The amplifier on the sj 201 that you have does work. It just is very, very poor as an amplifier because of the passenger swap. So it will work, but it may will not be very loud. That's fine. That's fine. Okay, so I don't need the external amplifier on this jig to get it working. That's good to know. Okay. Yeah, so as I mentioned at the last meeting I got the enclosure code classes done, and I started integration into core. And, yeah, so it's bubbly. What happened was that the low level GPIO stuff requires pseudo privileges to run. And so we really don't do that. And so I hacked start to make enclosure runners root, which of course didn't work because all the code was in the skill. I did not want to make skills run as root. So I pulled stuff out of there and put it in between closure. The problem is that when enclosure runs as root, it barfs it has some issues. And those are there's a variety of those but not the least of which is our architecture causes it to be super classed by code that isn't running as root. And that's bad and needs to be refactored as well at some point. My initial intent was to clean it up and refactor it and get everything nice and neat. But my fallback was always I can brute force it if I have to to get it working. And so after burning a day and a half of realizing I'm not going to be able to do this elegantly. I am now working on getting it working in a brutish manner. So it is actually calling out with a Python OS system command that says pseudo Python three run this script that does specifically the function I need. Obviously, not an elegant solution and something I would like. But we'll get the job done because most of what we're doing is not time sensitive anyway turning up the volume reading the switches whatever and as I was mentioning. When the meeting started. This kind of puts a damper on being able to have users hook into the callbacks for the buttons. That being said, it's okay since they have dedicated functions right now anyway, they're indeed printed on the or etched on the board. So I will make those work as advertised this button will do volume up. Volume down, et cetera, and we'll deal with the ramifications of ugly code downstream as as it seems been the case in the past. So that's where I'm at. I should have this running doing volume handling leads and when the buttons by our next meeting on Friday. I can't I can't get I couldn't. Yeah, I couldn't get my new mark to working because I didn't get a SD card when it was shipped and that is going to be here hopefully by tomorrow or Friday. As soon as I get that I will flash the boot image so that I can convert it to boot off of usb and then I'll burn the image on the usb card and boot off of that. Okay, great. So, I need to involve you and direct myself and Kevin in a discussion about the next spin on the sj201 for for reasons which I will get into when it's my turn. Okay, alright, so yeah, Chris mission earlier I got him his device yesterday, and I did make a little tweak to it I threw on the back of the acoustic chamber I threw on the amplifier that we were using on the off the shelf design to drive that audio chamber from the line out. I guess it didn't actually work pretty well, just as a kind of band aid until we can get past the amp so if we actually one of the sj201s, the amp was not working at all internally which I suspect had to do with that that capacitor switch. That was Chris's device to play play stuff and I think it might actually just have that on all of them that we're doing for this first round as a way to if need be test the acoustic chamber. I like to just have a ways to isolate the systems and say okay this thing actually working so. I think a pause from printing the. The first 30 printed version for a variety of reasons one. Michael might get into in a minute, but the other reason is kind of bumped up in priority getting the sj2 30 the sj2 30 which is the laser cut designs for parts for Michael and guess. So I got those on the printer and the laser cut stuff which should be done by the end of the week. So be ready to send those out when we have boards to accompany them. I've been today mostly wrapping up where we left off with the gooey tiger. A couple of things outstanding there, especially around how to get to it where it's going to kind of live in the navigation. And hopefully I'll have that actually done by the end of today. So I'm not blocking Chris. So that's, that's where I'm at. No new tickets. Okay, great. So for myself, I actually got to get my fingers a little bit into the hardware debugging yesterday. And a short call with Kevin and we were able to figure out the. The audio problems he was having. So XMOS released a firmware update at the end of July that we had been waiting for started this project. And the upshot of that firmware now that we've tested it, you know, how it works is that it may allow us to greatly simplify the sj201 design. We can theoretically take two ICs off the board. And use instead of using any GPI at all, we may be able to use the DSI interface for LCDs, which would be allows to use a good quality LCD that's a lot cheaper than the mippy interface points that we've been planning. All told, it might save us as much as 25 bucks on the bomb, which would be really awesome. So it probably won't quite save us that much. But this causes a couple of issues. One, we might not be able to have the fancy 12 LEDs that we have on the current design, just because of the GPIO constraints coming out of the XMOS chip. But unless we can figure out a way to write our own custom firmware for controlling those, they'll be restricted to fairly simple operations that we can do. There's no reason why we can't write our own firmware, but it's going to be a question of bandwidth. So maybe we'll be able to come up with a compromise where we can come up with a design that allows us to do something now and upgrade it in the future with just firmware. So I'll be talking with Kevin about that. But it greatly simplifies the audio data path. So the audio data will go out of, well, basically it'll be all USB driven. There'll be no other interface to the board. You'll send audio through USB directly to the XMOS chip, which will then send I2S output to the amplifier, which, you know, is, it's as simple as it could possibly be. So we don't have to have dual audio streams, one going to the XMOS chip, one going to the amplifier, anything like that. That's our goal. Whether we'll actually be able to get there is going to require some experimentation. And so it also might be a little bit of a step backwards in terms of progress on the SJ201. So what I need to have a discussion with, you know, with Derek and Ken and probably Josh and myself to decide, you know, what path do we want to take forward? Do we want to get the prototype boards out as soon as possible? Or do we want to try to get it out in a manner that's going to be more cost effective? And the difference probably in the long run isn't that great. But, you know, we're in a state right now where, you know, every couple of weeks is critical, right? So we might end up actually dealing both. So we'll see. But so that's the update on the hardware. I think it's really helpful. Literally, every part of the system now works. It's just a matter of giving them to all work on one board at the same time, which Kevin is working on. So the audio application is a really simple thing. Kevin now has the properties and stuff, so he can just re-solder those fairly readily. If we need to have those amplifiers fixed for any kind of testing that we're doing now, just let me know and we can send those back to Kevin for good work. And you can have the amplifiers working well for testing the audio chamber. Oh, as I was going to say, I don't think that's a high priority right now. I think that, yeah, if we need to decide which way we're going to go in terms of prototyping the next round, I think that's the higher priority. And I think what we've gotten out of work with the answer work for the foreseeable future. The big thing for me is that the sooner we can get to all of having the exact same thing on our desks, the better. So I mean, like right now, can you have something very rigged up and, and I've got something kind of rigged up so. That's sort of the trouble with this prototype stage, right? Because everyone is sort of a device. So here's my question for you guys. Would it be useful to save two to four weeks, maybe two weeks in a couple weeks, in terms of getting an SJ201 that does work and has all the functions working so that you can start writing software for it? Or knowing, well, I guess knowing that in two or four weeks, we'll have another version, which is not really software compatible in the sense that right now, you know, the data path works one way and one way. So, in fact, you know, the interrupts will be different. And, you know, the I2C control will be different. And so there'll be a number of different differences at that sort of low level. Is it useful to continue developing on the correct system, knowing that those changes will happen? Or would you rather, would it be more useful to spend your time on something else? So if I'm understanding you correctly, all the change is PIN22 becomes PIN47, the I2C channel is 9 instead of 7 ad noisium. I mean, that's just configuration. It's more like this. Instead of using any of the Raspberry Pi's I2C PINs or PPI opens, you'll be sending USB commands, which will then control an I2C master controller on the Xbox chip. So it will have an I2C bus that will communicate with other parts. And so, you know, software-wise, you know, it's not really, you know, it's difficult to send USB commands. No, no, no, I get that. But it's a different kind of the major change that, and this is something where I think we need to talk about it. And this is why I want to talk about this potential change with, you know, the software and hardware at the same time is that in this proposed to new revision, we won't have any actual interrupts coming in. And so, as Ken, you found out, you figure out how to do interrupts through Raspberry Pi and that sort of thing, but you are running into some, you know, system-level triplet stuff, right? Using this new data path, all of your interrupts would be coming over the USB bus. And I don't actually know how this works, but, you know, from the documentation that I've read, defining a personal interface device as a type of thing that's on the USB bus. Can generate interrupts. So, like, you know, it's a, it's a keyboard, right? It generates an interrupt when the user presses the key. That sort of thing. So that's the kind of device that, that sort of behavior we'd be looking to use with this new data path. Because when I first pressed a button, it would generate an interrupt, you know, via the USB. So handling USB interrupts is the thing we would have to learn. Well, no, so, so, I mean, just from a high level where you're heading there is we're going to have to write a device driver for the device, a Linux device driver. There's no other way around it when you go that level. But that's not what I'm concerned about. So, or really that that's a big issue. Reading between the lines of what you said, am I under the, am I correct in the assumption that we will have access to the firmware source code that runs on the XMOS chip? And that is unclear. Then how will we do all of these things also unclear? Oh, no, well, that's not clear. The, the current firmware that they give us has a pretty well documented interface with controlling the GPIO and an I2C master controller that they've implemented inside firmware. Where is that document? Where is that document? Because that's not the VF control file. Okay. And that is a C program, by the way, right? So, yeah. That's going to require a device driver for us to develop for our own hardware, which is not impossible. I've done it. I've done filter drivers and Linux device drivers before. It's, it's just, it's disappointing because what we have now shows up as basically a sound card, a generic sound card, and access to the additional functionality is through well understood API means, which is GPIO and I2C. In this new approach, it's going to require device driver because all of that's going to have to go through a interface that's going to convert the commands. There's going to be one interrupt coming from the card that's going to say, here's USB data. And then you're going to have to figure out is that mic input is that GPIO. And that's going to change the audio data path. It still shows up as a sound card. The XMOS to implement a USB 1.0 compliant sound card. So for audio input output, you can just use regular sound card drivers. Correct, but the problem is, correct, but the problem is that current sound cards don't generate interrupts for buttons. It's not the sound card device. It shows up as multiple devices on the USB bus. Oh, it's going to show up as multiple devices, kind of like the microphone and the output. Exactly. Multiple USB devices. Yeah. I don't know. I'd have to look into what that's going to take. There's going to be some heavy lifting that being said, did Kevin take a look at the switch code that I sent him to determine the initial latch up problem, or was he too busy with the sound stuff. I don't know. The reason I ask is because if we decide we need pull downs on those switches and that would be something we would want to incorporate before the next revision of boards. And that dovetails nicely into project. Roll over. I always want to say overlord project roll over who is patiently awaiting us to replace their non functioning hardware with working hardware. And what does this decision do to that timeline. That's a good consideration as well. So there's an intermediate path where we don't eliminate the two ICs that we have on board, which doesn't enable us to use the DPI interface. But it allows us to continue using the software as we're writing it now, but it will continue to use the DPI for interrupts and for like controls and that sort of thing. But it will basically fix the data path so that we have. I'll put one on. And it. The sound card. Is the is the significant benefit in the bill materials cost realized by the replacement of the lead drivers. Is that the primary cost factor there? No, it's basically we're using a chip and the USP sound card chip and an amplifier chip. So we've got those three chips in the fully optimal sense. Well, yeah, maybe it's not clear to me. Okay, okay. And did you discuss with him anything about the potential capacitance issue on these switches. No. Okay. Yeah, okay, so I don't have an opinion one way or the other intermediate paths tend to be annoying because, you know, we already have like a version of our image that works with the re speaker. And now we're getting one for the sj201 and then it'll be sj201 alpha sj201 beta and then sj201 final. But yeah, I mean, I'm flexible either way I'm just concerned about the account and what the ramifications are regarding their their hardware because if I get it back and it's what I think it is which is it's not really dead in the water it's just dead to audio, which makes it sound like it's dead in the water. Then I can certainly reflash it and it'll work until the next time it doesn't and then they'll be back in the same situation, whereas I really haven't seen that annoying behavior out of the sj201. So that's my concern is turning something around. That's going to within a week, exhibit the same behavior versus something that hopefully that would go away. So that that would be my only input on that. For me, the biggest thing on the hardware side, physically is the switch from the DSI to the DPI interface really is kind of interesting if, if we're no longer interfacing the GPIO for the sj201 itself. And, you know, freeing that up to drive the display, the whole orientation kind of might need to be rethought a little bit. Not a lot, I don't think, but a little bit. We also are going to need a board to convert that kind of bulky two by 20 40 pin GPIO to, you know, a thin FPC style connector that's actually on the display, which actually could be on the sj201, but you know, that starts to get kind of complicated. So, I don't know. Well, yeah, it would, it could be, I guess. Yeah, it, it could be. Yeah, and then we'd be using just, we would need the I2C on the Raspberry Pi for the touch input, because right now that's all going through the DSI. I was going to say otherwise, why would we need that connector, but yeah, I didn't think about the touch input. Yeah, so. Yeah, it's not as easy as it might look at first glance. So, we might, you know, we might end up not with necessarily cost savings, but at least a fair bit of that. Well, there is a big cost savings potentially because so far I understand most of the displays we've looked at, even these wave share displays, which you guys all have, you know, your device is powered by DSI. But really the display itself is an RGB display, which the board on the back of that display is converting the DSI maybe interface to RGB. But really, if you're getting rid of the middleman, you're getting rid of the converter board, and now you're able to talk to display, kind of in a native thing, sort of a certain degree, that kind of having the cost of the display, because now you're not buying the converter board. You're really just buying, I mean, you're just getting the interfaces to meet up correctly. So I could say, that could be all a capital point of the display. It could. Yeah, it depends on the cost and the touch interface. ICs that just do that for you. At which point now we're talking about USB hub chip back on the board because we've got two physical devices. So, yeah, it's there's a lot of decisions we have to go through. Well, Michael, and I realize it's complicated, but that's why we make the big bucks. But is it is it possible that it would be smarter to continue along the path. We're currently going to reach completion with the existing hardware, recognizing it's a gazillion dollars too much, but that downstream, it could be completely redesigned to be half price. And get this out and working into several sets of users hands. Roll over being one, maybe even dev kit. Kickstarter people to with the belief that six months downstream, we will have an entirely new SGA one board that completely is different than what we've produced. Yet we have met some obligations in a reasonable amount of time before that because the other reason I ask is the best laid plan so we we know we think we know we're going to be able to decrease price by getting rid of this chip and getting rid of this chip and replacing the display and doing But those often don't work out as intended. And so there's delays, and rather than causing all the people that are relying on us or waiting on us to buy into those delays. Maybe we could give them something we have now as an interim solution knowing that in six months it's going to become. I hate the word deprecated. Absolutely right. I mean, what we're working on now is intended to be a dev kit. So we're relatively price insensitive. My hope is that we get them, you know, quickly turn this into a consumer ready device simply by you know, helping the quantities that would be that would be the ideal situation but you're correct. If we want to get the least risky path to getting developer units out there quickly, then yeah we should go with the known solution, even if it's a little bit more expensive. The next there though is, as you said, we're going to end up with two different hardware out there in the field that we're going to have to support the firmwares and that sort of thing. Not that big a deal because the differences are pretty many, but but there is a difference and, you know, that will be great practice for us for the hardware. But is that really the thing we want to take out at this stage. One might argue it's not much different than the fact that we have a mark one artifact that we still have to kind of support the benefit of that approach though, is that the dev kits get into people's hands outside of this group, and any kind of feedback regarding chamber issues driver issues, poor quality components could be surfaced before we actually do a power by. Yeah, that's a good point. I think my biggest would be something like the re speaker issue, whereas, you know, the design that is intended to be deprecated has a thing about it that just nags at us and takes a lot of our time that we keep can't get quite past kind of like the three speaker audio issue when we're we know that we're going to not be needing it long term anyway. Yeah. So I've been running the SJ 201 for several weeks now and I have not seen any show stockers, but that's anecdotal at best right. Okay, well, this is a great discussion. I. Yeah, I'll all noodle on this for a little bit and let's put something on the schedule for. Maybe just a little bit, maybe grab Kevin and have a discussion about this if you guys are available otherwise let's put something on my calendar for tomorrow. I'd like to hash this out quickly. I hate I hate doing this but it's you guys know me already. So what's the intention of the leads regarding directionality of any. As I mentioned, we might go with less than 12 leads. We currently have 12 leads configured in a circle where the prior re speaker codes would use the far field microphones to indicate where the input direction was coming from. And I'm wondering if that was our intended usage of these leads. So other than how having less leads would impact that much. We didn't revisit when the chip changed out from underneath it. So you're correct. The original intent was to use them as a directionality indicator. But when XMOS deprecated the chip that we were going to use and pointed us to this new chip. So we might use that that design aspect, you know, even though this new chip does not give us a directionality information. So that's kind of a holdover from that other design. So, you know, I think we it's tempting to say well I want to keep that feature because it's cool but like, what does it really do for us, you know, I think, you know, we might want to think about that. On a device that didn't have a screen that we use this board, you know, and that's essentially the same hardware except you literally just take the screen off. And then the the leads are your, your main interface options. So, you know, it could spin for loading change colors for, you know, different states, all kinds of different things like that. Don't need 12 necessarily do that. But that was also the other use case. Yeah, so that's something for you to think about in terms of the human interface factors, you know, what do we need? What are the requirements for those LEDs as an interface? Because, you know, we might be able to get the, we might be able to easily add for right. Right. But that doesn't give us a ring sort of architecture. Maybe it's a bar that goes back and forth. But yeah, something something to think about in terms of potential restriction. Right. Okay, well, yeah, thanks again for the discussion there. Some good things to think about. Just regarding any last minute meetings tomorrow, I'll be in and out. I have to, I'm waiting for packages here because I don't want them to float away if I'm not here. But I have to take my wife down to a dealer by the by the condo, drop her off, get the car worked on, drop her back at the condo, come back up here, and then four hours later go back. Please give me more than a five or 10 minute head up heads up regarding any last minute. Okay, we'll take care of that. Okay. Okay. Go team.