Arron Chapman

Alex,

 

This is a common situation with analog devices and there may be several factors involved.

 

For example, if there is any ripple in your light source this will be reflected in the output of your sensor.  In the US it's quite common to find 60hz (50hz in most of EU/AU) noise in just about everything because this is the frequency the AC in our houses runs at.  In many cases, one will find a 60hz oscillation in optical sensors because the lights will flicker at this frequency.  Additionally, it's possible that there are fluctuations in the power supply of your Netduino, which can be induced by the same AC signal.

 

I'm going to assume your circuit looks a bit like this;

 

There are 2 realistic ways of solving this problem; First is the electrical solution!  You can add some capacitance to the output line to help filter out the noise. What type and size of capacitor won't matter a huge amount for this purpose, I'd pick something in the 100pf range, though you might just experiment a bit to see what gets you the best results. Wiring it up is rather easy, you'll just put it in between your sensor's output and GND.

 

The second option is the less fun option but you can fix this in software as well!  The easiest way to do this would be to just keep a local average of the input, using that instead of the raw value.

for (int i = 0; i < 100; i++)
{
	localTotal += sensorInput.ReadRaw();
	Thread.Sleep(10);
}
localAvg = localTotal / 100;

This will give you an average over the last ~1 second.

 

 

Both of the solutions have 1 major consequence which is that they reduce the responsiveness of your sensor, as each solution increases the amount of time required to output the new value.  The exact extent of this delay depends on how you choose your capacitor, or how tightly you run the averaging loop.

Hey! It's good to see this, updating the devices was arguably the most frustrating part of the process for users

 don't have any soldering experience (or gear) and I would like to avoid that part if I can.

I highly recommend you change this, more info on why below, but I think Go isn't the right answer for you. Not right now.

 

so here are the parts I was thinking of getting:

 

- netduino go

- nwazet touch display (any larger available for less than 100$?)

- 2 joysticks

- go shield base if needed

 

- sd card module (for storing/loading games etc)

- mini speaker (because every game needs sound )

So far not too bad.  There are no existing joystick modules for Netduino Go, while someone could make some it isn't a trivial task for a self described Noob, it will also require some soldering.  The SD Card Module also isn't currently available and doesn't have a firm ETA.  For your speaker, if you want to go retro the piezo module (from Secret Labs) will produce beautiful 8-bit sound for you.

 

 won't ask about the gadgeteer boards, but to me It seems I could use that as well.

 

Gadgeteer Boards with port type S, U or X should work fine, however note that each one of those modules will take up 4 ports on your Go Mainboard.

 

Overall I think that for tinkering with parts when there aren't existing Go Modules for them puts Go is a bad position overall.  You can get done what you want with the Shield Base, but it's less than an ideal solution, IMO.  I'd prefer you to start with the Netduino Plus 2 and a soldering iron.  You don't need an expensive one, I use a ~$5 iron from Radio Shack and manage to solder Surface Mount parts without much trouble.  With the hardware (and of course the software to) itself if you stop by chat we can often help.

I absolutely agree with Troll, at least Secret Labs could finish Gadgeteer extention to be able to use GHI modules, and of course should be found solution with SB working much slow then Netduino or Arduino, I think those 2 things are the most critical from my point of view

The speed issues will never change, think about what happens.  Process data on mainboard, transmit to shield base (currently via UART later via SPI), process data, set pin states.  If you really need speed choose another device like the N+2.

 

I'm also getting a little tired of the "to be released soon" messages.  In fact I have now got to the point where I ignore any new pending product announcements as hype.  I agree with Troll, announcing something which does not appear annoys people.  I can see the point in letting a community know what is heading our way but I'd like to see firm delivery dates not FITA dates.

 

I'm a great fan of these products but the only posts I have any confidence in are those which are restricted to technical discussions.

 

Regards,

Mark

I think you missed the mark on this one a little, Troll was referring to NXTwoThou,

Lots of Netduino activity going on here this week at Secret Labs. While the Ethernet module winds through its final steps before shipping, other GoBus boards have made it through the design process and onto validation. I really like how the Ambient Light sensor module turned out. Photo attached. More to come... Chris

 

Nice!

 

Awesome! When can we expect to see this module in various resellers hands? 

 

And about the nice photo...

 

What kind of cable is that attached to the GoPort?! 

 

Cheers,

Steve

Why Steve, that the new super secret part from SL!  [REDACTED]

I have them, but i seem to remember that someone gave them to me in chat, the file is called FirmwareSource.zip
I have no clue if they are official released and that's why i'm not posting them here now.
- Ulrik Lunddahl
 

That would have been me
 
 

regarding stm8 firmware, was the source for the go-modules, rgbled and so on, ever released?

 
I just got permission to post the firmware.  I'm not going to post it on the wiki just yet because it includes the firmware for several modules in a single IAR Workspace so it doesn't quite fit on any one page well.
 
The attached FirmwareSource.zip contains the source for the RGB LED, Potentiometer and Piezo modules.
The attached FirmwareBinaries.zip contains pre-built binaries for the same modules.

 

These are the firmware versions that are currently shipping with these modules, to the best of my knowledge.

There is a bug in each of them, to do with the way the module GUID is sent, I don't recall the fix off hand but I'll ping a couple people who know it and I'll get updated ZIPs posted.  Look for an edit to this post when I do.

 

These are Go!Bus 1.0 Firmware versions.  The current version of Go!Bus is 1.5, however it is backwards compatible.  Go!Bus 2.0 is currently in the works and will still be backwards compatible with Go!Bus 1.0.

However, I personally recommend building for Go!Bus 1.5, for which you can get the spec doc to work from.

I'll think about it and see if I get any ideas.  I too worked in RFID for a while doing cargo container tracking applications.  I've done some RFID for alarm systems for security doors and personnel tracking.  Probably lots you can do outside of those realms but nothing comes to mind.

Does anyone here have any desire or interest in any rfid applications with the Netduino Go? Ive worked on some ideas on and off, but never was able to focus on anything long enough to produce much of anything. I keep changing my project ideas.

 

Personaly, I'd love to see a Netduino Go module for RFID, but I'm not in a position to start on another module right now.  However you can be sure I'll remember you if/when I do start on such a module

Setting the time / date on the Go is the same as all Netduinos as this is a function of the .NET Framework.

 

Just to expand on this, almost all of the code you will write for the .Net Micro Framework (.NetMF) will be 100% portable across all boards.  That is, in part, the purpose of the framework.  The only exceptions to this are SecretLabs.NETMF.PWM and SecretLabs.NETMF.AnalogInput which do not work on the new generation of boards (Netduino Go! and Netduino Plus 2).

Can't promise to match Dave's $50 but I'll happily chip in with what I can.

 

Cheers,

Mark

 

I'll second this.  I also wanted to ask when you guys are needing to leave?

I am getting the exact same erorrs using the exaxt same code as noom.  Sandisk 8GB card, formatted to fat32.  The card works fine in other devices.

 

Anything else needed to help with this?

 

Most cards above 4GB are unlikely to work.  As far as I know, 4GB cards are hit and miss, and most anything 2GB or smaller should work fine.

Ah ok. Do you mean netduino (plus) 2 use the Arduino form factor and Arduino components are compatible with it? I'm very new to this so sorry if this sounds obvious.

Indeed, the Netduino, Netduino Plus and the Netduino Plus Two all use the Arduino form factor with the Netduino Plus Two using the latest Rev C layout.  Most shields and arbitrary hardware will work with the Netduinos.

This works extremely well. Thanks for the contribution Arron. I just upgraded my Pandora's Box device to use the Netduino Plus 2 and the first thing I noticed was the LCD's RGB Backlight was flickering and when I put it into scanning mode (basically activating all the sensors) the flickering got worse. Having the ability to turn the Ethernet Port and SD Card on when needed and off while scanning made a huge difference.

More importantly I think we need to thank SecretLabs for adding those mosfets Not having more control over what was going on, on the board was one of my biggest complaints about the Gen 1 devices. That and not having enough I/Os.

Thanks for your quick response, Chris.
I understand the hardware is different from the Netduno plus, so the dll also is.
I am wondering what more differences are there between the two.
For example I just replace the dll's for the right ones for Netduino plus 2.
Now I get stuck on the follwoing command:
AnalogInput A0 = new AnalogInput(Pins.GPIO_PIN_A0); i get an error message saying:

Error 1 The best overloaded method match for Microsoft.SPOT.Hardware.AnalogInput.AnalogInput(Microsoft.SPOT.Hardware.Cpu.AnalogChannel)' has some invalid arguments
Error 2 Argument 1: cannot convert from 'Microsoft.SPOT.Hardware.Cpu.Pin' to Microsoft.SPOT.Hardware.Cpu.AnalogChannel'

So i am looking for a manual especially of the netduino plus 2 so i can find out what i have to change in the software.
To make thingsclear: i am trying to get it working as a webserver for Thingspeak

That is the new (prefered) AnalogInput class, you can find more information on it's MSDN page. The correct way to instantiate the object for a pin on A0 is like so

AnalogInput a0 = new AnalogInput(AnalogChannels.ANALOG_PIN_A0);

Hi!

First of all sorry if the terms in the post won't be technically correct, english is not my main language, but I'll try my best.

Welcome to the community! Like most people who are self conscious about it your English was better than most native speakers.

I'm working on a project and came to a point where I need to read data from the device, and I'd like to have that data in the array so I can work with that data programmatically in Netduino to continue the project.

The device I have sends data over 3 pins: CLOCK, DATA and LOAD (it is meant to be read by OKI Semiconductor MSM6775 if it's any help). The data format is something like SPI but with one difference - the DATA is in 8 bit words but LOAD signal is every 11 words. Complete data frame consist of 4 packets of these 11 words (ends with 4th LOAD signal and then it's aprox 31,4ms gap between new data frame). So I'm looking for a way to have that data frame in an array of 352 elements (4*11*8).

And this is where I'm stuck. Is it possible to do this with Netduino? How can I trick it into reading this as SPI when Netduino works as SPI master? Is there a way to send "false" load signal every 8 bits?

I don't think you even need to do any tricks. I looked through the datasheet you linked to and I think that if you use the following SPI configuration, along with mannualy managing the LOAD pin you'll be set.

SPI.Configuration Device1 = new SPI.Configuration(
    Pins.GPIO_NONE, // SS-pin
    false,             // SS-pin active state
    0,                 // The setup time for the SS port
     0,                 // The hold time for the SS port
    true,              // The idle state of the clock
    true,             // The sampling clock edge (HIGH)
    1000,              // The SPI clock rate in KHz
     SPI_Devices.SPI1   // The used SPI bus (refers to a MOSI MISO and SCLK pinset)
);

Then you can transfer your data as you need to with spi.Write(data) after you Write every 11 words, then manually pulse the LOAD pin;

OutputPort LOAD = new OutputPort(Pins.GPIO_PIN_x, false);
...
LOAD.Write(true);
Thread.Sleep(1);
LOAD.Write(false);

If I've understood that datasheet that should work for you.

is it possible to get an eta on when the issue will be resolved? can we return our boards for ones that work?

From my experience in software and as of late software that runs close to the hardware it's impossible to say with any certainty how long it will take until your done. Chris will often cite the time he expects it to be done, but as it goes with these sorts of things it turns out to be more complicated. Sometimes a simple fix regresses the entire rest of the system and ends up taking orders of magnitude longer to fix than planned, and during these times it's best to stay heads down and get it fixed than to spend time jabbering about it.

That is a good question. I purchased several ND+2 thinking they would be somewhat ready to rock. Now I regret it... should have ordered ND+ so I could keep working on my new projects. Don't these things get tested at least a little?

You can still order Netduino Plus' at Amazon. The devices get tested quite a bit, by more than just Secret Labs, but there is no chance that every possible use case can be accounted for, something you yourself say in the next quote.

I have owned several business over my career all of which are client facing. There have been times we've release both Hardware and Software products that have had bugs. It happens as you cannot test every single scenario.


...

I am very critical with vendors when they fall on their faces. I don't typically give a vendor the "3 strikes and you are out" opportunity. There are plenty of options when it comes to getting your projects to market. I have talked to my business partners and just based on the complete lack of communication from Secret Labs, we are cautious of continuing to design any products using these boards. They pointed out that lack of communication like this happens when a company is about to bang up and close it's doors. I certainly hope for everyone's sake this is not the case.

As someone who also has run a variety of public facing businesses, I can understand some of the frustration but what I don't understand is why you'd even begin to consider a newly released product as part of yours? That's is certainly not something I'd ever consider doing for my companies, it's not going to be stable enough. Companies MUST depend on stable products to be stressful in the long run, early adoption in business is almost always a bad idea.

I just contacted Amazon.com where I purchased them and they issued me a pre-paid return shipping label and return authorization and will refund me when they receive the product. I thought maybe I spoke loud enough for Chris Walker to take a moment to chime in, but I guess not. So these boards are going back.

Ordering me two G120HDR Modules from GHI Electronics. I think I'll have better luck with them.

If you think that Secret Labs isn't fixing things fast enough, good luck with GHI.

So again, not ticked about the timelines... it will take what it takes. The lack of communication is the issue. It took me 2.5 minutes to write this message. I am sure anyone can afford 2.5 minutes to post a status message... that is the point.

It took you 2.5 minutes to write one non-technical/business post in response to one thread in one sub forum. Chris' responsibilities extend well beyond that.

Anyone who has made it far enough to use a Netduino should have learned long ago that early adopters always have it hard. If you want a feature complete, 100% stable product, wait until next year or be prepared to deal with the problems and delays that inevitably come up.