Skip to main content

How well does JSR179 / serial port access work?

8 replies [Last post]
jkp
Offline
Joined: 2009-09-06
Points: 0

Further tries with gpsmid - this time a couple of questions about JSR179 LAPI support and serial port support. I have gotten a GPS fix via JSR179 a few times, but it seems I can get it only sometimes and it's only a one-time fix, and the location doesn't get updated.

1) Regarding JSR179 and serial GPS support - how well tested is the JSR179 serial support? Is there some other program using JSR179 which is known to work on phoneme, so I could test with it?

2) Regarding serial port support from j2me - should this work? I seem to get different results with comm:COM7:baudrate=4800 (which is where the GPS is) from comm:COM6:baudrate=4800 (which gives an error opening COM6)

3) I found a page about serial port support at http://www.cs.kuleuven.be/~davy/phoneme/?q=node/16 - if there are problems with JSR179 or comm:COM*, should I try this instead?

For details on the device & settings, see http://wiki.openstreetmap.org/wiki/Software/Mobilephones#JavaME_Midlets_... for details on the device.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jkp
Offline
Joined: 2009-09-06
Points: 0

Marking as unanswered, as there are some suggestions for solving, but the problem doesn't resolve based on those alone, some further input would be needed.

davyp
Offline
Joined: 2007-01-03
Points: 0

I am aware there are issues with my JSR179 implementation. The buffering for communicating
with the serial port could indeed be an issue. I remember having to finetune the internal size, or
it would not work on my device either.

I was thinking about using the GPS Intermediate Driver to have a more stable implementation:
http://msdn.microsoft.com/en-us/library/bb202086.aspx

However, that would mean JSR179 would no longer "work" on older systems like Windows
Mobile 2003, because that feature was only introduced in Windows Mobile 5.

Davy

davyp
Offline
Joined: 2007-01-03
Points: 0

(1) As with all my builds, testing is limited as I only have an old pda and a bluetooth gps dongle
to test with (I don't have a device with built-in GPS to test with and it has been a while since I
tested the implementation).

The JSR179 implementation I made uses the Bluetooth Serial Port Profile to access the NMEA
sentences and parses these sentences into the structures that JSR179 provides. The lapi.cfg file
is pretty simple. It is a one-line configuration file:

SerialPort =

And the is the same string you would use to open a serial port:
http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/io/C...

I guess the implementation could be improved in terms of error recovery, for example by
retrying to setup a connection when the GPS device gets disconnected.

(2) That depends of course on which serial port you have configured your GPS. For my Bluetooth
GPS device this would be "comm:6;baudrate:9600;bitsperchar:8;stopbits:1;parity:none"

(3) For midlets with phoneme feature you should not use the rxtx serial port backend.

Davy

jkp
Offline
Joined: 2009-09-06
Points: 0

Thanks for the info. It may be the device's GPS receiver has some pecularities triggering something in phoneme's JSR179 support. With a program called GpsTacho, the speed is shown as a multiple of light speed, while a previous hardware of the same resaler worked OK. Now I got some success with gpsmid however: When I connect gpsmid to the GPS receiver via TrekBuddy's GpsPort helper app, I do seem to get good results. Details at https://sourceforge.net/apps/mediawiki/gpsmid/index.php?title=Platforms#...

It would be nice and easier than the helper app solution if phoneme supported GPS via JSR179 also on this device. Do you have any suggestions on what I could do to debug JSR179 support so it could be made to work also on this device? I think I'll try different baudrates at least, as GpsPort didn't ask for a baudrate parameter.

jkp
Offline
Joined: 2009-09-06
Points: 0

I did some more tests with the parametres in serial port open, with blocking=off;autorts=off;autocts=off parametres. No luck yet; it seems that gpsmid hangs in reading the serial port either via serial Connector.open(url) or JSR179. When accessing the serial port directly, gpsmid hangs after the open and then gets "unhung" occasionally for a while. When using JSR179, the hang doesn't happen at open but at app close or ending use of JSR179.

One minor detail about the syntax - you say

"SerialPort =

And the is the same string you would use to open a serial port:"

I made a partially-working (gets sometimes a first GPS fix, then stops) lapi.cfg based on the one in distribution, and there the syntax was a bit different, : is used instead of = as described in http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/io/C... and the com port identified by just a number compared to COM7 in other sources.

Semi-working lapi.cfg I used, based on the one in the distribution:

SerialPort = comm:7;baudrate:4800;bitsperchar:8;stopbits:1;parity:none

However, lapi.cfg based on the Sun's doc would be:

SerialPort = comm:COM7;baudrate=4800;bitsperchar=8;stopbits=1;parity=none;blocking=off;autocts=off;autorts=off

(or com7)

Both seem to fail in the same way - when stopping JSR179 access by stop gps menu entry or application exit, the application hangs and runmidlet must be killed.

Message was edited by: jkp

davyp
Offline
Joined: 2007-01-03
Points: 0

I don't think the port identifier is standardized, but I could be wrong. I guess I relied on
examples on websites that just used a digit to identity the comm port:

http://www.ibm.com/developerworks/wireless/library/wi-jio/?S_TACT=105AGY...

But you are right, I should support both formats. For the time being, only the digit
version is supported, but it should not be to difficult to fix.

Given that JSR 179 and using the serial port directly both result in similar problems, I
guess there is something odd going on with the native serial implementation in
combination with your device and settings. I am guessing that reading from the serial
port is blocked perhaps due to a buffering issue, but I am not sure. If I could only
reproduce the problem :-(.

Do you have other applications that can read the serial port without problems with
those settings? I have an application called GPS Info that I use for that purpose.

Davy

jkp
Offline
Joined: 2009-09-06
Points: 0

"Do you have other applications that can read the serial port without problems with
those settings? I have an application called GPS Info that I use for that purpose."

I use a native WinCE serial port socket daemon which correctly reads the serial port, and with which I can get gpsmid working fine. That program can be downloaded from http://www.trekbuddy.net/forum/viewtopic.php?t=1331 - the source doesn't seem to be available right now, some SVN server problem apparently. The surprising thing to me is that it doesn't ask for a baud rate at all, so I don't what baud rate it's using. Is there a registry entry in wince or something? I'm not quite familiar with wince. However, getting a first GPS location via lapi.cfg seems to suggest that the baud rate is right, and the problem might well be some kind of blocking/buffering issue as you say. And there's a third-party GPS program which says the baudrate is 4800 and port is com7, and also GpsTacho (wince native program) works with com7/4800, so I think the setting is correct.

I just tried to find a j2me midlet to see if they work. Pollicino and bbtracker from getjar.com seem to start on phoneme and seem to exhibit similar symptos to gpsmid, ie. hanging on exit.

jkp
Offline
Joined: 2009-09-06
Points: 0

Any suggestions on how to progress with this? I tried again with the newest PhoneME release, and am having the same problems. Things work with the gpsport helper program, but it would be easier to not have to use the porgram. Might it be something with opening the serial port for read or read/write, or how could I instruct PhoneME with different buffering options if buffering is the issue?