Stefan W.'s Content

#26367 Redacted 00101100

Posted by Stefan W. on 04 April 2012 - 09:54 AM in General Discussion

Setup a task to change stuff on midnight. Definitely

#19384 SPI, Netduino, and RGB LED Strip

Posted by Stefan W. on 19 October 2011 - 01:18 AM in General Discussion

I just noticed something odd ...

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

Posted Image

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

#19381 SPI, Netduino, and RGB LED Strip

Posted by Stefan W. on 19 October 2011 - 12:06 AM in General Discussion

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

#19332 SPI, Netduino, and RGB LED Strip

Posted by Stefan W. on 17 October 2011 - 09:47 PM in General Discussion

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.

#19434 SPI, Netduino, and RGB LED Strip

Posted by Stefan W. on 20 October 2011 - 12:16 PM in General Discussion

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)

#19480 SPI, Netduino, and RGB LED Strip

Posted by Stefan W. on 21 October 2011 - 12:03 AM in General Discussion

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.

#19567 SPI, Netduino, and RGB LED Strip

Posted by Stefan W. on 21 October 2011 - 09:38 PM in General Discussion

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.

#19563 SPI, Netduino, and RGB LED Strip

Posted by Stefan W. on 21 October 2011 - 08:53 PM in General Discussion

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.

#19316 SPI, Netduino, and RGB LED Strip

Posted by Stefan W. on 17 October 2011 - 01:46 PM in General Discussion

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

#19471 SPI, Netduino, and RGB LED Strip

Posted by Stefan W. on 20 October 2011 - 08:08 PM in General Discussion

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.

#19357 SPI, Netduino, and RGB LED Strip

Posted by Stefan W. on 18 October 2011 - 11:05 AM in General Discussion

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

#19273 SPI, Netduino, and RGB LED Strip

Posted by Stefan W. on 16 October 2011 - 09:20 PM in General Discussion

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?

#19250 SPI, Netduino, and RGB LED Strip

Posted by Stefan W. on 16 October 2011 - 10:49 AM in General Discussion

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

#18240 High resolution light measurement

Posted by Stefan W. on 20 September 2011 - 01:11 PM in General Discussion

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.

#18224 High resolution light measurement

Posted by Stefan W. on 20 September 2011 - 05:35 AM in General Discussion

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

#18161 High resolution light measurement

Posted by Stefan W. on 18 September 2011 - 08:40 PM in General Discussion

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

#18246 High resolution light measurement

Posted by Stefan W. on 20 September 2011 - 02:13 PM in General Discussion

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.

#18151 High resolution light measurement

Posted by Stefan W. on 18 September 2011 - 06:40 PM in General Discussion

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

#19213 TMP36 Temperature Sensor/SB Protoshield

Posted by Stefan W. on 15 October 2011 - 01:44 PM in Netduino 2 (and Netduino 1)

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.

#20333 DS1307 Sparkfun I2C

Posted by Stefan W. on 07 November 2011 - 11:37 PM in Netduino 2 (and Netduino 1)

Arduinos I2C library uses the internal pullups of the microcontroller when it's not driving the line low - those are weak pullups, but since it only uses "slow" I2C, it works most of the time ... that's the reason you didn't need it, it's still better if you do have external pullups there.

#19867 I become crazy because wiring?

Posted by Stefan W. on 27 October 2011 - 04:11 PM in Netduino 2 (and Netduino 1)

You still have the wiring wrong. You have Netduino Pin 13 = MOSI connected to 595 Pin 11 = Shift register clock with the blue cable, and Netduino Pin 11 = SPCK goes to 595 Pin 14 = Data serial (pink cable). Switch the blue and the pink cable at the netduino.

#19757 I become crazy because wiring?

Posted by Stefan W. on 25 October 2011 - 04:12 PM in Netduino 2 (and Netduino 1)

Can you take a picture of your setup, and post it along with the code you've used?

#19775 I become crazy because wiring?

Posted by Stefan W. on 25 October 2011 - 10:01 PM in Netduino 2 (and Netduino 1)

Okay, a few wild shots to rule things out ... if you remove the 74hc595 and then connect the 3.3v rail to the places where its output legs are, do the LEDs light up? (just to rule out a problem with the wiring ...) Are you sure that you have a 74HC595 and not a 74HCT595 - can't read that on the images? (the latter needs a supply voltage >= 4.5V, you're providing 3.3V - nothing wrong when you use a 74HC595, but won't work with 74HCT595). If that's the case, you can try powering it via the 5V line - should work, but you're scratching the edge of the specs then (regarding signal voltage levels).

#18822 Help porting Arduino code for FM radio module

Posted by Stefan W. on 05 October 2011 - 03:47 PM in General Discussion

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

#18763 Help porting Arduino code for FM radio module

Posted by Stefan W. on 04 October 2011 - 12:26 PM in General Discussion

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