Date   
Re: Erratic tuning with my new uBitx

Chris Clarke G3SQU
 

Hi Ian

I'm nearly there!

I've installed v1.061 firmware and uBITX Memory Managerv1.01 and unchecked the option to show frequency shift in CWL and CWU modes.

Can you tell me exactly what the option "Enabled Adjust Frequency CW frequency" does when ticked (which it is)?

After enabling RIT, now RitTX and RIT A both show identical values, whilst my actual TX frequency = RIT A - CW tone frequency (which I've just changed to match the 600Hz peak of my beloved W3NQN passive CW audio filter). RIT A changes as a I tune, as expected, and Rit TX is unchanged,as expected, and I suppose you could argue that Rit TX is the frequency to which I need to tune to get back whence I started, so is that the intention? But in my head I think I should be seeing the TX frequency!

I'm still clearly still misunderstanding something, but I'm definitely getting closer!

73 Chris
G3SQU

Fw: Re: [qrp-tech] Congrats to KN4FAW and a CW primer (Long) was:New to CW build a Bayou Jumper or QCX

Jack, W8TEE
 

Love how the QRPGuys case uses magnets to hold the paddles on the case. I always worry about snapping something like that off the case during the hike. The alternative is a heavy set of paddles that can hold the USS Forrestal at anchor in a 20 knot wind...not good. With the Mega2560 holding down the fort, you could turn the keyer into a code practice oscillator, too, like my Morse Code Tutor. It has:

User-settable code speed       
User-settable sidetone frequency       
Practice sets using words
Practice set using letters
Practice sets using numbers
Practice sets using punctuation
Practice set using words and numbers together       
Practice Field Day exchanges       
Practice CW Sweepstakes exchanges       
Practice QSO's with randomly generated segments that make sense (e.g., "RIG HERE IS K2 TO VERTICAL ANT", "QTH IS
         CINCINNATI, OH", "WEATHER CURRENTLY SUCKS" [not really, but you could add it]), including random call signs
User-settable encoding using Standard or quasi-Farnsworth encoding      
On-off LCD display option--watch letters as they are sent, or turn the display off       
Portable or “wall wart” power

I'd be happy to share the schematic and code with anyone who wants to make one.

Jack, W8TEE


On Tuesday, April 10, 2018, 10:19:39 AM EDT, Ken KM4NFQ <km4nfq@...> wrote:


Hello Justin, KN4FAW,

The K3NG Arduino CW Keyer has a list of features that rivals (and maybe
exceeds) commercial keyers.
FYI: I am using a MEGA2560 clone (~$12) in my keyer, due to enabling so
many features.
The K3NG Keyer cvan also be built with an Arduino Nano. Tailor it to your
needs.
Don't forget that there is an extremely helpful online community for K3NG
projects.
https://blog.radioartisan.com/support-for-k3ng-projects/

There is a PCB enclosure PDF for the QCX at QRPGuys (Look under MISC at the
top of their web page):
https://qrpguys.com/wp-content/uploads/2017/11/qcx_pcb_chassis_110317.pdf

Regards,
Ken, KM4NFQ "Not Fully Qualified"



On Mon, Apr 9, 2018 at 9:16 PM, Justin Maynard KN4FAW <
justin.maynard27@...> wrote:

> I have not seen this keyer. Thank you for sharing it. It looks like it
> would have a lot of features that would help me. I will put one together. I
> have some spare Arduinos laying around.
> Looks like a good project while I am waiting on my QCX to arrive. I am
> currently trying to work out an enclosure and battery power supply to give
> me 16v for the QCX.
>
> Justin
> KN4FAW
>
> On Sun, Apr  8, 2018 at 01:02 pm, Ken KM4NFQ wrote:
>
> >
> > Hello Justin, KN4FAW,
> >
> > I believe I have already mentioned the K3NG Arduino CW Keyer? Some
> things I
> > would like to point out about it are that it has some features for
> > learning/practicing the Morse code. See the Wiki here:
> >
> > https://github.com/k3ng/k3ng_cw_keyer/wiki/495-CW-Training-Functionality
> >
> > You mentioned that you will be building the QCX. The QCX has a built-in
> > keyer, but you can also use an external keyer (such as the K3NG Keyer).
> > Just set the internal keyer to "Straight" in the keyer menu and plug your
> > external keyer in.
> >
> > Regards,
> > Ken, KM4NFQ "Not Fully Qualified"
> >
> >
> > On Sat, Apr 7, 2018 at 1:00 PM, Justin Maynard KN4FAW <
> > justin.maynard27@...> wrote:
> >
> > > Wow, thank you so much for all of the advice. I have been practicing
> > > copying CW both by writing and on a keyboard. I have not done much
> practice
> > > sending yet. I am going to build a code practice oscillator as well. I
> > > ordered the QCX. I think while waiting on it to arrive I will start
> gather
> > > supplies to build a nice enclosure out of copper clad pcb material,
> maybe
> > > with a built in battery for portability.
> > >
> > > The ham community truly is made of the best people. Especially these
> > > online communities. I have found more advice and inspiration from
> people
> > > like you online than I have at my local club. I see value still in my
> local
> > > club, but it I have not found many locals interested in QRP, CW, or
> > > homebrewing.
> > >
> > > Learning CW does seem to be a journey in itself. I enjoy the challenge
> and
> > > the discipline that it is giving me to practice every day. I am a
> vegetable
> > > farmer for a living, so sometimes it is difficult to find the time,
> but It
> > > is important to me, so I am making time to practice almost every day.
> > >
> > > Thank you for reaching out to me. I hope to hear many of you on the air
> > > when I get the QCX up and running.
> > >
> > > Justin
> > > KN4FAW
> > >
> >
>
>
>
>



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

Jack, W8TEE
 

I think K9HZ raises a valid question. The I2C interface would not need the extra pins since it uses the slave-master address to create a communications channel. Indeed, while the class constructor may be overloaded, I doubt that any of those throws in a bunch of unnecessary pins in the function signature. That's not to say there aren't such methods out there. I just don't know why they would be.

Jack, W8TEE

On Tuesday, April 10, 2018, 12:58:40 AM EDT, Jerry Gaffke via Groups.Io <jgaffke@...> wrote:


I'm not convinced.

>>  I find it curious that some liquidcrystal_i2c libraries have you specify the parallel pins 
>   Its to use the parallel rountines to talk serially.


Here's one of many examples on the web of a LiquidCrystal_I2C library
that doesn't care about those pin numbers:
    https://codebender.cc/example/LiquidCrystal_I2C/HelloWorld#HelloWorld.ino

 
On Mon, Apr 9, 2018 at 09:06 pm, K9HZ wrote:
I find it curious that some liquidcrystal_i2c libraries have you specify the parallel pins  Its to use the parallel rountines to talk serially.

Re: TDA2822 Audio problem #ubitx #tda2822

Dexter N Muir
 

I like it! UART to the rig - could do high-rate given logic-level, UART<->USB remote to take the place of the old RS232 (remember them ol' D9 and D25 cables and connectors?). What sort of cost?
How would the Arduino do UART? How many pins?
73
Dex ZL2DEX

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

Jerry Gaffke
 

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: 
    http://masteringarduino.blogspot.com/2013/12/lcdi2c.html
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:
    https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/schematics#!configurable-i2c-address-modules

And this old post describes confusion regarding whether i2c device addresses are 7 or 8 bits:
    https://groups.io/g/BITX20/message/39966

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.

Jerry


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 type.

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

Jack, W8TEE
 

It appears that most of those extra pins are for read/write capability, and most of the BITX displays don't use software that reads the display. Also, since most of those use pins 2 and 3, they would kill the ability to use external interrupts on the rig. Since I use external interrupts for tuning, such an I2C display for my projects would be a bad choice. They probably are fine for projects that don't use external interrupts. Personally, I'd look for displays that only require the device address and the row/column specs.

Jack, W8TEE


On Tuesday, April 10, 2018, 11:46:02 AM EDT, Jerry Gaffke via Groups.Io <jgaffke@...> 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: 
    http://masteringarduino.blogspot.com/2013/12/lcdi2c.html
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:
    https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/schematics#!configurable-i2c-address-modules

And this old post describes confusion regarding whether i2c device addresses are 7 or 8 bits:
    https://groups.io/g/BITX20/message/39966

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.

Jerry


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 type.

Re: TDA2822 Audio problem #ubitx #tda2822

Jerry Gaffke
 

The Arduino already does UART, digital pins 0 and 1 get tied to the CH340 usb chip on the Nano.
That chip converts the usb interface on your host into UART TX and RX that the ATMega328P can deal with.
I'm just proposing that we do away with the CH340 chip on the Nano, and use a cable assembly 
that includes a CH340 chip or similar, typically only needed when we download firmware.
Though since the 9600 baud interface is so slow it is easy to filter before going into the rig
if you wish to have that USB connection while using the rig for digital modes.

Here's a nice cheap USB-to-UART converter.  
  http://www.oddwires.com/cp2102-serial-adapter-module-usb-to-rs232-with-jumper-wires/


On Tue, Apr 10, 2018 at 08:45 am, Dexter N Muir wrote:
I like it! UART to the rig - could do high-rate given logic-level, UART<->USB remote to take the place of the old RS232 (remember them ol' D9 and D25 cables and connectors?). What sort of cost?
How would the Arduino do UART? How many pins?
73
Dex ZL2DEX

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

Jerry Gaffke
 

I think that list of pins describes the interface between the PCF8574 i2c chip on the backpack
into the parallel interface of the LCD display.
Nothing to do with pins on our Nano, all the Nano sees is the SDA and SCL pins
for the i2c bus that is shared between the i2c display and the si5351.

The parallel interface into an lcd requires 4 parallel data lines, and they are used for both read and write.



On Tue, Apr 10, 2018 at 08:56 am, Jack Purdum wrote:
It appears that most of those extra pins are for read/write capability, and most of the BITX displays don't use software that reads the display. Also, since most of those use pins 2 and 3, they would kill the ability to use external interrupts on the rig. Since I use external interrupts for tuning, such an I2C display for my projects would be a bad choice. They probably are fine for projects that don't use external interrupts. Personally, I'd look for displays that only require the device address and the row/column specs.

Re: Raduino no longer recognized by PC

Mike Bryce
 

Jack and the group,

how does one tell the difference between a Chinese clone and the real McCoy? I mean other than buying four of them for $6 on eBay.

and where does one fine the genuine article?

Inquiring minds and all.

On Apr 10, 2018, at 11:30 AM, Jack Purdum via Groups.Io <jjpurdum@...> wrote:


Another common problem is a faulty bootloader. Sometimes you need to change the processor selection (Tools --> Processor --> ATmega328P (old bootloader)). Also, many of the clones use the CH340G chip for the FTDI. Usually you can google "Arduino CH340G driver download" and find one for your op system:


Re: AGC circuit to try?

Kees T
 

Jerry,

At least the BAP64Q at Q70 would only cost $0.56 but proper biasing to work "as expected AGC" might be a trick. 

73 Kees K5BCQ

Re: TDA2822 Audio problem #ubitx #tda2822

Arv Evans
 

Dex ZL2DEX

Beauty of using the built-in UART and built-in USB interface on an Arduino NANO is
that you don't have to mess with voltage level conversion between RS-232 and TTL.
This is also convenient because many modern PC do not have built-in RS-232 ports.

The Arduino Pro-Mini is an alternative to the NANO that does not include the USB
interface.  With this board you only need to do the voltage level conversion in order
to use it with your RS232 PC port. 

Arv  K7HKL
_._


On Tue, Apr 10, 2018 at 9:57 AM, Jerry Gaffke via Groups.Io <jgaffke@...> wrote:
The Arduino already does UART, digital pins 0 and 1 get tied to the CH340 usb chip on the Nano.
That chip converts the usb interface on your host into UART TX and RX that the ATMega328P can deal with.
I'm just proposing that we do away with the CH340 chip on the Nano, and use a cable assembly 
that includes a CH340 chip or similar, typically only needed when we download firmware.
Though since the 9600 baud interface is so slow it is easy to filter before going into the rig
if you wish to have that USB connection while using the rig for digital modes.

Here's a nice cheap USB-to-UART converter.  
  http://www.oddwires.com/cp2102-serial-adapter-module-usb-to-rs232-with-jumper-wires/


On Tue, Apr 10, 2018 at 08:45 am, Dexter N Muir wrote:
I like it! UART to the rig - could do high-rate given logic-level, UART<->USB remote to take the place of the old RS232 (remember them ol' D9 and D25 cables and connectors?). What sort of cost?
How would the Arduino do UART? How many pins?
73
Dex ZL2DEX


Re: Fw: Re: [BITX20] AGC circuit to try?

Kees T
 

Jack,

Phototransistors are great/cheap for isolation and switching applications ......as with your keyer. Not so much for symmetrical and variable output resistance, tracking an AC input.

73 Kees K5BCQ

Re: AGC circuit to try?

Jerry Gaffke
 

Yup.
Getting AGC right however you do it is not trivial.
And not something I am able to fully analyze.
For example, Henning Weddig pointed out some time ago that
delays through the crystal filter can cause instability when you close the loop.

He also pointed out that it is our audio pre-amp that limits the 
total dynamic range of the rig, and thus an attenuator prior to 
that pre-amp is preferred if you might be dealing with really strong signals.





On Tue, Apr 10, 2018 at 09:10 am, Sandy T wrote:
At least the BAP64Q at Q70 would only cost $0.56 but proper biasing to work "as expected AGC" might be a trick. 

Re: AGC circuit to try?

Kees T
 

Allison,

A #49 and CDS photoresistor brings back memories. The CDS costs about $1, add to that a few cents for a current limited diode, then figuring out which color is best for the correct CDS light frequency range, achieving an acceptable low end resistance, and packaging. A 6 pin DIP sounds easier.

Adjusting AGC "attack" and "decay" is always a challenge.

73 Kees K5BCQ

Re: Fw: Re: [BITX20] AGC circuit to try?

Jack, W8TEE
 

OK...I'm a software guy and should learn to keep my mouth shut on the EE side of things!

Jack, W8TEE

On Tuesday, April 10, 2018, 12:21:18 PM EDT, Sandy T <windy10605@...> wrote:


Jack,

Phototransistors are great/cheap for isolation and switching applications ......as with your keyer. Not so much for symmetrical and variable output resistance, tracking an AC input.

73 Kees K5BCQ

Re: Raduino no longer recognized by PC

Arv Evans
 

Mike, WB8VGE

Good question.  Major difference is related to the serial-TTL/USB conversion IC.  In original
NANO boards this was an FT240RL device.  In subsequent built-in-China (and Philippines,
Japan, Mexico, etc.) boards this is the much less expensive CH340 device.  Functionally
there is no difference between the FT240RL and the CH340 devices, although some
DOS/Windows users have reported driver program problems when switching between
NANO boards that have the FT240RL versus the CH340.  Linux users will find that their USB
ports automatically work with either original or clone boards.


The so-called clones have been sold and used by many with apparently no compromise in
performance  The Arduino IDE works well with either original or clone boards.  Cost is the
main differentiator between original and clone purchases. 

Arv  K7HKL
_._


On Tue, Apr 10, 2018 at 10:05 AM, Mike Bryce <prosolar@...> wrote:
Jack and the group,

how does one tell the difference between a Chinese clone and the real McCoy? I mean other than buying four of them for $6 on eBay.

and where does one fine the genuine article?

Inquiring minds and all.



On Apr 10, 2018, at 11:30 AM, Jack Purdum via Groups.Io <jjpurdum@...> wrote:


Another common problem is a faulty bootloader. Sometimes you need to change the processor selection (Tools --> Processor --> ATmega328P (old bootloader)). Also, many of the clones use the CH340G chip for the FTDI. Usually you can google "Arduino CH340G driver download" and find one for your op system:



Re: Raduino no longer recognized by PC

Jack, W8TEE
 

As a general rule, the real thing has "Arduino Nano" on the body of the device. (See the Mouser ad.) The clones do not. I buy Nano clones 10 at a time and have always been able to get them to work, even though occasionally you have to work around an old bootloader or FDTI chip.

Jack, W8TEE


On Tuesday, April 10, 2018, 12:05:25 PM EDT, Mike Bryce <prosolar@...> wrote:


Jack and the group,

how does one tell the difference between a Chinese clone and the real McCoy? I mean other than buying four of them for $6 on eBay.

and where does one fine the genuine article?

Inquiring minds and all.



On Apr 10, 2018, at 11:30 AM, Jack Purdum via Groups.Io <jjpurdum@...> wrote:


Another common problem is a faulty bootloader. Sometimes you need to change the processor selection (Tools --> Processor --> ATmega328P (old bootloader)). Also, many of the clones use the CH340G chip for the FTDI. Usually you can google "Arduino CH340G driver download" and find one for your op system:


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

K9HZ <bill@...>
 

I believe this is correct, or at least what my digging into the libraries shows. 


Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ

 

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

 

Owner – Operator

Villa Grand Piton - J68HZ

Soufriere, St. Lucia W.I.

Rent it: www.VillaGrandPiton.com


email:  bill@...

 


On Apr 10, 2018, at 11:02 AM, Jerry Gaffke via Groups.Io <jgaffke@...> wrote:

I think that list of pins describes the interface between the PCF8574 i2c chip on the backpack
into the parallel interface of the LCD display.
Nothing to do with pins on our Nano, all the Nano sees is the SDA and SCL pins
for the i2c bus that is shared between the i2c display and the si5351.

The parallel interface into an lcd requires 4 parallel data lines, and they are used for both read and write.



On Tue, Apr 10, 2018 at 08:56 am, Jack Purdum wrote:
It appears that most of those extra pins are for read/write capability, and most of the BITX displays don't use software that reads the display. Also, since most of those use pins 2 and 3, they would kill the ability to use external interrupts on the rig. Since I use external interrupts for tuning, such an I2C display for my projects would be a bad choice. They probably are fine for projects that don't use external interrupts. Personally, I'd look for displays that only require the device address and the row/column specs.

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

Jack, W8TEE
 

I don't know, as I've never had one that used more than 3 arguments in the constructor.

Jack, W8TEE


On Tuesday, April 10, 2018, 12:52:45 PM EDT, K9HZ <bill@...> wrote:


I believe this is correct, or at least what my digging into the libraries shows. 


Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ

 

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

 

Owner – Operator

Villa Grand Piton - J68HZ

Soufriere, St. Lucia W.I.

Rent it: www.VillaGrandPiton.com


email:  bill@...

 


On Apr 10, 2018, at 11:02 AM, Jerry Gaffke via Groups.Io <jgaffke@...> wrote:

I think that list of pins describes the interface between the PCF8574 i2c chip on the backpack
into the parallel interface of the LCD display.
Nothing to do with pins on our Nano, all the Nano sees is the SDA and SCL pins
for the i2c bus that is shared between the i2c display and the si5351.

The parallel interface into an lcd requires 4 parallel data lines, and they are used for both read and write.



On Tue, Apr 10, 2018 at 08:56 am, Jack Purdum wrote:
It appears that most of those extra pins are for read/write capability, and most of the BITX displays don't use software that reads the display. Also, since most of those use pins 2 and 3, they would kill the ability to use external interrupts on the rig. Since I use external interrupts for tuning, such an I2C display for my projects would be a bad choice. They probably are fine for projects that don't use external interrupts. Personally, I'd look for displays that only require the device address and the row/column specs.

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
lcd(0x20,2,1,0,4,5,6,7,3,POSITIVE).

This site also has a nice discussion:
forum.arduino.cc/index.php?topic=157817.0

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

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);
lcd.begin(16,2);

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" <jgaffke=yahoo.com@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: 
    http://masteringarduino.blogspot.com/2013/12/lcdi2c.html
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:
https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/schematics#!configurable-i2c-address-modules

And this old post describes confusion regarding whether i2c device
addresses are 7 or 8 bits: https://groups.io/g/BITX20/message/39966

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.

Jerry

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
type.