New WiFi AP Config page

[nseidle]

Ok, v15RC now has the WiFi AP config page working. To access it:

• Load latest v15RC firmware
• Put RTK Express into 'Config' mode by pressing the Setup button until 'Config' is highlighted
• Use a computer or phone to connect to WiFi SSID 'RTK Config'
• Type IP address 192.168.1.1 into a browser
• Press buttons, see magic

I have a handful of cosmetic details to work out but the bones are working. Please let me know feedback.

[Eric-FR]

Very nice feature. No more need for a computer to configure.

[nseidle]

Thanks!

No more need for a computer to configure.

That is the hope. There are a few things to consider:

• More advanced settings a.k.a. the Debug Menu (SPI freq, I2C debug, heap reporting, task highwater reporting, SPP settings) is not exposed on the Web Config because most of those need Serial output to be of any value.
• Log file downloading over WiFi is possible but probably not going to be a feasible. My last benchmarking showed 250kB per second download speeds so a 100MB file would take >6 minutes. I think it's still easier to pull out the SD card than wait.
• Firmware file selection and loading from SD card is supported.
• Add a firmware file to the SD card via WiFi uploading is not supported but is possible. I figured that people will be inserting/pulling the SD card enough that WiFi uploading is not really beneficial. Firmware files can now be uploaded via GUI.
• SD file deletion might be possible
• SD formatting might be possible but unlikely

[Eric-FR]

I can connect with my smartphone (Samsung J7@2016 with Android 8.1.0) but I can't modify parameters. When Save Config, I get an error message on the right Error: Please clear 1 error (both with Chrome and Opera).

Maybe it is better that I open a new issue.

Side question : how do we go out of the configuration mode?

[nseidle]

If it's not too much trouble, please post a screenshot of what you see on your phone. It's odd that the parameters can't be modified.

The error is probably because your ECEFZ (under Base Config) is set to 0.000 (default) which is out of bounds (must be 3,000,000 to 5,000,000). I'll make that failure go away.

Exit config mode: You press the setup button on the unit to change to Rover or Base mode. I'll add a 'Exit to Rover Mode' button on the HTML page.

Good feedback. I've been staring at the config page for so long I don't see these small annoyances. Please keep the feedback coming.

[nseidle]

RCAug9: An 'Exit to Rover Mode' button was added. The area with error is auto-expanded. ECEFZ error is fixed. Firmware versions are now shown.

[Eric-FR]

[nseidle]

Nice. Looks like the fields are editable? Expand The Base Config section, fill in the ECEFZ field, and you should be good (Also, this has been fixed in today's RC).

[Eric-FR]

I added coordinates of a real point in ECEF fields and I get ride of the error. Will check the new RC.

[Eric-FR]

I tried to give coordinates of a point in La Réunion island (South hemisphere) (http://rgp.ign.fr/STATIONS/#PIER): X = 3373248.245 m, Y = 4894475.014 m, Z = -2304445.534 But I can only give positive values.

Even more, if my understanding is right, X²+Y²+Z²~R². R ~6,370,000 m. So X, Y and Z should be between -6,370,000 and +6,370,000. Not between 3,000,000 and 5,000,000.

[nseidle]

Good catch! Ugh, sorry my brain was still trying to think in geodetic coordinates. Increasing to 6.4M meters to facilitate 6378100.0 for north pole. RC-Aug9-2 will be on release page.

[Eric-FR]

Still, how can I set a negative number? There is no minus key available.

[Eric-FR]

Same problem apply to latitude/longitude/altitude that could be negative.

For sake of clarity, it would be better to indicate in which direction longitudes are positive. Something like : (positive to East).

Altitude? Do you really mean altitude? Or height above ellipsoid?

[gdt]

As I often rant elsewhere, altitude is a confusing word. I suggest to stick to one of "HAE" or "WGS84 Orthometric Height" (if that's what is really meant. I know there is often a concern that normals do not know what HAE means, but in the RTK surveying context I would just use it and perhaps say something i docs.

[Eric-FR]

For sure, users setting a RTK base must know the difference between altitude and height above ellipsoid. Something like "WGS84 Orthometric Height" should be a good warning that there is some tricky things underlying.

[nseidle]

@Eric-FR - WRT to negative inputs, it seems you have a keypad/keyboard issue.

Hi gdt - As this is a number passed into the ZED-F9P directly I'm digging through their docs to see if there's better definition from u-blox. Is 'Geodetic' a better definition for the block of 'Lat/Long/Altitude'? This would fit with a few references I'm seeing through 'normals' eyes. Altitude is far more comprehensible than "WGS84 Orthometric Height", but I'll leave it up to you, the professionals.

[gdt]

I have read extensively and have not encountered "geodetic height". So I would expect that to lead to confusion. Altitude is not in my view comprehensible; it merely seems to be comprehensible, which I think is worse. I've read hundreds of pages of NGS docs and several geodesy textbooks, and when someone says "altitude" to me I usually am not sure what they mean precisely. In all seriousness, height is a very difficult subject that not very many people understand. HAE relative to a particular datum is a relatively clear concept. Once you depart from that, there are orthometric heights (along the normal to gravity to some reference surface) defined by various geoid models relative to various datums, and orthometric heights (such as NAVD88 in the US) defined by published coordinates on passive marks.

It seems overwhelmingly likely that one is supposed to input coordinates for the user's datum of choice, with the caveat that is must be close to WGS84. That can be in XYZ or equivalently (coordinate transform, not datum transform) in lat lon HAE. If that's what it is from the specs (good to read them!) I think it's best to label them that way. People who understand will understand and people who don't will ask what HAE means, which is a good outcome. From a US-centric viewpoint, I would expect some people to set base coordinates in WGS84(G1762), and some to set them in NAD83(2011). (My state government (MA) has an RTK data network that operates in NAD83(2011).)

(BTW, I don't have one of the devices yet but am eyeing it and have been using an ardusimple board. I am impressed with the software improvements.)

[nseidle]

Here's UBX-CFG-TMODE3 docs:

I have to walk the line of matching what current folks are used to using (seen above, u-center) and educating people (like me) that don't know the details.

Does "WGS84 Geodetic" (Lat/Long/Alt) work gdt?

I am impressed with the software improvements.

Awesome! Thanks! And thanks for making it even better.

[gdt]

The notion that "altitude" must be in the range -99 to +99 is strange. It's also strange to be in cm vs m. I think there may be something more complicated going on where there are multiple concepts, common in surveying, of the HAE of the mark itself, and then the distance from the mark to the ARP (often called Height of Instrument (HI)), and finally there is the Antenna Phase Center to ARP offset variable in azimuth and elevation according to an antenna cal file. Maybe this is about a limited range of Instrument Height; up to about 2m or so is totally normally and 10m would be odd. I normally see cm in the context of antenna calibration and m every place else.

I find "WGS84 Geodetic Alt" to be strange, even if there is some usage of it. The concept here is very much HAE; if one is inputting in XYZ, those are very definitely related to the Cartesian origin of the frame. Changing to latitude longitude and ellipsoidal height is just math without any physical assumptions, a change of coordinate systems. So the device must, for some 99.99% value of must, take height above ellipsoid.

There are two problems with terminology. One is that "altitude" is a concept almost always referenced to gravity and level surfaces, and thus on hearing altitude one thinks of height above the geoid, something sort of like NAVD88 (which is referenced to an almost-level surface...). The other is that Android has an odd standard for the location provider where they define getAltitude to return Height Above Ellipsoid. To me this muddies the waters further and is another argument for adopting a policy of never using the word altitude; lots of people think they know what it means but they don't all agree.

A problem here is that if you imagine someone using the UI and they do not understand the concept of Height Above Ellipsoid (or equivalent term ellipsoidal height), they are just not going to be able to do this right. And they are going to have to get that value from someplace. So I think it's better to use a precise term they might not understand and document it.

I have been able to obtain HAE values for most locations by only two methods: doing 24 hours of dual-frequency carrier phase observations and using OPUS from NGS, and doing RTK with the MaCORS reference network (and hence getting HAE in NAD83(2011) instead).

So I really think you should say "Height Above Ellipsoid" or HAE and define that in documentation. The idea of HAE of the ARP vs the HAE of mark plus HI needs to be understood as well. However, I would expect most people using a pair of RTK Surveyors would set one of them up with a permanent or semi-permanent antenna and then using OPUS, or doing RTK with their fixed antenna as rover and some local RTN as the base. So what one obtains is an HAE for that antenna setup, and there is no physical mark. (Actually, it's sort of HAE of the ARP as modified by the antenna calibration; I don't know if you are loading antenna cal files into the F9P.) Then this location is stored with that same device, not moved, to be the base.

[gdt]

Can you comment with a link to the F9P spec you are reading; I can grab the pdf and look at it.

[nseidle]

u-blox ZED-F9P Integration Description. Page 79, UBX-CFG-TMODE3.

The notion that "altitude" must be in the range -99 to +99 is strange.

Sorry, my fault. That was byte 18, the high precision portion of the coordinates. Below is the correct setting in cm:

This is what my working RC looks like:

And they are going to have to get that value from someplace.

We generally point folks at our PPP Tutorial which eventually has folks input ECEF.

I've added firmware upload. Don't mind v16 file name, it was just for testing.

[Eric-FR]

I support Greg in using "Height Above Ellipsoid", instead of the underlying notation of ublox. End-user is not supposed to use F9P directly but he may more likely SparkFun's products.

And also avoid mentioning WGS84 (https://www.openstreetmap.org/user/StephaneP/diary/390290). For the open RTK network centipede implemented in France, we use a local geodetic system that coincided with WGS84 in 1993 : RFG93. It is subject to plate motion but with negligible deformation. Plate motion is about 3 cm/year (7 cm/year in Australia) so it should be take into account when working with RTK. For people willing to extend centipede to other countries, we also recommand to use local system, if available.

[gdt]

I also think @Eric-FR eric-fr is right about other datums. RTK is basically carrier phase differential, and what you get is a vector from base to rover. Of course the base's coordinates have to be close to the WGS84 coordinates for the math to work, but it is entirely normal for the base coordinates to be in a plate-fixed national datum. Plate motion in the US (except California where basically everything is unstable :-) is also a few cm/year and over 10 years this will become noticeable with this grade of equipment; I think I am getting better than 5cm repeatability with the ardusimple unit (basically the same F9P with different board/power/case/wifi choices and no battery) and their "calibrated survey" antenna. I am unclear on if NTRIP or RTCM has a way to encode the datum, but it should.

While PPP is good, I think for people in the US that can gather 24h of carrier phase data and use OPUS, it will get them better data. I'm still experimenting.

A further wrinkle is that many GPS receivers output an "altitude" and because of NMEA0183 marine heritage and "humans use orthometric heights", that value is basically the HAE measurement with a geoid model applied. However, many receivers, apparently including the F9P use an old and reduced-resolution model, leading to about 4m of error between the actual EGM2008 value and the receiver's estimate of geoid separation. Which is basically to say that WGS orthometric heights from an F9P cannot be taken seriously even in RTK mode with an accurate HAE.

[Eric-FR]

@Eric-FR - WRT to negative inputs, it seems you have a keypad/keyboard issue.

So I installed the google keyboard and I can set negative values.

More surprisingly, I made a factory reset of my phone (for other reasons) and when I configured again office wifi, the ".-" key of the numerical pad was available. But when connecting to the Express (with Chrome), the same key was only showing the ".".

[Eric-FR]

BTW, I installed the stable 1.5 firmware from the µSD using the wifi interface and it went well.