Mercurial > whatever / changeset

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/content/eip545b_3.rst	Fri Jan 26 23:32:39 2018 +0100
@@ -0,0 +1,203 @@
+========================================
+ EIP 545B RF Frequency Counter - Part 3
+========================================
+
+:author: David Douard
+:Category: Electronics
+:Tags: test equipment, RF, EIP, 545B, counter
+:series: EIP545B Frequency Counter
+:series_index: 3
+
+
+Default settings
+================
+
+One of the annoying thing with this 'SPECIAL' edition of the firmware are the
+default settings:
+
+- Frequency Offset -160MHz
+- Resolution 5 digits
+
+One of my goals while disassembling the formware was to 'fix' these defaults
+settings. I was wondering wether they where located in an undocumented part of
+the EEPROM or directly as hardcoded values in the firmware itself.
+
+I have partially understood the setup routine, the one called from the RST
+vector; the interrupt vector is located at addresses 0xFFF2-0xFFFF, with the
+RST routine address being at 0xFFFE. In my case, the RST handler is located at
+0x5F19:
+
+::
+
+  FFF2 svec_SWI3   FDB     hdlr_SWI3                ;08 20
+  FFF4 svec_SWI2   FDB     hdlr_SWI2                ;9E 90
+  FFF6 svec_FIRQ   FDB     hdlr_FIRQ                ;48 45
+  FFF8 svec_IRQ    FDB     hdlr_IRQ                 ;70 F1
+  FFFA svec_SWI    FDB     hdlr_NMI                 ;00 00
+  FFFC svec_NMI    FDB     hdlr_NMI                 ;00 00
+  FFFE svec_RST    FDB     hdlr_RST                 ;5F 19
+
+
+But completely disassembling the whole RST routine is slow and difficult. At
+some point, I found that a smarter approach would be to compare the content of
+the RAM after a fresh start and after having modified some configuration
+values, like the Frequency Offset.
+
+The RAM addresses where the offset values are documented in the Service Manual,
+unfortunately, each model as its how address map, and no available Service
+Manual covers the EIP 545B. So I first needed to find where the frequency
+offset is stored in RAM so I can then look where this area is modified in the
+firmware.
+
+Thanks to the TEST10 allowing to read any address in the address space (be it
+RAM, EEPROM, EPROM or even I/O registers), I wrote a simple Python script to
+read the whole content of the RAM via GPIB.
+
+It's very slow, since I did not find a way using GPIB commands to read 2 memory
+addresses without quitting the TEST10 mode between to reads. And I had to add
+several sleep() since the EIP is pretty slow to respond to GPIB commands. A
+complete dump of the 2ko RAM took somethin like 15 or 20 minutes.
+
+I did not even wrote a script, in fact, just throw some code in an IPython
+session. However, the crude code looks like:
+
+
+.. code-block:: python
+
+   import serial
+   cnx = serial('/dev/ttyUSB0', baudrate='115200')
+   cnx.write('++addr 17\r\n')
+
+   def rd(x):
+       cnx.write('TA10\r\n')
+       time.sleep(0.1)
+       cnx.write('%04X\r\n' % x)
+       time.sleep(0.1)
+       cnx.write('++read\r\n')
+       time.sleep(0.05)
+       r = cnx.read_all()
+       cnx.write('TP\r\n')
+       return r
+
+   def getmem(n=0x800):
+       out = []
+       for x in range(n):
+           v = rd(x).strip()
+           v = v.split('-')
+           out.append(v)
+           time.sleep(0.5)
+       return out
+
+   ramcontent = getmem()
+   # [...] write ramcontent in a file
+
+
+This allowed me to quickly find where the Frequency Offset is stored:
+0x0276-0x027C (using the format described in the service manual).
+
+For the number of digits, I'm not sure yet, but it looks to be located at
+0x0045 or 0x0046.
+
+So I could then look for this Freq. Offset address (OxO276) in the firmware:
+It's used directly only a couple of times in the code, one of them lloking
+like:
+
+::
+
+   6118             LDX     #M0276                   ;8E 02 76
+   611B             LDA     #$01                     ;86 01
+   611D             STA     ,X                       ;A7 84
+   611F             STA     $02,X                    ;A7 02
+   6121             LDA     #$60                     ;86 60
+   6123             STA     $03,X                    ;A7 03
+
+
+in which we can see that the value 0x01 (from register A) is stored at address
+0x0276 and 0x278 (thanks to the STA $02,X instruction, with X being 0x0276 when
+this former instruction is executed, it stores the content of A (0x01) at
+addres 0x0276+2=0x278), and the value 0x60 is stored at 0x0279 (STA $03,X).
+
+It worth noting that this snip of code is executed shortly after intializing the
+RAM content to zero.
+
+So the result of this piece of code is that the content of the RAM at this
+0x0276 address is:
+
+..
+
+  01 00 01 60 00 00 00
+
+ie., conververted in frequency: -160MHz, the initial value I want get rid of!.
+
+So I just have to replace these code by NOP instructions and it should be fine
+for the Frequency Offset, which I haven't done yet (I was waiting for a cheap
+EPROM eraser from eb, which just arrived).
+
+Now I also want to fix the initial resolution setup, which I haven't figured
+out yet.
+
+
+The sensitivity problem
+=======================
+
+I have also investigated a bit the sensitivity problem I have on band 3: I can
+hardly detect signals lower than -10dBm at 1 or 2GHz, where it should be able
+to catch a -30dBm.
+
+I've tried to recalibrate (on that frequency range) the YIG filter, it did not
+help.
+
+Following the advise of HighPrecision on the eevblog forum, I did give a check
+at the SMD capacitors in the IF amplifier/detector detector part of A201. I
+still need to investigate more, but I haven't found an obvious culprit in
+there.
+
+But since I had disassembled the A203 unit, I also gave a closer look at the
+YIG filter itself, taking pictures with my small USB microscope.
+
+On one side is the ceramic support for connections from the output YIG coupling
+loop:
+
+.. image:: {filename}images/eip545b/yig_top.jpg
+   :alt: Top view of the YIG filter
+
+On the bottom side, we can see the YIG spheres and the coupling loops:
+
+.. image:: {filename}images/eip545b/yig_bottomn.jpg
+   :alt: Top view of the YIG filter
+
+So this filter consists in a 2 stage bandpass filter (with input and output
+couplig loops at 90° each other).
+
+Having a closer look, the problem appears:
+
+.. image:: {filename}images/eip545b/yig_broken.jpg
+   :alt: Broken stage 1 of the YIG filter
+
+As can been seen there, the YIG sphere took off the holding rod. Tha cage made
+of the 2 coupling loops is small enough the sphere stayed there, but it is not
+at the center of the 2 loops any more, nor it is correctly orientated. No
+surprise the input signal is so low (in fact the suprise is that is still works
+somehow).
+
+I tried to move the sphere a bit, using a sharp (as sharp as possible) wooden
+stick under the USB microscope, but it is really hard to orientate the sphere
+(which diameter is around 0.1 or 0.2mm).
+
+I'll try again, just in case, since I can see the mark of the rod on the
+sphere, I think I may be able to roughly reorientate the sphere, but it is
+really hard to do without micrometric actuators.
+
+Meanwhile, I've bought on eb a cheap (20$) A203 assembly. It's not exactly the
+same model (it's probably one for the 26.5GHz version, according to
+HighPrecision), we'll see if it works. I hope it's a 127MHz version, otherwise
+I'll have to replace the YIG filter (A201) on my A203 unit with this one.
+
+By the way, for thoses interested, I found these 2 documents interesting to
+begin to understand how a YIG oscillator and a YIG filter works:
+
+- `YIG TUNED OSCILLATORS`_
+- `YIG TUNED FILTERS`_
+
+.. _`YIG TUNED FILTERS`: http://www.microlambdawireless.com/uploads/files/pdfs/ytfdefinitions2.pdf
+.. _`YIG TUNED OSCILLATORS`: http://www.microlambdawireless.com/uploads/files/pdfs/ytodefinitions2.pdf

Binary file content/images/eip545b/yig_bottom.jpg has changed

Binary file content/images/eip545b/yig_broken.jpg has changed

Binary file content/images/eip545b/yig_top.jpg has changed