## My Research with the MOSAiC Expedition

The Polarstern setting up its year-long camp near the North Pole (85° N, 137° E) on October 11, 2019. Photo credit: AWI / Stefan Hendricks.

The last few months have been some of the busiest and most exciting of my life. In 2019, I began a PhD program, moved to a new city, started my son in kindergarten, gave my first international presentation, and traveled to four states, four countries, and two new continents. And next year I will be a part of something I never imagined I would be able to do as an electrical engineer. I will travel to the North Arctic, live onboard a research vessel for two months, and participate in the largest Arctic expedition in history.

The Multidisciplinary Drifting Observatory for the Study of Arctic Climate (MOSAiC) is the first year-long Central Arctic expedition and the largest study of its kind. Beginning September, 2019, the German icebreaker Polarstern made way from Tromsø, Norway towards the northern coast of Siberia. It found a section of sea ice large enough to support it and, for the next year, will drift with the ice floe across the Central Arctic, getting within 200 km (~120 mi) of the North Pole. The year is divided into six two-month legs with research vessels from Russia, Sweden, and China assisting in the transfer of personnel and supplies between each leg.

Polarstern drift path. Graphic credit: https://www.mosaic-expedition.org/expedition/drift/

Led by the Alfred Wegener Institute (AWI) in Bremerhaven, Germany, 600 researchers from all over the world and from an array of disciplines will come together to study sea ice, ocean, atmosphere, and ecology and acquire data throughout the year as the ice, sea, and atmosphere interact and change in response to the Arctic climate dynamics. This data will then be made publicly available to be used by generations of researchers in the development of ever-more accurate and robust climate change models.

Our group at The Ohio State University built an ultra wideband microwave radiometer (UWBRAD) that will receive emissions in the 0.5 – 2 GHz range and use a radiative transfer model to estimate ice thickness and salinity. These observations will be conducted for the entire length of MOSAiC, giving an overall picture of how the ice changes over the course of an Arctic year. The instrument was designed and constructed by my advisor, Dr. Joel Johnson, and colleagues, Oguz Demir and Mark Andrews at OSU. Oguz and I will each be on a separate leg of MOSAiC, operating the instrument. To be a part of this expedition as a PhD student is the chance of a lifetime.

The Ultra Wideband Software Defined Microwave Radiometer (UWBRAD) installed in the ice floe near the Polarstern. Photo credit: Gunnar Spreen, Nov 2019

There will be 40-50 researchers onboard the Polarstern for each leg. They range from atmospheric and marine scientists to electrical engineers. Each group is conducting their own research studies to collect data about the Arctic which will be made publicly available once the expedition is complete. In addition to operating our UWBRAD and other remote sensing instruments during my leg, I will be assisting some of these other research groups to collect data while in the Arctic.

One such group I will assist is the sea ice group. To prepare for my sea ice duties on MOSAiC, in April of 2019, I flew to the northernmost settlement in Alaska, Utqiaġvik (formerly Barrow), to attend a week of sea ice training.

Utqiaġvik, Alaska, a small town on the north coast of Alaska, faces the Arctic Ocean, surrounded by ice. Image from a Sentinel 2 satellite, taken April 6, 2019, one day before my arrival.

Closer view of Utqiaġvik.

In Utqiaġvik, we learned how to take field measurements in 0°F (-18°C) temperatures and 20-25 mph (32-40 kph) winds. The conditions will be much worse near the North Pole, of course, but it was a great primer for what to expect when working out on the ice for 2-3 hours at a time. The biggest lesson I learned: you need the right cold weather gear. If you are warm inside your gear, you can get the work done you need to do and even enjoy it.

A few of the highlights from this trip were snowmobiling on the frozen Arctic Ocean, learning to take ice cores for later analysis of the different ice layers, operating a LIDAR scanner to measure changes in snow thickness, and taking snow profiles using the SnowMicroPen.

Jeff Bowman (left), of Scripps Institution of Oceanography, demonstrates taking an ice core, along with researcher Steve Archer (right), of Bigelow Laboratory for Ocean Sciences.

Chris Polashenski (far left), of Dartmouth College, demonstrates using a LIDAR altimeter to precisely monitor snow depth changes.

Dr. Martin Schneebeli (right), of WSL Institute for Snow and Avalanche Research, and researcher Marc Oggier (left), of University of Alaska Fairbanks, use a Snow MicroPen to precisely measure snow profiles.

In the mornings and evenings during my week in Utqiaġvik, I left our warm berthing to stand at the edge of the frozen Arctic Ocean and watch the sun come and go for as long as I could take the cold. It is difficult to explain what it feels like to see the edge of the world, and to see what lies beyond it. Where the Beaufort and Chukchi seas meet on the north coast of Alaska, the wind builds unobstructed for a thousand miles. There are no trees or large buildings, just frozen land, sea, and ice. Nietzsche said, “If you gaze long into an abyss, the abyss also gazes into you.” I could feel the unknown reaching out to me in its slow, heavy way. The longer I stood there, the closer I became to something much bigger and older than me. But inevitably my eyelashes would freeze and my fingertips became numb, so I was forced to turn back towards the road.

I have always wanted to know what the Earth felt like before man. To live without buildings or roads or hospitals or neighbors or systems that push us forward through life. To live without a safety net. This is it. It is bitterly stunning and cold at the threshold where the last town ends. I have a primitive gratitude for the systems that carry us. We have created structure in our society. We have schools, interstates, climate-controlled offices. We have saved ourselves from chaos and extremes. We could have left progress at the hunter-gatherer stage, but it is not in us to be stagnant. It is in man’s DNA to work towards a goal. We need to build, to light our world, to advance, and to pass on our knowledge to the next generations. The spirit of science is to learn more about our world and the spirit of engineering is to apply that knowledge. But it is our responsibility as humans, capable of understanding the consequences of our actions, to ensure our efforts are applied for the good of the world. We are responsible for the outcome.

Projects like MOSAiC give me hope in our future. It is an international community, funded by multiple international government agencies and nonprofits, working together to learn more about the world, to provide that knowledge free to the world, and to apply it for the good of the world, while taking full advantage of man’s natural need to create structure from chaos. This is mankind at her best.

People are not good or bad, but have the potential to create both. MOSAiC puts us to work, uses our skills and knowledge to create change. If you visit the MOSAiC website, you can find a lot of information about the project, as well as some great videos about the expedition, the science, and the Arctic. In one of them (shown below), the expedition leader, Dr. Markus Rex, beautifully summarizes the purpose of MOSAiC:

“Our overarching scientific goal is to improve the climate models such that they can be used as a solid scientific basis for political decisions we are facing right now so that we can shape our future rather than tumble into it.”

Our greatest desire as societies is to shape our future into what we most believe to be good and true. Unfortunately, we don’t have an overall consensus of what is good and true. Fortunately, research like this helps us gather the data and facts about the world that we need to one day, hopefully in my own or my son’s generation, reach this consensus.

## Women in Remote Sensing

View from my dorm room during my week-long stay at Universitat Autónoma de Barcelona, Cerdanyola del Vallès, Spain

Much has changed since my last post on my undergraduate research with GNSS and UAVs. In Fall of 2018, I applied and was accepted into a PhD program in electrical engineering. I started the program in January and have since become involved in some exciting projects and research. One of those is MOSAiC: the Multidisciplinary drifting Observatory for the Study of Arctic Climate, which I will soon be writing a separate post for.

But last week I attended a remote sensing summer school near Barcelona. The school was hosted by the Institute of Space Sciences of the Spanish Research Council (ICE-CSIC/IEEC), located at the Universitat Autónoma de Barcelona (UAB) in Cerdanyola del Vallès, Spain, about a 50 minute train ride from Barcelona center. This was the first summer school of the IEEE GRSS Instrumentation and Future Technologies Technical Committee. The week-long course was led by Dr. Estel Cardellach, a remote sensing expert in the field of GNSS-reflectometry. Together with Prof. Adriano Camps, Dr. Lidia Cucurull, Dr. Scott Hensley, Dr. Marwan Younis, Dr. Pau Pratts, Dr. Rashmi Shah, Dr. Serni Ribó, Prof. Adolfo Comerón, Dr. Upendra Singh, and Prof. Alex Papayannis, the instructors covered synthetic aperture radar, GNSS-reflectometry, other signals of opportunity (SoOp), and LIDAR. It was a very fun and informative week and I met many amazing people who are excited about remote sensing and its applications.

Institute of Space Sciences, UAB: site of our remote sensing course

There were around 40 of us students and we came from at least 24 countries: Romania, Saudi Arabia, Turkey, Zimbabwe, Central African Republic, United Kingdom, Finland, Italy, China, India, Poland, Greece, Germany, Estonia, Japan, Spain, Philippines, Australia, Vietnam, Pakistan, France, Argentina, Guatemala, and the United States. Almost 20 of us were females. We were a diverse lot.

Two of the women I got to know last week have inspired this post (after an interesting conversation on the metro!): Inshu Chauhan and Estefania Ortiz Geist (below). These two remind me that women belong here in science and engineering.

Inshu Chauhan (left) and Estefania Ortiz Geist (right) at UAB

Inshu Chauhan is an Assistant Professor of Civil Engineering at G B Pant Institute of Engineering and Technology in Pauri Gharwal, India. She teaches geomatics, introductory remote sensing, GIS, GNSS, and image processing. She has been in her current position for two years and is one of only two women in her department. She loves remote sensing and wants to stay in this field for the rest of her life. “Remote sensing is multi-disciplinary. There are scientific, societal, and environmental aspects that can be integrated to improve the lives of people. I love that, using technology, we can touch people’s lives.”

Estefania Ortiz Geist is a Navigations Operations Engineer at ESA: European Space Agency. She currently works at ESA’s European Space Operations Center in Darmstadt, Germany, where she has worked in precise orbit determination for GNSS constellations for the last 2 1/2 years. In school, Estefania majored in math, astronomy, and geodesy, and says she has always wanted to work in space. She was born in Argentina and raised in Madrid. She now has a huge interest in working in remote sensing with applications in Earth science.

Over the years, science, math, and programming have become a safe haven for me, a place where I can find relief from the things in the world that don’t make sense. But I only found my passion for them in my twenties. And it wasn’t until I reached my thirties that I finally believed these pursuits could be for me. I look back now and see I had an implicit image in my mind that engineering was for men. Logically, I knew it wasn’t impossible for women to pursue this field. But I had this subconscious image that came up when I thought of ‘engineer’, and I didn’t match it.

Perhaps if I had met more women like Inshu and Estefania earlier in my life, this implicit belief I had would have been challenged and I may have chosen engineering much sooner. Understanding that a career pursuit is not just possible but normal for someone like you makes it much more likely that you will choose it, given interest and ability.

There is this argument going around that women’s underrepresentation in STEM is due to a genuine lack of interest in STEM rather than systemic discrimination. But what this argument overlooks is human beings are wired to want to fit in with their peers. When you’re in school and trying to find your path in life and you look around at the people in a certain profession and do not see others like you, it changes your view of that profession, and of whether or not you belong. You come to a tacit conclusion that that field is not for you. There is no room for you. There are no people like you. And this belief is so insidious that most people have no idea it’s present. Instead, it manifests as an apparent disinterest in a field that was never given genuine consideration.

I have a personal hero whose name is Bertha Lamme. Lamme was the first American woman to graduate in an engineering field other than civil, the first female to graduate from an electrical engineering department, and the first female engineering graduate at my alma mater, The Ohio State University. Unfortunately, she is not well-known by instructors or students, women included. Yet, it is people like Lamme who made this path possible for the rest of us.

Bertha Lamme, 1892 (courtesy: IEEE History Center)

To be the first at anything, to do something that you have no evidence is possible for you, takes an enormous amount of courage and inner vision; there is nothing more inspiring. And yet, I only learned who Lamme was from a book I happened upon at the library: “Women in Engineering: Pioneers and Trailblazers,” by Margaret Lane (highly recommended, by the way).

There are so many women who are nameless in history who have paved the way for us. Just as there continue to be women, right now, all around us, who have the courage and inner vision to be the first in their families, the only at their universities, or the leader of their teams. Women who have some intangible inner drive to pursue their dream no matter the obstacles. There is a loneliness to it. But also the knowledge that our paths have great meaning beyond our immediate sight.

It is easy to fall into the trap of thinking we don’t belong here when we sit in a room that is 95% men, or that our male counterparts have an inherent advantage over us. It certainly has happened to me and that type of thinking kept me from pursuing this path earlier in my life. So I take it as a personal mission to be an echo for women like Lamme, Inshu, Estefania, and all women in this field who are doing amazing things in their lives with the knowledge that they will have to fight for the same respect readily given men, and without the glory.

Lamme and others like her were the first to make a career in engineering possible for women. It is our task to continue the change-maker tradition, widening the path by making ourselves visible to future generations, teaching them the new normal.

## Convert Latitude, Longitude, Altitude to North, East, Down and Find Distance Between Base and Rover

In order to achieve accurate and precise positioning on a moving platform like a drone, an RTK (real time kinematics) GNSS is the best option. The u-blox C94M8P achieves RTK positioning by using two GNSS receivers: the rover mounted to the drone and the base stationary on land.

For many of the imaging tasks we wanted to perform in my undergrad research group, we needed to convert the typical latitude, longitude, altitude (LLA) coordinate system to a north, east, down (NED) coordinate system.

For more information about what NED is and why it’s often used in aerospace, this Wikipedia article is a good start.

The short version is NED measures the north, east, and down directions from an origin of your choosing. It’s a convenient system to use if you want to know where a moving platform is relative to some reference point, as is the case with our drone’s rover-base positioning system. The drone’s initial position can also be used as the origin, but in our application with two GPS receivers, the base is a natural choice.

An advantage of NED is you can easily obtain distance between base and rover by simply implementing the 3D distance formula:

$\mathbf{distance=\sqrt{north^{2}+east^{2}+down^{2}}}$

While MATLAB has a built-in function, geodetic2ned, which converts geodetic (LLA) coordinates to NED, it’s only available in their mapping toolbox, which requires an additional purchase. So, I did some research and created my own function, which I named LLAtoNED. I share it freely in the name of open source.


function [time, north, east, down, dist] = LLAtoNED(baseFile, roverFile)

%{
File:           LLAtoNED.m
Author:         Brandi Downs
Last Updated:   12.11.2018

LLAtoNED.m reads in a file specified by the user, looks for the
parameters given below, and stores them to a cell array for further
processing.

This script currently stores data only from $GNGGA sentences. This script assumes the base GPS unit is stationary. Parameters: TIME LAT LONG FIX HDOP ALT SEP %} %% Open base and rover txt files, read in NMEA sentence data, store data in new arrays roverData = fopen(roverFile,'r'); % open rover file for reading row = 1; % begin with row 1 % initialize a matrix for each parameter you want to store gngga = []; % stores all data from GNGGA sentences time = []; % time in UTC lat = []; % latitude long = []; % longitude fix = []; % fix type or quality indicator (see note above) sats = []; % satellites used hdop = []; % horizontal dilution of precision alt = []; % altitude sep = []; % geoidal separation format long; while ~feof(roverData) % while not end of file line = fgetl(roverData); % get next line line = regexp(line,',','split'); % split line into cell array according to commas if ~any(strcmpi('$GNGGA',line))     % if line doesn't contain 'GNGGA', continue to next iteration of loop
continue
end

for i = 2:length(line)
gngga(row,i-1) = str2double(line{i});   % store all data to gngga matrix

% store time parameter to column vector
time(row,1) = str2double(line{2});

% convert degree, minute, decimal minute to decimal degrees
lat(row,1) = str2double(line{3})/100;   % move decimal place left 2
latdeg = floor(lat(row,1));             % extract integer part
latdec = lat(row,1) - latdeg;           % extract decimal part
latdec = latdec/60;                     % convert decimal minutes to decimal degrees
latdec = latdec*100;                    % move decimal place right 2
lat(row,1) = latdeg + latdec;           % add integer and decimal to complete calculation
% do same for longitude
long(row,1) = str2double(line{5})/100;  % move decimal place legt 2
longdeg = floor(long(row,1));           % extract integer part
longdec = long(row,1) - longdeg;        % extract decimal part
longdec = longdec/60;                   % convert decimal minutes to decimal degrees
longdec = longdec*100;                  % move decimal place right 2
long(row,1) = longdeg + longdec;        % add integer and decimal to complete calculation
% continue to store remaining parameters
fix(row,1) = str2double(line{7});
sats(row,1) = str2double(line{8});
hdop(row,1) = str2double(line{9});
alt(row,1) = str2double(line{10});
sep(row,1) = str2double(line{12});
end

row = row + 1;  % next row
end

fclose(roverData);

% Do same for base data
% Only keep lat, long, alt
baseData = fopen(baseFile,'r');     % open base file for reading
row = 1;
latBase =  []; % latitude
longBase = []; % longitude
altBase =  []; % altitude
while ~feof(baseData)   % while not end of file
line = fgetl(baseData); % get next line
line = regexp(line,',','split');    % split line into cell array according to commas
if ~any(strcmpi('$GNGGA',line)) % if line doesn't contain 'GNGGA', continue to next iteration of loop continue end for i = 2:length(line) % get base latitude and convert to decimal degrees latBase(row,1) = str2double(line{3})/100; latBasedeg = floor(latBase(row,1)); latBasedec = latBase(row,1) - latBasedeg; latBasedec = latBasedec/60; latBasedec = latBasedec*100; latBase(row,1) = latBasedeg + latBasedec; % get base longitude and convert to decimal degrees longBase(row,1) = str2double(line{5})/100; longBasedeg = floor(longBase(row,1)); longBasedec = longBase(row,1) - longBasedeg; longBasedec = longBasedec/60; longBasedec = longBasedec*100; longBase(row,1) = longBasedeg + longBasedec; % get base altitude altBase(row,1) = str2double(line{10}); end row = row + 1; % next row end fclose(baseData); %% Convert from lat, long, altitude (LLA) to north, east, down (NED) coordinate system % lat0, long0, alt0 will form the origin of the NED coordinate system lat0 = median(latBase); long0 = median(longBase); alt0 = median(altBase); % geodetic frame parameters Rea = 6378137; % semi-major axis (m) f = 1/298.257223563; % flattening factor Reb = Rea*(1-f); % semi-minor axis ecc = sqrt(Rea^2 - Reb^2)/Rea; % first eccentricity Ne = zeros(1,numel(lat)); % prime vertical radius of curvature for k = 1:numel(lat) Ne(k) = Rea./sqrt(1-(ecc^2)*(sind(lat(k))).^2); end Neref = Rea./sqrt(1-(ecc^2)*(sind(lat0)).^2); % prime vertical radius of curvature for reference point %% Geodetic to Earth-Centered Earth-Fixed (ECEF) -- Intermediate step % preallocate arrays for speed xe = zeros(1,numel(lat)); ye = zeros(1,numel(lat)); ze = zeros(1,numel(lat)); % convert rover lat, long, alt (LLA) to ECEF for k = 1:numel(lat) xe(k) = (Ne(k) + alt(k))*cosd(lat(k))*cosd(long(k)); ye(k) = (Ne(k) + alt(k))*cosd(lat(k))*sind(long(k)); ze(k) = (Ne(k)*(1-ecc^2)+alt(k))*sind(lat(k)); end % convert reference position (origin in NED frame) from LLA to ECEF xeref = (Neref + alt0)*cosd(lat0)*cosd(long0); yeref = (Neref + alt0)*cosd(lat0)*sind(long0); zeref = (Neref*(1-ecc^2)+alt0)*sind(lat0); Pe = [xe;ye;ze]; Peref = [xeref;yeref;zeref]; %% ECEF to NED % Rne is the rotation matrix from ECEF frame to local NED frame Rne = [-sind(lat0)*cosd(long0) -sind(lat0)*sind(long0) cosd(lat0); ... -sind(long0) cosd(long0) 0; ... -cosd(lat0)*cosd(long0) -cosd(lat0)*sind(long0) -sind(lat0)]; % convert ECEF to local NED frame Pn = zeros(5,numel(lat)); for k = 1:numel(lat) Pn(1,k) = time(k); Pn(2:4,k) = Rne*(Pe(:,k) - Peref); Pn(5,k) = sqrt((Pn(2,k))^2 + (Pn(3,k))^2 + (Pn(4,k))^2); end % use num2str(x,'%4.10f') to display full numbers time = Pn(1,:); north = Pn(2,:); east = Pn(3,:); down = Pn(4,:); dist = Pn(5,:);  LLAtoNED.m is a MATLAB function and hence must be called as a function command. By typing: [time,north,east,down,dist] = LLAtoNED(‘nameOfBaseFile.txt’,’nameOfRoverFile.txt’) in the command window, LLAtoNED will read in text files for the base and rover position data, do the coordinate conversions from LLA to NED, and output arrays for time, north, east, down, and distance between base and rover at each observation data point. For the ublox C94M8P in wireless RTK mode, the observation rate — or how many times the base and rover record their position data — is a maximum of 3 Hz max (3 times per second). Enjoy and please leave comments if you have any questions or feedback! Note: For the coordinate conversion matrices, I used this very helpful reference document: Coordinate Systems and Transformations ## How gpsd can interfere with your GNSS receiver and how to fix it Raspberry Pi 3 Model B and u-blox C94-M8P In order to work with the u-blox C94-M8P on the Raspberry Pi, I installed a GPS interface called gpsd on the Pi. Documentation on gpsd can be found here. And this is the tutorial I used to install it on the Pi. However, there is one issue with gpsd that neither tutorial mentioned. It turns out, when gpsd attempts to reconfigure certain Bluetooth- or USB-connected GPS receivers, it can interfere in strange ways with their functioning. I found that certain gpsd commands interfered with the C94-M8P’s ability to reach RTK mode. The receiver would initially reach RTK mode, then quickly lose it and achieve only a 2D/3D fix while gpsd was running. After much digging, I found a solution. You can configure gpsd to run with the -b option, which is a read-only mode that prevents it from writing to the GPS receiver. This can be achieved when you install it, by passing -b to the Options to gpsd prompt, or, if you have already installed gpsd, you simply need to change the default parameters, as detailed below: • Start up your Pi and open the default file for gpsd with: sudo nano /etc/default/gpsd • Set the parameters to look like this: • That’s it. Exit and reboot. From the gpsd man page: -b Broken-device-safety mode, otherwise known as read-only mode. A few bluetooth and USB receivers lock up or become totally inaccessible when probed or reconfigured; see the hardware compatibility list on the GPSD project website for details. This switch prevents gpsd from writing to a receiver. This means that gpsd cannot configure the receiver for optimal performance, but it also means that gpsd cannot break the receiver. A better solution would be for Bluetooth to not be so fragile. A platform independent method to identify serial-over-Bluetooth devices would also be nice. The read-only mode was a simple solution to a problem that plagued our group for over a week. If you are finding your Pi-connected USB or Bluetooth GPS mysteriously goes in and out of RTK mode and you have exhausted other causes, such as poor satellite reception at the base receiver or incorrect RTCM messages at the roving receiver, try checking your gpsd default parameters and adding this option. ## Decoding NMEA Sentences NMEA sentences (pronounced nee-ma), are a standard format of data output for all GPS receivers. In other words, it’s the language GPS receivers use to communicate the data they produce and receive, such as time, latitude, longitude, altitude, GPS health, speed, etc. NMEA stands for National Marine Electronics Association, the agency responsible for standardizing the language. The sentences were created as a means for marine electronics to all speak the same language, thus enabling digital communication between different devices. The sentence structure consists of a string of comma separated values, beginning with a ‘$’ and ending with a checksum. They look like this:

Each sentence is referred to as a message and tells useful information about the receiver and its positioning. The output above was obtained from a u-blox C94-M8P. Let’s take a closer look at the GNGGA sentence to understand what each field means. Note the contents of each field will be the same for all GGA sentences but minor variations may occur from one GNSS receiver to the next.

Message Identifier:  Identifies the source and type of information. The first two letters denote the Talker ID, identifying the source of the information. This sentence is a GN message, or Global Navigation Satellite System (GNSS), meaning a combination of navigation systems was used to obtain the message data. Common talker ID’s are listed below.

Talker ID Constellation Country
GA Galileo European Union
GB BeiDou China
GL GLONASS Russia
GP GPS United States
GN combination (GPS+GLONASS) multiple

The next three letters define the message content. GGA denotes GPS fix data. Some common messages are listed below.

Message ID Meaning
GGA GPS position, time, and fix data
GLL Latitude and longitude data
GNS GNSS position, time, and fix data
GRS GNSS range residuals (error-related data)
GSA Satellite information and dilution of precision (DOP: see HDOP below)

Time:  Universal Time Coordinated (UTC) in hhmmss.ss.

Latitude:  Latitude in decimal degrees (ddmm.mmmm).

North/South Indicator:  North or south of the Equator.

Longitude:  Longitude in decimal degrees (ddmm.mmmm).

East/West Indicator:  East or west of the Prime Meridian.

Quality Indicator:  The quality of the GNSS data — what kind of fix the receiver has obtained.

0 — No fix
1 — Standard GPS (2D/3D) fix
2 — Differential GPS (DGPS) fix
3 — Precise Positioning System (PPS) fix — for government use only
4 — RTK fixed solution
5 — RTK float solution
6 — Estimated (Dead Reckoning, or DR) fix

Satellites Used:  Number of satellites used in solution.

HDOP:  Horizontal Dilution of Precision — a measure of confidence in the solution. Lower numbers indicate a higher confidence level. Thus, the 99.99 shown here denotes highly inaccurate measurements. Refer to Wikipedia’s Dilution of Precision article for more information.

Altitude:  Altitude above mean sea level.

Units:  Units used for altitude or geoidal separation (M = meters).

Geoidal Separation:  Difference between the reference ellipsoid and mean sea level based on the geodetic model WGS84.

DGPS Station ID:  ID of the differential reference station used for DGPS. Blank when DGPS is not used.

Checksum:  Used for data validation.

The GNGGA sentence provides all the data one needs for most GNSS analysis and is what we’ll use when we write our script converting latitude, longitude, altitude (LLA) to a north, east, down (NED) coordinate system. However, other sentences may be useful, depending on your navigation needs. Below are some great resources I used in compiling this information.

u-blox 8 / M8 Receiver Description (pdf) — Includes a full breakdown of all NMEA sentences used in u-blox 8 / M8 receivers.

Trimble’s NMEA-0183 Overview

ESRI’s article on Mean Sea Level, GPS, and the Geoid

Eric Raymond’s extensive page on NEMA sentences

## u-blox tutorials

For my research project, I’ve worked pretty extensively with a certain Global Navigation Satellite System (GNSS) application board: the u-blox C94-M8P, which includes two u-blox NEO-M8P-2 receivers. It’s a highly accurate GNSS module with tons of cool functionalities (like anti-jamming capabilities) but takes quite the learning curve to be able to understand its various uses and settings.

So I’m starting this website by writing up a series of tutorials explaining some of the things I’ve learned about the C94-M8P and GNSS, such as:

• how GPS works
• all about NMEA sentences
• what are RTCM messages
• how RTK GPS works
• using u-center, u-blox’s evaluation software
• saving configuration settings with u-center
• configuring the C94-M8P for base/rover mode
• enabling RTCM messages on the C94-M8P
• achieving RTK mode on the C94-M8P
• troubleshooting why the receiver won’t achieve RTK fixed mode
• using gpsd to interface with the C94-M8P on the Raspberry Pi
• how gpsd can interfere with a GNSS receiver and how to fix it
• converting latitude, longitude, and altitude to a north, east, down coordinate system
• finding distance between base and rover

I’ve gathered this knowledge through a combination of research, reading u-blox manuals, browsing their Q&A forum (and especially learning from clive1), and my own trial and error. My hope is to contribute to the free library of online knowledge that I have benefited from and help others with similar technical problems to those I encountered.