Re: Variation on Ian's KD8CEC uBitx software (based on his 1.04 release for now) and ATU sketch. #ubitx

Tim Gorman

According to your second link the higher priced unit from oddwires uses
lcd(0x20, 4, 5, 6, 0, 1, 2, 3, 7, NEGATIVE) as it is an "mjkdz"unit.

The lower priced one probably uses the more common

This site also has a nice discussion:

I'm going to check the backpacks I threw away to see if they are mjkdz

I agree we should standarize on the cheaper ones! They seem to be more
standard everywhere.

It looks as if the LiquidCrystal_I2C lcd(x,y,z.....) function is to
create an object (whatever that means). The lcd.begin(16,2) is to
initialize the lcd itself.

So the lines are doing two different things.

The w0eb et al. software does just that:
LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);

I can't see where the test software from john does that. Maybe I'm
missing something.

tim ab0wr

On Tue, 10 Apr 2018 08:45:56 -0700
"Jerry Gaffke via Groups.Io" <> wrote:

You might email or call Oddwires, see what they say is different
about the two. I think the more expensive one just has a less common
parallel pin-out from PCF8574 i2c chip into the lcd display.
They have to explicitly set the pins, whereas the cheap one uses the
default pins.

Enough of these being sold that there are now clones of clones of
clones. Choosing one because the board layout looks similar to one
that failed is probably not a good plan.  Better to just choose a
vendor you trust.

There are lots of "how I done it" webpages regarding these i2c
displays, but nothing I've found really describes all the gotcha's in
one place. Weird that the libraries don't include a decent Readme.

Here's an interesting page that better describes all those args
to some of the Liquid_Crystal_I2C libraries:
He never mentions using a scanner to figure out what the i2c address
is. He shows two primary ways those parallel pins might get stirred,
the fact that backlight could be POSITIVE or NEGATIVE, and two of the
16 or so i2c device addresses you might run into:

###### Some example of initialization codes (try them to find one
that suitable for your device), instantiated on object *lcd* :

* LiquidCrystal_I2C *lcd* (0x20,2,1,0,4,5,6,7,3,POSITIVE);
* LiquidCrystal_I2C *lcd* (0x27,2,1,0,4,5,6,7,3,POSITIVE);
* LiquidCrystal_I2C *lcd* (0x20,4,5,6,0,1,2,3,7,NEGATIVE);

This page shows a variant of the first entry above, the last two args
giving the backlight pin and polarity are not included:
    // addr, en,rw,rs,d4,d5,d6,d7 LiquidCrystal_I2C lcd ( 0x27 , 2 ,
1 , 0 , 4 , 5 , 6 , 7 ); // Set the LCD I2C address Anyways, stirring
those parallel pins is something to try for those with apparently
dead i2c displays. Hopefully the Arduino world is slowly coalescing
into one version of parallel pinout, since users with i2c backpacks
that don't conform to the majority of the documentation will be
wanting their money back.

If you run into an i2c lcd with the "wrong" polarity on the
backlight, it will probably just stay lit by default if you don't
mess with the backlight in your code.

Here's a wiki page describing some of the various lcd interfaces you
can run into that are supported by the Malpartida library, including
a brief mention of the i2c interface:!configurable-i2c-address-modules

And this old post describes confusion regarding whether i2c device
addresses are 7 or 8 bits:

Hopefully we can all settle on one backpack type and one library.
For US customers at least, I'd tend toward the cheaper backpack from
oddwires, which also comes mounted on an LCD if you wish.


On Tue, Apr 10, 2018 at 07:19 am, Tim Gorman wrote:

The $2 backpack looks like the ones I have. I might give the $5 one
a try and see how it works. The code they give for it uses the pin
assignments although with a negative type instead of positive

Join to automatically receive all group messages.