DIY Marine GPS using enhanced GPS Module, u-blox NEO-6M GPS receiver, and ILI9341 Module controlled 2.8" Color TFT LCD #2060
Replies: 9 comments
-
Posted at 2014-09-27 by JumJum Hello allObjects, |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-09-27 by @allObjects @jumjum, there are multiple TFT LCD displays of different size - 2.2", 2.8", 3.2",... even up to 5.7", all controllable by the ILI9341 controller chip, and therefore have all the same resolution and color depth: 320x240px 262K colors. For helpful information on Espruino site see http://www.espruino.com/ILI9341 - I know that the Buying on eBay link on this site goes for 2.2". Just search directly in eBay with above given sizes, for example: 2.8" TFT LCD. Resolution(s), Color depth(s) and interface(s) are defined by the controller. Some controllers have it all configurable. Some controllers can be cascaded to achieve higher resolutions, for example, https://www.displaytech-us.com/sites/default/files/driver-ic-data-sheet/HX8264-D02_DS_v01.pdf |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-10-01 by @allObjects In this update, the project uses the GPS module variation with the array of tuples of lineHandlers and callbacks - as discussed in http://forum.espruino.com/conversations/255757 - GPS Module, Extensions, and u-blox NEO-6M GPS receiver. This is the running code - with a first cut of the display implementation. Since the display poses significant performance challenges, expect updates, and furthermore, expect updates too for the GPS module for handling multiple GPS sentences, for which the implementation has not settled yet. As usual I (will) add shot and clip to see what's going on. Don't try to copy from below code section into Web IDE: it will corrupt the code. Download the code from uploaded navi5p.js file at the very bottom of this post.
The first shot was taken at the moment when the last digit of the time in top row was re-drawn - digit 8. The clip shows the sequence after 'warm'-reboot (send code to board, GPS already locked in). You will notice the partial drawing... because of the display's performance drawing strings... You can see code of the sort of this.cnt = ... this.cnt + ... and this.cnt2 = ...this.cnt2 + .... These are counters from 0..9 and 0..59 - updated every second - that control partial and staggered full re-draw of the data in addition to the code that triggers partial redraw only on data changes. The redrawing code is still in its infancy and needs to be refactored for less redundancy (copy-paste-modify is good only for figuring something out). The second shot was taken after returning from work with taking the GPS for a spin for the commute. The display shows - from top to bottom:
Note: the degree symbol - character - is not part of LCD controller's font - assuming the LCD controller takes the character and draws it... (@gfwilliams, is that assumption correct?) TBC - to be completed w/ some code walk through in a bit. For now, enjoy the short clips (links below):
Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-10-01 by @gfwilliams Not sure how I missed this - it looks great! @allObjects, depending how serious you are about this (and if you can spare 20 IO pins for the LCD), you could recompile your own version of Espruino with the hardware (parallel) ILI9341 support (which is much faster). |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-10-01 by @allObjects Thanks for your compliments. You did not miss anything... - Parallel driving: Was thinking about it. It for sure performs better. With serial: for complete drawing of time, 1 second is sufficient; drawing latitude and longitude takes a bit longer... What adds pain to the (re)drawing is the absence of a fixed size font (...may be I just have not discovered it yet). Your hint to use a parallel interface makes me rethink my assumption about 'who' runs the drawing: a) Espruino - or b) LCD controller... and I tend now towards assuming a) Espruino. --- Btw, I like to 'fix' hardware using software... - or more accurately - complement and be complemented by hardware. ;). |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-10-02 by @gfwilliams There's a small bitmap font built-in, or you can load more as modules: http://www.espruino.com/Fonts I should come up with a 'fast SPI' graphics driver really. If done right it should be able to support a few different modules - however the speed of If you're interested, there are other options: You can't store the whole screen in Espruino's memory, because it's just too big. However you could:
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-10-02 by @allObjects Ic. Many options. For now I have dashed the display speed challenge. With more changing data to display, this may change though, and all options will be back on the table. Fixed font for a limited number of characters / symbols in 1-bit foreground/background color mask and may be compressed/deflated will save me the storage. Using a streaming algorithm that just in time inflates two levels - first from compressed to full 1 bit mask and second from 1 to 18 bits by picking 18 bits background or 18 bit foreground depending the filter bit and sent them over a parallel interface, the display may give me the speed I could just dream of . To have performing inflations most likely require 'going underground' to (inline) assembler or using dedicated helper added to the firmware. This approach eliminates then the current drawing of a rectangle in background color before redrawing with current drawString()... ;) - Btw, with limited font options, all digits of a font should be same width, preferably two spaces and two dots (decimal points) wide, and also the -, +, and parenthesis should have this width. These measures provide the means to manageably display changing number values in fixed font and related (unchanging) labels in variable font. Time may come and make me build such a font. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-10-03 by @allObjects Extended the display with the display of the velocity. Velocity is shown in nautical miles. Code is updated. Next steps are:
Time line is open.... |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-10-03 by @gfwilliams :) Actually it's pretty neat that your display has the touchscreen on. The 2.2" ones have the foil on them, but for some unknown reason they didn't bother bringing it out to connections! |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-09-27 by @allObjects
The end goal is to have a GPS that is also connected to other inputs - such as Wind direction, Wind speed, heeling, etc. Of course: there is plenty of electronics to buy (and rely on), but it is a fun and entertaining training project to get all these things working together.
Basis for the basic GPS code (module) is the extended code as posted with title GPS Module, Extensions for handling other sentences, and u-blox NEO-6M GPS receiver on http://forum.espruino.com/conversations/255757/. Get the GPS code from there.
The gpsHandlerObject is picking up and transforming the gps receiver sentences and sending it to the navi object which displays the information on the LCD display (code below).
In this stage, the whole Hardware and Software system works as GPS / satellite driven clock... with time zone adjustment ;). Provisions for handling changes due to jitters and displaying of other essential data are in infancy to absence.
The satelliteClock.mp4 clip - link below the code - shows a send-to-board / restart phase.
The satelliteClock.mp4 clip (link below) shows a send-to-board / restart phase. Notice the nice skipping of displaying some time, and also that only the part of the string that changes is redrawn. Uncommenting line 28 will show the not redrawn part as dots followed by the part to redraw on the LCD in the console pane (see below). Most of the code of .timc() method is dedicated to that part and is combined with the time zone adjustment for display. In other words, internally, UTC is used, and converted only to local time for display.
The difference detection algorithm has though still a flaw! What is the flaw? When will it show? And how could it be fixed with practically the same code lines?
Attachments:
Beta Was this translation helpful? Give feedback.
All reactions