HFU HF Underground
Loggings => DGPS => Topic started by: skeezix on September 13, 2020, 1531 UTC
-
The numbers are bogus. As can be seen in the graph, there is a periodic nature to the strong decodes. What that actually is, is just before the recording ends, things are solid. After a new recording starts, then its sparse for a while. No idea why, as the previous couple of days looked great. The win7 box has been rebooted and let's see if that clears things up.
Count ID ref1 ref2 kHz Baud City Country Lat Lon km Deg
7 971 903 904 307.0 200 Gatun Panama 9.261 -79.937 4,181 158
8 940 338 339 315.0 200 Cape Race, NL Canada 46.661 -53.075 3,098 72
164 944 342 343 310.0 200 Cape Norman, NL Canada 51.509 -55.831 2,842 62
536 942 340 341 288.0 200 Cape Ray, NL Canada 47.636 -59.241 2,621 71
38 909 300 301 309.0 200 Alert Bay, BC Canada 50.589 -126.93 2,554 296
5 934 336 337 307.0 200 Fox Island, NS Canada 45.361 -61.097 2,518 78
44 908 302 303 315.0 200 Tofino [Amphitrite Point], BC Canada 48.931 -125.545 2,456 292
13 937 330 331 298.0 200 Hartlen Point, NS Canada 44.583 -63.45 2,353 80
2074 907 304 305 320.0 200 Richmond, BC Canada 49.114 -123.183 2,283 292
318 935 334 335 312.0 200 Western Head, NS Canada 43.993 -64.67 2,273 83
1620 936 332 333 319.0 200 Point Escuminac, NB Canada 47.075 -64.8 2,210 74
101 939 326 327 295.0 200 Partridge Island, NB Canada 45.239 -66.056 2,138 80
39 925 320 321 313.0 200 Moise, QC Canada 50.202 -66.119 2,115 64
1971 927 316 317 309.0 200 Lauzon, QC Canada 46.821 -71.165 1,729 75
4991 929 312 313 296.0 200 St Jean Richelieu, QC Canada 45.324 -73.317 1,574 82
2914 919 308 309 306.0 200 Cardinal, ON Canada 44.783 -75.417 1,417 85
4524 918 310 311 286.0 200 Wiarton, ON Canada 44.75 -81.117 971 87
(https://i.imgur.com/7LAlbhy.png)
AFE822x v2.0 SDR with 43' Wellbrook ALA100LN loop oriented E-W
-
Curious. I was going to suggest some sort of issue with the reported sample for the file causing a drift in apparent time over the recording, but that would produce the opposite result - good at the beginning of a recording.
Some sort of wonky AGC action in the SDR software?
-
No, I think its OS related. I've had problems on & off for a long time with various symptoms. This one is new. You can see from time to time where its usually pretty dense, have a gap with sparse decodes. For some reason, the software gets behind during that hour. It fine when it starts the next file. However, it fixing during the hour and fine at the end doesn't really make sense.
Its either win7 being stupid, something wrong with the HD, or maybe the antivirus has had some new update (which it did) and is now "protecting" the server by scanning and putting load on it.
However, unsure of the current mess. Hopefully the reboot has straightened it out (at least for a while).
-
Thank goodness it's not just my system! Occasionally, I get exactly the same issues with periodic peaks and troughs coinciding with the file end or beginning. The bad news is that it happens on both my machines - laptop W8.1 and desktop W10. It is quite infuriating when it does happen.
Each time I re-start the computer (full re-boot); ensure all updates are updated incl anti-virus; etc. sometimes it works and sometimes it doesn't. I only use the laptop for overnight recording so I've uninstalled all superfluous software and disabled as many Windows background services etc that I dare. I've trawled through the various system logs to see if anything is running at the times it happens. Nothing obvious. But I'm no Windows expert....
My assumption is that it has to do with the process of writing to the disk (it's internal SSD, but I've tried USB HD). I have had this issue with both Perseus native software and HDSDR running the Perseus receiver.
Is it hardware or software related?
Please let me know if you get to the bottom of this before you pull out all your hair!
-
This time, the reboot fixed it. For now.
This system is running windoze 7 (fully patched), Malwarebytes (fully patched), and Studio1 (last version).
The recordings are saved to a 6 TB SATA HD drive, 5200 RPM, IIRC. That should be sufficient and usually is.
Studio1 is set to save a 1 hour file (which is 14 seconds just over one hour, when things are normal).
A year or so ago, I would see an occasional disruption in a recording. The start of the recording is fine, then sometimes something would disrupt and cause the rest of the file to have scattered decodes. The new file starts fine and could continue fine. Did some troubleshooting and thought it was due to fullness of drive & fragmentation. About 5-6 months ago, cleaned off the storage drive and quick formatted it. That should've cured problems until it got full. It was fine for a while, then started happening again. So apparently that wasn't it.
The recent problem of starting out scattered and becoming good is puzzling, as that's the first time its corrected itself while recording a file.
The only thing that has changed is Malwarebytes. There was an update some number of months ago, and after that it seemed to get scattered more often than not (but I have RFI here, so I attributed it to that). Then a few days ago, another update, so I applied that and things got much better up until this strange behavior. So I rebooted, then turned off a couple of the features that I wouldn't need (this machine solely records from Studio1 and literally does nothing else). So far since the reboot its been ok, but hasn't been close to long enough.
I'm not yet ready to blame Malwarebytes. That hasn't always been on there, but can't remember if the behavior started before it was installed.
Thanks for letting me know that my behavior isn't unique... neither to the OS and it happens with other software.
I wouldn't use a USB HD unless its USB-3.
I have the full disk scan run at 1400 local time, as that's the middle of the afternoon with no more DGPS stations (and when the U.S. were still on, would only have 3 locals and sometimes some daytime DX, rarely).
-
Glad to hear that the reboot has given you some respite - until the next time.
"Studio1 is set to save a 1 hour file (which is 14 seconds just over one hour, when things are normal)"
Just check the absolute lengths from file properties and also whether the start-time of the next file is always contiguous with the end-time of the previous file. I suspect that there is quite a lot of "slippage" in those recordings ie many micro-hesitations in the writing. I have found that these can add up to 5-15 seconds in a bad recording. If you are using a programme called Pskov for NDB work then this will show the slippages. I can post an example of a single slippage.
Malwarebytes! I have been using this for many, many years and have always been a solid supporter of their software. But from the start of version 4 there have been problems. I have disabled it completely on my laptop which i use only for recording IQ files. But that hasn't resolved the occasional recording hiccups. On my desktop where I do all of the CPU intensive analysis (like ADGPS an Pskov) I can only run it with web protection and exploit protection switched off. Most unsatisfactory. I had a lengthy discussion with Malwarebytes about this but no solution. See this forum topic https://forums.malwarebytes.com/topic/255932-malwarebytes-causing-programs-to-run-slowly/
Defrag, etc. Also went through that and no lasting resolution. I have switched off automatic optimisation and manually implement every so often.
I religiously patch/update all my software on a regular basis ie weekly or bi-weekly. I would really like to get to the bottom of this as it doesn't seem to be a widespread issue reported by others.
-
Thanks a ton for that MB thread, now I know to where I can cast a stink eye. Next time this happens, I'll go through some of those things.
MB here is at the latest release version, can't remember which things I've turned off (web protection for sure, as I don't use any web browsing on that system). I do have IPv6 enabled and next time the recordings start having problems, I'll disable that. I'm not going to run a beta, as I deal with computers all day long at work and not about to run experiments on this system at home.
Studio1 is using an AFE822x SDR via 1 Gbps ethernet, but that's only IPv4. So disabling IPv6 isn't a big deal.
The recordings cover 1h 14s each when all is well. When they get longer, then there are problems with the recording and then I go check on things.
As you can see from the subject lines in the DGPS logs, a normal day would run a day + 5-6 minutes. For a while, a day was +9 minutes (there are exceptions to that when patches were applied or a power failure and that would screw up that scheme).
There are two HD's in this system, one for the OS, applications, and other misc junk, the other drive is dedicated solely to the I/Q recordings. When it gets near full, then I'll stop recording, then move them to a USB drive for long term storage. If I'm feeling ambitious, then I'll quick format the drive and start fresh (otherwise, I'll just let it go without formatting).
Bah.
-
So all good for now. Fingers crossed. Let us know if it rears its ugly head again and whether you find definitive resolution.
I'll not be doing any radio stuff for a day or 2 as my neighbour is working on his trees and our common fence. So I've had to take down my sole antenna (pa0rdt mini-whip which was 4m up in his overhanging tree!). It should go up again by the weekend. I will be moving the antenna laterally by about 8m and it will be interesting to see whether it makes any difference to the abundant QRM. Hopefully better and not worse!