Hank,
Thanks for sharing! You projects always push the limits, so we all learn.
Regards
Hank,
Thanks for sharing! You projects always push the limits, so we all learn.
Regards
Thanks gents ...but I'm just a guy who has a couple "hmm, I wonder if ....." ideas - & without truly knowing how to arrive at the end destination! (or sometimes how to even start off on the journey!). It's the wealth of knowledge on this forum (& willingness to contribute to my threads) by folks that actually have a clue that makes it all happen.
Re the Wiki - I'd be too mortified/embarrassed that my (sometimes cringeworthy) stuff would actually make it into such a place (like I say, in this instance the program I've knocked up is not that elegant but seems to work...I think!), but to do it justice I'd have to write it up a lot better, do a lot more testing etc ....there's not enough hours in the day blah blah.... but I'm really chuffed though that you thought it was a potential contender though :-)
You thought I was done here didn't you?!
Well for this to be 100% dependable, I need to be assured I know what the hell is going 'behind the scenes' with respect to this special event trigger melarkey.specifically whether the sample rate can be easily worked out & dependable.
Firstly...I've accounted for the ADC value 'jitter' - the incoming audio ignal is jittering! (this means it's not a measurement error...but the actual signal itself is varying. This is very heartening as it means this thing has real potential!)
Ok, something troubles me here, this from the datasheet.,..
"The Special Event Trigger output of the CCP occurs immediately upon a match between the TMR1H, TMR1L register pair and the CCPRxH, CCPRxL register pair. The TMR1H, TMR1L"
At 8MHz, therefore a 2MHz instruction clock that presetting 50 for TMR1L to match against would - if I have the maths/theory correct - mean a a 40khz special event trigger rate......but if that were the case, I'd have expected to seen the ADC samples be ing far more erratic at an audio input signal 20khz than what I'm seeing (two samples during the 20Khz waveform would have ADC results all over the place) ...so what's going on?
I looked at the datasheet, and apparently it's possible to get the special event trigger to toggle a pin (as opposed to take an ADC sample) ...at least in that way, I could the put a scope on to the physical pin confirm the observed frequency vs the number preloaded into the CCPRxH, CCPRxL pair. I'll revisit this over the coming evenings, but if anyone has had prior dealings with the special even trigger & specifically getting it to toggle a pin - all top tips greatfully received! Here's what I'm seeing on the CCP4 pin (I've set the pin as an output)....
(thats doesn't look like a good square wave at all!)
& here's the register I'm setting....
Code:CCP4CON = %0000010
Also, can someone clear up this ADC uncertainty for me.....Fosc/8 & tads...there's a table on page 149 of the datasheet here http://ww1.microchip.com/downloads/e...Doc/41419A.pdf but it's not clear to me how many tads an 8 bit ADC sample will take (10 bits would appear to be 11.5...therefore 12us?!)....basically I want to know how long an ADC sample takes...as obviously this will dictate the maximum sample rate I can get the special event timer to run at.
Last edited by HankMcSpank; - 23rd February 2011 at 22:59.
I believe you are correct in the math, maybe you are off by a count of 1 for reload or something. The more perplexing part to me is the scope showing 30 Hz!! That really confuses me.At 8MHz, therefore a 2MHz instruction clock that presetting 50 for TMR1L to match against would - if I have the maths/theory correct - mean a a 40khz special event trigger rate......but if that were the case, I'd have expected to seen the ADC samples be ing far more erratic at an audio input signal 20khz than what I'm seeing (two samples during the 20Khz waveform would have ADC results all over the place) ...so what's going on?
Is the incoming signal comming from a signal generator? if so it is prolly a really nice clean 20K? So if this is the case, it stands to reason the samples are being taken at the same spot maybe? since 20k is half the sample frequency.
What if the signal is 19.367K? (random number)
-Bert
The glass is not half full or half empty, Its twice as big as needed for the job!
http://foamcasualty.com/ - Warbird R/C scratch building with foam!
You do not give yourself enough credit. Who cares if the code is "elegant" as long as it works. I do understand about time though...Re the Wiki - I'd be too mortified/embarrassed that my (sometimes cringeworthy) stuff would actually make it into such a place (like I say, in this instance the program I've knocked up is not that elegant but seems to work...I think!), but to do it justice I'd have to write it up a lot better, do a lot more testing etc ....there's not enough hours in the day blah blah.... but I'm really chuffed though that you thought it was a potential contender though :-)
Keep up the good work!
Dave
Always wear safety glasses while programming.
That's a good call (as ever) Bert - I shall try it tonight.
Since I can't get to the bottom of ensuring the sample rate *is* what I *hope* it is....last night, I tried the good old 'tried & tested' ...send the max audio frequency I'm interested in (1.5khz) then tweak the TMR 'match against' CCPRxH, CCPRxL registers (sample rate) until I saw static ADC readings. From recollection it was about CCPR4l = 100 (which I think works out at 20khz sampling)...which is 13 samples throughout the waveform ....albeit this was with a slower decrement (pseudo capacaitor discharge rate). As I type this, that doesn't seem enough samples in the light of the stable readings I was seeing. Hmmm.
I really can't figure out what's going on with the toggling CCP4 output pin (the whacky square wave)...30Hz?!!!
Can anyone think of an alternative method of confirming the special event trigger frequency?!!
I've now got a fresh challenge-ette with this method ...the dependency (stability) of it very much depends on the time it takes for my main loop....obviously the ADC register is getting updated at the sample rate (in the background), but if I don't copy the ADRESH register into my my main loop & then process it 'in between' subsequent samples then I'm in trouble - therefore I need to establish a way of seeing exactly how much time my main loop is taking (ie so I know when I've gone past the time allowed between samples) .....how best to approach this? (my immediate thought is a timer count between loops & convert the timer value to human time that I can see onscreen?!!)
Last edited by HankMcSpank; - 24th February 2011 at 09:42.
HankMcSpank , If you have an extra pin available or one you can (borrow) for the test, just set it at the begining and then clear it at the end of the portion of the program you are trying to time. Use a scope or a timer/counter to get the actual timing value.... It works for me... The plus side is the instructions don't add much to offset the timing. (portb.4 = 1).......(portb.4 = 0)
Dave Purola,
N8NTA
Bookmarks