@baxter: those boards are USB host modules, I was under the impression that a USB device was sought after. @Haurucki: As I gathered, you're looking to make your Netduino present itself as a USB virtual com port to the host PC, right?

Hi! Found a few things to be a little odd, I'm not sure they'll solve your problem though. You are creating the trigger port each time GetDist() is called. If you wish to share the same trigger pin among multiple class instances, declare the trigger port member as static instead and make sure it only gets created once. Create both the trigger and echo ports in your constructor and store them in private members. Remove the pin members since there's no point in remembering those any more. About interrupts, when adding an event handler, you are only registering a method to be called if and when an interrupt occurs. You are not, as your comment implies, waiting for it to happen at that point. This also means you should move event handler registration to the constructor as well. How are the the instances ultraSonic1 and ultraSonic2 created, what parameters are passed to the constructor?

Hi! While looking for adjacent info, forum member emg mentioned this module: http://www.ebay.co.u...e-/270762577188 That and other alternatives was discussed in this thread: http://forums.netdui...for-rtc-backup/

I should expect so and hopefully even runs NETMF !

 

...and it really was a time machine!

Looks sweet, don't know what it can do but still only a question of how much I should place!

Yes, where is it?

I must say, I never expect a smartwatch - I was so wrong, so very wrong!

 

How much?

Awesome video! - must have taken months to combine all those separate videos into one.

 

EDIT: Too me, the video would suggest something with an LCD on it.

Could be sort of....the mystics around this seem to thicken by the hour...check out this post:

 

http://forums.netdui...mepage/?p=49589

 

Code cracked!

I actually edited the post on 1:57 but that doesn't show...I initally wrote 4 minutes, but you beat me to that 

No, its 3 minutes 

I agree, a Netduino is not a good choise for those things and I don't even think the PI could cope. Any of those would probably be a really big detour from achieving what you want. As all of the bullets are pretty high level stuff, I'd recommend using a PC. Later, you could move to a micro or nano ATX if size is important. Of course, a Netduino could perhaps handle some of it but what's the point if you got s PC on the side. To be quite honest, I think the stuff you've mentioned taken together could take years to develop no matter what hardware you got.

...and here's how I did it:

http://forums.netdui...-potentiometer/

Can you see what the oscilloscope says? 

 

 

I'll be uploading some code later so we can compete in drawing the best oscilloscope art 

 

I used an MCP41100 digital pot for drawing the signal and here's the code for it:

http://forums.netdui...-potentiometer/

Good, then it was as I suspected and also the solution was the one I suggested earlier:

 

Also, I see you got rid of the redundant calls to IndexOf (as I also mentioned).

Hi! I'm not sure but could be the VB implementation of the IndexOf imethod s one-based and that zero means "not found". If so just substitute "greater or equal" for just "greater" or simply replace the zero with a one. Also, your loop repeats the same call to IndexOf for as many times as there are characters in _src - is that intentional and if so, why?

I see, well then I suppose gfcwfzkm's tests did not run under the micro framework but under the regular. Btw, you do mean "iif" and not just plain old "if", right?

Also, IndexOf always returns -1 if not found.

In C# it does but are you sure it does so in VB too?

It doesn't seem to judging from the solution and VB is traditionally 1-based.

Ah, I was totally unaware of that, thanks for the info. I really liked the last part about the new operator being "short circuit" so that it only evaluates the true alternative and not both as the old iif did. I guess my VB is gettng a bit rusty from all the C#.

Perhaps you got the msb/lsb conversion wrong or the values are signed? The ratio between inches and centimetres seem correct most of the time. I trust the I2C pull-up resistors are in place. Got any pins floating?

Yes, two 10k resistors i parallel should correspond to a single 5k resistor. Well, it was just a thought.

 

Looking again at your code and comparing to the user manual you referred to, it seems you're are doing the reads wrong. You should read location 2 and 3 separately to get the high and low byte respectively. As it is now, you issue a series of four transactions where the read buffer gets overwritten by the the second read transaction. Your read buffer is 2 bytes but I think it only need be one byte since first you should read the high byte and then you read the low byte (the order does not seem to matter).

 

Also, I believe the location counter (address counter) auto-increments for each read performed so you could probably do something like this instead (here, the read buffer is still 2 bytes long):

xActions = new I2CDevice.I2CTransaction[]{	I2CDevice.CreateWriteTransaction(new byte[] { 0x02 }),	I2CDevice.CreateReadTransaction(RegisterValue),}int c = srf02.Execute(xActions, 1000);Debug.Assert(c > 0, "I2C write/read failed!");int val = (RegisterValue[0] << 8)|RegisterValue[1];

As you know, the Netduino is 5V tolerant and I wonder if the the LLC is really necessary - have you tried without it?

I agree, the byte order is equal to that of the Arduino code.

 

In my experience floating pins can sometimes result in strange phenomena and I try to avoid them even if it theoretically shouldn't matter. I normally use 100k pull-downs on unused pins though.

 

You could try using stronger I2C pull-ups, say 4k7 as see if that helps.

You're not skipping LSB, you read both MSB and LSB as two consecutive bytes - because they are one byte each, only when combined can they form the 16 bit number that represent the reading. About the "c == 2", I changed that shortly afterwards since it was a mistake, sorry for the confusion it may have caused. Fortunately, you quoted the correct version. As for the LLC, you usually only need that when talking to something that either 1) uses less than 3V3 and is intolerant of that or something that 2) uses something in between of 3V3 and 5V which doesn't think 3V3 qualifies as a logic high or 3) something that uses more than 5V as it could harm the Netduino. A logic low is normally ground and thus no problems with that. In your case, the Netduino will have no problem with the I2C lines being pulled up to 5V.

You could try removing R1 and R2 on the shield, those are 2k2 I2C pull-up resistors to 5V. After removing them, add your own pull-ups to 3.3V externally. That should work as long as the RTC considers 3.3V as logic high, which I think it does but check the d/s first. Be careful desoldering R1 and R2 not lifting the pads in case you want to put them back in future. If you know you will never use R1 and R2, just take a sharp knife and cut the traces instead of desoldering.

So basically, you leave the analogue input pin floating "in the rain" - I suppose that is bound to produce strange results. I once created kind of a "human body proximity sensor" consisting of 8 floating digital inputs and they all triggered when I held my hand about two inches away. I guess, in a moist environment the effect would be even stronger. I suppose you could try using a really weak pull-down resistor of several Mega Ohms but perhaps it would be better to use an actual humidity sensor?