Maybe you can’t get there from here, but I’m trying!
We (my son and I) are trying to build a GS tracking device that will show my location, relative to the numbered tree rows, within my Orchard. The rows are 15’ apart and run almost due north and south. What I’m looking for to start with is to have the display show 21/22 when I am driving between rows 21 and 22.
What we have done so far is to drive up and down (N/S direction) the middle of rows 21/22, 22/23, 23/24, 24/25 and 25/26 collecting the longitude and latitude on an SD card. Using row 21/22 as our A-B line we are trying to use a 15’ offset to have the LCD display show what row we are currently driving in: currently only within rows 21 and 26. When we drive east of row 20/21 the LCD displays EAST and when we are driving west of row 26 it reads WEST.
Currently we are getting mixed results with our row ID (i.e.21/22)…It always gets East and West right. But within the rows it is a mix of correct row reading, incorrect row reading and Blank. Here is a picture of the display. Speedometer works fine.
The hardware is:
Arduino R3 2560
Adafruit Ultimate GPS shield
Adafruit Standard LCD 20x4 Product 198 with i2C/SPI back pack
QGP waterproof 28dB Gain Antenna (Amazon)
Calculation Logic:
For this particular orchard, the rows are parallel and only 600 feet long with a total of 81 rows. Basis for our calculations is Y=aX+b to tell which row it’s in currently.
Assumption: Since it’s so close to vertical, say the slope is 0. When you calculate it out, there are three zeros after the decimal point before a number. It’s not going to change the answer to include this tiny number. So when we get rid of the aX we just have an offset equation. Is this valid?
I know the linear equation method isn’t really the best way to go with GPS data, but I was thinking the rows are short enough, parallel enough and vertical enough to treat them as rectangular. For such a small area can I make these assumptions? Should I use another method on the data? Is it the hardware limitation of the GPS I’m running into? Are there any tricks to improve our accuracy? Is there a more accurate GPS module I should be looking at?
Any and all suggestions appreciated.
Jan 3 gps-row-test-2018A.ino.ino (8.77 KB)