Hi,

The van is diesel, so no ignition noise. Re-measured phone cable 2Mtrs not 1 1/2.

First test was 'with same failing set-up' put shade over GPS in case it was overheating, (it's been hot and sunny). No difference.

Removed existing set-up, and it still failed away from the van.

This is a new circuit with only 7805 regulator, PIC, XTL and UART. Running from a battery. The circuit to GPS 5V from same regulator.

Changed phone cable for screened cable, and it hasn't failed so far

C

 

hi C,
Try this program, attached is CamLog.bas .hex and logged text file.

The Ref Coords in the program are 50N 1W.

The program outputs a valid GPGGA message and the Azimuth and Altitude.

Eric

Hi E,

I tried your hex and it works.

With the other TXT for me to compile, there was nothing between the '############### lines. I presume it should be instructions for me to add the base location?

C.

 

Hi E,

I tried your hex and it works.

With the other TXT for me to compile, there was nothing between the '############### lines. I presume it should be instructions for me to add the base location?

C.

hi C,
Yes, the '########### is an area for adding extra comments.

How did the rewire of Neo6 to PIC on the van go.?

This is a new circuit with only 7805 regulator, PIC, XTL and UART. Running from a battery. The circuit to GPS 5V from same regulator.

Changed phone cable for screened cable, and it hasn't failed so far

Good...
E

 

Hi,

Here is an SVG file (Keeps size the same) of the opto disk. [4 quadrature counts x 9 at 100:1 gear ratio giving 0.1 degree at the spindle] I have made Lith film copies, and waiting to see the results of a laser print before making the mounting.

Cheers, Camerart

 

hi C,
Ref the Elevation, do you want the Angle measured from the Base station to the Remote, assuming the Base station is the Datum or from say Mean Sea Level [MSL]

Ref the Range from Base to Remote do you want the Ground path range or the Elevated range.?

E

 

hi C,
Ref the Elevation, do you want the Angle measured from the Base station to the Remote, assuming the Base station is the Datum or from say Mean Sea Level [MSL]

Ref the Range from Base to Remote do you want the Ground path range or the Elevated range.?

E

Hi E,

I would like the Elevation angle from the base station to the remote, and the elevated range, please.

C.

 

hi C,
Ref the Elevation, do you want the Angle measured from the Base station to the Remote, assuming the Base station is the Datum or from say Mean Sea Level [MSL]

Ref the Range from Base to Remote do you want the Ground path range or the Elevated range.?

E

Hi Eric,

This subject has been broached before!

I have been puzzling about Altitude angles, E,g, In the unlikely event of a 'remote' passing directly overhead would the tracker need to spin 180 degrees at directly above? or could the 'remote' go from horizon to the opposite horizon with the Azimuth staying more or less the same?

This isn't important if it causes extra programming, but I thought it would be better to mention it, before you go too far with the program.

C.

 

hi C,
I am not querying the 'overhead' or below horizon, I am asking what do you consider the Datum altitude of the base station to be.???

Zero or its altitude above MSL.

E

EDIT:
A little additional information.
In order to tilt the scanning head to the correct Elevation, the Altitude of the Base station will have to be available to the PIC maths routines.
Example:
Assume the Alt of the remote is indicating say 1000mtr, thats above MSL.

If the base station is at 500mtr above MSL, we have to subtract the Base Alt from the Remote Alt, to get the correct Alt value to calc the Atn value from the 'ground' distance/range, for the tilt degrees.

Eric

 

hi C,
I am not querying the 'overhead' or below horizon, I am asking what do you consider the Datum altitude of the base station to be.???

Zero or its altitude above MSL.

E

EDIT:
A little additional information.
In order to tilt the scanning head to the correct Elevation, the Altitude of the Base station will have to be available to the PIC maths routines.
Example:
Assume the Alt of the remote is indicating say 1000mtr, thats above MSL.

If the base station is at 500mtr above MSL, we have to subtract the Base Alt from the Remote Alt, to get the correct Alt value to calc the Atn value from the 'ground' distance/range, for the tilt degrees.

Eric

Hi Eric,

My last post was something I was puzzling regarding quadrants, and not the answer to your initial question.

To answer your question: Hopefully at initialisation, the tracker will read the onboard GPS and extract it's Altitude, which will be entered into it's Altitude datum, then it will switch to reading the remote GPS and compare the two Altitudes.

I hope this answers your question ok.

C

 

Hi Eric,

My last post was something I was puzzling regarding quadrants, and not the answer to your initial question.

To answer your question: Hopefully at initialisation, the tracker will read the onboard GPS and extract it's Altitude, which will be entered into it's Altitude datum, then it will switch to reading the remote GPS and compare the two Altitudes.

I hope this answers your question ok.

C

hi,
OK.
I will include the Base station Alt1.
The results for the tilt elevation are looking good, I will post a logging prog.

E

 

Hi Eric,
...
I have been puzzling about Altitude angles, E,g, In the unlikely event of a 'remote' passing directly overhead would the tracker need to spin 180 degrees at directly above? or could the 'remote' go from horizon to the opposite horizon with the Azimuth staying more or less the same?
...

I'm not Eric, but you know I'm going to chime in anyway.

Since your azimuth rotation needs to be 0-359 degrees on a flat plane, your elevation needs to be 90 dgrees from flat plane up to directly vertical.

Or the elevation needs to be from (say) -10 degrees to +90 degrees because you mentioned earlier some possible instance where the base station is higher than the target.

So in both cases if the target passes directly overhead, travelling directly from E to W, the azimuth will be 90' (E) right up to the point when it is overhead, then will change to 270' (W) from that instant on. So yes, the azimuth rotation needs to rotate 180' while it is going overhead.

In practice this should be a non-event. Almost all instances will NOT be directly overhead, so the azimuth degrees will change over a number of seconds and the array will rotate as it is changing.

 

I'm not Eric, but you know I'm going to chime in anyway.

hi Roman,
Feel free to chime anytime.
Lets know how your Neo6 project goes.

hi C,
I have tested the latest tracker program for calculating the Range, Azimuth, Altitude and Elevation, it looks OK.

Ref the Elevation, rather than a 180deg approach, an option would be a 0deg thru 90 deg East, then 90 deg thru 0deg West, this would keep the 'units' as the Eastings/Northings.

eg: target moving directly overhead from East to West would show...
0degE, 10degE......90degE [overhead at 90deg] then 89degW, 80degW....etc.
I would consider this a more user friendly displayed elevation.
The scanner motor drive program part will have to be decided when you have finished your tests.

Any elevation less than 0deg would be a negative value.

If you have a PIC pin free I would consider using it to detect a 'test' switch while testing the project.
You could then select serial out the $GPGGA message OR the Ran, Azim, Alt, Elev.

I am writing the programs to output RS232 serial data rather than to the LCD, as this will allow you to get a hard copy of your tests. Later on you will have to decide which parameters you want to LCD.

Eric

 

I'm not Eric, but you know I'm going to chime in anyway.

Since your azimuth rotation needs to be 0-359 degrees on a flat plane, your elevation needs to be 90 dgrees from flat plane up to directly vertical.

Or the elevation needs to be from (say) -10 degrees to +90 degrees because you mentioned earlier some possible instance where the base station is higher than the target.

So in both cases if the target passes directly overhead, travelling directly from E to W, the azimuth will be 90' (E) right up to the point when it is overhead, then will change to 270' (W) from that instant on. So yes, the azimuth rotation needs to rotate 180' while it is going overhead.

In practice this should be a non-event. Almost all instances will NOT be directly overhead, so the azimuth degrees will change over a number of seconds and the array will rotate as it is changing.

Hi Roman,

It took a while for the penny to drop, but I'm now in complete agreement with you.
The tracker azimuth must spin as the remote goes overhead.

Keep chiming

C

 

hi Roman,
Feel free to chime anytime.
Lets know how your Neo6 project goes.

hi C,
I have tested the latest tracker program for calculating the Range, Azimuth, Altitude and Elevation, it looks OK.

Ref the Elevation, rather than a 180deg approach, an option would be a 0deg thru 90 deg East, then 90 deg thru 0deg West, this would keep the 'units' as the Eastings/Northings.

eg: target moving directly overhead from East to West would show...
0degE, 10degE......90degE [overhead at 90deg] then 89degW, 80degW....etc.
I would consider this a more user friendly displayed elevation.
The scanner motor drive program part will have to be decided when you have finished your tests.

Any elevation less than 0deg would be a negative value.

If you have a PIC pin free I would consider using it to detect a 'test' switch while testing the project.
You could then select serial out the $GPGGA message OR the Ran, Azim, Alt, Elev.

I am writing the programs to output RS232 serial data rather than to the LCD, as this will allow you to get a hard copy of your tests. Later on you will have to decide which parameters you want to LCD.

Eric

Hi Eric,

Your Elevation reasoning is perfect.

I have free pins for a 'test' switch, e,g, pins 2-5.

Regarding RS232 all fine.

C

 

hi Roman,
Feel free to chime anytime.
Lets know how your Neo6 project goes.
...

Yeah it's the first time I've played with the Neo6, they look good at $16 each on ebay.

All I've done so far is plug it into the PC and run FoxGPS freeware at 9600 baud to see the satellites and signal strengths etc.

At this point the Neo6 looks to be better than the Lea6 that I'm used to, the Neo gets more satellites and slightly better signal strengths in the same indoor location.

Actually at $16 each I'm thinking of buying a few more Neo6's, they can go inside clocks and I want to make a GPS disciplined frequency meter which is accurate to about 10 -9. I have a couple of xtal oven test boards i made that can be GPS disciplined.

 

Yeah it's the first time I've played with the Neo6, they look good at $16 each on ebay.

All I've done so far is plug it into the PC and run FoxGPS freeware at 9600 baud to see the satellites and signal strengths etc.

At this point the Neo6 looks to be better than the Lea6 that I'm used to, the Neo gets more satellites and slightly better signal strengths in the same indoor location.

Actually at $16 each I'm thinking of buying a few more Neo6's, they can go inside clocks and I want to make a GPS disciplined frequency meter which is accurate to about 10 -9. I have a couple of xtal oven test boards i made that can be GPS disciplined.

Hi Roman,

Are you thinking about programming the GPS module? I think the update rate can be changed. I haven't tried yet, as I don't want to break anything at the moment.

Your clock sounds interesting!

C.

 

I progammed the old LEA6 which was a bit of a chore on a PIC because I had to write the code from scratch including the checksums and responses etc.

For clock use you can put them in ground stationary mode, most come standard in ground vehicle mode I think. But it's not really necessary, the 1PPS timepulse pin is easily available for precision timing apps, and the serial output gives a very accurate ASCII clock every second anyway.

If you are interested in clock type stuff I recently tested a $1.99 ebay clock module against a GPS and made a thread;
http://forum.allaboutcircuits.com/showthread.php?t=99839

 

I progammed the old LEA6 which was a bit of a chore on a PIC because I had to write the code from scratch including the checksums and responses etc.

http://forum.allaboutcircuits.com/showthread.php?t=99839

It looks like you miss-understood me. I meant program the GPS module itself, to make it change it's outputs etc, to the PIC

C

 

No that's what I'm talking about too. I got the PIC to reprogram the GPS block to change its operation.

You can make it (the GPS block) display different NMEA sentences, different updating, different freq on the 1PPS timepulse pin etc.

For my purposes at the time I tested putting it into different modes like aircraft mode or stationary mode, to test the effect on clock accuracy. I also changed the 1PPS signal to various frequencies and tested that.

The Ublox reference manuals and appnotes are comprehensive but unwieldy. It's not a job for the fainthearted! These days you can probably just get a windows app to program the GPS block for you with much less hassle.

 

No that's what I'm talking about too. I got the PIC to reprogram the GPS block to change its operation.

You can make it (the GPS block) display different NMEA sentences, different updating, different freq on the 1PPS timepulse pin etc.

For my purposes at the time I tested putting it into different modes like aircraft mode or stationary mode, to test the effect on clock accuracy. I also changed the 1PPS signal to various frequencies and tested that.

The Ublox reference manuals and appnotes are comprehensive but unwieldy. It's not a job for the fainthearted! These days you can probably just get a windows app to program the GPS block for you with much less hassle.

Hi Roman,

Thanks. I'll come back to this later.

C