Thu, 10 Nov 2022 16:45:50 +0100
Fix a pelican warning on why.rst
76 | 1 | ======================================== |
2 | EIP 545B RF Frequency Counter - Part 3 | |
3 | ======================================== | |
4 | ||
5 | :author: David Douard | |
6 | :Category: Electronics | |
7 | :Tags: test equipment, RF, EIP, 545B, counter | |
8 | :series: EIP545B Frequency Counter | |
9 | :series_index: 3 | |
10 | ||
11 | ||
12 | Default settings | |
13 | ================ | |
14 | ||
15 | One of the annoying thing with this 'SPECIAL' edition of the firmware are the | |
16 | default settings: | |
17 | ||
18 | - Frequency Offset -160MHz | |
19 | - Resolution 5 digits | |
20 | ||
21 | One of my goals while disassembling the formware was to 'fix' these defaults | |
22 | settings. I was wondering wether they where located in an undocumented part of | |
23 | the EEPROM or directly as hardcoded values in the firmware itself. | |
24 | ||
25 | I have partially understood the setup routine, the one called from the RST | |
26 | vector; the interrupt vector is located at addresses 0xFFF2-0xFFFF, with the | |
27 | RST routine address being at 0xFFFE. In my case, the RST handler is located at | |
28 | 0x5F19: | |
29 | ||
30 | :: | |
31 | ||
32 | FFF2 svec_SWI3 FDB hdlr_SWI3 ;08 20 | |
33 | FFF4 svec_SWI2 FDB hdlr_SWI2 ;9E 90 | |
34 | FFF6 svec_FIRQ FDB hdlr_FIRQ ;48 45 | |
35 | FFF8 svec_IRQ FDB hdlr_IRQ ;70 F1 | |
36 | FFFA svec_SWI FDB hdlr_NMI ;00 00 | |
37 | FFFC svec_NMI FDB hdlr_NMI ;00 00 | |
38 | FFFE svec_RST FDB hdlr_RST ;5F 19 | |
39 | ||
40 | ||
41 | But completely disassembling the whole RST routine is slow and difficult. At | |
42 | some point, I found that a smarter approach would be to compare the content of | |
43 | the RAM after a fresh start and after having modified some configuration | |
44 | values, like the Frequency Offset. | |
45 | ||
46 | The RAM addresses where the offset values are documented in the Service Manual, | |
47 | unfortunately, each model as its how address map, and no available Service | |
48 | Manual covers the EIP 545B. So I first needed to find where the frequency | |
49 | offset is stored in RAM so I can then look where this area is modified in the | |
50 | firmware. | |
51 | ||
52 | Thanks to the TEST10 allowing to read any address in the address space (be it | |
53 | RAM, EEPROM, EPROM or even I/O registers), I wrote a simple Python script to | |
54 | read the whole content of the RAM via GPIB. | |
55 | ||
56 | It's very slow, since I did not find a way using GPIB commands to read 2 memory | |
77
9ba7fe3d0a22
[eip545B] part 3: few improvements about digits resolution
David Douard <david.douard@logilab.fr>
parents:
76
diff
changeset
|
57 | addresses without quitting the TEST10 mode between two reads. And I had to add |
76 | 58 | several sleep() since the EIP is pretty slow to respond to GPIB commands. A |
59 | complete dump of the 2ko RAM took somethin like 15 or 20 minutes. | |
60 | ||
61 | I did not even wrote a script, in fact, just throw some code in an IPython | |
62 | session. However, the crude code looks like: | |
63 | ||
64 | ||
65 | .. code-block:: python | |
66 | ||
67 | import serial | |
68 | cnx = serial('/dev/ttyUSB0', baudrate='115200') | |
69 | cnx.write('++addr 17\r\n') | |
70 | ||
71 | def rd(x): | |
72 | cnx.write('TA10\r\n') | |
73 | time.sleep(0.1) | |
74 | cnx.write('%04X\r\n' % x) | |
75 | time.sleep(0.1) | |
76 | cnx.write('++read\r\n') | |
77 | time.sleep(0.05) | |
78 | r = cnx.read_all() | |
79 | cnx.write('TP\r\n') | |
80 | return r | |
81 | ||
82 | def getmem(n=0x800): | |
83 | out = [] | |
84 | for x in range(n): | |
85 | v = rd(x).strip() | |
86 | v = v.split('-') | |
87 | out.append(v) | |
88 | time.sleep(0.5) | |
89 | return out | |
90 | ||
91 | ramcontent = getmem() | |
92 | # [...] write ramcontent in a file | |
93 | ||
94 | ||
95 | This allowed me to quickly find where the Frequency Offset is stored: | |
96 | 0x0276-0x027C (using the format described in the service manual). | |
97 | ||
98 | For the number of digits, I'm not sure yet, but it looks to be located at | |
99 | 0x0045 or 0x0046. | |
100 | ||
101 | So I could then look for this Freq. Offset address (OxO276) in the firmware: | |
102 | It's used directly only a couple of times in the code, one of them lloking | |
103 | like: | |
104 | ||
105 | :: | |
106 | ||
107 | 6118 LDX #M0276 ;8E 02 76 | |
108 | 611B LDA #$01 ;86 01 | |
109 | 611D STA ,X ;A7 84 | |
110 | 611F STA $02,X ;A7 02 | |
111 | 6121 LDA #$60 ;86 60 | |
112 | 6123 STA $03,X ;A7 03 | |
113 | ||
114 | ||
115 | in which we can see that the value 0x01 (from register A) is stored at address | |
116 | 0x0276 and 0x278 (thanks to the STA $02,X instruction, with X being 0x0276 when | |
117 | this former instruction is executed, it stores the content of A (0x01) at | |
118 | addres 0x0276+2=0x278), and the value 0x60 is stored at 0x0279 (STA $03,X). | |
119 | ||
120 | It worth noting that this snip of code is executed shortly after intializing the | |
121 | RAM content to zero. | |
122 | ||
123 | So the result of this piece of code is that the content of the RAM at this | |
124 | 0x0276 address is: | |
125 | ||
126 | .. | |
127 | ||
128 | 01 00 01 60 00 00 00 | |
129 | ||
130 | ie., conververted in frequency: -160MHz, the initial value I want get rid of!. | |
131 | ||
132 | So I just have to replace these code by NOP instructions and it should be fine | |
133 | for the Frequency Offset, which I haven't done yet (I was waiting for a cheap | |
134 | EPROM eraser from eb, which just arrived). | |
135 | ||
77
9ba7fe3d0a22
[eip545B] part 3: few improvements about digits resolution
David Douard <david.douard@logilab.fr>
parents:
76
diff
changeset
|
136 | Concerning the resolution, some clue can be found just after the previous |
9ba7fe3d0a22
[eip545B] part 3: few improvements about digits resolution
David Douard <david.douard@logilab.fr>
parents:
76
diff
changeset
|
137 | routine:: |
9ba7fe3d0a22
[eip545B] part 3: few improvements about digits resolution
David Douard <david.douard@logilab.fr>
parents:
76
diff
changeset
|
138 | |
9ba7fe3d0a22
[eip545B] part 3: few improvements about digits resolution
David Douard <david.douard@logilab.fr>
parents:
76
diff
changeset
|
139 | 6125 LDX #M005D ;8E 00 5D |
9ba7fe3d0a22
[eip545B] part 3: few improvements about digits resolution
David Douard <david.douard@logilab.fr>
parents:
76
diff
changeset
|
140 | 6128 LDA #$0D ;86 0D |
9ba7fe3d0a22
[eip545B] part 3: few improvements about digits resolution
David Douard <david.douard@logilab.fr>
parents:
76
diff
changeset
|
141 | 612A STA $01,X ;A7 01 |
9ba7fe3d0a22
[eip545B] part 3: few improvements about digits resolution
David Douard <david.douard@logilab.fr>
parents:
76
diff
changeset
|
142 | 612C LDA #$05 ;86 05 |
9ba7fe3d0a22
[eip545B] part 3: few improvements about digits resolution
David Douard <david.douard@logilab.fr>
parents:
76
diff
changeset
|
143 | 612E STA >M0045 ;B7 00 45 |
9ba7fe3d0a22
[eip545B] part 3: few improvements about digits resolution
David Douard <david.douard@logilab.fr>
parents:
76
diff
changeset
|
144 | |
9ba7fe3d0a22
[eip545B] part 3: few improvements about digits resolution
David Douard <david.douard@logilab.fr>
parents:
76
diff
changeset
|
145 | In which the value 0x0D is written at RAM address 0x005E (0x005D + 0x01 from |
9ba7fe3d0a22
[eip545B] part 3: few improvements about digits resolution
David Douard <david.douard@logilab.fr>
parents:
76
diff
changeset
|
146 | the opcode ``STA $01,X``), and the value 0x05 is written at RAM address 0x0045, |
9ba7fe3d0a22
[eip545B] part 3: few improvements about digits resolution
David Douard <david.douard@logilab.fr>
parents:
76
diff
changeset
|
147 | which we identified previously as a candidate for the digits resolution |
9ba7fe3d0a22
[eip545B] part 3: few improvements about digits resolution
David Douard <david.douard@logilab.fr>
parents:
76
diff
changeset
|
148 | setting; pretty consistant with the 0x05 value written there. Not sure what the |
9ba7fe3d0a22
[eip545B] part 3: few improvements about digits resolution
David Douard <david.douard@logilab.fr>
parents:
76
diff
changeset
|
149 | 0x0D is used for at address 0x005E. |
76 | 150 | |
151 | ||
82 | 152 | .. _sensitivity-problem: |
153 | ||
76 | 154 | The sensitivity problem |
155 | ======================= | |
156 | ||
157 | I have also investigated a bit the sensitivity problem I have on band 3: I can | |
158 | hardly detect signals lower than -10dBm at 1 or 2GHz, where it should be able | |
159 | to catch a -30dBm. | |
160 | ||
161 | I've tried to recalibrate (on that frequency range) the YIG filter, it did not | |
162 | help. | |
163 | ||
164 | Following the advise of HighPrecision on the eevblog forum, I did give a check | |
165 | at the SMD capacitors in the IF amplifier/detector detector part of A201. I | |
166 | still need to investigate more, but I haven't found an obvious culprit in | |
167 | there. | |
168 | ||
169 | But since I had disassembled the A203 unit, I also gave a closer look at the | |
170 | YIG filter itself, taking pictures with my small USB microscope. | |
171 | ||
172 | On one side is the ceramic support for connections from the output YIG coupling | |
173 | loop: | |
174 | ||
128
aba381b2bac9
Fix several inter-document links
David Douard <david.douard@sdf3.org>
parents:
115
diff
changeset
|
175 | .. image:: {static}/images/eip545b/yig_top.jpg |
76 | 176 | :alt: Top view of the YIG filter |
177 | ||
178 | On the bottom side, we can see the YIG spheres and the coupling loops: | |
179 | ||
128
aba381b2bac9
Fix several inter-document links
David Douard <david.douard@sdf3.org>
parents:
115
diff
changeset
|
180 | .. image:: {static}/images/eip545b/yig_bottom.jpg |
76 | 181 | :alt: Top view of the YIG filter |
182 | ||
183 | So this filter consists in a 2 stage bandpass filter (with input and output | |
184 | couplig loops at 90° each other). | |
185 | ||
186 | Having a closer look, the problem appears: | |
187 | ||
128
aba381b2bac9
Fix several inter-document links
David Douard <david.douard@sdf3.org>
parents:
115
diff
changeset
|
188 | .. image:: {static}/images/eip545b/yig_broken.jpg |
76 | 189 | :alt: Broken stage 1 of the YIG filter |
190 | ||
191 | As can been seen there, the YIG sphere took off the holding rod. Tha cage made | |
192 | of the 2 coupling loops is small enough the sphere stayed there, but it is not | |
193 | at the center of the 2 loops any more, nor it is correctly orientated. No | |
194 | surprise the input signal is so low (in fact the suprise is that is still works | |
195 | somehow). | |
196 | ||
197 | I tried to move the sphere a bit, using a sharp (as sharp as possible) wooden | |
198 | stick under the USB microscope, but it is really hard to orientate the sphere | |
199 | (which diameter is around 0.1 or 0.2mm). | |
200 | ||
201 | I'll try again, just in case, since I can see the mark of the rod on the | |
202 | sphere, I think I may be able to roughly reorientate the sphere, but it is | |
203 | really hard to do without micrometric actuators. | |
204 | ||
205 | Meanwhile, I've bought on eb a cheap (20$) A203 assembly. It's not exactly the | |
206 | same model (it's probably one for the 26.5GHz version, according to | |
207 | HighPrecision), we'll see if it works. I hope it's a 127MHz version, otherwise | |
208 | I'll have to replace the YIG filter (A201) on my A203 unit with this one. | |
209 | ||
77
9ba7fe3d0a22
[eip545B] part 3: few improvements about digits resolution
David Douard <david.douard@logilab.fr>
parents:
76
diff
changeset
|
210 | By the way, for thoses interested, I found these 2 simple documents interesting |
9ba7fe3d0a22
[eip545B] part 3: few improvements about digits resolution
David Douard <david.douard@logilab.fr>
parents:
76
diff
changeset
|
211 | to begin to understand how a YIG oscillator and a YIG filter works: |
76 | 212 | |
213 | - `YIG TUNED OSCILLATORS`_ | |
214 | - `YIG TUNED FILTERS`_ | |
215 | ||
216 | .. _`YIG TUNED FILTERS`: http://www.microlambdawireless.com/uploads/files/pdfs/ytfdefinitions2.pdf | |
217 | .. _`YIG TUNED OSCILLATORS`: http://www.microlambdawireless.com/uploads/files/pdfs/ytodefinitions2.pdf |