why doesn’t it drop like this. I pulled the battery and it came back for a while and it is off again. Pulled the battery like before but isn’t coming back.
You do not have connection with the data center. Another issue is that your SIM is not on. I don’t see the Halow status.
Is the data center green? Is it connected to the internet? Try a disconnect and reconnect of the data center if is already green. When did you activate it? (I don’t see the firmware version but is the data center currently updating?)
There are a lot of “not connected” things on the few I can see. But I don’t think this time GPS is the problem.
Definitely an issue with the data center connection. Is your HaLow status true or false? Pull power to the data center and the battery cable on the rover for 5 mins. Power up the DC and then the rover. If it disconnects again, I’d open a ticket.
You can try the solution suggested by our community member to see if it helps. If the issue still persists, we recommend submitting a support ticket with a detailed description of the problem, along with the steps you’ve already taken. This will help our support team better understand your situation and assist you more efficiently. We truly appreciate your patience and understanding!
Rebooting the data center fixed it.
Thanks.
Is there a way to send a command to reboot the datacenter or do you have to unplug it? It would be helpful to send a reboot command like you can with the rover. I couldn’t find any place to do it though.
Unfortunately it is not supported. Not sure if they can add that either. But, you can get a smart switch and use that to bounce the POE injector. I do recommend a few mins pause between off and on. It lets the capacitors fully drain.
I just bounce the port on my POE switch.
I used to work for a hardware vendor doing engineering support for communications equipment and there was an expectation of reliability.
For a problem to be fixed the worst thing you can do is power cycle the equipment… That does not fix the actual problem it just makes the condition that brought it there go away for now. It will return…
(I am just going to blame microsoft here but there maybe another company that is the root cause for everyone thinking this)
Rebooting/Powercycling does not resolve any issue.. it just makes it go away for now if it isn’t addressed it will return…
From an engineering standpoint if you are going to fix the underlying issue rebooting/powercycling almost always makes it impossible to troubleshoot and inspect the state that caused the error/condition.
Its fine to do once in a blue moon but if its happening often enough that you have automated a process to power cycle it.. That is a problem that needs to be resolved. Cheap power supply that isn’t handling transients or sags or a condition that causes a crash of the software.. All of those get hidden and never resolved because of powercycleing/rebooting.
Rebooting/powercycling is ok if its uncommon just to get things working but if your putting in an automated method to make it happen there is a underlying issue that needs to be addressed.
Don’t disagree but it often does solve memory leaks and other conditions that can occur. I rarely, if ever have to power cycle my data centers. I don’t have to power cycle my rovers either but I often do after a firmware update. And fully agree power cycling wipes the condition and hampers supports ability to troubleshoot it. If it is repeatable and a known issue then why not. If it’s a one off, also why not. Most people just want to get it back up and running quickly. As a tester, I will leave it in a bad state so support can troubleshoot it but I also always run it with logging record enabled which also helps them capture even those one off events.
Have you experience Yarbo turning off the Record Issue? I feel like that gets turned off without me doing that.
It will after 24 hours I think and it definitely will if you reboot. Support may toggle it off to if you tell them you have one and it’s left on. Leaving it on after you reproduce the issue is counterproductive because the file size gets rather large for copying off the rover. Best to turn it on and off when reproducing the issue and you are done doing so.
It does not solve a memory leak.. only frees up memory … the memory leak will persist because that is a coding problem that isn’t resolved.
I can see not leaving it on for something that can be reproduced. Turn it on, reproduce the issue, turn it off.
It’s difficult to predict when something like “work area suspended” is going to happen. So leaving it on is the only viable way of catching it. Unless I’m missing something.
You are not missing something. But turn it off when the plan completes.
Yes, that’s what I meant. Clear the immediate issue. Definitely doesn’t solve that issue long term.
That sounds like someone didn’t turn it off after the plan completed and didn’t like the outcome.
When you’ve had your issue records overwritten or so large they ask you to connect to WiFi, you tend to get a little more cautious with it. You definitely don’t want to have support trying to download it for days. Just slows down the analysis.
#BlameMicrosoft_But_It_Works