As our Reach units run with Wifi disconnected (i.e. in hotspot mode with no client), their only way to the Internet is via the usb1 interface
As this interface is never used as a default route (we’d love it to do so!), DNS lookups with the internal hardcoded servers do not work (as all are outside the hardcoded 192.168.2.0/24 network).
Consequently, NTP lookups (hardcoded with domain names) also do not work and are not accessible.
Is there a way to configure a custom NTP server just using its IP address (ideally, a DNS server, too)?
Or would it at least be possible to add a fallback NTP server (and fallback DNS server) to something in the 192.168.2.0/24 network? Even a hardcoded address would do, it would be sufficient to set up a device with this static IP on the other end of the USB cable, which is no problem for us.
That’s the thing - I don’t (always). We mount the units on robots which can freely roam between indoor and outdoor. They usually start indoor. We’d like to get a fix ASAP when they get outdoor. Having correct time would help it I guess.
Reach syncs the time once it receives the acceptable level of GNSS signal or connects to the internet. So when your robot with a receiver moves outside, it goes through the time sync.
Our reach never connects to the Internet in a way that would allow the the default NTP servers to work (because Emlid refuses to also route internet via the USB connection). That’s why we need custom NTP server (with an IP address in the usb0 device network, so that it gets routed through the USB cable).
Pardon me? One extra item to the list of the several preconfigured NTP servers in /etc/ntp.conf? Why should that be hard?
Why is Emlid doing everything in a way that the modules cannot be reliably used on mobile robots? Why is the USB interface treated as inferior to the Wifi, when it actually offers much higher reliability?
There is approx 4 simple settings that I’d set had I access to the root account, and that would help a ton! But I don’t have root and Emlid refuses even these simplest changes to the firmware. We’re ordering Septentrio in the meantime, and if Emlid doesn’t show more helpful, the M+ modules will go into trash…
Several factors affect the time required to obtain a fixed solution. The main one is the number of visible satellites. Even if the receiver passes through the time sync over the internet, it still needs to detect the satellites to calculate the solution. Once the receiver is outside in appropriate conditions, it goes through the time sync and detects the satellites which helps it to obtain FIX.
We don’t have open root access because it’s going to be extremely hard to identify what went wrong in case important settings were affected. If we add new functionality from our side, we need to weigh the pros and cons, understand how it can affect other users, and thoroughly test it. So, it’s a complex process.
Reach can stream its position via a Serial connection, which is sufficient for most applications with drones and robots. Wi-Fi connection, for the most part, is used for accessing the device’s settings and data downloading.
The problem is that the time reported by the receiver before time sync is nonsense, as the unit does not carry a battery-backed RTC clock. So any diagnostics (like CPU temperature) we get from the unit before it gets a fix carries wrong time and that’s also a problem. We access the unit either via API or SSH to collect the diagnostics. We need to be able to “force” the robot’s local time to the unit right after startup. The robot runs a local NTP server that can be used for this. But the firmware restrictions in M+ do not allow us to do it.
I agree.
And that’s the problem. You want to have RTK → you want to have Internet → you need to get it over Wifi (not good!) or do a harakiri over the wire to point the unit to a relay NTRIP server on the robot (Add default route to the usb1 device, too). Things could be so simple had there been the other default route and a customizable DNS server…
