Category: GPS / GIS

Categories
GPS / GIS

TomTom One V3 GPS Pause Revisited

After being side-tracked onto another project I got back to the TomTom datalogger application and believe I’ve solved the problem with intermittent pauses in the GPS output from /var/run/gpsfeed. The problem ended up being easy to repeat on the bench and in fact I could see the same pauses doing a cat /var/run/gpsfeed from the serial console but only when my application was running in the background. It only occured when my main loop was set to check for new input every 200mS, when I put it up to one second everything started working smoothly.

The TomTom is set to output a GPS fix approximately every 800mS so 200mS seemed like a fairly appropriate value to keep the buffers flushed and everything running along smoothly, but instead it appears the driver may have a problem if the buffer gets emptied too often. I’m using C++ streams so just have a fairly typical while stream.good style loop to process any new data received on a character basis and go ahead and process the data when a new $GPRMC / $GPGGA pair has been received. It will need some field testing but fingers crossed problem is now solved.

Categories
GPS / GIS Hardware

TomTom One V3 GPS Feed

Doing some testing on a TomTom datalogger application I’m writing I’m finding some data gaps in the NMEA GPS output both from /var/run/gpsfeed and /var/run/gpspipe. At first I suspected the feed may not be sending out NMEA data during a loss of coverage, however recently observed the TomTom tracking OK during a period the problem was occuring. It is possibly because I’m attempting to log all data so that I can post-process the data for reporting and KML generation. To assist hearing when the data feed stops without taking my eyes of the road I’ve attached a piezo buzzer and diode to a DB-9 connector that seems to give an audible but not too annoying sound at 115200 bps.

tomtom3

Categories
GPS / GIS Linux

TomTom One V3 console access

By default the TomTom One doesn’t give console access over ttySAC0, instead it looks like a plug & play daemon periodically polls the port possibly for a GPRS modem. A few attempts at allowing access to the shell with TomTom Navigator running concurrently failed so rather than modifying the ttpnpd file that I use to launch my main application I created a file called SerialTTY.cap in the SDKRegistry directory:


Version|100|
AppName|SerialTTY|
AppPath|/mnt/sdcard/bin/|
AppIconFile|tty.bmp|
AppMainTitle|Serial TTY|
AppPort|2001|
COMMAND|CMD|cmd|tty.bmp|SerialTTY|

And in the bin directory created a small shell script called SerialTTY to perform the redirection between the shell and the /dev/ttySAC0 port:

#!/bin/sh
cd /mnt/sdcard
stty -F /dev/ttySAC0 115200
sh < /dev/ttySAC0 > /dev/ttySAC0 2>&1

All works well and after the initial period I didn’t see any more interference from the plug & play daemon. I noticed in the /bin directory (on the internal filesystem) that the lrz binary is provided and successfully used it to perform a zmodem file transfer. In conjunction with a few scripts this may be a more convenient way to transfer new binary images to the device rather than going through the reboot required when using the USB mass storage interface.

Categories
GPS / GIS Hardware

TomTom One V3 RS232 Interface

The RS232 cable was attached to the TomTom and all works fine with the serial interface. I also attached the suspected audio line out to pin 1 on the cable and the line input to pin 2 in case they prove useful in the future. They are normally RTS/CTS on the PmodRS232 board but it has removable jumpers that will provide convenient access to the lines.

Telemetry2U IoT Docker Projects

Telemetry2U IoT Microsoft Profile

Telemetry2U LoRaWAN Kaggle Profile

List of IOT / LoRaWAN companies

https://www.cylex-australia.com/company/telemetry2u-pty-ltd-24829792.html

Categories
GPS / GIS Hardware

TomTom One V3 connector pinout

The TomTom data connector uses a non-standard 2.5mm audio style jack that has four poles on the inside and two around the outer sheath. I have been unable to find a convenient source for the connectors so will remove and replace with a cable to mate with a Digilent PmodRS232 adapter to perform 3.3V TTL to RS232 conversion during debugging. I’ve done some work with a scope and resistors to determine the pin functions for at least the pins I require. The connector viewed from the top of the PCB looks like this:

Pin functions were determined as:

1 = RX data in for UART ttySAC0, default rate = 115200, 3.3V TTL.

2 = Power output for accessory, I tested sourcing 100mA will no ill effects on unit.

3 = TX data out for UART ttySAC0, default rate = 115200, 3.3V TTL.

4 = Measured 1.4V output, most probably an audio line output.

5 = When connected to ground via a 1K resistor the unit reports an external line input, so presuably that’s what it is.

6 = Ground.

7 = Function unknown but when connected to ground via a 10K resistor it caused an immediate shutdown of unit.

Categories
GPS / GIS Linux

TomTom One V3 buzzer output

I was just attempting to use the /dev/buz device on a TomTom One V3 for debugging purposes but the test code below failed on the attempt to open the device driver despite trying a few combinations of open flags. The device seemed to be installed OK but I noticed in the Barcelona kernel source it is written for exclusive access so presumably the main ttn application opens it. I need the navigator application open while debugging my app so tomorrow will take a look at getting something out of a serial port.

int fd = open("/dev/buz", O_RDONLY | O_NONBLOCK | O_NOCTTY); 
cout << "fd: " << fd << endl; 
int result = ioctl(_IO('U', 3), 0); 
cout << "result: " << result << endl; 
sleep(10); 
close(fd); 
exit(0);
Categories
GPS / GIS Hardware

UBlox UTC Time

I’ve just discovered a time sync error with one of my embedded GPS systems that is part of a wireless system for performance monitoring of sporting events. One of the devices that sends a UTC timestamp to establish the start of an event was sending a time that appeared to be over 10 seconds out of sync with the GPS transmitters attached to participants in the event. Further testing against a known time reference uncovered the exact time difference was 15 seconds in the future which is the current difference between UTC time and GPS time.

It appears the UBlox LEA-4H and LEA-4S GPS receivers send out GPS time in their NMEA sentences until they have received a valid almanac and this is the first occasion when the GPS transmitters didn’t have time before the start of the event to receive an almanac. The UBlox receivers only appear to have the necessary data output to discriminate between GPS and UTC time in the versions of their firmware loaded into GPS modules specifically targetted at timing applications. The embedded host computer that receives data from the wireless network has an Internet connection so the solution in this case will be to sync the embedded PC clock to an Internet time source so that future times received can be treated as GPS time. Maximum wireless network latency is guaranteed to be less than 10 seconds so this should be a reliable solution.