Two weeks ago, the folks from Spark gave us two Spark Core WiFi development boards. These unique boards are based around TI's CC3000 chip, and also include an STM32F103 microcontroller for running user code. One of the key selling points of the Spark Core is that it includes a library providing compatibility with the Arduino Wiring "language". It was the work of two weeks to port my Arduino globalCALCnet bridge (first announced here in 2011) to the Spark Core, then integrate the functionality of the gCn Bridge code.

Previously, connecting a local-area CALCnet2.2 network to the wide-area globalCALCnet network required an internet-connected computer. A piece of software running on the computer, called the gCn Bridge, was responsible for encapsulating incoming packets ("frames") from calculators in TCP/IP packets and sending them across the internet, and unpacking incoming packets to deliver back to calculators. A previous Cemetech project attempted to use the ENC28J60 Ethernet module to directly connect CALCnet2.2 to globalCALCnet, but that project was put indefinitely on hold in 2013. This current project achieves all the goals of that project, and more: it provides a computer-free way to connect calculators to the internet, and lets the calculators independently configure the bridge device as well. The two components that were necessary to make this work are the Spark Core firmware itself, modified and expanded from the original Arduino gCn bridge firmware, and a Bridge Configurator program written in TI-BASIC that is used to set the WiFi credentials and local and remote gCn hub names on the Spark Core.

You can view a video of the device in action below, as well as download the Spark Core firmware and the gCn Bridge Configurator program at the links provided. I look forward to seeing more exciting developments based on this project.

Downloads and Information
WiFi Bridge firmware for Spark Core
Bridge Configurator program
Video of WiFi gCn in action


Now this is what I call awesome.
Great work Kerm!
That is pretty incredible, and like Sorunome said, its awesome! Very Happy Any further updates you are planning?
Thanks, guys! I am definitely hoping that someone will take the time to expand my Bridge Configurator program to remember WiFi credentials and allow you to switch profiles without manually entering the SSID and password each time you change locations, for starters. I also need to finish debugging certain aspects of CALCnet BASIC on non-TI-83+ calculators. It looks like there are occasional problems with memory getting overwritten and/or the interrupt code getting stuck, and once those issues are fixed, I'll try to release a new Doors CS version (either 7.2.1 or 7.3). I also plan to try to bring CALCnet into the next version of Doors CSE, although I'd like to make it a more advanced form of CALCnet that can support different calculators on the same network being connected to different hubs; ie, make broadcasts not be truly global.
Be sure to keep backwards compatibility so that DCSE calcnet is compatible with DCS calcnet Wink
Sorunome wrote:
Be sure to keep backwards compatibility so that DCSE calcnet is compatible with DCS calcnet Wink
I've long been thinking about how a better CALCnet3.0 could be backwards-compatible with CALCnet2.2. My best options at the moment are shortening the frame "preamble" assertion of the clock line so that Cn3.0 clients would listen to frames with the shorter preamble as well as frames with the longer preamble, but Cn2.2 clients would see the CALCnet3.0 activity as noise and ignore it.
I thought at one point you had some spare bits in there to flag things for future proofing? Or am I just completely misremembering?
elfprince13 wrote:
I thought at one point you had some spare bits in there to flag things for future proofing? Or am I just completely misremembering?
There is a two-byte fixed header and a one-byte fixed footer.
Sorunome wrote:
elfprince13 wrote:
I thought at one point you had some spare bits in there to flag things for future proofing? Or am I just completely misremembering?
There is a two-byte fixed header and a one-byte fixed footer.
That's for gCn rather than for CALCnet, Sorunome. Elfprince, yes, I do have extra bits for larger frames, but I'm not sure that I correctly discard packets with those set in the existing implementations. I will have to double-check.
That's great news! I am going to want to get one somehow.

And, a DCS7.3 sounds real cool, we could remove the mouse to make it match DCSE8 while we're at it!
CalebHansberry wrote:
That's great news! I am going to want to get one somehow.
They're available for $39 from Spark and at some Microcenters, although you might want to hold off until they release the new-and-improved Spark Core that is apparently in the pipeline.

Quote:
And, a DCS7.3 sounds real cool, we could remove the mouse to make it match DCSE8 while we're at it!
Unless "we" is a magical word that means something other than "Christopher", I don't have time for that.
Some praise, then the questions.

AWESOME! Now that we don't have to be hindered by a computer anymore, gCn usage should rise as people get these. I should also add in a "good job" for bug squashing Cn2.2 bugs, as I am sure they were a headache.

questions:
1) If we find a similar - but - cheaper WiFi module like the spark core, what is the likeliness of trying to get such a device working?

2) instead of plugging this into a calc, would it still work if we plugged it into a Hub?

3) How does the core know which Hub to connect to? is that part of the configuration program?

4) Is it possible we could have multiple calcs hook up to eachother wirelessly using this (in the future, of course, if that is not already feasible)?
Luxen wrote:
Some praise, then the questions.

AWESOME! Now that we don't have to be hindered by a computer anymore, gCn usage should rise as people get these. I should also add in a "good job" for bug squashing Cn2.2 bugs, as I am sure they were a headache.
They were, and there is at least one more bug left to track down, which is not something that we're enjoying.

Quote:
questions:
1) If we find a similar - but - cheaper WiFi module like the spark core, what is the likeliness of trying to get such a device working?
Working: very likely, given sufficient effort. Working easily: moderately difficult, depending on what kind of libraries and languages in which you can program the cheaper module. If it can be programmed in C/C++, then the effort should be relatively low.
Quote:
2) instead of plugging this into a calc, would it still work if we plugged it into a Hub?
Absolutely! rfdave's hub shield would work with the Spark Core, for instance.

Quote:
3) How does the core know which Hub to connect to? is that part of the configuration program?
That's correct. You can configure the local bridge name and the remote Hub with the Bridge Configurator program, and I defined a standardized API that can be used by devices other than the Spark Core.

Quote:
4) Is it possible we could have multiple calcs hook up to eachother wirelessly using this (in the future, of course, if that is not already feasible)?
Yes, but they'd have to all be connecting to a common WiFi access point (AP) in order to do it.
Would it be possible to get it working on this: http://hackaday.com/2014/10/02/gcc-for-the-esp8266-wifi-module/
It's a $5 wifi board, much cheaper than $40
Also, would it be possible to power the wifi directly from the 84+ usb port like you did with the gps module?
Ivoah wrote:
Would it be possible to get it working on this: http://hackaday.com/2014/10/02/gcc-for-the-esp8266-wifi-module/
From what I've heard about that board, it would be difficult, but if someone wants to throw one of those in my direction, I'd certainly be willing to give it a try. Smile My understanding was that they're still non-trivial to get in the US at this point.
Quote:
Also, would it be possible to power the wifi directly from the 84+ usb port like you did with the gps module?
Sadly, no. The Spark Core requires a peak of 300mA to transmit, which the USB port on the calculator cannot provide.

Also, Hackaday posted a mostly-factual article about this project:
http://hackaday.com/2014/10/07/internet-connected-ti-84/
I actually saw that post when looking for the esp8266 post
Saw it on hackaday, congrats!

And would it be possible to fork the power directly from the trippel A batteries?
Sorunome wrote:
Saw it on hackaday, congrats!

And would it be possible to fork the power directly from the trippel A batteries?
The Spark Core can handle an unregulated VIN between 3.3V and 6.0V, so you could indeed feed it power directly from the AAA batteries. I might recommend that you add a switching regulator and a switch so you could get it down to a slightly lower voltage and so that you could turn off power when necessary, though. And of course, a disclaimer: cheating is bad. Don't use my work for cheating.
Here is a place to get them: http://www.seeedstudio.com/depot/WiFi-Serial-Transceiver-Module-w-ESP8266-p-1994.html
Ivoah wrote:


Thanks for that, I was thinking about digging one up, but there it is. Who wants to volunteer to mail one to Kerm for testing? I actually might.

I'm excited to see that it is so tiny and could easily fit inside a calculator. Also, I'm guessing http://www.esp8266.com/ has some good documentation on it.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 4
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement