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.

Setup a task to change stuff on midnight. Definitely

No, the custom firmware just increases clock resolution, it does not make code run magically faster. Seriously, you are wasting your time. I don't get why you think this is a reasonable goal ... you will not be able to count pulses coming in at 1mhz in managed code. Why are you so fixated on directly interfacing this sensor with the netduino? As was already suggested in the beginning: Use another sensor, e.g. with a phototransistor or photoresistor (it does not get much cheaper or easier than this) or use another MCU to do the counting for you.

Not wanting to spoil something, but be careful. It's not "so close to working" - you are still more than an order of magnitude away from your target (500khz). The trick from CW2 is an interesting one, but as you've seen there are limitations - it builds on disabling the interrupt handler before the queue fills up, which it can't if the frequency is very high (as you've seen) and which gets also harder should the GC decide to kick in before the handler start and the removal of the handler. Also, a limitation of that approach is that you only sample for a short time, so you're susceptible to "noisy light" (if the sensor is fast enough for that, didn't check that).

Adding more hardware to this project is a kludge since the chip on-board the Netduino can count these pulses, and I'm not going shopping for more components when I have what I need right here.

"Using a lot of time to build a custom firmware is a kludge since there is cheap hardware available that can measure the light intensity easily with the netduino, and I'm not wasting my valuable time building a custom firmware when there are easy alternatives available."

I just need to know how to be able to count the pulses up to 1MHz.

And we told you the easiest way to do that.

Is it possible to get this sensor working with native code on Netduino, or not? Can I build my own custom Netduino firmware using the porting kit and make this sensor work?

Yes, and if you use 15 minutes of your time (including the time that you take posting here) to do that in order not to go shopping for the components, you are working for less than minimum wage.

If I am not going to get any further positive support on this forum, I guess I will have to look elsewhere.

You are getting positive support, you just don't recognize it.

Just browsing the code and they use a NativeEventHandler - wondering if this is helping with the speed of the interrupts?

Regards,
Mark

No, that part of the code is redundant.

The method will also work on the netduino, as long as the frequencies don't get too high. From the datasheet you can see that the frequency can go up to at least 500khz (they don't provide an absolute upper limit, but a graph in it goes up to 1mhz) which means that there's one pulse every 2 µs, and that is too fast (i don't have absolute timings, but i recall interrupts taking at least 20µs).

No, the ADC was for an hypothetical analog sensor. If you're hooking your sensor to an arduino, you can directly count the pulses with it and then send that number to your netduino. However, using an arduino is overkill for that, you could just use a "naked" microcontroller (e.g. an atmega168 or similar - also overkill for this, but a lot cheaper than a "full" arduino - that is, if you already have a programmer/are planning to buy one anyway).

Hi Stefan, see http://forums.netdui...dpost__p__18103 (yes, they are 5V tolerant unless you do analog input with them, however they are not switched to different pins on the MCU like in the case of I2C). Cheers, Stefan

The protocol it's talking is I2C, you can see some example code using I2C linked in http://forums.netdui...-i2cbus-class/.

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)

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
                )
            );/**/

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.

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.

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 ...

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?

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)?

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 ...

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).

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.

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.

I'm very happy to report that we are now shipping the FPGA shield, with a new name: ÜberShield. Boards are in stock at Amazon.com, and more information can be found at the product website http://ubershield.com and in our forums at http://forums.ubershield.com. The final product specs are essentially the same as above, although the 50 MHz clock oscillator has been replaced with a 25 MHz model.

Just in case you know - what is the reason amazon rejects overseas shipping (to Germany)?

You should NOT supply the current for the motors over the netduino (e.g. by using connecting V_M to VIn), as Mario stated. One (the most important) reason is that Motors usually need more current than the netduino can safely supply (read: you can burn out your netduino), another reason is that motors produce glitches in the power that the netduino won't like. You should use a seperate power supply (a seperate battery pack) for the motor and the netduino - connect the motor battery pack to VM and one GND port of the breakout board, connect 3.3V (netduino) to VCC (board), connect GND (netduino) to another GND on the breakout board. (on a side note - you don't need to connect GND on the netduino to GND on the board 3 times ...) You probably should also add filtering capacitors across VM + GND and VCC + GND.

Edit: It seems that the driver already has builtin filtering capacitors, so you can ignore that bit.

The picture looks like you connected 5V to VCC/STBY instead of 3.3V. As Mario said,

consider to power the chip (Vcc) with +3.3V instead of +5V. This allow much more compatibility for the input levels. If you take a look at the chip specs, they show as +3.5V (min) for the high-level, when powered at +5V. Since Netduino cannot reach output levels over +3.3V, that would be at limit. Another way is keep Vcc=+5V, and configure the Netduino outputs as open-drain.

What is the PWM frequency you are using?