Last weekend at World Maker Faire 2014, the folks over at Spark were kind enough to give us two Spark Core devices. This little dev board has a CC3000 and a Cortex-M3 on board, the former for WiFi and connecting to the "Spark Cloud", the latter to execute compiled user code. Tim "Geekboy" Keller took one of the boards, and I took the other one: my first obvious project was to use it to connect a calculator to the internet wirelessly. The globalCALCnet project already lets calculators browse the web, talk on Internet Relay Chat, transfer files, and play multiplayer games across the internet, but it requires a computer to bridge the local CALCnet network to the internet.

The Spark Core runs Arduino-like (Wiring-like) code, and connects directly to WiFi. Therefore, it was relatively easy to combine the gCn Bridge that runs on an Arduino and the gCnClient that runs on a PC into a single Spark Core firmware to connect a calculator directly to WiFi. Currently, I have taken the existing gCnBridge2 code and transformed it into a gCnBridge3, with the necessary conditionally-included code to connect to WiFi, connect to gCn, and bridge to IRCHub. You can see this demonstrated in the photograph below; the USB cable is merely providing power to the Spark Core board. The next step is to use a special endpoint address (I'm thinking FFFFFFFF) to let the connected calculator(s) directly configure the Spark Core board, specifically to set its WiFi network, security, and password, and to set the remote hub and local hub name. I will update this topic as that progresses.

After this project is done, I'm excited to try porting this to the CC3200 dev kit that Texas Instruments (not TI Education) generously mailed to me for that purpose.

Very nice. I have had this idea but did nothing with it yet. Thank you for the inspiration. Maybe I should see what the casio prizm provides as far as usb support. Maybe it too can act as a host.

To my knowledge, very little has been uncovered about its USB controller (unless Simon has more obscure documentation), so that sounds like a great idea. I should note that this device is connected via the calculator's I/O pins, and is bitbanging CALCnet2.2 the way that the Arduino bridge bitbangs CALCnet2.2.

Also, I just implemented controlling the Spark Core's RGB LED to show message transmission and network status, so I can pull the external RGB LED off the board.

That's really awesome. Love all the cool stuff you put together.

Yes I see for some reason I looked at the picture wrong and though you were utilizing usb OTG regardless I think exploring usb on the casio prizm would be interesting.

Have the Spark guys been following this? Seems pretty awesome.

Is it feasible to power it off of USB on the 84+ models? Or are the power requirements too high?

That is some wicked stuff right there.

Thanks, that means a lot to me. I like hacking on fun/cool projects, and it helps when you guys enjoy the things I make. Props must go to Geekboy, the Spark guys, and so on for making this one possible.

I'm going to tweet it at them once I write Cemetech news, which will come after I get the direct configuration stuff functioning.

It needs a peak of 300mA during WiFi communication, so I think it's too high.

Thank you, sir!

Current status: I worked on implementing calculator -> Spark configuration last night, and I've run into the following problem. When I use the DCSB Libs to try to send a frame to the Spark Core, which I have designated CALCnet address FF:FF:FF:FF:FF, the calculator freezes with the run indicator running and the bridge indicates that a frame was received, but that the calculator did not properly acknowledge the checksum calculated by the bridge (the Spark Core). In other words, it didn't send the 0xAA that indicates a correct checksum was received, and it instead simply quit from the SendFrame routine. This is supposed to make it continue to retry the send, but it seems to instead just be locking up with the run indicator running. It looks like this might be a compounding of two issues: some problem with checksums and DCSB Libs, and some previously unseen issue when checksums don't match.

Edit: In fact, it looks like the Cn2.2 code actually does a ret nz when the checksums don't match, rather than jump to Cn2_Int_Done_QuitOK the way it's supposed to.

Edit #2: Re-reading the code carefully, this will potentially break USB-based CALCnet, but it shouldn't make a difference to I/O-based CALCnet, which is what I'm using.

Edit #3: I tried writing a simple receive loop program on another calculator and connecting it to the original calculator running the code below, and that new calculator also ended up stuck with the run indicator active, responding to no keys.

Code:
That assembly chunk there corresponds to the follow code, and puts FF:FF:FF:FF:FF into θ (theta):
Code:

Calculator WiFi?! Very impressive!

The possibilities that such a project opens up is mouth-watering when you think about it.

Where 300mA is too high for a calculator, its still a fair bit lower than what such modules were running at a few years ago iirc. In a couple of years you never know what the power requirements might be.

* also looks at Ultimate Calculator project and spies an opportunity for integration

Now, as was mentioned at Maker's Faire, all we need to do is find a way to mount this inside the calculator, and the world tech markets can be ours to dominate. (or the SATs, whichever is easier)

Thanks! It has long been on my to-do list, and the Spark Core makes it relatively easy.

Absolutely, and we're seeing a proliferation of low-power, inexpensive WiFi modules usable with simple embedded dev boards.

Yep, delta the concerns of making it obvious the calculator has wireless capabilities.

I'd prefer it stays as a very obvious and brightly-colored novelty outside of calculators. TI struggles enough to keep what they already have on exams; let's not give the standardized tests any reason to stop liking our beloved programming platform.

Continuing the debugging from my previous post in this topic: because I was able to replicate the Cn2.2 BASIC library problem with two connected calculators, I realized I can now do some debugging with PindurTI without the problem of needing to somehow connect the Spark Core. More edits with progress coming soon.

This is awesome! So in theory, the need for a cable to link to your calculator might be evolving... That would be nice.

Yep! And because Sandpaper v1.0 exists, it has come full circle, and you can use a wireless cable to transfer files between two calculators.

Edit: The following pair of programs works fine on PindurTI with TI-83+ ROMs, but the receiving calculator freezes when I run it on a pair of hardware TI-84+ calculators instead.

Code:


Code:

*bump* Looks like two TI-83+SE calculators running Doors CS 7.2 have this problem as well, frustratingly enough. In fact, I am running a version of the program that just uses the broadcast address and therefore no checksum, so I'm not sure what in the CALCnet BASIC libraries is breaking.

Yeah, as soon as graphing calculators get WiFi I'mma ditch my smartphone. It'd be handy though if we could, in that case, get more services running on the calc - like email, phone or text. I'd like to make calls from my graphing calculator.

Two TI-83+ non-SE calculators do not have this problem, both PindurTI and hardware. The mystery deepens.

http://www.cemetech.net/forum/viewtopic.php?t=10321
Mateo's Ultimate Calculator can provide power, so put 2 and 2 together.

Self powered wifi for your calc!

Kerm: Looks amazing, what's the estimated cost of materials?

Well, as we discussed on IRC, I believe that that port is pretty much just connected directly to the calculator's batteries, so the same effect could be achieved by running a pair of wires into the battery compartment to power the Spark Core. Hopefully Mateo will correct me if I'm wrong about that. Another option would be a 3.7V LiPo battery with a simple charging circuit, and perhaps a 5V or 3.3V boost regulator or just regulator.

The Spark Core itself is $39, and the only extra hardware that you need is half of an I/O cable. It would probably cost an extra $20-$30 for a battery and charging/regulator circuit, depending on what you used. I'd love to create a standard board that the Spark Core can slot into that also has an on-board charger and regulator and socket for a LiPo, but I doubt a lot of people would be interested in purchasing it.

We continue to debug CALCnet 2.2 BASIC. Geekboy managed to track down one Link Assist-related problem, which makes broadcasts from calculator to calculator no longer freeze the calculators, but it appears that directed messages still cause an eventual freeze or crash.

throw a few together and sell them on ebay, or just within the cemetech community...
I would buy one!

Hmmm... Contest prizes???