I have been slowly tackling this and want to try a more hardware dedicated solution then my hackmejob attempts with my ez430 rf2500


I am still thinking a msp430 micro controller and a cc2550 would be a perfect pairing for this task tho. Thoughts?

Well, the cc2550 is a transmitter only, for starters, so perhaps you mean the cc2500, which is a transceiver? It seems like it would be a good choice to me; I'm just wondering how we'll build mesh-ish capabilities into this. Should be very interesting.

Really I thought the cc2550 was that oh well looks like it isnt.

And what do you mean by mesh-ish capabilities?

I only figured it out once I read through the datasheet, understood the TX protocol, and realized it had no information about how it receives. I scrolled to the top, and lo and behold, "transmitter" instead of "transceiver". Mesh-ish in that when a CALCnet frame goes out over the network, everyone sees it. For broadcast frames, that's a requirement; for directed frames, ie, those sent directly to a target calculator, we might be able to do something tricky.

Well the way the simplicti stack is setup (when it works it works well when it doesnt its garbage) each adapter we make can get assigned a custom identifier. which im sure we can make this setupable to a calc and get an id sent to it over the i/o port or something.


also in any network with the cc2500 there will be a hub node that can handle all the finicky stuff like communicating with the computer and handling broadcast frames and such

Hmm. I definitely like the idea of a hub acting as a gCn bridge, but I don't like needing the hub in order to have any sort of network, as CALCnet is supposed to be ad-hoc. I bet we can figure out something without a hub, although we'll probably have to assume that all of the calculators in the network are in range of all the other ones. Alternatively, we could run metadata around to figure out who can't hear who, and repeat messages as necessary. The cc2500/cc2550 has a max bandwidth of 500Kbps, whereas CALCnet tops out around 4kbps, so we have tons of spare bandwidth to work with.

Well I could set it up so that there can be a calc side program to configure the adapter prior to initiating the calcnet protocol. So we could easily remove the hub that way. And have options to link with a computer side hub etc. etc. etc.


And i would expect closer to 100kb/s throughput on this as we would be running this at low power probably which means a low clockspeed on the mcu so lower data traffic. Tho that depends on alot of factors sooooo yeah

Certainly, but still way above what CALCnet can manage calculator-side, so I think we have plenty of room to work with.

This is my first post. It was great to see you at Maker Faire. I thought I'd put in my two cents, maybe it will assist in some development aspects.


Instead of thinking on your typical topology of dedicated hub, why not have a variable master hub in a similar theory to ciscos stacking technology. Upon starting calcnet the adapter attached to the calc is put in psudo monitor mode allowing it to monitor for advertisement packets sent by the master hub(s). The user is then displayed a list of all the master hubs within their range. They are then allowed to join a master hub or create a new master hub (network). The structure within this network is such that the calc listens for these advertisement packets after joining then master hub. When the advertisement packets have not been recieved from the master hub within a certain threashold a control packet is broadcast to see if any other calcs have contacted the master hub. a reply is then sent from other calcs (yes, no, true, false, etc). If no reply is recieved an out of range or hardware error is raised. If replies are recieved then then new master hub election takes place based upon a unique identifier within the calc (MAC Address lets call it) and a specified value unique to each network which is then added to the MAC. The lowest value is then elected master hub and the network continues. this way the network has the redundancy and portability between enclosed spaces. it also allows for private networks for information which should not be broadcast to everyone.

I think the ultimate goal is to not have a hub if at all possible unless ultimily required. Which is doable based on how calcnet is managed actually is pretty easy with the simpliciti stack. The only reason a "hub" would be needed is for internet access. Which is easily managed as well


Also welcome aboard esaucier be sure to check the introduction topic im sure Kerm will make a link for you to ^^

Yeah, I think decentralized would be ideal. One idea I came up with while riding the subway today would be for each wireless bridge (we need to come up for a name for what this thing actually is, adapter? bridge? widget?) to occasionally transmit a fixed-sized, short hash of the addresses of all the devices it had heard from recently, plus its own address. It could figure that out by simply monitoring frames coming from its connected calculator, and could (perhaps) be silent until it first received an outbound frame. Each other wireless adapter nearby could check that against their own hash, and if the hash didn't match, request a verbose list of known IDs from that original sender. It could then ask that other adapter to retransmit a frame on its behalf to the calculators it couldn't reach. There would be a huge issue of how to actually get frames to be repeated over the 'mesh', if that was necessary, without having receivers who heard multiple copies of the same frame send it to their attached calculators multiple times. All this makes me think we should just focus on getting a version without mesh capabilities working first, assuming everyone can hear everyone else, and then worry about variations later. Mesh networking has been studied in depth, so we might be better off trying to build on existing work than re-invent the wheel, anyway.

Also, esaucier, feel free to Introduce Yourself when you get a chance.

I was intending on building it assuming every adapter (thats what im going with) can hear all the others. At least for starters. I know for a fact i can include an updater function over a i/o protocol to update the devices if i push an update so.

But yeah im going with assuming everyone can hear everyone else.

Great. So for a prototype I guess we'll at least need two (or three) microcontrollers and two (or three) transceivers. Is there an issue with interference with WiFi at 2.4GHz, by the way? And what features of the MSP430 make you suggest it as an applicable microcontroller, out of curiosity?

The main feature of the msp i liked it for was its very low power draw. Meaning we could easily power it over the i/o line and nothing else (like every time the clock line is high siphon some current into a cap to keep the device running). I already have my two testboards which is what i will be working with for prototyping. Has some built in i/o functions for debugging as well but thats just useful.


I dont think there is interference from wifi never honestly thought about it.

Bridget.


Depending on the exact pull-ups on the calculator, you may have a hard time getting even a few milliamps out of it over extended periods of time. These radios take significant amounts of power when in active modes, too, since the important bits in there are all analog.

its still worth a shot i mean i know i have powered leds off of the i/o lines before. IDk we shall just have to test it and find out. can always make them plug it in the backcase lol

I'd say we're better off just powering it normally, personally. A simple Li-Ion battery and a tiny charger chip plus a micro-USB port for charging would work well. Although I love the out-of-the-box thinking of avoiding the power supply entirely.

Well we can always hammer that out later I guess xD probably should get a working prototype first which will happen eventually if i get time to relearn what little I know about C my dev environment is almost setup on my netbook now

Any other sporadic ideas to consider? Right now I like whats on the table.

I like it too. Three other questions that occurred to me: how many GPIO pins do we have to work with on the MSP430, what's its power usage like, and what's the cost looking like for MSP430 + cc2500 + battery + MAX1555?

for the battery and the max1555 (what is that?) i have no clue the cc2500 is about 2.5$ a piece from avnet if I remember correctly and the mcu is anywhere between $0.45 and I think 2 dollars (the value line is really cheap and seems to be more then ample for the product we want Linky)

There are a few other odd and ends parts on top of that we will need. caps and resisitors and stuff but im not to worried about those they are cheap