We seek to understand and document all radio transmissions, legal and otherwise, as part of the radio listening hobby. We do not encourage any radio operations contrary to regulations. Always consult with the appropriate authorities if you have questions concerning what is permissible in your locale.

Author Topic: DGPS Logs Sep 12 2020 UTC 2311 - Sep 13 2020 UTC 2325 (AFE822x)  (Read 1067 times)

Offline skeezix

  • Global Moderator
  • Marconi Class DXer
  • *****
  • Posts: 5544
  • Minneapolis, MN
  • What does 'RNO stand for?
    • View Profile
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 






AFE822x v2.0 SDR with 43' Wellbrook ALA100LN loop oriented E-W
« Last Edit: September 17, 2020, 1859 UTC by skeezix »
Minneapolis, MN

Offline ChrisSmolinski

  • Administrator
  • Marconi Class DXer
  • *****
  • Posts: 31105
  • Westminster, MD USA
    • View Profile
    • Black Cat Systems
Re: DGPS Logs Sep 11 2020 UTC 2305 - Sep 12 2020 UTC 2311 (AFE822x)
« Reply #1 on: September 13, 2020, 1701 UTC »
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?

Chris Smolinski
Westminster, MD
eQSLs appreciated! csmolinski@blackcatsystems.com
netSDR / AFE822x / AirSpy HF+ / KiwiSDR / 900 ft Horz skyloop / 500 ft NE beverage / 250 ft V Beam / 58 ft T2FD / 120 ft T2FD / 400 ft south beverage / 43m, 20m, 10m  dipoles / Crossed Parallel Loop / Discone in a tree

Offline skeezix

  • Global Moderator
  • Marconi Class DXer
  • *****
  • Posts: 5544
  • Minneapolis, MN
  • What does 'RNO stand for?
    • View Profile
Re: DGPS Logs Sep 11 2020 UTC 2305 - Sep 12 2020 UTC 2311 (AFE822x)
« Reply #2 on: September 13, 2020, 1918 UTC »
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).

Minneapolis, MN

Offline pnoelw

  • Newbie
  • *
  • Posts: 18
    • View Profile
    • Email
Re: DGPS Logs Sep 11 2020 UTC 2305 - Sep 12 2020 UTC 2311 (AFE822x)
« Reply #3 on: September 14, 2020, 1647 UTC »
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!

Offline skeezix

  • Global Moderator
  • Marconi Class DXer
  • *****
  • Posts: 5544
  • Minneapolis, MN
  • What does 'RNO stand for?
    • View Profile
Re: DGPS Logs Sep 11 2020 UTC 2305 - Sep 12 2020 UTC 2311 (AFE822x)
« Reply #4 on: September 15, 2020, 0321 UTC »
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).



Minneapolis, MN

Offline pnoelw

  • Newbie
  • *
  • Posts: 18
    • View Profile
    • Email
Re: DGPS Logs Sep 11 2020 UTC 2305 - Sep 12 2020 UTC 2311 (AFE822x)
« Reply #5 on: September 15, 2020, 0631 UTC »
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.

Offline skeezix

  • Global Moderator
  • Marconi Class DXer
  • *****
  • Posts: 5544
  • Minneapolis, MN
  • What does 'RNO stand for?
    • View Profile
Re: DGPS Logs Sep 11 2020 UTC 2305 - Sep 12 2020 UTC 2311 (AFE822x)
« Reply #6 on: September 15, 2020, 1351 UTC »
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.
Minneapolis, MN

Offline pnoelw

  • Newbie
  • *
  • Posts: 18
    • View Profile
    • Email
Re: DGPS Logs Sep 11 2020 UTC 2305 - Sep 12 2020 UTC 2311 (AFE822x)
« Reply #7 on: September 15, 2020, 1436 UTC »
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!

 

HFUnderground Mug
HFUnderground Mug
by MitchellTimeDesigns