USB GPS Functions!

[psyberjock]

I'm thinking of making a game using the Sony USB GPS. Does anyone know the functions for usbgps.prx? Of course it could also use the serial port GPS mod, but those functions are well documented and easy to find. I can't find functions for the usbgps anywhere. Help please!?

[johnmph]

http://moonlight.lan.st/2.71/kd/usbgps.html

+

0xA259CD67 = sceUsbGpsReset


Some reverse :

- Done with PRXTool to get the source in html format (http://forums.ps2dev.org/viewtopic.php?t=7182)

- I have get the stub file (sceUsbGps.S) also with PRXTool (option --stubs)

- Replace :

STUB_START "sceUsbGps",0x40010011,0x000A0005

by

STUB_START "sceUsbGps",0x00090000,0x000A0005

if you want use these stubs with Devhook (0.46 with 2.71 emulated) and Hen D.

- I have tried to port Deniska's gps_viewer (http://www.mphweb.com/file/20061216_0.zip, test it with Devhook (0.46 with 2.71 emulated) and Hen D) but it's not yet ok.


int sceUsbGpsOpen (void)

Checks the state of the GPS with a structured variable (0x5254 in memory (without relocation)) :

- if 0x5254[0x0] = 0x0 then it creates a event flag ("SceUsbGpsCommand") and 2 threads ("SceUsbGpsReceiveData" and "SceUsbGpsSendCommand") and starts them.

(SceGpsUSbSendCommand thread reads some value in a file)

After it sets 0x5254[0x0] = 0x1 (state = ready ?)

- if 0x5254[0x0] != 0x0 then it returns an error code.


int sceUsbGpsClose (void)

Close the GPS by deleting threads and event flag.


int sceUsbGpsGetData (void *a0, void *a1)

Checks the state of the GPS :

- if 0x5254[0x0] = 0x0 then it returns the error code 0x80244002.
- if 0x5254[0x0] = 0x1 then it returns the error code 0x80244004.

- if 0x5254[0x0] = 0x2 then it calls sceUsbAcc_internal_79A1C743 and if the functions returns an error code (0x80243701) so sceUsbGpsReadData returns this error code else returns the error code 0x80244005.

- if 0x5254[0x0] = 0x3 then it returns the error code 0x80244005.
- if 0x5254[0x0] = 0x4 then it reads the data of GPS according to the value of second parameter (it may also return the error code 0x80244006 or 0x80244010).


int sceUsbGpsGetState (u32 *state)

3 different states 0, 1 or 2 ?

- if the buffer passed in parameters is NULL, we get the error code 0x80244007.

- if address of the buffer is wrong (kernel address ?), we get the error code 0x80244006.

- if 0x5254[0x0] = 0x0 then state is not changed and an error code is sent (0x80244002 -> gps not open ?)

- if 0x5254[0x0] = 0x1 then state = 0x0

- if 0x5254[0x0] = 0x2 then it calls sceUsbAcc_internal_79A1C743 and if the function returns an error code (0x80243701) then state = 2 else state = 1.

So logically :

state | significance
-------|--------------
0x0 | sceUsbGpsOpen called successfully before but it needs other things
0x1 | ok ?
0x2 | error with sceUsbAcc_internal_79A1C743


int sceUsbGpsReset (u32 a0)

I don't know for what the parameter is used.


sceUsbGps_A259CD67

Same as sceUsbGpsGetData for the verifications then if the parameter is >= 3 then it returns the error code 0x80244007 else it will call :

sceKernelCpuSuspendIntr();

sceKernelPollEventFlag(); // According to the return value it may call after sceKernelClearEventFlag();

sceKernelSetEventFlag() :

lui $a3, 0x0
sll $a0, $s2, 2
addiu $v0, $a3, 0x4ED0
addu $a2, $a0, $v0
lw $a1, 0x0($a2)
jal sceKernelSetEventFlag
lw $a0, 0x10($s3)

sceKernelCpuResumeIntr();


int sceUsbGps_268F95CA (u32 a0)

If 0x5254[0x0] = 0x0 then it returns the error code 0x80244002 else if the parameter is >= 3 then it returns the error code 0x80244007 else it does that :

jal sceKernelCpuSuspendIntr
nop
move $a0, $v0
jal sceKernelCpuResumeIntr
sw $s2, 0x1558($s3) <- s2 = parameter and s3 the 0x5254 variable


int sceUsbGps_54D26AA4 (u32 *a0)

If the parameter is NULL then it returns the error code 0x80244004 else if the buffer address is wrong (kernel address ?) then it returns the error code 0x80244006 else it saves in the parameter the value 0x5254[0x1558].


int sceUsbGps_69E4AAA8 (void)

Same as sceUsbGpsGetData for the verifications but it doesn't take any parameters.

Then it gets some values with getTick, addTick, ... and saves them in a file (the name of the file is given with 0x5254[0x1558] ?).

For the filename we can find these strings in the prx :

flash1:/gps/init_data.bin
ms0:gps_init_data.bin
host0:./gps_init_data.bin


int sceUsbGps_9D8F99E8 (u32 a0, u32 a1)

It works when 0x5254[0x0] = 0x1 ! (maybe it must be called just after sceUsbGpsOpen ?)

addiu $v0, $s3, -0x1E
lui $t3, 0xF
sltiu $t2, $v0, 0x23B
bnez $t2, loc_00000880
ori $a1, $t3, 0x4240

mult $s3, $a1
sw $s1, 0x2AA8($a0)
mflo $t5
j loc_00000830
sw $t5, 0x2AAC($a0)

with s1 = first parameter, s3 = second parameter and a1 = 0xF4240 (without relocation).


int sceUsbGps_31F95CDE (void)

Same as sceUsbGps_9D8F99E8 but with this code :

lw $a2, 0x2AAC($s4)
lui $v1, 0x431B
ori $a1, $v1, 0xDE83
multu $a2, $a1
mfhi $t9
srl $s4, $t9, 18
sw $s4, 0x0($s2)

[psyberjock]

Sweet! That's more than I ever could have hoped for! Thanks a ton!!

I'm going to try your port of MapThis. I'm running 2.71SEC. I'll tell you what happens.

I have gotten the GPS to work in MGS:PO under devhook with 3.02, so I know it does at least work. I'm also looking for a copy of MAPLUS (UMD GPS map here in Japan) with no GPS unit since I already have one, but so far I only found it bundled with the receiver.

Doh, your file is only source... so far my toolchain hasn't installed properly because GCC is crashing when I try to patch it with the new psp toolchain.sh, so until GCC and the toolchain are working I'm stuck programming in LUA. Since .18 though I can access the PRXs from LUA, so I'm hoping I can still put together my game. Unfortunately that means I'll have to start from the ground up, and I was hoping to use Deniska's MapThis as a base. (I was also going to start with the GPS Viewer to make sure everything worked.)

I'll pass along my original idea and you can run with it if you want since I have no way of building PRXs without the SDK.

My first idea for the USB GPS and Deniska's MapThis was to build a custom PRX that would simply forward the USB GPS data to the sio and trick MapThis into thinking that the NMEA data was coming from the serial port. Then allow the reverse and make Sony software think that the serial GPS units are actually the USB GPS. It's probably beyond my programming skills, and like I said, I don't have the toolchain or SDK running, so I can't do anything with the idea. So, you and anyone else are welcome to use the idea. It might be easier than completely recoding the MapThis serial functions and it would definitely be more useful.

My idea for LUA is a Marco Polo kind of game. That's all I'll say for now. If I ever have to abandon the idea I'll discuss it in length and let someone take that over too, but for now I want to try my hand at it.

If you need any testing done, I have SEC and the USB GPS unit.

Good luck on your new build and I hope to hear from you soon.

[johnmph]

With the help of psyberjock, i have found two others functions :

0x54D26AA4 = int sceUsbGpsGetInitDataLocation (u32 *a0);

and

0x268F95CA = int sceUsbGpsSetInitDataLocation (u32 a0);

[johnmph]

The error was the PID for GPS, i used PID of chotto cam (0x282), the GPS PID is 0x283.

Now the state of the GPS is 0 when sceUsbGpsOpen is called after 1 after 2 after 3.

When state = 3, we can read data with sceUsbGpsGetData.

data[0] = 0x1244913 (when 3 satellites are found)
data[1] = 0x11E
data[2] = 0x12F0908 (when 4 satellites are found)
data[3] = 0x11
data[4] = ... (when 5 satellites are found)
data[5] = ...

(Each satellite send 2 data ? with 3 satellites to begin).

EDIT: i think that second parameter of sceUsbGpsGetData is the number of connected satellites

I continue research, many thanks to psyberjock for helping me.

sceUsbGps.S

Code: Select all

	.set noreorder

#include "pspstub.s"

	STUB_START	"sceUsbGps",0x00090000,0x000A0005
	STUB_FUNC	0x268F95CA,sceUsbGpsSetInitDataLocation
	STUB_FUNC	0x31F95CDE,sceUsbGps_31F95CDE
	STUB_FUNC	0x54D26AA4,sceUsbGpsGetInitDataLocation
	STUB_FUNC	0x69E4AAA8,sceUsbGps_69E4AAA8
	STUB_FUNC	0x6EED4811,sceUsbGpsClose
	STUB_FUNC	0x7C16AC3A,sceUsbGpsGetState
	STUB_FUNC	0x934EC2B2,sceUsbGpsGetData
	STUB_FUNC	0x9D8F99E8,sceUsbGps_9D8F99E8
	STUB_FUNC	0x9F267D34,sceUsbGpsOpen
	STUB_FUNC	0xA259CD67,sceUsbGpsReset
	STUB_END

pspusbgps.h

Code: Select all

/*
 * PSP Software Development Kit - http://www.pspdev.org
 * -----------------------------------------------------------------------
 * Licensed under the BSD license, see LICENSE in PSPSDK root for details.
 *
 * pspusbcam.h - Prototypes for the sceUsbCam library
 *
 * Copyright &#40;c&#41; 2005 John Kelley <[email protected]>
 *
 * $Id&#58; pspgps.h
 */
#ifndef __PSPUSBGPS_H__
#define __PSPUSBGPS_H__

#ifdef __cplusplus
extern "C" &#123;
#endif

#define PSP_USBGPS_PID				0x283
#define PSP_USBGPS_DRIVERNAME		"USBGps_Driver"


// Unknow

int sceUsbGps_31F95CDE &#40;void&#41;;									// ?
int sceUsbGps_69E4AAA8 &#40;void&#41;;									// ?
int sceUsbGps_9D8F99E8 &#40;u32 a0, u32 a1&#41;;						// ?
int sceUsbGpsReset &#40;u32 a0&#41;;									// ?

// Init

int sceUsbGpsOpen &#40;void&#41;;										// Open the GPS device
int sceUsbGpsClose &#40;void&#41;;										// Close the GPS device

int sceUsbGpsSetInitDataLocation &#40;u32 a0&#41;;						// ?
int sceUsbGpsGetInitDataLocation &#40;u32 *a0&#41;;						// ?

// Data
int sceUsbGpsGetData &#40;u32 *buffer, u32 *satellites&#41;;			// Get data from GPS &#40;size of buffer = 0x30 u32 ?&#41;

// State
int sceUsbGpsGetState &#40;u32 *state&#41;;								// Get GPS device state

#ifdef __cplusplus
&#125;
#endif

#endif

[johnmph]

You can download here a little program which uses GPS and shows some infos.

(Tested with devhook 0.46 + hen D with 2.71 emulated and usb and gps modules in ms0:/camprx (usbacc.prx + usbgps.prx))

This is the main code :

Code: Select all

int main_thread (SceSize args, void *argp)
{
 SceCtrlData pad;
 u32 oldButtons = 0;

 // Must be local ?
 u32 data[0x30];
 u32 satCount = 0;


 // Init psp
 SetupCallbacks();
 pspDebugScreenInit();

 pspDebugScreenClear();
 pspDebugScreenPrintf("\n\n\nPSP GPS Test\n");
 pspDebugScreenPrintf("------------\n\n\n");

 // Init usb
 printf("- Loading USB Accessory module...");
 if (moduleLoadStart("ms0:/camprx/usbacc.prx"))
 {
  printf("\terror\n");
  cleanExit();
 }
 else
  printf("\tok\n");

 printf("- Loading USB GPS module...");
 if (moduleLoadStart("ms0:/camprx/usbgps.prx"))
 {
  printf("\t\terror\n");
  cleanExit();
 }
 else
  printf("\t\tok\n");

 // Start usb drivers
 printf("- Starting USB BUS driver...");
 if (sceUsbStart(PSP_USBBUS_DRIVERNAME,0,0))
 {
  printf("\t\terror\n");
  cleanExit();
 }
 else
  printf("\t\tok\n");

 printf("- Starting USB Accessory driver...");
 if (sceUsbStart("USBAccBaseDriver",0,0))
 {
  printf("\terror\n");
  cleanExit();
 }
 else
  printf("\tok\n");

 printf("- Starting USB GPS driver...");
 if (sceUsbStart(PSP_USBGPS_DRIVERNAME,0,0))
 {
  printf("\t\terror\n");
  cleanExit();
 }
 else
  printf("\t\tok\n");

 // Initialize GPS device
 printf("- Opening USB GPS device...");
 if (sceUsbGpsOpen())
 {
  printf("\t\terror\n");
  cleanExit();
 }
 else
  printf("\t\tok\n");

 // Initialize data
 memset(data,0x0,sizeof(data));
 currentY = pspDebugScreenGetY();

 // Show main menu
 for (;;)
 {
  // Get state of GPS
  if (usbState & PSP_USB_ACTIVATED)
   sceUsbGpsGetState(&gpsState);
  else
   gpsState = -1;

  // Get data of GPS
  if (gpsState == 0x3) sceUsbGpsGetData(data,&satCount);

  // Read the buttons
  sceCtrlReadBufferPositive(&pad,1);

  if (oldButtons != pad.Buttons)
  {
   // Save the buttons
   oldButtons = pad.Buttons;

   // Exit if TRIANGLE
   if (pad.Buttons & PSP_CTRL_TRIANGLE) break;

   // Start / Stop GPS if CROSS
   if (pad.Buttons & PSP_CTRL_CROSS)
   {
    if (usbState & PSP_USB_ACTIVATED)
	 sceUsbDeactivate(PSP_USBGPS_PID);
    else
 	 sceUsbActivate(PSP_USBGPS_PID);

    sceUsbWaitCancel();

    // Get state of the USB
    usbState = sceUsbGetState();
   }
  }

  // Update display
  updateDisplay(data,satCount);
 }

 pspDebugScreenClear();
 printf("- Close program...\n");

 // Close gps
 sceUsbGpsClose();

 // USB Deactivate
 sceUsbDeactivate(PSP_USBGPS_PID);
 sceUsbWaitCancel();

 // Exit
 return cleanExit();
}

[psyberjock]

Just got back from Guam and I have to say, Wow! You've gotten a lot done! Great work!

I'm back in Osaka for most of today, but later I'm going to Hiroshima for about a week (Christmas and New Years with family). I think I'll still be able to do a bit while in Hiroshima.

I really appreciate the work you're doing. Once I get my dev system up and running or get things working well enough in LUA, I hope to use this info. Thanks a ton! I'll try your new app in just a couple of minutes.

[deniska]

johnmph, you rock!

I am gonna try to get one of those receivers and play with it...

Meantime, can you capture & post the data from the Sony gps?
What format does it come in? NMEA?

[moonlight]

Thanks for the info and for the nids ;)

[johnmph]

Thanks all ;)

Meantime, can you capture & post the data from the Sony gps?
What format does it come in? NMEA?

data[0] = 0x1244913 (when 3 satellites are found)
data[1] = 0x11E
data[2] = 0x12F0908 (when 4 satellites are found)
data[3] = 0x11
data[4] = ... (when 5 satellites are found)
data[5] = ...

(Each satellite send 2 data ? with 3 satellites to begin).

Value come in pairs (0 and 1 after 2 and 3, ...), the first value is higher than second value and these values are similar between pairs.

It's not NMEA code but i found NMEA code in boot.bin of maplus software :

Code: Select all

0x000A5C84: "$GPGGA,%02d%02d%02d.00,,,,,0,00,,,M,0.0,M,,0000"
0x000A5CB4: "$GPGSA,A,1,,,,,,,,,,,,,,,"
0x000A5CD0: "$GPGSV,%d,%d,%02d"
0x000A5CE4: ",%02d,%02d,%d,%02d"
0x000A5CF8: "$GPRMC,%02d%02d%02d.00,V,,,,,,,%02d%02d%02d,,,N"
0x000A5D28: "$GPGLL,,N,,E,%02d%02d%02d.00,V,N"
0x000A5D4C: "$PGRMM,Tokyo"
0x000A5D5C: "$GPGLL,%d%09.6f,N,%d%09.6f,E,%02d%02d%02d.00,A,A"
0x000A5D90: "$GPRMC,%02d%02d%02d.00,A,%d%09.6f,N,%d%09.6f,E,%.6f,%.6f,%02d%02d%02d,,,A"
0x000A5DDC: "$GPGSV,1,1,00"
0x000A5DEC: "$GPGSA,A,%d"
0x000A5DF8: ",%02d"
0x000A5E04: ",,%.6f,"
0x000A5E0C: "$GPGGA,%02d%02d%02d.00,%d%09.6f,N,%d%09.6f,E,%d,%02d,%.6f,%.6f,M,0.0,M,,0000"

and this boot.bin imports only sceUsbGpsOpen, close, getstatus and getdata so there is not functions to get NMEA data but maybe we must convert data received with getdata to get NMEA data.

[harleyg]

Nice information.

[psyberjock]

Good job so far. Good to see what happened with the Maplus files.

To me it looks like it is arriving in NMEA. It looks like the $GP### info is NMEA with some empty values. The N and E would be the North and East coordinates. When NMEA is passing empty values it will usually do so with a , or two and no info. Isn't that right Deniska? My guess is that the $GP### ($GPRMC $GPLLL $GPGGA etc) are different satellites sending partial data (i.e. poor signal strength). But I'm not sure. I'm still a beginner at programming for PSP and GPS. That data looks pretty good though. I would say that you're on the brink of getting coordinates.

Nice job. Still looking for a good cheap copy of Homestar. I'll let you know what happens.

Oh, HarleyG, I have some info for you. You're working on 3.02 OE with Dark_Alex right? I left a couple of posts about bugs I found on Max Console but there were so many noobs posting their trouble installing I'm not sure my bugs were seen by any devs. The region code hacks don't work on my Japanese PSP and the network settings don't save new connections. Maybe you already know that, but I just wanted to make sure. Thanks!

[harleyg]

I dont directly work on it, but i will let alex know.

[psyberjock]

Sorry to go off topic again, but the network connections problem of 3.02 OE was resolved after re setting my system to the default config. FYI

Back on the USB functions, no cheap copy of Homestar here in Hiroshima, so once I get back to Osaka tomorrow I'll find a used copy and buy it. Then we can see what functions it holds for us. Since it was the first software coded for the USB GPS, I'm hoping it's a bit sloppy and the functions are easy to decypher. We'll find out in a couple of days I hope!

Once I get it, I'll coordinate with JohnMPH and he'll most likely report any findings.

UPDATE: Found a copy of Homestar. May have more soon.

[deniska]

Did anyone try to run johnmph's program under 1.5 kernel?
I still don't have the Sony's GPS unit, but I did compile the code and tried to run in under 3.02 OE-B FW with 1.50 kernel and GPS prx modules from 3.02.
So far I only got the balck screen and shutoff after a few second..
Any suggestions?

[psyberjock]

Did anyone try to run johnmph's program under 1.5 kernel?
I still don't have the Sony's GPS unit, but I did compile the code and tried to run in under 3.02 OE-B FW with 1.50 kernel and GPS prx modules from 3.02.
So far I only got the balck screen and shutoff after a few second..
Any suggestions?

I can't compile it or I would have tried. I'm working on a similar program in LUA, but haven't finished yet. If you send me the compiled program I'll run it and tell you what I get.

Based on the code of the program, it is probably trying to load the GPS and when it doesn't work it just exits. You might try throwing in some error messages when it exits to be sure though.

[moonlight]

Did anyone try to run johnmph's program under 1.5 kernel?
I still don't have the Sony's GPS unit, but I did compile the code and tried to run in under 3.02 OE-B FW with 1.50 kernel and GPS prx modules from 3.02.
So far I only got the balck screen and shutoff after a few second..
Any suggestions?

you cannot expect to load usbgps modules in 1.50... (maybe decrypted, but they probably need specific imports from 3.0X modules)

why don't you run it in the 3.0X kernel?

[deniska]

Is this supposed to work under 3.02 OE-B kernel?
I get (800200D9) error then I try to run un-xploited EBOOT.pbp

[johnmph]

Is this supposed to work under 3.02 OE-B kernel?
I get (800200D9) error then I try to run un-xploited EBOOT.pbp

You can download here a little program which uses GPS and shows some infos.

Tested with devhook 0.46 + hen D with 2.71 emulated and usb and gps modules in ms0:/camprx (usbacc.prx + usbgps.prx)

He maybe works with 3.02 OE but don't forget to create a directory with usb and gps prx (ms0:/camprx (usbacc.prx + usbgps.prx)) or edit the source to load prx in flash.

It was compiled to use with HEN D and devhook 0.46 (user prx, maybe you must recompile with the rules of 3.02 OE homebrew, i don't have the 3.02 OE firmware so i don't know how to create homebrew for this)

[deniska]

Of course, I loaded both prx files in to ms0/:camprx (both were taken from 3.02 FW dump)..
Well, I guess I'll try to get 2.71, emulate it and run through hen-d, when I have time...
I'll let you know if it works for me..

Thanks for the response...

[deniska]

I figured out what my problem was:
Apparently my pspsdk version was too old, so even though it compiled w/o complaints, it crapped out on execution right away...
After I updated the SDK I was able to startup the johnmph's program in both 3.02 OE-A and 2.71 (via devhoor & hen-d).
I can see that it is loading the drivers, but can't test it further until I get my gps unit..

Will let you know if I find out anything new...

[deniska]

I finally got my hands on an actual Sony unit and played with the code abit..
My findings so far:

Things seem to get more animated if you pass bigger buffer as second param to sceUsbGpsGetData()...
The first buffer seems to be populated with a date/time data which always starts up as 04/15 23:59:48 and then goes on to 04/16/00:00:00 and so on...
The date/time data starts with a second byte in the first buffer param and can be read as ints.
I have a feeling that it's going to change to correct GMT/UTC time once it locks on satellites...

Below is a slightly changed johnmph's version, showing the running time:
http://deniska.dcemu.co.uk/bin/usbgps.zip (paste the link in to browser window)

I cant get any more data as I am sitting indoors at the moment..
will report if I find more meaningful stuff later...


[Edit]
As I expected, I got more data, once I wend outside:


So, the bytes 1,2,4,6,8,10 have year,month, day,hour,min,sec
byte 48 -stores # of satelites in view.
bytes 52,53,54,56 seem to store satelite PRN (ID), elevation(degrees), Azimuth(degrees), SNR (the higher the better) for the first satelite
byte 57 (0 or 1) is probably the signal quality flag...

Then bytes 60-65 would store the signal data for the 2nd satelite.. and so on...

The lat/lon data seem to be located somethere between bytes 16 and 48 : the numbers there start to jump when there is a fix on at least 3 satelites (with 6-9 satelites in view)...
I suspect that some of that data needs to be aligned in to doubles and/or long ints... I could not figure out the format of that block yet...




The rest remains unclear at the moment...

[johnmph]

Very good work ;)

You just made a little error in updateDisplay function :

replace

Code: Select all

 printf("\nData :\n------\n");
 for &#40;x=1;x<0x39;x++&#41;
 &#123;
  printf&#40;"%04d ",data&#91;x&#93;&#41;;
  if &#40;&#40;x&#41; && &#40;!&#40;x % 8&#41;&#41;&#41; printf&#40;"\n"&#41;;
 &#125;
 printf&#40;"\nData2 &#58;\n------\n"&#41;;
 for &#40;x=0;x<0x30;x++&#41;
 &#123;
  printf&#40;"%04d ",data2&#91;x&#93;&#41;;
  if &#40;&#40;x&#41; && &#40;!&#40;x % 8&#41;&#41;&#41; printf&#40;"\n"&#41;;
 &#125;

by

Code: Select all

 printf("\nData :\n------\n");
 for &#40;x=0;x<0x30;x++&#41;
 &#123;
  printf&#40;"%04d ",data&#91;x&#93;&#41;;
  if &#40;&#40;x % 8&#41; == 7&#41; printf&#40;"\n"&#41;;
 &#125;

 printf&#40;"\nData2 &#58;\n------\n"&#41;;
 for &#40;x=0;x<0x30;x++&#41;
 &#123;
  printf&#40;"%04d ",data2&#91;x&#93;&#41;;
  if &#40;&#40;x % 8&#41; == 7&#41; printf&#40;"\n"&#41;;
 &#125;

else you will have duplicate info (9 last bytes of data is in fact 9 first bytes of data2).

So with what you found, maybe data is GPS general infos and data2 is satellites infos.

Thank you very much for these infos ;)

[deniska]

Yeah, I corrected it some time ago..

basicaly the first buffer should be 48 bytes and the second one is 64 or more...

I'll try to look closer at bytes 16-47 in the first buffer when I have time..
I suspect that's where they store latitude, longitude, altitude and ,maybe ground speed.
Altitude, if exists in the feed, would only show up when there is a fix on at least 4 satelites. perhaps this would hint it's location in the buffer...

As a general observation, Sony's unit's reception quality is much worse than the holux's gpslim236. In my tests (puting both close to a window in my appartment) holux would report 8 satelites in view with a fix on 4 while Sony's PSP-290 would only "see" 2 satelites in view with no chance for a fix... :-(
This, of course, makes the hacking of it a big pain in the a$$, since I'd have to go outside and wait in the cold for 5 minutes (for it to get a fix), after each change in my code...

[psyberjock]

Yeah, I corrected it some time ago..

basicaly the first buffer should be 48 bytes and the second one is 64 or more...

I'll try to look closer at bytes 16-47 in the first buffer when I have time..
I suspect that's where they store latitude, longitude, altitude and ,maybe ground speed.
Altitude, if exists in the feed, would only show up when there is a fix on at least 4 satelites. perhaps this would hint it's location in the buffer...

As a general observation, Sony's unit's reception quality is much worse than the holux's gpslim236. In my tests (puting both close to a window in my appartment) holux would report 8 satelites in view with a fix on 4 while Sony's PSP-290 would only "see" 2 satelites in view with no chance for a fix... :-(
This, of course, makes the hacking of it a big pain in the a$$, since I'd have to go outside and wait in the cold for 5 minutes (for it to get a fix), after each change in my code...

Can you post the corrected PBP? I'm very eager to help figure out the long lat details.

Yes, the reception is not as good as other GPS units. However if you get it to connect outside first, then come inside, it will disconnect for a second, but once you place it back in the window it should reconnect fairly quickly and with a workable signal. It tracks much better than it connects.

I also just found an interesting file. If you look in the savedata directory of your PSP AND if you use Maplus (Deniska, you mentioned it before so maybe you have it) you'll notice a GPSLOG save directory. Inside is a plaintext .dat file that has a log of GPS satellite info. Might be useful in helping decipher these things.

EDIT: I think the file is used when the GPS is following your path. I checked the dates of the files and the were made on a day that I tried to use the path saving feature but don't seem to have been updated since then.

CONFIRMED: I couldn't tell from the hex of the .sfo because the text was in Japanese, but when I loaded the save in the PSP's save data viewer, I could see that it was the saved path data. Ashi-ato as it's called. Ashi = legs or feet / Ato = after.

I'll get a good lock today and save a nice long file. Then I'll paste the resulting GPS data here.

[deniska]

I fished out a few more fields .. here is the latest program:


http://deniska.dcemu.co.uk/bin/usbgps.rar (copy the link in to the browser window)

Basically, the date/time fields seem to be stored in 2-byte shorts bytes 0-12
Latitude, Longitude and Altitude stored in 4-byte floats starting @ byte 24
The speed& bearing (also floats) seem to be located @ bytes :40,44..
Azimuth is also a short, while other sat info seems to be stored in single bytes...
The only problem for me so far is that the longitudecomes out as positive 355.**** instead of -74.**** which is supposed to be around my area...
Perhaps some byte order is screwed up.. Could someone take alook?

The program requires usbgps.prx & usbacc.prx to be copied in to
ms0:/camprx directory and must be run under 2.71+ kernel (I tested it with 3.02 OE-A with 2.71 fw prx modules for usbgps)
It also dumps the data from both data buffers [48 & 160 bytes per cycle] in to test.dat file in the camprx dir.
viewer.c contains some code to parse the test data file for those who wants to dig in to this issue...

[psyberjock]

Well, I just tried out the newest version, and I must say, I think its pretty good. I'm not sure if the lat and long are completely perfect (mins, secs, etc), but I do know that the degrees for long and lat matched up for where I was. I'll email you the file.

I noticed that one satellite that popped up every now and then was # -121 (I think) and that seemed a little strange compared to the numbers of the other satellites. (like 23 and 17 or something ordinary like that)

I also generated a decent path in maplus of the same area. (I was walking up and down a street) Maybe you can compare them and come up with something a little more conclusive. I'll include it in the rar. Check your DCEMU PMs for the file.

EDIT:

I was just looking at the saved GPS data of MapThis and I noticed your satellite values are based on N. and W. Here in Japan they are based on N. and E. I wonder if that changes depending on your Hemisphere. That could then be changing the result of your latitude. If the GPS unit is somehow hard coded to recognize the Eastern Hemisphere and you're using it in the Western Hemisphere, you may only have to adjust the value by the appropriate amount to come up with the proper number of degrees.

It doesn't really seem to make much sense, as I'm explaining it, but I think there may be something to it. I can't believe it would be hard coded, but I think it has something to do with the way you're dealing with East and West. Especially since neither of us have problems with longitude and we're both in the Northern Hemisphere. It would be interesting to see what an Aussie would come up with. Any takers?

[deniska]

Actually, the lat/lon seem to be reported in decimal format..
Google out the tools/formulas if you need to convert the decimal part to min,sec,etc ...
In MapThis N/S E/W depend on the sign of the lat/lon values so 'E' would be displayed whenever the lon is positive...

[psyberjock]

Actually, the lat/lon seem to be reported in decimal format..
Google out the tools/formulas if you need to convert the decimal part to min,sec,etc ...
In MapThis N/S E/W depend on the sign of the lat/lon values so 'E' would be displayed whenever the lon is positive...

Ah, I see. Well, then what I was trying to say is that the whole numbers are correct, but I'm not certain of the decimal portions since I didn't write them down. The info would all be in the files that I sent you if you needed to check to be sure.

It's just strange that it worked for me but not for you. Even the altitude was correct and bearing seemed to be correct. At first the altitude seemed impossibly off, like I was 4000 above sea level, but then it suddenly looked correct. Perhaps I didn't look at the right numbers the first time or I didn't have enough satellites.

Anyway. Goodwork. I would say that it's a huge step in the right direction.

It even seemed to track and fix onto satellites better and faster than Maplus. Don't ask me why. It just seemed to see more and get a fix faster.

[deniska]

It's just strange that it worked for me but not for you. Even the altitude was correct and bearing seemed to be correct. At first the altitude seemed impossibly off, like I was 4000 above sea level, but then it suddenly looked correct. Perhaps I didn't look at the right numbers the first time or I didn't have enough satellites.

Well, there seem to be only problems with negative values..
People in japan would get both lat & lon positive...
The latitude calculation would require a stable feed from at least 4 satelites... so, chances are, you had a lock on only 3 satellites in the beginning.. plus, from my experience with the unit, because of generally weak reception, all values can deviate significantly from what they are supposed to be... maybe it has something to do with [MADE IN CHINA] sign on the back of the devicde :-)
Perhaps sony never designed it for "serious" navigation... or maybe it's just my bad unit...