• We recently switched our forum platform. If you experience any issues please email support@crystalfontz.com

631 Specifications


New member
My company just ordered several 631s and we plan to include them standard in several boxes that we sell. The boxes will run Linux and our own software will drive the LCD displays. We plan to have them walk you through initial IP address setup, allow you to recover a lost password, see any alerts from drive failures, overtemperature, and so on.

Anyway, I'd like to get a jump on getting the software ready. What I'd like to know is:

1) What sort of USB device will the 631 appear as? A USB-to-serial? If so, which one?

2) Where can I get the specifications for the LCD display? I need the packet formats for custom characters and need to know what other operations it supports.

Thanks in advance.
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
USB LCD Displays - Graphic and Character LCDs with a Keypad

CF Web

The 631 usb works much the same in Linux that it does in Windows. That is, that a virtual com is created and the USB device is associated with that port. The FTDI usb to serial driver (ftdi_sio) handles the conversion in the background so that all you need to do is use the standard packet communication method for the 631, 633, and 635 modules to "talk" to the display.

Here's the output of a "cat /proc/bus/usb/devices" from a terminal:

T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0403 ProdID=fc0c Rev= 2.00
S: Manufacturer=Crystalfontz
S: Product=Crystalfontz CFA-631 USB LCD
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=200mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms

As you can see, the OS just associated the USB device to a virtual com port "Port=01" (/dev/ttyUSB1).

You can find our sample 631 Linux communications code here: http://www.crystalfontz.com/products/631/631_linux.tar.gz

It should give you a clear example of how to communicate with the module as well as a good start on creating your own custom software.

Good luck and feel free to ask if you have further questions.

Edit -
The FTDI driver is required as our displays use the FTDI usb to serial chip onboard. If you do not have the driver loaded in your distribution of Linux (very unlikely if it's a recent distro.. will show up as "ftdi_sio" when you do an "lsmod" command from a terminal), then you can find it here: http://sourceforge.net/project/showfiles.php?group_id=32425&release_id=101763


New member

Thank you. That's exactly the information I need.

One more question. There's no license in the 631 Linux example code. Is it okay to use this example code to create our own code? Or must we re-implement things like the CRC function?


New member
One more question

One more question, and this one is *really* baffling me:

In the picture of the 631, you can clearly see a blank vertical space between the letters "t" and "a" in "Crystalfontz". There's clearly a one pixel horizontal gap between the right-most bit of the 't' and the left-most curve on the bottom of the "a".

Yet the documentation says the display is gapless and the provided CGROM images for "t" and "a" both have bits set on both the leftmost and rightmost columns. How can that be? Why aren't the bottom right of the 't' and the bottom left of the 'a' touching?


New member
The term 'gapless', I believe (IMHO), refers to the horizontal lines between text. Thus, if you looked at the difference between a 634 and a 631 module then you would definately see a definative gap line between each horizontal line. The 631 is close tiled, and thus has no horizontal gap line.

If in any doubt about gaps between characters then simply try a 20 character line fill. As it is a 20x2 display it should fill with 20 characters horizontally, regardless of spaces. You will always get an element of gaps between certain characters and this will be more marked between certain letters due to the integral font design.

I hope this answers some, if not all, of your query. I have a 631, 634 and 635 module here so its easy to see the differences involved. As a contrast, look at the 'l' and the 'f', the gap is almost miniscule. Now imagine all four letters on a seperate 8x8 grid, with the shape of the letters defined by shading in the 64 squares. Because of the natural structure of the 't' this would place the main body of the letter to the left, whereas the rather minor bottom curve would have all the vacant space to fill out in. Thus, certain letters appear to have bigger gaps between.

Regards and best wishes,

Last edited:

CF Tech

JoelKatz wrote: ". . . Is it okay to use this example code to create our own code? . . ."

Yep. Feel free to use anything we offer for any purpose.

JoelKatz wrote: ". . . There's no license in the 631 Linux example code. . . ."

Here is a version of the 633_WinTest we made for the open source LCDproc project that is specifically GPL.


Please also take a look at "Appendix C" of the CFA-633 Data Sheet for other CRC examples.

JoelKatz wrote: ". . . gapless . . ."

The "standard" LCD font is 5x7 pixels. Most character LCD modules lay it out on a 6x8 spacing, with a non-addressable "gap" between the characters. The CFA-631 uses a controller that has the same 5x7 font, and lays it out on the same 6x8 spacing, but you can use the "special characters" to address the pixels that are in the gap. For text, this is no change, but for doing bar graphs and tiled graphics it is a big improvement.


New member
Thanks for explaining the gap issue. I get it now. I knew it had to be something obvious.

Unfortunately, I cannot use GPL'd code (as I need to release binaries), so I will have to reimplement. If you released a version of the example code under a public domain or BSD-style license, let me know.


CF Tech

The GPL code was just for the LCDproc group. You are free to use any of our example source code for whatever you want.


New member
Ummm .. the Port=01 is in reference to the USB port the device is associated with. It does not map to which usbserial ttyUSB(x) device will be chosen.

I edited the kernel I am using to recognize the 631, and am experiencing kernel OOPS'es at the moment. Still trying to debug why.

CF Web said:

Here's the output of a "cat /proc/bus/usb/devices" from a terminal:

T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 2 Spd=12 MxCh= 0


As you can see, the OS just associated the USB device to a virtual com port "Port=01" (/dev/ttyUSB1).