Author Topic: GPS for Graphing Calculators  (Read 3513 times)

0 Members and 1 Guest are viewing this topic.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55931
  • Rating: +3153/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • DJ Omnimaga Music
Re: GPS for Graphing Calculators
« Reply #15 on: February 05, 2014, 01:32:03 pm »
Yes, but it costs as much as a NASA mission to Mars.

Offline naib864

  • LV2 Member (Next: 40)
  • **
  • Posts: 31
  • Rating: +16/-0
    • View Profile
Re: AW: Re: GPS for Graphing Calculators
« Reply #16 on: February 05, 2014, 02:26:53 pm »
Yes, but it costs as much as a NASA mission to Mars.
Sounds expensive :D



Offline MGOS

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 336
  • Rating: +95/-0
    • View Profile
Re: GPS for Graphing Calculators
« Reply #17 on: February 14, 2014, 12:42:24 pm »
so... funny enough - two weeks before Kerm posted this - I ordered GPS module from a Chinese ebay shop. Well, after the three weeks of shipping to Europe, I could play around a bit with it and decided to do the same (sort-of) myself.

However, I don't have a 84+ where this works, neither the program nor the USB power supply. Having no idea how Kerm pulled it off to make the serial interface that good, I started from scratch, using my TI-83+ and Axe. I faced several problems though, mostly with syncing the GPS module to the calc to do not miss the start of the protocol on the one hand, and keeping both serial interfaces in sync on the other hand - which turned out to be way more difficult than I expected for such long protocols (just less than a kB for my module). I guess it is easier on a 15 MHz calc where you have fast enough interrupts to handle it. The 500 Hz interrupt just isn't sufficient for a 9600 baud port.

Keep both devices in sync is a different problem. These are four ways I could think of:
  • 1. Check the port in the main loop -> Bad for adding further functionality later
  • 2. Check the port in an interrupt -> interrupts are also to slow for this (catching the start bit)
  • 3. Request data when you need it -> I don't have a datasheet of the module so I don't know if this is possible at all
  • 4. Use a hardware asynchronous serial interface with a buffer -> I'm quite sure the TI-83+ does not have such a thing.
Eventually, I used the two latter solutions, inserting an ATtiny2313 in the serial line. It features a hardware serial port and is pretty idle so it can watch it all the time. What I did:
  • The AVR listens for any incoming GPS data on the asynchronous port and buffers the RMC string -> The data is stored so it can be called at any time
  • At any time, the calc can pull the signal lines low to request the buffered data -> The calc knows where the packet starts
  • The AVR transmits the RMC string using a synchronous (that means using two lines - clock and data - instead of one) interface -> save transmission
  • The calc only manipulates the ASCII string and displays it -> it has plenty of time to do other stuff
Furthermore, I used a Nokia battery to power it (you probably know that one - I use it in plenty of my projects). That is in a manner useful since the module draws with ~80 mA at 3.7 V quite a lot of power and would suck the calc batteries empty in no time - having it to be rechargeable is a nice feature I guess.

Some drawbacks I will fix later:
  • The AVR has only 128 bytes (!) of RAM, so it can only buffer the RMC string, not other information (such as altitude or # of satellites)
  • The code is pretty messy at the moment - I'm too ashamed to upload it ;)
The direction data only works when the ground speed is high enough.
« Last Edit: March 15, 2014, 11:54:48 am by MGOS »