Hi,

I am hoping to make a tracker that will aim antennas towards the signal, based on GPS, NMEA, AIS etc signals.

There are some parts to this project that I am capable of doing ok, these are Antennas, receiver and mechanics, but not so good at the programming and maths of it.

There are other similar projects, where I can find example code, but I'm afraid I can't read the code, as I am stuck in time with Basic, and have Oshonsoft and Pickit2 for programming the PICS.

So far I have mainly used 16F684A and 16F819 PICs for my projects, but I am guessing that there might be quite a lot of maths, so I might need a larger PIC memory for the code. The PIC will need USART, LCD and enough pins for driving motors.

Any help will be greatly appreciated.

EDIT: This is a long thread, the circuits, PICs and programs changed along the way. It may be better to start at post at POST #565, and save a lot of unnecessary reading.

Cheers, Camerart.

 

I've made progress, I have a program simulating a 4X20 LCD on 16F819.

Cheers, Camerart.

 

I suggest that based on the amount of experience you've indicated in your other thread, you shouldn't try this with a microcontroller at first. Set up a controller to act as an interface for the GPS hardware if you want, but make it pass all the information to a computer, and write a program for the computer to handle it. It'll be much easier to experiment with, and you'll be able to re-use most of the code when the time comes to move to a freestanding system on a processor.

Edited to say that you don't even need the processor in order to get started. If you have a file containing sample NMEA data, you can process it and see if the result makes sense, and keep working at it until you're satisfied. By using the same input for every trial, you can always be sure that any variation that occurs in the result is because of your software, and not simply because the incoming data has changed.

 

I suggest that based on the amount of experience you've indicated in your other thread, you shouldn't try this with a microcontroller at first. Set up a controller to act as an interface for the GPS hardware if you want, but make it pass all the information to a computer, and write a program for the computer to handle it. It'll be much easier to experiment with, and you'll be able to re-use most of the code when the time comes to move to a freestanding system on a processor.

Edited to say that you don't even need the processor in order to get started. If you have a file containing sample NMEA data, you can process it and see if the result makes sense, and keep working at it until you're satisfied. By using the same input for every trial, you can always be sure that any variation that occurs in the result is because of your software, and not simply because the incoming data has changed.

If I understand you correctly. When you say "set up a controller", are you saying:

Set up a microcrontroller and signal input (Receiver or recorded data), connected to a computer, where the data is worked on by the program in the computer. This allows the program to be edited quickly.

My computer only has USB inputs. How do I connect the controller to the computer?

Camerart.

 

Did you catch John's edit?

Edited to say that you don't even need the processor in order to get started. If you have a file containing sample NMEA data, you can process it and see if the result makes sense, and keep working at it until you're satisfied. By using the same input for every trial, you can always be sure that any variation that occurs in the result is because of your software, and not simply because the incoming data has changed.

It's a good idea, as long as you have a Basic for Windows. Visual Basic is not it... QB64 (Google it) may work.

 

Sorry, I've gone through several stages of increasingly simple suggestions!

What I'm getting at is that you should try to solve just one problem at a time. If you start with some sample NMEA sentences stored in a file on the computer, you don't need any external hardware at all. All you have to do is read the stored data and process it, and it's actually helpful that it's the same every time your program runs; it means that you'll get a consistent input. Once you have it running, try it with a different data file. Once you have it running with several different sets of stored data, try with a serial data stream coming from the actual instrumentation.

If I'm remembering right, GPS devices send out NMEA at 4800Baud, and you can easily get a serial-to-USB converter for that rate. So then you'd have a computer doing the job that you want the microcontroller to do, and once you're satisfied with the way it works, you can set up an actual controller and start to shift the software over to it. My suggestion of having the controller simply pass the data to the computer was a waste of time--the microcontroller wouldn't be doing anything useful there.

I've done this myself where a microcontroller would basically be doing an information-processing job. It's much easier to develop the algorithm on a computer than on the controller itself.

 

Did you catch John's edit?



It's a good idea, as long as you have a Basic for Windows. Visual Basic is not it... QB64 (Google it) may work.

I did read it, but I'm storing a lot in decreasing brain cells, and some drops though the cracks, I've got it now thanks.

EDIT: Do you know how to interface a USB input with QB64 please? Or is it as simple as plugging one in and looking for the COM port?

 

Sorry, I've gone through several stages of increasingly simple suggestions!

What I'm getting at is that you should try to solve just one problem at a time. If you start with some sample NMEA sentences stored in a file on the computer, you don't need any external hardware at all. All you have to do is read the stored data and process it, and it's actually helpful that it's the same every time your program runs; it means that you'll get a consistent input. Once you have it running, try it with a different data file. Once you have it running with several different sets of stored data, try with a serial data stream coming from the actual instrumentation.

If I'm remembering right, GPS devices send out NMEA at 4800Baud, and you can easily get a serial-to-USB converter for that rate. So then you'd have a computer doing the job that you want the microcontroller to do, and once you're satisfied with the way it works, you can set up an actual controller and start to shift the software over to it. My suggestion of having the controller simply pass the data to the computer was a waste of time--the microcontroller wouldn't be doing anything useful there.

I've done this myself where a microcontroller would basically be doing an information-processing job. It's much easier to develop the algorithm on a computer than on the controller itself.

Thanks for your patience John. I understand now.

 

Did you catch John's edit?



It's a good idea, as long as you have a Basic for Windows. Visual Basic is not it... QB64 (Google it) may work.

Got QB64 going. I don't think it will read ports, but as a start, can I put a string of data in an array, and use that instead. Any examples welcome.

Is this the better way of working instead of 'say' using in-circuit programming with actual ever changing data?

Cheers, Camerart

 

Is this the better way of working instead of 'say' using in-circuit programming with actual ever changing data?

Here I define "better" as "faster to make an attempt" to define the algorithm to parse and process the raw data. If I was doing this using a Microchip tool chain I could do all this just using the MPLAB simulator. I am not that familiar with Oshonsoft any more to say it can be done using those tools.

Ultimately what tool you use is your call based on your style of working.

Using "ever changing data" is the last step: first you want to give it a known set of data and see if it gives you the known set of outputs.

(Aside: I am not dinging Oshonsoft. I bought all the PIC basic tools many years ago and still get emails to update them. I just have moved on to Microchip C for the libraries.)

 

Here I define "better" as "faster to make an attempt" to define the algorithm to parse and process the raw data. If I was doing this using a Microchip tool chain I could do all this just using the MPLAB simulator. I am not that familiar with Oshonsoft any more to say it can be done using those tools.

Ultimately what tool you use is your call based on your style of working.

Using "ever changing data" is the last step: first you want to give it a known set of data and see if it gives you the known set of outputs.

(Aside: I am not dinging Oshonsoft. I bought all the PIC basic tools many years ago and still get emails to update them. I just have moved on to Microchip C for the libraries.)

It's taken me a long time to get used to Basic and Oshonsoft, and have slowly worked out how to watch variables, and memories in the simulator, so I'm pretty stuck with these. (Not really a choice any more!)

I am looking at examples in other languages, and once I've chosen my first attempt from them, I'll try to copy them over into Basic. (With help)

Ok, first I'll try an string of known data, I presume that's ok?

 

There are plenty of little free software programs you can download that will display the GPS module's output on your PC.

One that I looked at showed all the satellite azimuths and angles, and also displayed all the GPS NMEA strings as text at the same time.

My GPS module output TTL serial data, so I used a $3 ebay TTL->USB serial converter to plug it into my PC.

If you do that, you can parallel the GPS data so it goes to your PC for display AND at the same time goes to your project. The serial data is 9600 baud and you only need TX (one way comms).

That should really help debug what your project is doing in real time if your PC simultaneously displays the data and the satellite positions.

 

There are plenty of little free software programs you can download that will display the GPS module's output on your PC.

One that I looked at showed all the satellite azimuths and angles, and also displayed all the GPS NMEA strings as text at the same time.

My GPS module output TTL serial data, so I used a $3 ebay TTL->USB serial converter to plug it into my PC.

If you do that, you can parallel the GPS data so it goes to your PC for display AND at the same time goes to your project. The serial data is 9600 baud and you only need TX (one way comms).

That should really help debug what your project is doing in real time if your PC simultaneously displays the data and the satellite positions.

Can you post the name of the program please?: "One that I looked at showed all the satellite azimuths and angles, and also displayed all the GPS NMEA strings as text at the same time." it sounds interesting.

I realise that this project will be a big test of my capabilities. As the end result will be on a PIC chip, I think my main code writing will be in the Oshonsoft simulator. This will allow me to build the code up, while testing it, and it will then go straight into a PIC. I won't be able to use any input, but for testing I think I can put the data into the code in arrays. This plus programs as you suggest running in parallel, seem to be the best way for me.

 

Sorry I can't remeber the name, this was a couple of years ago now.

But it was freeware I found with a google search. From memory I would have searched for something like "freeware GPS data display".

 

Sorry I can't remeber the name, this was a couple of years ago now.

But it was freeware I found with a google search. From memory I would have searched for something like "freeware GPS data display".

Does GPS Visualiser or GPSBABEL ring any bells?

EDIT: I've downloaded GPSBABEL, and it looks a likely program for looking at the data.

In parallel, I've got a PIC wih GPS showing changing letters on an LCD

 

You mentioned the simulator and BASIC, but not which BASIC?
Calculating distance and/or bearing between points is going to be a pain in the butt (if possible at all) without trigonometry.

 

You mentioned the simulator and BASIC, but not which BASIC?
Calculating distance and/or bearing between points is going to be a pain in the butt (if possible at all) without trigonometry.

Mentioned in #11 and #13. Oshonsoft simulator.

Your correct about the Trigonometry, and I will need it, but I'm not capable myself, and hope to get help at that distant stage. What will be needed is only the Azimuth angle and elevation angle, between two points. (I think that's the correct termination)

 

hi C,
Do you have the floating point package with Oshonsoft.?

E

 

hi C,
Do you have the floating point package with Oshonsoft.?

E

Hi E,

I'm not sure! it looks as though it's an add on package. If you think I'll need it, I'll buy it.

C

 

Hi E,

I'm not sure! it looks as though it's an add on package. If you think I'll need it, I'll buy it.

C

It will make the trig maths easier and more accurate.

E