u-blox GPS modules: Much
of the information
to be presented in the following paragraphs (perhaps the useful part)
may also be found in a “Build this....” article,
by Trident
Amateur Radio Club president
Ron (K4TCP).
Radio amateurs deploy GPS modules in a
variety of applications, including APRS (https://github.com/4x1md/vx8_gps),
high-altitude ballooning (http://www.arhab.org/), or
possibly in the construction of a precision station clock. [Although
for station time, an Internet solution
might also be considered,
such as was described in my station clock project,
or alternatively, long wave radio time, e.g., station WWVB
in the United States.]
The first u-blox GPS module I purchased
was a
Neo-6M, similar to this one. I didn’t realize at the
time that a more advanced model the Neo-M8N was available for roughly
the same price (e.g. https://www.ebay.com/itm/142360007536).
These modules consist of a postage-stamp size evaluation board
containing
the GPS receiver, a small battery, annotated serial interface connect
points (no header), plus an active antenna that attaches via a tiny and
rather flimsy connector. The idea must be that once the unit has been
mounted in an enclosure, the board and antenna will not be jostled or
fall apart, as they are inclined to do on the bench. The M8N also
has attachment points for an accessory antenna connector (not included).
The u-blox module can be interfaced
directly with a computer using a USB-to-serial adapter, or if the
computer is old enough, a hardware serial port (with appropriate
voltage conversion). Another option is to
use Arduino’s hardware
and software serial capabilities
for message forwarding. The present exercise employs the
latter method.
Software
serial:
I have long had difficulty with directions that appear to omit a
frame of reference. For example, if the weatherman says that
a
storm system is circulating anti-clockwise, I want to ask, “Do you mean
looking up into it or looking down on it?”
(S/he means the latter.) It is the same when directions say, “pin
2 is transmit.”
Well, who
is talking? Is it device A or device B, and so forth? Possibly I am the
only person in the world with this problem. However, my point is that
whereas input-output connectors may have standard specifications, if a
communications channel will be defined on arbitrary pins, it is
important to identify which pin serves which direction of communication.
Multiple Arduino serial
com pass-through sketches may be found on the Internet, for
example the one at https://blog.startingelectronics.com/how-to-use-arduino-serial-ports/.
They are all basically the same, up to naming of
variables and choice of transmit-receive pins. I have copied a
pass-through sketch,
making only minor changes,
from the aforementioned link
here.
Before abandoning my rant about specifying the transmit-receive frame
of reference, one final note: Care is also required to observe the
directionality of the hardware serial connection. The photo above left
shows
that Neo-M8N connection points are directionally opposite to
those of the Neo-6M, other things being equal (chip side up, battery or
antenna location, etc). Of course, these evaluation boards came
from different suppliers and there may be no standard for such things.
In the example listing
above, selected data
columns have been blanked out. Well, from the remaining viewable data,
fixes were obtained somewhere on a circle that is 6,561 kilometers
from London, so the location isn’t 100% anonymous. The software that
produced this listing is called “FullExample”
and is part of the TinyGPS++ Arduino library (https://github.com/SensorsIot/TinyGPSplus-for-Neo-M8N).
I modified the sketch slightly to omit displaying asterisks when no
valid data are available. This and similar examples included with the
TinyGPS Arduino library should make custom applications
development an easy exercise. Another
excellent software resource is
the u-center suite (from u-blox), which may be downloaded here.
The green-on-black “Deviation Map”
reproduced at the beginning of this narrative is one of several views
furnished by the u-center software.
The
breadboard photo above shows a Neo-M8N
connected to an Arduino Nano by way of a bi-directional level
converter. The 3.3 volt
pin on
the Nano supplies power
to the GPS module, while GPS receive and transmit wires connect to Nano
pins
D5 and D6, respectively. These pins are the same ones defined in
corresponding test sketches for software serial use.
Of course, other pins could be used instead, provided
sketches and
wiring are consistent. Connections (in the photo) between Arduino pins
0 and 1 and the
level
converter at B1 and B2 are not relevant to the configuration being
demonstrated.
A flashing green LED on the Neo board
indicates that the module is receiving sufficient
satellite
data for a
valid fix. This indicator is handy for checking things out at the
bench, without
having to connect the module to a computer. Based on limited testing
the Neo-M8N appears to
be more sensitive than the 6M. A possible explanation
is that
the M8N processes data from Russian as well as United States
satellites. When
testing inside the house, that is without a clear sky view,
the M8N quickly acquires a fix, while the Neo-6M may take
several minutes (or may fail completely on an overcast day).
It should not be surprising that
altitude
estimates derived from these modules are generally poor, because the
same is true of consumer GPS
devices. A quick Internet search yields several putative explanations
for the altitude anomaly, for example
the following, which seems plausible: http://gpsinformation.net/main/altitude.htm.
I have no particular goal or application
in mind for these units. One possibility is to interface
the M8N with a specific amateur radio transceiver.
Another idea that seems
logical, but I’m not sure is valid, would be to average many thousands
of fixes in order to derive an exceptionally precise estimate of a
specific (marked) location. According to scientists and the National Geographic Society, North
America is moving away from Eurasia at a rate of 2.5 cm per year. Hmm!
For fun I used Excel to compute the
average of 62,725 GPS fixes acquired overnight. I thought that the
result should provide a decent estimate of the latitude and longitude
of the bannister next to my computer desk. However, given this average
as input, Google Earth puts its stickpin over the next door neighbor’s
breezeway, about 10 meters from the true location. How
accurate is Google Earth? One supposes that cartographers have
referenced the photos to precisely known (surveyed) locations. But that
is only a guess.
GPS Demo: u-blox_modules.mp4
Project descriptions on this page are intended for entertainment only.
The author makes no claim as to the accuracy or completeness of the
information presented. In no event will the author be liable for any
damages, lost effort, inability to carry out a similar project, or to
reproduce a claimed result, or anything else relating to a decision to
use the information on this page.
