question about SOUND command

[bartman]

sound gpio.1, [116, 12]

Can anyone explain to me why this tone would sound different when used in different programs?

I've been writing two programs for two devices and they both use this sound command. In one program the sound has a higher pitch than the other which has a noticably lower pitch.

I, so far, haven't found anything in the program which would affect this line. It is just in a gosub by itself.

Thanks.

Bart

[Melanie]

You will probably find your PICs oscillators differ... your ear will easily distingush tone changes as small as 0.2% (especially at the higher frequencies)... you'll find that your PICs oscillators are out by more than that from each other (especially if you're using the internal oscillator settings).

[bartman]

I can buy that, and actually thought of that as a reason - for later, but in this case it is the same chip. I have it set up on my breadboard and just reprogrammed it with each of the two programs. So all components are the same in both cases.

In doing a bit more fiddling with it I noticed that a little routine used elsewhere that involves a bit of assembly code to drvie the speaker works the same if used in both programs so it still seems to be revolving around the actual SOUND command.

I have swapped the program a couple times and each time the sound has changed so it isn't just one of those weird one time things.

It really has my head going since I managed to write a program that worked as intended in every other way. The sound thing will keep me awake!

Bart

[mister_e]

You'll remind this OSCCAL stuff :)

As you want a specific (or close to) sound/frequency, you should (and if i remind you did) place this DEFINE OSCCAL_1K 1 line at the top of your code OR if you already know the OSCCAL value OSCCAL=YourValue

AND now you can play with the OSCCAL value to adjust/calibrate the frequency on each and every of your PIC if you have time to kill.

The few assembly line routine you have should look like...


@PlayTone
@ BSF _Piezo
PauseUs AVar
@ BCF _Piezo
PauseUs AVar
@ DECFSZ _Cycles,1
@ Goto PlayTone
.
.
.


wich is almost the same as


PlayTone:
High Piezo
PauseUs AVar
Low Piezo
PauseUs AVar
Cycles=Cycles-1
if Cycles!=0 then PlayTone
.
.
.


The problem with the PBP one, is when you loop many times to produce a longer tone duration, it introduce a longer delay between each LOW to HIGH transistion and do a kind of distortion in the produce sound... unpleasant to hear.

Another advantage of using those instead of SOUND is that you have a better frequency range. As i remind, Melanie already did a table of it... somewhere on this forum.

[bartman]

Yes to all of that Steve.

All the calibrations are set the same on the PIC. The program is different, but the sound has changed between them.

The only thing I can think of is that the timing is off for some reason between the programs, but in such a way that it isn't obvious as to what is doing it.

I have been considering using those other routines to make the beep, but this has become one of those things that needs an explaination now to satisfy me.

I also found that table that Melanie made while I was searching for possible explainations.

I think today I am going to redo the program from a different angle and see if while doing that I uncover the reason. There has to be a logical reason for it.

Bart

After using a different method to get what I wanted I managed to eliminate 200 words which I always like, and bring the two programs to within 66 words of each other. There was no difference in the sound. The second, longer, program still has different sound from the same command as the shorter program. I'm really scratching my head here although I've learned more thinking outside the box through it all.

[bartman]

I've done more experiment with your example code Steve using the one that has some assembly.

If I use Melanie's table to get my corresponding frequency of what SOUND 116 would produce I come up with 886.5 / 2 is 443 as my Avar (from your example). I used a cycle (from your example) of 1200 for the note length.

Doing this I can duplicate my orignal sound which is good.

Now, you may remember you gave me this little program bit a while back for something else. At that time the variables were all BYTE size, but to use the 443 and 1200 I needed WORD size. No problem, I changed that in my definitions.

Now I see that using WORD in place of BYTE actually distorts my other bit of sound code which used a cycle of 30 and a Avar of 255.

From this I can assuming that it takes the processor longer to deal with a WORD variable than a BYTE variable hence the distortion of my original code?

I can easily include two of these routines, one to deal with WORD and one for BYTE for the different sounds I need without distortion, but is my logic correct on the handling of different size variables?

Is there a way around including two routines that are identical except for the variable size?

Thanks.

Bart

[bartman]

If I use Melanie's table to get my corresponding frequency of what SOUND 116 would produce I come up with 886.5 / 2 is 443 as my Avar (from your example). I used a cycle (from your example) of 1200 for the note length.

I see now that this is actually wrong and it should be 1/886 x .5 for a pauseus value of 564.

At least I am reasonably sure of this from what I have learned.

Bart

[bartman]

Seems I may have stumped everyone?

The plot thickens. Last night, out of the blue, it started working properly. I had made no changes to the program. Just as suddenly it returned to producing the wrong sound.

I swap the buzzer and it works properly so I think that the problem has been a bad buzzer, but when I used the "bad" one again with the other program it still works fine 100% of the time.

So the new program requires a different buzzer then the old program to make the same sound. I don't think so.

Anyone have any ideas at all keeping in mind it is the SAME PIC I'm using each time with the same components, just swapping out the programs which are within 66 words of being the same length of each other with the same sound values.

Bart