Inspired by ArTICL, I have thrown together an implementation of the TI-82 link protocol in Python using pySerial and the Graylink. As of right now, only lists, reals, and pictures are fully implemented, yet all data types will be supported once I add them to the variable header code.

I have a few project ideas in which I can use this, and after I finish up TI-82 support I'll toss in TI-83/+ and TI-85 support (GPS-85 will almost certainly be using this to transfer the NMEA 0183 sentences between a GPS unit and the calculator). Being in Python, the code should be reasonably portable to various devices; I hope to bring this to Raspberry Pi within the next few weeks.

As an early example, here's the PC simulating a Get(L1):

Cool project, and I'm glad that ArTICL inspired its creation. You say that you have a few ideas for projects that could use this particular tool: does that mean you don't envision it as turning into a general-purpose piece of linking software? Either way, good luck, and let me know if I can clarify any of the no doubt poorly-documented code in ArTICL.

My TI-82 linking module provides functions to create the packets and var headers as bytearrays, functions to make Python variables (int/float, list, etc.) into TI-82-format bytearrays, and a basic set of pySerial functions directly copied from my LabPro code that provide a simple way to send and receive bytearrays from the serial port. Since the linking procedure currently isn't handled by the linking module (gasp), its use is very broad in scope. The above linking example should work for any variable type if I change it to not hard-code the variable header, so I can integrate it into the linking module to provide an easy way to receive variables. I do need to make it handle timeouts better...

With an extremely messy expansion of this code to use the TI-92 link protocol, I've written a version of it to communicate with the CBL, CBL 2, or LabPro. The TI-89 link protocol to LabPro is generally interesting, in which the list data is practically in the same ASCII format that LabPro's serial port uses. Given that I have preexisting code for the LabPro (and I can't remember where anymore, it's long gone), making Python speak CBL 2 wasn't very difficult. I discovered that the sensor interfaces have rather long turnaround times, so the code in its unoptimized form is much slower than an actual calculator. I have also discovered that I need the serial port open throughout all communication attempts; when working with Python-82 and Python-85 I could close the port when there was no activity. Those issues aside (and not necessarily resolved D: ohno) I ported over my useful utility CBLInfo to Python using the linking commands I wrote.


Note the low battery level, explaining much of my programming headaches as to why the interface would randomly become unresponsive. Pro tip: if the device won't respond, check to make sure it is powered.

The main goal of this here is to get simple, easy-to-use data logging from a PC without the user having to know the more complex C++ programming language and with all of the heavy lifting done within my code. Graylinks are wonderful cables, doing all the physical layer stuff for me. And had it not been for the quirk about the TI-92 to CBL link protocol using ASCII data, I probably would still be working on a solution.

I certainly understand why you chose the Python solution here, even if I don't agree that it's the right language choice for this particular project. I do hope you'll explore ArTICL and C/C++ now that you have your own Arduino, as I think you'll find it to be a lot easier that you're anticipating. Do you have further plans to expand this with more of an interface, and/or integrate it into other Python tools, especially CBL/CBL2-related, that you're working on?

Typecasting is stupid easy in Python. It makes porting the existing calculator software (CBLM-Python hype hype) to a computer platform much simpler; CBLConsole and CBLInfo are almost direct ports (Python is more permitting of zero-length things, and has different types for float and int). GUI is also easier, which makes software porting further easier. Everything I've ported over so far is just command-line utilities, as I'm still learning Tkinter and the tools themselves aren't complex to any degree.


I'm planning a CBL-compatible interface around Arduino and a 16-bit ADC. However, LabPro has a heck of a lot more I/O than my puny Arduino can provide, so I'll only have Vin-low inputs and one digital in/output.

Sadly, Arduino does not provide me with enough resources to build a LabPro-compatible interface. LabPro has three ADC inputs for each of its four analog inputs, so 12 analog channels. 4 of those have a -10 to 10 volt range, whereas my ADC only has four. Each of the AutoID channels also needs to be able to be read as an i2c memory device, using more of my precious I/O. Additionally, it has two digital channels, each of which is 8 pins and can be used as an input or output. LabPro contains a reprogrammable table of all the sensors' parameters, along with program storage space. Timing precision needs to be about 1/50000th of a second, which is feasible but can be inconvenient with long int rollover for micros() and long sample times. Arduino simply isn't built to be the type of data acquisition solution that LabPro is, as there's a lot to pack into a little microcontroller; as a result I'm using a CBL-compatible command set with extensions to support programs like CBLM. It'll have commands like sensor equation setup, but I'm taking out the complicated or DataMate-tailored commands to save effort and memory. Likely I'm leaving in only commands 1, 3, 4, 6, 7, 8, 80, and 110 (channel setup, sampling setup, calibration equation, interface control, per-channel sensor detect, global sensor detect, and digital memory read), along with my own additions such as an arbitrary length digital output buffer and an analog output buffer to a 12-bit DAC. I might even add code to daisychain a CBL to the Arduino-based interface, since the CBL can accept an external sample clock source and I can have the Arduino act as a calculator receiving or sending data to it. I'll save that for later, since that would require another DBUS channel.

Whoops, I forgot entirely to posf about the CBLConsole port to PC.

It's a direct port of the TI-89 version, which doesn't seem to be uploaded anywhere (sorry). Basically, it provides a simple way to test commands for the CBL, CBL 2, or LabPro by means of typing them out and sending them to the interface. It follows the general LabPro-via-RS232 input format, with some additional commands to simplify what would normally be a long process, such as looking up errors or converting strings. The PC version, like all above examples, uses a Graylink to facilitate communication. The linking code is more robust in this example than in the CBLInfo demo, but is still a bit wonky on first command and can't handle lists over ~2kb.

Why can't it handle lists over 2KB? Is there anything we could do to help you figure out how to fix that, or is it a technical limitation somewhere in the CBL2/LabPro or the greylink?

I'm pretty sure this has to do with some stupidity I did with serial port open/close, or the serial port is timing out while reading data (iirc I have it set to respond within a second). I checked against an emulated TI-89 and, as expected, no problems were encountered; it's definitely a problem with my code. I'm finally resuming work on this as I unify it with my LabPro code and add IRC as an I/O option (use CBLConsole from a remote CBL/2/LabPro via IRC!).