I have tried two virtual serial port drivers, using ports 7 and 17: VSP Manager, and com0com. No difference. I enabled buffer overrun (on both 7 and 17) in com0com. No change. I selected "emulate baud rate" on and off. No difference. The ALE software has a wide choice of CAT commands. I have tried using Kenwood TS-480, and the old VSP1000 receiver (both Kenwood commands, really.) No difference. When baud rate emulation is on, it appears that SDRuno runs longer at 4800 baud than at 9200 baud, but I'm not sure.
Depending upon how many times the ALE software detects a signal and pauses scanning, it can take 2-4 hours before SDRuno stops responding. That's probably more than 10,000 successful frequency changes via CAT before SDRuno stops responding.
If I have the ALE software send data once for just one frequency, with NO scanning, SDRuno will run forever, apparently. I get tired before it does; it never dies.
I have tried this on two PCs, one running Win8.1, the other, Win10. Both are 64 bit. I have ensured that all USB ports never power down (which is obvious, because SDRuno runs just fine when not receiving all those frequency commands.)
How do I fix this? Mike (SDRplay support) has been helpful. He also suggests I try this community forum. The software I use is MARS-ALE. The developer has seen a 2015 version of SDRuno that was sensitive to baud rate (higher = bad) but that's all he says.
I hope I have said something here that inspires a solution. Feel free to ask questions.
Reason: No reason
Also, I wonder... Is there any CAT handshaking going on? There does not seem to be. MARS-ALE happily continues to send CAT commands, even after SDRuno has stopped responding. And how long, after a CAT frequency command is received, does it take the receiver to begin sending audio on the new frequency?
PS: I tried editing my first post, but I received an obscure message in red about "poll options." No idea what that is
Reason: No reason