I have been researching this idea for months now and have not found a single RF link that has been constructed. I am a freshmen in high school and I am trying to start a project like this for our county science fair. Any inputs regarding a RF wireless link. If you think a RF link would not be useful for this project please suggest other ways. Thanks!


(Looking at a standard 2.4 gHz frequency here no wi-fi hopefully)

P.S. I do NOT want to write drivers for my calculator. I am fine with having to write a simple chat program in TI-Basic but I can't handle driver.

As I mentioned to you in my email:



Basically, you should use CALCnet Chat for your chat program, and then you just need a drop-in hardware solution. A Zigbee would work; Sami Khawan's IR link (although it's of course not RF) would also work.

This is a science fair project so, in my opinion, using another persons program to connect to another calculator might be considered either cheating or not impressive. The chatting is actually the least of my worries ATM. I am hoping to just make a link that basically "tricks" the calculator into thinking that its just an average link cable that requires no programs to run properly. All the encoding, decoding, transmitting and receiving should be done on the piece itself. I was think along the lines of an Arduino, which is simple enough for me to understand.

From a hardware point of view, I think a pair of Digi Zbee module will work by itself, there's a transparent mode that should work, although I haven't fired it up.

Alright can I have that again but in English please? I'm sorry just some of the words like transparent mode and firing up don't ring a bell.

Oh, really? Can it deal with two bidirectional data lines?

Sammi: "fire it up" is an English idiom for "give it a try". Is English your first language? And transparent mode is what you just described, that the calculator isn't aware the link it's talking over is anything other than a simple link cable.

Yes, English is my first language, but I was wondering if it was some sort of technical term for something xD But thanks anyways And now that I know what he said I have seen the ZBee modules and believe they work off wi-fi. Would this mean I would need some sort of router setup?

802.15.4 != 802.11. You need a coordinator device for any given network, but I'd imagine it's possible to make any given node the coordinator with minimal effort.

I'm sorry to ask again but I am new in the field of RF and thought this would be a cool project to attempt so whenever possible please try to use the simplest and most laymans terms possible please. Aldo while looking at the ZBees I noticed their hefty price tag which is way over my budget...

@Kerm-You're right, the Digi Xbee's only deal with Data in/Data out, so no bi-directional data per pin. Both lines are Bi-directional? Seems like an odd decision, but it makes the cables easy. Transparent mode won't work then.

@Sammi12006-I'll try to do an impedance transform to noob
There are a lot of pre-build RF modules that operate at different frequencies. 2.4 GHz is a very popular, unlicensed band in the US for low cost wireless links, and there are several different systems or standards for devices to communicate. WiFi (ieee 802.11xx) is one that most everyone is familiar with, and it works well for computers. It's a little high overhead for low data applications like a calculator chat program, though.

Zigbee (ieee 802.15) is a standard that is designed for low cost, low power slow data links. This would be appropriate for a calculator chat program, and I've been kicking around doing that design work.

I had thought that the signals were wired up so that one pin was Data out, and one pin was Data In. This would make it possible to hook a calculator directly to one of those Digi XBee modules, configured as transparent mode, and talk directly to another Digi XBee module, also connected to a calculator, and have a chat program just work.

However, that's not apparently the case, and each pin is able to act as both Data in and Data Out (Simultaneously?). As that's the case, there's a need for a small microcontroller to connect to the TI-84, seperate the data from both pins into separate data in/Data Out lines, and then run that into an RF module.

Arduino's are a pretty popular microcontroller prototyping platform, and have lot's of support for Xbee modules, but not particularly cheap. Ballpark $120 or so for 2 arduinos, 2 xbees, and arduino shields from sparkfun. Now, there are cheaper solutions for some of this, but you're trading off time for money, and I haven't really researched this yet, I was looking more of a proof of concept thing that it would be possible to do.

The link is similar to I²C at the hardware layer. Each line is normally pulled up, and either end can pull either line low at any time, and it won't return to high until both ends have released it.

The TI link protocol lends reasonably well to being quantized (eg over a packet-based RF link)- the sender of a bit pull one of the lines low (which one it is indicates the value of the bit), and waits for an acknowledgment from the other end (pulls the other line low). Each end waits for the lines to return to being high, and the next bit gets sent.
Given that, it's pretty easy to force some clock-stretching into the protocol, just by throwing some packets back and forth across a lower-level link (eg the radio) to indicate the state changes, since you don't need to do anything more to force the sender to wait.

I quite like MSP430 controllers, and the development tools/experimentation boards are pretty reasonably priced. Low-power micro with on-chip RF transceiver, and I rather prefer the MSP430 architecture to AVR (as one acquaintance put it, the "MSP430 was designed by people who realize that most processors suck"). With TI's SimpliciTI protocol, there shouldn't be much code required to get a packet network running..

Tari-Good point, I've got Arduino on the brain because of another project, but the MSP430 is another excellent choice, and the rt2500 dev board is nice and small.

Meh, reading this topic makes me upset that I didn't use a more clock-stretch-insensitive protocol for CALCnet, although I know why I made my decisions. It's too bad that it makes wireless networking for CALCnet challenging. That SimpliciTI protocol looks quite intriguing, though, and I might even consider what it would take to bridge CALCnet over SimpliciTI.

I don't see how CALCnet could be made insensitive to clock stretch, since, unlike the TI protocol, it can't depend on bi-directional acknowledgments.

How hard would it be to create a radio link using nothing more than two different frequencies (one for tip and one for ring)? If a line is pulled high, no signal is transmitted on its frequency, and if a line is pulled low, a signal is transmitted. All receivers in range will "hear" the radio signal and will pull its line low. There's probably some problems with this scheme (eg, a radio unit might "hear" itself and keep the line low even after the calc has released it).

It cannot, but neither does the TI protocol, if I recall correctly. I believe that it lets bits be as long as possible, then reads the data line again on the next clock flip. CALCnet does the same thing, but has fairly strict timeout limits. Actually, I really should investigate just how strict those limits are...

I was reading a book from Radioshack that was basically Wireless Communication for Dummies in concept, and it seems as though a solution like the that could be done with simple electronic components (ie. transistors, capacitors etc.) I have not actually done any experimenting, though.

RF Links are noisy, error prone, and in general unreliable. You need Synchronization bits, forward error correction, parity bits, collision detection, etc to make a reliable connection. You're much better off from a time point of view taking something like a zigbee or bluetooth chip that takes all this into consideration, and writing a little code to run a chat program over that.

The TI bit-level protocol doesn't have a dedicated clock line. As Tari mentioned earlier, the protocol works as follows:

1. A pulls one of the data lines down, depending on the value of the current bit (tip is logical 0, ring is logical 1)
   
2. B pulls the opposite line down
   
3. A releases its line
   
4. B releases its line

(Calc A is the sender, Calc B is the receiver)

At each step, one calc is waiting for the other calc to pull or release one of the lines. This is what I meant by "bi-directional acknowledgment", even if that's not the proper technical term (I don't know what this type of two-way acknowledgment scheme would be called).

From what I've read, this protocol has a bit timeout of 2 seconds, so it seems like it can be stretched quite a bit.

Christop, you're absolutely right, I was misremembering a timing diagram for another protocol I was reading about as TI's own protocol. And I totally understand you calling that bi-directional acknowledgement, imagined just what you described, and thought that wasn't what TI does. Thanks for that bit of clarification.

So each bit is Ack'ed? Works well for a wire connection, less well for an RF link with mucho additional protocol overhead..