I have recently picked up an analog breadboard cable for the TI CBL 2 / Vernier LabPro to complement my digital breadboard cable, and I've been toying around with various circuits I could use them with. I'm new to working with the digital port, so it'll be a while before any neat miniprojects use it. So far, I have managed to control an RGB LED using the digital output buffer to produce a predefined sequence of colors, linked below.

Code:

I also have used the orientation of a 3-axis accelerometer to control the color, in addition to the state of an infrared LED. I have ported that project from TI-83 series BASIC to Python, using pySerial to interface with the LabPro's serial port.

More and better miniprojects are coming soon, and I'll take any reasonable requests.

Wow, I just looked on eBay, and the CBL is going for ~ $20 or so. That's pretty cheap. The CBL2 looks like $40 to $50 is the going price. That' also pretty good.

Unfortunately the original CBL can't run the code I've listed here. Its digital port works differently, and the connector is much harder to find. It has a 22-nibble digital output buffer, but it lacks power control (command 102) and direct digital port control (commands 2001, 201x); however, it can read sensor data while operating the digital port in realtime mode as the digital output buffer is not subject to the one-channel input limitation of the CBL. I don't have a DIG OUT connector for the CBL, so I can't be entirely sure how everything works, but my description aligns with documentation and observations.

tl;dr The CBL 2 made some nice improvements on working with the digital port, and is generally preferred when doing things.

I was wondering what the differences between the two are. I figured that Vernier made a bunch of improvements with the new version. It's nice that Vernier does document their interface so you can make you own sensors.

Fellow Cemetechian pyrot3chnic and I have worked on a protocol to use the CBL 2's DIG OUT port with an Arduino to send a 9-bit number. The DIG port is 4 bits wide when used as an output, and in the mode I am using, is limited to the rate that TI-BASIC can send lists at. The Arduino waits for D3 (most significant bit) to go high, and this triggers the Arduino to read the three remaining bits. This repeats twice more, sending 3×3=9 bits of information with D3 used as a clock line.

In this particular example, the calculator encodes a string as a list of ASCII values with ord(, sends the length (n = 300 + length, informing Arduino it is sending a string and simultaneously supplying the length), then the ASCII data. The TI-89 can send 2.3 of these 9-bit values to Arduino per second, so filling one line of the screen takes about 7 seconds to transfer. After the data is received, Arduino displays it to the LCD.

The neat part about this is that Arduino and the LCD are all powered by the CBL 2. I used the regulated 5V output to power the Arduino, which also powers the LCD and its SPI backpack.

For some photometry stuff I've added a barometer, RGB light sensor, and luminous intensity sensor to the project above. To feed data to the LabPro / CBL 2, I've changed the DIG port to a LabPro input and added a DAC connected to an analog input channel. The barometer will be connected to the analog channel, and the other sensors will be received via digital input. Due to the increased power consumption, LabPro does not supply power to this. Since there's a lot of sensors and I haven't used I²C successfully yet, it'll be probably a day or three for all this to work.

My mind is blown. :O Nice!

So I had finally completed the above project. I couldn't use the TCS34725 RGBC light sensor with the TSL2591 luminosity sensor, so I instead swapped it out for a 3-axis magnetometer+accelerometer. With that, I have 12 sensor feeds coming in (barometer, thermometer, RGBC light sensor in 4 channels, accelerometer xyz, magnetometer xyz), which causes the calculator to take some time processing the binary received from the LabPro/CBL2. Transmitting the ~ 20 bytes of data from Arduino to LabPro/CBL2 takes about a quarter of a second, but processing takes 12 seconds. But hey, calculators aren't meant to get data this way. For the more rapid data acquisition, one sensor channel can be sent via a DAC, which is then picked up by LabPro/CBL2 on one of its analog inputs. The analog inputs are handled natively by LabPro/CBL2 and calculators alike, using programs such as CBLM or good old linking commands on the homescreen.

In the near future (read: tomorrow or the day after) I'll work on a way to get Raspberry Pi to read and log the data at the same rate at which it is sent out, using the same PWM I used to feed data to the LabPro. The pulses are fairly long (2ms low, 4ms high, 6ms end of 12-bit number, total length 8ms per bit) so even the notoriously poor for PWM Raspi should be able to keep up.

Video below:

Great work, CVSoft! I'm glad you seem to be a natural with Arduino programming and have found a way to multiplex all these sensors with the Arduino. I must confess to being slightly confused as to why you still need the CBL2/LabPro in the loop between the Arduino and the calculator when something like ArTICL exists. It seems to me that that would be a cheaper option and more accessible to people who don't own the CBL2 or LabPro, but I'm sure I'm missing some reason why the extra hardware needs to be there. Regardless, awesome work!

Mainly because I'm too lazy/inexperienced to use ArTICL, but also because I'm working on new ways to make sensors. The analog output, combined with a digipot and AutoID-compatible microcontroller (neither of which I own, and the latter I still don't know how to use), allows for the creation of universal sensors. So this build branches off in two directions, one the creation of a universal interface with proper digital support, the other the creation of a universal sensor with analog output. Now, the two could easily merge and make a universal interface capable of spoofing any sensor imaginable by using an analog output that works identically to LabPro's, but with all the thinking done onboard as to allow realtime updating of the digital output. However, I favor the universal sensor idea being for smaller, inexpensive microcontrollers which run off of provided power.

An issue with a universal interface would result with presence detection of sensors; i2c as far as I can tell doesn't like hotplugging. But this is all for a different day.

Using the Vernier 3D Accelerometer and a TI Light Sensor, I wrote a quick-and-dirty program to measure my computers' input lag. The setup is simple: point the light sensor at the screen, and hit a mouse button with the accelerometer.


The accelerometer will register a peak while it is pressing the mouse button, and after 100ms or so, the light sensor will register a brightness change.


By (manually) selecting these two points, the time difference can be calculated within a few hundred microseconds. The field of view here is 22 frames of 60fps video, which gives 20 frames after the sensor interface is set to record after the trigger event (about 1 g-force above the initial value when the program was started). This screenshot shows about 5 frames of latency.

I'll upload the TI-83 source code once I get it off my calculator.

I assume that you're using a single-player game, to ensure that you're not including a measurement of your round-trip latency to a server in the calculation? I'm suitably impressed at this clever method of measuring latency using the tools at hand (especially since it uses a calculator, of course). Your 5 frames of latency indicate that your input latency is about 83ms, if I'm doing my math correctly?

When staring at a pile of sensors and trying to figure out how to find the timing of a mouseclick, you're forced to be clever :-). My original plan was to use the fact that the +/-10V input floats above 1V and drops to 0 when closed, and have a button on top of the mouse button to detect when I pressed a key. However, sampling triggering wouldn't be as easy, and key bounce might influence that triggering. I settled on the accelerometer since it produces a sharp voltage increase when I smack it against a mouse button, which is easy to detect when configuring the sample trigger.

Yeah, 83 ms sounds about right. I think the raw measurement was around 87 ms. I should experiment with different monitors, such as CRTs.

I used a singleplayer game as 1) it's basically instant, and 2) it helps to be alone since the accelerometer is in one hand and the light sensor is in the other. There's probably a much better way to trigger a brightness change on the screen instantaneously, and I could probably write a program to flip a window from black to white on mouseclick with mimimal effort. Right now I'm dependent on how quickly UT2004 can draw a shock core to the center of my screen, which could introduce a frame or many of latency itself.

Needless to say, there is a pronounced difference between that computer and PentiumII, which measured 6 frames under low load but 10 frames at around 40 FPS. The 6 frame measurement thoroughly impressed me, as it scored better than my laptop while being less than half the minimum processor requirement for UT2004 and going through an older 8-port KVM switch. Additionally, as screen resolution on that computer increases, input lag does too (significantly; 1920x1080 is somewhere around a third of a second) as all the I/O gets used by the graphics card and CPU.

Ingenious this chap!

This is pure awsome! Although I understand little of what is going on, my mind is blown!



Ime not an expert at real time multiplayer networking, but I pretty sure that only in a poorly designed network will there be a [notable] difference in latency between single/multiplayer. Most games use client side prediction, meaning that the client updates the entities' and players' positions independently, but eventually merges them with those the server calculated. If this was not so, then people with high pings would have outrages latency between pressing a key and seeing movement on the scream