Topics

I2C display up and running on my uBITX

Jim Sheldon
 

Hi All,
I now have an I2C display up and running seeminglyi quite well on the older of my two uBITX rigs.  I used the older one because I had originally built it into the largest of the enclosures the 4 State QRP Group sells and it was as tight fit  I did get everything in that case and working so I figured if I could get the I2C controlled display running and fit into a space not much larger than the original display when it was plugged into the Raduino, then it would be "Mission Accomplished".  

This whole project was possible due to the extensive research & breadboarding done by Jim, N5IB, the super programming skills of W2CTX and N5IB, with me doing the experimental connections to an actual Raduino (N5IB doesn't have his uBITX yet).  

To bring out the Raduino's I2C bus, I made up a small adapter out of a piece of Proto-Board.  Since the Arduino Nano's header pins have been soldered to the Raduino board but protrude quite some distance through the back of the board, it was easy to make this adapter and pick off 3.3 Volts, Ground and the SDA/SCL lines of the I2C bus which is used on the Raduino only to control the Si5351A clock generator chip which is an I2C device.  Due to the nature of I2C's ability to have a number of devices attached to it as long as each device has a unique digital address, it's possible for the 5351A and the display controller to operate on the same bus.  The only problem was the display controllers I bought were designed to operate on 5 Volts, not 3.3. 

This presented a slight problem as the Si5351A is a 3.3 volt device and with the display controller pulling the bus up to 5 volts the possibility existed of that higher voltage destroying the clock chip on the Raduino.   Several people were kind enough to chime in with possible solutions.  One was that the "el-cheapo" I2C controllers we bought off of Amazon.com would actually run just fine on 3.3 volts but you had to remove a pair of surface mount 4.7K pullup resistors attached between the board's Vcc and the SDA/SCL bus lines and allow the on-board chip's internal pullups to work on the bus instead and this is what I opted to do.  

In initial testing, my connection interface to the back of the Raduino worked just fine and everything powered up.  The I2C controller that N5IB used had the device address of 0X3F and the source code he modified for I2C had this address specified.  The ones I bought came from the same source but when powered up after loading the software, nothing displayed.  There is a little program out there called I2C Scanner that will run on the Nano and goes out looking for I2C addressee's on the bus.  Once I figured out how to run the scanner program it found the 5351A at address 0X60 (right where it's supposed to be) and found the display adapter at 0X27 instead of 0x3F like Jim's was.  Changing the device address and re-compiling/uploading the program did the trick but having the display powered by 3.3 volts just wasn't going to cut it.  You could read it, but the contrast (even set to max) was so light it was almost impossible to read a yellow display.  The blue one was slightly better but still too dim for my eyes.

Operating on a hunch and deciding I'd take a chance on destroying one of the several I2C display controllers I had, I made up a quickie adapter isolating pins 2 and 15 on between the controller and the display.  I wired these 2 pins together on the display side and hooked the resulting connection to the 5 volts on the Raduino.  Next power up - WOW, the display was very readable - both blue and yellow (I hate yellow displays though) had very decent contrast and that was still adjustable through the controller card.  Final assembly saw me unsoldering and removing pins 2 and 15 from the display controller board, wiring the 2 pins together on the display side, soldering the controller to the display (less pins 2 and 15 of course) and hooking up a short 4 wire DuPont cable I made up between the vertical header pins on my Raduino's rear side adapter to the I2C Display Controller's 4 pin header consisting of Ground, Vcc (3.3 volts) and the 2 bus lines SDA and SCL.  Remounted the display on the uBITX front panel, plugged the Raduino back into the main uBITX board, hooked up the I2C bus/power lines to the display controller and fired it all up.  Everything came up fine - made a slight adjustment to the contrast and let it sit for an hour to see how hot the 7805 on the Raduino got.  It stayed about the same it always was so I hooked up the speaker and an antenna.  I tuned all over 40 and 20 meters and I heard NO artifacts from the I2C operation at all. 

Called it good, took a few pictures put it back together again and closed the lid.  Working like intended so I'm happy and another successful project in the bag.

Here are the pictures I took of the hardware mods I made and how it all fit together.  Not sure yet but I may write up a detailed instruction sheet on how to do what we did to make this work.

Now though, there are 6 complete digital I/O lines on the Arduino Nano that have been freed up to make the CW Keyer work right and release the analog inputs to those who want to use them for things like an S meter and a Power meter.

Jim Sheldon - W0EB




Boot up with the experimental I2C software - N5IB's call should be on there
instead of mine but it's MY raido - LOL.


Showing the clearance between the original display connector on the Raduino
and the new I2C controller hooked to the display - notice the missing pins 2 and
15.  Look closely and you can see a red wire on the front side of the display
connecting those 2 pins together and it runs out the right side (wired to pin 3
on the digital connector (+5V).


Perfboard adapter soldered to the back of the Raduino picking off the 3.3V, 
SDA and SCL bus lines and ground.


Back of the display with the I2C controller card mounted - bus connection to
the right on the 4 pin header.  The red wire coming out from between the 
display and controller is the +5 to power the display itself independent of
the power for the controller to vastly improve display contrast.



Jerry Gaffke
 

Good to know that you did not hear additional RFI in the receiver when updating the i2c display,
even with that same i2c bus running to the si5351.  
Display update noise has been an issue for some, but this seems to be mostly due to poor power supply filtering.

Took me awhile to figure out exactly what you were doing with the 3.3 and 5v supplies.
My understanding is that you replaced the stock uBitx LCD display with a similar display that also included
the i2c "backpack" in the final picture, the backpack has the blue pot next to the 4 pin connector.
Then arranged to power the i2c backpack with 3.3v, but give the main LCD display board 5v.

Just below that blue pot in the photo are three resistors labeled A0,A1,A2.
Adding or removing resistors there will change the i2c address of the display, if that's of interest to anyone.

I would power the 5v LCD display plus the 5v i2c backpack both from 5v as it was designed to be,
leaving pins 2 and 15 intact.  But remove the SDA and SCL pullup resistors to 5v on the i2c backpack.
The Raduino already has pullup resistors to 3.3v on SDA and SCL, and that should be sufficient.
These are open-drain signals and are driven only from the Nano on register writes, which is all we ever do.
(On a register read, the si5351 or i2c backpack will drive the SDA line.)
The Nano drives these by shorting the signals to ground for a zero, letting the pullup bring them high to 3.3v for a one.

The i2c backpack logic that listens to the SDA and SCL lines will generally do just fine
with SDA and SCL signals that only go as high as 3.3v, not going all the way up to 5v.
If you do run into a 5v i2c device that wants higher incoming logic levels than 3.3v, then an adaptor such as 
this might be the best answer:  https://www.adafruit.com/product/757 
(or build something similar using a couple $0.05 FET's.)

Powering the i2c backpack logic from 3.3v  (but LCD at 5v) as you have done does sort of fix the SDA and SCL high level logic issue,
but then we are operating a logic chip on the i2c backpack designed for 5v from a 3.3v rail.
Also, all the lines from i2c backpack to 5v LCD display are only going up to 3.3v, so we are back to
the same sort of logic level issue between 3.3v and 5v devices.  Not worth the trouble.

So, if you have a 5v LCD display assembly, power it from 5v but remove the SDA and SCL pullup resistors from it.
Alternately, buy a 3.3v i2c display, or use that adafruit adapter board.

The Nano has a USB chip that includes a 5v to 3.3v linear regulator inside that chip, the regulator is not capable of 
supplying much power.  Don't ask it to do much more than power parts of the Nano plus the si5351.
If anybody wants to power a 3.3v LCD display they should probably add a 3.3v regulator to power it.

Jerry, KE7ER


On Mon, Jan 22, 2018 at 02:20 pm, Jim Sheldon wrote:
This presented a slight problem as the Si5351A is a 3.3 volt device and with the display controller pulling the bus up to 5 volts the possibility existed of that higher voltage destroying the clock chip on the Raduino.   Several people were kind enough to chime in with possible solutions.  One was that the "el-cheapo" I2C controllers we bought off of Amazon.com would actually run just fine on 3.3 volts but you had to remove a pair of surface mount 4.7K pullup resistors attached between the board's Vcc and the SDA/SCL bus lines and allow the on-board chip's internal pullups to work on the bus instead and this is what I opted to do.  
 
In initial testing, my connection interface to the back of the Raduino worked just fine and everything powered up.  The I2C controller that N5IB used had the device address of 0X3F and the source code he modified for I2C had this address specified.  The ones I bought came from the same source but when powered up after loading the software, nothing displayed.  There is a little program out there called I2C Scanner that will run on the Nano and goes out looking for I2C addressee's on the bus.  Once I figured out how to run the scanner program it found the 5351A at address 0X60 (right where it's supposed to be) and found the display adapter at 0X27 instead of 0x3F like Jim's was.  Changing the device address and re-compiling/uploading the program did the trick but having the display powered by 3.3 volts just wasn't going to cut it.  You could read it, but the contrast (even set to max) was so light it was almost impossible to read a yellow display.  The blue one was slightly better but still too dim for my eyes.
 
Operating on a hunch and deciding I'd take a chance on destroying one of the several I2C display controllers I had, I made up a quickie adapter isolating pins 2 and 15 on between the controller and the display.  I wired these 2 pins together on the display side and hooked the resulting connection to the 5 volts on the Raduino.  Next power up - WOW, the display was very readable - both blue and yellow (I hate yellow displays though) had very decent contrast and that was still adjustable through the controller card.  Final assembly saw me unsoldering and removing pins 2 and 15 from the display controller board, wiring the 2 pins together on the display side, soldering the controller to the display (less pins 2 and 15 of course) and hooking up a short 4 wire DuPont cable I made up between the vertical header pins on my Raduino's rear side adapter to the I2C Display Controller's 4 pin header consisting of Ground, Vcc (3.3 volts) and the 2 bus lines SDA and SCL.  Remounted the display on the uBITX front panel, plugged the Raduino back into the main uBITX board, hooked up the I2C bus/power lines to the display controller and fired it all up.  Everything came up fine - made a slight adjustment to the contrast and let it sit for an hour to see how hot the 7805 on the Raduino got.  It stayed about the same it always was so I hooked up the speaker and an antenna.  I tuned all over 40 and 20 meters and I heard NO artifacts from the I2C operation at all. 

Jim Sheldon
 

Thanks Jerry,
That cleared up a lot of stuff We were unable to find regarding the controllers and caused a bit of worry regarding possible damage to the Si5351A by running the backpack on 5 volts even with the pullups on SDA & SCL removed.  Now I won't worry about it and will run the next one on 5V and just remove the 2 pullup resistors.

As to addressing, some of these (with all 3 address pads open) have a base address of 0x3F and some have a base of 0x27 and no documentation comes with them, hence the need to run "Scanner" on them.

Thanks again, 
W0EB

On Jan 22, 2018, at 6:02 PM, Jerry Gaffke via Groups.Io <jgaffke@...> wrote:

Good to know that you did not hear additional RFI in the receiver when updating the i2c display,
even with that same i2c bus running to the si5351.  
Display update noise has been an issue for some, but this seems to be mostly due to poor power supply filtering.

Took me awhile to figure out exactly what you were doing with the 3.3 and 5v supplies.
My understanding is that you replaced the stock uBitx LCD display with a similar display that also included
the i2c "backpack" in the final picture, the backpack has the blue pot next to the 4 pin connector.
Then arranged to power the i2c backpack with 3.3v, but give the main LCD display board 5v.

Just below that blue pot in the photo are three resistors labeled A0,A1,A2.
Adding or removing resistors there will change the i2c address of the display, if that's of interest to anyone.

I would power the 5v LCD display plus the 5v i2c backpack both from 5v as it was designed to be,
leaving pins 2 and 15 intact.  But remove the SDA and SCL pullup resistors to 5v on the i2c backpack.
The Raduino already has pullup resistors to 3.3v on SDA and SCL, and that should be sufficient.
These are open-drain signals and are driven only from the Nano on register writes, which is all we ever do.
(On a register read, the si5351 or i2c backpack will drive the SDA line.)
The Nano drives these by shorting the signals to ground for a zero, letting the pullup bring them high to 3.3v for a one.

The i2c backpack logic that listens to the SDA and SCL lines will generally do just fine
with SDA and SCL signals that only go as high as 3.3v, not going all the way up to 5v.
If you do run into a 5v i2c device that wants higher incoming logic levels than 3.3v, then an adaptor such as 
this might be the best answer:  https://www.adafruit.com/product/757 
(or build something similar using a couple $0.05 FET's.)

Powering the i2c backpack logic from 3.3v  (but LCD at 5v) as you have done does sort of fix the SDA and SCL high level logic issue,
but then we are operating a logic chip on the i2c backpack designed for 5v from a 3.3v rail.
Also, all the lines from i2c backpack to 5v LCD display are only going up to 3.3v, so we are back to
the same sort of logic level issue between 3.3v and 5v devices.  Not worth the trouble.

So, if you have a 5v LCD display assembly, power it from 5v but remove the SDA and SCL pullup resistors from it.
Alternately, buy a 3.3v i2c display, or use that adafruit adapter board.

The Nano has a USB chip that includes a 5v to 3.3v linear regulator inside that chip, the regulator is not capable of 
supplying much power.  Don't ask it to do much more than power parts of the Nano plus the si5351.
If anybody wants to power a 3.3v LCD display they should probably add a 3.3v regulator to power it.

Jerry, KE7ER


On Mon, Jan 22, 2018 at 02:20 pm, Jim Sheldon wrote:
This presented a slight problem as the Si5351A is a 3.3 volt device and with the display controller pulling the bus up to 5 volts the possibility existed of that higher voltage destroying the clock chip on the Raduino.   Several people were kind enough to chime in with possible solutions.  One was that the "el-cheapo" I2C controllers we bought off of Amazon.com would actually run just fine on 3.3 volts but you had to remove a pair of surface mount 4.7K pullup resistors attached between the board's Vcc and the SDA/SCL bus lines and allow the on-board chip's internal pullups to work on the bus instead and this is what I opted to do.  
 
In initial testing, my connection interface to the back of the Raduino worked just fine and everything powered up.  The I2C controller that N5IB used had the device address of 0X3F and the source code he modified for I2C had this address specified.  The ones I bought came from the same source but when powered up after loading the software, nothing displayed.  There is a little program out there called I2C Scanner that will run on the Nano and goes out looking for I2C addressee's on the bus.  Once I figured out how to run the scanner program it found the 5351A at address 0X60 (right where it's supposed to be) and found the display adapter at 0X27 instead of 0x3F like Jim's was.  Changing the device address and re-compiling/uploading the program did the trick but having the display powered by 3.3 volts just wasn't going to cut it.  You could read it, but the contrast (even set to max) was so light it was almost impossible to read a yellow display.  The blue one was slightly better but still too dim for my eyes.
 
Operating on a hunch and deciding I'd take a chance on destroying one of the several I2C display controllers I had, I made up a quickie adapter isolating pins 2 and 15 on between the controller and the display.  I wired these 2 pins together on the display side and hooked the resulting connection to the 5 volts on the Raduino.  Next power up - WOW, the display was very readable - both blue and yellow (I hate yellow displays though) had very decent contrast and that was still adjustable through the controller card.  Final assembly saw me unsoldering and removing pins 2 and 15 from the display controller board, wiring the 2 pins together on the display side, soldering the controller to the display (less pins 2 and 15 of course) and hooking up a short 4 wire DuPont cable I made up between the vertical header pins on my Raduino's rear side adapter to the I2C Display Controller's 4 pin header consisting of Ground, Vcc (3.3 volts) and the 2 bus lines SDA and SCL.  Remounted the display on the uBITX front panel, plugged the Raduino back into the main uBITX board, hooked up the I2C bus/power lines to the display controller and fired it all up.  Everything came up fine - made a slight adjustment to the contrast and let it sit for an hour to see how hot the 7805 on the Raduino got.  It stayed about the same it always was so I hooked up the speaker and an antenna.  I tuned all over 40 and 20 meters and I heard NO artifacts from the I2C operation at all. 

Jerry Gaffke
 

I looked a bit further into this, it's not as trivial a problem as it first seems.
I believe removing the two pullup resistors from the i2c backpack is the best solution if using a 5v i2c display
along with the Raduino's 3.3v si5351, powering the i2c backpack and the display from 5v.
The 3.3v SDA and SCL signals into the 5v powered chip on the backpack is not enough
to be guaranteed to work, though good enough for our purposes.

If you want guarantees, best to go to an i2c level shifter such as  this one previously referenced:
     https://www.adafruit.com/product/757 
There are similar i2c displays designed to operate from 3.3v, not 5v.
That is also a good solution, though will require a new 3.3v regulator to power the display
as the 3.3v rail from the Nano can't supply much current.

Here's a schematic of the backpack:  https://www.sunrom.com/p/i2c-lcd-backpack-pcf8574
and a datasheet for the PCF8574 chip it uses:   http://www.ti.com/lit/ds/symlink/pcf8574.pdf

Datasheet says the default i2c write address with no resistors is 0x4E.
the LSB of that address is 0 for write and 1 for read,  so the i2c read address is 0x4F.
In binary, the write address = 0x4E =  0100-1110
Some i2c documentation figure that to be 7 bits of address = 0100-111 = 0x27  plus a R/W bit in the LSB.
Your scanner apparently uses this 7 bit address convention when reporting addresses.
A short across the A0,A1,A2 resistor pads (a piece of wire will do) can change the write address to any of
the eight addresses between 0x27 and 0x20 as described in the TI datasheet referenced above.

It says on this webpage:  https://tronixlabs.com.au/news/tutorial-serial-i2c-backpack-for-hd44780compatible-lcd-modules-with-arduino/

"We may send you one of two versions of this device - the difference is the controller IC. If you have the PCF8574T. the default I2C bus address is 0x27. If you have the PCF8574AT the default I2C bus address is 0x3F."

The datasheet for the PCF8574 says it will work fine on anything between 2.5v and 6.0v,
so your powering the i2c backpack from 3.3v is perfectly legal (assuming the Nano's wimpy little regulator can supply it).
Likewise, the HD44780 that is likely on your LCD is good from 2.7v to 5.5v:   https://www.sparkfun.com/datasheets/LCD/HD44780.pdf
However, on page 48 of the HD44780 datasheet is says that the input high voltage must be a minimum of 0.7Vcc = 0.7*5v = 3.5v,
your i2c backpack powered from 3.3v will not be able to meet that spec when the HD44780 is running on 5v.
(Though you have found it to work anyway).

On page 4 of the PCF8574 datasheet, it says input high voltage for this chip should be a minimum of 0.7Vcc as well.
So removing the two 5v pullup resistors from the i2c backpack means SDA and SCL into the PCF8574 won't meet spec,
as they get a max of 3.3v using the Raduino's R13 and R14:  http://www.hfsignals.com/wp-content/uploads/2017/12/raduino.pdf
But seems to work, and this is probably the easiest mod to get this i2c display to talk on the same bus as the 3.3v si5351.

Going back to this webpage:  https://www.sunrom.com/p/i2c-lcd-backpack-pcf8574
the resistors we want to remove are the 4.7k resistors at R8 and R9, probably marked as "472" (so 47 plus 2 zeros worth of ohms)
There is a third 4.7k that feeds Q1 to turn on the LED, no need to mess with that.
From the photo, I believe the two 4.7k resistors to be removed are in the middle row, nearest the PCF8574 chip.
You should measure 0 ohms between the SDA pin on the 4 pin header to one of the resistors, and 0 ohms from SCL to the other resistor.
I would use two soldering irons, one on each end of the resistor, to pick them off the board, though many here
just use one iron and figure out how to touch both ends simultaneously.

Jerry, KE7ER


On Mon, Jan 22, 2018 at 04:35 pm, Jim Sheldon wrote:
Thanks Jerry,
That cleared up a lot of stuff We were unable to find regarding the controllers and caused a bit of worry regarding possible damage to the Si5351A by running the backpack on 5 volts even with the pullups on SDA & SCL removed.  Now I won't worry about it and will run the next one on 5V and just remove the 2 pullup resistors.
 
As to addressing, some of these (with all 3 address pads open) have a base address of 0x3F and some have a base of 0x27 and no documentation comes with them, hence the need to run "Scanner" on them.
 
Thanks again, 
W0EB
 

Jim Sheldon
 

100 percent agree Jerry and thanks for the excellent explanation.  Cleared up a lot of mud in my mind.  I actually went back, carefully removed the +5 wiring I had on pins 2 and 15 of the display, put the pins back in place from 2 and 15 of the I2C controller and rewired my pickoff interface on the back of the Raduino to put +5 instead of 3.3 volts to the I2C controller.  I HAD removed the 4.7K pullups to Vcc on that controller before I even used it on 3.3v.  With +5 on the controller, I have excellent display contrast and it runs just fine in the uBITX.  

I still have no noise or tuning artifacts in the receiver from the I2C interface.  I DO have a good DC supply coming to the radio - its an MFJ 40 amp (quiet) switcher that I use to power the main station (K3S, P3 and KAT500 tuner on the 13.8 supply) KPA500 amp running on 220V.

BTW I just worked PV8ADI on 40 meter CW with the uBITX just after I finished putting the I2C display back the way it should have been in the first place.

Jim - W0EB

------ Original Message ------
From: "Jerry Gaffke via Groups.Io" <jgaffke@...>
Sent: 1/22/2018 8:54:55 PM
Subject: Re: [BITX20] I2C display up and running on my uBITX

I looked a bit further into this, it's not as trivial a problem as it first seems.
I believe removing the two pullup resistors from the i2c backpack is the best solution if using a 5v i2c display
along with the Raduino's 3.3v si5351, powering the i2c backpack and the display from 5v.
The 3.3v SDA and SCL signals into the 5v powered chip on the backpack is not enough
to be guaranteed to work, though good enough for our purposes.

If you want guarantees, best to go to an i2c level shifter such as  this one previously referenced:
     https://www.adafruit.com/product/757 
There are similar i2c displays designed to operate from 3.3v, not 5v.
That is also a good solution, though will require a new 3.3v regulator to power the display
as the 3.3v rail from the Nano can't supply much current.

Here's a schematic of the backpack:  https://www.sunrom.com/p/i2c-lcd-backpack-pcf8574
and a datasheet for the PCF8574 chip it uses:   http://www.ti.com/lit/ds/symlink/pcf8574.pdf

Datasheet says the default i2c write address with no resistors is 0x4E.
the LSB of that address is 0 for write and 1 for read,  so the i2c read address is 0x4F.
In binary, the write address = 0x4E =  0100-1110
Some i2c documentation figure that to be 7 bits of address = 0100-111 = 0x27  plus a R/W bit in the LSB.
Your scanner apparently uses this 7 bit address convention when reporting addresses.
A short across the A0,A1,A2 resistor pads (a piece of wire will do) can change the write address to any of
the eight addresses between 0x27 and 0x20 as described in the TI datasheet referenced above.

It says on this webpage:  https://tronixlabs.com.au/news/tutorial-serial-i2c-backpack-for-hd44780compatible-lcd-modules-with-arduino/

"We may send you one of two versions of this device - the difference is the controller IC. If you have the PCF8574T. the default I2C bus address is 0x27. If you have the PCF8574AT the default I2C bus address is 0x3F."

The datasheet for the PCF8574 says it will work fine on anything between 2.5v and 6.0v,
so your powering the i2c backpack from 3.3v is perfectly legal (assuming the Nano's wimpy little regulator can supply it).
Likewise, the HD44780 that is likely on your LCD is good from 2.7v to 5.5v:   https://www.sparkfun.com/datasheets/LCD/HD44780.pdf
However, on page 48 of the HD44780 datasheet is says that the input high voltage must be a minimum of 0.7Vcc = 0.7*5v = 3.5v,
your i2c backpack powered from 3.3v will not be able to meet that spec when the HD44780 is running on 5v.
(Though you have found it to work anyway).

On page 4 of the PCF8574 datasheet, it says input high voltage for this chip should be a minimum of 0.7Vcc as well.
So removing the two 5v pullup resistors from the i2c backpack means SDA and SCL into the PCF8574 won't meet spec,
as they get a max of 3.3v using the Raduino's R13 and R14:  http://www.hfsignals.com/wp-content/uploads/2017/12/raduino.pdf
But seems to work, and this is probably the easiest mod to get this i2c display to talk on the same bus as the 3.3v si5351.

Going back to this webpage:  https://www.sunrom.com/p/i2c-lcd-backpack-pcf8574
the resistors we want to remove are the 4.7k resistors at R8 and R9, probably marked as "472" (so 47 plus 2 zeros worth of ohms)
There is a third 4.7k that feeds Q1 to turn on the LED, no need to mess with that.
From the photo, I believe the two 4.7k resistors to be removed are in the middle row, nearest the PCF8574 chip.
You should measure 0 ohms between the SDA pin on the 4 pin header to one of the resistors, and 0 ohms from SCL to the other resistor.
I would use two soldering irons, one on each end of the resistor, to pick them off the board, though many here
just use one iron and figure out how to touch both ends simultaneously.

Jerry, KE7ER


On Mon, Jan 22, 2018 at 04:35 pm, Jim Sheldon wrote:
Thanks Jerry,
That cleared up a lot of stuff We were unable to find regarding the controllers and caused a bit of worry regarding possible damage to the Si5351A by running the backpack on 5 volts even with the pullups on SDA & SCL removed.  Now I won't worry about it and will run the next one on 5V and just remove the 2 pullup resistors.
 
As to addressing, some of these (with all 3 address pads open) have a base address of 0x3F and some have a base of 0x27 and no documentation comes with them, hence the need to run "Scanner" on them.
 
Thanks again, 
W0EB
 

John Backo
 

Good information, Jerry.

That is a good price on the sunrom FTDI cable, if it is genuine.

They were about $US20.00 a short time ago.

Admittedly, though, it is old technology by now with the advent of the CH3xx
and AD2102 chips, but still useful.

john
AD5YE

Graham W
 

Using the I2C that frees up a few digital lines that could be used to switch other filters. 
Would it be possible to point to the code you used for this please ?