Hey Guy,

If you move your 2 analog inputs to analog pins 4 and 5 (instead of 0 and 1), does that change anything?

I know it sounds like an odd request.

Chris

Hi Chris,
I tried your suggestion (temp. sensor A4, light sensor A5) and got the opposite result: when I shine a light at the light sensor, the temperature reading now jumps up considerably. I get readings of 230C in my room (luckily, untrue ).

The temperature sensor then proceeds to go up and down in a loop. It won't reset back to the 22C temperature unless I remove the flashlight.

But the cross effect is still there. May ask what were you anticipating?

Thanks,
Guy

PS: Something else I just noticed. After transferring the temp. sensor from A1 to A4, it now jumps up and down over the span of 4C, even without me doing anything. It's like something else on the board "irritates" it.

Hi,
Still messing about with my Sensors project. Reminder: light sensor + temperature sensor + LCD - posting to Pachube.

Everything works well now, and updates the Pachube feed correctly. My next step would have been to use Szymon's shift register idea, to go down from using 10 pins for the LCD to 3 pins.

Only while taking a Youtube video of my creation, I noticed (and documented) an undesired behavior: if I shine a bright light at the light sensor, the temperature drops considerably (from 20C to 14C) and jumps back up when I move the light away.

Logically this has to do with resistance (as the resistance in the light sensor grows, it lessens in the temp. sensor), and with some co-dependency in the way I wired the circuit. But I'm not experienced enough to find the root cause.

So here's a Fritzing diagram of my board (again, pardon the wire mess and 2 boards - it'll hopefully go away soon). The two sensors are on the lower left, and are connected as follows:
- TMP36 temperature sensor: right leg -> GND; middle leg -> analog1; left leg - Netduino 3.3V
- CdS light sensor - right leg -> Netduino 5.5V; left leg -> analog0 + 1kΩ resistor to ground



I figured since one sensor goes to 3.3v and the other to 5.5v they are separated. But maybe I've mixed the GNDs?

The code, as well as the full Fritzing file, can be found on github. The video can be found on Youtube (the effect can be seen at 1:48 into the 3 minute video).

As always, any help appreciated. And as always, I'll learn
Thanks!
Guy

PS: Fritzing question: I have this 330Ω resistor connected to the LCD at the lower part of the screen. Fritzing shows it as a 4-ring orange-red-brown-gold, while in reality it's a blue 5-ring orange-orange-black-black-brown. I guess they amount to (almost) the same thing, but how can I tell Fritzing to draw the right one?

Hi Guy,

Just to rule anything else out--were you operating without a network cable plugged into your Netduino during this test?

I'm just trying to sort out all the potentials here We've found a few analog sensors which don't work well...whether it's because they can't drive enough current or otherwise...that's what we're trying to sort out. Analog inputs should be pretty simple things.

Chris

Hi Chris,
I tested twice - with, and without the network. The ranges of variance with the network cable are greater than without, but I can confirm bad behavior even when the network cable is not in use.

I then tried 2 modes of cable disconnect: one where the cable itself is still connected to a router, but the router is disconnected from electricity; and one where the cable is completely out. In the second case, it looks like the variance is smaller - almost to the point of no trouble at all, but once in a while the application gets frozen - the last 2 values remain on the screen and won't change again until a forceful reboot. I hope I have not damaged my Netduino with all these games.

To sum it up:
* if I do not have the network cable in, I get accurate results;
* if I have it in but with the router off, I get discrepancies and the program gets stuck after
several such jumps;
*if I have the cable in and the router on, I get crazy discrepancies (that get posted to Pachube sadly - my sensor graph was 14-24 C - it's now -30 - 306 )

How's the Ethernet port affecting the analog pins? Anything else I can try?

Thanks,
Guy

About the Fritzing resistor colors.
The Fritzing drawn resistor is a 330 Ohm, granting an error within -/+ 5%. Orange is 3, black is zero and the 5% tolerance is gold.
The resistor you used is much better: -/+ 1% (last ring brown). Since its precision, it has a ring more, so: orange-orange-black-black ==> 330.0

About the strange value.
I noticed a strange jitter on the ADC readings on my Netduino PLUS, when the ethernet cable is plugged-in. As soon you unplug, the readings are stable. No workarounds, maybe an average.
Could be that?
Cheers

Mario,
My problems started before I added the Ethernet/network component (as you could see in the video) to the equation, and it keeps on happening now.

As for the resistor coloring in Fritzing - I realize both representations end up as 330 Ohm. I was just wondering if I could have Fritzing draw my actual resistor (i.e. 5 rings), rather than a similar one, or do I need to manually add a part?

Thanks,
Guy

Hi Guy,

When the Netduino Plus is talking to a network, there are a lot of interrupts firing the background. These may or may not affect the analog input values. We're doing some tests here to determine if we can disable interrupts completely during analog readings...to see if that clears things up.

It's also possible that the ARM microcontroller on the Netduino has reduced analog accuracy when the embedded network MAC is in use, but it's more likely to be a software issue (resulting in different setup times, readings, etc.)

Many microcontroller apps take multiple readings--and then average them. This may be a scenario with that sort of approach would be appropriate as well.

Chris

Hi Chris,
Thanks for clearing it up. Coming from software problem resolution background, I've seen plenty of problems that are caused by "environmental factors" - i.e. factors surrounding the actual issue, that you'd never even consider to be the root cause. The Netduino+ contains so many layers and functions (network, analog, digital, sd card...) that some background noise is sure to seep in once in a while. I'm glad to see you guys are on top of this. Hopefully it IS a software issue, and can therefore be solved in a future release (any news on 4.2 BTW?)

As for averaging readouts - yes, I thought of that, but how do you average -30 and +300? The behavior is such that the temperature jumps up (or down) and takes several seconds to normalize. If during that time a bright light shines on the senor, it jumps even higher. I'll have to have a longer period of time in my averaging equation - and that would mean losing some resolution (no biggie - it's a fun project, not a crucial application).

One other thing I thought of is registering when the light conditions change drastically, and ignore the temp sensor for several seconds afterwards - using the last sane reading. That would get rid of the peaks as well.

Guy

Try this average:

const float N = 4;
float actual;

actual = (adc.Read() + (N-1) * actual) / N;

The higher is N the smooth will be the filtering.
The step-response is somewhat exponential.
Cheers

Mario,
I think the result of your equation is non-deterministic: you are using actual before initializing it.
But I see what you're trying to achieve. Still, as I told Chris, the sudden peaks are so far above the norm reading, that even with averaging I'll get crazy results.

I proposed you an algorithm that we used tons of times, and it is working very well.
Of course you must init the vars' values.
The very first "actual" value should match the ADC read.

If you own an Excel-like tool, try that function on the cells.
Cheers

Thanks Mario,
I wasn't suggesting the algorithm doesn't work. Just that it seemed like the variable was uninitialized in the sample you attached.
I'll give your suggestion a try.
Regards,
Guy

Hi Guy,

The assemblies you're adding aren't that big--but there may be some really large ones being pulled in as dependencies. That said, if they're not in your BIN folder...they probably aren't getting pulled in.

The .pdb file is not loaded onto your Netduino Plus.

The exception you're getting is an odd one. It could be size related, but it could be something else entirely. Is there any chance you can (a) zip up a copy of your project and post it online and/or ( try to stub out the MicroLiquidCrystal features and assemblies to see if that fixes the issue?

Chris

P.S. Just to confirm...do you get any size info in the Output window before this error occurs? Such as...

Chris,
Just posted my code to a Github repository - with the images I posted in some of my other questions, I got very close to the forum limit.
If Github is not accessible enough, let me know, and I'll zip and Dropbox the code.
Pay attention to the fact that you need to provide an API key and feed number in the Pachube.cs file to get a real result - although it's not relevant, since I'm just trying to deploy, not yet debug, the application.

To answer you second question - I never get the size line - I only get the error I posted, which got me to re-think the size issue.
I never get to deployment and I don't get a good reason. Any help is appreciated.

Thanks,
Guy

Guy,

Just another idea. I’ve been using the MicroLiquidCrystal library for a project I’m working on. It has a provider model, which is great. A single API to talk with multiple LCD devices over different types of communication protocols. But what that means, is you are probably linking in providers for LCD screen types you aren’t using. For example, I am using the I2CBus to talk to a MCP23008 (using the Adafruit LCD Backpack). So I excluded from the MicroLiquidCrystal project both the GIPO and Shifter74Hc595 providers. This saved me about 3k. Not much, but if you go through this process with all of the libraryis you are including, it might save you enough without having to re-write your app.

Also, you could build the release version of the libraries you are using. Because NetMF is interpreted, and I’m 99% sure there are no optimizations in the compile, I don’t think you get any performance improvements. But I have seen small decrease in size. Chris or others may know of a reason to not use the release version, but I haven't had any issues, including still having the ability to debug and use Debug.Print().

One thing I haven’t tried yet is to put everything into a single project. I wonder what overhead you get with each new dll.

Chad

Chad,
Just tried building the project in release - it gets stuck deploying. I never see the size or any error issue. It builds, and then forever hangs on

------ Deploy started: Project: Sensors, Configuration: Release Any CPU ------

Maybe something is wrong with the combination of libraries, code, network...
My code itself is quite simple (Github repository link).
At this point, I'm not sure if it's a software, hardware or PICNIC issue

Thanks,
Guy

Hi Guy,

thanks for buying my book!

The Gsiot.PachubeClient library is very simple and small, but it references System.Http. This is a large DLL, about 46 KB if I remember correctly. So together with the LCD library and the application, it may indeed be more than the available 64 KB.

You may want to take a look at example 9-1 (HelloPachubeSockets), which directly uses the Sockets API instead of the higher-level System.Http library. The price is that it doesn't interpret responses from Pachube, which may or may not be ok in your case.

Another possibility would be to create a reduced version of System.Http, a System.HttpClient assembly. It would have stripped away all server-related code, i.e., the classes HttpListener, HttpListenerContext, HttpListenerRequest, HttpListenerResponse, and auxiliary classes that are not used for the client-side classes. I did this once for the server-side, i.e., removed all client-side classes. I guess that (roughly) about 15 KB could be shaved off from the original 46 KB. Note that your program's source code would need no changes, not even to the source code of Gsiot.PachubeClient. The only change would be in Gsiot.PachubeClient in order to reference the System.HttpClient assembly, instead of System.Http. Unfortunately, stripping down System.Http is a bit of an iterative process until all unnecessary code is found and eliminated.

Cuno

PS
I just uploaded all the examples, and beta release 0.9 of Gsiot.PachubeClient and Gsiot.Server to www.gsiot.info.

Hi Cuno,
First, apology- I didn't buy your book (yet) - just read the online chapter.
How would I go about trimming the System.Http library? Is the code available? Can I just use the System.HttpClient somehow?

I realize I can (should?) always go down to sockets, but I'd like to avoid that for as long as possible

Thanks for the code and the support!!!

Guy

UPDATE:

I managed to minimize the code and remove some stuff - got it down to 58K. Finally managed to deploy the code with System.Http.
However, after 2 loops, I got a memory exception in the code writing to the SD card. Clearly, 58K is pushing it.

So, I took Cuno's advice and switched to his sockets code - it dropped the total size to 14K!
The program can now successfully post both sensors' data to Pachube (feed link).
I'll trim it a bit further and update my Github, if anyone's interested.

One big negative side effect I've noticed: if you experience an error in deploying a version to the Netduino, or if your code suffers an exception,
you have to disconnect/reconnect the USB cable, or else you'll get strange behavior and hangs in VStudio.

Thanks all!
Guy

BTW, just to make sure that I'm suffering from a size related error, here's what I see in the Output window when I click F5:

An error has occurred: please check your hardware.
Object reference not set to an instance of an object.
Source: Microsoft.SPOT.Debugger.CorDebug
Stack : 
   at Microsoft.SPOT.Debugger.VsProjectFlavorCfg.Deploy() in c:\depot\current\CLIENT_V4_1\Framework\CorDebug\VsProjectFlavorCfg.cs:line 893
   at Microsoft.SPOT.Debugger.VsProjectFlavorCfg.<Microsoft.VisualStudio.Shell.Interop.IVsDeployableProjectCfg.StartDeploy>b__0() in c:\depot\current\CLIENT_V4_1\Framework\CorDebug\VsProjectFlavorCfg.cs:line 634

Could it be something else? Just building succeeds.

What version of the GSIOT assemblies are you using? The latest ones from the book site?
http://www.gsiot.info/download/

I noticed that a new, smaller version of the server side is due to be posted next week. Which GSIOT components in particular are you using?

I'm using the latest version from that site. I'm using the client library, as all I need is to post a value to a feed.

I'm sorry, but I don't understand the question. Can you please rephrase it for me? [The source code is compiled into object code...which is then deployed to the device. There is no limitation to the source code size specifically.]

Chris

What I meant was: what specifically gets deployed to the Netduino?
For example, if I just build the application, the bin/debug directory contains:

• Sensors.exe - 8k in size
• MicroLiquidCrystal.dll - 19K
• Gsiot.PachubeClient.dll - 5k
• Various PDB files - totaling well over 100k

So if just the EXE and DLLs get deployed, I don't see how go over the 64k limit. If there's a further list of DLLs and objects deployed in addition to the EXE and the DLLs I specified, how can I know what are they and how to calculate the total size of what will be deployed?

Thanks,
Guy

Hi all,
I have a simple application that uses a light sensor, a temp sensor and MicroLiquidCrystal library to display the results and save them to an SD card. Everything works great.

I was hoping I could send the 2 sensor results to a Pachube feed. I downloaded the Gsiot PachubeClient and added it to my project. It compiles well. But when I try deploying, I get a generic error

An error has occurred: please check your hardware

and an error in

Microsoft.SPOT.Debugger.VsProjectFlavorCfg.Deploy()

.
No amount of restarting, re-connecting the USB, or even erasing the board helps.

After looking around, I found this thread, suggesting it might be a program-size problem. And indeed, if I remove any reference to the Gsiot DLL, the application can be deployed.

My questions are (in order of light to hard):

• How much space do I have to deploy to? (Netduino Plus (v4.1.1.0 b1))
• How/where in Visual Studio 2010 can I find out the total size my application compiles to?
• While I did include the DLL for Gsiot, I just added the MicroLiquidCrystal project to my solution. Will compiling it and just adding the release version of the DLL mean a smaller sized application?
• What other code-minimization techniques can I use?
• Is what I'm trying to achieve (sensors + LCD + SD card + network) even possible?

This size limit takes me back 20 years to my Assembler days (and even then, I wasn't that great at it ). Any help is appreciated!

Thanks,
Guy

PS: for internet connection, I'm using the Asus WL-330gE as an adapter - so no additional components and or code are involved.

Hi Guy,

You have 64KB of flash available for deployment. When you run/deploy your program, Visual Studio should show the total size of your app in the build window (while it's copying it to the Netduino). It should appear for a few seconds.

The System.Http.dll is the really big file. If you're using it in your application, it will take over half of your space. In sophisticated web apps, users sometimes switch from using the HttpWebResponse objects and just use simpler Socket wrappers instead.

Chris

P.S. What you're trying to accomplish should be totally possible on the Netduino Plus.

Hi Chris,
Thanks for the prompt reply and the great work you guys are doing on Netduino in general.
On my other laptop, using C# Express, I could see the size. However, I can't seem to get it in VS 2010 (Ultimate) output window.

I didn't check, but I assume the dll you've mentioned is used by the library I tried using. Any way around it? What are some other solutions you'd recommend?

Thanks,
Guy

In the GSIOT book, there's a chapter on using socket programming (vs. using the http object). Perhaps we need to pull the author into the conversation to help identify a good way to swap one for the other?

Chris

Chris,
Since I got to his book through your site, then by all means - if you have any way to get him to comment, I'd appreciate it

Guy

PS: btw, does the size of the executable itself matter, or is it non-relevant to the code deployed?

Google just (I/O day 1, 5/10/11) announced the "Android Open Accessory Development Kit" (ADK for short), that will allow

external USB hardware (an Android USB accessory) to interact with an Android-powered device in a special "accessory" mode.

They are providing a software and hardware (I swear the link to the Japanese company is taken directly from Google's page ) that will use an Arduino board + shield to communicate with Android 2.3.4 and higher devices.

The myriad of possibilities of using my N+ with my phone, if possible, is staggering. This could bring a new level of network, location and sensor integration.

I have not followed on all the board's hardware requirements (voltage, connections etc.). My questions are:

• Will I be able to use the Netduino+ I have to communicate with my Android devices?
• Will the NETMF environment be agnostic enough to allow integration with the ADK?
• Will I need to buy that special Arduino shield, and will that be compatible with the Netduino?

Hoping for good news

Guy

Hi Guy,

You can already use your Android, Windows Phone, iPhone, or Palm phone to control a Netduino Plus-based accessory via WiFi. Which is in many ways a much nicer solution than a USB cable.

That said, we're investigating ways to support USB Host. It's an interesting thing, as it's much more complicated than USB Client (since you need support code for each device type--plus hubs, enumeration ability, etc.). And of course you'd need a shield...but possible. Especially if the shield abstracts away much of the USB Host support already.

Chris

Thanks Chris,
I know that I can use Android (or any other web-capable platform) to control my Netduino over wifi.
I was more interested in utilizing the phone's 3G capability to cut my wifi dependence. The ability to control the phone itself (i.e. camera, GPS etc.) would also be a great feature.

I appreciate you guys keeping on top of this and researching the USB host requirement. It may all turn out to be just the need to add a specialized shield. Although now we'll have 2 code bases to maintain: C# and Java...

Both cicruits@home and SparkFun have USB Host shields. I looked at the circuits@home one and it's a SPI slave--so it's quite likely that the Arduino "USB Host" code could be ported over to NETMF.

This also means you could probably do something along these lines with Netduino Mini. In fact, there's a USB Host board targeted towards that form factor as well if I remember right.

Chris

Thanks Chris.
So if a USB host shield (like this one from SparkFun) solves the hardware aspect, "all" we have to do now is port the software side to NETMF? Or am I still missing something?

Guy

That's pretty much it. Although USB Host is of course one of the bigger projects to tackle. The one caveat is that you might end up going with some native code interop in speed sensitive areas (but I haven't looked far enough into the SPI interface requirements of the component).

Chris

I believe that's a bit above my current level. I believe I'll take a "wait and see" approach on this

Thanks for all the replies, and I'll go out and get a 10k pot + a bunch of resistors later today.
But I still do have a question: if this has something to do with the brightness (lack of resistance on Pin 3), shouldn't I be seeing 2 lines of blocks rather than one? Will adding resistance solve the problem, or just move me to the next one?

You did say 16x2 so why do you set it to 16x4 in the code ? And I did it using 1K potentiometer for the brightness and it works fine

Actually, my code does say (16, 2) - I just copy-pasted from Pete's blog. But thanks for the catch - corrected the original question.

Hi,
Just got this 16x2 HD44780 controller from Hacktronics. After reading for a while, and realizing that using just the specified the Arduino wiring is not enough, I landed on Pete Brown's blog post.

I followed his instructions (almost) to the letter:

• I soldered the head pins into place (been a while - man, I'm rusty)
• I checked the continuity of my 16 pins
• I connected all pins as specified in the post, using a mini breadboard, with the exception of Pin 3.
  I do not have a potentiometer, so I just connected that pin to GND
  
• I downloaded the library from Codeplex
• I added the sample code specified in the article
  

  public static void Main()
  {
      var lcdProvider = new GpioLcdTransferProvider(
          Pins.GPIO_PIN_D12,  // RS
          Pins.GPIO_NONE,     // RW
          Pins.GPIO_PIN_D11,  // enable
          Pins.GPIO_PIN_D9,   // d0
          Pins.GPIO_PIN_D8,   // d1
          Pins.GPIO_PIN_D7,   // d2
          Pins.GPIO_PIN_D6,   // d3
          Pins.GPIO_PIN_D5,   // d4
          Pins.GPIO_PIN_D4,   // d5
          Pins.GPIO_PIN_D3,   // d6
          Pins.GPIO_PIN_D2);  // d7
   
      // create the LCD interface
      var lcd = new Lcd(lcdProvider);
   
      // set up the number of columns and rows: 
      lcd.Begin(16, 2);
   
      // Print a message to the LCD.
      lcd.Write("hello, world!");
   
      while (true)
      {
          // set the cursor to column 0, line 1
          lcd.SetCursorPosition(0, 1);
   
          // print the number of seconds since reset:
          lcd.Write((Utility.GetMachineTime().Ticks / 10000).ToString());
   
          Thread.Sleep(100);
      }
  }
  

What I got is an LCD in the "on" state showing one line of blocks and nothing I try get it to show anything.

From this I deduce I must have been doing something right, to get the controller powered, but I must be missing something as well.

My only guesses are:

• I screwed something up while soldering (although then I'd expect this to not work at all)
• The potentiometer is a must for Pin 3 - skipping it might have done something
• The list of connections Pete specified is not correct for my board/controller (I have an N+)

Any ideas of what am I doing wrong/missing?

Thanks,
Guy

Update 5/13: Just received my 10K potentiometer, and wired it as follows:
LCD Pin 3 to Pot Leg 2
Pot Leg 1 to GND
Pot Leg 3 to 5V

Turning the Pot does change the LCD brightness, however, I'm still seeing just one row of blocks.
I stepped through the program in VS - nada.

What am I missing here? What's my next step?

Thanks,
Guy

SOLVED!
Well, what do you know? It was my $#itty soldering after all!

After racking my brain, re-wiring the LCD, checking each line of code and visiting tons of blogs (thank you all),
I finally went back to basics: I bought a real soldering station and got rid of the Fry
s $10 house burner. I also got a nice solder sucker.

I de-soldered all my connections, re-soldered them at 700F, re-wired one last time, and presto! It works. Attached image proof



Thank you all for your suggestions, and for getting me to get a potentiometer. Now to wire in some sensors

Guy