Agilent E7495 linux root account

[kirill_ka]

Also, I played around with the files in /flash/egServer/Dragonfly/Recievers, like E7495A and CPXSRC. You can indeed change things here and sometimes see the effects (e.g. you can change E7495A to have Freq Range be 3000e6, and it makes it possible to enter that value). However, some of these changes will have no effect for other reasons (here, I assume it's because there is actually a filter which sharply cuts off at ~ 2.7GHz).

Limitations are spread in configs, gui, elgato, dsp code and hardware. I mean along with configs there are many hardcoded values.

[kirill_ka]

Another few questions:

1) Is it possible to keep the power meter reference output on but go back to the spectrum analyzer window, to see it? Apparently this is possible to do with the signal generator, but not with the spectrum analyzer.

There's a separate serial port which is used to communicate with power meter hw. It's closed immediately when you exit the power meter. If I have time, I'll try to decode the protocol.

[PA0PBZ]

Also, I played around with the files in /flash/egServer/Dragonfly/Recievers, like E7495A and CPXSRC. You can indeed change things here and sometimes see the effects (e.g. you can change E7495A to have Freq Range be 3000e6, and it makes it possible to enter that value). However, some of these changes will have no effect for other reasons (here, I assume it's because there is actually a filter which sharply cuts off at ~ 2.7GHz).

Limitations are spread in configs, gui, elgato, dsp code and hardware. I mean along with configs there are many hardcoded values.

If the 7495 is anything like the N1996 (and we have a lot of reasons to believe so) you will not be able to go above 2.7GHz.
The N1996 has 2 receive paths, one for 0.1MHz - 2.7GHz and the other for 2.7GHz to 3/6GHZ. Since the N1996, depending on the model, has an upper limit of 3 or 6GHz both receive paths are there, and that is why you can change the 3GHz model to 6GHz by changing the upper limit value. Since the 7495 goes to 2.7GHz only I assume that the upper part is missing in the 7495. See below the N1996 receive path:

[technogeeky]

Also, I played around with the files in /flash/egServer/Dragonfly/Recievers, like E7495A and CPXSRC. You can indeed change things here and sometimes see the effects (e.g. you can change E7495A to have Freq Range be 3000e6, and it makes it possible to enter that value). However, some of these changes will have no effect for other reasons (here, I assume it's because there is actually a filter which sharply cuts off at ~ 2.7GHz).

Limitations are spread in configs, gui, elgato, dsp code and hardware. I mean along with configs there are many hardcoded values.

If the 7495 is anything like the N1996 (and we have a lot of reasons to believe so) you will not be able to go above 2.7GHz.
The N1996 has 2 receive paths, one for 0.1MHz - 2.7GHz and the other for 2.7GHz to 3/6GHZ. Since the N1996, depending on the model, has an upper limit of 3 or 6GHz both receive paths are there, and that is why you can change the 3GHz model to 6GHz by changing the upper limit value. Since the 7495 goes to 2.7GHz only I assume that the upper part is missing in the 7495. See below the N1996 receive path:

Do you have any idea about extending the range (power) or (frequency) of the signal sources? Also, it seems the N1996A has a zero-span mode. I wonder if this could be enabled on this device. Also, I wonder if we can expose the number of sample points (in fact, I find it downright weird that these aren't at least listed somewhere, let alone adjustable).

[TheSteve]

Do you have any idea about extending the range (power) or (frequency) of the signal sources? Also, it seems the N1996A has a zero-span mode. I wonder if this could be enabled on this device. Also, I wonder if we can expose the number of sample points (in fact, I find it downright weird that these aren't at least listed somewhere, let alone adjustable).

I was able to extend both the power and frequency range of the signal source in a N1996A. The power range difference was only a few dB so I changed it back to stock as the real maximum output varied with frequency. I extended the frequency range down to 1 MHz from 10 MHz. I believe the E7495A has similar text files which can edited however I have read someone tried lowering the source range on an E7495A in the past and it would crash the unit when you tried to enter a lower frequency.

[technogeeky]

2) When I connect a GPS antenna with a good view of the sky, I easily get GPS (bottom left says GPS Locked), location usually shows ~8 satellites tracked, but the GPS icon in the bottom right never goes to the green dot (I've left it tracking for over 24 hours).  It always stays at the yellow triangle.  Because of that, I can't run the Time Base Adjustment (it requires me to wait for the green dot).  Switching to the internal reference shows a green dot, and the frequency accuracy seems pretty good, so I don't think the TCXO is bad.


Also, I noticed that it shows time on the screen, but it never gets set to the correct GPS time (and it appears that the time/date gets reset to the time/date that was set at boot every 30 seconds, even if I manually set it over telnet).  The GPS location looks correct though (drops a dot right on my neighbors house :-P ).

I thought I might have some insight into this problem, but it appears you already noticed what I noticed. The GPS never goes GREEN, it stays at YELLOW TRIANGLE.

I think the problem lies with the time/clock itself. Something is clearly fighting the GPS to reset the clock to some (arbitrary, it seems) earlier value. And I do mean arbitrary. I tried this procedure and I think this pretty well proves something is fighting it:

• Turn on device, connect GPS antenna.
• At any time (but for sake of argument, after you notice at least 5 satellites locked), log into the web interface (port 5000). Click on Date and Time, and tell the device to take the current time of the your computer.
• It will update, but then after about 30 seconds, it will reset to this initial time.
• No matter how long you wait, it will continue to allow you to set the time; but it will always rollback to this 1st clock set.
• You can confirm this by changing the time zone on your host computer. This will set the clock to the same time, but it will suddenly be many hours ahead; and the device will still go back to whatever the initial setting was (this can sometimes be Jan 1 2004).

However, I do have something additional to report: You can fool the device into launching the Time Base Adjustment (... sort of):

• When you are at the Time Base Adjustment screen (the Calibrate button will be greyed out)...
• Log onto the web interface.
• Click on Active STIM.
• Select and activate the GPS stim.
• Click on Channel I/O.
• Set the Frequency Reference parameter (10) to 0, using the Int 10M reference.
• This will fool the unit into believing that the 10MHz reference (e.g. the one we are trying to calibrate) is the locked signal. It will bring up the menu we are all trying to see. It will show the ADC value for the reference, and where/when it was chosen (2053, and Initial Factory).

This doesn't help us, but I think it must be the case that something is fighting us for the clock. So we just need to find what other processes/stims/whatever access/try to change the clock. Perhaps this is a sign of a hardware malfunction in a clock on the motherboard, or some other malfunction that could be tested/corrected if we could e.g. get into the BIOS? Is there a BIOS?

3) I rebuilt my 2nd battery pack, and like the first one, going through the battery recalibration procedure never finished.  It says that it'd take up to 12 hours, and on the first battery I left it running for almost 2 days and it never finished, so it aborted... on the 2nd battery, I left it running since I rebuilt the pack on Friday night... so almost 5 days.  I finally aborted it tonight.  The battery voltage was slowly creeping upward around 12.4 (going up around 10mV per day) but never hit 12.6V (4.2V per cell)... not sure if it didn't think it was done because of that, or something else.  It almost always showed 0 mA current.  The percentage shown is usually 99%, though it sometimes bounces down to 98% or up to 100%.

The battery life seems fine (~1.5 - 2 hours per battery), so I'm not too worried about it... just seems strange (and my OCD would like that fuel gauge error to say 0%, not 10% )... I also tried just running the batteries down and recharging them normally, but that didn't make a difference.

Related to that... the 2nd battery rebuild went smoother than the first.  I'll update my rebuild post above with a couple more notes/pics.

I rebuilt one of my battery packs, and I took pictures of the process. Unfortunately the 2nd one I rebuilt was actually already good, and I simply hadn't checked. I will be getting batteries in soon to replace the first pack.

[TheSteve]

I was hoping you were on to something to help adjust the time base on the N1996A. On the N1996A there is a frequency/reference setting menu. It won't let you continue though unless the system is configured for GPS.
However the N1996A doesn't support a GPS - it was never enabled and the receiver is not installed.

I can set the external reference to "even second" but it locks just fine to a 1 PPS signal(even second doesn't lock).

Not a big deal but it would have been fun to adjust the timebase without using the crazy expensive calibration software Keysight sells for the N1996A.

[technogeeky]

I was hoping you were on to something to help adjust the time base on the N1996A. On the N1996A there is a frequency/reference setting menu. It won't let you continue though unless the system is configured for GPS.
However the N1996A doesn't support a GPS - it was never enabled and the receiver is not installed.

I can set the external reference to "even second" but it locks just fine to a 1 PPS signal(even second doesn't lock).

Not a big deal but it would have been fun to adjust the timebase without using the crazy expensive calibration software Keysight sells for the N1996A.

Well, this may be a route toward that (if a circuitous one). I really don't know that hardware (or this hardware, to be honest). But this method let me see the the value stored somewhere (in firmware or eeprom or something) for the calibration setting (which is, in this case, an integer constant for the ADC). If we could use the screen in which this was displayed (I did not get a screenshot or photograph; I was actually driving my car at the time!) to find where it's writing a firmware setting to, perhaps we could translated this process back to your device?

[DogP]

This doesn't help us, but I think it must be the case that something is fighting us for the clock. So we just need to find what other processes/stims/whatever access/try to change the clock.

IIRC, I came to the conclusion that it's a script running in the background that's causing the time to constantly reset.  I think it was keepTimeUpdated or something like that.  I don't think the system clock is why GPS never goes green though (I don't think there's any code for the GPS to even try updating the system clock).

I was able to extend both the power and frequency range of the signal source in a N1996A. The power range difference was only a few dB so I changed it back to stock as the real maximum output varied with frequency. I extended the frequency range down to 1 MHz from 10 MHz. I believe the E7495A has similar text files which can edited however I have read someone tried lowering the source range on an E7495A in the past and it would crash the unit when you tried to enter a lower frequency.

That'd be great to be able to extend the sig gen freq below 375 MHz... and if it could do that, maybe it could do the insertion loss test below 375 MHz as well.  Those features would be very high on my wishlist (even though the arbitrary sig gen kinda sucks since it doesn't filter the LO or image).  Does the N1996A have an arbitrary sig gen, or just a tracking generator?

Pat

[technogeeky]

IIRC, I came to the conclusion that it's a script running in the background that's causing the time to constantly reset.  I think it was keepTimeUpdated or something like that.  I don't think the system clock is why GPS never goes green though (I don't think there's any code for the GPS to even try updating the system clock).

I think you are correct. I think I might have proof, but I don't think it's (yet) needed. In any case, when I was having trouble running the Calibrate Timebase thing, it turns out the hardware clock (as displayed by hwclock) was set to Jan 1 1970. In other words, it was just counting up from epoch. There is also an 'rtc' module, which could be the source of our problem: if the RTC is faulty or resetting, then it's possible the RTC or the manager of it is fighting attempts to set the clock.

I have found some code regarding this in the GUI, so I can investigate further.


Has anyone been able to decompile the ARM code? I assume there is little to no hope to decompile the firmware for the Dragonfly chips, but the ARM code (of elgato server) should be easy to decompile. I tried downloading and using snowman, but it is unfortunately stupid and it runs out of memory at the "regenerating types" stage. It seems to have generated all of the functions from two different binaries, but because I only have 8GB of memory I can't get much further. Does anyone know how to force a process to work from a disk instead of from memory?

You can look at the elgato GUI (siege) source JAR linked here, and it's clear that there are a few checking conditions before you're allowed to enter the timebase recalibration. Also, there appears to be a direct command you can issue to some command listener to set the new timebase ADC value directly -- this may help N1996A owners. At the very least, you could GET the existing timebase ADC value and then SET a new one, then compare the clocks (though how one would go about this, I have no idea).

[technogeeky]

Can you guys post screenshots of the noise floor of your instruments? I am wondering noise floor curve on my instrument is wrong or not. See the attached images. This is with nothing connected at all.

The screenshots show the measurements and diffs between:

• 500 kHz and 375 MHz (+2.8dB)
• 375 MHz and 2.7 GHz (+10.4dB)

Something tells me that a gain of 10.4dB over that range is probably not a good thing.

[TheSteve]

Looks pretty normal to me.

Edit:

I've attached a full span screen shot of my N1996A - however it is only valid to 3 GHz. The drop you see is when it passes 2.7 GHz. The noise floor from 3 GHz to 6 GHz should actually rise as the frequency increases. It doesn't as that portion of it is uncalibrated(I enabled the 3-6 GHz portion myself).

[technogeeky]

Also, I played around with the files in /flash/egServer/Dragonfly/Recievers, like E7495A and CPXSRC. You can indeed change things here and sometimes see the effects (e.g. you can change E7495A to have Freq Range be 3000e6, and it makes it possible to enter that value). However, some of these changes will have no effect for other reasons (here, I assume it's because there is actually a filter which sharply cuts off at ~ 2.7GHz).

Limitations are spread in configs, gui, elgato, dsp code and hardware. I mean along with configs there are many hardcoded values.

If the 7495 is anything like the N1996 (and we have a lot of reasons to believe so) you will not be able to go above 2.7GHz.
The N1996 has 2 receive paths, one for 0.1MHz - 2.7GHz and the other for 2.7GHz to 3/6GHZ. Since the N1996, depending on the model, has an upper limit of 3 or 6GHz both receive paths are there, and that is why you can change the 3GHz model to 6GHz by changing the upper limit value. Since the 7495 goes to 2.7GHz only I assume that the upper part is missing in the 7495. See below the N1996 receive path:

Do you have more information from this source? I'd like to see any schematics or block diagrams I can find.

[PA0PBZ]

Do you have more information from this source? I'd like to see any schematics or block diagrams I can find.

N1996 Service manual guide: https://www.dropbox.com/s/5axcrduzvvd3rvb/N1996-90006.pdf?dl=0

[ferdinandkeil]

Can you guys post screenshots of the noise floor of your instruments? I am wondering noise floor curve on my instrument is wrong or not. See the attached images. This is with nothing connected at all.

The screenshots show the measurements and diffs between:

• 500 kHz and 375 MHz (+2.8dB)
• 375 MHz and 2.7 GHz (+10.4dB)

Something tells me that a gain of 10.4dB over that range is probably not a good thing.

Did the same test with my E7495B and got similar results. Looks to be normal.

[technogeeky]

I'm still trying to hunt down the clock problem, as unlike an above poster I do think this is the reason the GPS won't go from yellow to green (though I don't yet have any firm information on this, other than configuration information: In the web UI, the STIM # 106 says the internal clock gets its time from Time).

In any case, I can confirm that basically something is resetting the clock exactly every 60 second. This is not the hardware rtc (which for me, defaults to Jan 1 1970 epoch). You can actually look at some of this with /proc/interrupts:

Code: [Select]

  0:     323496   ADS_ext_IRQ
 26:     502791   timer
 27:          0   rtc timer
 30:         18   rtc 1Hz
 31:          0   rtc Alrm

I can confirm that "rtc 1Hz" is the number of times I have accessed the RTC with hwclock. You can easily confirm this.


I was interested to note that (I need to state this carefully): the time the clock resets back to every 60 seconds, is the timestampped value of /etc/adjclock. It didn't seem like changing the timestamp on this had any effect, so I just moved it to the side. I thought this was the end of this route. However, 30 minutes later (again, exactly) the file was recreated with the timestamp 30 minutes later, but now with zeroed contents (0.000000 0 0.0000000 / 0 / LOCAL).

Note that all of this was carried out with all of the time-related processes and local GUI processes killed. So either this is a driver, something kernel level, or elgato (the server itself) doing this.


edit 1:

More notes. It looks like /dev/receiver is a pointer to a UART where the GPS dumps raw information. Maybe.

In any case, looking at /dev/ram0 shows:

Code: [Select]

ttyS0 at I/O 0xf0100000 (irq = 50) is a 16550A
ttyS1 at I/O 0xf0120000 (irq = 51) is a 16550A
ttyS2 at I/O 0xf0140000 (irq = 52) is a 16550A
ttyS3 at I/O 0xf0160000 (irq = 54) is a 16550A

So these are all UART-things.

[technogeeky]

Funny enough, they were nice enough to fill out their /etc/services with their own services:

Code: [Select]

diag            31415/tcp                       # ARMS diagnostics
elgato_cmd 5028/tcp # ElGato Command Generator
elgato_reporter 5029/tcp # ElGato Reporter
scpi            5025/tcp                        # SCPI
scpi            5025/udp                        # SCPI (to be safe ?!?)

I'm not sure if all of these are known, I will have to make yet another pass through this thread. :/

[kirill_ka]

Code: [Select]

scpi            5025/tcp                        # SCPI
scpi            5025/udp                        # SCPI (to be safe ?!?)


scpi code is missing from elgato. There's SCPI STIM in N1996A's toro, which we don't have in elgato.

[ve7xen]

I did some digging into the time setting issue, since I was pretty sure my unit successfully synched to GPS time back when I got it, but I see the same 'yellow triangle' behaviour now.

Long story short, I did some poking around with the logging. Nothing useful comes out of the client (though maybe some insight into the protocol, it's quite verbose when set to level 255), but the server application logs directly to /dev/ttyS0 at 38400 8N1 (which is also the bootloader and a Linux tty). This happens to be 'Serial 2' on the top panel of the instrument. Looking at the log output, it seems that some variant of the Y2K / Y2038 bug could be in play here, this repeats every 30 seconds:

Code: [Select]

System time less than minimum allowed. Setting clock to Thu Jan  1 00:00:00 2004

What I presume is happening is that the GPS is setting the clock, then the server process doesn't like it and resets it. Some strange things start happening if I set the system clock manually (date -s "YYYY.MM.DD-HH:MM:SS"). For example, if I set the system clock to Fri Dec  1 00:00:00 UTC 2017, I now get this error, setting the time back exactly 12 hours? Where did the new set time come from (it's not in the script mentioned below).

Code: [Select]

System time less than minimum allowed. Setting clock to Thu Nov 30 12:00:00 2017

So this is quite odd, since Linux itself has no trouble with the current date, but the egServer process seems to be rolling it over zero to 'less than the minimum'. I guess egServer must be internally representing the time in a nonstandard way. Maybe just patching the comparison would make it work again?

In case you're curious, the keepTimeUpdated mentioned is a simple script that writes the current date every 20 minutes to another script that is part of the startup of the instrument. I guess to get it 'closeish' to the previous time when it boots.

[technogeeky]

I did some digging into the time setting issue, since I was pretty sure my unit successfully synched to GPS time back when I got it, but I see the same 'yellow triangle' behaviour now.

Long story short, I did some poking around with the logging. Nothing useful comes out of the client (though maybe some insight into the protocol, it's quite verbose when set to level 255), but the server application logs directly to /dev/ttyS0 at 38400 8N1 (which is also the bootloader and a Linux tty). This happens to be 'Serial 2' on the top panel of the instrument. Looking at the log output, it seems that some variant of the Y2K / Y2038 bug could be in play here, this repeats every 30 seconds:

Code: [Select]

System time less than minimum allowed. Setting clock to Thu Jan  1 00:00:00 2004

What I presume is happening is that the GPS is setting the clock, then the server process doesn't like it and resets it. Some strange things start happening if I set the system clock manually (date -s "YYYY.MM.DD-HH:MM:SS"). For example, if I set the system clock to Fri Dec  1 00:00:00 UTC 2017, I now get this error, setting the time back exactly 12 hours? Where did the new set time come from (it's not in the script mentioned below).

Code: [Select]

System time less than minimum allowed. Setting clock to Thu Nov 30 12:00:00 2017

So this is quite odd, since Linux itself has no trouble with the current date, but the egServer process seems to be rolling it over zero to 'less than the minimum'. I guess egServer must be internally representing the time in a nonstandard way. Maybe just patching the comparison would make it work again?

In case you're curious, the keepTimeUpdated mentioned is a simple script that writes the current date every 20 minutes to another script that is part of the startup of the instrument. I guess to get it 'closeish' to the previous time when it boots.

I wonder if this is as simple as Agilent assuming the epoch is Jan 1 2004. I think 'hwclock' is happy to set an epoch that is different from the typical 1970 one. This is, of course, the RTC. I don't know if they are reading this directly or not, but I think they could be (e.g. I think elgato could be bypassing the interrupts and going directly to the RTC).

I also wonder if this issue happened in the previous firmware. Does anyone still have it? I didn't keep it, unfortunately.

[TheSteve]

I am thinking that the GPS used to lock fine on the E7495A as that surely would have been a fixed bug if it was always present. I also didn't find any service note related to it.

[technogeeky]

I learned a little bit more. First:

* We can be 100% sure the time resetting is caused by elgato itself.
* If you kill elgato and run your own copy, you get a shell. This isn't the most friendly shell, but we might be able to find useful commands by searching through the elgato binary.

First of all, we can directly see this system time problem:

System time less than minimum allowed. Setting clock to Thu Jan  1 00:00:00 2004

Second, we can do the one thing they suggest doing, which is:

debugIPub=1; (or 2, or maybe 3?)

Code: [Select]

Samplers/timeLicense.p1 publishing {argArray with 10 elements} as 'timeLicense'
gui1.s23 receiving data as timeLicense

System time less than minimum allowed. Setting clock to Thu Jan  1 00:00:00 2004

Samplers/timeFreqRef.p1 publishing {argArray with 10 elements} as 'timeFreqRef'
gui1.s9 receiving data as timeFreqRef


With the same setting to 2, we get:

Code: [Select]

Samplers/timeFreqRef.p1 publishing {argArray with 10 elements} as 'timeFreqRef'
<ArgArray length="10">
<UInt32>1</UInt32>
<UInt32>1072915200</UInt32>
<Int32>3397774</Int32>
<Int32>-8440589</Int32>
<Int32>32993</Int32>
<Int32>4</Int32>
<UInt32>2</UInt32>
<UInt32>1</UInt32>
<UInt32>0</UInt32>
<UInt32>3</UInt32>
</ArgArray>

We've seen this before, this is the data gotten directly from the GPS unit STIM.

And we also get:

Code: [Select]

Samplers/timeLicense.p1 publishing {argArray with 10 elements} as 'timeLicense'
<ArgArray length="10">
<Int32>-1</Int32>
<Int32>-1</Int32>
<Int32>-1</Int32>
<Int32>-1</Int32>
<Int32>-1</Int32>
<Int32>-1</Int32>
<Int32>-1</Int32>
<Int32>-1</Int32>
<Int32>-1</Int32>
<Int32>-1</Int32>
</ArgArray>

I don't think turning off the hack has any effect on this problem, but maybe someone should double check that.

In any case, there are a *bunch* more symbols to turn on and off. Certainly anything that starts with debug. I'll keep looking...

[kirill_ka]

Today I have some progress in decoding serial protocol used to communicate with power meter.
Below is the shell command to enable 50 MHz power reference. GUI shouldn't be in power meter mode while you run it.

Code: [Select]

(stty 38400; sleep 2; printf "\x83\xf8\x04\x08\x01\x00\x01") < /dev/ttyS4 > /dev/ttyS4Turn it off with

Code: [Select]

(stty 38400; sleep 2; printf "\x83\xf8\x04\x08\x01\x00\x00") < /dev/ttyS4 > /dev/ttyS4However, it turns off when you open the port. Opening the serial port seems to reset some power meter state.

[Puffin]

Has anyone else had issues with the remote GUI not responding to clicks on the right-side buttons?   I had it working once, but struggling to make those buttons work again which severely limits what you can do with the GUI.

On the subject of the date reset, it's every 30 seconds, not every 60.  Done by the elgato process itself (killing that stops the time getting reset anyway).    A crude hack to run hwclock --hctosys every few seconds is a kind of work-around.

I'm also noticing the GPS seems somewhat unreliable - and even when it does get 6 sats locked, I've never seen the GPS indicator with anything other than the yellow triangle.

I'll likely prod at this some more, but I'm somewhat nervous to try hacking things further due to fear of bricking this otherwise nicely functional kit.

[lectrohamlincoln]

Hello Everybody,

I picked up an E7495A described as "LOCKS UP ON POWER UP." I suspected that the firmware was corrupted and it would be easy enough to flash the latest A.06.25 version. I've tried using both a Sandisk 512MB and a 8Gb Compact Flash formatted to FAT32. With no luck

So, I followed the "Update via Load Firmware Utility" procedure described in the Service Guide. I removed the RF section and set the DIP Switch as instructed. I tried again with both Sandisk CFs, but my E7495A would only turn on with a blank display. Is it possible this factory reset requires a PCMCIA instead of CF?

I'm beginning to suspect there might be a hardware problem. I also noticed that there was a red LED lit on the controller board. I'm hoping for any suggestions before I start doing a component level debug tomorrow.