Timesync issue. General testing

I usually boot reach unit up first (and connect phone to reach hotspot) and then assign/select and connect to wifi from reachs own wifi menu, i find this much easier.

thanks @TB_RTK. doable for sure. if you have time sync since that check appears to be a blocking process as far as i can tell. also trying to minimize what users need to do in the field. our reach units get integrated into portable wifi AP’s and robots so trying hard to make it all as easy as possible. we can work around all this. just trying to avoid work arounds as they can cause unhappy customers. as it stands (unless i am crazy, and that is always in play) we will have to tell our customers that they can only connect to the units when outdoors. most do not allow internet on the robot network for security reasons and/or could be in an area with no/little coverage (come visit me in the midwest to really check your cell providers coverage) so they have to have a good enough view to pull sat time.

here’s a question for you since i do not get to see these things much once deployed: how do you pull logs indoors? say you go out and do a survey or run a UAS mission and then come indoors. can you still connect with your phone?

I am not sure what this time sync issue is about.
Done some testing in the field with just a plain hotspot router with no internet access. (wrt54g) and never run into time sync problem.
I pull the log either straight away connecting to reach hotspot in the field or at home when i boot up reach again and it is connecting to my local wifi.And yes, with my phone usually.
How do you provoke time sync issue?
I also run dd-wrt firmware on all my wifi gear

In the field you will have sat time. Does your local wifi have internet?

To induce time sync failure you remove internet and clear enough sat view.

I am in an old pole barn with steel siding so even a good antenna has a hard time getting time sync. This could also be true of say an emergency response or operations trailer with metal sides/roof.

Like I said, it could just be me and I have found an edge case. Just trying to figure that out.

Ok,i ll give it a try later and see if i get the same result.

@TB_RTK thanks for splitting to new topic. Here is what would help out to test:

  1. Setup Reach with latest Beta using preferred method
  2. Turn off AP Reach was connected to
  3. Remove or block any antenna
  4. Boot Reach and try to connect to Reach hotspot

Does it work?

Made 2 attempts and no problem occured. Here is what i did

1.Boot wifi router with no internet connection
2.Boot reach and it connects to wifi
3.Turning of wifi and putting a silver bowl over reach to block signal. Though reach still gets about 10snr on 2-3 satellites
4.Reboot reach
5.Reach hotspot shows up and i can connect to it.

Did i do this right?

Can you go to port 5000 and see if time sync passes?

Please tell me how, havent done that before :flushed:

reach.local:5000 or

IP address with port … xxx.xxx.xxx:5000

thanks!

Ah, that port.
This is what i get

Sorry for asking,i think my brain is not working properly. Had to reread the issue and i still dont get the time sync issue. Could you please lay it out for those like me

Has this something to do with use of reach or the update part?

OK. I am gong to try again today with a different machine. I can’t even get to that screen since I can not connect to Reach AP. I can see it come up but it acts like Reach does not want to give out IP addresses when it is broadcasting it’s AP indoors with no GNSS antenna. It’s a Windows 10 machine that has been hooked up to way too many ad hoc networks so might be a problem there.

Hmm strange. 192.168.42.1 (and not :5000) is usually the adresse that works. You might also try with the antenna on, its just something an old man on youtube said once that makes me never use this kind of device with the antenna off.
Also try your smart phone. Good luck

I am just making sure that when these go out in the field we do not cause issues under a rather normal use case. For instance, our systems have their own portable WiFi network; all Reach units, Navio’s, robots etc connect to this network. Assume it does not have internet and it is the only network available. Not hard to do for field ops and research. If I come indoors to post flight, pull logs, perform maintenance, or any other reasonable action item, I would expect WiFi comms to work like they did outdoors. After all, it’s just a portable WiFi network. The only thing that has changed is I am now indoors without clear sky view. I want to make sure our customers can still get the job done without jumping through hoops. Asking them to log into each Reach unit (they may have two or several) to switch them to a network with internet so it can finish booting indoors is sub-optimal and may not even be an option. Next option is to take everything outdoors again so we get sat time. Perhaps, doable, but I can already hear my customers who work from mobile platforms and/or live/work in crap weather grumbling (to put it politely). Bottom-line: Time sync is now a requirement to finish loading ReachView that is not always easy to meet during normal use. That is going to be a problem since, as explained above, there are many valid reasons to want to get into ReachView without needing time sync.

Here’s a specific example to tell a story:

We just had a bunch of tornadoes in Illinois. Imagine responding to that event with say four drones. Each drone has a Reach Rover and a Navio2 and you have two WiFi base stations, which each have a Reach Base. Weather sucks. Cell comms are down. No internet. You fly when you can between storm cells. You are working from a trailer and/or inside a building. How many hoops do you want to jump through to get access to ReachView? Would you like to stand around outside with a bunch of expensive gear to get good sky view so you can finish booting into ReachView and pull logs? I would not.

Extreme edge case? Probably. I just hate to see a decision in software, that should be avoidable, drive operations to such an extent. It’s one of my peeves after many years of trying to make tech work in the field. Just an old guy trying to help out young Team Emlid.

I have a confession to make… I used Reach RS, but it has a internal battery so no problem there.
Tried the other Reach unit, and i could reproduce your time sync issue. No luck connecting it via wifi.
Not with Reach own hotspot either. But with browser in incongnito mode it would connect to Reach hotspot.
Hope that gives you a workaround

Thanks. Interesting that incognito worked. I was not able to even get an IP assignment. Thanks for checking!

I am really hoping we are not too tightly coupled to the RS code base if it is forcing this time sync issue. After having one customer test a Copter with Reach for a few weeks, and dealing with the support issues caused by the time sync requirement, I am at a point where we will need to think twice about integrating Reach into more projects. So here to make my case before stable is released.

I also think clearing cashe does the same trick, might test that as well.

@coby

The decision to force time sync comes from RTKLIB, which unfortunately does not function properly unless a good time is available. In order to ensure stability of the system we made the decision to enforce time synchronization. We do understand that it could cause inconvenience in certain rare scenarios and eventually we will get rid of it. There is no quick fix for it unfortunately. Time sync can come from Wi-FI or GPS, which means that the issue can be experienced only if you are using Reach in hotspot mode inside a building. Reach RS is not affected as it maintains clock from the battery.

@igor.vereninov Thanks for the info. Just knowing more details and rough timeline gives me the info to start making better decisions about integration. I will look at 3G/4G integration into our WiFi which should help for most use cases.