psyberjock wrote:
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...
Well, I know it's not just your unit. I definitely have a little twitch on my coordinates even when I'm sitting down with the PSP resting in my lap. I think the size and shape restrict the antenna size, so it might work better with a bigger/better antenna. I'm pretty sure they're using a patch antenna and that's only good for things directly above us.
I may eventually look into installing an external antenna port, but I'm not bored with it enough (nor rich enough) to start taking it apart yet. Especially since there is a lack of screws and the thing is all plastic. While I'm pretty sucky at software, I'm much more comfortable with hardware. That being said, I'm no electronics engineer either. Just more experience with it.
Well, I'm off to bed. Good luck with the negative values. I'll check back in the morning.
Well, I know it's not just your unit. I definitely have a little twitch on my coordinates even when I'm sitting down with the PSP resting in my lap. I think the size and shape restrict the antenna size, so it might work better with a bigger/better antenna. I'm pretty sure they're using a patch antenna and that's only good for things directly above us.
I figured out yet another field:
HDOP (Horizontal Dillusion of Presision) is stored in a float, starting @ byte 16 of the first buffer..
Basically, the bigger the number in that field -the smaller chance that you get a trustworthy coordinates reading...
I would discard any readings with HDOP>5....
[disclaimer]Ok, I did take a C++ course for comp sci majors when I was in university, so I can follow most of what I see, I just can't write it from scratch. That being said, I'll ask some questions about what I saw. Please don't get annoyed by my ignorance.[/disclaimer]
I can't figure out what this viewer program is doing. I see some numbers passed to floatBuffer() and those numbers are then spit back onto my screen. However the file that I use doesn't exactly matter if it's the real file or just a dummy. The same values are spit onto the screen. Am I supposed to be changing the values that get passed to floatBuffer? If so, where do those values come from? My test.dat doesn't contain ascii, so I can't really trust copy and paste to input the proper information. I also don't see any fileio, that I recognize, that would be automatically importing the values from test.dat. I would love to parse my test.dat and try to help figure out the latitude bytes, but I'm not sure what I need to do to get this going.
Please help?
values passed and seemingly useless file required:
You can comment out those test print lines - I was just trying to to print buffers for those numbers and try to figure out why I would get 355.**** instead of -73.****
make sure that test.dat is not empty and is in the same directory as your executable..
Also, there might be a filter there which checks for non-zero value in the 16th byte, displaying only buffers with "good" data.... (Sorry, this code keep mutating and I am not sure which version I have uploaded)
So if your GPS unit did not get a good fix on satellites, you will not be seeing anything.... just look for "continue" in the code and comment out the condition...
deniska wrote:You can comment out those test print lines - I was just trying to to print buffers for those numbers and try to figure out why I would get 355.**** instead of -73.****
make sure that test.dat is not empty and is in the same directory as your executable..
Also, there might be a filter there which checks for non-zero value in the 16th byte, displaying only buffers with "good" data.... (Sorry, this code keep mutating and I am not sure which version I have uploaded)
So if your GPS unit did not get a good fix on satellites, you will not be seeing anything.... just look for "continue" in the code and comment out the condition...
Thanks. I got it working. The only problem I've come across since is that the program seems to stop collecting data before I can connect to more than 2 satellites.
It captured 928 frames then cut out. Perhaps I did something to cause it to do so, but I don't think so. One reason this might be happening is because it takes 4-5 frames in one second.(Assuming the seconds are actually recorded correctly since the rest of the date isn't.. probably cause only 1 satellite and no fix) Maybe the memory just fills up. Take a look at the time stamps:
Is there anyway to slow this to 1 or 2 frames a second or allow the file to collect more than 928 frames? Now that I got this viewer working, I can start checking bytes if I can get them captured. I'll go back out tomorrow and try to get a lock as soon as possible. If I can connect to a good 6-8 satellites maybe we can figure out all the bytes for sure. My only problem now is capturing more frames. Any idea why it would have stopped before I turned off the program or why I just ended up with so many blank bytes even though I was connected to 5+ satellites for at least 10 minutes?
Something is definitely wrong with the test.dat file creation and data capture. I think that when the viewer program gets enough fixes for the lat and long to be recorded, the test.dat file starts recording all 0's. Something is happening between recording satellites in view to the file and the actual lat and long being generated that is messing up the data.
If it was in the viewer program alone I could maybe fix it and continue on my merry way, but I can't seem to get the PSPSDK to compile under cygwin so I can't recompile the actual GPS program to try and record data properly. Can you help?
I'll try to find the part of the code that is wrong so we can come up with a solution, but you'll probably find it before me. It's probably something small.
UPDATE: Maybe it's not in the program. I don't see anything that is glaringly wrong. I saw your file that's named Denis and it has everything that is should have it seems. But I don't know how else to explain that my GPS data goes from seeing 6 satellites to being completely blank and just full of 0's.
Wow, good job. I never would have thought to try a newer prx. I was also using the 2.71 prxes. Looks like we'll all have to switch to the newer prxes. Thanks!
Is there any pinout information for the PSP-290 out there?
I saw some photos on a Japanese Boy's Blog of a dissected PSP-290.
It appears the power for the unit is coming from one of the posts securing the unit to the PSP. The photos are somewhat blurry, and the google translation doesnt convey very well why he took it apart. He seemed to be unable to put it back together though....
Also, is there a pinout information of the PSP usb port?
"..nothing is more common than unsuccessful men with talent...unrewarded genius is almost a proverb....the world is full of educated derelicts. Persistence and determination alone are omnipotent... "Calvin Coolidge
30th president of US (1872 - 1933)
I would be interested in seeing a link to that site you mentioned.
As far as the power is concerned, it actually comes from the pogo pins just on either side of the usb adapter. The screwpost is only for attaching it to the psp.
From what I understand, the usb port is a standard usb port. You should be able to find a pinout on google quite easily. It should be standard USB 2.0.
psyberjock wrote:I would be interested in seeing a link to that site you mentioned.
As far as the power is concerned, it actually comes from the pogo pins just on either side of the usb adapter. The screwpost is only for attaching it to the psp.
From what I understand, the usb port is a standard usb port. You should be able to find a pinout on google quite easily. It should be standard USB 2.0.
"..nothing is more common than unsuccessful men with talent...unrewarded genius is almost a proverb....the world is full of educated derelicts. Persistence and determination alone are omnipotent... "Calvin Coolidge
30th president of US (1872 - 1933)
Deniska explains pretty well how to find the data, and types,
but here is a link to the source: http://en.pudn.com/downloads100/sourcec ... 18_en.html
You have to join a forum and share source first, but the other links in this thread are dead, and Deniska has lost the code.
This is the greenscreen app for testing the PSP-290.
This might save anyone headaches if they were to try to use it now,
To get it working with 3.52 M33, I had to load the two USB modules from flash the way it's done in the chotto cam sample in the famous giant chotto cam thread.
Art.