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).
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.
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.
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).
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 ).
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 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.
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.
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.
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).
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.
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.
0: 323496 ADS_ext_IRQ
26: 502791 timer
27: 0 rtc timer
30: 18 rtc 1Hz
31: 0 rtc Alrm
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
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 ?!?)
Code: [Select]scpi 5025/tcp # SCPI
scpi 5025/udp # SCPI (to be safe ?!?)
System time less than minimum allowed. Setting clock to Thu Jan 1 00:00:00 2004
System time less than minimum allowed. Setting clock to Thu Nov 30 12:00:00 2017
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.
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
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>
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>
(stty 38400; sleep 2; printf "\x83\xf8\x04\x08\x01\x00\x01") < /dev/ttyS4 > /dev/ttyS4
Turn it off with(stty 38400; sleep 2; printf "\x83\xf8\x04\x08\x01\x00\x00") < /dev/ttyS4 > /dev/ttyS4
However, it turns off when you open the port. Opening the serial port seems to reset some power meter state.