WIN 7 64bit (I7-6700)
ge to all,
i ́m running 3 iq-streams 96kHz, feeding 3 instances of cwskimmer with 96kHz.
All working good.
But i cannot increase even one to 192kHz.
I change one of the iq-streams to 192kHz, change the relevant skimmer to 192kHz and after clicking "ok" i get these messages:
and after clicking "ok" then
Now the only way to close cw-skimmer is to stop in taskmanager.
next i have to edit the iqx.ini and change
after that i can start skimmer again and all is fine again with 96kHz.
even starting sdr-bridge or DAX is not helping to get a 192kHz bandwidth.
i thought i had it run with 192kHz on an older PC before, but this could have been a win7 32bit....
What is wrong? Any ideas?
DK8NE - Uli
I don't use CWSkimmer, but after a couple decades designing and writing software...
The first error tells us a couple interesting things:
1) The file extension indicates the source is written in Pascal. Which was released in 1970. It's really, really old. I last used it in 1989. I believe it's still 32 bit, but not sure.
2) The assert means that the CWSkimmer code saw something it didn't like at line 411, but doesn't tell you what that might be. This is rarely if ever seen in 'release' code, it's usually only seen in debug versions of the code.
3) Despite the warning that CWSkimmer saw something it didn't like, it went on ahead and crashed anyway in the second error dialog. It should have aborted before that and told you why. A divide by zero error indicates a fundamental flaw in data validation, which is under the control of the author.
So, that's the error analysis. I ran some of alex's stuff ten years ago, even after buying a license I wasn't really impressed with the product support, and abandoned it. Things may have changed since then.
On to maybe fixing it:
Try running one slice, one instance of CWSkimmer, at 192Khz. If it runs, check the CPU and memory stats. If all looks well, add another instance.
If it won't consume 192k, file a bug/feature request.
i tried as you suggested and ran only one panadapter and one slice with 192kHz to feed cwskimmer.
skimmer aborted the same way as before. i had to stop it with taskmanager.
but after restarting i got a new message:
all i can do to get it work again is to edit the ini and set the signalrate to 96000 again.
after starting cwskimmer again all is working good again even without starting sdr-bridge.
so it ́s really a problem in cwskimmer, isn ́t it?
maybe some file are out of date on my pc??
i will test it on a 32bit win7 again later
my Skimmer runs under Windows7 64bit without any problems, using all bandwidth settings.
Here is one for 192kb:
I must say, however, that I use only one slice and can't say anything about running more
instances of CWSkimmer. I think that 3 instances with 192kB bandwidth just overload your
CPU and/or memory capacity. I normally run CWSkimmer with 48kB bandwidth only,
as this is more than sufficient for my purposes.
My CPU is the same as yours and I run SmartSDR 220.127.116.11 and CWSkimmer 1.9.1.
73, Alex - DH2ID
i think i will clean everything an reinstall again. then slowly start testing with one stream only
and try with smartsdr 18.104.22.168 as well.
73, Uli DK8NE
The access violation says you're trying to access memory you don't own. I don't think this was written to have multiple instances running at the same time. This is a common error in this scenario.
I'm not too sure why I would use skimmer with 192K stream, but it works fine. I run skimmer regularly at 96K, feeding the RBN when not using my rig.
I've have up to four instances running at 192 KHz. I don't think the errors Uli sees is necessarily related to how many instances are run but I have to (unfortunately) agree with other analysts that the software - like a lot of ham radio software today - is hobbiest level. That's not bad as long as you aren't counting on it and don't have to explain to your son why you are running 1990's software.
Now, I understand that CW Skimmer is no longer supported and a new Skimmer (CW and other modes?) is due out in the next year or so. I will register it to show my support but I don't expect any better than we have today.
As for the errors. I see them all the time. Very frustrating. It's almost a ritual of shutting down and restarting SDR-Bridge, each instance, making sure in task manager that all skimmers are truly shut down and not hanging around, rebooting SSDR, rebooting the radio and, in the end, rebooting the computer.
I try to make sure when I quit SDR-Bridge that all four skimmers are unchecked. I think starting SDR-Bridge with no skimmers makes things a little more stable. If I get an error while running, I quite the instances of skimmer - checking task manager. If that doesn't work then it is back to the ritual. I never change soundcard settings while skimmer is running.
Thank goodness for hobbyist programmers. Where would we be without them. But, I truly wish Ham Radio Operators were a large enough market to really become a source of revenue for some of the professional developers. I still think we are kind of stuck in the past... the Pascal past :) Between you and me (don't tell anyone), I still believe the GUI of SSDR is lousy. Lots of promise but in the end pretty unfulfilling and unsatisfying. I think there is a very big difference between someone that programs FFT spectrum plots and DDS SCUs and someone that makes a truly useful GUI that enhances the user experience and workflow following user interface guidelines and being relatively glitch free.
I mean no insults to any developer and very much appreciate your work. Hobbyist coding for hobbyists is fine. But it is hard to call someone that pays $5-$7K each for multiple radios, has 200' towers with 4-over-4-over-4-over-4-... wacko 1 degree beamwidth, 1000 dbi gain antennas, is looking at a couple of $7K gigawatt amplifiers and buys a home based on antenna layout acreage a simple hobbyist. There's a next level where professional programs at a cost should be able to find a market. I'm NOT thinking about HRD nor the disgusting thing that was done to Cebik's treasure of information (solely my opinion). I'm thinking of professional programs with solid features and modern GUIs at a reasonable cost to support future development by a team - not an individual. I guess a lot must change before that can happen.
Thanks for the soapbox opportunity!
I found the problem.
it was the Audio I/Q Device.
I had this pointing to my Realtek Soundcard.
It worked for 96kHz with 3 instances, but not for 192kHz. i wonder why.
After setting this as showed below all is working well with 2 instances each 192kHz.
Although cw-skimmer is a bit tricky sometimes and has some issues when running for quite a while without restart, for me it ́s one of the biggest milestone for dxing and monitoring for many many years.
i ́m very happy Alex developed this.
i run now 2 instances with 192kHz and several more slices as you can see below. CPU has plenty of more to give, so running 4 instances with 192kHz would be possible, too.
it might look weird to most of you, but i ́m dedicated to 6m :-)
So problem solved, thanks to all supporting me and giving inputs.
hope to hear you soon on 6m and many tnx again
Uli - DK8NE
I think Kevin captured it well... the software (any ham software, really) is what it is, take it or leave it. As an engineer, I learned long ago (while porting my SQL table synchronizer from OS/2 to NT) that I have no business designing a UI. Most teams I've worked with in the last five years have dedicated people for UX and UI design. It's really challenging to get those right.
Thrilled you got it to work for you.
This conversation is no longer open for comments or replies.
This conversation is no longer open for comments or replies.