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

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.

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

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

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?

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

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

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,

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

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

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?

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

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.

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

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

Hello Guy.
Mark is absolutely right.
Driving a LCD in a parallel fashion is a waste of pins, and they are precious indeed!
That's not all: consider seriously the tip of using the 74HC595 shift-register. By using it, you will take advantage of the SPI interface, having a dramatic increase of speed.
Cheers

Thanks Mark and Mario - I'll start diving into the 74HC595 shift-register right away. Found t on SparkFun already. Any other component I need to get to use it, just off the top of your head?

Ok, making some progress. Following great forum advice, I now know how to use a dual-color LED, and I finally got my LCD screen working.

As a next step, I tried combining the 2 programs, completely forgetting the hardware side of things - both programs were using the same pin (D12)!
Of course, I found it the hard way, getting an exception thrown somewhere in the MicroLiquidCrystal code. I'm using a bread board, and thought I could just plug in the LED to a row connected to the pin, but the pin is already in use by the LCD.

Clearly, I'm missing a key piece in electronics, or hardware programming. The LCD, as wired now, uses almost all of the digital pins (2-12 - see post for list). I want to move forward and start wiring sensors, some LEDs, maybe a button or two. But if I can only have one leg connected to one pin - I'm out.

What do I need to do to be able to use the LCD as it is wired right now, but continue to add components? Do I have to use the analog pins? And what happens when they run out?

Thanks,
Guy

Hmm... I wonder then where the CPU is. Both those chips are for flash then. Must be under an RF shield.

I keep wondering if it's even worth pursuing. I tried prying that silver cover open - it looked like it was held by flimsy pieces of metal. Boy, was I wrong. It broke the flat screwdriver blade of my Leatherman

Oh well - live and learn.

The ASUS router is good. I am using a Fonera router. Both can run off 5V. I have an Energizer XP8000 battery pack powering the netduino and fonera. Everything is Velcroed together.

May I ask where did you get the Fonera? Been looking all over for them...

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

The chips. Specifically, the 2 black ones that lack pins coming out the sides.

Chris,
The writing is kinda washed out here, but I'll do my best. Both chips have the word 'SanDisk' and 'Nand' on them, suggesting they're NAND storage units.

The top one has the following: SDIN2C1-512M and a serial: S73825221 followed by CP0078846
The bottom one: SDIN2C2-1G and a serial: S80925691 followed by CP0112595

So, all in all 1.5GB of NAND. I believe the real "logic" is buried in that silver unit on the SD reader side.
I wonder if it's worth all the de-soldering work, and where would I be able to find re-wiring info for any of these.

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