*bump* I'm working on debugging the timing issue that AhAwesome reported that causes long messages to not be received by the Arduino. Specifically, there's a loop on the Arduino that calculates the time to wait until transmitting the checksum so that the calculator will have a chance to calculate the checksum on its own. My calculations indicate it should be 17μs base + 12.33μs per byte, but that only seems to work up to 70 bytes or so. I have a few tricks up my sleeve, though; will keep you all updated.

*bump* Spent about 8pm to 4am debugging things. Figured out (I think) proper timing; 14.667 instead of 12.333us?! I spent two of those hours or so writing software flow control on top of my serial protocol, because the Arduino serial buffer is 128 bytes, but CALCnet2.2 frames can be up to 255 bytes of payload plus 12 bytes of header and 3 bytes of guard for a max of 270 bytes. Oh my aching sanity, and it's not even completely debugged yet. :/ I suspect the nonblockingness of the serial connection is wrecking havoc somewhere in the flow controller.

That sounds nasty. You have my pity!

Thanks. I've made slow, slow incremental progress; it turns out I misremembered part of my protocol, so I was sending the flow control in-band instead of out-of-band. I'm working on overhauling the protocol accordingly now.

A quick question regarding gCn, the C# libraries, and CALCnet. Will the data I send to the gCn hub will show up exactly the same in the gCn receiving location? As in, if I send (exactly) [100,200,100,150] to the gCn hub, if I check (ReceiveBank+3), will it be 150 (pretty sure it will, but just making sure)

Yes.

Yes and no. The gCn metahub, as you might imagine, does routing based on the information in the header of each frame. Those with a non-0000000000 recipient get routed to the specific gCnClient that has that calculator (or dropped if the specified endpoint is unknown). Those with a 0000000000 -recipient, aka broadcast frames, get copied to each of the other endpoints on that particular virtual hub. However, the payload of each message is kept intact. If you read the Cn2.2 whitepaper, you'll know that the Cn2.2 frame consists of 5 bytes of receiver address, 5 bytes of sender address, 2 bytes of size, and then 1-255 bytes of payload (technically the entire framework supports up to 65535-byte frames, but the oncalc interrupt only has 255-byte buffers). You can't send any data for the entire frame, because the gCnHub will ignore it as unroutable. However, it won't interfere with the frame's payload.