Getting I2C hd using 44780 running

Some time ago I got help to run an I2C LCD (20, 4) using hd 44780 library. A computer crash made all that stuff disappear. The succesful test scetch I wrote was lost and now I don't manage to get the LCD running together in my GPS Project.

The beginning of the code is:

#include <TinyGPS++.h>
#include <SoftwareSerial.h>

#include <hd44780.h>

#define BACKLIGHT_PIN     13

//LiquidCrystal_I2C lcd(0x38, BACKLIGHT_PIN, POSITIVE);  // Set the LCD I2C address
hd44780 lcd();// 0x38, BACKLIGHT_PIN, POSITIVE);  // Set the LCD I2C address

Compiler resonce is:

BasicExample_my_own_6:10: error: invalid abstract return type 'hd44780'

 hd44780 lcd();// 0x38, BACKLIGHT_PIN, POSITIVE);  // Set the LCD I2C address

 ^

In file included from C:\Users\User\Documents\Arduino\BasicExample_my_own_6\BasicExample_my_own_6.ino:5:0:

C:\Users\User\Documents\Arduino\libraries\hd44780/hd44780.h:85:7: note:   because the following virtual functions are pure within 'hd44780':

 class hd44780 : public Print

       ^

In file included from C:\Users\User\Documents\Arduino\BasicExample_my_own_6\BasicExample_my_own_6.ino:5:0:

C:\Users\User\Documents\Arduino\libraries\hd44780/hd44780.h:384:14: note: 	virtual int hd44780::iowrite(hd44780::iotype, uint8_t)

  virtual int iowrite(hd44780::iotype type, uint8_t value)=0;// mandatory

              ^

C:\Users\User\Documents\Arduino\BasicExample_my_own_6\BasicExample_my_own_6.ino: In function 'void setup()':

BasicExample_my_own_6:29: error: request for member 'begin' in 'lcd', which is of non-class type 'hd44780()'

   lcd.begin(4,20);

       ^

BasicExample_my_own_6:30: error: request for member 'clear' in 'lcd', which is of non-class type 'hd44780()'

   lcd.clear();

       ^

BasicExample_my_own_6:31: error: request for member 'print' in 'lcd', which is of non-class type 'hd44780()'

   lcd.print("Starting...");

       ^

exit status 1
invalid abstract return type 'hd44780'

Can You who once helped me give me a push?

If using the hd44780 library with a LCD using an I2C expander, you need to also include Wire.h and hd44780ioClass/hd44780_I2Cexp.h. To see how to set up the basic sketch, go to File, Examples, hd44780, ioclass, hd44780_I2Cexp and load and run the HelloWorld example. Don't forget to change the LCD geometry to match your display.

Lots and lots of thanks! Incredible.
Now I can send messages to the I2C LCD! Copying Serial monitor test data to the I2C LCD ought to be quite straight forward.

I don't remember that the set up of the hd 44780 was that sophisticated. Maybe I got such a good and complete example that I didn't notice the difficulties.

Your Quick answer and the result of success lifts my day, my days, a lot!

Could Forum improve the Karma++ into Karma++(int a)? Maybe long....
Whow! You really made my day gF!

Formatted output to the I2C LCD is working now!
God bless You and Your patience gF!

Speed, altitude, number of satellites, date and time now shine one the 4 row, 20 columns I2C LCD. WHOW!

Sweet, good going.

A few, not highly important, questions from playing with the running module.

What does the Hdop parameter stand for? It looks quite a bit jumpy.
The Altitude parameter seems to vary quite a lot from time to time and it is given in centimeters. The from time to time changing values varies as much as tenths of meters.

Do know any data treatment of those parameters to make them more accurate, more useful?

Thanks from a very pleaced Railroader.

What does the Hdop parameter stand for? It looks quite a bit jumpy.

HDOP stands for Horizontal Dilution Of Position. The lower the number the better the positional accuracy.

The Altitude parameter seems to vary quite a lot from time to time and it is given in centimeters. The from time to time changing values varies as much as tenths of meters.

Altitude, like lat and long, also depends heavily on how many satellites are in view and their relative positions. The GPGSA sentence has a VDOP as well as HDOP entries.

Do know any data treatment of those parameters to make them more accurate, more useful?

HDOP depends on how many satellites are in view and their positions, there is little that you can do to improve that except provide the clearest view of the sky possible. Altitude might be improved by averaging several readings, though I don't know if that will really improve accuracy or just smooth out the variations.

I am no expert on GPS so may not be 100% correct. If you have more questions (or better answers than mine), maybe post in the Sensors section. There are a couple of members that know a lot more than I that watch that section.

Thanks again!

I Googled and found this: Dilution of precision (navigation) - Wikipedia

Vdop is not supplied by the library….

I will raise the question in Sensor Forum and see what they say.

Situated some 5 feet into the room I read 7 - 11 satelites…

Running the application from a Power Pack works fine and makes it portable without housing. Fun, fun and interesting to compare the speed with my Garmin Zumo 550.

If you look at the TinyGPSP+ library Wiki you will see that there is a way to do Custom NMEA Sentence Extraction. You could extract the VDOP that way.

Hi and lots of thanks gF!

Today I brought the project with me in the car and tested it.
Speed works very well and that was the goal of the project. Altitude data were poor a little bit too often. Just added "Cource", heading, to the display. Hard to verify that resting on a an indoor table....

I tried to follow Your tip and have been reading the link: GPS - NMEA sentence information
I got overloaded by all info and didn't find the Vdop…. Ålenty of ¤GPxxxxxxx messages.

One more question about loop() frequency.

The man program starts like this:

void loop()
{
while (mySerial.available() > 0)
gps.encode(mySerial.read());
//Then query it for the desired information:

// if (gps.altitude.isUpdated())
if (gps.altitude.isValid())
{
void loop()
{
while (mySerial.available() > 0)
gps.encode(mySerial.read());
//Then query it for the desired information:

// if (gps.altitude.isUpdated())
if (gps.altitude.isValid())
{
.
.
.
.
.

eventually a delay(100)…. delay(500)….
}

At the end I have expeimented putting a delay of some 100 mS.
Is that any good or should I allow the loop to run as fast as it executes?
I don't se any abvious difference using a delay or no delay. Various real time occurencis gives different and, for me, unexplainable results.

Ooops. There is only one loop(). Contact bouncing when copying?

Thanks a lot!
The Vdop parameter is now received!

Hi gF!

i have been working on the project and testing it quite a lot.

In my car it runs very well showing good data. Testing it on one special railroad the result was a bit disappointing. Speed values sometimes dropped by 20% and stayed in that wrong set of values. My guess is that high trees surrounding the railroad tracks created disturbance for the GPS antenna.

The coming weekend I will test the project on another railroad earlier giving a more positive result.

Anything You want to comment?

In order to show that loop() is running I print out "<" and ">" on the I2C LCD.

Printing the chars "<" and ">" sometimes goes wrong. The ">" is printed, on the LCD as some Japaneze character with lots of pixels being on.

Restarting by disconnecting power and reconnecting power cures it.

The chars are prepepared in an array, at the end of this piece of code.

#include <SoftwareSerial.h>
#include <TinyGPS++.h>

#include <Wire.h>
#include <hd44780.h>
#include <hd44780ioClass/hd44780_I2Cexp.h>

//#define BACKLIGHT_PIN     13

hd44780_I2Cexp mylcd; // declare lcd object: auto locate & config exapander chip

// LCD geometry
#define LCD_COLS 20
#define LCD_ROWS 4

// The TinyGPS++ object
TinyGPSPlus gps;
TinyGPSCustom vdop(gps, "GPGSA", 17);//Pick upVdop

//Create GPS channel using digital i/o
#define RX 2
#define TX 3
SoftwareSerial mySerial(RX, TX);  // pick any 2 unused digital pins (not pins 0 or 1)

#define time_adj 2// adjust: +1 for winter time, +2 for summer time
#define arr_size 20

int act_cnt = 0;
char activity[] = "<><>";

They are printed out using

  if (millis() > next_act_print)
    {
      mylcd.setCursor(19, 3);
      mylcd.print(activity[act_cnt++ % 2]);
      next_act_print = millis() + 500;
    }

Does anybody have an idea how this misprinting is happening?