# HG changeset patch # User David Douard # Date 1517005959 -3600 # Node ID aa1c62f7951894c7771442da3484fcaf5329164c # Parent 70f45e3ac6d00648987c7a4cd6e54ca4a5782fe2 [eip545b] part 3 diff -r 70f45e3ac6d0 -r aa1c62f79518 content/eip545b_3.rst --- /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 diff -r 70f45e3ac6d0 -r aa1c62f79518 content/images/eip545b/yig_bottom.jpg Binary file content/images/eip545b/yig_bottom.jpg has changed diff -r 70f45e3ac6d0 -r aa1c62f79518 content/images/eip545b/yig_broken.jpg Binary file content/images/eip545b/yig_broken.jpg has changed diff -r 70f45e3ac6d0 -r aa1c62f79518 content/images/eip545b/yig_top.jpg Binary file content/images/eip545b/yig_top.jpg has changed