Breaking out of pre-built Arduino

Hello,
A buddy of mine and I got the idea for a class project to expand upon the "Skylanders" and "Disney Infinity"-type games (with the toys that, by means of an RFID tag). Since RFID tags have a maximum storage capacity of about 128 Kilobytes, this is obviously quite limiting in what can be stored on the figurine. We would like to expand this storage using flash memory to something on the order of ~1GB, so things like entire high-res models can be stored on the figurine, so anything, not just the figures available, could be placed into some hypothetical computer game and played with, each with their own models and possibly unique rules and persistent statistics.

Each figurine will have its own system and storage, and we plan to transfer data by means of Bluetooth. Power will come from the base station by means of inductive charging (Adafruit has some nice kits which will supply all the power an Arduino chip needs).

Obviously, size will be a large consideration, and while we could likely use an Uno-and-shield setup for the base station where it is not as much, to keep the figurine size down we would like to move away from the pre-built Arduino boards and build our own.

This is my main question, then: What is the best way to go about doing this? Each figurine will need:

  • A controller - I'm thinking this or this depending on whether or not we want to deal with SMDs (to save space) or not
  • A MicroSD card module to store the data (OR some sort of flash memory or EEPROM, which for size and price reasons would most likely be preferable but I really don't know the first thing about adding something like this to a project. If anyone has any ideas, I'd love to hear them!)
  • A Bluetooth module to communicate with the base station and transmit data
  • An inductive power module. Adafruit has some good ones.

Mainly, what I'm looking for here is for some guidance. What other parts do I need to make the AVR controller work properly, and to program it? Is Bluetooth really the best wireless protocol to use, or is there something more suitable? Are there any good tutorials for using flash memory or EEPROM, or for building up an "Arduino" controller like this?

I really appreciate your help. Thank you!

Before going any further what sort of bandwidth are you expecting? Are you expecting
native-mode performance from an SDcard for instance?

Are there any good tutorials for using flash memory or EEPROM

Not at the 1GB level.
I think you need to scale your ideas down to something that can approach reality.

Since RFID tags have a maximum storage capacity of about 128 Kilobytes

Some types of smart card RFID can store this value but most store around 2K, and the 125KHz type store 128 bytes or less.

We would like to expand this storage using flash memory

You want to add flash memory to a passive RFID tag? I do not think that is possible.

Have you got any experience in engineering, this is a major development program not something you can just throw together.

Grumpy_Mike:

Are there any good tutorials for using flash memory or EEPROM

Not at the 1GB level.
I think you need to scale your ideas down to something that can approach reality.

We would like to expand this storage using flash memory

You want to add flash memory to a passive RFID tag? I do not think that is possible.

Have you got any experience in engineering, this is a major development program not something you can just throw together.

Yeah, we have experience. From what you've said it seems at EEPROM or flash memory is not feasible (by the way, we don't want to "add flash memory to a passive RFID tag," - maybe I worded it strangely but we want to replace the RFID altogether). Therefore, it seems a MicroSD card is the way to go and I guess what I'm looking for is advice on how to begin fabricating "our own Arduino" setup.

MarkT:
Before going any further what sort of bandwidth are you expecting? Are you expecting
native-mode performance from an SDcard for instance?

Well, I don't think we'll be limited by the bandwidth of our SDcard but rather by the wireless connection, which, if I recall my Bluetooth correctly, is in the range of around 3 Mbits/second for Bluetooth 2.1. So, not that quick, especially for the amount of data we're talking about, but that's fine.

I think it might be more realistic to use the RFID to identify the item, and to store the associated bulk data somewhere else that can be looked up via the ID.

Just in case it's relevant to your project, the CastAR project includes active and passive RFID location of multiple tags, and seems to support I/O between the tag and simple local electronics devices via a microcontroller. I'm not sure quite what you want to achieve, but using RFID to identify, locate and track multiple figurines which may include some local behaviour or data seems a very good fit to the CastAR system.

PeterH:
I think it might be more realistic to use the RFID to identify the item, and to store the associated bulk data somewhere else that can be looked up via the ID.

This is exactly what we are not trying to do. That's what Infinity and Skylanders do and they're limited to what is stored on the base station (or in the game). With a system where everything is on-figure, it could theoretically be almost infinitely extensible - you could create your own game piece and play with it.

acegard:
With a system where everything is on-figure, it could theoretically be almost infinitely extensible - you could create your own game piece and play with it.

On the other hand, with a system where everything is on-figure, in practice it will be ham-strung by the limitations on the amount of data that you can actually retrieve from the piece using RFID and the length of time it takes to do that. And, once you have retrieved the data, you still have to pass it to something that knows what to do with it - you'll still completely bound by whatever restrictions that device imposes on the format, content and quantity of data it's willing to handle. If you choose to bypass those restrictions by creating your own device which does (whatever you need) then you're back to the original situation, where you might just as well have passed the bulk data directly to it instead of trying to cram it over an RFID link.

But we're not using RFID. We're using Bluetooth or Wi-fi Direct. Forget I even mentioned RFID.

acegard:
But we're not using RFID. We're using Bluetooth or Wi-fi Direct. Forget I even mentioned RFID.

Oh, sorry, I must have misunderstood.

So, you're going to use BLE? I've read about TI's new BLE-Stack but never used it. They still need 20mA or so, though. Can you supply that much inductively?

I'm not sure if I fully understand the game play, but the suggestion of PeterH make good sense to me. The characters only have a key and the "base station" has the data.

At first thought, I might use a Raspberry Pi as main station with Arduinos in the characters. With the RPi, data storage becomes a a much easier problem to solve with much greater bandwidth, cpu speed, programming flexibility, etc.

With the characters, I would strongly suggest prototyping with commercially available boards to test out your concept before making your your own circuit boards. For eample, the Arduino Pro mini is much smaller than an uno. There are many others such as Ardweeny , TinyDuino (all of which I have used).
There a recent kickstarter http://www.rfduino.com/ with bluetooth built -in.

PeterH:
So, you're going to use BLE? I've read about TI's new BLE-Stack but never used it. They still need 20mA or so, though. Can you supply that much inductively?

I hadn't heard of this, but perhaps. Yeah, the inductive chargers you can get from Adafruit will supply 500 mA, which should be enough for each character.

This is what other systems currently do, with the limitation that if you want to make a new character available you must push an update to the base as well as fabricating the new figure. If all the data were stored on-figure, one could simply fabricate the figure and be all set up to go.

[quote author=joe mcd link=topic=194274.msg1436189#msg1436189 date=1382308636]With the characters, I would strongly suggest prototyping with commercially available boards to test out your concept before making your your own circuit boards. For eample, the Arduino Pro mini is much smaller than an uno. There are many others such as Ardweeny , TinyDuino (all of which I have used).
There a recent kickstarter http://www.rfduino.com/ with bluetooth built -in.[/quote]

Thanks for this! RFDuino looks like it might work superbly.

If all the data were stored on-figure, one could simply fabricate the figure and be all set up to go.

In my mind, the trick here is to store the personality on Flash and "register" that with the game by enforcing an I2C download of the flash contents - one time. The interrogation of the piece via BT/WiFi transport would return XML which could be quickly parsed and then specific rules could be extracted from lookup of the playing-piece downloaded tables. This makes for a few seconds for piece pre-game "registration" via simple mechanical connections and very fast gameplay and rules lookup once a piece is wirekessly interrogated, validated from returned XML (is this piece suppose to be in this game? Was move ligimate? Was time-to-move proper?, ETC.)

simple, flexible, identical play hardware, identical base hardware .... Infinite software potential.

Ray

Mrburnette, is this assuming that the 3D-model of the piece is stored on-figure as well? Good thought with the initial I2C download. That's likely a lot faster than wireless, especially if we're talking about models as well.

3D-model of the piece is stored on-figure as well?

The XML representation of the 3D definitions on piece could be controlled by various sensors. For example, if a piece was "square" and was being placed into a "round" board space the XML would provide the board computer, when interrogated with all dimensional data in the WireLess stream. Validation could then be made on true dimensions.

Added:
Or, all dimensional data for a piece could be downloaded initially. The tradeoff becomes a bit complexed - the more complex the game, the more sense it makes to have the board computer rely upon the download for most physical attributes and the realtime interrogation for things that may be sensor driven: x/y/z, acceleration, touch sensing, etc.
Ray

Good thought with the initial I2C download.

We could also do this optically instead of mechanical contacts if a little extra cost did not inhibit you XD

Ray

Don't get hung up with thinking all the data has to be avaliable from the remote location. How about the situation where then new piece is introduced into the game by putting it on a special pad, thus transferring all the data through contacts. And then the location / position could be sensed remotely. This cuts down on data transfer time and high speed wireless communication.