Have you ever used this book? It's got a lot of cookbook style algorithms for navigating your way around coordinate systems without assuming that you either already have or want to pick up a lot of mathematical knowledge.

http://www.sky-watch.com/books/duffett1.html

I am not best at being good at calculations, this is why I'm hoping for someone to post one for me, who has experience. I'm more practical! This morning I drew longitude and latitude lines on a balloon, with two disks stuck on the represent tracker and target, so I can visualise what's happening. I can see error traps already

 

Check this page;
http://aprs.gids.nl/nmea/
it is a good reference of the text data spat out by most GPS modules. You module won't output every NMEA sentence, but it will output the satellites in view.

Check out the sentence;
$GPGSV
it has data for every GPS satellite in view. You can use these two data fields;
5 = Elevation in degrees, 90 maximum
6 = Azimuth, degrees from true north, 000 to 359

which show the satellite position relative to your GPS ground position. To point at that satellite just turn the rotation motor to match 6 (Azimuth) and the elevation motor to match 5.

Your antenna will then be pointed at the satellite. No maths required.

(edit) The PC freeware I linked to in a post above uses that elevation/azimuth data to show the satellites on a circle map. The GPS outputs those two data fields for every satellite in view, so the software shows them on a little circle map of the "sky".

Thanks, I have that page you linked to already.

Reminder! I am making a tracker to follow information sent from different objects, satellites being one, but it could be used on a model aircraft or for animal tracking. Information, like you posted (thanks) will be used to start off the tracker plus scanning around and indeed visual.

 

Yes it depends on the speed and distance of the object.

0.15, thanks, that seems good enough for what I want. Once I have the calculation, I will design the tracker to be as fast as the calculation.

Sorry, I made a big mistake.
The times were for 10 iterations.
The functions take about 1ms/each and calculating the bearing about 15ms.

 

Sorry, I made a big mistake.
The times were for 10 iterations.
The functions take about 1ms/each and calculating the bearing about 15ms.

This is what I fear, if I have a go, only worse! As long as we end up with the best possible, we can't ask for more.

Cheers.

 

...
Reminder! I am making a tracker to follow information sent from different objects, satellites being one, but it could be used on a model aircraft or for animal tracking. Information, like you posted (thanks) will be used to start off the tracker plus scanning around and indeed visual.

Animals and model 'planes are definitely in the "local" category. Just ignore the planet curvature and geoid calcs and use the simple trig calcs I posted previously.

This is done a lot for local use, up to 10 miles or so. In such a small area the planet can be considered as "flat" and lat/long as an XY grid. It's done all the time for local XY lat/long distance calcs.

 

Animals and model 'planes are definitely in the "local" category. Just ignore the planet curvature and geoid calcs and use the simple trig calcs I posted previously.

This is done a lot for local use, up to 10 miles or so. In such a small area the planet can be considered as "flat" and lat/long as an XY grid. It's done all the time for local XY lat/long distance calcs.

Here's my 'help me to visualise globe'. It's not accurate but give me an idea of what's going on. I can see that anything on the disc can almost be counted as flat, but it would be good to explore, doing it to cater for 'falling off the disc' then there will be one calculation for all events.

 

This is what I fear, if I have a go, only worse! As long as we end up with the best possible, we can't ask for more.

Cheers.

I don't understand your message.
The times for calculations are 1/10 of what I said first, about 0.015 seconds for the bearing.

 

I don't understand your message.
The times for calculations are 1/10 of what I said first, about 0.015 seconds for the bearing.

The problems with words!

What I mean is: What you say about the calculation time is fine by me, I will be happy with whatever is sent to me, it will be the best I can get.

What I fear is: If I did the calculation, any errors would be worse than the error you made

 

Hi All,

I've got the GPS to read on to a google map using Ardupilot, but this is not what I want, it was just to test the GPS module.

I have the RAW NMEA data from the GPS on screen using PUTTY, I've attached a screen shot of the NMEA titles, but not my location, the data is typical of NMEA data.

You will notice that there is more than one $GPGSV sentence in each pass, I've counted 4 same sentences.

Also the number of different sentences change, e,g, 7-9.

Now I would like to be able to 'play' with the data in Qbasic or similar, but at a struggle might be able to get C translated.

Cheers, Camerart

 

hi C,
The $GPGSV is the number of satellites in view, so it may change if the signal strength changes

E

 

hi C,
The $GPGSV is the number of satellites in view, so it may change if the signal strength changes

E

I'll have to have a closer look at the data against what is expected.

I'm a bit puzzled! If you look at the data I sent to you, it shows my location, so if the GPS was elsewhere, it would show where it is. Looking at the $GPGSV sheet you posted it appears to show a satellite ID and an Azimuth plus Altitude, of that satellite. If an id could be found for any received data source, including the GPS, then all that would be needed would be to isolate the intended ID, and extract the Azimuth and Altitude, so no calculation.

I'll re-write this if it's not clear (It's not that clear to me)

Camerart.

 

The GSV can only have 1-4 satellites in each sentence (max 4, obviously), so if your sats in view goes from 12 to 13 the sentences go from 3 to 4.

The GSV shows the ID's of the satellites, that is because the GPS module receives an ID code from each satellite.

The GPS engine in the module computes the elevation and azimuth for each satellite, it has a massive math engine inside.

The GPS module can't get "ID's" for anything else. I think that was the ting you wanted cleared up?

What you will have is a location for the GPS module lat/long/ele. You will have to manually assign heading to yourt pointing motor system, to compass north or geo north.

After that you will need to do the trig calcs to point at other lat/long/ele locations.

I really suggest in the short term just get it going with a simple XYZ grid model and get it pointing at local locations.

Once that is done and working ok, you can then add the planet sphere curvature to the calcs as an extra layer, or even proper geoid curvature calcs.

 

This might be of interest! Flip though a couple of pages and there is a NMEA checksum calculator: https://learn.sparkfun.com/tutorials/gps-basics/reading-gps-data

 

The GSV can only have 1-4 satellites in each sentence (max 4, obviously), so if your sats in view goes from 12 to 13 the sentences go from 3 to 4.

The GSV shows the ID's of the satellites, that is because the GPS module receives an ID code from each satellite.

The GPS engine in the module computes the elevation and azimuth for each satellite, it has a massive math engine inside.

The GPS module can't get "ID's" for anything else. I think that was the ting you wanted cleared up?

What you will have is a location for the GPS module lat/long/ele. You will have to manually assign heading to yourt pointing motor system, to compass north or geo north.

After that you will need to do the trig calcs to point at other lat/long/ele locations.

I really suggest in the short term just get it going with a simple XYZ grid model and get it pointing at local locations.

Once that is done and working ok, you can then add the planet sphere curvature to the calcs as an extra layer, or even proper geoid curvature calcs.

The_RB
Just as I thought things were getting easier, the rug gets pulled

From your experience, and thinking about GPS modules in models and on animals etc, and satellites, funcubes etc, plus any more you can think of. I'm trying to settle on the best form of data exchange, am I correct in thinking that all of those different transmitters send the same NMEA sentence that will be the best to use?

The_RB
Just as I thought things were getting easier, the rug gets pulled

From your experience, and thinking about GPS modules in models and on animals etc, and satellites, funcubes etc, plus any more you can think of. I'm trying to settle on the best form of data exchange, am I correct in thinking that all of those different transmitters send the same NMEA sentence that will be the best to use?

EDIT: Is there anyway to utilise the GPS module and it's big brain, at the receiver end, to do a useful calculation, such as Azimuth and Elevation of any SOURCE?

Camerart.

Camerart.

 

I've only worked with two GPS types, they both sent GSV and GGA sentences. Usually they send about 5 sentences standard. I think they also send GSA? Going from memory here.

If you want to write some code to communicate BACK to the GPS you can configure it to output different NMEA sentences and also set some options (like to put it in stationary mode where its lat/long/ele coords are more accurate). But be warned it's not a beginner task and the datasheets for the GPS chips can be a bit rough.

And NO you can't get the GPS's big brain to do calcs for you. It's a hardware math engine and all you can do with the comms is listen to its data or do some simple configuring of it.

Don't be so scared of doing the math to point at a second location you can get C libraries for tan/sin/cos etc, they might aready be inside your compiler.

Also we need to know your desired pointing accuracy. It gets MUCH easier in the calcs if you are happy to point within a couple of degrees of the location. If you want it to be super accurate in pointing (like a high powered telescope needs etc) then the math gets larger and the microcontroller you will need gets larger too.

 

I've only worked with two GPS types, they both sent GSV and GGA sentences. Usually they send about 5 sentences standard. I think they also send GSA? Going from memory here.

If you want to write some code to communicate BACK to the GPS you can configure it to output different NMEA sentences and also set some options (like to put it in stationary mode where its lat/long/ele coords are more accurate). But be warned it's not a beginner task and the datasheets for the GPS chips can be a bit rough.

And NO you can't get the GPS's big brain to do calcs for you. It's a hardware math engine and all you can do with the comms is listen to its data or do some simple configuring of it.

Don't be so scared of doing the math to point at a second location you can get C libraries for tan/sin/cos etc, they might aready be inside your compiler.

Also we need to know your desired pointing accuracy. It gets MUCH easier in the calcs if you are happy to point within a couple of degrees of the location. If you want it to be super accurate in pointing (like a high powered telescope needs etc) then the math gets larger and the microcontroller you will need gets larger too.

The_RB
I'm at the early stages of this subject. so far I've got connected GPS showing it's received sentences.

I won't need to TX to the source.

Shame about the big brain, glad you saved me from endless searching to find out.

I think these libraries have been pointed out to me, but I think the PICs I've just received for the project(16F886) don't have them, the suggestion was for one in the 18 series PICs, I decided not to upgrade, unless I really have to. I've got lots of suggestions for calculations etc, and I suppose I'll have to start, and if I have to I'll go to larger PICs.

Cheers, Camerart

 

If you are using C then the "upgrade" from 16F to 18F is as easy as plugging in a 18F PIC and clicking the new PIC number in the compiler.

The benefit of going to 18F in this project is immense. The 18F can run at 10 MIPS (the 16F is only 5 MIPS) and the 18F has the hardware multiplication which is like a little math processor inside the PIC. That really speeds up large calcs! You will need to do math in the PIC so switching to 18F series is a no-brainer.

 

If you are using C then the "upgrade" from 16F to 18F is as easy as plugging in a 18F PIC and clicking the new PIC number in the compiler.

The benefit of going to 18F in this project is immense. The 18F can run at 10 MIPS (the 16F is only 5 MIPS) and the 18F has the hardware multiplication which is like a little math processor inside the PIC. That really speeds up large calcs! You will need to do math in the PIC so switching to 18F series is a no-brainer.

Being mono lingual, I can only use basic, but i suppose your message applies to this too.

Thanks, I'll update, Camerart.

 

If you are using C then the "upgrade" from 16F to 18F is as easy as plugging in a 18F PIC and clicking the new PIC number in the compiler.

The benefit of going to 18F in this project is immense. The 18F can run at 10 MIPS (the 16F is only 5 MIPS) and the 18F has the hardware multiplication which is like a little math processor inside the PIC. That really speeds up large calcs! You will need to do math in the PIC so switching to 18F series is a no-brainer.

I don't like receiving advice, ignoring it and regretting it later!

Just updated to 18series PICs.

For this sort of application, I count signal UART-1 pin, motors -2, feedback-2, leds-2, and keyboard, I'm not sure how many, maybe USB-2. There may be more, I'm sure there will be, but so far 9 ish. So can you recommend which PIC you would choose. As small as possible please.

Camerart.

 

What do you mean by as small as possible?
Number of pins or something else.
Don't you use LCD anymore.

Did you update Oshonsoft to PIC18 IDE ?
I don't know if Oshonsoft Basic uses the hardware multiplier, but at least you get 2x speedup.