The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
The secondary Netduino Go will be receiving hub profile commands, just like a physically-connected hub. That profile will wrap other gobus packets so that they make it to their destination (which can be directly connected to the hub or can be downstream even farther).
How much of this is based in C# serial code vs. using Zigbee source / destination configuration?
Is this approach XBee specific?
Are there any other Zigbee compatible devices frequently used in the Arduino/Netduino community which are not XBee?
Could another serial connection other than XBee be used with the code?
Could two Netduino Go boards be wired up over TX/RX for example and use this code?
Along with the 8-port hub, we'll also be enabling Netduino Go itself to be a wireless hub using an XBee link. Simply plug XBee Adapter GoModules into two Netduino Go mainboards and you can make one the extension of the other. It's pretty awesome. We'll be sharing video of that feature in action in the near future.
Will this work the same way as the Netduino Go and Shield Base proxy example?
Where the primary transmits it's functions async over serial via byte arrays to the secondary?
Thank you for everything that you do. Your passion for this product and community really is awesome. Some folks can fake it and go through the motions, but it shows that you are truly passionate about the product and people. I am a complete newb to this hardware stuff, but I have learned so much reading this forum and posts you have made. I generally skip over all the love posts where people say thanks, but this is my one time where I want to say, Thank You.
The C# implementation is not performance optimized. We'll want to move to native code for that.
The UART transport is really useful for external IO...but the SPI transport (packet switching) will be the solution for fast virtual i/o.
We'll be doing a lot of performance tuning around packing/unpacking frames. It shouldn't be too much overhead, in the grand scheme of things...especially when considering that transfer will take place in the background using DMA.
So it's obvious by the code that the shield base can function as it's own Netduino and run micro framework code. Is this an intended use of the shield base? Is there more information about how to use the shield base as it's own Netduino?