Sounds like you got it from a secret place ;-)

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?

I just had another look at your code and I see that you check Available before doing anything at all. Maybe you have changed that now, but I think Available can be zero which just means that no data has been read in advance for you and that you must read it all by yourself - there's still an incoming request to be serviced. If not already done, put a Debug.Print statement immediately after the Accept statement and see what happens.

I see. What are you using this for yourself?

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 you mean the pull-down I suggested for the open analogue pin was the one thing that helped?

Ha, ha - that is just hilariously awseome!

 

As a child, I actually dreamt of creating a fart detector in order to answer the inevitable question "who was that?" and now, some 30 years later its finally here - your are a true genius!

 

EDIT: It's mostly methane is it not?

Oh really, come on!

I really can't believe I'm the only one fascinated by this, come on folks - admit that it's really cool or at least very funny!

...Is it really the first one?

As a web server I think not but as Networked Attached Storage, I suppose it is. In a data acquisition application you don't have to take the card out to examine the log which ought to be an appreciated feature.

 

It is fully self made (the C# standard libs, like Windows.Forms and System.Net.WebClient are used, but I think it's not what you meaned?

in DuinoFinder I used the same code, but the GUI (there I took Gtk instead of Windows.Forms, what is also for Unix available))

I was thinking more in terms of whether you can access the files as kind of a network share like SAMBA (or something like that) using the standard Windows Explorer. I get that impression from looking at your pictures.

 

Sorry, I don't know, I haven't made any investigations in that direction yet. My devices have only a single slot for SD card. Is there an extra hardware necessary?

I didn't mean that seriously but yes, you would need an external SD card slot and drive that over SPI.

.... though I don't know how netmf will feel about it, or even if the spi the sd is on will be reachable....

 

Oops, didn't think of that, might be a problem.

 

With the mini I always use a simple SD card holder breakout on the regular SPI port.

Managing FAT32 adds a lot of overhead. You could try using the SD card in raw mode without a file system. 

 

Of course, you can't use the regular NETMF functions for this, instead you have to treat the SD card like the SPI slave device that it is. You'd also have to use a special PC app to extract the data from the SD.

 

I know Nwazet has a data acquisition module called DAQ and I think they use their own FAT32 implementation for that. Perhaps you could look into the underlaying implementation of that and find some code for doing raw SD card writing:

http://nwazet.com/co...Q/10-FileSystem

 

If not, there ought to be some Arduino code for this that you could port.

Sounds like a good decision given the benefits you see in a relay server and the time invested in fruitless attempts to getting it working without one. Still, its remarkable that it does not work, I have such a hard time believing that requests via a router is treated any different that ones coming from a local network. Have you actually checked to make sure it has nothing todo with bytesAvaible? That is one thing that could be handeled differently. I agree, it would be very interesting to hear if others are experiening this issue.

Ah, the world's first Netduino NAS - very nice work!

 

About the Duinoexplorer - is that a fully custom made application or does it somehow integrate with windows?

 

What transfer speed can you reach when downloading a reasonably large file?

 

Does it support uploads too?

 

If you put a second SD card in there, you could have software RAID too 

I don't recall what the standard blocksize is but if it normally is less than what you typically write, then the speed increase would make sense as you basically would only have to make one hop through the linked list or whatever FAT32 uses to keep track of the multiple parts that files consist of. If I'm not mistaken, FAT uses an initial table of contents with file names etc and a pointer to the first block of each file which in turn points to the next and so forth like a linked list. Jumping around the blocks would obviously take longer than just writing to or reading from a single byte stream. I argued that the FS itself introduces a significant overhead that raw writes wouldn't. I've seen an Arduino play a music video on a Nokia 5110 LCD and that was only made possible using raw reads from the SD and a streamlined home brew file format where bits of video and music was interleaved.

I'd expect time to be zero when the board starts up since there's no RTC on board, or is there? After startup, clock should start ticking of course. Would that explain the phenomena you're seeing? EDIT: What is the initial value of the ButtonLastPushed variable? I guess it should be DateTime.MinValue.

It is this code snippet (taken from your code above) that I'm referring to:

Dim bytesReceived As Integer = clientSocket.AvailableIf bytesReceived > 0 Then...

Now, I'm not sure about how this works in the .NETMF (and Netduino) world, but in a Windows environment, clientSocket.Available would only contain the part of the data that is immediately available.

 

That is, clientSocket.Available does not necessarily contain the full request data (headers and such) but only some initial part of the data that has been pre-read for you by the framework at the point in time at which your listener receives the incoming request. The rest of the data you must read yourself by calling the corresponding read method on the socket. You can see clientSocket.Available as being a read-ahead buffer.

 

This means, that just because clientSocket.Available is zero, that does not mean that there's no request. I believe that clientSocket.Available would typically be more likely of be non-zero for requests coming from a LAN than from a WAN since the LAN would be faster. This could explain the issues your having with this.

 

I have a really hard time believing a h/w flaw is causing the problems you're experiencing.

I really doubt it's the keypad, I think you should try setting a few breakpoints in select places of the Toolbox.NETMF.Hardware.MatrixKeyPad driver code and find out where that zero originates from. There could be a bug in there or perhaps something resulting from incorrect wiring.

Ok, that is truly strange. What if you just assign a variable DateTime.Now, does that produce anything other than zero? If not, could be hardware problems but one should think more stuff would also not work then so I assume you get a decent value and that would leave a firmware upgrade or you've teied that already perhaps? I don't know the differences, if any, between the N2 and NP2 with respect to such an issue, I'd suspect there's none.

Aha, I thought we were talking about remote controlling from within the LAN only.

I wouldn't have my gear connected to the internet accessible from the outside world.

In some home automation product broshures, manufacturers push for things like being able to control the lighting in your home from away on vacation in another country or perhaps starting your sauna from the car on the way home. Dangerous madness.

Exactly, I see no hazards in what you're doing and naturally telemetry is harmless.

In my home, I got a networked IR gateway (iTach) for controlling all my A/V gear and built an RF bridge for controlling wall oulets like the ones you're using. I'm using my iPhone/iPad as a WLAN remote control but it only works within the domestic LAN.

http://www.avsforum....for-itach-irule

Halogen light contains lots of IR so, like Paul said, watch out if the room is heavily lit and with what. I made something similar with a electrical model car race track where I could use photointerrupters since those cars have small "fins" sticking down a slot in the middle of each track. I suppose you need to time each car separately and not just the winner which makes it more difficult. Another idea might be to use micro switches buried in each track at the finish line. The switches would have to be fitted with with fairly long arms to make them easy enough for cars to lever as the they rush by barely touching the switches. This might be the easiest way to do it.

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?

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.

I've never used the Go! but it sounds as if the port is broken. This can happen if you draw to much current in trying to drive too big a load. It has happened to me a couple of times and so I simply avoid using the corresponding ports anymore. Does the port work when used as an input?