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

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'.

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?

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

actually looks like you need to comment all 4

I do not really want internet access. I am just trying to develop a robot platform above a line following LED blinker.  You know, collision avoidance, drive motor encoders, IMU, LIDAR, ICP-SLAM, basic robotics stuff  :|  Then move on to arms and IK, motion planning, high school stuff.

So an Intel NUC main processor w/windows 8 (and vs 2013), a netduino for I/O.  I guess I must be bleeding edge or something. I am not finding anything similar. Sigh, I'll work through it eventually.

http://www.spiked3.com/?p=338

I had to look up what it was, and right there on the wiki page is code.

http://en.wikipedia.org/wiki/XTEA

what is it you are looking for?

Any followup on this?  Jrc903 indicates he saw where the programs ran under 4.1, but martijn says they never could run.

I can say for a fact it dies on 4.3 (10042 Bad protocol option). 

I am wondering, is the UDP Multicast only used for anonymous discovery?  Is there a way to bypass that and get dpws functionality?

Does the gadgeteer implement dpws?

MQTT worked great for me on simple first tries. I ran a broker called mosquito, but I think the M2Mqtt guys have one as well.

http://m2mqtt.wordpress.com/

Throw in some JSON and it is cakewalk.

Yes. It is a brokered message passing system. Strikes me as identical to ROS internal stuff.  Clients subscribes to topics, and clients can publish topics. Either side can be a client.  I ran both directions in simple tests, at the same time.  Master asked for an update by publishing a request.  Slave (Netduino) published accelerometer data via a JSON string.  I'm not sure if there was a 'reply' to publish supported, as in a blocking publish, but I don't think you would want that anyhow, on loosely coupled systems.

BTW, I was unable to get the micro frameworks supplied DPWS samples (mf version of wcf) to run. It looks like they encountered an error in the MF implementation - multicast udp not supported?.  It seems to me that you should able to get around that not using 'discovery', but I did not want to spend much time on it just to run into the next problem, and no one spoke up and said it would work.  M2Mqtt worked first try, seems to be currently actively maintained, I was impressed.

Other projects I ran across had not seen activity in years, and maybe that is because they work and don't need fixing, but that is seldom the case in my experience.  I got the popular web server to run after a few code tweaks, but I would end up just making it look like M2Mqtt anyhow.

Curious how you tried 5v and 3.3v?   I have a 3.3v 9dof stick that will only work when the analyser is attached and powered on.

https://www.sparkfun.../products/10724

It has pullups built in as well.

http://www.spiked3.com/?p=421

has my learning code to date.

Ok, I apologize for my lack of hardware knowledge. I had recently been told by 'an i2c expert' that the i2c clock & data was at 3.3 or 5v.  I've since learned to not trust an expert. I was confused / misled.

My problem appears to be that if the analyser is attached it MUST be powered.  But part of me also wonders about ground loops, and maybe that is the issue.  I sure wish us software types were not forced into hardware, there is a reason I avoided it for 60 years.

You will need to look into the socket exception to find the actual win32 socket error. Google that.  I ran into a problem where dhcp had not set the address soon enough - so I finally just started using non-dhcp addresses (I think the error was network down, so it was confusing). 

I was looking for your design, I did not find it.

Which broker are you using?  I grabbed one called mosquito. Not knowing much about them I thought having a python binding would be helpful.  I don't remember having to do anything special to set it up. Just ran the install, and it was an autostarted service. Check to make sure it is running as a service (if you are using mosquito).

I just got 2 i2c devices going - and will post that in a new topic in a minute.

Had to think about this a little more ....

How do you know they are not arriving at the broker?

There needs to be a client somewhere subscribing to the topics that will receive them. I'm not sure I really see any activity on the broker - actually its a service with no console or UI, so I'm sure I don't see anything there

SPARKFUN 9DOF IMU STICK ACCELEROMETER AND GYRO RAW DATA TO WPF VIA MQTT

So, still learning, but I seem to be getting along ok, solving a few problems I see others encountering - so if the code helps anyone, great.

If nothing else it shows off WPF simplicity a little for those of you unfamiliar with with it. WPF was the intended replacement for UI on windows.  It has been made 'legacy' at this point, but the follow-up - WIndows Store apps are very similar.

http://www.spiked3.com/?p=438

direct links;

http://www.spiked3.c...2014/06/imu.zip

The video shows some 'unaligned' response. I assure you this was a video alignment problem. In actuality the response is very fast and aligned.  Next time I will do the screen capture differently as I think frame rate differences messed with me.

Just some wild guesses.

You create a new Led port in main, then eventually fall through to a infinite wait (never exit). The object reference may never be garbage collected.

In your loop you create another Led port (same pins), over and over, never disposing of it, although I guess it might self dispose in the 250ms wait, but in any case this is bad practice.  Allocate it once, in main, and refer to the same object everywhere.

You also allocate a buffer, the size of bytes to be read whenever bytes are available, then read that amount. It is probably safe to assume that a single read will do the trick in that case, no need to 'while (serial.BytesToRead > 0)'

Your comment

Just kidding  That is me, and my quad copter, but not this board.

I run a flight controller called a Naze32 on it.  It is a stm32 like the netduino, with IMU components.  I did not write the code.

http://www.multiroto...cro-naze32.html

There is no noticeable latency with the netduino attached to a pc, even with mqtt brokering, although I am sure it adds a tiny bit. Again, the video does not look as good as it really is, because of editing problems.

Sure sounds like it should see the publish messages, but you sound like you are on the right track. Let us know how it goes.

Yes. I am actually pretty advanced in the FPV quad hobby.  

The quad in the picture has a 5.8g video transmitter. The one in the video has a 1.3g video transmitter that goes to a 1.3 receiver, that retransmits to 5.8 - so I can wear the same wireless 5.8 fat sharks for both.  1.3 has better foliage penetration, but 5.8 has more frequencies channel choices - so it depends on if you are flying with friends or behind trees.

my meetup group

http://www.meetup.com/wa-fpv/

That is the best US source I know of for the board. They just sell fast (for obvious reasons). Keep checking.

No, I haven't - other than the loosely coupled idea; send a request, send a reply.

Is there something explicitly 2-way?  I'll have to look.

Glad it is working. It worked well for me without much effort also. I plan on using it as a main component of my learning robot project, knowing that if I swap a piece later (the main processor or netduino I/O), i will not have to re-write everything.

CAD files sent to be cut this week  http://www.spiked3.com/?p=338

Look at their web site (https://www.windowsondevices.com/). They claim a person can not have used both Win32 and WinRT for development. Of course that is not true, it is an artifact of web designers that have no clue, but I suspect it continues to represent leadership at Microsoft, non existent.

I filled out that form months ago, nothing. What a way to run a company.

Chris I was referring to the combobox choice when you signed up for information.  Instead of a check box, like the (incomplete) 'which dev boards have you used?' section, they ask what experience do you have, pick one; Win32 or WinRT. Anyone even vaguely technical would know there should be a lot more choices, and not exclusive.

No instead, they handed the web site off to some 'designers', and never followed up on what was produced. And like I said, even if you fill out the form and request more information, you never hear anything, from anybody.

I used to work at Microsoft, I left around the time this sort of 'management' started to become the norm. I truly feel sorry for the technically competent people at Microsoft. I hope the MF team can make something happen anyhow, but looking at their track record the last few years - I wouldn't invest much.

edit: I see they changed it in the last 12 hours. Hmmmm.

Verified.  Same issue using bitconverter.tostring(). Have to reflash.
 
my quick workaround is;
 

const string hexChars = "0123456789ABCDEF";
static string BugWorkAroundToString(byte[] buf)
{
   string s = "0x";
            
   foreach (byte b in buf)
   {
       s += hexChars[b >> 4];
       s += hexChars[b & 0x0F];
   }
   return s;
}