Agilent E7495 linux root account

[9aplus]

Thank you Kirill,
My unit was on approx half OS boot, then went black.
The protection on external PS was safe triggered like short circuit.

Than I loaded battery on separate load rack and try to power on with
battery, the screen went on for the moment, than black again.

Now with all other connectors disconnected from A4A4 on power on
red LED goes on for short blink than protection trigg. again to black.

[kirill_ka]

Now with all other connectors disconnected from A4A4 on power on
red LED goes on for short blink than protection trigg. again to black.

Try holding the red button. This should hold the PIC in reset state, so we know whether it shorts the supply before or after the firmware starts.

[kirill_ka]

The yellow tantalum in the middle of the picture doesn't look good.
Or is it just a shadow?

[TheSteve]

The yellow tantalum in the middle of the picture doesn't look good.
Or is it just a shadow?

It does look like there is a chunk of it missing.

[9aplus]

True, that tantalum is blown... Thank you for remote troubleshooting.   

[9aplus]

So tomorrow morning I am in chase for 10 uF 35V tantalum.
Will report further development when replaced 

[kirill_ka]

Do you have a PIC programmer? Maybe you could download the firmware from your PSU board? I'd like to check if they fixed the SMBus code in newer revisions.

[9aplus]

No PIC programmer at the moment. But can find one when done with this trouble...

Today browse through 3 local shops, some tantalum procured, but not the right one SMD 10 uF 35 V
So trial with:
SMD 4,7uF 50V
or
Pin through 10uF 35V
Must decide after removing of the blown one...

[kirill_ka]

I'd stack two 4,7uF

[9aplus]

Stacking was not feasible operation, therefore classic wire through component replacement.
Unit tested, red LED lit... looks good.

[kirill_ka]

Good. If you'd be so kind to grab the firmware, the programming header (2mm pitch) pinout is as follows:

1. PGD (PIC pin 17)
2. PGC (PIC pin 16)
4. MCLR (PIC pin 18)
6. VDD (PIC pin 7)
8. VSS (PIC pin 6)

Please, double check the connections before trying.
In my E7495A  PIC pin 17 is connected to the header through 10K resistor, so I had to connect the PICkit to the pin 17 directly.
Other than that I had no problems reading the firmware with the board powered off.

[9aplus]

Locally can find only:
"
Vellman VM203
 PICKit™2 Development Programmer is very versatile.
It features on board sockets for many types of PIC® microcontrollers.
Also provided is an ICSP connector, to program your onboard device.
https://www.velleman.eu/downloads/0/modules/usermanual_vm203.pdf
"
On A4A4 ISCP is marked like "PIC PGM PORT J55"
Do you know the layout?

Or you have some tool to clamp on PIC 16F877 directly ?

Do you have any picture how did you manage to read out that PIC 

[kirill_ka]

Locally can find only:
"
Vellman VM203
 PICKit™2 Development Programmer is very versatile.
It features on board sockets for many types of PIC® microcontrollers.
Also provided is an ICSP connector, to program your onboard device.
https://www.velleman.eu/downloads/0/modules/usermanual_vm203.pdf
"

It should work. However, if it's becoming too complex, please, don't waste your time on this.

On A4A4 ISCP is marked like "PIC PGM PORT J55"
Do you know the layout?

Yes, I noted it above. 1. 2. 4. 6. 8. are the pin numbers of J55.

Or you have some tool to clamp on PIC 16F877 directly ?

No.

Do you have any picture how did you manage to read out that PIC 

Unfortunately no, my unit is assembled already. I made an adapter to connect PICkit 3 to the J55. Then I cut the trace  going to J55 pin 1 and added a bodge wire to connect J55 pin 1 directly to the pin 17 of  PIC. That's because I wanted to program it many times. If you do it once, you may just solder wires directly to the pins of PIC16 (U201).

[9aplus]

@kirill ok on all

It seems that my unit will remain open for some time

After reassembly
Power on, green LED ON, no sign on LCD screen, after couple of seconds green LED off
tested on internal BAT and external PS
It seems that some voltages are missing...
The puzzle is that initially with blown tantalum, unit was able to blink LCD powered from BAT...
Possible that I mix some interconnections, but I followed instructions from bellow DOC.

All ideas or experience is more than welcome.

Regarding documentation have only:
Service Guide
Agilent Technologies E7495A/B
Base Station Test Set
Any other available?

To be continued...

[9aplus]

UPDATE:
For sure some voltage was missing, on recheck have find out one grey wire set
routing from A4A4 to CPU A4A1 board not fitted properly.
Now all good.
Unit boot OK
Just must finish assembly to perform proper test

[9aplus]

All in order...
Have used the opportunity to clear the LCD screen, from that black internal seal,
the glue is nasty thing to handle. Some minor damage on lexan remains after cleaning.

Pictured with RLB, procured on line recently for some SDR play.
The price was to good, to be true (45 GPB).
On the end RLB OK, and E7495B OK after all     

Like to thank You all for kind assistance 

[jofre]

can anyone help me with user and web password inteface?

thanks

[ddcc]

I managed to start the remote Gui on my System!

You need the folowing files

Code: [Select]

egclient.jar
JimiProClasses.zip
RemoteGui.jar
xerces.jar

I think it will only work with the OpenJDK Java 6 runtime

You need to change the server and localAddress parameters, the server is the E7495 and localAddress is the IP of your PC.

Code: [Select]

java -Dserver=10.10.0.101 -DlocalAddress=10.10.0.156 -classpath "egclient-patch.jar:xerces.jar:JimiProClasses.zip:RemoteGui.jar" elgato.gui.MainWindow
Some helpful Key kombinations
CTRL-H = Help
CTRL-L = Local (This one is important!)
F1 to F7 =  Menu items on the left side
F9 = Mode Button
1 to 7 = Menu items on the right side

Before you can do anything you have to switch to the local mode on your PC, press CTRL-L to do this.

I picked up an E7495A recently, and have been poking around the Java remote GUI feature. I ended up patching the bytecode in the main v6.25 egclient.jar to fix a couple of annoying bugs, so hopefully this is useful:

• elgato.infrastructure.util.RuntimeConfiguration.isEmbeddedUsingInstance(): This is used to determine if the keypad should be shown in the remote GUI, but it implements this by checking if the runtime system architecture string contains "86". However, on a 64-bit system, the check will fail, and the keypad won't be displayed. I've modified it to check for "arm" instead.
• elgato.infrastructure.util.Platform.createPlatform(): This is used to determine which JVM wrapper should be instantiated, either Skelmir's CEE-J or Sun's JVM, but it implements this by checking if the current JVM version string contains 1.4, 1.5, or 1.6. This is part of the reason why egClient.jar doesn't work with JRE > 6. The other part is that the "CEEJPlatform" is referenced statically, whereas the "Java14Platform" is instantiated dynamically, which can cause a ClassNotFoundException at runtime if the CEE-J runtime classes aren't available. I've modified this by swapping the two so that "CEEJPlatform" is dynamically instantiated, and changed the version check to perform a vendor check instead. This should allow the GUI to work on any modern JRE, though I've only tested with JRE 8.

Link: https://www.dcddcc.com/blog/e7495a/egclient.jar

[ddcc]

So it turns out that on my unit, the spectrum analyzer, signal generator, and two-port insertion loss features seem to work fine, but the one-port insertion loss and return loss measurements give incorrect results. Since there's no block diagram available, I ended up taking apart and reverse engineering the receiver board, shown below. I don't have much previous RF experience, so corrections/suggestions are welcome!

It seems that this unit is a superheterodyne receiver using double conversion, with the 1st LO at 1.5 - 3 GHz, the 2nd LO at ~3 GHz, and a final IF at ~135 MHz. The unit seems to have two separate receiver bands, one for < 2.7 GHz, and the other for 2.7 - 4 GHz ??. There are 2x 5-bit (<= 31 dBm) digital attenuators on the input path, and a 0 - 90 dBm electronic attenuator on the output, although the module seems capable of up to 130 dbm attenuation.



Since this unit is designed for portable operation, the internal cables are short and the assemblies are all stacked on top of one another, making it difficult to probe the receiver board with the unit running. I ended up removing the connection panel and flipping the receiver board, which gave me access to its top side. Since the spectrum analyzer and signal generator features work independently, I'm guessing that the fault probably lies on the feedback path from the source output on to the input path, which runs from the coupler through some filters and SPDT switches (from D to A on the annotated image). Interestingly enough, some rework seems to have already been performed on the filters on this path, probably by the factory?

Next, I plan to probe this path while operating the unit in return loss mode, but this will be a bit tricky because I only have a 100 MHz scope, and no other spectrum analyzers or high-frequency probes. However, I do have a RTL-SDR and a LimeSDR, so I can probably make do, and just need to compile the software stack on my laptop.

[PA0PBZ]

This is the block diagram of the RF part for the N1996A, the bigger brother. It could help because they are very similar.

[9aplus]

@ddcc
Thank You for that picture, during my unit PS repair I was wondering what is inside that box 

Member here Wolfgang made nice FET probe which can be of good use during your repair ->
https://electronicprojectsforfun.wordpress.com/2018/08/03/a-homebrew-fet-probe-to-1-5ghz/

Good luck with the rest of your repair journey.

[ddcc]

Member here Wolfgang made nice FET probe which can be of good use during your repair ->
https://electronicprojectsforfun.wordpress.com/2018/08/03/a-homebrew-fet-probe-to-1-5ghz/

Thanks for the link, looks useful!

This is the block diagram of the RF part for the N1996A, the bigger brother. It could help because they are very similar.

Thanks, I saw the reference to the N1996A earlier in the thread. Some parts are a bit similar; e.g. the four 1st LO filter banks, and two mixers for the 1st and 2nd converters. But otherwise, a lot seems to be different; for example, there doesn't seem to be a 3rd converter, the LO/IF frequencies are different, the attenuator values/positions are different, and the intermediate filters also seem different, although most aren't labeled on the PCB. I'm also not sure why there's a 2.7 - 4 GHz high band on the E7495A, since the instrument is only rated up to 2.7 GHz.

[Wallace Gasiewicz]

Has anyone resolved the GPS lock issue where the yellow triangle stays on and there is no green "lock" on the time/frequency base?

Wally

[technogeeky]

So it turns out that on my unit, the spectrum analyzer, signal generator, and two-port insertion loss features seem to work fine, but the one-port insertion loss and return loss measurements give incorrect results. Since there's no block diagram available, I ended up taking apart and reverse engineering the receiver board, shown below. I don't have much previous RF experience, so corrections/suggestions are welcome!

It seems that this unit is a superheterodyne receiver using double conversion, with the 1st LO at 1.5 - 3 GHz, the 2nd LO at ~3 GHz, and a final IF at ~135 MHz. The unit seems to have two separate receiver bands, one for < 2.7 GHz, and the other for 2.7 - 4 GHz ??. There are 2x 5-bit (<= 31 dBm) digital attenuators on the input path, and a 0 - 90 dBm electronic attenuator on the output, although the module seems capable of up to 130 dbm attenuation.



Since this unit is designed for portable operation, the internal cables are short and the assemblies are all stacked on top of one another, making it difficult to probe the receiver board with the unit running. I ended up removing the connection panel and flipping the receiver board, which gave me access to its top side. Since the spectrum analyzer and signal generator features work independently, I'm guessing that the fault probably lies on the feedback path from the source output on to the input path, which runs from the coupler through some filters and SPDT switches (from D to A on the annotated image). Interestingly enough, some rework seems to have already been performed on the filters on this path, probably by the factory?

Next, I plan to probe this path while operating the unit in return loss mode, but this will be a bit tricky because I only have a 100 MHz scope, and no other spectrum analyzers or high-frequency probes. However, I do have a RTL-SDR and a LimeSDR, so I can probably make do, and just need to compile the software stack on my laptop.

Thanks for posting this. I've been waiting a long time to see this (since my unit doesn't have problems, I didn't want to open it).

Can we also get the same picture without annotations -- for A/B comparison to see your notes?

Also, can we get some shots from a low angle (say, 30 degrees up from the plane of the board) so we can see the size and configuration of RF gaskets and such.

Thanks!

[technogeeky]

So it turns out that on my unit ...  Interestingly enough, some rework seems to have already been performed on the filters on this path, probably by the factory?

I'm like you and I don't have much RF experience, my initial reaction to looking at this picture carefully is that I would be surprised that this is factory rework. Upon reading your comment and looking at the path involved (along with your statements about what works and what doesn't), I think we have a repair attempt.

It looks like all of the reworked items are passives, too.

My first guess would be to check the SPDT switch that comes out on the right side of the board at A.