Again, thanks for the noob pointers. Yes I am quite experienced as a developer, Remoting, WCF, WPF all all pretty much second nature to me and I cringe on the thought of not having them.  But Solder? I cringe at thought as well  But as I mentioned, I have done some. I have the saleae analyser that does I2C and others, as well as the newer one which adds analog (oscope), on order  

Yes getting vs2013 up was the first step.

So I had a look at the internet of things. I ran step 1 ok, step 2 was not blinking the light, so I added a Parameters.Setup(), because I didn't see where the proper pin was being set.  And that invoked the 'sign up for you private key, we only want your personal information' routine and I bailed.  I'll see what I can get from the code, but I really dislike that kind of dishonest thing. If it truly can be run without it (as advertised), one preprocessor variable should do the trick, not 30 minutes of chasing down unrelated code.

I'll take a look at Mark's blog now.  Mine is at http://www.spiked3.com  <- warning; not open source friendly at all

Thanks Jack.  The mac has been configured, that is why I indicated it had gotten a valid dhcp IP - it pings fine, but it is nmikaweb server that is getting the network down exception.  I'm trying other IP stuff to see if I can figure it out. One thing I notice consistently is the use of non-dhcp, which might be a hint, I can explore that angle on my own more.*

Yes, debugging is crucial, otherwise I'd just as soon use an arduino. So I need to do both, communicate and debug. I would have to disagree though on simplest way to communicate, if I can code a object, import its wsdl file into visual studio, and treat a object on a remote device (netduino) as local (intel NUC), that is simple.  I understand your description is more from a bytes across the wire point of view, not a developers point of view.

I'll take a look at the internet of things.

*so yeah - after double checking before posting this, I am finding totally unreliable unrepeatable dhcp usage. time to go fixed.

Update: yep, going to fixed, it is now communicating.  So a question remains, has anyone used dpws and what was the experience, good or bad?

Any speed comparison between dpws(ethernet) and USB? I can find out the hardware differences (12mbit v 10mbit), but some feel for the actual stack throughput / latency on this particular device (plus 2) would be helpful. right off the bat I would think dpws would have the advantage of ease of use (WSDL) in visual studio, if it performs as well, does not require extra hardware, then it is the obvious choice. This assumes dpws works as intended (and any insight on that would be helpful).

So far I have been unable to get any ethernet communications going. MF deploy indicates good DHCP obtained config, but ReceiveFrom throws 'Network is down'.

Hello all, Netduino Noob here, so apologies. I'm quite experienced as a .Net developer, but slightly new at robotics and MF, having done a little of both.

I have a robotics project where the Netduino is intended to serve as the hardware interface, and communicate back up to the WIndows app.

This involves some sort of remoting. So in googling, I've run across a stale remote project (http://kaushikspotse...s.codeplex.com/), Microsoft dpws, and now this.  

I tend to gravitate towards this since it has some fairly recent activity and is the most specific for the Netduino.  Is that the correct assumption?

I also notice that at present because of interaction with the debugger a separate FTDI is needed. I happened to have the Sparkfun 3.3v FTDI breakout board already (not the cable, but the equivalent board).  Will this get me going? Am I on the right path?

Mike