GPS controlled NMEA DATA following tracker

[camerart]

The single type variable has 7 digit precision in calculations.
Single_decimal_places = 2 means that only 2 decimals are displayed.

Hi J,
If I enter a variable to be 19.9 and it makes it 19.899999, then in a program 19.9 does not = 19.899999. Is this is important? I even tried making it 19.900001 and it made it 19.900001.

In this case I can round it up to 20. Should I do that or try to get it correct?

C.

 

[ericgibbs]

hi C,
IIRC correctly we were using a WORD variable for 3599, which infers a resolution of only 1 Bit , equivalent to 0.1 Degree.

Also the Yagi aerial, which is tracking the Remote transmitter, has a beam width of approx 8 degrees, why do you think a better than 1 degree dead band/zone is required.?

Eric

 

[jjw]

Hi J,
If I enter a variable to be 19.9 and it makes it 19.899999, then in a program 19.9 does not = 19.899999. Is this is important? I even tried making it 19.900001 and it made it 19.900001.

In this case I can round it up to 20. Should I do that or try to get it correct?

C.

You can't get it correct due to rounding errors in the single variables, but you can test if they are almost equal by calculating the difference being smaller than some value.

For example testing if a is within 0.1 of b:

If a<b Then
difference = b-a
Else
difference=a-b
Endif

If difference < 0.1 Then
eq= 1
Else
eq=0
Endif


Or simpler:
difference = a-b
eq=0
If difference <=0.1 and difference >= -0.1 Then
eq = 1
Endif

 

[camerart]

hi C,
IIRC correctly we were using a WORD variable for 3599, which infers a resolution of only 1 Bit , equivalent to 0.1 Degree.

Also the Yagi aerial, which is tracking the Remote transmitter, has a beam width of approx 8 degrees, why do you think a better than 1 degree dead band/zone is required.?

Eric

Hi Eric,

I think you introduced the SINGLE type variable to take care of negative numbers, but I'm not certain. As the little equasion that avoids negative numbers is now being used, I asume I can go back to WORD values.

I recently found that the previously thought 100:1 gearbox, has a 99.5:1 ratio, so 3599 is now 3581.

The resolution of the tracker is from the AXXX input which is 1 degree accuracy then x9.95. I am trying to get the DEADBAND to be 3 degrees wide which is 9.95 each side of the SETPOINT.

C.

 

[camerart]

You can't get it correct due to rounding errors in the single variables, but you can test if they are almost equal by calculating the difference being smaller than some value.

For example testing if a is within 0.1 of b:

If a<b Then
difference = b-a
Else
difference=a-b
Endif

If difference < 0.1 Then
eq= 1
Else
eq=0
Endif


Or simpler:
difference = a-b
eq=0
If difference <=0.1 and difference >= -0.1 Then
eq = 1
Endif

Hi J,

Ok, thanks.

Is it not advised then to put If A=B, if one of them could have been rounded up by 0,000001, when in fact they are really the same?

C.

 

[camerart]

Eric,

Woke up this morning recalling that SINGLEs are used for (brackets)

I need SINGLES for adding the wider DEADBAND. The program has changed since you used WORDs when you wrote it.

C.

 

[ericgibbs]

recalling that SINGLEs are used for (brackets)

hi C,
Not sure what that means?

Looking at the 3581 and 3599, that's a 0.01% percent error in a 360 degree rotation.

As IIRC, your tracking Head is not capable of a continuous circular rotation, the 0.01% error is not cumulative.

Your 8 degree beam width Yagi can acquire the Remote signal within say, +/-4degress, which is approx +/-1% of a full rotation.

IMHO you are making the band/zone over complicated.

Have you carried out the 'tests' we discussed, using a weight/mass equal to the Head assembly and cabling.?
[ or with the complete final Head assembly mounted on a tripod]

When doing this doing this test, what was the measured angular error.?
ie: input Azimuth angle compared to the Actual angle the Head came to rest.??

E

 

[camerart]

hi C,
Not sure what that means?

Me neither, you will be the first to know when I figure out what I'm talking about

Looking at the 3581 and 3599, that's a 0.01% percent error in a 360 degree rotation.

When carrying out tests, with a test motor, backwards and forwards, I noticed a cumulative error, as my disk moved round, which amounted to 1.7Deg/rev. Correcting the 3599 to 3582 corrected this (Almost)

As IIRC, your tracking Head is not capable of a continuous circular rotation, the 0.01% error is not cumulative.

Perhaps not the tracker, but I have two extra motors, and would like to make the program as near accurate as possible, so that I can use them for another purpose.

Your 8 degree beam width Yagi can acquire the Remote signal within say, +/-4degress, which is approx +/-1% of a full rotation.

There are a variety of options instead of yagis, so I'm just thinking mechanics and as good as I can.

IMHO you are making the band/zone over complicated.

Quite possibly, but it's not intentional.

Have you carried out the 'tests' we discussed, using a weight/mass equal to the Head assembly and cabling.?
[ or with the complete final Head assembly mounted on a tripod]

When doing this doing this test, what was the measured angular error.?
ie: input Azimuth angle compared to the Actual angle the Head came to rest.??

No tests of the actual tracker, only with a test motor, A/ in case of accidentally breaking the tracker mechanics, and B/I can carry out all kind of tests out of the wind.

I did loads of tests with the program that you wrote, and could never get it to stop anywhere near the SETPOINT. Not being able to follow your program, and realising that I have used a lot of your time, I decided to use the first part of your program, that receives the AxxxExxx data, and try to write the second part myself. I got best results from not using PWM and switching the motor cwise and ccwise depending on conditions. That had a DEADBAND of '1' and most times stopped ok, but sometimes it oscillated between the DEADBAND ends, so now I'm trying to widen the DEADBAND with BRAKE inside it. (With great difficulty)

C.

E

 

[camerart]

Hi,
Trying to add a DEADBAND and following a suggestion to make a kind of 24hour clock around the 3581 to 0 and 0 to 3581 point, so that a DEADBAND doesn't hit a jump. I've been trying this:
EDIT:
poscalc = poscnt
azcalc = azimval

If poscalc <= 49.75 Then '=5 DEG
If azcalc >= 3532.25 Then '=355 DEG
poscalc = poscalc + 3582
Endif
Endif
If azcalc <= 49.75 Then '=5 DEG
If poscalc >= 3532.25 Then '=355 DEG
azcalc = azcalc + 3582
Endif
Endif

If poscalc <= 49.75 Then '=5 DEG
If azcalc <= 49.75 Then
poscalc = poscalc + 3581
azcalc = azcalc + 3582
Endif
Endif

azminus = azcalc - dband 'test with smaller deadband ################
azplus = azcalc + dband

It nearly works, apart from AZIMVAL 359, and I've got tangled up in the spaghetti of it. If someone can see through my error, as I can see it could be 'simplified' I'd appreciate it.

C

 

[camerart]

Hi,
Here are the latest files for the project. They all work in a test rig, so next to finalise them all, try them in the Tracker and comment them better.
I WILL UPDATE THE FILES HERE AS I UPDATE THEM!
Camerart.

 

[camerart]

Apologies for keep changing the title, but I hope that's the last time.
C.

 

[camerart]

Hi,
Here's the reply regarding a superfluous line in my program:
((hi,
That basecos is equivalent to latcos1, so its now redundant.

'extract from your listing
latrad1 = 50.662341 / 57.295779
lonrad1 = 1.591347 / 57.295779
latcos1 = Cos(50.662341).???? degrees !

''Note:
latcos1 = cos(50.662341/57.295779) ' REM Rads !! == 0.884224665 ==latrad1

E

You have lots of free RAM))

REPLY: Hi Eric,
I removed the BASECOS line, but it gave wrong readings in test, So I replaced it and it is working again?????
I can't see LATRAD1, LONRAD1 LATCOS1 in my program?
I've updated the 18F4520 program in POST #30. This works ok, and is sometimes 1 degree out due to rounding.
There is still a problem with reset, as in the: https://www.electro-tech-online.com/threads/reset-on-18f4520.148815/ thread.
C.

 

[ericgibbs]

hi,
It that program you are using the prefix 'base' for the Lat/Lon of the Base station reference, in earlier programs we used
Lat1, Lon1 as the 'base' and Lat2, Lon2 as the 'remote'
Why did you ask me 'is the code basecos required.???

E

 

[camerart]

hi,
It that program you are using the prefix 'base' for the Lat/Lon of the Base station reference, in earlier programs we used
Lat1, Lon1 as the 'base' and Lat2, Lon2 as the 'remote'
Why did you ask me 'is the code basecos required.???

E

Hi Eric,
I'm pretty slow working through the programs and testing them, sometimes with the tracker and sometimes each PIC individually in separate circuit boards. Each time I change something in the program, that works ok, I try to keep the files updated in post #30.
Regarding the basecos line, I couldn't see how it worked, as it is before getting the GPS input. It appears that it is needed though. (I see why your puzzled)
Anyway, the latest 18F4520 program is working on the test circuit, apart from the reset problem, which always sorts itself out after a couple of restarts? I'm trying different things.
C.

 

[ericgibbs]

Regarding the basecos line, I couldn't see how it worked, as it is before getting the GPS input. It appears that it is needed though. (I see why your puzzled)

hi C,
The lines of Latitude around the planet are 15 degrees for every hour of time difference.

Assuming the Earth circumference at the Equator is say 40,000 km
If you divide 40,000km by 360 degrees you get 111.11km distance per degree at the Equator.

At 50Deg North of the Equator [ ie the ~UK] the distance for 1 degree is no longer 111.11km. [ it is shorter]

So we have to use the Cosine of 50deg to calc the actual East/West distance for our location and the Cosine of the remotes East/West location, so that we can calc the Azimuth and Distance from our location to the remote location.

Do You follow OK.?
E

 

[camerart]

hi C,
The lines of Latitude around the planet are 15 degrees for every hour of time difference.

Assuming the Earth circumference at the Equator is say 40,000 km
If you divide 40,000km by 360 degrees you get 111.11km distance per degree at the Equator.

At 50Deg North of the Equator [ ie the ~UK] the distance for 1 degree is no longer 111.11km. [ it is shorter]

So we have to use the Cosine of 50deg to calc the actual East/West distance for our location and the Cosine of the remotes East/West location, so that we can calc the Azimuth and Distance from our location to the remote location.

Do You follow OK.?
E

Hi E,
Thanks for the explanation, I follow.
Thinking that the basecos line was in the wrong place, I moved it down into the 'loop', so that it can do it's calculation properly. I also moved my push button section.
I have updated the 18F4520 program again in post #30, with these changes.
This appears to have solved what I have been calling the 'reset problem' too.
I have run tests in circuit and it looks as though the program is now working ok. (Further tests, to make sure)
C.

 

[camerart]

Removed

 

[camerart]

Hi,
Still alive and kicking, but working on: https://www.electro-tech-online.com/threads/radio-control-by-location.152926/
at the moment, I'l be back.
C.