Its my understanding that the RTK data generated at the roof-mounted datacenter first gets uploaded to the yarbo cloud ntrip service. After that, it bounces back down to the DC and then over the HALO link to the rover. This happens even if wifi and cellular are disabled on the rover.
Feature request:
Can the NTRIP/RTK data be sent DIRECTLY from the DC to the Rover
This could be set up to only directly send if cellular and wifi are disabled, no chance of backhaul changes.
For those that DO keep cellular turned on, Perhaps data mirror the RTK data to the cloud service so if its needed/halo cuts out, the rover can pull from the cloud service then. (Or only mirror once halo signal gets below x threshold)
Some reasons:
Proxying the data to the cloud services makes sense for seamless handoff if the rover moves to cellular from Halo. Some of us don’t need that. This is just wasted bandwidth
Some folks are heavily bandwidth constrained (Rural, Geostationary satellite internet)
Reduces the yarbo fleet reliance on a real-time service that can’t afford much downtime. Right now, if the NTRIP services are offline, which they have been in the last couple weeks, there is no workaround for users to work remotely.
Because of ^ reasons, reduced infrastructure costs for Yarbo, the company.
Self-reliance/Self-hosted. I realize Yarbo is very connected. But a big part of the reason for buying the yarbo for some of us is to bring things ‘in-house’ instead of hiring out a lawncare service. Being so at-mercy for a cloud service goes against that
You can have WiFi and Cell off in the rover and pull the Ethernet connection from the Data Center (leaving the PoE injector for power only), and the system will still work. It’s a way to test for a dodgy network, suggested to me by Co-founder Ken – didn’t know it’d work without Internet. I guess everything for daily tasks is stored locally and locally done over HaLow.
Interesting! So I’m not home at the moment but the rover is running a mission that I can see over CCTV. I blocked all network traffic from the yarbo devices on the network to the internet and it looks like the rover came to a stop within about 50ft. BUT! It did start back up and now its continuing. All data in the app is stale (expected).
Ahh, sneeky sneeky, cellular is on somehow. So RTK is Status:4 and DC is Connection:3 . Super interesting because cellular is definitely disabled in the mobile app and it now says its used 84mb of data.
Alrighty, maybe something is sneaking through the mac-based firewall. Disabling the network port and leaving POE up. Rover paused… and now its continuing on again. App shows 4G connection. I confess, I’m stumped. If cellular really is disabled, I’m not quite sure how its getting the traffic out.
I turned the port back on, removed the firewall rules and the icon changed from 4G back to the 3 concentric arcs (Halo).
Well that was an interesting experiment. So maybe we can’t actually turn off cellular? Thats wild. It looks like it successfully failed over to public NTRIP via cellular (ignoring the fact that its disabled) and didn’t even need(??) the RTK data from the local DC..? Less the rover was being fed from the DC via Halo directly and using cellular just as telemetry backhaul for the app updates..?
I’m not sure. @Yarbo can you comment on whats going on? How am I getting status reports from the yarbo when the DC is unplugged/powered down, wifi is off and cellular is off
No firewall, No ports down: Connection: 2 “NTRIP”
Disabling the switch port puts the yarbo into Connection: 3 “Local Halow”
Firewall rule blocking the DC puts the yarbo into Connection: 3 “Local Halow”
Powering the DC Down: Status: 2Halow Connection: False - Yarbo pauses, waiting for gps signal to recover
Powering DC back up, ports still off: Status: 4Connection - Yarbo recovers
The switch from NTRIP to Local HaLow takes about 60 seconds. It’s odd that cellular isn’t truly disabled because it does show a different status in the diagnostics when it’s disabled vs not.
Yeah. The status page showed cellular is offline as did the settings page. But somehow was still getting info from the rover when the DC was powered down. Maybe I’m just missing something obvious