Saturday, June 25, 2011

GPS to 16x2 Character LCD Using an FPGA

This is a project that uses a Spartan-3E FPGA Board (Xylo-LM) to grab the serial stream transmitted by a Locosys LS20031 GPS Module and parse the messages for the latitude and longitude. The latitude and longitude values are then feed into a 16x2 Character LCD display on a push of a button.

Note: The GPS coordinates shown will not lead you to me. The GPS module at the time of recording this, was not locked onto my don't try hunting me down..else you will find yourself in the Atlantic =P

Below is a basic block diagram that helps to illustrate what the FPGA does in the system. The FPGA has 3 modules: A Serial Module, a Parser Module, and an LCD Controller Module. The serial module is only responsible for acquiring the serial data at the specified baud rate. Over sampling is used in the FPGA to help minimize bit errors.  The serial module passes the raw data to the parser module. At this point in time the raw data is the NMEA messages (with the overhead information removed, i.e. stopbit/startbit). The parser module waits for the occurrence of a '$' which indicates the start of an MTK/NMEA message. Once the '$' is received, the parser extracts the message type and checks for a "GGA" message. If the current message is a GGA message, then we extract the Latitude and Longitude based on the standard format of the GGA message. This is currently being done by counting the characters; however, counting the comma delimiters work just as well. The parser module passes the latitude and longitude data to the LCD module as it is received on the serial line. The LCD controller module handles the initialization process required to set the LCD module into an operative mode, and it handles all the timing and writing data to the display.

This is an on-going project and I plan to add many more features to it. Below are some changes that I plan on making in the future.

Future Improvements/Additions:

  • Write the serial stream from the serial module to a Block Memory or RAM
  • Read the data in a Block Memory or RAM and feed the data into the Parser Module.
  • Perform mathematical operations on the acquired data, such as computing the displacement from the current location to the last saved location.

For those interested in knowing more about this project, or want more information about certain aspects of the HDL code that I wrote, please don't hesitate to post a comment.

For those interested in the LCD controller module's code, go here: LCD Controller.
Or to download all of the related HDL files, go here:

My project was featured on Sparkfun's Main Page! Pretty cool and I got some good constructive criticism.


  1. Awesome Jon! I really need to get into FPGAs.... once my thesis is done that is

  2. Thanks Dan, yeah FPGAs are really cool and very powerful. The LCD controller module was quite an accomplishment for me. It ended up being an 11-state state machine that has 3 substates per state (a setup stage, an execution stage, and a wait stage). The LCD controller code itself took about 600 lines of code. Anyways, I will probably post a separate blog post soon that talks just about the LCD controller, because implementing that was a project in itself.

  3. Oh my that is quite the undertaking. My somewhat side project had been working on an android app. I will have to post on my blog at some point. Just today I implemented the cosine similarity function for my thesis and I seem to finally be getting good results and can finally move forward. At least for that algorithm.

  4. Cool, I have been thinking about getting into that stuff as well especially since this thing exists:

    Currently I have a lot of gadgets to experiment with though, I got an Arduino. So I probably wont venture into Android stuff for some time to come.

    Great to hear that your thesis is progressing. Make sure to let me know when your done and ready to do your thesis defense =P

  5. That IOIO is awesome! I will definitely have to get one at some point and have some coding fun. And it works with my phone!

  6. Hi...My name is ahmed ali from iraq
    I am M.Sc. computer engineering student.
    My project is on Spartan 3AN from Xilinx but I still have some troubles in it.
    Can you help by sending me your project files if you never mind?
    this is my mail

  7. Nice design for the block diagram.
    Which program are you using for this ?

  8. Hi M.Faith,
    The block diagram was made using Visio 2007

  9. hi john . I am very much interested in your project . can you please send me the code of this project .. I will be very thankful to you..

  10. please john I am waiting for the positive feedback:-)

  11. alimeraj,
    Thank you for your interest. I sent you the top level code. Hopefully you find it useful. I will probably make that portion of code publicly available at some point, but it is a little rough around the edges as of right now.

  12. Hello Jon
    great project, I have a papillio FPGA board and an Adafruit GPS module. Could you possibly send me your code as I'd like to a GPS and LCD working on the papillio.

    many thanks

  13. Hello Jon,
    forgot my email address


  14. Hello Jon,

    I have to say that it's a great project, and in fact, that's what I need to do for my final class project... hehehe... I already have the GPS module, but I am wondering if you could be so kind and lend me your code? I am working with an Altera FPGA DE0-Nano...

    Hope to hear from you soon... thanks for your help...

    BTW my mail is:

  15. Hello sir. I would like you to send me the source code an my e-mail I made something similar but I'm having trouble with it. Thanks

  16. Interesting!
    I'd like to modify the code to calculate speed and present to a 7seg display instead of LCD. Could you share with me the code?

    1. Hi Takis,
      My project might not be the "best" base-point for your project since my top level hdl only parses and writes IMMEDIATELY to the display. FYI, you should not even need to calculate the speed since it is in the VTG NMEA sentence ($GPVTG), but my guess is you are more interested in the computation side of the project anyways.

      I do have an updated version that would be more appropriate, but there are still some things that need to be fixed before I can release it to the world. Unfortunately I have been too busy with other matters to put those finishing touches on it...but I DO plan to get around to it this summer.

      With my older version of this project as a starting point, you will need to add some form of RAM (or FIFO) that you can read and write to asynchronously, have logic to convert an array of ASCII characters into a numeric value, have logic to perform your calculation(s), then feed that into some logic that drives your 7seg display.

      Anyways I placed all the HDL in a dropbox link (see the bottom of the post).

  17. Hi,
    This is awesome. Could you please post the exact parts that you used and the cost for this project? I also want to include a GPRS module so that I can transmit the data using 'wifi'. What do I need to do in order to achieve that?

    1. Hello Amit,
      Glad you like this. This project's bill of materials is more expensive than needed merely because of the FPGA board that I used. I would recommend replacing the Xylo-LM with a cheaper alternative (unless of course you want an ARM microcontroller then this is actually a pretty good buy). You can most likely reduce this BOM by about $100(USD) by going with a cheaper FPGA dev board. Here are the list of key components and prices:

      KNJN Xylo-LM: $229.95
      LCD 16x2 (HD44780 compatible): $14.95
      GPS Module: $59.95
      See the blog's in-line links for the exact product pages I purchased from

      Again, unless you need a "Hard" CPU/Microcontroller, I would recommend going with a cheaper alternative to the Xylo-LM that is just a FPGA (with some form of flash that can load the bit-file to the FPGA). This project should in theory be portable to any FPGA and the footprint of the HDL is quite small so don't worry too much about the fabric size of the FPGA.

      Unfortunately I can't provide much help on what is needed to include GPRS as I am not very familiar with the technology but for starters it looks like getting these two pieces of hardware could get you going in the right direction:
      ...and a suitable antennae

      This particular GPRS module can be interfaced via UART (or SPI) which is easy to emulate on an FPGA pin. Depending on how complex you want to get it may be easier to just do this on a Microcontroller.

      Basically to interface a peripheral to an FPGA you want to make sure that:
      1. The FPGA can be configured to work on the same logic level/type as the peripheral (i.e. 3.3V CMOS)
      2. You can understand an implement the communication protocol they use to function (such as a device that interfaces via UART and has a set of commands/responses for configuration/operation)
      3. The amount of logic you will implement wont exceed physical limitations of the FPGA fabric (unlikely for hobbists, but if you are trying to do a full fledged product on an FPGA then you may want to look into this more)
      4. The FPGA is fast enough for your application (i.e. FPGA fabric limitations and the oscillator(s) that is driving the FPGA logic)

      Note: this is not necessarily a complete list, but these were the criteria that were off the top of my head

  18. Jon,

    I was wondering what kind of host PC you used for this project. I'd like to work on these sorts of FPGA projects using the DE0 Nano board, but I've heard that FGPA synthesis requires a hefty CPU. For "smaller" projects such as this (and the LED matrix example on sparkfun), could I get away with using a Core2 2.0 ghz?

    Great project, by the way!

    1. Hi Manuel,
      The PC used during this project was a quad core i7 with 12GB RAM. While it does help considerably in terms of build speed (i.e. performing the various steps of the normal work flow such as sysnthesis, implemenation, and generating the bit stream) to have a multithreaded CPU with fast cores and lots of RAM, it is not required. For smaller projects such as this the system you have is sufficient. Projects that I have worked on for work, when built on an old single core cpu took >1 hour, while the same project built on a newer i7 could be built in <30mins, so it certainly can help when projects get big, but for starters its not really needed.

  19. Nice job! congratulations. I have 2 questions, what language did you use, VHDL? and how did you get the information from the GPS, I mean where did you? In a vector maybe?
    Sorry by my english, I don't speak it very good!

    1. Hi Daniel,
      Thanks for the feedback. Verilog was used for this particular project. The GPS info that is being parsed is "minimal" in this project, I am only pulling out "GGA" sentences and directly writing the longitude and latitude data to the LCD. In more realistic/practical applications you would most likely want to implement a dual port RAM (DPRAM) that the "parser module" writes to and your "application" would read from.

    2. You're welcome! About the DPRAM, I will consider that great idea when I improve my project, because today I could write longitude and latitude in my LCD, but I used "GLL" and goes good. I am making a robot, I'm using VHDL, but I need show the speed of the robot too, How can I do it? can you help me please? I am thinking that I can use the physic formula X = V * T, distance = velocity * time, but how can I get X and T.
      Thanks and sorry about my english again.

    3. Hi Daniel,
      You could get speed (speed over ground) by using one of the other GPS sentences such as VTG in addition to GLL or switch to a sentence that has both lon/lat and speed, such as "RMC".

      If you wanted to manually calculate it then you would need to create a conversion mechanism that takes two sets of lon/lat coordinates and converts to the "Great-Circle Distance" traveled between these two points.

      Read more about "Great-Circle Distance" here:

      See an example of the conversion here:

      The problem with this approach (using just longitude and latitude) is that it assumes elevation is held constant...which may be fine for what you are doing. But if it isn't then you need to add elevation to your sampling. In practice you would take the following data: timestamp, longitude, latitude, and elevation. In general the faster you sample the more accurate your computation of speed will be. In fact, if the longitude and latitude are the dominant "changing" positional data and you sample "fast enough" the error due to making an assumption that elevation is constant becomes negligible. But this can become a very lengthy discussion which I will leave you to look into on your own. But if you can't make this assumption, you would need to expand the "Great-Circle Distance" equation to include elevation which I image you can find somewhere on the internet. Basically you would be computing:

      speed = (a 3-dimensional great-circle distance)/(difference in timestamps)

      My 2 cents:
      I think the reality's easier to just use another GPS sentence that provides this information for you. This computation would also be fairly resource heavy for an FPGA since it would involve floating-point computation, multiplication/division.

  20. hello..i am also working to interface gps with fpga...i have done gps with pic microcontroller...i need some help regarding to veriloge code to serial interface of gps receiver with

  21. hi jon

    i am currently running a project relating to FPGA and GPS. can you share your file and code since it would be so helpful for me. i had planned to use your project as my guild line. i would be very thankful if you can help me out.

    this is my email

    i have deleted the last comment since i forgot to include my email. sorry for inconvenience.


    1. I sent you what I have to your specified email. I am not sure where the actual Xilinx project is at the moment but what I sent should be everything (you just have to import into your project)