That particular sensor asks for a 4.5V or up supply though, so you'll have no luck feeding it from a regulator that gets its input from USB ... so either add filtering or use another sensor.

Well, if you don't connect MOSI (the line where you send the data), then it literally does not matter what you send Also, be sure to get the headers for the arduino if you want to use it as a shield, it seems the "shield" does not come with them (so you'd have to solder wires or connectors to them).

The image from the logic analyzer looks like you switched the clock and chip select pins.

The IEEE specification does not mention any epsilon, and as you've seen most people actually have less knowledge about floating points than they'd need - also there are severe misconceptions like

A double is a double... They all have the same precision

flying around ... leading to bugs like this

You can use basically all of those for a first adventure into the world of electroncis. The last kit lacks resistors as "basic components", as it also says in the description, so you'll need some of those. However, don't focus too much on those kits - they give you something to play around, but usually if you have a specific project in mind you'll need to go shopping again for the parts. For the first steps, I'd also buy a breadboard (like http://www.cooking-h...breadboard.html) so you have something to put your components on.

The reset is automatically disabled when you use Pins.ONBOARD_SW1 as an InputPort or InterruptPort, nothing you have to do in addition to that - the netduino is nice like that

Hi,

Somebody has probably already asked this, but the keywords are so general ("analog", "pin", "power", "ground") that I haven't been able to find it.

The BlinkM documentation suggests that it can be plugged directly into a 'duino. If so, I guess it would be using A2 and A3 as GND and 3.3V. I think I read elsewhere that the Netduino analog pins come up at 3.3V when it is powered on... Is it safe to have 3.3V to the device's VCC and GND? Would it just mean that the device has no voltage potential to operate, but that it wouldn't smoke and that it would begin operating once the A pin connected to GND is set to 0V?

I'd like to make a little standoff that holds sensors off to the side, away from the minor heat island caused by the Netduino. I want to use a strip/vero board with 8 lines, 6 of which will be connected to A0 through A5. Then, with two jumper wires and three cuts, I can connect the two i2c sensors and one analog sensor, but I'd need to use A2 as a 3.3V supply and A1 as ground. If you've ever seen pirates make somebody "walk the plank", that's what I'm doing with the sensors. Ship = Netduino, plank = strip board, pirates = me.

I've thought about alternatives (e.g. sensors dangling from ribbon connectors) but I really have my heart set on having them walk the plank, if I can, and it all hinges on using A2 as 3.3V device supply and A1 as GND for devices. Any reason not to try this?

The device won't smoke, but the netduino will. See http://www.netduino....duino/specs.htm - you're only allowed to draw 2mA per analog pin, your LED will draw more. You'll need to use the "real" 3.3V and ground pins of the netduino.

Bummer! How many mAh do six 1.5volt batteries have?

Since you put them in series, you want to know how much one has, and you can find that out at http://en.wikipedia....wiki/AA_battery.

That depends on your LEDs and your wiring. A stock alkaline 9V battery provides 400mAh or something, so for a really simple circuit, with resistors and "standard" 20mA LEDs, a 9v battery will light 10 LEDs for 2 hours. For low-power 2mA LEDs you'd get 20 hours. By pulsing the current you could lengthen the span also ... if you're looking for battery life, use 6 AA batteries instead of one 9v batteries. They last far longer ... And also, yes, it makes sense that a portable usb battery is no good power source - they usually don't deliver a regulated voltage like a computer does, which is usually fine for charging e.g. mobile phones, but the netduino might not like what it gets.

I might be mistaken, but I think on rev a boards there is no internal connection between aref and 3.3v? And his wiring is without a connection to aref, so it should be rev b.

Hey Mark,

Got all the bits now I think... for the less able of us in regards wiring things up is there any chance you could perhaps fritz the tlc with the oscillator so it is possible to easily reproduce this?

PS hows the daisy chaining going on? And is it possible to reduce the number of netduino pins used (I refer to pins 8,9,10 in your code) for example can you provide high and low logic from a shift register such as stefans bit shift example?

Thanks

Andy

If you feel it's above you to easily reproduce the circuit, you could use another clock source. I think you should be able to use http://www.sparkfun.com/products/9116 for this, the two clock outputs should suffice to create the clock and the blanking signal.

Okay, something odd. To the left is my netduino+, to the right my regular netduino, same code, both 4.1.0.0 if I can trust the VS output ("Assembly: Secretlabs.NETMF.Hardware.Netduino (4.1.0.0) ...").
The regular netduino has the additional clock pulse before CS goes down ... I don't have a mini, so I can't check that.

Using a netduino pin as the 3.3V supply is hacky, but could work (output port, logic level high) - however make sure that you don't draw too much current from it (you don't if you just use it for this level converter). A "clean" solution would involve another regulator like http://www.sparkfun.com/products/526 (make sure you read the datasheet and add the caps if you do that).

Is the error "random"? Have you tried reducing the clock rate (on a phone right now so I can't look at the datasheet for timing info)?

Yeah, there are no breaks long enough, but i definitely see the clock pulse that you don't see - not at home to check the firmware version though (also, was a regular netduino). The clock select, if used, goes low about 10µs after the pulse on the clock line if I recall correctly ... However, I have to disagree with you on one thing: "But there's no reason that 2MHz shouldn't work." - since the pullup on the HV side of the logic level converter is fairly weak, high rise times can become an issue (nothing one can't fix, but during debugging i'd keep to low clockrates and then increase the rate when it's working)

As a rule of thumb, you always want to connect the grounds of circuits you connect, unless you use something like optocouplers or relays. You also want to connect ground first, supply voltage second, and then the data lines.

So, I found out that I can't trust the VS output, because I just updated and the pulse went away, but it still says 4.1.0.0 Found out the proper way to find the version out now but it's too late ... and iukpo uses 4.1.0.6 as well so he shouldn't have the pulse.

The 500 microsecond delay is supposed to happen after you sent the data, it's unrelated to the frequency (except that it means that you can't use a frequency <= 1khz because then it has 500 µs lows during data transfer). 0xFF means "all bits high", so my random guess is that means that you have some noise/other data on the clock line and your data line is high ... is there anything else connected to the clock pin?

No, that's not given. if you are between 0.2*VDD and 0.8*VDD (that is, 1V and 4V) it's neither "high" or "low", you're in unspecified territory - so it could be a 0 on a cold day, but a 1 on a warm day for example.

I just noticed something odd ...

I made a testcase and hooked up the MOSI and SPCK pins to my scope, and got this:

(yellow clock, cyan data)


There is a 40µs pulse on the clock line that serves no purpose as far as I can tell ...
Does someone have an idea why this happens?

This won't have an effect if one writes all data at once, but if you write in groups of 3 bytes, this pulse will mess your data up. (data sent is 170,0,255 - 10101010,00000000,11111111 as bit patterns)

Used configuration:

SPI(new SPI.Configuration(
                Pins.GPIO_NONE,
                false,                  // SS active-low (irrelevant)
                0,                      // No SS setup time(irrelevant)
                0,                      // No SS hold time(irrelevant)
                false,                  // Clock low on idle (so it will be low for 500µs after transmission, which triggers the output of the leds)
                true,                  // Data valid on rising edge
                100,                   // 2kHz clock rate (allows for 500µs between writes)
                SPI.SPI_module.SPI1     // SPI device 1
                )
            );/**/

I might be doing something wrong, so let me ask if I have this part at least right:

1) For the LV input, I have designated Pin 5 (AD0). For the GND for LV, I am using Pin 4.
2) I have an infinite thread that is just constantly writing true via OutputPort on Pin 5. This should generate a constant 3.3V signal.

There is no point in "constantly writing true". You set it high once and then leave it at that ...

A battery with a resistor is not a good idea ... and yes, the pin has to be on - as I said, just use it as an outputport and set it to high.

You don't need the SS pin, why do you define it as pin 13?

Your postData is a mess ...

What is the point of this?

            for (int k = 0; k < 24; k++)
            {
                _data.Write(writeBuf);
            }

You're writing the same buffer 24 times?
As has been already stated, don't use multiple writes for each LED - use one buffer, write it, and be done with it ... this means a single Write call for updating the whole LED strip, no loops involved. The way you do it, there will be seemingly random delays between writes which will sometimes cross the 500us boundary and sometimes not, which will result in odd behaviour ...

The I2CDevice class has a parameter that handles clock speed, so yes. http://msdn.microsof...ockratekhz.aspx

Hi,
I am using a N+ to do a variety of tasks (including a threaded process using sockets). Watching the debugger after a while it slows down and grinds to a halt with no exceptions.

I have tried using Debug.EnableGCMessages(true)-
at start - bytes used 30888 available 20088,
when it stops bytes used 31872, available 19104

I am using build 4.1.0.6 N+

regards
Eric

You'll need to post more information (e.g. source code) if you want useful help - also, trying to build a minimal testcase often identifies the problem (trying to remove as much from the code as possible while keeping the bug alive).

Regards,
Stefan