Why slotted? And why so many slots?
Your encoder goes on the motor shaft, which is 100:1 ratio compared to antenna movement (assuming no final gear ratio).

A slotted disk is much harder to make! I suggest using a reflective sensor and a printed disk with white and black stripes. Very easy to make.

If you have 9 white and 9 black stripes around the circumference (a "9 line" encoder) with quadrature encoding gives 36 quadrature events per rotation.

Adding your 100:1 gearing means you will get 3600 encoder events per output shaft rotation, or 10 encoder counts per degree that the antenna moves.

Since we already discussed that the antenna will be fine within a 5 degree range, having 10 counts per degree is still excellent.

Remember that the less encoder counts per degree, the less encoder events that have to be handled in software per second of movement. That eases the workload of the processor.

Hi again Roman,

I've re-read this post, and it's looking more feasible as I understand better.

Can you clarify? Am I correct that with this method, there would be 1/10 of a degree output movement per quadrature event?

I think the encoding will be carried out on external chips (one for each motor) to the main PIC. Is this speed (2400 x 9 dark/light) ok?

It would be easier for me, mechanically to work on the 'fast' end of the motor, but thought it added more complexity to the calculations.

C.

 

No, it's definitely the best way; putting a simple, easy, reliable encoder on the "fast" shaft of the motor itself.

If your motor maxes out at 2400 RPM that is 40 revs per second, * 36 encoder events per rev = 40*36 = 1440 encoder events per second max. That is a trivially low frequency.

Your PIC can directly sense encoder events in a timer interrupt, and read both encoders (total of 4 input pins) every interrupt. The software to read two encoders is very fast and simple.

A timer interrupt that runs at 0.5mS (2000 Hz) will easily handle both encoders at 1440 Hz max, the only requirement is the interrupt freq must be >= to the max encoder freq.

Here is some extremely fast code that reads two
quadrature encoders in every interrupt;

// Here is C code I used to read both the TrackBall Horiz(X) and Vert(Y) encoders;

//----------------------------------------------------
// read BOTH encoders
encoder = PORTB;
//----------------------------------------------------
// check for any change of X encoder pins
newX = (encoder & 0b11000000);
if(newX != lastX)   // if changed
{
  // now check direction (if newA != oldB)
  if(newX.F7 != lastX.F6) x_value++;
  else x_value--;

  lastX = newX;
}

//----------------------------------------------------
// check for any change of Y encoder pins
newY = (encoder & 0b00110000);
if(newY != lastY)   // if changed
{
  // now check direction (if newA != oldB)
  if(newY.F5 != lastY.F4) y_value++;
  else y_value--;

  lastY = newY;
}
//----------------------------------------------------

I used it to read X and Y encoders for this "miniature trackball" project;
http://www.romanblack.com/trackball.htm

 

No, it's definitely the best way; putting a simple, easy, reliable encoder on the "fast" shaft of the motor itself.

If your motor maxes out at 2400 RPM that is 40 revs per second, * 36 encoder events per rev = 40*36 = 1440 encoder events per second max. That is a trivially low frequency.

Your PIC can directly sense encoder events in a timer interrupt, and read both encoders (total of 4 input pins) every interrupt. The software to read two encoders is very fast and simple.

A timer interrupt that runs at 0.5mS (2000 Hz) will easily handle both encoders at 1440 Hz max, the only requirement is the interrupt freq must be >= to the max encoder freq.

Hi Roman,

Thanks, I'll move my ideas to the fast end. I'm amazed at the speeds attainable!!

At the moment I'm thinking about the mechanics, and will come back to the software later, now I know it's possible.

I looked at your code, and even though I can't read 'C' I see it is simple, but is it reading the mouse hardware, or actual raw quadrature outputs?

I notice you are changing your program to suit 16F628 PICs, will that work on 16F648A PICs also, as I have lots. Also can you compare these PICs to the PIC18F2431 please as it has encoders built in.

C

 

The code reads PORTB, which has all 4 encoder input pins (2 pins per encoder). So the raw quadrature outputs connect to PORTB.

Re the choice of PIC; the hard part is not reading the encoders but will be doing dual PWMs (to control 2 motors) and real time motion control like accel/decel. I think it would be wise to use a 18F as it is a lot faster than a 16F and 18F series are commonly available with dual independent PWM modules. As for the PIC with inbuilt encoder module, it is such a simple task (and low speed!) I would just do that in software and not get locked into using that one PIC.

I agree that it is a good idea to be "thinking about the mechanics" and even build a test setup. Then you could try a simple project to get that thing moving, tune the motion control, etc etc. That will give you a lot of useful info on the PSU and motoro drivers needed and speeds possible and hassles with decelerating to come to rest at a fixed position etc.

 

The code reads PORTB, which has all 4 encoder input pins (2 pins per encoder). So the raw quadrature outputs connect to PORTB.

Re the choice of PIC; the hard part is not reading the encoders but will be doing dual PWMs (to control 2 motors) and real time motion control like accel/decel. I think it would be wise to use a 18F as it is a lot faster than a 16F and 18F series are commonly available with dual independent PWM modules. As for the PIC with inbuilt encoder module, it is such a simple task (and low speed!) I would just do that in software and not get locked into using that one PIC.

I agree that it is a good idea to be "thinking about the mechanics" and even build a test setup. Then you could try a simple project to get that thing moving, tune the motion control, etc etc. That will give you a lot of useful info on the PSU and motoro drivers needed and speeds possible and hassles with decelerating to come to rest at a fixed position etc.

Hi Roman,

You have answered some questions I woke up with

I've found a PIC that has more than 2 motor controllers: 18F2431 Does it fit the bill?

First I intend to add the disk and interrupters to the motor, then make a test circuit.

What information goes between the motor control PIC and the main PIC and in what form?

C.

 

hi C, Ref your PM.

I could post a copy of the latest parsing program that I have working in a PIC.

Its got the all maths for range and azimuth.
Within the program I have a Hserout for ALL the parameters. Which I normally Rem' out from the Hserout for the PIC and display only on the LCD range/azimuth and altitude.
Its not got the Keypad routines.

I would suggest if you do want a copy of the program, that I unRem some of the Hserout parameters. You will in that way have the 'raw' GPS data and math results as well as the LCD data.

I assume that as you are data logging on your laptop you don't want the LCD output commands.???

Let me know what you decide.
E

 

hi C, Ref your PM.

I could post a copy of the latest parsing program that I have working in a PIC.

Its got the all maths for range and azimuth.
Within the program I have a Hserout for ALL the parameters. Which I normally Rem' out from the Hserout for the PIC and display only on the LCD range/azimuth and altitude.
Its not got the Keypad routines.

I would suggest if you do want a copy of the program, that I unRem some of the Hserout parameters. You will in that way have the 'raw' GPS data and math results as well as the LCD data.

I assume that as you are data logging on your laptop you don't want the LCD output commands.???

Let me know what you decide.
E

Hi Eric,

At the moment I am data logging with putty, and only need the $GPGGA sentences if possible, so I would appreciate the unRemmed version please.

A second point! Up to now I imagined that the directly overhead angle would be '90' degrees, with the horizon at '0' degrees, but I had the thought that if the tracker was on a mountain, then the horizon angle would be below '0' degrees. Is this a problem?

C.

 

A second point! Up to now I imagined that the directly overhead angle would be '90' degrees, with the horizon at '0' degrees, but I had the thought that if the tracker was on a mountain, then the horizon angle would be below '0' degrees. Is this a problem?

hi,
You could consider it as minus degrees, eg: -10deg below the tangential line of observation from the Earth's surface.?

If you only want to log the 'raw' GPS data from the Neo6 onto your laptop why do you need the PIC in circuit.?? Log directly from the Neo RS232 out to the Laptop using Putty,!

E

 

hi,
You could consider it as minus degrees, eg: -10deg below the tangential line of observation from the Earth's surface.?

If you only want to log the 'raw' GPS data from the Neo6 onto your laptop why do you need the PIC in circuit.?? Log directly from the Neo RS232 out to the Laptop using Putty,!

E

Hi Eric,

Minus degrees. Ok.

If I use the RAW data from the NEO-6 I get all 6 plus sentences, I used the program on #325 to extract only the $GPGGA sentence 1/second.

C.

 

...
I've found a PIC that has more than 2 motor controllers: 18F2431 Does it fit the bill?
...

I have not used that PIC but it looks quite capable as a 28pin PIC with multiple PWM outputs and inbuilt encoder module. And serial USART.

...
First I intend to add the disk and interrupters to the motor, then make a test circuit.

Great idea. I would also add a load similar (or exactly) the same as your final load. Even if you balance your antenna assembly well if will have a lot of inertia, which affects your accel/decel performance.

...
What information goes between the motor control PIC and the main PIC and in what form?
...

Well I'm a "minimalist" and like to use the absolute minimum stuff needed to get a job done.

That would be a USART serial wire from master PIC to motion control PIC, sending azi/ele coords to move to. Then maybe a single "flag" wire back from MC PIC to master PIC, as a "move in progress/move completed" flag.

So the master PIC sends the coords, the MC PIC just moves there, and sets that flag wire high while moving. In that way the master PIC does not need to receive any serial data, it can just poll the flag wire. The master is already processing GPS serial data and user inputs etc so the least data coming back to the master the better, in my opinion.

Since you are already getting experience with USART serial data to/from a PIC the inter-PIC comms should be the easy part of the project.

 

I have not used that PIC but it looks quite capable as a 28pin PIC with multiple PWM outputs and inbuilt encoder module. And serial USART.

Great idea. I would also add a load similar (or exactly) the same as your final load. Even if you balance your antenna assembly well if will have a lot of inertia, which affects your accel/decel performance.

Well I'm a "minimalist" and like to use the absolute minimum stuff needed to get a job done.

That would be a USART serial wire from master PIC to motion control PIC, sending azi/ele coords to move to. Then maybe a single "flag" wire back from MC PIC to master PIC, as a "move in progress/move completed" flag.

So the master PIC sends the coords, the MC PIC just moves there, and sets that flag wire high while moving. In that way the master PIC does not need to receive any serial data, it can just poll the flag wire. The master is already processing GPS serial data and user inputs etc so the least data coming back to the master the better, in my opinion.

Since you are already getting experience with USART serial data to/from a PIC the inter-PIC comms should be the easy part of the project.

Hi Roman,

Ok, I'll order some 18F2431 PICs.

There will be some experimentation, when it come to the antennas, with weight, balance inertia etc. I think a rule of thumb might be the better the antenna the heavier it is??, but of course light will be fine.

Minimalist good! Perhaps you can remind me about the Master PIC and the MC PIC 'chat' later, but it sounds good.

I'm finding the USART experience fascinating

C

 

hi,
You could consider it as minus degrees, eg: -10deg below the tangential line of observation from the Earth's surface.?
E

Hi Eric,

I suppose that if 0 degrees is straight above, then below the horizontal could be 'say' 100 degrees, unless there's a reason not to.

C

 

hi C,
This PIC program is RS232 I/O only, RXD from the Neo6 and TXD to the Laptop.
No LCD functions.

The program checks the $GPGGA , for the red 'G' is in that position in the Neo message.

If you need to accept/suppress any other Neo messages modify the program in the 'main' loop.

The RXD030713.txt is a working sample of a Log from my PC's RXD input from the PIC.
The PC also sends the test data, note I have modified the message lengths to demonstrate that program copes with different field lengths.

The CamLog1.txt is the PIC .bas program.

E

Note: for Ref Only
That the first 8 messages in the txt file are based on a ref coord of 50N, 2W and form a box grid of 8 coords around 50N,2W. 0deg, 1000m,, 45deg, 1414m,, 90deg, 1000m..... etc

 

hi C,
This PIC program is RS232 I/O only, RXD from the Neo6 and TXD to the Laptop.
No LCD functions.

The program checks the $GPGGA , for the red 'G' is in that position in the Neo message.

If you need to accept/suppress any other Neo messages modify the program in the 'main' loop.

The RXD030713.txt is a working sample of a Log from my PC's RXD input from the PIC.
The PC also sends the test data, note I have modified the message lengths to demonstrate that program copes with different field lengths.

The CamLog1.txt is the PIC .bas program.

E

Note: for Ref Only
That the first 8 messages in the txt file are based on a ref coord of 50N, 2W and form a box grid of 8 coords around 50N,2W. 0deg, 1000m,, 45deg, 1414m,, 90deg, 1000m..... etc

Thanks very much Eric,

C.

 

hi C,
This PIC program is RS232 I/O only, RXD from the Neo6 and TXD to the Laptop.
No LCD functions.

The program checks the $GPGGA , for the red 'G' is in that position in the Neo message.

If you need to accept/suppress any other Neo messages modify the program in the 'main' loop.

The RXD030713.txt is a working sample of a Log from my PC's RXD input from the PIC.
The PC also sends the test data, note I have modified the message lengths to demonstrate that program copes with different field lengths.

The CamLog1.txt is the PIC .bas program.

E

Note: for Ref Only
That the first 8 messages in the txt file are based on a ref coord of 50N, 2W and form a box grid of 8 coords around 50N,2W. 0deg, 1000m,, 45deg, 1414m,, 90deg, 1000m..... etc

Hi Eric,

Using putty, I can't get it to print more than one sentence.

If I connect it up and switch on voltage, only 'READY' appears. If I allow the GPS to warm up before switching it into the circuit, then one sentence only appears only.

I've monitored the TX pin with an oscilloscope and I only see one burst, at switch on.

C.

 

Hi Eric,

Using putty, I can't get it to print more than one sentence.

If I connect it up and switch on voltage, only 'READY' appears. If I allow the GPS to warm up before switching it into the circuit, then one sentence only appears only.

I've monitored the TX pin with an oscilloscope and I only see one burst, at switch on.

C.

hi,
Thats strange.?
Can you post an image showing the single message that the Laptop received.?

When you say you monitored the TX, was that the TX from the PIC or the Neo.?

I would scope both the PIC and Neo outputs.?

I have already been running the PIC and PC this morning and it works without any problems.

E

 

hi,
Thats strange.?
Can you post an image showing the single message that the Laptop received.?

When you say you monitored the TX, was that the TX from the PIC or the Neo.?

I would scope both the PIC and Neo outputs.?

I have already been running the PIC and PC this morning and it works without any problems.

E

Hi Eric,

Putty1 shows switch on 'No GPS'
Putty2 shows GPS switch in after 'warm up'
I've erased location numbers, but it looked ok before.

I monitored the RX on the PIC (GPS) with Putty which shows endless, all types of sentences. The Oscilloscope shows, endless bursts.

The TX on the PIC with putty, shows: (See attachments) With oscilloscope, at switch on, 1x burst (Probably READY) then when GPS is switched in 1x burst only.

I'm not sure what it tells me, that your circuit works ok, and mine doesn't

C.

 

hi C,
Thats a little puzzling?
Look thru the basic program listing I posted and rem out the line marked in BOLD.
That should let everything thru that the Neo sends.
Run a test and see what you get on the Laptop.
I will re-look at the working setup here, se if I can duplicate your problem.

main:
If msgflg = 1 Then

If str1(4) <> "G" Then Goto etm
For ix = 1 To 80
Hserout str1(ix)

If str1(ix) = 0x0a Then
'''Hserout CrLf
msgflg = 0
Goto etm
Endif

 

hi C,
Thats a little puzzling?
Look thru the basic program listing I posted and rem out the line marked in BOLD.
That should let everything thru that the Neo sends.
Run a test and see what you get on the Laptop.
I will re-look at the working setup here, se if I can duplicate your problem.

main:
If msgflg = 1 Then

If str1(4) <> "G" Then Goto etm
For ix = 1 To 80
Hserout str1(ix)

If str1(ix) = 0x0a Then
'''Hserout CrLf
msgflg = 0
Goto etm
Endif

Hi Eric,

Same result, 1x sentence, but all types.

(I'm not sure if it helps, but the 'faulty' program at #325 still works, and types endless selected messages, with $GP*** cut from the beginning)

C.

 

hi C,
Try changing the 4 to a 5 in this program line
If str1(5) <> "G" Then Goto etm

This should allow only the $GPGGA message thru and block all other
$GPG.. S,,, T,, B etc messages

At the moment all messages with 'G' in the 4th position are being accepted and the TXD cannot keep a lock.

Let me know the result.
E

EDIT:
I have run some tests with str1(5) <> "G" and it works OK
The TXD into the PIC is at 10 messages per sec, with every 10th message a $GPGGA message and the others using $GPGxx etc.... randomised messages.