Questions on an SFH3710 phototransistor

Ok, solved the problem, sorta...

Was measuring with the ADC on my PIC, and looking at the results. I looked at no LED, red, blue, then green. Got values for the blue and the green, but no red. so looked AGAIN for the red and now it gets a value. Same PIC code, just copied it after the others. So, somehow the order seems to make a difference to the ADC code... :-(

PIC programming drives me nuts, sometimes!

Charlie

Sure the red is actually turning on? Ye olde modify-write bug^H^H^H feature?

Or maybe insufficient ADC acquisition time?

Best regards, Spehro Pefhany

On a sunny day (Tue, 26 May 2009 20:33:12 -0400) it happened Spehro Pefhany wrote in :

Or banksel

Coming from an other piece of code using an other bank, the first (red) will not work, but once a banksel happened the green and blue worked? Perhaps in PIC asm at the start of a subroutine use: banksel X as you do not know where it is called from. LOL

;-)

"Charlie E." schreef in bericht news: snipped-for-privacy@4ax.com...

Don't think so. But switching the ADC from one pin to another takes some time. Then the ADC needs some aquisition time before it produces a usable value. (That's what I found when running in a similar problem some time ago.) You need to read the appropriate part of te datasheet at least twice unless you are a real genius.

Consider it part of the fun :)

petrus bitbyter

Well, I am only using one pin for the ADC, and programming in C, so the bank selects shouldn't be a problem. I was doing some quick logic before the faulty ADC read, so my assumption at this point is that the ADC had gone into la-la land, and the first read didn't do the necessary wait for the sampling. For now, at this stage in testing, I will just re-read the red at the end.

Now, I just need to build a little amplifier, maybe 10x, to get the output of the photo transistor up to full scale. Even the bright LEDs don't put out as many lumens as my original test source...

Charlie

"Charlie E." schreef in bericht news: snipped-for-privacy@4ax.com...

What PIC are you using?

FAIK all midrange PICs with A/Ds have an A/D control register in which - amongst others - a bit to turn the A/D on and another one to control conversion. This last bit should be set to start the conversion and will be reset by the PIC when the conversion has been completed. Be aware that turning the A/D on and starting a conversion should not be done in the same instruction. This may be the cause of the failure of the first conversion.

More details in the relevant part of the datasheet.

petrus bitbyter

Man, do PICs really suck that much? AVRs can set the ADC in a couple instructions, run it 24/7, *and* trigger an interrupt so you can keep it hacking away, apply averaging, etc. :-)

Tim

Ok, this is my basic code:

// Read and store RED // Turn on red LED LATA = 0xFE; // Need to delay for time for LED to turn on... Wait(200000); // // Read value for RED AD1CON1bits.SAMP = 1; // Start sampling while (!AD1CON1bits.DONE); // Wait for conversion to complete RED = ADC1BUF0; // Put result of conversion in RED // Turn off red LED LATA = 0xFF;

I turned on the ADC in the read before this, where I didn't have any of the LEDs on. Very strange... :-(

Charlie

Charlie:-

Looks like you're using something like a PIC24, with Tad based conversion start. Among other things you need to make sure that the configuration allows sufficient time for acquisition to take place. eg. AD1CON3 = 0x0F00 for 15 cycles (PIC24). If it's at the default

Ok, my setup code is:

AD1CON1 = 0x00E0; // SSRC bit = 111 implies internal // counter ends sampling // and starts converting. AD1CON2 = 0; // Configure A/D voltage reference // and buffer fill modes. // Vr+ and Vr- from AVdd and AVss (VCFG=000), // Inputs are not scanned, // Interrupt after every sample AD1CHS = 0x0005; // Connect AN5 as CH0 input AD1CSSL = 0; // No scanning required AD1CON3 = 0x1FFF; // Tsamp = 32 x Tac;

Boy, that formatting gets screwed up!

Charlie

"Tim Williams" schreef in bericht news:mmfTl.70584$ snipped-for-privacy@newsfe08.iad...

Well, PICs can do the same but I don't want to treat the whole of the A/D conversion part. You can read it for yourself if you want to :)

petrus bitbyter

Charlie, dare i believe that you did not cross check at analog levels before changing parts?

Yep, sloppy of me... ;-)

Charlie

response

is

At least i am not alone.