camerart
Well-Known Member
Hi,
Firstly, I have other threads on this subject open, but they could be confusing!! e,g, (https://www.electro-tech-online.com/threads/gps-data-tracker-for-antenna-aiming.140729/) So I hope that this one is clearer? I have attached a program, that has been written and helped by others on this and other forums, so thanks to them.
What the program does is read an azimuth or AZIMVAL angle as a 3x digit number e,g, 090 = 90degrees. The tracker compares this with a base angle POSCNT set to '0' at north and counts round 360 degrees, so if AZIMVAL = 090 then the tracker moves round 90 counts till it points at 90degrees. There are a number of extra things to note, such as degrees are actually counted as a 4 digit number so 090 = 0900. also counts are QUADRATURE etc.
The program has gone through many revisions. I have spent a long time testing PWM, velocity, slow and fast braking etc, but find the best results have been from the more simple: 'If AZIMVAL<POSCNT then go one way and visa versa. If AZIMVAL=POSCNT then stop'. This sometimes works and stops, but over-runs a few degrees, and sometimes oscillates within the SETPOINT or '1deg' either side. What is happening is, as the SETPOINT is passed the program re-sets AZIMVAL, so there can be no more comparisons before actually stopping.
What I am hoping for is at SETPOINT set BRAKE and wait for a split second till stopped before updating AZIMVAL so it can keep comparing. Later if necessary, I can widen the each side of SETPOINT degrees till the BRAKE stops at or near SETPOINT. I think the fast oscillations with introduce a kind of PWM, but I'm not sure, so hopefully only '1' bounce will occur.
The program is ok above the '////////////////////////////// line. (Check for errors)
I hope it's all understandable and looking forward to any replies. (I will update this post if there are any errors.)
EDIT: I've made some progress with the attached program. This now stops at the SET POINT. It will receive data at 1sec intervals, but perhaps errors if the data is too far to move before the next is received. It would be better if the incoming data was held ready for the next input instead of as it is now. Also the timer0 needs setting.
Camerart.
Firstly, I have other threads on this subject open, but they could be confusing!! e,g, (https://www.electro-tech-online.com/threads/gps-data-tracker-for-antenna-aiming.140729/) So I hope that this one is clearer? I have attached a program, that has been written and helped by others on this and other forums, so thanks to them.
What the program does is read an azimuth or AZIMVAL angle as a 3x digit number e,g, 090 = 90degrees. The tracker compares this with a base angle POSCNT set to '0' at north and counts round 360 degrees, so if AZIMVAL = 090 then the tracker moves round 90 counts till it points at 90degrees. There are a number of extra things to note, such as degrees are actually counted as a 4 digit number so 090 = 0900. also counts are QUADRATURE etc.
The program has gone through many revisions. I have spent a long time testing PWM, velocity, slow and fast braking etc, but find the best results have been from the more simple: 'If AZIMVAL<POSCNT then go one way and visa versa. If AZIMVAL=POSCNT then stop'. This sometimes works and stops, but over-runs a few degrees, and sometimes oscillates within the SETPOINT or '1deg' either side. What is happening is, as the SETPOINT is passed the program re-sets AZIMVAL, so there can be no more comparisons before actually stopping.
What I am hoping for is at SETPOINT set BRAKE and wait for a split second till stopped before updating AZIMVAL so it can keep comparing. Later if necessary, I can widen the each side of SETPOINT degrees till the BRAKE stops at or near SETPOINT. I think the fast oscillations with introduce a kind of PWM, but I'm not sure, so hopefully only '1' bounce will occur.
The program is ok above the '////////////////////////////// line. (Check for errors)
I hope it's all understandable and looking forward to any replies. (I will update this post if there are any errors.)
EDIT: I've made some progress with the attached program. This now stops at the SET POINT. It will receive data at 1sec intervals, but perhaps errors if the data is too far to move before the next is received. It would be better if the incoming data was held ready for the next input instead of as it is now. Also the timer0 needs setting.
Camerart.
Attachments
Last edited: