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.

[nseidle]

During normal operation, the Horizontal Positional Accuracy is displayed in meters seen below:

I'm with @gdt, I don't completely believe the HPA claims, but I suspect is close to reality.

During Survey-In, the 3D Mean Standard Deviation is displayed below:

This value is queried directly from the ZED module. It's a very different number from HPA. It's displayed because a Survey-In will run until both the min time (60s default) and the std deviation is below the max threshold (5 meters is default) so I found the mean more important to know during Survey-In than HPA.

Additionally, the Survey-In will not start until HPA is below 1 meter. This is extra code that we've added. I found that when a unit first powers on, if a Survey-In is immediately initiated the mean gets 'poisoned', effectively, as the initial fixes are quite bad. Allowing the unit a few tens of seconds to settle below an HPA of 1 meter leads to much lower reported deviations during survey in. Whether or not this 'settle' time leads to a more accurate Survey-In is unknown.

But I worry this is all an aside: Survey-In is what it is, good, bad, or indifferent. I return to my question/concern of adding a 'use current coordinates' box:

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?

[tonycanike]

Thanks @nseidle , that helps clarify some things for me. Though my answer to your question is going to veer some from this "redesign the UI to make it less confusing" and go into other issues. I apologize.

I don't believe I was the person who requested the "Pasted Current Coordinates" feature, but I did incorporate that request into my writeup above because it was being implemented. And now that I've used it, I understand the concept and find it useful to me. I can setup my tripod, power up the facet as a rover, let it settle in, WiFi configure, config my logging, set base->fixed->geodetic, past current LLh, add to CSV, set initial state to base, start new log file, save config, exit&reboot. Boom, it's go time! tho it's a lot of steps. And I get to write down in my paper notes (oh phone screen-shot) and in the CSV the assumed base coordinates without having to fire up SWMaps and getting the base coordinates from the NMEA stream over bluetooth.

Your concern about the lay user and the mis-use case you described is very valid. But don't we already have the same problem whenever someone enters fixed base coordinates? Once coordinates are entered for a fixed base, don't they automatically get reused after each power-on until the unit is configured otherwise? If someone knows how to fire up the WiFi or serial menu to set fixed based coordinates, then they better know what they are doing and how to undo it.

Now that I've figured out the power of the "Paste Current LLh" and the "Add" to CSV buttons, the survey-in process doesn't bother me so much anymore.

LONG DIGRESSION ON CONFIGURING AND REBOOTING

Let me ask a question - is the fact that the unit reboots every time a configuration is changed a limiting factor here? It seems to me that setting the base coordinates should be a dynamic activity that sets the ZED base coordinates without saving the coordinates someplace where they will automatically be reused at power on. If you power on in base mode and don't set the base coordinates, it should survey-in...oh unless you're setting up a CORS-type permanently fixed base.

This gets to my point about the UI needing some more thought. Setting the base coordinates for one day's survey session is a different use case from setting and fixing the base coordinates for a permanently-fixed CORS-type base. The UI treats them as the same use case.

If you set the coordinates for today's survey (the current power-on), perhaps the coordinates shouldn't survive a reboot. I believe it's very possible to set the ZED base coordinates without rebooting. (I think SurvPC will set the Facet base coordinates without rebooting when I use SurvPC's F9P driver.)

Maybe this is going too deep here? Folks can get their jobs done without reworking everything. And if we have immediate action buttons vs. buttons that only take effect after a reboot, it might get more confusing.

more digression

Some of my thinking about changing the configuration without rebooting is my concern about the corrupted data files. I've not had much luck getting clean log files. And I've not had much luck getting OPUS solutions, which are the gold standard in the US. I see a lot of errors in the beginning of the log files. Because of this I speculate that I want to let the unit get settled in, surveyed-in, running smoothly, configure the base, configure the logging, etc.,.....and then start a new clean log file without rebooting.

Hand-editing RINEX files to remove the first 10-15 minutes of data is getting tedious. Though I just watched a webinar from the NGS and they suggested doing exactly that! Having poor data in the log files from a just-powered-on GNSS receivers (name brand $$$$ survey-grade units) sometimes causes problems for OPUS.

[nseidle]

Hi Tony - This is an old issue that has morphed and pieces of it have been fixed (please tell me you're getting clean logs now!). Can we close this out with an eye on the future. I'm all for UI changes, I just don't know how to move forward on this issue as it stands.

[tonycanike]

I'm ok with closing it.

[tonycanike]

I believe the conversation between @amlago (Angel) and myself in #417 provides ideas for smaller changes to the UI that will make it very workable and usable.

In that conversation I wrote some ideas for a bigger reworking of the UI. I'm copying the ideas here solely for future reference. At this point I believe we can leave this issue (#330) closed and focus on other work,

Can the UI elements be reordered so the are presented top-to-bottom in the order the user needs to manipulate them? Not sure this is easy.

i. User enters antenna height (do this first because the user just measured it and the number is floating around in their head, about to be forgotten.) ii. User enters phase center offset (prefilled if Facet or Facet-L) iii. User chooses source of coordinates (CSV file, ZED, manual entry) iv. UI adjusts automagically!! The calculate radio buttons appropriately selected but can be changed. User can enter LLh if manually entering. User can select CSV file row if loading from file. v. User hits the "Load and Calculate" button. Data is loaded from selected source and calculations performed. vi. User reviews displayed results. LL and the h's top-to-bottom to intuitively match real-world order: HAE APC, phase center offset, antenna height, HAE Mark.) vii. If necessary, user adjusts their entries and uses the "Load and Calculate" button again. viii. There's a "save to file" button the user can use if they are satisfied. ix. User saves settings and exits, RTK device restarts.

# # #