Products > Test Equipment
Agilent E7495 linux root account
<< < (34/91) > >>
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: ---  0:     323496   ADS_ext_IRQ
 26:     502791   timer
 27:          0   rtc timer
 30:         18   rtc 1Hz
 31:          0   rtc Alrm

--- End code ---

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: ---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

--- End code ---

So these are all UART-things.
technogeeky:
Funny enough, they were nice enough to fill out their /etc/services with their own services:


--- Code: ---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 ?!?)

--- End code ---

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

--- Quote from: technogeeky on March 17, 2017, 07:01:37 am ---
--- Code: ---scpi            5025/tcp                        # SCPI
scpi            5025/udp                        # SCPI (to be safe ?!?)

--- End code ---

--- End quote ---

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: ---System time less than minimum allowed. Setting clock to Thu Jan  1 00:00:00 2004

--- End code ---

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: ---System time less than minimum allowed. Setting clock to Thu Nov 30 12:00:00 2017

--- End code ---

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:

--- Quote from: ve7xen on March 18, 2017, 04:05:15 am ---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: ---System time less than minimum allowed. Setting clock to Thu Jan  1 00:00:00 2004

--- End code ---

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: ---System time less than minimum allowed. Setting clock to Thu Nov 30 12:00:00 2017

--- End code ---

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.

--- End quote ---

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.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod