Hi all,

I'm interested in building a GPS logger and transmitter for a weather balloon. I am wanting to avoid arduinos for this project, thinking that using a 'proper' microcontroller will fair me better in terms of me actually _learning_ something. However, I have not done any really serious programming before, and this is where I am lost. At uni we have concentrated on C++ for consoles, so I would think that C would probably be the best suited language for me. I have a pic18f4520 dev kit too, so if we could base the project on that, that would be really great. Below is a very simple sketch of my overall plan.

I envisage the system working by receiving a NMEA sentence, which is then read by the pic. This sentence is then written to an SD card in a .txt file and then transmitted via the radio module.

I have done a bit of research and quite like the look of this GPS module:
http://www.ebay.co.uk/itm/For-Ardui...sGames_RadioControlled_JN&hash=item5af565e741

And this radio module:
http://uk.farnell.com/radiometrix/ntx2-434-650-10/rf-module-tx-fm-434-65mhz-10kbps/dp/1348829

I reckon that hardware wise, the connection between uC and GPS module should be relatively straighforward, as it is just a case of connecting the GPS Tx to a uC input. I plan to use a standard SD card, and plan to use on uC port to control the SD card operation and writing. If I am correct I should need to connect 4 pins to the uC; Chip Select/Slave Select, MOSI, MISO, and data.

As for the transmission, I believe I can use PWM to send the data to the RF module which then transmits it.

However, here is where I kind of hit a wall. I have no idea as to where to begin with the programming. I have tried reading things like Microchip App notes, alas I am not clever enough to be able to understand them quite as much as I would like. Perhaps I have jumped the gun and need to consider more of the hardware layout, but I am now stuck. Compared to what we have done in uni, this is very different. I would describe myself as being able to figure my way around small projects on computer based C/C++, but the embedded side is very new to me.

If anyone can offer any help or advice, I would be really grateful. Ideally, I would love to be able to finish this before I go back to uni (ironically less access to components/test equipment/etc at uni), which will be mid January. However, I appreciate Rome wasnt built in a day. I would also like to point out that this has nothing to do with _any_ uni work/assignments/etc, I am just itching to do something.

What should I next look into?

Regards,

Sparky

 

Doable.

The first thing I would do is implement the GPS receive using the USART RX line with an interrupt-driven receive buffer. I would not attempt something like this just polling the RX line. Provide something like getchar() to pull chars out of the buffer.
Next, I would implement a buffered, interrupt-driven USART TX. Provide a putchar() routine that drops characters onto the buffer for automatic transmission.
Provide buffer-full checking, etc, for robust operation.
To test these, fire up the GPS module and send the GPS sentences to a PC terminal to verify that they are received with no errors.

Next, write the code that extracts the info that you want from the GPS sentences. You probably don't need to store every one so extract the ones you need to store. Send that info to the PC for inspection.

Once you are happy with that, verify by sending the same data to the PC using the radio link.

If all of that is ready to go, add storage. Microchip has some info here. See the referenced software You also can roll your own - an older uCHIP appnote described how but I don't know what the number is offhand. Of note: SD cards are licensed by the 'SD Card Association' which wants licensing fees. Some earlier 'non license' apnotes may be harder to find. There should be plenty of stuff on the intertubes, however.
Once you begin managing the storage, you'll be happy that you have fully buffered, interrupt-driven communications.

Sounds like fun.
Good luck!

 

Great project.

Have you considered using an EEPROM instead of SD-card? Not quite the same, but...

What equipment will be at the receiving end?

 

Thanks for the replies guys. I am sure I will be needing a lot of help.

I will do some reading on receive buffers John, although I believe I may need some help constructing the actual implementation. We shall see.

Nerdegutta, I have considered an EEPROM, but just settled for SD card as it seemed a more convenient storage. Perhaps EEPROM would be better? Each flight last about 2 hours, and I would like to store its position once every five seconds, so it wouldn't need to be too big. At the moment, I plan to use existing software to plot the location in real time:

http://tracker.habhub.org/

At least, until I become better at programming. Using the above website, people from all over my country can decode telemetry and it is then uploaded to the website in real time. They do have a guide with how to make a tracker using arduino, but as mentioned, I want to stay away from Arduino.

 

The 18F450 has SCL and SDA (Pin 18 and 23). With those you can easily connect to an EEPROM.

 

I'll second nerdegutta on the EEPROM. Not as much capacity (although should be plenty) but much easier to use. You can do the data dump via the RF link to a PC if you follow the development sequence I suggested.

I have RX/TX code in C and assembler that I can dig up if you elect to go that way. Which language/compiler are you going to use?

 

Okay thanks guys.

John, I am happy to use whichever language/compiler you suggest. I have done very little embedded work, so am all ears to the knowledgeable.

 

MikroC might be a good one for C. Its user friendly and has extensive library support for lots of peripherals including SD cards and UART, although its polled, not interrupt-driven and you'd have to write the buffering yourself..
They use their own debugger / programmer, not the cheaper PICKits. Also the free version is code-size limited and its not very much. Check out the very well written user manual here. It has lots of examples and even schematics for hooking up peripherals.

XC8/MPLABX/PICkit 2 or 3 is another way for C (and MPASM too). The free version of XC8 has no code size limitations but does not optimize like the paid versions do. The libraries are less refined than MikroC although there are lots of apnotes and uCHIP is adding stuff all the time. Check out XC8 here.

Of the two, I personally would go XC8 but I've done lots of C on PICs in HiTech (XC8 comes from it) and write my own library routines. If you are just starting out, the warm and fuzzy MikroC may be a better option, even at some additional cost.

Another way to compare the two is to consider that you can make better code cheaper with XC8 but will have to work harder and suffer a steeper learning curve. MikroC has taken care of many of the details for you at the expense of more cost and you have to do things their way which is OK for most things (probably including this one) but if what their libraries do is not what you want, you're back to writing libraries yourself anyway.

The best approach would be to detail your design a bit more to identify what functions it needs to perform (receive NEMA sentences, store info etc..) flow it out and see which compiler approach is more comfortable to you.

Either way, lots of help here at AAC.

Have fun looking at the options.