Hacking old HP spectrum Analyzers - Page 1
Forum section: electronics / testgear

author: alex.forencich
author_rank: Frequent Contributor
timestamp: April 08, 2014, 02:08:58 am
content: So this is something I did a little while ago, but I figured people here might find it useful, or at least interesting.The 859xE series analyzers made by HP/Agilent have a number of installable options. One of these options is Option 105, the gate option. For the A series analyzers, this is a card. However, for the E series analyzers, HP actually built the gate circuitry into the motherboard. Interestingly, they then provided two ways of adding option 105: one is to send the analyzer back to Agilent, where they will turn on the internal gate option. If this is too difficult, they can also send out a whole gate card that the customer can install. The internal option shows up as GATE rev B, while the card shows up as GATE rev A.I figured it would be interesting to figure out how to turn on the gate option in the analyzer as installing a whole option card is rather redundant.First, the recon: the internal gate module itself just appears as a pair of SMB connectors on the motherboard that must be connected to the back panel with SMB to BNC cables. Then, the module must be enabled in the firmware somehow. These analyzers have a small amount of battery-backed NVRAM, the perfect place to store calibration data and possibly this sort of a 'sofware switch.' The service manual also lists some procedures for when the internal memory is erased. For most analyzers, nothing special is required as the firmware can detect what analyzer it's running in. However, there are a couple of cases where this doesn't work and manual intervention is required. First, there is apparently no detectable difference between the 8595E and the 8596E, so the unit will pop up a box and ask. However, the procedure for an 8591C is different: it will initialize as an 8591E, and then the manual asks you to send the analyzer FACTSET 11023,1 to switch it to 8591C.That's a very pretty looking magic number, there. I wonder if there are any more of those?So, I bought an EPROM programmer, read out all four EPROMs, pieced them together into one, and opened the shebang up in a hex editor. I searched for FACTSET. I found exactly one hit at address 0007E3E0, in what appeared to be some sort of command data structure. That's not going to do me a whole lot of good, so I converted the magic number 11023 to hex (2B 0F) and searched for that. I got exactly one hit, at address 0001978E. This one appeared to be buried in some instructions as well - more interesting! Off to the disassembler....Right around that address, we find this very interesting piece of code:Code:ROM:0001974C ; =============== S U B R O U T I N E =======================================ROM:0001974CROM:0001974C ; Attributes: bp-based frameROM:0001974CROM:0001974C process_factset: ; CODE XREF: j_process_factsetjROM:0001974CROM:0001974C var_4 = -4ROM:0001974C arg_0 = 8ROM:0001974CROM:0001974C ; FUNCTION CHUNK AT ROM:0001977A SIZE 00000082 BYTESROM:0001974CROM:0001974C link a6,#-2ROM:00019750 move.w d0,(sp)ROM:00019752 bra.s loc_1977AROM:00019752 ; End of function process_factsetROM:00019752ROM:00019754ROM:00019754 ; =============== S U B R O U T I N E =======================================ROM:00019754ROM:00019754ROM:00019754 update_bff6: ; CODE XREF: process_factset+3CpROM:00019754 ; process_factset+4Cp ...ROM:00019754 btst #0,9(a6)ROM:0001975A beq.s loc_19768ROM:0001975C move.w ($FFFFBFF6).w,d6ROM:00019760 move.w -4(a6),d0ROM:00019764 bset d0,d6ROM:00019766 bra.s loc_19774ROM:00019768 ; ---------------------------------------------------------------------------ROM:00019768ROM:00019768 loc_19768: ; CODE XREF: update_bff6+6jROM:00019768 move.w ($FFFFBFF6).w,d0ROM:0001976C move.w -4(a6),d6ROM:00019770 bclr d6,d0ROM:00019772 move.w d0,d6ROM:00019774ROM:00019774 loc_19774: ; CODE XREF: update_bff6+12jROM:00019774 move.w d6,($FFFFBFF6).wROM:00019778 rtsROM:00019778 ; End of function update_bff6ROM:00019778ROM:0001977A ; ---------------------------------------------------------------------------ROM:0001977A ; START OF FUNCTION CHUNK FOR process_factsetROM:0001977AROM:0001977A loc_1977A: ; CODE XREF: process_factset+6jROM:0001977A subq.l #2,spROM:0001977C cmp.w #$3421,d0ROM:00019780 bne.s loc_1978CROM:00019782 move.w #$A,var_4(a6)ROM:00019788 bsr.s update_bff6ROM:0001978A bra.s loc_197F4ROM:0001978C ; ---------------------------------------------------------------------------ROM:0001978CROM:0001978C loc_1978C: ; CODE XREF: process_factset+34jROM:0001978C cmp.w #$2B0F,d0ROM:00019790 bne.s loc_1979CROM:00019792 move.w #9,var_4(a6)ROM:00019798 bsr.s update_bff6ROM:0001979A bra.s loc_197F4ROM:0001979C ; ---------------------------------------------------------------------------ROM:0001979CROM:0001979C loc_1979C: ; CODE XREF: process_factset+44jROM:0001979C cmp.w #$2B44,d0ROM:000197A0 bne.s loc_197ACROM:000197A2 move.w #$E,var_4(a6)ROM:000197A8 bsr.s update_bff6ROM:000197AA bra.s loc_197F4ROM:000197AC ; ---------------------------------------------------------------------------ROM:000197ACROM:000197AC loc_197AC: ; CODE XREF: process_factset+54jROM:000197AC cmp.w #$30E,d0ROM:000197B0 bne.s loc_197BAROM:000197B2 move.w arg_0(a6),($FFFF9FBC).wROM:000197B8 bra.s loc_197F4ROM:000197BA ; ---------------------------------------------------------------------------ROM:000197BAROM:000197BA loc_197BA: ; CODE XREF: process_factset+64jROM:000197BA cmp.w #$30F,d0ROM:000197BE bne.s loc_197C8ROM:000197C0 move.w arg_0(a6),($FFFF9FBE).wROM:000197C6 bra.s loc_197F4ROM:000197C8 ; ---------------------------------------------------------------------------ROM:000197C8ROM:000197C8 loc_197C8: ; CODE XREF: process_factset+72jROM:000197C8 cmp.w #$310,d0ROM:000197CC bne.s loc_197D6ROM:000197CE move.w arg_0(a6),($FFFF9FC0).wROM:000197D4 bra.s loc_197F4ROM:000197D6 ; ---------------------------------------------------------------------------ROM:000197D6ROM:000197D6 loc_197D6: ; CODE XREF: process_factset+80jROM:000197D6 cmp.w #$311,d0ROM:000197DA bne.s loc_197E4ROM:000197DC move.w arg_0(a6),($FFFF9FC2).wROM:000197E2 bra.s loc_197F4ROM:000197E4 ; ---------------------------------------------------------------------------ROM:000197E4ROM:000197E4 loc_197E4: ; CODE XREF: process_factset+8EjROM:000197E4 cmp.w #$44,d0 ; 'D'ROM:000197E8 bne.s loc_197F4ROM:000197EA move.w #6,var_4(a6)ROM:000197F0 bsr.w update_bff6ROM:000197F4ROM:000197F4 loc_197F4: ; CODE XREF: process_factset+3EjROM:000197F4 ; process_factset+4Ej ...ROM:000197F4 unlk a6ROM:000197F6 movea.l (sp)+,a0ROM:000197F8 addq.l #2,spROM:000197FA jmp (a0)ROM:000197FA ; END OF FUNCTION CHUNK FOR process_factsetThis code appears to take two arguments, where one is compared with several 'magic numbers' and the other is then either compared with zero to set/clear a bit or is directly written to a memory location. After some experimentation, it became clear that this code is definitely called by the factset command somehow. This is what these magic numbers do:FACTSET 13345,1 sets a bit in NVRAM with unknown effectFACTSET 11023,1 sets the analyzer to C seriesFACTSET 11076,1 sets the analyzer to L seriesFACTSET 782,n sets the FM demod zero to nFACTSET 783,n sets the FM demod slope to nFACTSET 784,n sets the FM demod narrow bw setting to nFACTSET 785,n sets the FM demod wide bw setting to nFACTSET 68 sets a bit in NVRAM with unknown effectThe memory addresses that 782-785 write to correspond with NVRAM registers for the FM demodulator. I do not know why FACTSET can access them, I presume it is for calibration or debugging, but these commands do not appear in the calibration guide. Searching on the addresses eventually yielded the corresponding strings where the values are displayed in the 'cal data' screens. Two of the bits that FACTSET can change in location FFFFBFF6 have unknown functions, while two of them change the analyzer to C or L series.None of this has anything to do with the gate module, though! Or does it? Hmm....Next step is to search for what is displayed when the gate is enabled - "GATE rev B"

author: rastro
author_rank: Frequent Contributor
timestamp: April 08, 2014, 02:45:20 am
content: This might be of interest:http://www.home.agilent.com/agilent/techSupport.jspx?cc=US&lc=eng&nid=-536902970.536880671.08&pid=1000002152%3Aepsg%3Apro&pageMode=DFRastro

author: alex.forencich
author_rank: Frequent Contributor
timestamp: April 08, 2014, 03:43:56 am
content: Whoops, sorry about the double post. Not sure how that got posted twice.

author: Ron Curry
author_rank: Contributor
timestamp: August 28, 2016, 02:28:50 am
content: Has anyone made any progress on this? Anyone dumped the NVRAM?Cheers,Ron

author: MarkL
author_rank: Unknown
timestamp: August 28, 2016, 06:27:44 pm
content: Quote from: Ron Curry on August 28, 2016, 02:28:50 amI've dumped the NVRAM on a 8595E. Attached below; have at it. Let us know if you find anything interesting.This dump was obtained by removing the NVRAM (SRAM) card and reading it out with an external processor (Silabs C8051F581). Perhaps it's possible, but I couldn't find a way to do it with the native firmware.My goal was to transfer the EMC personality which was loaded into the NVRAM to another 8595E which had the quasi-peak detector hardware. I was unsuccessful with this approach but eventually found a way to do it via GPIB.One useful thing I found on my journey was the undocumented "SERSET nnn" command which can be used to change the serial number. If your NVRAM battery goes dead, you lose the cal contants AND the serial number. This can be used to restore the SN.Possibly useful info for anyone else wanting to dump their NVRAM the hard way: The connector to mate with the board is a Molex 15-92-2050. And be careful since the battery power is present on one of the connector pins.

author: dfnr2
author_rank: Regular Contributor
timestamp: September 06, 2016, 08:42:06 pm
content: Quote from: MarkL on August 28, 2016, 06:27:44 pmCould you write up the procedure here? I have an 8594E with opt 119 and the noise figure measurement personality installed, but I don't have the original noise figure personality card. It would be great to be able to safely back it up.

author: AlanG
author_rank: Newbie
timestamp: September 07, 2016, 01:31:12 am
content: +1 - if you need any further encouragement

author: rastro
author_rank: Frequent Contributor
timestamp: September 07, 2016, 02:26:35 pm
content: Additional Info...Verified to work on rev: 950308Enable Gate Option 105:1) Press Frequency -2001 Hz2) Press Cal, More 1 of 4, More 2 of 43) Press Service Cal, Flatness Data, More4) Press top softkey (not labeled)5) Press ExitTo verify Install:press Config, More 1 of 3, Show Options

author: MarkL
author_rank: Unknown
timestamp: September 07, 2016, 05:55:41 pm
content: Quote from: dfnr2 on September 06, 2016, 08:42:06 pmWell, it's not a straightforward procedure, unfortunately. But I'll give it shot.Let me caveat all this by first saying it worked on a 8595E (maybe it was a 8591E?) loaded with the EMC personality. I don't have the EMC card itself to double check, but everything seemed to work fine after being transplanted to a second 8595E that had the quasi-peak HW installed.One thing missing, however, are the various EMC limit profiles which are loaded by the DLPs directly from the card. Since I don't have the card, manual entry of the profiles is needed. I don't know if Noise Figure and other personality cards have the same issue.Also, I did this a couple of years ago, so hopefully I got it right.In a nutshell, everything the card loads is visible via GPIB commands but they are scattered throughout different storage types. The procedure is to get a directory of all of them, retrieve them one-by-one, and then push them back into the target.I'll point out there is a command call "USTATE?" which appears to dump everything in the SA, including what was loaded by the card. In theory I think it can be used to transplant the personality, but I couldn't get it to work. I think something was wrong with the format of the dump I captured. Pushing it into the target always failed. Perhaps someone else can try with better luck.To do it piecemeal like I did, you would first use the "cat" command to get a directory list of everything. The EMC card created ACTDEFs, DLPs. KEYs, and TRs.cat d* <-- includes dlps, actdefs, and keyscat t* <-- includes traces and variablesThere are other "cat" commands for other storage types which other cards may use (cat on*, cat prefix*, etc). See the programmer manual for the full list. You may need more than what I used.From the "cat" output above you then sort out what's what. The output is minimal with each item name and the length in bytes. As you retrieve individual items it's a good idea to always sanity check the number of bytes received against the length reported by cat.For cat d*:- KEYCMDs and KEYLBLs are tagged with "KEY#nnn". Both the KEYDEF and the KEYCMD must be retrieved for each KEY entry. This is done with the commands (nnn is the key number):keydef nnn?keycmd nnn?- DLPs and ACTDEFs are co-mingled. Retrieve everything with (xxx is the name):xxx?Compare the length of the item returned against the length reported by cat. If it's wrong, it's an ACTDEF. Retrieve ACTDEFs with:actdef xxx?For cat t*:Both variables and traces are retrieved with:xxx?If the returned value is in A-block format (see programmer manual), it's a trace. Otherwise, it's a scalar variable. I can imagine other cards could also store vectors in addition to traces. They should show up here too in A-block format.Ok, so now you have a pile of ACTDEFs, DLPs. KEYCMDs, and variables, and traces. How to get them into another analyzer?ACTDEFs: They can be pushed back in the exact same format that they were read out. The readout includes the "ACTDEF" command, and the value is in A-block format. (Note: In fact, much of the data retrieved in the preceeding commands is in A-block format so you need to do everything with an 8-bit clean path.)DLPs: Recreate using "FUNCDEF xxx,yyy" where xxx is the name and yyy was the definition.Variables: If the variable retrieved is in A-block format, it's a vector and restored as a trace (below). Otherwise it's a scalar. Recreate scalars using "VARDEF xxx,nnn" where nnn is the value.Traces: Recreate by reading into trace C with "TRCyyy". Then define the target trace with "TRDEF xxx,401", and move trace C to the target with "MOV xxx,TRC".KEYs are complicated. You will find that for each key number, a KEYDEF and a KEYCMD exists, AND they are different, BUT some of the definition overlaps in memory, so you can't use both. How do you know which one to pick?If the KEYCMD retrieval has an A-block, its either a KEYCMD or KEYDEF. If no A-block, then it's a label and recreate with "KEYLBL xxx,yyy" where yyy is from the KEYDEF. That case is easy.If the definition has two commands in it, it's a KEYCMD. Recreate with "KEYCMD xxx,yyy". If a single command it's a KEYDEF. Recreate with "KEYDEF xxx,yyy". If the definition of the KEYDEF of the same number as the KEYCMD also has a label associated with it, recreate the label with "KEYLBL xxx,yyy" where yyy is the label from the KEYDEF readout.That should be it. It seems likely I did a "DISPOSE ALL" on the target to make sure it was clean before pushing the new definitions at it.I never said it was simple. HP's crazy formats and inconsistencies in the command parser doesn't help.The EMC card loaded 3 ACTDEFs, 103 KEYCMD/KEYDEFs, 118 trace/variables, and 118 DLPs into memory. The procedure is not something you want to do by hand.I have a pile of perl and bash scripts written for linux that calls linux-gpib that does what I've described above. Some hand tweaking of the data was also needed. This was a one-shot use for me, so I never finished it to be generalized. If there's any interest I can post it with the expectation that it's a guideline for someone who wants to do a real implementation. There was one eevblog member who was interested in doing this, but other priorities indicated it would be months away.I'll say again that the "USTATE?" command has promise to replace all this nonsense. It bothers me I couldn't figure out why it wouldn't work.

author: Ron Curry
author_rank: Contributor
timestamp: September 08, 2016, 05:34:08 pm
content: Quote from: MarkL on August 28, 2016, 06:27:44 pmMark,Thanks! That's awesome. I just finished building something similar using an Arduino Mega board (LOTS of I/O pins) but haven't had time to get back to analyzing the data yet. I couldn't find the exact connector without waiting a few weeks so I created my own by cutting off the card edge of an old PCIe card. Unfortunately, in my checking for fit, I must have shorted the battery and corrupted the card. Hence the need for the serial number info. The good news is I have another 8595E and now, your dump to compare against. Reality is though, now that I have both the info to enable option 105 and fix the serial number from the front panel, my need to dig through the RAM is now only curiosity!Thanks again,Ron

author: MarkL
author_rank: Unknown
timestamp: September 08, 2016, 06:49:57 pm
content: Quote from: Ron Curry on September 08, 2016, 05:34:08 pmYou're welcome but sorry to hear you lost your NVRAM. Hopefully you had your cal constants backed up!I needed more pins on the SiLabs part (oops), so I had to do the readout in two banks, and for even/odd.I found digging into the NVRAM/SRAM contents to be fairly frustrating. I had written some programs that helped me search for items and begin to parse sections of HP's storage structures, but it got increasingly messy with more and more dangling pointers into more rat holes to try to decode. There was a diminishing possibility that I was going to be able to filter out what belonged to the EMC personality.And I wasn't in the mood to start disassembling the OS. Really. How much time was I going to burn on this.Looking at it with "strings -a" is probably as useful as it's going to get.One plus is that the SRAM reader provided me with a full backup of the unit. If I totally blew it, I could always code-up the SRAM writer and restore the state of the SA down to the last byte.

author: Ron Curry
author_rank: Contributor
timestamp: September 19, 2016, 03:29:32 am
content: Quote from: MarkL on September 07, 2016, 05:55:41 pmHi Mark,I'd be interested if you could post or send me the scripts. Also which GPIB card did use. I'm wondering if one could do the same thing over serial if the SA had a serial card in it?Thanks,Ron

author: MarkL
author_rank: Unknown
timestamp: September 20, 2016, 12:28:36 am
content: Quote from: Ron Curry on September 19, 2016, 03:29:32 amHi Ron,I have an NI-PCI card, but I have no reason to believe it wouldn't work with any card supported by linux-gpib. I've never tried a serial card, so I'm not familiar with its capabilities or if it's 8-bit clean.I put a copy of my working directory for that project here:http://www.employees.org/~markl/gpib-dlp-poc.tgzPlease consider it a "proof of concept" and not even close to something that's complete enough for routine use. Since this thread is already dedicated to SA hacking, feel free to post questions or findings back here.In the tar file there's a notes/ directory with a couple of messages from me re-telling the procedure in answer to some PM's, and how to run the command scripts. (Edited slightly to be anonymous and fix a couple of links.)You will also need the perl wrapper:http://www.employees.org/~markl/gpib-perl-v0.3a.tgzThis is a generic set of programs that allows commands and queries to GPIB instruments from bash (has nothing specific to do with DLPs). It may be of interest to hard-core unix users beyond what we're doing here. There's a README on how to set it up.Let us know if you come up with anything!EDIT: Clarify perl wrapper stuff.

author: Ron Curry
author_rank: Contributor
timestamp: September 20, 2016, 05:14:26 pm
content: Mark,Thanks for making that info available. The reason why it came up is I found that one of my 8591E's has the EMC personality loaded but I'm parting the unit out and want to load the personality on my personal 8595E along with the QPD card. I do have the card for the QPD drivers but not the EMC personality (I have the empty case for it though!).On idea I came up with is to simply do a dump of the 8591E NVRAM card and load that to my 8595E NVRAM card. Reset the serial number, module ID, and attenuator calibration and see what happens. Haven't tried it yet. I may have to abandon my homemade NVRAM card connector for an actual commercial connector though because it seems easy to corrupt the card when plugging and unplugging which causes a lot of extra effort when it happens.Another idea which may or not be more straightforward, is to identify the area in NVRAM where the file system resides and only duplicate that section. In the course of your firmware research, if you've come up with anything that might help with that I'd be interested.Thanks,Ron

author: MarkL
author_rank: Unknown
timestamp: September 20, 2016, 06:03:25 pm
content: Quote from: Ron Curry on September 20, 2016, 05:14:26 pmI almost did this, but I was concerned that were other things that might get set in an empty NVRAM at boot time that would be specific to the model.There's at least one thing like that. It can't tell the difference between a 8595E or 8596E, so once you tell it it's storing that information in the NVRAM.This approach might work, but I would be concerned of unseen consequences on operation.QuoteThis is what I tried to do at first, but I could not discover a nice tidy area where it made a copy of the card. There appears to be separate structures set up to store DLPs, ACTDEFs, variables, etc. Once the card is read in, the various items are scattered throughout memory. I don't think it's using an in-memory file system.I provided an NVRAM dump a few postings ago. Have a look at it and see if you can discover anything. Maybe I missed something obvious.I think the only way to fully understand what's going on in the NVRAM is to disassemble the OS and trace how the OS is using it. It may even take a logic analyzer to verify execution paths. That was way too much effort for me and I would rather wait for my ebay search to hit on an EMC card first.

author: MarkL
author_rank: Unknown
timestamp: September 20, 2016, 06:29:36 pm
content: Quote from: Ron Curry on September 20, 2016, 05:14:26 pmNo problem - I hope it's useful for you or anyone who is interested.One side note: If your 8591E was purchased as an EM series (or possibly under some other order option as well), it will have a special EM shielded glass over the CRT. The shielded glass will have obvious metalization around the edge and it is a little thicker.If you have it, you might want to move it your 8595E since that's your new EMC analyzer. Also, the bezel is slightly different to accommodate the thicker glass, so that needs to move too.

author: Ron Curry
author_rank: Contributor
timestamp: September 20, 2016, 08:18:33 pm
content: Quote from: MarkL on September 20, 2016, 06:29:36 pmMark,I'll look into that - thx. On a related note. I've been hacking together software on the PC side (Mac in my case) to control the SRAM reader. Right now I have the reader reading and right extended linear Intel Hex. Would rather just do it in binary but getting less and less motivated to dump time into this low priority project. Do you have any software code that controls your reader/writer that you wouldn't mind me leveraging?Thx,ROn

author: MarkL
author_rank: Unknown
timestamp: September 20, 2016, 09:15:04 pm
content: Quote from: Ron Curry on September 20, 2016, 08:18:33 pmHi Ron,The code I have is extremely specific to the Silabs C8051F581 and how it was wired to the NVRAM board. It really won't be of any help. All it did was set the address lines (MA1 - MA17), the bank (LUSERRAM0/LUSERRAM1), and then enable the output (LOE) for each word. Each word was printed on the UART as two hex numbers (xx xx) per line, 8 words per line, like so:41 46 d8 1d bc 1d 7c 05 ab 05 ff 05 d4 05 fb 05b6 05 13 06 d8 05 36 06 a9 05 0f 06 ff 05 27 06e4 05 7e 05 fb 05 13 06 d8 05 26 06 81 05 34 06...The lines sprayed out of the serial port and I captured them into a file with the "cat" command on linux. I then used "xxd -r -p" to turn the ASCII hex into binary. I didn't bother doing Intel format. That's overkill for such a simple goal. Any lost or garbage ASCII hex would be obvious since the exact number of characters that should be received was known.From my notes:LUSERRAM1=low enables the first bank in ascending memory, LUSERRAM0=low enables the second bank.The 68000 is bigendian, so you need to flip the bytes in each word if you want a byte linear representation of the memory.I never did the "writer" part.

author: Ron Curry
author_rank: Contributor
timestamp: September 22, 2016, 05:26:55 pm
content: Quote from: MarkL on September 20, 2016, 09:15:04 pmMark,Thanks for the info. That's pretty much what I'm doing. I'm generating Intel Hex and shooting it out or in. and then streaming to serial on the Mac end. I thought maybe you'd done more than that on the host end. Thanks though!You also answered another question I was just about to ask. I assumed LUSERRAM0 would be at the lower addresses just by convention but I saw in the dump file you posted bank 0 and bank 1 were flipped compared to my dumps. It doesn't really matter much for what we are doing as long as one keeps track of it but is there a particular reason you thought LUSERRAM0 is the higher addressed bank and LUSERRAM1 is lower in the address space? The ROM code would tell me but I haven't dug into that and the address decoder is a PAL on the processor board so no way to tell from the schematics alone. Did you get that from the ROM code or was it just arbitrary?Best regards,Ron

author: Ron Curry
author_rank: Contributor
timestamp: September 22, 2016, 06:57:42 pm
content: Quote from: MarkL on September 20, 2016, 09:15:04 pmAgree. I had a nice library already written so just plugged it in.....

author: MarkL
author_rank: Unknown
timestamp: September 23, 2016, 01:15:27 am
content: Hi Ron,I took a guess based on context. The boundary between LUSERRAM0 going to LUSERRAM1 would look like this if you did it in that order:...00 bf 97 bf 00 bf 97 bf 00 bf 9d bf 00 bf df bf ................00 bf 9c bf 00 bf ce bf 00 bf df bf 00 bf f3 bf ................00 bf bf bf 00 bf af bf 00 bf b1 bf 00 bf ef bf ................00 bf fb bf 00 bf e7 bf 00 bf d0 bf 00 bf f6 bf ................00 bf ff bf 00 bf 9b bf 00 bf ff bf 00 bf ff 07 ................--------------------41 46 d8 1d bc 1d 7c 05 ab 05 ff 05 d4 05 fb 05 AF....|.........b6 05 13 06 d8 05 36 06 a9 05 0f 06 ff 05 27 06 ......6.......'.e4 05 7e 05 fb 05 13 06 d8 05 26 06 81 05 34 06 ..~.......&...4.f3 05 d1 05 45 06 f6 05 43 06 de 05 71 06 06 06 ....E...C...q...a8 05 4a 06 4a 06 d9 05 1c 06 1d 06 eb 05 28 06 ..J.J.........(....The other way, LUSERRAM1 to LUSERRAM0 looks like this:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................--------------------00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................It seemed like it dovetailed together better, that's all. Because I was short pins on the Silabs part, I know I did LUSERRAM0 and LUSERRAM1 separately. I could be wrong, or maybe I had something flipped on the protoboard if you're getting a different order.I agree with you and would have expected LUSERRAM0 to be first too.I found a small C program I wrote that prints out the in-memory directory. I was able to decode the name, type, and the pointer (I think) where it stashed the object. Attached if it's of any use to you.My best guess at the directory structure is this (from my notes, I really don't remember much of the detail anymore):each dir entry appears to be 12 bytesstarts at 004b4cf with _BWST and it seems to go backwardslowest address at 004a344 ("PKZOOM"), maybe lower1 byte name len1 byte type0x10 trace?0x30 func0x40 ? name is PKZOOM0x50 ?0x60 var?4 byte pointername, w/ 0x20 pad to force first char to fall on a word boundaryAnother tidbit is that the SA does store the model number in the SRAM, probably after it figures it out when the NVRAM is empty. It stores it as a big-endian 16-bit integer at 0x7bfee. For example, 8595 is 0x2193. The letter "E" is right after the serial number, and it seems likely this is to differentiate E vs. C models.

author: Ron Curry
author_rank: Contributor
timestamp: September 23, 2016, 04:52:06 pm
content: Hi Mark,Cool stuff!I can't make a strong case for either way on the bank selects. I assumed LUSERRAM0 was lower address and when I did a dump there was a bunch of stuff starting at address 0 that seemed consistent with so many other embedded systems I've reversed engineered and assumed I had it correct. Another reason for my assumption is the first 16 bits seems like it might be a checksum of some sort so it can quickly tell if RAM has become corrupted because it seems to change every time I make changes on the SA between dumps. However, if that C program was done by someone else then there is at least one more person who agrees with you that it's opposite of my assumption. For our purposes, it may not matter as long as we write stuff back in the correct order.Since I corrupted my card I went ahead and set the model number and serial number via EXECUTE TITLE and then used the the front panel to basically delete everything with the thought of re-initializing the card so I could see what got cleared and what stayed. Both banks are mostly zeroed out with some areas filled with what looks like 16 or 24bit repeating values. Some areas stayed the same of course but they both are mostly cleared LUSERRAM1 more so than LUSERRAM0. There is darned little else! I'm going to try writing your data to my card and determine if that gives me the EMC stuff (I assume your SA has EMC personality installed - let me know if I'm wrong). I want to see if I can get that working before I risk corrupting the 8591E EMC unit I have.BTW, based on the EMC info you wrote about I checked and the 8591E I have is a factory EMC unit with the thick glass over the CRT etc. - Thanks for that!I'll let you know what else I find out.Best regards,Ron

author: MarkL
author_rank: Unknown
timestamp: September 23, 2016, 06:40:03 pm
content: Quote from: Ron Curry on September 23, 2016, 04:52:06 pmIf the dump of your SRAM has stuff in the front too and not 0's, it seems more likely I got LUSERRAM backwards. In that case, I at least hopefully re-assembled the binary correctly.QuoteThe EMC personality is in there. But of course with my cal constants.I have two 8595E and one 8591E. The EMC personality was in the 8591E which also had the QPD card in it. You're in the exact same situation that I was.I should note that the SRAM dump was from the 8595E after I moved the QPD card and reloaded the EMC personality via GPIB. I also have a copy of the 8591E SRAM dump which I've attached. I'm including it in case I messed something up when re-creating the EMC personality on the 8595E. The 8591E dump is untouched from when I originally received the unit as an 8591EM.The program was done by me and it works against the 8591E dump, which is where I started this project. I just tried it on the 8595E dump for the first time and it doesn't have the start of the directory right in addition to some other issues. The directory is probably dynamically allocated.Keep us posted on how it turns out!

author: Ron Curry
author_rank: Contributor
timestamp: September 27, 2016, 05:23:12 am
content: Mark,Thanks for that! My 8591E EMC had the QPD card as well but I moved that to my 8595E which is now has a fully loaded card cage and includes a TG. I've been busy on higher priority stuff the last week but I plan to do some more experimenting later this week..Cheers,Ron

author: Bicurico
author_rank: Super Contributor
timestamp: March 21, 2019, 06:52:25 pm
content: Quote from: rastro on September 07, 2016, 02:26:35 pmJust to confirm that this worked on spot on my HP 8594E!Now I have to figure out what this option actually does...Regards,Vitor

author: MarkL
author_rank: Unknown
timestamp: March 21, 2019, 07:30:43 pm
content: Quote from: Bicurico on March 21, 2019, 06:52:25 pmYou might find this enlightening: "Time-Gated Spectrum Analysis: New Measurement Fundamentals" :http://literature.cdn.keysight.com/litweb/pdf/5952-3685.pdfEverything you ever wanted to know about option 105.

author: Bicurico
author_rank: Super Contributor
timestamp: March 21, 2019, 08:57:12 pm
content: Thanks!I found that, too, shortly after posting the question.But I have a new question: obviously my unit lacks the GATE INPUT and OUTPUT connectors on the rear. Do you know if I can retrofit them? Where would I need to hook them up? I saw some empty connectors on the inside...And where could I source appropriate connectors and cables?Not that I need this option, but would be nice to do the upgrade properly...Regards,Vitor

author: MarkL
author_rank: Unknown
timestamp: March 21, 2019, 10:07:37 pm
content: Quote from: Bicurico on March 21, 2019, 08:57:12 pmMost (but not all) in this series have the GATE INPUT and GATE OUTPUT built onto the processor board. J500 is GATE OUTPUT and J501 is GATE INPUT. See photo for the location on the bottom of the unit. If it's not marked, J501 is the one closer to the edge.The two cables are part numbers 08591-60077 and 08591-60076 if you want to search around for them. But they are just ordinary 50-ohm SMB right angle to BNC jumper cables that you can easily make yourself.

author: Bicurico
author_rank: Super Contributor
timestamp: March 21, 2019, 10:55:15 pm
content: Thanks! With your part numbers I found the installation manual:http://literature.cdn.keysight.com/litweb/pdf/5967-8554.pdf

author: Bicurico
author_rank: Super Contributor
timestamp: March 21, 2019, 11:12:31 pm
content: Here how to enable/disable the 001 option (75 Ohm): "Opt 001 75 W Input (HP 8590L only)"Enabled = 75 Ohm RF InputDisabled= 50 Ohm RF InputI have not tested this (is not even available for my model), but got these from the Keysight forum. This is useful in case the RAM contents are lost. If you have a 75 Ohm device, it would default to 50 Ohm and CAL would fail.Enable 75 Ohm:PresetFrequency -2001 HzAmplitude, More 1 of 2Input Z 75-ohmAmplitude, Scale Log Lin (Log), More 1 of 2 Amptd Units dBmVAmplitude, Scale Log Lin (Lin), More 1 of 2 Amptd Units dBmVCal, More 1 of 4, More 2 of 4Service Cal, Stor Pwr On UnitsDisable 75 Ohm - enable default 50 Ohm:PresetFrequency, -2001 HzAmplitude, More 1 of 2, Input Z 50-ohmAmplitude, Scale Log Lin (Log), More 1 of 2 Amptd Units dBmAmplitude, Scale Log Lin (Lin), More 1 of 2 Amptd Units dBmCal, More 1 of 4, More 2 of 4, Service Cal, Stor Pwr On UnitsRegards,Vitor

author: Bicurico
author_rank: Super Contributor
timestamp: March 21, 2019, 11:14:26 pm
content: I am now wondering if there are more "secret" key codes to activate other options...What about firmware upgrades?

author: MarkL
author_rank: Unknown
timestamp: March 22, 2019, 12:15:14 am
content: Quote from: Bicurico on March 21, 2019, 11:14:26 pmI'm not aware of any other hidden options like the gated analysis.The firmware is all in EPROM. Here's a document describing the various versions:http://literature.cdn.keysight.com/litweb/pdf/08590-90324.pdfKO4BB has a good collection up to version L:http://www.ko4bb.com/getsimple/index.php?id=download&file=HP_Agilent/HP_859xE_859xE_series_SA_firmware_EPROM.zipThey don't have the latest version M with the Agilent logo (aawww...).

author: Bicurico
author_rank: Super Contributor
timestamp: March 23, 2019, 10:31:31 pm
content: I am looking at the USER MEMORY dump I made using the USTATE? command.I had some strange DLP's installed, which I unfortunately erased while trying to use the USTATE command to upload a backup.Warning: using USTATE without the "?" is used to upload a user memory backup. If that fails (and it will fail in 99.9% of cases), you end up with a fresh deleted user memory.Anyway, I think I had some calibration/support/service personality installed on my device and there are interesting passages in the DLP:Here one program to check some fault:Code:IP;CF-2001HZ;CAL FREQ;MOV S_TAT,STB?;IF S_TAT,GT,0,THENCLRDSP;BLANK TRA;GRAT OFF;ANNOT OFF;MENU 0;PU;PA,100,100;TEXT%CAL. FREQ. **FAILED**%;PU;PA,100,90 ;TEXT%---------------------%;PU;PA,100,60 ;TEXT%PRESS  %;PU;PA,100,50 ;TEXT%PRESS ,-2001Hz,%;PU;PA,100,40 ;TEXT%& ,CAL FREQ. %;PU;PA,100,30 ;TEXT%...TO ISOLATE PROBLEM%;ABORT;ENDIF;CAL AMP;MOV S_TAT,STB?;IF S_TAT,GT,0,THENCLRDSP;BLANK TRA;GRAT OFF;ANNOT OFF;MENU 0;PU;PA,100,80;TEXT%CAL. AMP. **FAILED**%;PU;PA,100,70;TEXT%--------------------%;PU;PA,100,50 ;TEXT%PRESS  %;PU;PA,100,40 ;TEXT%PRESS ,-2001Hz,%;PU;PA,100,30 ;TEXT%& ,CAL AMP. %;PU;PA,100,20 ;TEXT%...TO ISOLATE PROBLEM%;ABORT;ENDIF;CAL STORE;Notice the "IP;CF-2001HZ;CAL FREQ;" this must be the key sequence to do all sort of weird stuff...Take a look at this thread, too:https://www.eevblog.com/forum/testgear/hp8590e-series-option-103-driver/I will continue to write about hacking the device here...Regards,Vitor

author: Bicurico
author_rank: Super Contributor
timestamp: March 23, 2019, 11:38:58 pm
content: I *think* I managed to rebuild the installed software, which I lost.Code:KEYDEF 101,W_ARM,%Warm Up |859x%;KEYDEF 102,C_PU,%CPU Pre-|Test%;KEYDEF 103,S_CAP,%Super |Cap%;KEYDEF 104,M_EAS,%Measure |Test%;KEYDEF 105,I_NIT,%Init |Test%;KEYDEF 106,R_EVDATE,%DLP |Revision%;FUNCDEF S_TIME,@I_NIT;S_CAP;M_EAS;MENU 1;@;FUNCDEF M_EAS,@C_HECK;S_TIME;E_LAPSE;C_AL;D_ONE;MENU 1;@;FUNCDEF C_HECK,@MOV C_LOCK,HAVE CNT;IF C_LOCK,GT,0,THEN;IP;CF-2001HZ;CAL FREQ;MOV S_TAT,STB?;IF S_TAT,GT,0,THENCLRDSP;BLANK TRA;GRAT OFF;ANNOT OFF;MENU 0;PU;PA,50,190;TEXT% PRE WARM-UP CAL. CHECK%;PU;PA,50,180;TEXT% ----------------------%;PU;PA,100,110;TEXT% --------------------- %;PU;PA,100,100;TEXT%|CAL. FREQ. **FAILED**|%;PU;PA,100,90 ;TEXT% ---------------------%;PU;PA,100,60 ;TEXT%PRESS  %;PU;PA,100,50 ;TEXT%PRESS ,-2001Hz,%;PU;PA,100,40 ;TEXT%& ,CAL FREQ. %;PU;PA,100,30 ;TEXT%...TO ISOLATE PROBLEM%;PU;PA,50,140;TEXT%$$$$ WARM-UP WAS NOT DONE $$$$%;ABORT;ENDIF;CAL AMP;MOV S_TAT,STB?;IF S_TAT,GT,0,THENCLRDSP;BLANK TRA;GRAT OFF;ANNOT OFF;MENU 0;PU;PA,50,190;TEXT% PRE WARM-UP CAL. CHECK%;PU;PA,50,180;TEXT% ----------------------%;PU;PA,100,90;TEXT% -------------------- %;PU;PA,100,80;TEXT%| CAL. AMP. **FAILED**|%;PU;PA,100,70;TEXT% --------------------%;PU;PA,100,50;TEXT%PRESS  %;PU;PA,100,40;TEXT%PRESS ,-2001Hz,%;PU;PA,100,30;TEXT%& ,CAL AMP. %;PU;PA,100,20;TEXT%...TO ISOLATE PROBLEM%;PU;PA,50,140;TEXT%$$$$ WARM-UP WAS NOT DONE $$$$%;ABORT;ENDIF;CAL STORE;ENDIF;@;FUNCDEF C_AL,@IP;CF-2001HZ;CAL FREQ;MOV S_TAT,STB?;IF S_TAT,GT,0,THENCLRDSP;BLANK TRA;GRAT OFF;ANNOT OFF;MENU 0;PU;PA,100,100;TEXT%CAL. FREQ. **FAILED**%;PU;PA,100,90 ;TEXT%---------------------%;PU;PA,100,60 ;TEXT%PRESS  %;PU;PA,100,50 ;TEXT%PRESS ,-2001Hz,%;PU;PA,100,40 ;TEXT%& ,CAL FREQ. %;PU;PA,100,30 ;TEXT%...TO ISOLATE PROBLEM%;ABORT;ENDIF;CAL AMP;MOV S_TAT,STB?;IF S_TAT,GT,0,THENCLRDSP;BLANK TRA;GRAT OFF;ANNOT OFF;MENU 0;PU;PA,100,80;TEXT%CAL. AMP. **FAILED**%;PU;PA,100,70;TEXT%--------------------%;PU;PA,100,50 ;TEXT%PRESS  %;PU;PA,100,40 ;TEXT%PRESS ,-2001Hz,%;PU;PA,100,30 ;TEXT%& ,CAL AMP. %;PU;PA,100,20 ;TEXT%...TO ISOLATE PROBLEM%;ABORT;ENDIF;CAL STORE;@;FUNCDEF E_LAPSE,@MENU 0;REPEATMOV T_REG,TIMEDATE;MOV T_IME,T_REG;DIV T_IME,T_IME,10000000000;MOV Y_EAR,T_IME;INT Y_EAR,Y_EAR;MOV T_IME,T_REG;DIV T_IME,T_IME,100000000;MOV M_ONTHS,T_IME;MPY Y_EAR,Y_EAR,100;SUB M_ONTHS,M_ONTHS,Y_EAR;INT M_ONTHS,M_ONTHS;MOV T_IME,T_REG;DIV T_IME,T_IME,1000000;MOV D_AYS,T_IME;MPY Y_EAR,Y_EAR,100MPY M_ONTHS,M_ONTHS,100;ADD T_EMP,M_ONTHS,Y_EAR;SUB D_AYS,D_AYS,T_EMP;INT D_AYS,D_AYS;MOV T_IME,T_REG;DIV T_IME,T_IME,10000;MOV H_OUR,T_IME;MPY Y_EAR,Y_EAR,100MPY M_ONTHS,M_ONTHS,100;MPY D_AYS,D_AYS,100;ADD T_EMP,M_ONTHS,Y_EAR;ADD T_EMP,D_AYS,T_EMP;SUB H_OUR,H_OUR,T_EMP;INT H_OUR,H_OUR;MOV H_REG,H_OUR;MOV T_IME,T_REG;DIV T_IME,T_IME,100;MOV M_IN,T_IME;MPY Y_EAR,Y_EAR,100MPY M_ONTHS,M_ONTHS,100;MPY D_AYS,D_AYS,100;MPY H_REG,H_REG,100;ADD T_EMP,M_ONTHS,Y_EAR;ADD T_EMP,D_AYS,T_EMP;ADD T_EMP,H_REG,T_EMP;SUB M_IN,M_IN,T_EMP;INT M_IN,M_IN;MOV T_IME,T_REG;MOV S_EC,T_IME;MPY Y_EAR,Y_EAR,100MPY M_ONTHS,M_ONTHS,100;MPY D_AYS,D_AYS,100;MPY H_REG,H_REG,100;MPY M_IN,M_IN,100;ADD T_EMP,M_ONTHS,Y_EAR;ADD T_EMP,D_AYS,T_EMP;ADD T_EMP,H_REG,T_EMP;ADD T_EMP,M_IN,T_EMP;SUB S_EC,S_EC,T_EMP;INT S_EC,S_EC;IF I_NDEX,EQ,0 THENMOV S_REG,S_EC;PU;PA,95,40;TEXT%ELAPSE= %;PA,175,40;TEXT% MINUTES%;PU;PA,135,30;TEXT%& %;PA,175,30;TEXT% SECONDS%;MOV S_aveDa,DA;PU;PA,158,40;DSPLY,M_CNT,2.0;PU;PA,158,30;DSPLY,S_CNT,2.0;ADD I_NDEX,I_NDEX,1;ENDIF;IF S_REG,NE,S_EC THENADD S_CNT,S_CNT,1;MOV S_REG,S_EC;ENDIF;IF S_CNT,EQ,60,THENSUB S_CNT,S_CNT,60;ADD M_CNT,M_CNT,1;ENDIF;MOV L_astDa,DA;MOV DA,S_aveDa;PU;PA,158,40;DSPLY,M_CNT,2.0;PU;PA,158,30;DSPLY,S_CNT,2.0;MOV DA,L_astDa;{ds_sync()};UNTIL (M_CNT >= W_RMUP);CLRDSP;@;FUNCDEF I_NIT,@IP;CF-2001HZ;CAL INIT;CAL FETCH;CAL STORE;TS;BAUDRATE9600;KSP18;PLOTADRS5;PSTATE0;PREFX%%;VARDEF _PRT;VARDEF _CLR;PRNTADRS1;PLT0;CRTVPOS20;CRTHPOS8;KS<0;IP;POWERON IP;IP;CF-2001HZ;INZ 50;AUNITS DBM;LN;AUNITS V;LG;CAL UNITS;TS;CF-2001HZ;CAL TIMEBASE 128;CF-2001HZ;CALATNDATA 0,0,0,0,0,PREAMPG 0;AMPCOR 30GHZ, 0DB;AMPCOR OFF;GRAT OFF;ANNOT OFF;BLANK TRA;MENU 0;PU;PA 100,115;TEXT% INITIALIZATION COMPLETE %;PU;PA 100,105;TEXT%============================%;PU;PA 100,95;TEXT%- DEFAULT CAL DATA LOADED %;PU;PA 100,85;TEXT%- TIMEBASE DEFAULTED TO 128 %;PU;PA 100,75;TEXT%- CAL ATTEN DEFAULTED TO 0'S %;PU;PA 100,65;TEXT%- PRE-AMP GAIN DEFAULTED TO 0'S %;PU;PA 100,55;TEXT%- AMP CORRECTION DEFAULTED TO 0'S %;WAIT 2;IP;MENU 1;@;FUNCDEF R_EVDATE,@GRAT OFF;ANNOT OFF;BLANK TRA;MENU 0;PU;PA 50 185;TEXT% LASTEST DLP REV. DATE: 01/12/97%;PU;PA 50,60;TEXT% PRESS ENTER AFTER VIEWING%;HD;EP;MPRST;MN1;@;FUNCDEF S_CAP,@$;ANNOT OFF;GRAT OFF;BLANK TRA;CLRDSP;MN0;CSIZE 1,1;PU;PA; 200, 50;PD;PR;110,70;90,0;0,-70;-25,0;0,-15;25,0;0,-40;-200,0;0;55;PU;10,-50;TEXT%o%;PU;150,100;TEXT%o%;DRAWBOX 250, 35, 265, 25,5,5;CSIZE;PU;PA; 125, 135;PD;PR;55,0;70,-100;4,10;-4,-10;-15,5;PU;PA;120,200;TEXT%Verify Super-Cap Voltage%;PU;PA;120,190;TEXT%========================%;PU;PA;-10,170;TEXT%- Lift the edge of the shield on%;PU;PA;-10,160;TEXT% the memory board.%;PU;PA;-10,150;TEXT%- Touch the test fixture probe to%;PU;PA;-10,140;TEXT% the square pad of C1 on the%;PU;PA;-10,130;TEXT% memory board.%;PU;PA;-10,120;TEXT%- The LED in the%;PU;PA;-10,110;TEXT% test fixture must%;PU;PA;-10,100;TEXT% light for the board%;PU;PA;-10,90;TEXT% to PASS.%;PU;PA;-10,80;TEXT%- Press ENTER when done.%;HD;EP;MPRST;MN1;@;FUNCDEF D_ONE,@MENU 0;BLANK TRA;ANNOT OFF;GRAT OFF;CLRDSP;PU;PA,100,150;TEXT%WARM-UP DONE%;PU;PA,160,120;TEXT%CAL. FREQ/AMP DONE%;PU;PA,250,25;TEXT%PRESS ENTER TO EXIT%;PU;PA;100,100;PD 100,150;150,150;100,100,100;150,150;100,100,100;150,150;150,100,100,100;PU;EP;IP;MENU 1;ANNOT ON;TITLE%WARM-UP DONE%;ERASE;@;FUNCDEF C_PU,@VARDEF F_FLAG,0;TRDEF TRA_A,401;VARDEF ADC_LO,0;VARDEF ADC_HI,8000;VARDEF F_HI,0;VARDEF F_LO,0;DET GND;TS;MOV ADC_LO,MEAN TRD;PU;PA 150,45;TEXT%ADC GND=%;PU;PA 250,45;DSPLY ADC_LO,5.0;PU;PA300,45;IF ADC_LO,GT,135 THEN TEXT%FAILED%;MOV F_FLAG,1;MOV F_LO,1;ENDIF;PU;PA300,45;IF ADC_LO,LT,45 THEN TEXT%FAILED%;MOV F_FLAG,1;MOV F_LO,1;ENDIF;IF F_LO,EQ,0 THEN TEXT%ok%;ENDIF;DET REF;TS;MOV ADC_HI,MEAN TRD;PU;PA 150,35;TEXT%ADC 2V =%;PU;PA 250,35;DSPLY ADC_HI,5.0;PU;PA 300,35;IF ADC_HI,LT,3430;THEN TEXT%FAILED%;MOV F_FLAG,1;MOV F_HI,1;ENDIF;PU;PA 300,35;IF ADC_HI,GT,3630;THEN TEXT%FAILED%;MOV F_FLAG,1;MOV F_HI,1;ENDIF;IF F_HI,EQ,0 THEN TEXT%ok%;ENDIF;GRAT OFF;BLANK TRA;MENU 0;PU;PA 150,25;TEXT%ENTER DATE:%;DATEMODE MDY;TIMEDSP ON;SETDATE EP;PU;PA 260,25;TEXT%Done%;PU;PA 150,15;TEXT%ENTER TIME:%;SETTIME EP;PU;PA 260,15;TEXT%Done%;IF F_FLAG,EQ,0 THENIP;GRAT OFF;ANNOT OFF;BLANK TRA;MENU 0;PU;PA 50,175;TEXT% ******* CPU PRETEST PASSED ******** %;PU;PA 50,135;TEXT% CYCLE THE POWER %;PU;PA 50,115;TEXT% TO ENSURE THE CPU COMES UP %;PU;PA 50,95;TEXT% WITH THE CORRECT DISPLAY %;ELSEIP;GRAT OFF;ANNOT OFF;BLANK TRA;MENU 0;PU;PA 50,185;TEXT% FAILED ................. %;PU;PA 50,175;TEXT% ............FIX & RETEST %;PU;PA 50,155;TEXT% PRESS ENTER TO EXIT SCREEN %;ENDIF;EP;IP;MENU 1;@;FUNCDEF W_ARM,@GRAT OFF;ANNOT OFF;BLANK TRA;CLRDSP;PU;PA,15,190;TEXT%********** WARM-UP DLP ************%;MOV T_REG,TIMEDATE;MOV T_IME,T_REG;DIV T_IME,T_IME,10000000000;MOV Y_EAR,T_IME;INT Y_EAR,Y_EAR;PU;PA,45,130;TEXT%START TIME= 19%DSPLY Y_EAR,2.0;TEXT% YEAR%;MOV T_IME,T_REG;DIV T_IME,T_IME,100000000;MOV M_ONTHS,T_IME;MPY Y_EAR,Y_EAR,100;SUB M_ONTHS,M_ONTHS,Y_EAR;INT M_ONTHS,M_ONTHS;PU;PA,157,120;DSPLY M_ONTHS,2.0;TEXT% MONTH%;MOV T_IME,T_REG;DIV T_IME,T_IME,1000000;MOV D_AYS,T_IME;MPY Y_EAR,Y_EAR,100MPY M_ONTHS,M_ONTHS,100;ADD T_EMP,M_ONTHS,Y_EAR;SUB D_AYS,D_AYS,T_EMP;INT D_AYS,D_AYS;PU;PA,157,110;DSPLY D_AYS,2.0;TEXT% DAY%;MOV T_IME,T_REG;DIV T_IME,T_IME,10000;MOV H_OUR,T_IME;MPY Y_EAR,Y_EAR,100MPY M_ONTHS,M_ONTHS,100;MPY D_AYS,D_AYS,100;ADD T_EMP,M_ONTHS,Y_EAR;ADD T_EMP,D_AYS,T_EMP;SUB H_OUR,H_OUR,T_EMP;INT H_OUR,H_OUR;MOV H_REG,H_OUR;IF H_OUR,LT,1 THENADD H_OUR,H_OUR,12;SUB A_MPM,A_MPM,1;ENDIF;IF H_OUR,EQ,12 THENADD A_MPM,A_MPM,1;ENDIF;IF H_OUR,GT,12 THENSUB H_OUR,H_OUR,12;ADD A_MPM,A_MPM,1;ENDIF;IF A_MPM,EQ,-1 THENPU;PA,157,100;DSPLY H_OUR,2.0;TEXT% AM%;ENDIF;IF A_MPM,EQ,0 THENPU;PA,157,100;DSPLY H_OUR,2.0;TEXT% AM%;ENDIF;IF A_MPM,EQ,1 THENPU;PA,157,100;DSPLY H_OUR,2.0;TEXT% PM%;ENDIF;MOV T_IME,T_REG;DIV T_IME,T_IME,100;MOV M_IN,T_IME;MPY Y_EAR,Y_EAR,100MPY M_ONTHS,M_ONTHS,100;MPY D_AYS,D_AYS,100;MPY H_REG,H_REG,100;ADD T_EMP,M_ONTHS,Y_EAR;ADD T_EMP,D_AYS,T_EMP;ADD T_EMP,H_REG,T_EMP;SUB M_IN,M_IN,T_EMP;INT M_IN,M_IN;MOV M_REG,M_IN;PU;PA,157,90;DSPLY M_IN,2.0;TEXT% MINUTES%;MOV T_IME,T_REG;MOV S_EC,T_IME;MPY Y_EAR,Y_EAR,100MPY M_ONTHS,M_ONTHS,100;MPY D_AYS,D_AYS,100;MPY H_REG,H_REG,100;MPY M_IN,M_IN,100;ADD T_EMP,M_ONTHS,Y_EAR;ADD T_EMP,D_AYS,T_EMP;ADD T_EMP,H_REG,T_EMP;ADD T_EMP,M_IN,T_EMP;SUB S_EC,S_EC,T_EMP;INT S_EC,S_EC;MOV S_REG,S_EC;PU;PA,157,80;DSPLY S_EC,2.0;TEXT% SECONDS%;@;Sending this up through GPIB will create the menu entries and DLP.I think this is some service/diagnose personality.This shows that one can rebuild most of the stuff from the USTATE? dump. The difficult part is to actually guess the filenames!I'm pretty happy that I got this back to work - for no particular reason.My only doubt is if some DLP or commands within require variables I have not created.I would like to suggest to describe personalities like the above code, as it can be sent to the device with great ease - I think I could use Keysight Interactive IO and just do a COPY&PASTE and it would work.Regards,Vitor

author: Bicurico
author_rank: Super Contributor
timestamp: March 24, 2019, 12:37:29 am
content: https://vma-satellite.blogspot.com/2019/03/vma-simple-spectrum-analyser-hpagilent.html

author: xwarp
author_rank: Frequent Contributor
timestamp: March 24, 2019, 02:27:03 am
content: Quote from: Bicurico on March 21, 2019, 11:12:31 pmI thought that I had read somewhere that there were some components that had to be changed out for the 75 ohm to 50 ohm use.

author: kawal
author_rank: Frequent Contributor
timestamp: April 28, 2019, 04:06:01 pm
content: nice software.I just got a broken 8591A which I managed to repair (power switch was defective). I will try the software you provided. I assume this is over GPIB ?

author: Bicurico
author_rank: Super Contributor
timestamp: April 28, 2019, 06:15:43 pm
content: Yes. And you need to install Keysight Connection Expert 2018.RegardsVitor

author: kawal
author_rank: Frequent Contributor
timestamp: April 28, 2019, 07:16:37 pm
content: do i need to register the software anywhere ? Tried it and asking for a code.

author: the Chris
author_rank: Regular Contributor
timestamp: January 12, 2025, 05:47:31 am
content: Quote from: MarkL on March 21, 2019, 10:07:37 pmI just did the upgrade with third-party cables but could not find any info about the required length so after some guesswork, I ordered a pair of 20cm and 30cm.It turns out, the 20cm will only fit if you take the shortest route from BNC through holes on the backplate to the terminals on the board. While this works with maybe the slightest squash, it kind of feels wrong.Taking the intended route where all other cables are going will require the 30cm cables and they fit just fine with maybe 2cm of reserve which helps in sorting their position in the passage.The amount of space available for the rear end assembly of the BNC terminals is limited and while the ones I bought work fine, it looks wrong so opt for short versions if available.Hope this helps those that seek to implement ready-made cables.