| Products > Test Equipment |
| Agilent E7495 linux root account |
| << < (64/91) > >> |
| 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 :clap: |
| jofre:
can anyone help me with user and web password inteface? thanks |
| ddcc:
--- Quote from: Urs42 on February 22, 2015, 09:08:27 pm ---I managed to start the remote Gui on my System! You need the folowing files --- Code: ---egclient.jar JimiProClasses.zip RemoteGui.jar xerces.jar --- End code --- 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: ---java -Dserver=10.10.0.101 -DlocalAddress=10.10.0.156 -classpath "egclient-patch.jar:xerces.jar:JimiProClasses.zip:RemoteGui.jar" elgato.gui.MainWindow --- End code --- 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. --- End quote --- 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. |
| Navigation |
| Message Index |
| Next page |
| Previous page |