While we wait for the next build to deploy,
App v 3.18.2
FW 3.12.0
If these were touched in 3.13, they can probably be ignored. Otherwise they’ll probably still be present.
Smartview audio is often around an hour behind reality. The M1 is working, but all I’m hearing is wind and birds and chainsaws. Not the core, not the blades. The guys with the chainsaws went home a long time ago but that’s what’s being streamed. Fully quitting and re-running the app has no effect.
When configuring an area for the M1, there is an option to mow the perimeter first, or mow the NGZ edges first.
If you select NGZ first, the plan will mow the inner area as usual. Upon completion, it’ll traverse to the start of the perimeter lap. Once there, it’ll head off to mow the NGZ edges. Once all NGZs are processed, it’ll return to that start of the perimeter, and execute the perimeter laps.
It probably shouldn’t make a 3 mile trek to the perimeter-start if it’s then going to trek 2 miles back to some NGZs, and then return to that perimeter-start.
Hi there, thanks for taking the time to share such detailed feedback—it’s really helpful.
For the Smart Vision audio delay you mentioned, this does sound like something that requires further investigation from our team. We’ll take a closer look into it.
As for the mowing logic when selecting NGZ-first, we understand your concern—the current pathing can indeed be optimized. There’s definitely room for improvement here, and I’ll make sure your feedback is passed along to the team for consideration.
It’s a heisenbug, lol.
Started today’s job, tuned in with SmartV after a few minutes, and the audio was from when the core was still docked. Checked in again 20 minutes later, and the audio was current.
Who knows, lol.
If I were to make this happen on purpose, I’d wrap the audio in a TCP tunnel and put the core at a location where it suffers packet loss. Then I’d make sure my TCP stack enforces the sequence number in those packets, instead of ignoring gaps and discarding those received out of sequence. Each lost packet would push back the audio by whatever the TCP timeout is. Ten second timeout? 50 lost packets would be 500 seconds, as a pretend example. Resetting the TCP connection, meanwhile, would effectively catch it back up.
I doubt that’s what is happening, but that’s how it seems to behave.
I think @Steve theory makes sense. I was having communication issues with the app at the time. Possibly related to a HaLow signal issue at that time. Just strange that whatever is streaming it would cache it for so long. Seems like some timeouts need to be added or tweaked.
I’m getting the audio bug too. Up until yesterday it had been working just fine, then yesterday afternoon the audio was like 20-40 minutes behind the video. Then last night and today it’s basically little chirps about 1-3 times a second. Almost like someone is jogging with a CD player and it’s skipping.
I can now confirm (for my situation) that the bug goes away when SW and FW match.
I have 2 mowers that were both doing it and one has now updated the FW and all seems to work with that one while the unit on the old FW is still at the rave!
So I just got the firmware update this morning on my rover and the audio issue appears to be resolved. I’ve only tried connecting the audio once so far but when I did now the audio was perfectly in sync with the video. I’ll try to do it again when the rover finishes charging and is back out on a work plan.
