UI for WiFi Base Configuration Page is confusing and needs a redesign

[tonycanike]

Subject of the issue

The UI for the WiFi Base Configuration page is confusing and needs a little redesigning

Your workbench

Facet with v2.5-Sep 19 2022

Current State

There are multiple overlapping and intertwined conversation threads in various issues regarding inconsistent details of the UI and functionality of the WiFi Base Configuration page.

Aspects of the current UI are confusing.

1. I believe some of the ZED internal terminology was logically reused in the UI, which made sense in the early stages of this product. But as the product matures and improves in functionality, the ZED terminology becomes less useful.
2. Using "Fixed" to name one of the techniques to determine the fixed base coordinates is a misnomer from a user point of view. The ZED coordinates are fixed once RTCM transmission starts whether we're using the "fixed" or "survey-in" functionality. And the base is physically in a fixed location whether we're using the "fixed" or "survey-in" functionality. So the base is always fixed. There are different techniques to determine the fixed coordinates, but they all result in fixed coordinates.
3. There three different techniques to determine what fixed coordinates the fixed base will use. They are munged into two techniques. The three techniques are (a) Survey-In, (b) Use Current Coordinates, and (c) Enter Base Coordinates (current called "Fixed").
4. Combing the "Use Current Coordinates" technique within the "Enter Base Coordinates " (currently called "Fixed") technique is confusing. The "Use Current Coordinates" technique is more closely related, from the users perspective, to "Survey-in"; and it is very different from "Enter Base Coordinates"
5. Combining the "Use Current Coordinates" to the "Enter Base Coordinates" section resulted in confusion about adding or subtracting rod height and antenna offset to the HAE.
6. The Tool Tip about the rod height and antenna offset being subtracted is confusing (and incorrect?).
7. Placing the "Use Current Coordinates" button next to the coordinate entry fields confuses the functionality - because this button is so close to the entry fields, it would seem that it's the button to press after you typed in coordinates to the entry fields.

Proposed Behavior

Fully recognize the three distinct techniques to determine the fixed locations the ZED will used for the physically fixed base and build the UI accordingly.

(a) Enter Base Coordinates (currently called "Fixed")

(a1) Geodetic - There are 3 required and 2 optional fields. Prepopulate the 5 fields if there are values in the current profile.
User must enter 3: LLh. h is height above ellipsoid. (no geoid correction).
User optionally enters antenna height and antenna offset. Assume zero if no entry.

When the user is finished, save all five values in the current profile. Zero out the ECEF XYZ value in the current profile.

(a2) ECEF - there are three entry fields for XYZ that the user must enter. If the ECEF coordinates in the current profile are non-zero, prepopulate the entry fields with the profile values.

When the user is finished, save the XYZ values in the current profile. Zero out the five LLh/AH/AO values in the current profile.

(b) Use Current Coordinates. The current location fix is copied into the ZED and it begins transmitting RTCM without the survey-in process and delay. This is useful for folks who are used to turning GNSS receivers on, setting them up properly to get accurate locations, and giving them time to determine their location. Prominently displaying the LLh coordinates that will be (were?) sent to the ZED is useful for the user to write down or screen-shot for future use, say setting up the base the next day. Note if the ZED's LLh are determined from the NMEA,, it's important to remove the ZED's crude geoid correction so we are using HAE.

The only UI input in this section are an optional antenna height and antenna offset. They are assumed to be zero if the user does not enter non-zero values.

The LL coordinates sent to the ZED are stored in the current profile.
The HAE of the mark ( HAE of the APC - antenna height - antenna offset) is stored in the current profile.
The antenna height is stored in the current profile.
The antenna offset is stored in the current profile.

The current ECEF coordinates are stored in the current profile.

(c) Survey-In, in which the ZED is commanded to use its internal algorithm to wait for a fix (ha that word again) that meets certain parameters. This is a very useful mode for beginners that setup the base, turn is on, wait for it to transmit, and they go roving. This is a less useful mode for experienced users.

The only UI input for the user to change is the parameters that the ZED uses to determine when it's fix is good enough.

[amlago]

I do not see the problem of calling a fixed base a fixed base obtained by different procedures.
Simply in some cases the base has relative coordinates and in others absolute.
The technician should know the difference.
For my way of thinking and not complicate the use of the base mode, it is that I suggested what was proposed in #327.
In almost all professional controllers, the coordinates of the mark that correspond to the base point, whether relative or absolute, are saved and in another session they are used from a list of points.
In each session you enter cane height and it is ready.
I don't think it is necessary to make differences depending on where the fixed base coordinates are obtained from.
I would like you to give what was stated in #327 a chance.
Greetings to all

[tonycanike]

I updated the original issue to add point 7 regarding the "Use Current Coordinates" button being too close to the manual entry fields.

I do not see the problem of calling a fixed base a fixed base obtained by different procedures.

@amlago yes, we agree on that! I'm saying all of the procedures result in a fixed base, so calling one of the procedures fixed and the other procedures something different is confusing. All three procedures result in a base with fixed coordinates. It would be clearer to call them all fixed.

FIXED applies to all the procedures we have today:

• Fixed base via survey-in
• Fixed base via user entry (type in coordinates)
• Fixed base via use current coordinates

and, hopefully someday

• Fixed base via recalling coordinates from a file :)

I find the survey-in procedure the least useful.

• It wastes a lot of time, as I've already had the unit running. It's settled in, and already determined its location.
• It's much faster to "Use Current Coordinates", write them down, and have the base start transmitting RTCM to my rover.
• I can't look at the WiFI page and get the coordinates that resulted from the survey-in procedure. I want to write them down so I can reuse them (Maybe I'm missing something)

[gdt]

There's a separate point, related to the Surveyor / Data Collector interface, which is that there should perhaps be an API over the data stream (TCP or Bluetooth, whatever) for the DC to write base coordinates and change modes. But we're heading into not-well-charted territory and a lot of work, so I don't really mean to suggest going there now, but rather am just pointing out that this is probably how it should be in the glorious future, with a Free Software DC.

[amlago]

1. Regarding the definition of a fixed base, we agree.
   The procedures you describe are the normal ones and I would love to retrieve coordinates from a file.

2. To see the base coordinates, after survey in, one way, uncomfortable but that worked for me, is the following.
   In one of the versions 2.5 or 2.4 I managed to issue rtcm corrections, connected to my wifi network and at the same time I connected with SWmaps via bluetooth on another cell phone and I saw the coordinates of the base station.
   I found that the rtcm corrections were issued slower, but it worked.
   This way of working would allow you to see the base coordinates in Swmaps while rtcm corrections are output.

3. In my case, the coordinates of the fixed base, I see them and they are recorded in my professional data collector, from another brand of equipment.
   In any case, I would like not to depend on that data, but would like it to be stored in Facet itself.

It's good to come up with meeting ideas, to obtain a more functional and mature product.

Cheers

[tonycanike]

There's a separate point, related to the Surveyor / Data Collector interface, which is that there should perhaps be an API over the data stream (TCP or Bluetooth, whatever) for the DC to write base coordinates and change modes.

@gdt , very true.

Perhaps the initial API can simply be F9P commands and messages. That is, a future Free/Open Source DC software could transmit F9P commands and read the F9P responses. While perhaps not the ultimate in glorious potential futures, it would save a lot of work designing the API. Ideally there'd be an open source API that doesn't significantly change with different hardware.

I say this because my $$ SurvPC-based data collector does support the F9P and I have had some success in getting SurvPC to set the base coordinates of my Facet, at least on my kitchen table. When the Facet is transmitting RTCM, the serial menu displays the coordinates I sent to the Facet/F9P via SurvPC, so it might be working. Fortunately the RTK Firmware passes the F9P commands and messages in and out via Bluetooth (Thank you @nseidle !)

Unfortunately, where I live is heavily wooded and I haven't had a chance to get out and test this with my rover yet. I hope to do so next week.

[tonycanike]

2. after survey in, one way, uncomfortable but that worked for me,

@amlago thank you! I've used SWMaps too, Agreed, it's not convenient.

[amlago]

@gdt
I would love an app where you can interact with the Facet without touching the power button, rather than turning it on. I understand the idea that you propose with a free and general software. It would be fantastic.
With a dedicated app the other professional equipment I own works, but of course its value is $$$$$$$.
I believe that Emlid has a dedicated app to manage their teams.

For now I would settle for the Facet to be able to save some base coordinates and be able to retrieve them in a simple way.
I think that the path of generating a file or list of base points in txt or csv as @tonycanike said is where we should go, if we continue with this simple interface.

[nseidle]

@gdt - WRT API, I agree and it's not too hard to implement but needs to be in its own issue.

@tonycanike - I'll stew on this for the next minor firmware version. We need to get v2.5 out.

[nseidle]

Work in progress:

This change mostly terrifies me because lay users will select 'Use current coordinates' and then go outside and, holding a unit in their hands, will turn unit on. That unit will power on, get a lock within seconds and begin base mode before the user gets the unit fully set on a tripod (or other). The base and resulting RTCM will be very inaccurate. Do you agree? Do we really want this change?

I would like to briefly discuss your following point:

I find the survey-in procedure the least useful. It wastes a lot of time, as I've already had the unit running. It's settled in, and already determined its location.

It is not clear what u-blox is doing during the 'survey-in' method. For instance, I have confirmed with u-blox that when a 'survey-in' is initiated the module's Dynamic Model is changed from X to 'Stationary' behind the scenes. There may be many other settings the u-blox designers are altering to minimize the aggregate error. Or they might just take 60 fixes, add them together and divide by 60. My point is we don't know so I want to argue that the 'Survey-In' method is better than the 'Use current coordinates'. However, I'm learning to listen to the user (you are all using these devices in the field every day) and try to get you what you need; not what I think you need.

[tonycanike]

I would like to briefly discuss your following point:

I find the survey-in procedure the least useful. It wastes a lot of time, as I've already had the unit running. It's settled in, and already determined its location.

I will admit I might be missing something. But here is something I've experienced a few times that makes me question the utility of survey-in mode.

1. I setup my tripod for the base, put my Facet that's going to be the base on the tripod, and turn it on. The Facet happened to be in Rover mode based on its last use. I get out my notebook and tape measure, measure the height, and spend a few minutes making notes.
2. While all that happens, the Facet in Rover mode acquired 25+ satellites, and is displaying a sdev of 0.5 or so. That's great!
3. I don't have an exact location of my base, I am going to log raw, OPUS or PPP later, and adjust all my rover coordinates in the office. Or I am going to use my rover for survey tasks (and there are many!) that don't required absolute accuracy, but only high relative precision.
4. I go into WiFi config mode to set the logging. (This means I couldn't start survey-in when I was making my notes in step 1.)
5. I use the button to switch to base mode. It starts survey-in. Now I need to wait for it to get a fix again, and then a minute for it to survey-in. The accuracy displayed during the process is far worse than I just had moments ago. Like 2m or something. And they don't seem to get better. I guess I could change the timing on the survey-in process but what about that nice fix I had 5 minutes ago?
6. It appears to me that I get to stand around and wait when the Facet just had a perfectly good set of coordinates for the day's task. And now it has worse accuracy. What am I missing here?

[tonycanike]

I guess what I'm forgetting is the device needs to be rebooted to start base mode. There's no "switch to base using current coordinates" button.

And I've wondered if the two accuracies (the one displayed during roving, and one displayed during survey-in) are different measures. Like I'm comparing apples and oranges.

[gdt]

@tonycanike I don't understand the fine points of the displayed accuracies (but I'm pretty sure they aren't documented clearly enough). I also have never had a reason to believe that survey-in gets coordinates at the 10 cm level or better. So I more or less agree that either you are going to postprocess (OPUS/NRCAN as you say) the base and adjust, or you are just going to have 0.5m to even 1m of fuzz. Given that, I'm not sure there's real value in survey-in.

I suspect a "store current position as base and reboot" is easy and useful. however that's sort of reimplementing survey-in differently -- which is not to argue against it.

I have been using MassDOTs network, so there is no base calibration issue (or rather, they are logging raw constantly and doing the equivalent of OPUS so the calibration is already done), so this is mostly of academic interest.