I figured it was just a bulk in endpoint and a bulk out endpoint, but I hadn't actually tried to do anything like write a driver for one.

What if I scratched the Arduino and went with this: https://www.sparkfun.com/products/762?

It seems to provide everything I need: Easily programmable over (mini) USB, controllable I/O pins, relatively inexpensive, well documented, etc. What do you guys think?

That sounds a lot like an Arduino. I don't see much difference between that and the Nano. The difficult part is the USB driver. I reccomed the Tennsy. The Teensy is also easily programmable via the same interface as the Arduino, and It has USB HID (Human Interface Device), which the calc can handle already.
http://www.pjrc.com/store/teensy3.html

I hadn't seen anyone link this thread here but this may be useful to you guys. http://www.cemetech.net/forum/viewtopic.php?t=3466&start=0

It wasn't clear when I read about it whether this uses actual USB or the same serial-over-USB that Kerm was talking about. I assumed the former, but on reading again, it unfortunately seems to use serial-over-USB.


I'll look into this. It looks like I will need to use the Teensy 2, not the Teensy 3 because version 2 uses mini USB whereas version 3 uses micro.


Thanks for the link. I hadn't seen this post before. Unfortunately, it looks like he is using a heavily modded Enttec Open DMX USB adapter, which is just a fancy serial-over-USB to DMX converter. That's what I'm trying to avoid. But that thread may still be useful for the software concepts.

If you want to use the mini A <--> mini B, yes, you want the Teensy 2, although it is the same USB protocol, just different shapes of the connectors. If you want to cut the cable and splice it, you should go with the Teensy 3 because it is much more powerful.

Looking at the specs, the Teensy 3 has a 48 MHz 32-bit ARM whereas the Teensy 2 only has a 16 MHz 8-bit AVR. It's clearly much more powerful. However, I want to avoid cable splicing to make the project as user-friendly as possible. After all, the TI-84+ and SE calculators both come with a mini-A to mini-B cable (I have several of the cables), which makes mini-B ideal for what I will be using it for. Also, standard-A to mini-B cables are a dime a dozen; using mini-B would allow it to be used with computers, given a compatible driver, which greatly expands the usefulness of the device. That's also the main reason why I don't just splice together a mini-A to standard-B and use it with existing DMX hardware like the Enttec DMX USB Pro. The DMX USB Pro costs $170, whereas my build should cost in the realm of $50 or less and could still theoretically work with a computer as well as a calculator.

If I use USB (which I probably won't), I think I would need this USB controller along with ATmega328 with the Arduino bootloader preinstalled. One problem I would have with this setup is dealing with the non-DIP-packaged USB controller.

But my sanity is worth more than making this work via USB. I think I'm going to take a cue from keoni29's soundchip and go with an Arduino-based serial interface. The parts I think I'll need are:
*Arduino Pro Mini, 5V
*FTDI Basic breakout board
*Some headers
*TI-SN75176 transceiver
*5-pin XLR female jack
*2.5mm female audio jack
*Some kind of enclosure

And a serial link cable for my calculator, which I have been woefully lacking all these years.

Please comment on my hardware list. I'm still new to this.

Edit: Whoops. I linked the wrong headers. These are the ones I'll need: https://www.sparkfun.com/products/553

I've been saying all along that you should do I/O linking. I think that's definitely the best solution here. I don't see anything missing from that list for starters; just remember that you also want a USB plug if you're going to steal 5V from the calculator.

I know, but I thought USB would be easier than it actually is.




The FTDI Basic breakout should be able to do that, right? At least, that's what SparkFun's website said:

I've been working on developing a high-bitrate protocol to communicate with the Arduino. Then I saw Kerm's Arduino code for using the TI link protocol, which would make my work on the Arduino side much easier.

tl;dr: Neither option is perfect. My protocol may not even be technically feasible (see below). Which do I use?

Long version:

The main problem I have with TI's protocol is that it's very slow (9.6 kbps - think half a second to send 512 channels). The good part is that if I understand correctly, it's interrupt-driven, so the program can continue executing while the data is being sent, whereas it cannot with my protocol. Another benefit is that it could possibly be supported in Basic through the Send( and Get( commands. However, because it's driven by TI's interrupt, I'm thinking that it would be incompatible with custom interrupts. Not a deal-breaker, but worth mentioning.

The protocol I was developing operates at 200 kbps so that I can quickly send large packets if necessary (e.g. updating all channels at once). The main problem I have with this is that I'm not sure that the link cable is able to transmit data at 200 kbps without lots of distortion. I don't have any data to back this up other than that as far as I know, no calculator link protocol has been developed that transfers faster than 10-15 kbps. If the link cable actually is able to transfer data correctly at 200 kbps (or less - this isn't set in stone), this would be a non-issue.

So. Any recommendations on which protocol to use?

Okay, so I finally ordered most of the parts today after more research. Here's a list of the parts I bought:

XLR 5-pin female jack
2.5mm stereo jack (panel mount)
I/O link cable (because my 84+ didn't come with one)
SN75176B transceiver
Arduino Pro Mini 328 - 5V/16MHz
FTDI Basic breakout board, which will also supply power to the board from the calculator
Aluminum enclosure
Right angle male headers (for connecting the FTDI to the Arduino)
Straight female headers for the protoboard
Straight male headers for the Arduino
3" protoboard
Standoffs
Screws for the standoffs
Indicator LED (probably will be a power indicator, but also could be for TX)
Panel mount LED holder
330 ohm resistor for the LED

Next, I want to make sure the project is isolated between the XLR jack and the transceiver to prevent issues arising from voltage spikes on the DMX network. I've looked into optocouplers, but what I've read says they're too slow for high bitrates. What do you guys think is the best isolator for 250 kbps?

A ISO3088 appears to do exactly what you need. It's an optoisolated RS-485 transciever rated for 2.5 kV isolation, taking a 5V supply.

Thanks Tari. That part looks perfect. I'll look more into it when I get a chance.

EDIT: Looks like that chip is a SMD... so I probably don't want to attempt that with my underdeveloped soldering skills.

I know that it's been a while since my last post. I'm still planning to finish this project, but it will have to wait until Thanksgiving or Christmas break since I just moved in to college.

The next steps are to acquire a breadboard, buy an optocoupler, wire it up, and start programming the drivers. Not necessarily in that order, because I can program the Arduino to some degree using the serial console to transmit sample data, even if the circuit isn't on the breadboard yet. I can also work on the calculator driver, albeit without being able to test until the circuit is laid out.

One nice thing I thought of is that because I'm probably going to have the TI serial connection use the Arduino's hardware serial interface, it should be possible to also use it as an adapter for the computer over USB. It wouldn't be too hard to just add a feature that changes it from TI mode to Open DMX USB mode (in which the computer bit bangs the signal over USB). But that will have to wait for v2.

If you had that going on, you'd almost be better off emulating the Black (serial) Link from the Arduino, since it already has a UART transceiver on D0 and D1. If you wanted to make the Arduino bitbang USB to the computer, you could emulate the SilverLink, but that's very poorly-documented at this point.

Please excuse me if I'm wrong, but I'm not sure you understand what I mean. The Open DMX USB adapter is just a USB to serial converter connected to a SN75176B or similar driver. Using the Open DMX USB driver, the computer bitbangs the DMX signal over the USB cable, which is sent through the SN75176B to generate a differential signal, then to the DMX Out jack. Since I will already have both a USB to serial converter (the FTDI breakout) and a SN75176B, it would be almost trivial to make a cheap version of the Open DMX USB adapter that even works with existing drivers. It wouldn't even have to go through the Arduino at all because it could go straight from the FTDI to the SN75176B.

The difficulty arises when I want to make it operate in 2 modes: Open DMX USB mode and the calculator mode that I'm developing. The benefit of this is that the adapter would become much more useful because it could be used by both calculators and computers. However, since that's not the main purpose of the project, I want to wait to add that feature until a later version.

EDIT: Corrected part number for SN75176B.

Project update:

I implemented pretty much the entire Arduino firmware at a recent hackathon at my university (currently using the Serial interface). The source is here. I also recently added a few new features such as a communication timeout (1 second) and auto power down. (It waits 6 hours after the last command was received and then asks the calculator first if it's OK to do so. If it doesn't receive a reply within 60 seconds, it shuts down.)

In other news, my university's ACM chapter has some cheap DMX lights that they said I could use to test out my project, which means I should be able to test changes on the fly instead of having to go into a physical theater to try new code. Unfortunately, they use 3-pin connectors, so I'll need a 5-pin to 3-pin adapter.

I looked more into TI's link protocol, and I think the best option calculator-side may be to write my own simple link routines. My reasoning:

• The TI protocol is too slow for my project. It needs to be able to send up to 513 bytes in a reasonable amount of time. For infrequent transfers, 9600 baud would be sufficient but not preferred. While I haven't been able to test the throughput of the TI protocol, it has to be significantly slower than 9600 baud because of the ACKs and checksums and whatnot. Even CALCnet 2.2 is less than half that speed.
  
• I probably don't need much (or any) error detection/correction because the DMX protocol doesn't have it either. The exception is for protecting certain commands, like the shutdown and reset commands, from accidentally being executed. I've already implemented protection for these commands by requiring that they are preceded by a no-op command.
  
• I really don't like the TI protocol's wacky method of signalling 1s and 0s. It makes it a lot tougher to read from the Arduino. I know that Kerm published some routines to make this easier, but that still leaves the issue of speed.
  
• By writing my own protocol, I could make it transmit much faster. The only problem is determining exactly how fast because I don't have the equipment to test the speed limitations of the standard TI link cables. I'd love to do 100 kbps, but I'm not sure that the data will come through correctly. Does anyone more experienced than me know the practical upper bitrate that the link cable can support? I haven't been able to find this information anywhere, except that every custom protocol that I'm aware of typically operates at or around 9600 bps.
  

Please feel free to provide constructive feedback to the preceding reasons. I'm still new to this, and the whole point of the project is for me to learn a little about ECE.

First pictures!

Tonight I finally got around to soldering the headers on my Arduino and various other components that needed soldering. Now I can actually debug the firmware I've been working on since I can connect the Arduino to the I/O jack.

The breadboard isn't 100% laid out, but it's basically done. Also, I apologize in advance for the poor quality pictures; the only camera I have available is my phone.

The full breadboard:


The Arduino/FTDI (plus the indicator LED):


The XLR jack and the transceiver:



Also, I think I am going to end up using Kerm's Arduino linking routines because I don't know how to write a serial implementation on the 84 when there are no interrupt frequencies fast enough.

Merry Christmas to my fellow Cemetechians!

I got my enclosure drilled out on Monday with my grandpa's help. Lacking advanced tools, we had to use his drill press and files to make the holes (including the USB one), so some of them aren't very pretty.

Anyway, the gallery is available here and is embedded below for your convenience. I think the pictures are rather dark because the flash was reflecting too much off the metal enclosure.


This was probably the toughest hole to drill because the largest drill bit we had was old and rusty and slightly too small. The bit ended up tearing through the edge and creating a gap, which you can't see well in this picture. After filing and sanding the hole, the XLR jack fits nicely.


The rectangular USB hole was not as difficult as I originally thought it would be. I still need to file it down a bit to make it smoother, though.


Here is the XLR jack in place with the indicator LED on top. Luckily, I had some extra nuts and bolts lying around from an old robot kit that happened to fit the XLR jack perfectly.


These are the ports on the other side of the enclosure. The USB port has just the right amount of overhang from the FTDI board to fit perfectly across the 2mm-thick enclosure.