Reprogramming "old" Sennheiser Microphone - Part 4 - PLL

 PLL

At the beginning when I was looking at the I2C communication I have found out which parts of it talks with PLL, but then I carry on as I did not expect it I will need to understand it better and also since I have very vague idea about what PLL actually is. But now I have to find out in order to compute and load proper data for it into the memory.

From the microphone schematics I got the basic idea

• Red line is quite clearly audio input from the AF microphone part. So its the signal that drives the modulation.
• Green line is HF output that goes to the HF amplifier stage, thats also quite clear
• Blue line looks like output from PLL that drives the VCO
• Yellow is line that goes back from the output to the Prescaler which I have found out is fancy word for frequency divider and then into the PLL

 What I thougth PLL is: IC into which you send some f1 and you will get f2 thats locked to the f1 phase. But looking to the datasheet the working frequency of this PLL is actually quite low, much lower then whats the transmitting frequency. Also connections did not make much sense to me, and I was thinking that the prescaler migth be used backwards as multiplier etc. I was wrong. 

 And now how the PLL really works! Heart of the f modulation is VCO which means Voltage Controlled Oscilator. Simply put, output frequency of VCO is driven by voltage on its input. But the problem is that VCO is not very stable due to heating, tolerances of components and noise. So you can't reliably get same frequency for the same input voltage. To solve this issue you will introduce feedback loop! And that's where PLL comes into play. You feed the PLL with some highly stable f source, like crystal. And lock PLL to this reference. Then you also provide feedback from the VCO output. As the PLL and crystal ref. is usually working on lower frequency the PLL has couple of counters/dividers on it's inputs. And also like in this case migth have prescaler. 

 That means, in case you want for example stable 100MHz on the output and you have 5MHz reference you just divide the feedback frequency by 20 so they are equal. If there is some misalignment, the PLL changes output voltage that is used to drive the VCO. This also means that by simply changing the counter/divider ratio you can tune frequency into some extent. 

 What I still dont understand is how it work together with modulation since it changes the frequency. It migth be done with Low-Pass filter on the PLL output that would keep only frequencies, for example, below 50Hz would allow modulation of the frequency from 50Hz above. But this is my guessing.

Quite nice picture that actually looks a lot like topology of the microphone.

That clarified the principles now lets take a look on the communication with PLL. 

write to 0x51 ack data: 0x6A 

read to 0x50 ack data: 0x40

write to 0x51 ack data: 0x6B 

read to 0x50 ack data: 0x28

write to 0x51 ack data: 0x6C 

read to 0x50 ack data: 0x1E

write to 0x7F ack data: 0x5D 0x06 0x83 0x80

0x40

0xE4 0x0A 0x0F 0xFC 0x82

0x01 0x81

This is I2C when the frequency is changed. You can clearly see that three values are read from second block of memory and then some values are sent to the PLL. But stragely values that are sent are not the same values as read. Is MCU doing some processing of the values? Also communication from the I2C decoder looks rather strange/broken. If compared to the tidy memory communication.

And again taking look on the PLL datasheet there are strange blocks of data that should be sent on the bus. But it does not make much sens to me. For now.

16 or 6 bits? EN? Looks akward. So let see what is going on the I2C bus.

I also added probe for extra signal that is used for enabling I2C communication with PLL, it's called EN. Which is the same as the EN on the end of data blocks in datasheet. After reading little bit more it actually looks like its not completly standart I2C. It is even refered as 3-Line bus not I2C. Its using this third line to show when the frame ends. And as the frames have not standard lengths it confuses the I2C encoder. 

Excel to the rescue! Since the I2C decoder wont help me here I tried to write down all the values manualy to excel sheet. Blocks separated by EN high signal. I got 16 bit, 18-ish bit and three 23bit frames. Looking again into the datasheet and it actaully makes sense!

With the help of the information I was able to findout that the first packet is for settings, and the long packets are for the a and n counter. Mentioned 18-ish packet migth be r counter. but the last 2 bits looks strange. Below is functional block diagram of the PLL.

This PLL has 3 counters. r-counter is for reference frequency which in our case is 4Mhz crystal, then there are a and n-counter for the feedback input. The thing is Im not really sure how these counters work with the feedback frequency. Should it be f/(n+a) or n/a. 

Clearly having two counters means that you will get more resolution to match the reference frequency. When decoding the frame that should contain a and n counters it shows up that the values in the packet are actually really the values that are read from the memory after all! That means there is not any post-processing and values in the memory are pure counters values. But since the n-counter is 14-bit its composed from two bytes and the second is padded by 01 to create address of the frame. Belowe is description of data block. Thanks to decoded setting block I know we operate in Dual Mode.

To find out if the last extra block is really r-counter I converted it to dec and its gave me 800. When you divide 4 000 000  by 800, you get 5000 which looks like something that might be correct. Now I have to find the relation between the counters of the feedback from VCO and if Im correct I should also get 5000. 

Interestingly after studying PLL datasheet I did not find place with some huge, obviouse formula for something I would expect to be basic functionality, but maybe the datasheet is meant for someone who works with PLL a lot. So its so common thing it does not have to be mentioned.

But finally I have found, hidden in description of pin that changes prescaler divider, this.

And the formula already takes into account the prescaler. Checking the schematics and prescaler datasheet it should be set to 64 or 65 division, this is decided by MOD output from PLL. But that means I have formula, and also all variables. 

fref/R = f/NP+A  =>  4000/800 = 798700/2495*64+60 => 5 = 5 (using kHz)

Which means that this is correct indeed! That really made my day! This means that now I just have to reverse it to compute a- and n-counter for frequency of my choice! Excel for the rescue, again!

 This task could be, surely again, done in some simple script, but since I need it just for once and there is only 16 channels. It is easier for me to just use Excel sheet with formulas. I was actually surprised that Excel has handy BIN2DEC and similar conversion formulas as this made all the operations really easy. Finding proper counters values was then simple manual work, as the bigger n-counter is increasing with the increasing desired frequency. And the a-count can be max. 128 number as it is only 7-bit. So all it is just about to find number for n-counter for which a-counter will not be more then 128 in order to get the result of 5 kHz.

So after all of this I have table that produces 3 bytes for the memory to be stored and used for PLL programming. 

Lets try to write to memory and test if it really works. Fingers crossed.

More in part 5