- Home
- Product Categories
- SparkX
- Qwiic Alphanumeric Display - Red
Qwiic Alphanumeric Display - Red
This product went red! Check it out here.
We are quite familiar with seven-segment displays. We see them on our alarm clocks, ovens, and microwaves. But what happens if you add more segments to each digit? All of a sudden you can display more than just numbers! Introducing the brand new Alphanumeric Display from your friends at SparkX. These fourteen-segment digits allow you display all sorts of numbers, characters, and symbols.
The SparkFun Alphanumeric Display Arduino library makes printing strings to the display as easy as calling the print() function. Use the library to send I2C commands to the HT16K33 LED driver chip to light up segments (including the decimal point or colon) and even scroll your string across the display. You can download the library through the Arduino library manager by searching 'SparkFun Alphanumeric Display' or you can get the GitHub repo as a .zip file and install the library from there.
The HT16K33 also supports I2C address configuration. Simply close a combination of the address jumpers on the back and you can communicate with up to four displays on the same bus. Our slim board design also features detachable stand off holes, vertical Qwiic connectors, and internal mounting holes.
This board is one of our many Qwiic compatible boards! Simply plug and go. No soldering, no figuring out which is SDA or SCL, and no voltage regulation or translation required!
We do not plan to regularly produce SparkX products so get them while they’re hot!
Experimental Product: SparkX products are rapidly produced to bring you the most cutting edge technology as it becomes available. These products are tested but come with no guarantees. Live technical support is not available for SparkX products. Head on over to our forum for support or to ask a question.
Comments
Looking for answers to technical questions?
We welcome your comments and suggestions below. However, if you are looking for solutions to technical questions please see our Technical Assistance page.
Customer Reviews
2.5 out of 5
Based on 2 ratings:
1 of 1 found this helpful:
worst reliability ever
Purchased 7 of these and in 3 days 1/2 had failed in one way or another. Had to purchase replacements from a more reliable source, and will have 2nd thoughts on purchasing again from Sparkfun.
1 of 1 found this helpful:
Works great
So far it works great. Some of the letters can be difficult to make out but that's a limitation of the 14 segments and can't be helped, numbers show beautifully. I'm using it on an esp32 with some type k thermocouples as a woodstove temperature monitoring and alarm system. I'm really digging the qwiic system you guys have come up with, it's very convenient to not have to deal with as much wire spaghetti.
I was only able to get 3 of these working with a SparkFun RedBoard Artemis Nano with no other devices on the I2C bus. Using 4 would overload the I2C bus and lose communication.
Disable the I2C pull up resistors on all but one board and you should be OK with 4+ boards.
Just looking at the HT16K33 datasheet, I note that the controller/driver is specified for 4.5-5.5V operation (typ 5V). So operating at 3.3V may be problematic; also I note that the input threshold is 0.7 * Vdd, so operating at 5V, a 3.3V pull-up may not be reliable, 5V pull-ups are required and the I2C drivers need to tolerate this.
I think these are great points and should be filed as an issue in the GitHub repository, which is helpful of our engineers when tracking problems.
As this is a SparkX product, I don't have much insight the product. We may have accidentally linked a 5V version of the product; otherwise, you bring up a valid point an a boost converter (DC step-up) and a logic level converter should be added. I'll try to reach out to the SparkX team on this from my end as well.
If you are going to make these into mainstream products you should seriously re-think the interconnect between the HT16K33 controller and the display module. The segments for each character position are spread over too many memory locations. Each COM output should be for ONE character and the ROW values for the segments. This is not the case here. Direct character modification and scrolling without a shadow buffer is nearly impossible!
The COM outputs can drive the 7 segment inputs, sure. But each digit is split into two because they're 14-segments, so it strikes me that each digit will required 2 COM outputs.