GPS NMEA antenna aiming tracker.

THE_RB

Joined Feb 11, 2008
5,438
Sorry Camerart, that was was my mistake. I thought the 4620 was just the increased memory version of the 4520, but they are different PICs.

When I suggested that I only looked at the fact the 4620 has double the RAM and ROM compared to the 4520, but missed that it also had an inbuilt LCD driver. Sorry!

Re the arctan function I like Eric's suggestion of just using a lookup table. You can use Excel spreadsheet to make a lookup table, and cut/copy the values as text and put that in your code.

You only need the table to cover one octant if you want to derive angle from X and Y grid distances. I'd use a binary sized table (say 64 or 128 entries) to cover the 45 degree octant. That will make it easier to scale and makes the math quicker.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,724
Sorry Camerart, that was was my mistake. I thought the 4620 was just the increased memory version of the 4520, but they are different PICs.

When I suggested that I only looked at the fact the 4620 has double the RAM and ROM compared to the 4520, but missed that it also had an inbuilt LCD driver. Sorry!

Re the arctan function I like Eric's suggestion of just using a lookup table. You can use Excel spreadsheet to make a lookup table, and cut/copy the values as text and put that in your code.

You only need the table to cover one octant if you want to derive angle from X and Y grid distances. I'd use a binary sized table (say 64 or 128 entries) to cover the 45 degree octant. That will make it easier to scale and makes the math quicker.
The_RB,

I did ask for suggestions, then panic bought.(18F4520) I thought I'd rather just get going, then if it becomes obvious to someone, they could get me to change later.

Re-the LCD driver. Without one, is there any difference in using 4bit or 8 bit?

So that's what a look up table is! I'm now assuming that there are 90 or 360 'columns' with a known value in each, instead of a calculation?

I've been looking up trigonometry, quadrants, octants, arctan etc etc. I've come to the conclusion, that (just like college) I'm not going to ever be good at it. I've had friends and family explaining and it makes very little sense to me. I am at the stage that I can put a ladder against a wall at a safe angle, using Pythagoras:) I'll just have to leave it to people who have a feel for it, and stick to what I'm better at.

Camerart.
 

ericgibbs

Joined Jan 29, 2010
18,766
So that's what a look up table is! I'm now assuming that there are 90 or 360 'columns' with a known value in each, instead of a calculation?
hi C,
This Code fragment is a Look Up table example from the Oshonsoft Basic Manual
It could be modified as follows:

Azimuth= LOOKUP(0, 5, 10,15, 20,25, 30, 35,40,45), Atn1

Azimuth is the Value from 0 to 45 degrees that will be read by the Basic program, using the Atn1 value as Pointer to the values in the brackets.
eg: Atn1 = 0 would return '0' and Atn=9 would Return '45'.

Where Azimuth values could be either Radians or Degrees and the Atn1 is the Ratio of the LatOffSet/LongOffSet , rounded to give an Integer value.
[the Lookup Table can be upto 255 entries long if required]

Eric

Rich (BB code):
DIM DIGIT AS BYTE DIM MASK AS BYTE loop: 
TRISB = %00000000 
FOR DIGIT = 0 TO 9 
MASK = LOOKUP(0x3F, 0x06, 0x5B, 0x4F, 0x66, 0x6D, 0x7D, 0x07, 0x7F, 0x6F), DIGIT 
PORTB = MASK 
WAITMS 1000 
NEXT DIGIT 
GOTO loop
 
Last edited:

jjw

Joined Dec 24, 2013
823
How do you make lookup tables longer than one line in Oshonsoft Basic?
I have tried with no success.
The documentation from Oshonsoft is minimal.
 

ericgibbs

Joined Jan 29, 2010
18,766
How do you make lookup tables longer than one line in Oshonsoft Basic?
I have tried with no success.
The documentation from Oshonsoft is minimal.
Hi jjw,
This problem was discussed on the Oshon/Yahoo group, no one found a way to wrap the table over more than one line.
Its 0 to 255 on one line, a real pain.

If you ever find a way to wrap the table over over a number of lines, please let me know.

Eric
 

Thread Starter

camerart

Joined Feb 25, 2013
3,724
hi C,
This Code fragment is a Look Up table example from the Oshonsoft Basic Manual
It could be modified as follows:

Azimuth= LOOKUP(0, 5, 10,15, 20,25, 30, 35,40,45), Atn1

Azimuth is the Value from 0 to 45 degrees that will be read by the Basic program, using the Atn1 value as Pointer to the values in the brackets.
eg: Atn1 = 0 would return '0' and Atn=9 would Return '45'.

Where Azimuth values could be either Radians or Degrees and the Atn1 is the Ratio of the LatOffSet/LongOffSet , rounded to give an Integer value.
[the Lookup Table can be upto 255 entries long if required]

Eric

Rich (BB code):
DIM DIGIT AS BYTE DIM MASK AS BYTE loop: 
TRISB = %00000000 
FOR DIGIT = 0 TO 9 
MASK = LOOKUP(0x3F, 0x06, 0x5B, 0x4F, 0x66, 0x6D, 0x7D, 0x07, 0x7F, 0x6F), DIGIT 
PORTB = MASK 
WAITMS 1000 
NEXT DIGIT 
GOTO loop
Hi E,

With the optical disk, (0-360) the next number up from 360 is 0.
I don't quite understand how look up tables work, I'm assuming behind each step is a long logarithmic type number. Would it be possible to make the look-up table have 360 steps (180 steps 180 gaps), and use an approximation for the gaps?

Camerart.
 

jjw

Joined Dec 24, 2013
823
Maybe I am missing something, but why is 0-45 degrees enough in table lookup.
Should'nt 0-90 degrees needed?
The problem is also that index to table ( tan value ) is very nonlinear after 45 degrees.
It would need some "if then else" programming or searching based on tan values.
 

ericgibbs

Joined Jan 29, 2010
18,766
Maybe I am missing something, but why is 0-45 degrees enough in table lookup.
Should'nt 0-90 degrees needed?
The problem is also that index to table ( tan value ) is very nonlinear after 45 degrees.
It would need some "if then else" programming or searching based on tan values.
hi jjw,
The 45 degree table is ONLY an example, the OP will have to increase the length of the table to suit his application.

E
 

ericgibbs

Joined Jan 29, 2010
18,766
With the optical disk, (0-360) the next number up from 360 is 0.
I don't quite understand how look up tables work, I'm assuming behind each step is a long logarithmic type number. Would it be possible to make the look-up table have 360 steps (180 steps 180 gaps), and use an approximation for the gaps?
Hi C,
You did say an Azimuth and Elevation resolution of 1 degree would be sufficient.

The Trig tables only need to be 0 thru 90 degrees, they repeat for each 90 degree quadrant.
You can determine the quadrant from the sign of the angle or the sign of the direction of Base to Remote N, E, coordinates.

For a tracker Yagi aerial of say receiving 10 Deg beam width, I would use 5 Deg steps for the Atn/Degree table, to calc the approx Atn from the received GPS message.

As I recall the purpose of your tracker is enable the Base station receiver to pick up the GPS message from the Remote transmitter.

If the Base station Yagi is pointing +/-5Deg towards the 'believed' position of the Remote transmitter , it will receive the GPS message.

E
 

Thread Starter

camerart

Joined Feb 25, 2013
3,724
Hi C,
You did say an Azimuth and Elevation resolution of 1 degree would be sufficient.

The Trig tables only need to be 0 thru 90 degrees, they repeat for each 90 degree quadrant.
You can determine the quadrant from the sign of the angle or the sign of the direction of Base to Remote N, E, coordinates.

For a tracker Yagi aerial of say receiving 10 Deg beam width, I would use 5 Deg steps for the Atn/Degree table, to calc the approx Atn from the received GPS message.

As I recall the purpose of your tracker is enable the Base station receiver to pick up the GPS message from the Remote transmitter.

If the Base station Yagi is pointing +/-5Deg towards the 'believed' position of the Remote transmitter , it will receive the GPS message.

E
Hi E,

For the first tests, is it possible to use 1 degree steps? For me to visualise comparing one degree by calculation against the 1 degree optical disk, would be easier I think. If later the system can't keep up and steps of 5 degrees work better, I could change then. Also the motor/aerial would not 'hunt' so much with 1 degree steps.

Trying to understand the look-up tables better. Am I correct in thinking, that the tables are capable of 1 degree steps for 1 to 90 degrees in say quadrant 1, then the next step would be 1 in quadrant 2? up to 4 quadrants.

Cheers, C
 
Last edited:

THE_RB

Joined Feb 11, 2008
5,438
Maybe I am missing something, but why is 0-45 degrees enough in table lookup.
Should'nt 0-90 degrees needed?
...
The code needs to get the angle from two grid distances (Xdist and Ydist).
All you need is a table for one octant (45').

(Camerart, you can draw these on a paper grid if you like)
Example 1;
PointA is on grid position X0 Y0, PointB is on X0 Y10;
Xdist = 0, Ydist = 10.
So pointB is directly above pointA, the angle is 0 degrees.

Example 2;
PointA is on grid position X0 Y0, PointB is on X4 Y4;
Xdist = 4, Ydist = 4.
So pointB is equally above and to the right of pointA, the angle is 45 degrees.
(that is as large as the table needs to be).

Example 3;
PointA is on grid position X0 Y0, PointB is on X10 Y0;
Xdist = 10, Ydist = 0.
So pointB is directly to the right of pointA, the angle is 90 degrees;

However, this is just a mirror reflection of example1! So you can use the same table BUT swap the X and Y values (because X is now larger than Y). The table will still work fine, and returns a reading between 0-45 degrees. It will return "0 degrees" which is the offset back from 90. So because the table is mirrored the real degrees are; (90-result) or 90-0 = 90 degrees.

If you use a 90 degree table you still have to flip and swap values etc to get the 4 quadrants with the one table. It's a similar process (and similar amount of work) to flip and swap a 45 degree table to match 8 octants.

The lookup table needs one entry value; the ratio of small dist to large dist. Generally you would make it have 100 entries, and use percent. So if Ydist is larger than Xdist, you get the ratio as percent;
Ydist = 451, Xdist = 358
tablepercent = (100 * small_dist) / large_dist
tablepercent = (100 * 358) / 451
tablepercent = 79

So you just get the 79th value from the lookup table of 100 values. That returned value is the angle (somewhere between 0-45 degrees). Then you just flip/rotate it as needed, to suit the correct octant.
:)
 
Last edited:

ericgibbs

Joined Jan 29, 2010
18,766
Also the motor/aerial would not 'hunt' so much with 1 degree steps.
hi C,
The scanner would hunt more for 1deg resolution, as it would be constantly trying to hold the 'aimed' angle withing 1 deg.

If the program was set to change the aiming angle when the Remotes angular position changed by 5%, the motors would be in the 'holding' state for most of the time.
I thought we had agreed that a Yagi with a 10% degree receiving beam width would be used.? so a change in measured angle of 5% should keep the Yagi pointing at +/-5Deg of the remote.
Remember that the received GPS message will be sent at 1 second intervals.
Most simple Yagi's will have a beam width of +/-10deg.


Trying to understand the look-up tables better. Am I correct in thinking, that the tables are capable of 1 degree steps for 1 to 90 degrees in say quadrant 1, then the next step would be 1 in quadrant 2? up to 4 quadrants.
I normally work with a quadrant [90deg] Table, but as pointed out an Octant [45deg] Table would be acceptable.
You can determine which Quadrant you are working in by checking the polarity of your Northings, Eastings calculations.

I would suggest you also consider what action is taken by the program/motors when the Remote transmission is lost and how you initially point the Yagi.

I have seen systems that swing around and wrap the cables around the tripod and crash to the ground.! [not mine.;)]

Add limits to the Hori/Vert rotations, either using your 0 thru 360 encoder disk within the program or mechanical limit switches.

E
 

Thread Starter

camerart

Joined Feb 25, 2013
3,724
Thanks The_RB and Eric,

Before I make mock-up graphs or models, can we decide 45degree or 90 degree tables. I will try the RB method, as an exercise, but for the reason Eric gave, N, S, E, W is easier imagined with a 90 degree imagination, so if possible my choice would be 90.

The only experience I have with this sort of thing is WIRE following camera vehicles. They used POTs for steering feedback, and if ACTUAL was > or < the FEEDBACK, then I slowly ramped up the voltage left or right with a null point in the centre. No hunting because of the ramp, and the feedback could swing left or right, with no 'hunting'. So the farther away from the WIRE the voltage would increase, making the vehicle steer faster. If it was on the WIRE or near, the correction voltage was low. If the WIRE signal was lost it was programmed to stop. This is why I favour 1Degree, it might take 5 degrees to over come the inertia of the system.

In this case I am using opto disks, so that it will be capable of going round and round. Mostly it won't need this, but if it needs to go past the 0/360 north point it can, and not need to spin 359 degrees backward. As far as wrapping cables round, I'll think of a way round it, once I've seen it working. Slip rings, bluetooth, transmitter receivers, whatever is best.

A keyboard will aim it before starting till a signal takes over.

Camerart.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,724
The code needs to get the angle from two grid distances (Xdist and Ydist).
All you need is a table for one octant (45').

(Camerart, you can draw these on a paper grid if you like)
Example 1;
PointA is on grid position X0 Y0, PointB is on X0 Y10;
Xdist = 0, Ydist = 10.
So pointB is directly above pointA, the angle is 0 degrees.

Example 2;
PointA is on grid position X0 Y0, PointB is on X4 Y4;
Xdist = 4, Ydist = 4.
So pointB is equally above and to the right of pointA, the angle is 45 degrees.
(that is as large as the table needs to be).

Example 3;
PointA is on grid position X0 Y0, PointB is on X10 Y0;
Xdist = 10, Ydist = 0.
So pointB is directly to the right of pointA, the angle is 90 degrees;

However, this is just a mirror reflection of example1! So you can use the same table BUT swap the X and Y values (because X is now larger than Y). The table will still work fine, and returns a reading between 0-45 degrees. It will return "0 degrees" which is the offset back from 90. So because the table is mirrored the real degrees are; (90-result) or 90-0 = 90 degrees.

If you use a 90 degree table you still have to flip and swap values etc to get the 4 quadrants with the one table. It's a similar process (and similar amount of work) to flip and swap a 45 degree table to match 8 octants.

The lookup table needs one entry value; the ratio of small dist to large dist. Generally you would make it have 100 entries, and use percent. So if Ydist is larger than Xdist, you get the ratio as percent;
Ydist = 451, Xdist = 358
tablepercent = (100 * small_dist) / large_dist
tablepercent = (100 * 358) / 451
tablepercent = 79

So you just get the 79th value from the lookup table of 100 values. That returned value is the angle (somewhere between 0-45 degrees). Then you just flip/rotate it as needed, to suit the correct octant.
:)
The-RB,

Thanks for your explanation of how tables work. I did the 3 exercises, and can now see the reflective nature of them. For me there are so many questions, that I fear many frustrating messages, backward and forward with diminishing returns. Maths is not for me! I will understand better when they are in use, and I see angles appearing out of the calculations.

Camerart.
 

THE_RB

Joined Feb 11, 2008
5,438
After what Eric has said about the Yagi's having a +/-10% beam width, you really only need to get within a degree or two of the right angle?

If so, I did a very fast and simple algortihm on this page;
http://www.romanblack.com/integer_degree.htm
that returns an angle 0-360 degrees from two distances Ydist and Ydist.

I used in on a motion control application where the machine recived new X,Y coords for each new location, and had to very quickly know what the new direction was (to decide if it could change direction instantly or needed to decel/accel before the direction change). It needed to do that calc in a fraction of a millisecond, in real time as the machine was moving fast.

It worked really well, and the code runs quite fast on a 18F PIC. The limitation is that it gets you to within about a +/-1 degree error. If you are happy with that, the code is already fully done and tested, scroll down the page to the heading;
Full 0-360 version in C code;

And if you want more accuracy you can replace steps 1 and 2 in that code with;
1. scale X and Y so the ratio matches lookup table entry;
tablepercent = (100 * small_dist) / large_dist
2. get the angle from the lookup table
:)
 

Thread Starter

camerart

Joined Feb 25, 2013
3,724
After what Eric has said about the Yagi's having a +/-10% beam width, you really only need to get within a degree or two of the right angle?

If so, I did a very fast and simple algortihm on this page;
http://www.romanblack.com/integer_degree.htm
that returns an angle 0-360 degrees from two distances Ydist and Ydist.

I used in on a motion control application where the machine recived new X,Y coords for each new location, and had to very quickly know what the new direction was (to decide if it could change direction instantly or needed to decel/accel before the direction change). It needed to do that calc in a fraction of a millisecond, in real time as the machine was moving fast.

It worked really well, and the code runs quite fast on a 18F PIC. The limitation is that it gets you to within about a +/-1 degree error. If you are happy with that, the code is already fully done and tested, scroll down the page to the heading;
Full 0-360 version in C code;

And if you want more accuracy you can replace steps 1 and 2 in that code with;
1. scale X and Y so the ratio matches lookup table entry;
tablepercent = (100 * small_dist) / large_dist
2. get the angle from the lookup table
:)
The-RB,

That is excellent! It will need to be converted to basic for me to read properly, but that's doable.

I should receive the 18 PICs today, and will start the process.

Thanks very much.

Camerart.
 

THE_RB

Joined Feb 11, 2008
5,438
Just bear in mind it might not be the best system for your needs. It is limited to X and Y distances must be between -1456 and 1456 (for 16bit version).

You can use a 32bit version and your Xdist,Ydist can be in the millions.

At this point we really don't know what your initial data looks like.

The code to get going first would be to decide on your data formats for the coords etc, and how you might convert the pontA lat/long and pointB lat/long to two distances; Xdist and Ydist.

And if Xdist,Ydist will be in a nice simple format like metres (which would probably be my preference).

Once you get that far, people may suggest better ways to convert the Xdist,Ydist to a heading angle. My way was a kludge that mainly just needed to be fast. :)
 

jjw

Joined Dec 24, 2013
823
I am lazy and would do the arctan like this in Oshonsoft Basic if speed is not an issue.
This is for the first quadrant
Rich (BB code):
Function arctan(arg As Single) As Single
  If arg <= 1 Then
    arctan = arg / (0.281125 * arg * arg + 1) * 57.296
  Else
    arctan = (1.5708 - arg / (arg * arg + 0.28125)) * 57.296
  Endif
End Function
This takes about 0.5ms with 16F877 and 20MHz oscillator.
I believe that handling all quadrants will be clearly less than 1ms.
The error is less than 0.26 degrees.
 

ericgibbs

Joined Jan 29, 2010
18,766
hi jjw,
I have just tried your arctan function as part of a Oshonsoft Basic program I have written for Camerart, it looks good, returns degree values within +/-0.5 degrees.

Thanks for that Function.;)

Eric
 

Thread Starter

camerart

Joined Feb 25, 2013
3,724
Just bear in mind it might not be the best system for your needs. It is limited to X and Y distances must be between -1456 and 1456 (for 16bit version).

You can use a 32bit version and your Xdist,Ydist can be in the millions.

At this point we really don't know what your initial data looks like.

The code to get going first would be to decide on your data formats for the coords etc, and how you might convert the pontA lat/long and pointB lat/long to two distances; Xdist and Ydist.

And if Xdist,Ydist will be in a nice simple format like metres (which would probably be my preference).

Once you get that far, people may suggest better ways to convert the Xdist,Ydist to a heading angle. My way was a kludge that mainly just needed to be fast. :)
The_RB,

The NMEA sentences that look most likely, are GGA The form they arrive at the PIC is: $GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47

There would be one of these sentences for the tracker, which (at the moment) is fixed and typed in via a 4X4 keyboard. The second one will be received using a receiver.

Where: GGA Global Positioning System Fix Data 123519 Fix taken at 12:35:19 UTC 4807.038,N Latitude 48 deg 07.038' N 01131.000,E Longitude 11 deg 31.000' E 1 Fix quality: 0 = invalid 1 = GPS fix (SPS) 2 = DGPS fix 3 = PPS fix 4 = Real Time Kinematic 5 = Float RTK 6 = estimated (dead reckoning) (2.3 feature) 7 = Manual input mode 8 = Simulation mode 08 Number of satellites being tracked 0.9 Horizontal dilution of position 545.4,M Altitude, Meters, above mean sea level 46.9,M Height of geoid (mean sea level) above WGS84 ellipsoid (empty field) time in seconds since last DGPS update (empty field) DGPS station ID number *47 the checksum data, always begins with *

Camerart.
 
Top