How do I discern Maidenhead Locator from GPS lat long info.

[Darrel Taylor]

Does your GPS module put out more decimal places in the LAT/LON fields?

Since the edge of the square runs through the middle of the house, whether you're at the front window or rear window inside, you're always near the edge.
I imagine that if you were standing in the middle of your back yard, the reading would be more consistent.

One or two more decimals may improve the resolution considerably.
With only two decimals, a difference of .01 is a whole square.

    LAT           LON       Maidenhead   
Deg Min.Min   Deg Min.Min   1234567890
------------  ------------  ----------
 53° 25.83'    -0° 49.77'   IO93ok03kh  Back Yard
 53° 25.82'    -0° 49.77'   IO93ok03kg  Front Yard

It depends on whether your GPS gives enough data or not.
When recording NMEA sentences from my Android, it gives 6 decimals.

[tasmod]

Again you come to my aid Darrel.

I had limited the output by declaring the lat/lon secs as byte. Changed them to word and it becomes much more stable now. Datasheet says the decimal part is of variable length not fixed, so word should cover it.

I have also improved the start time to fix by finally fitting the Supercap to the gps module, something I should have done a while ago. This gives 48hr backup.

Don't groan but I now have another problem I'm going to look at. The time is now 2 seconds slow. Probably all the code plus the NMEA being slow too.
I'm looking at adding 2 secs then trigger display using DT_Ints on the next PPS pulse rise time. Feasible ??

[tasmod]

Hmmm no. I screwed that up somehow.

I realised it was saving DEC2 in the gps string so it would not be any different, so I changed it to DEC4 for now.

I changed the DEC2 in display line to DEC4 and I was getting 4 decimal places on Latitude displayed but Long went to all 0's. So locator was IO84 something.

Will spend some time on it.

[tasmod]

Now this is interesting.

If I mess with the size of any 'secs' variables it screws everything up. I can get Lat to 4 decimal places but not Long, it still goes to zero.

Right now I put the code back to original and got IO93ok03kg as the locator. I'm going to reduce this to the 4 pair for display just now, only to get more on screen.

I put my phone with the app running next to the gps antenna.
The phone was showing a fix to 16 sats and gave IO93ok03lh with 53 25.8266 and 0 49.7704 as the co-ordinates.

For mine. When I had the 4 decimal places shown on the display it showed 25.8246

[tasmod]

It's between DEC4 in gps string and Aint in locator code.

I can get the display right but not the locator using DEC4 in the gps string and DIGs in the display LCDOUT.

I can get the locator right but not the position display if I just use latsecs as the variable in the gps input string.

Not knowing how Aint works I'm stumped now.

EDIT:

Just walked the property with the phone. Wow, those squares are small. I get LG, LH, KG, KH and guess where the crossover is, yes, right around the room where the unit is. I think I'll stick to DEC2 for now

[Darrel Taylor]

With DEC4 change it to this for the Longitude ...

;----[convert Longitude Sexagesimal to Decimal Degrees]-------------------------
Aint = LonMinDec : GOSUB ItoFA    ; decimal portion of Minutes
Bint = 10000 : GOSUB ItoFB        ; divided by 10000
GOSUB fpdiv
Bint = LonMin : GOSUB ItoFB       ; add whole portion of Minutes
GOSUB fpadd
Bint = 60 : GOSUB ItoFB           ; divide by 60
GOSUB fpdiv
Bint = LonDeg : GOSUB ItoFB       ; add degrees
GOSUB fpadd
IF LonDir = "W" THEN              ; if west of Prime Meridian
    @ MOVE?FF32 AARGB2, BARGB2    ; copy Float AARG to BARG
    Aint = 0    : GOSUB ItoFA     ; subtract from 0 to negate
    GOSUB fpsub
ENDIF

Bint = 180  : GOSUB ItoFB         ; add 180
GOSUB fpadd

And do the same thing with the Latitude.

[tasmod]

That was it.

Using "DEC4 latsecs/lonsecs" in the gps string and changing to Word size variables uses the 4 decimal places.

Interestingly using battery power for the unit, I got exactly the same reading as the phone app moving the unit around.

Thanks Darrel.

I'm now looking at making the time display more accurate to the second epoch using DT_Ints