Navigation systems to use in a boat is very expensive if you want a decent screen size and a nice user interface.
Example: GPSMAP® 720/720s https://buy.garmin.com/shop/shop.do?pID=37719#specsTab
In addition I would need a svinger for the sonar and a map covering my area, an additional $400 or so.
Total cost: $1800
For me the solution is obvious: Buy a cheap chart plotter / sonar and hook it up with a small cheap netbook via a RS232 to USB converter. And then make a chart plotter program.
Cuda 350 chart plotter / sonar, svinger included: http://www.cabelas.com/p-0065672020560a.shtml
I could probably get a cheap netbook for around $250, and a RS232 to USB for $20.
The maps I can grab for free.
Total cost: $480
Actually this is both cheaper aand a better solution for me as I will bring the netbook with me and dont have to sit in my boat to do trip planning and plot waypoints.
The Cuda sends GPS data using the NMEA 0183 protocol: http://www.tronico.fi/OH6NT/docs/NMEA0183.pdf
Longitude, Latitude is WGS 84, Degrees, Minutes and fractions of a minute. In my program I convert it to degrees and fractions of a degree and then convert it to an integer by ignoring the decimal point. The number of decimals is constant.
So far so good. But I ran into problems when trying to figure out how to calculate the distance between two Longitude, Latitude coordinates.
My math skills are really getting rusty.
I found this on Wikipedia: http://en.wikipedia.org/wiki/Great-circle_distance
Looking at the 'distance between two airports' example.
The degrees to radians part is easy, but the second formula is Greek to me.
Does anyone know what this formula means, example please?
Currently I assume the earth is flat (back to the middelages), but uses coordinates of the nearest place to reduce the error.
You can get what I have so far here: https://fbedit.svn.sourceforge.net/svnroot/fbedit/RadASM30/Release/Masm/Projects/ShowMap/ShowMap.zip
Note that the map tiles has been blured as they are copyrighted material.
Use the Trip Log / Replay Trip to see me race around my neighbourhood with my car. Actually the replay is x10 so I am not driving very fast. The speed shown is in knots.
If there is any interest in this project I will post the sources when I am done.
KetilO
This might be of help to you....
http://www.movable-type.co.uk/scripts/latlong.html
(But if you get lost it isnt my fault :bg)
Thanks a lot oex
Spherical law of cosines:
d = acos(sin(lat1).sin(lat2)+cos(lat1).cos(lat2).cos(long2−long1)).R
This one I can understand. Now I will be programming all night long translating it into fpu instructions.
KetilO
I use the following spheroid model. At some level you have to make some compromises, because the global is pretty ugly
It works well for short distances, probably less than 35 KM, I use it for proximity testing geofences.
The value of PI that I typically use is the one specified by the GPS constellation and used by the receiver. I could use the WGS-84 datum for the global too, but the math gets messier because it's an ellipsoid not a sphere.
#define PI (3.1415926535898) // ICD-200
#define DEG_TO_RAD (PI / 180.0)
#define RAD_TO_DEG (180.0 / PI)
#define EARTH_RADIUS (6371000.0)
#define EARTH_CIRCUM_METRES (EARTH_RADIUS * 2.0 * PI)
#define DEG_TO_METRES (EARTH_CIRCUM_METRES / 360.0)
//****************************************************************************
// Measure short distances, assumes the Earth is a spheroid and readily
// flattened. In reality it is an ellipsoid, and this computation is
// overly simplified.
// Input decimal degrees, output metres
double ComputeDelta(double latA, double lonA, double latB, double lonB)
{
double delta_lat;
double delta_lon;
double delta;
delta_lat = fabs(latA - latB);
delta_lon = fabs(lonA - lonB);
delta_lon = delta_lon * DEG_TO_METRES * cos(((latA + latB) / 2.0) * DEG_TO_RAD);
delta_lat = delta_lat * DEG_TO_METRES;
delta = sqrt((delta_lon * delta_lon) + (delta_lat * delta_lat));
return(delta);
}
//****************************************************************************
In reality you can probably loose the fabs()'s because the squaring will remove the sign, but I often want to know the Northing and Easting difference. If you just want to compare the current location to find the nearest waypoint you can loose the square root and perform a simple magnitude test against the table of waypoints. On a Intel processor running at a few gigahertz this probably doesn't matter, but on small embedded micros you want to avoid as much floating point math as possible.
Here (http://www.masm32.com/board/index.php?topic=7849.msg57648#msg57648) is some "Great Circle" FPU code I wrote. It uses the Spherical Law of Cosines.
hmm I tried stealig your code Clive but failed miserably :lol maybe someone can spot my error.... There are other algorithms I have found but maybe the issue is based on my usage of floats rather than doubles?
oexLongLatDistance PROC USES esi edi latA:REAL4, lonA:REAL4, latB:REAL4, lonB:REAL4
LOCAL lonX:REAL4
LOCAL latD:REAL4
LOCAL lonD:REAL4
LOCAL latD2:REAL4
LOCAL lonD2:REAL4
LOCAL oexDistance:DWORD
LOCAL oexPI:REAL4
LOCAL oexEarthRadius:REAL4
LOCAL oexEarthCircumferenceMeters:REAL4
LOCAL oexDegreesToRadians:REAL4
LOCAL oexDegreesToMeters:REAL4
m2m oexPI, CFLT(3.1415926535898)
m2m oexEarthRadius, CFLT(6371000.0)
fld oexPI
fdiv CFLT(180.0)
fstp oexDegreesToRadians
fld oexEarthRadius
fmul CFLT(2.0)
fmul oexPI
fstp oexEarthCircumferenceMeters
fld oexEarthCircumferenceMeters
fdiv CFLT(360.0)
fstp oexDegreesToMeters
fld latA
fsub latB
fstp latD
fld lonA
fsub lonB
fstp lonD
fld latA
fadd latB
fdiv CFLT(2.0)
fmul oexDegreesToRadians
fcos
fstp lonX
fld lonD
fmul oexDegreesToMeters
fmul lonX
fstp lonD
fld latD
fmul oexDegreesToMeters
fstp latD
fld lonD
fmul lonD
fstp lonD2
fld latD
fmul latD
fstp latD2
fld lonD2
fadd latD2
fsqrt
fistp oexDistance
mov eax, oexDistance
ret
oexLongLatDistance ENDP
:lol I found the bug in my coding of the haversine formula and have updated the code accordingly.... Floats is enough for about 0.3%ish accuracy I believe....
The last part you could code like this..
...
fld lonD
fmul st,st(0)
fld latD
fmul st,st(0)
faddp st(1),st
fsqrt
fistp oexDistance
mov eax, oexDistance
You could probably keep everything within the FPU, it will take me a little time to code and test
Something like this seems to be fairly concise..
double ComputeDeltaC(double latA, double lonA, double latB, double lonB)
{
const double deg2rad = 0.017453292519943334;
const double deg2metres = 111194.92664455897;
const double half = 0.5;
double delta;
__asm
{
fld qword ptr [latB]
fadd qword ptr [latA]
fmul qword ptr [half]
fmul qword ptr [deg2rad]
fcos
fld qword ptr [lonA]
fsub qword ptr [lonB]
fmulp st(1),st
fmul qword ptr [deg2metres]
fmul st(0),st
fld qword ptr [latA]
fsub qword ptr [latB]
fmul qword ptr [deg2metres]
fmul st(0),st
faddp st(1),st
fsqrt
fstp qword ptr [delta]
}
return(delta);
}
nice 1 Clive, it was a time vs value excercise I dont have more than a few long/lats to programaticallycheck as yet however that code improvement is gratefully accepted for future usage :bg
What, my code = chopped liver? :P
"mmmmmmmmm - chopped liver"
(http://1.bp.blogspot.com/_r6aQ9k1p2e8/SQihYPs625I/AAAAAAAAAIA/A2qwBxB8BYo/s400/homer_simpson31.jpg)
Dave,
Gee, thanks. I originally wrote it to calculate bearing and distance for radio contacts. The bearing part is great for aiming beams, the distance part is just interesting and can be used for bragging rights.
i have always had an interest in writing a program that would generate great circle maps
a user could enter their long and lat and it would crank out a map
of course, there would be a lot of user-selected options
maybe i'll attack that when i am a little better at win32 :bg
something like SM3GSJ has written:
http://www.qsl.net/sm3gsj/download.htm
it would bascially work on the same set of equations, with a database that describes the coast/boundry lines
this one is centered on Chatham Island, and has callsign prefixes (click on image for full-size)
(http://a.imageshack.us/img153/1015/zl7greatcirclemap.jpg) (http://a.imageshack.us/img153/1015/zl7greatcirclemap.jpg)
here is a simpler one for W5KFT near Austin, Texas (click on image for W5KFT's site)
(http://www.w5kft.org/great_circle/great_circle_color_ffffff.png) (http://www.w5kft.org/great_circle/)
Quote from: Greg Lyon on August 15, 2010, 11:13:09 PM
What, my code = chopped liver? :P
Hi Greg,
I believe your code is bearing distance rather than distance between 2 points.... I may also have a usage for this yet however havent gotten that far yet :bg
Ok, so a slight optimization.
double ComputeDeltaD(double latA, double lonA, double latB, double lonB)
{
const double deg2rad = 0.017453292519943334;
const double deg2metres = 111194.92664455897;
const double half = 0.5;
double delta;
__asm
{
fld qword ptr [latB]
fadd qword ptr [latA]
fmul qword ptr [half]
fmul qword ptr [deg2rad]
fcos
fld qword ptr [lonA]
fsub qword ptr [lonB]
fmulp st(1),st
fmul st(0),st
fld qword ptr [latA]
fsub qword ptr [latB]
fmul st(0),st
faddp st(1),st
fsqrt
fmul qword ptr [deg2metres]
fstp qword ptr [delta]
}
return(delta);
}
You might be interested in the Vincenty formula Clive.... I havent had a chance to code it yet (and it's more accurate than I need right now) however it works on an ellipsoidal model of the earth....
It's on (one hard drive of :lol) my 'todo' list however I will post it to the forum when done
Quote from: Greg Lyon
What, my code = chopped liver? :P
No, yours looks to be good, my only concern would be treating the global as a spheroid over long distances. I'd probably look to using a WGS84 ellipsoid model. Then again a radio wave is probably travelling significantly further as it bounces between the surface and the atmosphere.
I butchered your routine up a bit to fit it in my test framework (using REAL8 to pass parameters on the stack, and tweaked the radius of the earth to match the one I'm using in metres [6,371,000])
I should do some more testing, but here is a quick comparison
11.111100,22.222200 to 11.110800,22.222500
46.735966 metres (ComputeDelta)
46.735966 metres 135.542015 (BearingDistance)
11.111100,22.222200 to 10.991100,22.342200
18696.262895 metres
18696.260965 metres 135.524668
11.111100,22.222200 to 10.811100,22.522200
46747.664995 metres
46747.634890 metres 135.498814
11.111100,22.222200 to 10.124100,23.209200
153886.132556 metres
153885.067293 metres 135.402712
Mine is going to fall over as the curvature of the earth comes into play, and will probably not handle crossing the date line properly. For cars, the fact the roads are not straight (ie non Roman) the estimate is more of a crow-flies number. Mine would be more appropriate for geo-fencing or calling out the distance to a road junction, and where the embedded processor is less capable.
Quote from: clive on August 16, 2010, 03:21:48 PM
and tweaked the radius of the earth to match the one I'm using
I aspire to be able to code as well as Clive :bg
Quote from: oex on August 16, 2010, 03:06:19 PM
You might be interested in the Vincenty formula Clive.... I havent had a chance to code it yet (and it's more accurate than I need right now) however it works on an ellipsoidal model of the earth....
Yes, was just musing the ellipsoid issue in the post I was formulated as you posted. Things tend to get more complex as you pull in specific ellipsoid and datum models, the WGS84 and NAD83 model used by GPS are US centric, for other parts of the world NAD83 is going to be less than ideal for local cartography, although the use of GPS coordinates is probably becoming more prevalent. When dealing with regional maps knowing the datum used in it's creation is going to be important, and how that effects a bitmap/scanned map being pulled into a computer for display.
I need to delve into some of the navigation code to see how some of the maritime gear is handling this, as I've mostly done datum conversion work with ECEF based GPS coordinates (ie ellipsoid models, centre, and distortions wrt WGS84). The other maritime issue is one of bearing and the magnetic deviation (ie true vs compass), and the heading/speed are impacted by wind and currents, etc.
Quote from: oex on August 16, 2010, 03:33:13 PM
Quote from: clive on August 16, 2010, 03:21:48 PM
and tweaked the radius of the earth to match the one I'm using
I aspire to be able to code as well as Clive :bg
I have a team of elephants and tortoises at my command...
(http://philosophistry.com/scans/2007/09/chukwa.jpg)
lol
i was poking around a little and came across this site that has code by Mike Gavaghan
the guy seems to have it worked out, and allows selection of a number of different elipsoids
if he was an assembly programmer, i think we'd be done :bg
but, alas, he likes C#
the site is a little slow coming up, but probably worth the wait...
http://www.gavaghan.org/blog/free-source-code/geodesy-library-vincentys-formula/
Converting Gavaghan's implementation into C (not sure I want the pain to get it to assembler)
38.889220,-77.497800 to 45.858890,2.295830 - Lincoln Monument to Eiffle Tower
6600417.926524 metres (ComputeDelta, bogus for such distances)
6323278.164571 metres 54.934371 (BearingDistance, Clive's World 6371.0 km)
6330920.487890 metres 54.934371 (BearingDistance, Greg's World 6378.7 km)
6339542.878390 metres 54.948287 293.854750 (Gavaghan,Vincentys,WGS84)
The C compiler generated about 1100 lines of assembler
not too far out of the ballpark
thing is....
....we don't know the actual correct distance
maybe you do - you have GPS numbers on them or something ?
i suppose we could walk it off :bg
Quote from: dedndave on August 16, 2010, 06:23:36 PM
not too far out of the ballpark
thing is....
....we don't know the actual correct distance
maybe you do - you have GPS numbers on them or something ?
i suppose we could walk it off :bg
<G>
I took these numbers,
// set Lincoln Memorial coordinates
GlobalCoordinates lincolnMemorial;
lincolnMemorial = new GlobalCoordinates(
new Angle(38.88922), new Angle(-77.04978)
);
// set Eiffel Tower coordinates
GlobalCoordinates eiffelTower;
eiffelTower = new GlobalCoordinates(
new Angle(48.85889), new Angle(2.29583)
);http://www.gavaghan.org/blog/2007/08/06/c-gps-receivers-and-geocaching-vincentys-formula/
The proposed "course" probably wouldn't be achievable.
I can see a couple of parts of the code that can be folded, and would need to narrow the scope of various intermediate/temporary values to see if more can be held in the x87 registers and discarded once there usefulness has been exhausted. Still it's never going to provide a "fast" solution. If I were navigating I think I'd break the trip into several waypoints. Plus this doesn't handle 3D (probably not an issue for a boat, but certainly for a plane), I would use another algorithm with a higher update rate to recompute for an auto-pilot, and take into account the speed/course over ground being achieved with the current control inputs.
Looks as if I could use FSINCOS in a couple of places
http://siyobik.info/index.php?module=x86&id=115
I suspect we could get Greg's BearingDistance code to work with an ellipsoid model.
oex,
It calculates the bearing (azimuth) and distance between a point and another point.
Quote from: Clive... my only concern would be treating the global as a spheroid over long distances. I'd probably look to using a WGS84 ellipsoid model.
That's getting a lot more complicated than I wanted or needed to get into.
Quote from: Greg Lyon on August 16, 2010, 08:10:42 PM
It calculates the bearing (azimuth) and distance between a point and another point.
Oh right I get you, bearing could be quite useful.... I'll take a good look at it :bg
Quote from: Greg Lyon
That's getting a lot more complicated than I wanted or needed to get into.
Indeed, and not really a criticism, most of my usage tends to be points that are relatively close together. Things like breadcrumbing or odometer where you want to know where something went, but without tracking GPS position dither for a stationary object, but accumulating enough points so the lines Google Earth draws are actually on the road rather than cutting corners and appearing to take cross-country routes over the fields/medians
Some of the more algorithmic optimizations would come from doing crude/course filtering, say at an integer degree level, of huge lists of speed camera locations, too those likely to be reachable in the next hour by a car going at say 120 mph, and then re-evaluating on an hourly basis. The best way to save time is to avoid doing as much pointless computation as possible.
Vincenty does seem like a huge amount of overkill for finding a geocache within walking distance. Using Greg's or my implementation directly in the handheld GPS receiver would make much more sense, I could get a rough angle out of mine by looking at the delta Northing and Easting values. And for that matter GPS receivers don't have an intrinsic sense of direction (compass) so you either have to be moving for them to determine a direction of travel, or have an antenna array to determine orientation.
Unless I'm missing something obvious, why wouldn't the guy download the cache location(s) as waypoints into something like a Garmin eTrex and just use that. Perhaps he can download a list of caches as a Excel sheet or textfile, and spit out a list of viable ones to visit in a certain area and provide an optimal list of ones to visit in a travelling sales man type of way.
Thanks all for the feedback and advices.
This will probably be the distance / bearing calculations i will use.
.const
rad2deg REAL8 57.29577951308232088
deg2rad REAL8 0.017453292519943334
deg2metres REAL8 111194.92664455897
half REAL8 0.5
dqdiv REAL8 1000000.0
dq180 REAL8 180.0
.code
Distance proc latA:REAL8,lonA:REAL8,latB:REAL8,lonB:REAL8,lpfDist:PTR REAL10
fld REAL8 ptr [latB]
fadd REAL8 ptr [latA]
fmul REAL8 ptr [half]
fmul REAL8 ptr [deg2rad]
fcos
fld REAL8 ptr [lonA]
fsub REAL8 ptr [lonB]
fmulp st(1),st
fmul REAL8 ptr [deg2metres]
fmul st(0),st
fld REAL8 ptr [latA]
fsub REAL8 ptr [latB]
fmul REAL8 ptr [deg2metres]
fmul st(0),st
faddp st(1),st
fsqrt
mov eax,lpfDist
fstp REAL10 ptr [eax]
ret
Distance endp
;Bearing=ATAN2(SIN(lon2-lon1)*COS(lat2),COS(lat1)*SIN(lat2)-SIN(lat1)*COS(lat2)*COS(lon2-lon1)
Bearing proc latA:REAL8,lonA:REAL8,latB:REAL8,lonB:REAL8,lpfBear:PTR REAL10
;Convert to radians
fld REAL8 ptr [latA]
fmul REAL8 ptr [deg2rad]
fstp REAL8 ptr [latA]
fld REAL8 ptr [latB]
fmul REAL8 ptr [deg2rad]
fstp REAL8 ptr [latB]
fld REAL8 ptr [lonA]
fmul REAL8 ptr [deg2rad]
fstp REAL8 ptr [lonA]
fld REAL8 ptr [lonB]
fmul REAL8 ptr [deg2rad]
fstp REAL8 ptr [lonB]
;x=SIN(lonB-lonA)*COS(latB)
fld REAL8 ptr [lonB]
fsub REAL8 ptr [lonA]
fsin
fld REAL8 ptr [latB]
fcos
fmulp st(1),st
;y=COS(latA)*SIN(latB)-SIN(latA)*COS(latB)*COS(lonB-lonA)
fld REAL8 ptr [latA]
fcos
fld REAL8 ptr [latB]
fsin
fmulp st(1),st
fld REAL8 ptr [latA]
fsin
fld REAL8 ptr [latB]
fcos
fmulp st(1),st
fld REAL8 ptr [lonB]
fsub REAL8 ptr [lonA]
fcos
fmulp st(1),st
fsubp st(1),st
;ATAN2(x,y) NOTE this will fail if y=0
fdivp st(1),st
fld1
fpatan
;Convert to degrees
fld REAL8 ptr [rad2deg]
fmulp st(1),st
;Set result
mov edx,lpfBear
fstp REAL10 ptr [edx]
ret
Bearing endp
;In: Integer Longitude,Lattitude
;Out: REAL10 distance and bearing
BearingDistanceInt proc iLonA:DWORD,iLatA:DWORD,iLonB:DWORD,iLatB:DWORD,lpfDist:PTR REAL10,lpfBear:PTR REAL10
LOCAL fLatA:REAL8
LOCAL fLonA:REAL8
LOCAL fLatB:REAL8
LOCAL fLonB:REAL8
LOCAL fBear:REAL10
;Convert to decimal by dividing with 1 000 000
fild iLonA
fdiv dqdiv
fstp fLonA
fild iLatA
fdiv dqdiv
fstp fLatA
fild iLonB
fdiv dqdiv
fstp fLonB
fild iLatB
fdiv dqdiv
fstp fLatB
;Get distance
invoke Distance,fLatA,fLonA,fLatB,fLonB,lpfDist
;Get Bearing
invoke Bearing,fLatA,fLonA,fLatB,fLonB,lpfBear
mov eax,lpfBear
fld REAL10 PTR [eax]
mov ecx,iLonA
mov edx,iLatA
.if ecx<=iLonB
;0 to 180
.if edx>iLatB
;90 to 180
fadd REAL8 ptr [dq180]
.endif
.else
;180 to 360
fadd REAL8 ptr [dq180]
.if edx<=iLatB
;270 to 360
fadd REAL8 ptr [dq180]
.endif
.endif
fstp REAL10 PTR [eax]
ret
BearingDistanceInt endp
KetilO
The Norwegian fjords are treacherous, sometimes deep, sometimes shallow with underwater rocks. To make things even worse the difference between low and high tide is about 3 meters. A sonar is a must, preferably a bow mounted swinger to give you an early warning.
Hitting an underwater rock can be dangerous and expensive. On my map I will put a warning mark on places to avoid.
The place where I have my cabin and boat can best be described as a saltwater lake with a tidal river into the fjord. This place is really dangerous to those unfamiliar, full of underwater rocks only visible at low tide. The tidal current is stong so you cant go slow or you will be thrown off course.
Included is a screenshot that shows part of the place.
KetilO
that looks like a beautiful place Ketil
hafta go fishin for some of those elusive Norwegian Sweeties :bg
i would think the elipsoid corrections would be particularly important at lattitudes that far north (or south)
not so much for distances, but for bearings
but, as long as you can make your GPS jive with your map, i guess it doesn't matter
Hi dedndave
Last week I took a 40Km drive with my car to test the GPS / map acurancy. It never went off the road, although somtimes left hand driving.
If it is good enough for a car it is certainly good enough for navigating a boat.
On the map I am using the longitude / lattitude are straight lines. The longitude is linear, the lattitude is not. Instead of trying to figure out the formula to use I have an array of lattitudes with one entry for each vertical map tile. Since my area of interest is less than 100x100Km this works very well.
Yes, Norway is beautiful this time of the year. During summer there is nowhere else i rather be than right here where I live.
Today my wife had a day off from work, and I still have a few days left of my vacation so we decided to go to our cabin. It is just half an hour drive from home.
I wanted to fish and my wife wanted to pick some blueberries so i put her off at some small island while I went fishing.
After half an hour or so I had three cods, each around 5Kg. I went back to the island and cleaned the fish. One of the cods i cut into smaller pieces and wrapper it in tin foil with plenty of onion slices. I then picked some dry wood branches and made a small fire.
While the fire was burning out I went looking for my wife. When I found her she had alreddy picked a basket full of blueberrys.
When we returned to the fire it had alredy burned out so it was time to put the fish on. It is important to let the fire burn out or you will get fried fish instead of fish boilen in its own juice. I get water in my mouth just by thinking of how dellicious it is.
For dinner we had boiled cod and salad, for desert fresh blueberries with a teaspoon shugar and some milk.
Yes, life is good if you know how to enjoy it.
Ketil
mmmm - that sounds good :U
it would be cool to see that part of the world
all the mountain peaks in the same view as the lakes, with green everywhere
maybe i am just getting tired of seeing the Arizona desert - lol
rocks, dirt, cactus
Arizona has some great places, too - just hardly get out to see them anymore
of course, the weather here sux right now
it is hot, humid, and sticky - yesterday it was 110F (~43C) in the shade :red
Many years ago I visited Arizona (Phoenix). It is so long ago I cant even remember what time of the year it was. I am guessing it was winter or maybe early spring. A few things stuck to my mind. When we visited the desert I noticed that water came bubling out from the sand in my footprints. Not exactly what I have in mind when it comes to deserts. I also noticed that many of the larger buildings was underground due to the heat. during summer. I also remember that we had a rafting trip on some nearby river. It was nice. The guide told me he stayed in Phoenix during winter and went up north during summer. What a lucky guy.
Here, just now the weather is nice, the sky is blue and it is about 20C in the shadow.
Where I live it is just an hour drive to the polar circle. This means that a couple of months during summer we have 24 hour daylight.
You dont get all this without paying for it. The winter is long and cold and we only get some 6 hours daylight. But as a wise friend of mine says "If its too hot I take off all my cloths and its still too hot. If its too cold I just put on more cloths."
KetilO
i dunno where water was coming out of the ground - lol
that doesn't sound like the desert i am familiar with
from what i can see, they don't bury enough buildings around here
most houses in the Phoenix area do not have basements or cellars
that is because, after you get about 4 feet down, it is very hard to dig a hole here
but - the river i know well - it is the Salt River - when i was in high school, i tubed it a few times a week
now, the state charges you money to park, money for tubes, money for the bus ride
they have done what they can to prevent the old 2-vehicle method that we used to use
and - the banks are patroled by sherriff deputies on horseback and quads
they have really sucked all the fun out of it
well - most of the fun, anyways...
(http://blogs.phoenixnewtimes.com/jackalope/tubing1.jpg)
(http://farm2.static.flickr.com/1242/866897929_23df4e307e.jpg)
Hah! What the fuck?
Quote from: KetilO on August 18, 2010, 10:11:37 PM
Hi dedndave
Last week I took a 40Km drive with my car to test the GPS / map acurancy. It never went off the road, although somtimes left hand driving.
If it is good enough for a car it is certainly good enough for navigating a boat.
On the map I am using the longitude / lattitude are straight lines. The longitude is linear, the lattitude is not. Instead of trying to figure out the formula to use I have an array of lattitudes with one entry for each vertical map tile. Since my area of interest is less than 100x100Km this works very well.
Yes, Norway is beautiful this time of the year. During summer there is nowhere else i rather be than right here where I live.
Today my wife had a day off from work, and I still have a few days left of my vacation so we decided to go to our cabin. It is just half an hour drive from home.
I wanted to fish and my wife wanted to pick some blueberries so i put her off at some small island while I went fishing.
After half an hour or so I had three cods, each around 5Kg. I went back to the island and cleaned the fish. One of the cods i cut into smaller pieces and wrapper it in tin foil with plenty of onion slices. I then picked some dry wood branches and made a small fire.
While the fire was burning out I went looking for my wife. When I found her she had alreddy picked a basket full of blueberrys.
When we returned to the fire it had alredy burned out so it was time to put the fish on. It is important to let the fire burn out or you will get fried fish instead of fish boilen in its own juice. I get water in my mouth just by thinking of how dellicious it is.
For dinner we had boiled cod and salad, for desert fresh blueberries with a teaspoon shugar and some milk.
Yes, life is good if you know how to enjoy it.
Ketil
Wow. That sounds fantastic, KetilO! Thanks for sharing that awesome image.
Yes, that sounds really nice KetilO. Sounds like a beautiful place to live.
Hi Ketil,
Quote
On the map I am using the longitude / lattitude are straight lines. The longitude is linear, the lattitude is not. Instead of trying to figure out the formula to use I have an array of lattitudes with one entry for each vertical map tile. Since my area of interest is less than 100x100Km this works very well.
If you use a map with mercator projection the formula is
y = a*ln(tan(45deg + latitude/2deg))
where a is semi-major axis = 6,378,137m. You can read about it here (http://en.wikipedia.org/wiki/Transverse_Mercator_projection).
From your map ref points you can calculate a virtual axis in pixels with correct zoomfactor. I suppose your map has at least 3 ref points.
Thanks minor28
I will try it out.
KetilO
There is obviously someting I dont understand about this formula.
I expected that the difference between top and bottom would give me the height of the map in meters.
Instead it gives me a number about 2.5 times higher.
fp2 dq 2.0
pidiv4 dq 0.785398163397
iL2e dt 3FFEB17217F7D1CF79ACh
smaxis dq 6378137.0
.code
;minor28
;y = a*ln(tan(45deg + latitude/2deg))
;where a is semi-major axis = 6378137m
;http://mercator.myzen.co.uk/mercator.pdf
;y = a*ln[tan(Rad(lat)/2+PI/4)]
LatToPos proc iLat:DWORD
LOCAL tmp:DWORD
fild iLat
;Convert to decimal by dividing by 1 000 000
fdiv dqdiv
;Convert to radians
fmul deg2rad
;Divide by 2
fdiv fp2
;Add PI / 4
fadd pidiv4
fptan
;Pop the 1.0
fstp st
;ln
fld iL2e
fxch
fyl2x
;Multiply by a
fmul smaxis
fistp tmp
mov eax,tmp
ret
LatToPos endp
The code works as it should, verified using windows calculator.
KetilO
Since I started this project I have replaced the Cuda 350 with a BU 353 GPS module and added my homebrew sonar using the STM32 Discovery as microcontroller.
The BU 353 has better sensivity and the sonar has 3 times the range.
Only calibratinon of the temprature sensors and the time dependant gain control remains on the sonar.
This will be done using lookup tables.
(https://fbedit.svn.sourceforge.net/svnroot/fbedit/ShowMap/Sonar.jpg)
very nice Ketil
i did some work on bio-med ultrasound scanners
i seem to recall a formula for gain compensation
if you google "time-gain compensation", you should find some info
edit...
i found this graph - looks like a fairly simple log curve (for the most part - lol)
(http://img26.imageshack.us/img26/5201/tgc.png)
Thanks dedndave, interesting reading.
Unfortunatly the gain control of the receiver is not linear.
Gain control is achived by varying the bias of a jfet and a transistor.
The bias is set using one of the DAC channels on the STM32 Discovery.
A gain lookup table is needed as it is the fastest way to update the DAC.
The input signal range is 15uV to 1V (peak to peak) for a 3V output signal.
(https://fbedit.svn.sourceforge.net/svnroot/fbedit/ShowMap/Reciver.jpg)
(https://fbedit.svn.sourceforge.net/svnroot/fbedit/ShowMap/Transmitter.jpg)
Maybe this file can help. It converts the latitude and longitude to the corresponding point in pixel on the drawn map. The actual formula is calculated in "CalculateLatDistortion" function. Result is returned in "pScaleFactor".
Hope it helps. It works for me on every mapescale.
low-level gain controls are rarely linear - it's probably anti-log - the opposite of what you want - lol
you can use an analog multiplier at higher levels - not really applicable, here
but, you need some info to make the tables
we wrote a routine to interpolate values from points in the table - bsl function as i recall
we were careful to write it so that it took roughly the same number of cycles, regardless of values
then, we added that time to the "current" time so when the answer popped out, it applied to "then" :P
Surprisingly, a field test shows that the gain level needed to detect bottom at different ranges is pretty linear.
Some of the levels are off probably due to bottom conditions like a steep slope.
(https://fbedit.svn.sourceforge.net/svnroot/fbedit/ShowMap/FieldTest.jpg)
Although I am nott really interested in depth abowe 100 meters since the main purpose of the sonar
is to detect shallow places and finding fish. It is still nice to know the depth on really deep places.
(https://fbedit.svn.sourceforge.net/svnroot/fbedit/ShowMap/Sonar300m.jpg)
Hi minor28
Yes, that helped a lot. Using the formula I only need the left,top and right,bottom points to convert lon,lat to pixel position and vica versa.
What confused me was the semi-mayor axis. It made me belive I could use it to get the height of the map in meters.
I now realise the formula can only be used to dtermine the relation between lattitude and y axis.
KetilO
i really like the little fishies :bg
So you do.
What about this one. Its head is all about teeth and jaw.
Keep toes and fingers away, it will chop them off.
(https://fbedit.svn.sourceforge.net/svnroot/fbedit/ShowMap/UglyBeast.jpg)
he's an ugly critter - lol
bet he tastes good though
reminds me of the "goober fish" from starwars phantom menace :P