Using a GPS with TASMOTA (Part II)

This is part-2 of a two part series.  If you missed it, the first part is here.


CONFIGURATION

Once you have your build of TASMOTA installed and the physical connections made, you need to configure which ESP pins TASMOTA will use to communicate with the GPS module.  There are a couple of points to make here …first, the TASMOTA pin configuration refers to the data flow with respect to the ESP8266 itself, while the labelling on the GPS module pins refers to data flow with respect to the GPS.  This means that the pin you define as GPS_TX on the ESP actually connects to “RX” on the GPS module and GPS_RX connects to “TX”.  The second point is “Don’t Panic!”, as I mentioned earlier, you can’t harm either the GPS or the ESP by connecting or configuring them the wrong way round.  The last point is that if your GPS module doesn’t support the UBX protocol, it ain’t going to work, no matter which way round you connect things.

Okay, boot your ESP8266 and connect to the TASMOTA web interface.  Go to “Configure” and then “Configure Module” and select the “Module type” to be “Generic (18)” (you’ll need to scroll right down to the bottom of the list of modules to find it).The TASMOTA pin configuration menu, showing GPS_RX highlighted  Save this change.  When the save is complete you can go back to the “Configure Module” tab and will now find all of the available pins on your module displayed.  Select GPIO12 and again, scroll right to the bottom of the pull-down listing.  You should see the options “GPS_RX (190)” and “GPS_TX (191) close to the bottom of the list (if you don’t see them, then the “#define GPS” option in the tasmota/my_user_config.h file has not been un-commented, or you’ve flashed the wrong image to your ESP).  Remembering that “GPS_RX” refers to data received by the ESP, select that option for pin GPIO12 (which is connected to the “TX” pin of the GPS module) and then “GPS_TX” for pin GPIO_13 (connected to “RX” on the GPS module).  Save those changes.

The ESP8266 will restart itself as part of the “save” process and when it comes back up again you should see several GPS status lines above the normal buttons on the main menu.

TASMOTA main menu showing GPS status lines, but all readings zero.
No Data From GPS

If your GPS module hasn’t acquired satellite data (GPS LED not flashing). or if it doesn’t support the UBX protocol, the GPS status lines will be present, but the data will be zeroed out (as shown above).  It’s also possible that your TX and RX configuration is reversed, so it’s worth trying either changing the pin configuration in TASMOTA, or just swapping the wires over (whichever is easiest).

TASMOTA main menu with live GPS data shown
GPS With Live Data

If your GPS is correctly configured, has already acquired data and supports the UBX protocol, you should see something like the screenshot above, with the data updating once per second.

There are several commands available via the TASMOTA console to manipulate the GPS data handling functions.  Commands are entered at the console and have a format of sensor60  n[n] where “n” is a number and “sensor60” specifies that this command is  for sensor number 60 (which is reserved for the GPS module).  So an example might be:-

sensor60  9   —   Start the NTP server process (using time data from the GPS module).

Here’s the complete list of commands, as of early Feb, 2020.

  • COMMAND     DESCRIPTION
  • sensor60  0  —  Write log data to all available storage, then stop
  • sensor60  1  —  Write log data to all available storage, then restart from the beginning (overwrite mode)
  • sensor60  2  —  Filter horizontal noise from GPS signal
  • sensor60  3  —  Stop horizontal noise filter
  • sensor60  4  —  Start recording log data to storage in append data mode
  • sensor60  5  —  Start recording log data to storage in overwrite data mode
  • sensor60  6  —  Stop recording log data to storage
  • sensor60  7  —  Send an MQTT update on each positional change (very noisy)
  • sensor60  8  —  Stop sending MQTT updates on positional changes
  • sensor60  9  —  Start the NTP server on port 123 (GPS web updates stop)
  • sensor60  10 — Stop the NTP server (GPS web updates start again)
  • sensor60  11 — Force a TASMOTA time update on each GPS packet
  • sensor60  12 — Stop time updates on GPS packets
  • sensor60  13 — Set TASMOTA lat/long values from GPS positional data
  • sensor60  14 — Start virtual serial TCP server (UBX data) on port 1234
  • sensor60  15 — Pause virtual serial TCP server

USES
LATITUDE/LONGITUDE

Now that we have our commands down pat, we can put the GPS data to use.  The first (and possibly the the most immediately useful) is command 13, setting the latitude and longitude values from the GPS reported values.  This will allow the TASMOTA sunrise/sunset timer functions to work without any manual intervention (that is, even if your timezone isn’t correctly set, having longitude and latitude available from the GPS allows the sunrise/sunset algorithm to calculate those values).  Note that there was an issue with this function in the initial release, so you should use TASMOTA version 8.1.0.9 or above (the link in part-I of this article is to a good, working version).

NTP SERVER

Don’t be confused by this.  TASMOTA already has NTP client capability baked-in (it will listen to other NTP servers to set its own time), but this option, command 9, starts an NTP server process which allows other systems to interrogate your ESP8266 on port 123 for time data (your ESP becomes a network time provider, instead of just being a consumer).

As you might expect with such constrained memory limits, this implementation has some limits.  The stratum level  (the measure of how many levels, or hops, we are removed from the physical source of the time signal) is hard-coded to “2”.  In a normal configuration, the time source itself counts as stratum 0 and the machine connected to it would be stratum 1, which would be treated as a preferred source by downstream clients.  However, our ESP8266 isn’t using  pulse-per-second synchronization of the time data (it’s simply publishing it on arrival), so marking it as a stratum-1 primary source could lead to problems (especially if you happen to be a day-trader).  The good news is that it is still a very accurate source of time data in certain situations.  For instance, if you have an isolated network of IoT devices, accuracy to the nearest second is probably acceptable and having an ESP8266+GPS combination providing NTP services is a low cost, low power option for a network of wireless data-loggers.

There’s another point you need to be aware of if you’re setting this up on a network with other NTP servers present; the ESP needs to be configured as a “server” in the ntp.conf file on the other machines, not as a “peer”.  This is because being a peer requires two-way communications between the machines and this implementation only has the capability of replying to a simple request for a time packet.  If you configure the ESP as a peer, the other machines in the network will ignore it and show it as being stuck in the “INIT” state.  If you configure it as a server however, the other machines will happily request time data from it …although, in my case anyway, the data from the ESP is so far off the time reported by the other systems in the NTP group (that is, local NTP servers on my network as well as “upstream” NTP sources on the internet) that the ESP is almost immediately marked as an “outlier” (with a “-” character in the first column of the “ntpq -p” output) and subsequently ignored.  It could still be quite useful, though.  If you are relying on upstream NTP servers on the internet (which is generally a good thing), then you would lose synchronization if your internet connection was down for any significant amount of time.  Your ESP though, would still be providing a local time source with one second accuracy, which is still pretty good (day-traders excepted).

The load of updating the GPS readout (as seen in the photo above) and providing time critical replies to NTP requests is also a little bit too much for the ESP8266, so you’ll see a message, “NTP Active” appear in that window and the GPS updates will stop while the NTP server process is running.  Once the “Sensor60 10” command is given to stop NTP, the GPS updates will restart and the “NTP Active” message will disappear.

One final wrinkle to the NTP implementation is worth noting (although it’s more of an “interesting characteristic” than a bug).  The “refid” field in the output of  “ntpq -p” command (on another NTP client on your network, not on the TASMOTA device) has two different modes of output.  Normally it will display the IP address of the machine to which the indicated peer is currently listening, but if the peer is a stratum-1 clock source, it will print one of a limited number of strings to let you know to what type of a clock device it is connected (ie:- radio-clock, atomic-clock, etc).  Now because our ESP is directly connected to a clock-like device (the GPS) but, as mentioned earlier, is pegged as a stratum-2 device, the refid output field displays the highly unlikely IP address of “71.80.83.0” (hint:- if you haven’t already guessed why it should do this, try “man ascii” for the answer).

LOGGING

If you happen to take your ESP8266/GPS combo with you when you’re hiking, paragliding or orienteering, then this section might be of interest.  Christian has added the option of logging GPS data to the ESP8266 flash, so you can save your experience for perpetuity (well, you can probably save some of it anyway …there’s not that much flash on an ESP8266).  This is the reason for the very oddly named “#FLOG” setting in the TASMOTA config file (nothing at all, as far as I know, to do with fifty shades of black and blue).  If that setting is un-commented, then flash-logging of GPS data is enabled and commands “sensor60 0” and “sensor60 1” set the log handling mode to “overwrite” or “stop writing when flash is full”, respectively.  Commands 4 and 5 both start the log recording, but 4 starts in append mode, while 5 starts a completely new log, overwriting whatever data was there.  When you start a recording the “Flash-Log” status line in the TASMOTA main menu window (see photo, above) changes from “ready” to “recording”.  Command number 6 stops the recording.

Once you stop a recording, a new, blue button will appear above the GPS information in the main menu.  There is no text displayed on the button (at least there isn’t in either Firefox or Chrome) until you move your mouse pointer over it, at which point the message “Download GPX-File” will appear, flashing on and off in time with the updates to the GPS data (perhaps this works as a normal button in some other browser?).  In any case, clicking on the button will download the flash-log data to your system.

VIRTUAL SERIAL PORT

You can also connect to a virtual serial port on the ESP8266 to get a live view of the (binary!) data streaming from the GPS unit.  The “sensor60 14” command will start this virtual serial connection on port 1234 and command 15 will stop it.  If you’d like to check the data, you can connect to your ESP using:-

nc  IP-ADDRESS  1234  |  od -x

Christian mentions that the intended use for this (other than trying to read hex data very quickly) is to feed into the u-blox “u-center” application, which is a debug and management application, freely available from the u-blox site (recent revisions are for  Windows only, though).

The Bottom Line

Christian has produced a very versatile and interesting application, adding an exciting new sensor option to the TASMOTA family.  He’s not finished yet, either.  The most obvious challenge is trying to get PPS working (which should significantly increase the accuracy of the NTP server function) without making the ESP8266 completely unusable for any of the other options running on it.  Even without that addition though, this is still a useful addition to TASMOTA and is certainly a lot more fun to play with than most other sensors.

If the idea of an ESP interfaced to a GPS module tickles your fancy (as it did mine), there’s also Chris Liebman’s stand-alone ESPNTPServer project, which I’ve mentioned before in these pages and which now has its own PCB and 3d-printed case.

 

Advertisement

6 thoughts on “Using a GPS with TASMOTA (Part II)

  1. Great idea! I am having some trouble with the time server. When sensor60 9 is applied the gps data appears to stop – the numbers just don’t change. Sensor60 10 get the gps data updating again. I have tried this on 2 wemos minis and a neo6 and new8m gps module with the same result. This is just such a nice addition to the fabulous tasmota universe… Any ideas what the issue could be? Thanks.

    Like

    • Michael,

      That’s normal. Christian thought that it was asking too much of the 8266 to update the web and handle NTP requests at the same time, so he added an “NTP Active” message and disabled the GPS updates. Once you do the 60-10 you’ll find that the NTP message disappears (and, as you said, the GPS messages start updating as normal again).

      Thanks for reminding me of this (it did come up in my email exchange with Christian), I’ll update the text above to highlight that behaviour.

      I still think this is one of the neater additions to TASMOTA, though. 🙂

      All the best,

      -John-

      Like

      • So if I understand it correctly, you need to choose between time or location services – you can’t have both. Another issue I am running into is keeping the thing running in my RV. The idea was to provide time synchronization for a bunch of 8266 devices but I can’t keep the thing running. Is an internet connection required? It seems to run fine when one is available but not in the RV without.

        Thanks for your help Mike

        Like

  2. Michael,

    Not really either time -or- location. It would be more accurate to say time handling or location -display-. Your GPS will still be getting location information from the satellites, it just isn’t displaying it to the web page. You should still be able to get that information via MQTT.

    The issue with the RV (assuming that the ESP is connecting to your on-board router/AP and not bombing-out because it’s constant;y trying to talk to your home AP) is much more likely to be antenna related. I haven’t done any mobile testing with this set-up at all, so I don’t know how robust this code is in situations where it loses all satellites for any amount of time. It might be worth trying it with just the location display enabled to see whether that mode is reliable, or not.

    Let us know how it goes,

    -John-

    Like

    • Well it seems that MQTT is not sending data – status 8 is always the same location. If there is a better way to confirm please let me know. I am ready to leave this behind… I can get the location data from my OBD app (Torque). For time I’ll try something else. Thanks for you help in any case. Mike

      Like

  3. Mike,

    You really should contact Christian (the developer) directly with this. Contact him via GitHub:-

    https://github.com/Staars/Tasmota

    It would help him to get a handle on what exactly is going on if you could confirm that the location display works reliably when you’re on the road (to verify that there’s no issue with the antenna or losing satellites) when the NTP server is disabled. If you could also give some idea of the timing involved (ie:- does the NTP server typically quit immediately you start to move, or does it work for some amount of time and then quit). A more complete description of your mobile environment would help, too. Do you have a separate router/AP in the RV and, if so, what is it running? (there are some ARP issues showing up with OpenWRT and ESP devices — https://github.com/esp8266/Arduino/pull/6889 ). Are there any other mobile devices on the network that might be able to provide “ntpq” (or similar) output to show the status of the ESP NTP server? The more information, the better.

    Let us know how it goes,

    -John-

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s