Not from me. Haven't sat down to figure out some stuff I need to for working with my controller instead have been distracting my self with my lcd ^^


Can you do me a favor and outline your program flow roughly for what you do with the arduino bridge to look for and handle the connections and i/o stuff? Want to get this to work the first time so I'm trying to make sure my thoughts on how to set it up are ok. (having a bit of trouble wrapping my head around how to detect when a frame is being sent and such as well but one step at a time ^^)

Maybe I'm just boring, but my first chunk of prototype software would basically bit-bang the protocol, sending a packet over the radio when one of the lines changes.
It's easy to implement (at a protocol level, anyway- maybe less so at the link level), and is protocol-agnostic so you can use that mode for various other things such as for the TI link protocol or any other serial protocol that doesn't depend on strict timings (particularly I2C).

Tari: I'm fine with that, if we can get enough speed and reliability out of it for that to be feasible. There are a few problems, though: since every state change needs to get broadcasted to everyone else, everyone will need to keep track of who pulled a line low (counter?). Thus, to know when a line can float high again (counter == 0), everyone who pulled it low (counter++) will have to release it (counter--). If any packets get lost, potential problems. Of course, it would be easy to instead have each peer maintain a table of the current line states of all of their peers, so that if there is a missing packet, the next packet that succeeds will correct the incorrect state. Just thinking aloud here.

The Schematic looks pretty good. You might want to consider running some port lines from the 430 to test points for white wire hacking. You know, just incase...

I was even hoping for a few unpopulated through-hole pin areas to GPIO pins that enterprising hackers could use.

I agree with the last few posts there pins put out to GPIO outputs would be wondrous.

As for that idea tari the only issue with it is the time it takes to send a simpliciti frame we would miss more than one bit And interuptts wouldn't help us very well as simpliciti disables them for radio use. I mean it is doable its what I did with my first project with the simpliciti stack its just not the most feasable

I honestly don't see a huge reason to use SimpliciTI. With the reading I've done on the interface to the radio hardware, it's easy to do simple packet-based communication without any libraries. Though more fancy things will almost certainly be necessary for proper many-to-many networks.

As for headers to break out, I'll see what I can do. It's mostly dependent on the amount of board space I have available.

I have not looked into interfacing with the radio manually tho I really should do so. Task for tomorrow / this weekend maybe.


As for bitbanging the data. We can always modify simpliciti to allow nested interrupts and have it push data that way and just hope it Doesn't mess with radio timings to much.

And if we have to make a decision between a larger board and simple solder-able pads for the GPIO breakout (or none at all), I'd opt for the smaller board.

Geek: With regards to your question from last night, it basically runs a loop that constantly polls both the I/O port and the serial buffer. The serial buffer gets filled by the Arduino's serial interrupt, and when there's a full frame's worth of data, the Arduino pushes it out over CALCnet using the CALCnet protocol. When it polls the I/O port, it checks the clock line, and if it's low, it checks if it stays low for the length of time that indicates a frame will be sent from a remote calculator momentarily. If it does, it listens, receives the frame, and if it's to a calculator it doesn't know of being on the local network, it sends it out over serial/.

So if I am chekcing to see if a frame is pending being sent I would poll the line check to see if its low. If it is pause for ~< 52uS then check it again and if it is still low start receiving data over the i/o lines?

By the way, I heard a tech talk about this concept today and I think that it would be great to implement into the wireless CALCnet adapter:
http://stanfordcs244.wordpress.com/2010/02/10/wireless-protocols-lecture-8-2/
Basically, it's a software algorithim that can sort out interfering packets in order to differentiate between them, so that multiple packets can safely be sent at once. I don't think that you would need to modify the hardware at all to get this to work.

You can't just check once and then again later. You have to constantly poll for the whole time, and it has to stay low. The line could be fluctuating for that whole time, and only happen to be low the two times you check.

Ok thats what I thought. I will make use of this information eventually >.> <.< working on some other code for now.

Bump.

The solder paste showed up today can any of you direct me where to buy smd components so I can order some just to mess with?

Also Tari, KermM had some questions for you regarding the PCB design has he nagged you about them yet?

He's nagged me a little, but I haven't found the time to work on it. It may have to wait until the end of my semester.

Also noting a request from Kerm: break out three ADC channels from the micro. This should be easy, since all 8 of the ADC channels on our micro are on the corner of the package that doesn't have anything connected nearby. I just have to bump one of the decoupling caps out a few millimeters.

Actually, two ADC channels should be enough, I think, plus a ground connection. Unless you think I should request four and tie two pairs together.

Geekboy-Digikey/Mouser/Adafruit/Sparkfun all should carry SMT parts as well as sample kits. I've got some 0805 and 0603 laying around if you just want some solder practice.

@rfdave. I will probably just buy a handful of them for my own collection. if making these boards work out well I'm likely to do it alot more often for my own projects and the like so they will be nice to have

*bump* I think I may have found us an alternative that we could pursue in addition to our wireless CALCnet project or instead of:
http://hackaday.com/2013/01/12/finally-ti-is-producing-simple-cheap-wifi-modules/

No IPv6. :-/

I finished routing a preliminary board this morning: