For anyone else who has the aforementioned GPS and wishes to use the built-in data logger: I've put together the following utility to control and extract extract data from the logger. It's a command-line utility, with a readme included. Also, it will export to gpx, which can then be imported by Maemo Mapper. It requires python and python2.5-bluez. The first time trinegps is run, it may ask for a password to create /dev/rfcomm1 if it doesn't exist already.
The python class on the backend is more fully-featured than the command-line interface; if there's any interest, I can put together a bit of documentation on how it works.
Finally, a disclaimer - the code is fairly rough in places, and there may well be unexpected crashes. However, it's working well enough for me, and shouldn't do any damage to either the NIT or the GPS.

Quick howto:
I'm assuming the GPS and the NIT are already paired, and that nothing else is accessing the GPS (ie. Maemo Mapper is not running).

1. Unpack trinegps to a location of your choice
2. Go into that folder and enter:
3. If that works, try
This will store the bluetooth settings so you don't have to enter them every time.
4. Still here? Time to switch on some logging.
5. Take the GPS for a walk round the block to get some data in there.
6. Finally. Dump the track back out:
You should then be able to import the logged data back into Maemo Mapper with Track\Open...

Any problems, let me know, and try the readme - there are more options than mentioned above.

Addendum: I've registered http://code.google.com/p/trinegps for this. The only difference between 0.1 and 0.1.1 is the addition of a little extra code to support Windows usage; as far as Tablets are concerned, it's identical.

Okay... I've updated trinegps with better handling of large transfers, better usage of stdout/stderr (try -v!) and a few general bugfixes. Anyone out there actually using this at all? Any feedback is welcome.

Well, there have been a couple of downloads, so I'll keep going... trinegps 0.1.3 is out - this fixes the (ahem) slight problem when exporting to GPX for tracks in the Western or Southern hemispheres, along with better thread handling.

Any idea if this will work with other data loggers?

It's highly unlikely to work with any other loggers - from what I've figured out, most loggers use proprietary sets of extensions to the NMEA0183 protocol. TrineGPS was specifically written to work with my own GPS, which uses the $PEMT extension group. There's a possibility it might work with other Emtac models, but it's not been tested. If there's any protocol documentation for your GPS, I can have a look at a conversion.