Miles.
If you read the manual (always a good start to prove you're looking) you will see that CALIBFREQ is a pseudo command and can accept the values -15 to 15.
"CALIBFREQ {-} factor
- factor is a constant/variable containing the value -15 to 15"
It writes to the OSCTUNE and the manual shows the Address if you wish to Poke.
You
have to have that in your Code, the OSCTUNE register will power-up-reset and MCLR-reset to all the zeroes i.e. it's volatile and will reset to the centre frequency.
If you then look at the Microchip manual under OSCTUNE you can see how the bits are set. Seacrh on 90h in a microchip Data Sheet. This only works for the internal osc.
When setting Baud rates in PIC language you have to set bits in the Baud Rate Generator. There is always a slight error. Most of the times this can be ignored. But sometimes if you've done your BRG calcs based on a 4MHz xtal (say, using BRGH=0) and then move to a 20MHz crystal then you can get errors. Probably fine most of the time but nearer the 'edge' if the frequency drifts.
All these calcs and suggested values are in the Microchip Data Sheet.
I had a scenario a while back of 2-way asynch between PICAXE-PIC(10MHz xtal+PLLd). If I used the calcs to produce the correct Baud Rate it worked fine PIC-PC but intermittent PIC-PICAXE. After several hours I found values that were happy for PIC-PICAXE and PIC-PC. I'm just saying that it ain't magic and that sometimes you may need to twiddle.
I didn't try the PIC-PICAXE (+xtal), but I'm sure that would have been fine.
In fact if you plotted %data reliability vs BRG settings there was almost a Gaussian distribution, though my pencil may have slipped while I was joining the dots