This one I just found, and took me a little while to work around. Last night I found that some of my QSO records, though marked as sent, weren't actually in LoTW. Rather than pick through them all, I just resent all my "sent" ones, since it wasn't many (161) and had them reprocessed. Unfortunately a couple dupes were created in LoTW, and in an attempt to make sure the numbers there match the number in my log, I created dummy entries for those records in my log and set the QSL status to '-' for paper, LoTW and eQSL. This morning, every QSO defaulted to '-' for paper and I couldn't get it to revert to the default 'W' again. Based on the information from http://dl2rum.de/forum/viewtopic.php?f=4&t=161&p=706 I tried saving some dummy contacts, but it didn't help. Finally I set the paper QSL value to 'W', left it like that and quit the program; on next invocation, it now uses the default 'W'. So it seems that the bug is that the default status isn't from the last contact saved, but instead whatever the value was when the program was quit.
The second one has been around for a little while, and I'm finally getting around to mentioning it (I know, I'm a bad user :> ) When I start RUMlog I have many windows set to open including the ARRL and eQSL windows, as well as the DX Cluster terminal window. One of the commands sent to the cluster upon connect is 'sh/dx/50' to populate my bandmaps a bit and see what's been happening recently. The bug is that if I close the eQSL window (or possibly just the ARRL one, I haven't tried that one alone) I get a pop-up error window that says the program must shut down. And in showing just how bad a user I am right now, I can neither make the program do it, nor do I have a screenshot of the error to report what it says. So, if this isn't helpful enough I'll try to find it later - it might need there to be some data that was downloaded from eQSL in the window to affect it, and since I have nothing to pull down right now it's not happening. But next time, I promise, I'll screen cap it :>
Last, a feature question. I have a TS-2000 which works great with rig control except at higher frequencies (it seems the higher the frequency goes, the longer between updates so the band map moves much slower and is jumpy and the frequency display in RUMlog takes a while to update). One thing though, if I tell it to go to a digital part of the band and it switches to sideband (since I have "Force AFSK" checked) it always uses LSB instead of USB. All of the programs I use for digital modes expect USB mode, so I always have to hit the button on the transceiver. Is there a setting to change that from LSB to USB somewhere?
A couple bugs that bug me
Re: A couple bugs that bug me
Short answer to LoTW:
Which upload option do you use? Upload via Mail, via direct e-mail, via tqsl? What is your work flow? Never heard problems like this. But there are few option to check if the QSOs are sent correctly -> mail from ARRL, check on the web site ore tqsl gives you a response.
Crashes:
I'm aware of this problem. LoTW, eQSL and the cluster window are affected. I assume, this is a compiler problem. Normally the programmer has to catch exceptions like this. But here is a logical problem: The eQSL window sends a request to eQSL, you close the window and eQSL answers now. The data will see the eQSL window, but this is gone and you get a NIL exception. Normally, this error will be cached in the eQSL window, but this is blown away.
Digital:
Scrolling the band maps are seeking a lot go CPU load, even when the bands become wider. I have to modify the code for that, but no time yet.....
For RTTY you have to use FSK or LSB. For PSK it dosen't matter, LSB or USB are working the same way.
Which upload option do you use? Upload via Mail, via direct e-mail, via tqsl? What is your work flow? Never heard problems like this. But there are few option to check if the QSOs are sent correctly -> mail from ARRL, check on the web site ore tqsl gives you a response.
Crashes:
I'm aware of this problem. LoTW, eQSL and the cluster window are affected. I assume, this is a compiler problem. Normally the programmer has to catch exceptions like this. But here is a logical problem: The eQSL window sends a request to eQSL, you close the window and eQSL answers now. The data will see the eQSL window, but this is gone and you get a NIL exception. Normally, this error will be cached in the eQSL window, but this is blown away.
Digital:
Scrolling the band maps are seeking a lot go CPU load, even when the bands become wider. I have to modify the code for that, but no time yet.....
For RTTY you have to use FSK or LSB. For PSK it dosen't matter, LSB or USB are working the same way.
73 and best dx de Tom, DL2RUM
Re: A couple bugs that bug me
Sorry, I wasn't blaming the program for the LoTW issue at all; in fact based on the records that seem to have been lost (in December of last year) I think it was an ARRL problem and I just didn't think to reupload them at the time. The back story was mostly to help in describing the problem with the default QSL value not changing from '-' to 'W' when I changed that for an entry, but instead requiring I quit the program with 'W' as the filled-in option and restart it.
NIL exception is exactly the error I'd seen. I would make sure that the eQSL or ARRL window was done what it needed to do before closing it, but it seems if there's incoming data on the DX cluster that it will cause the same problem. Sounds like you're aware of it, and it's one of those kind of bugs that's difficult to track down, so no worries there. As I said if I nail down an exact behavior that causes it every time I'll update, I know vague "this doesn't work" messages all to well with my job :>
And in digital, in my case I'm using JT65 which does make a difference if you're using USB or LSB. Again, not a huge problem, I've got used to hitting the USB button if I change bands from the callsign window, though usually I'm pushing the band + or - buttons anyway. This would only become a big issue if I wanted to operate remotely since I'd have no way to touch the rig, but at least for now I have enough to do at work and don't need to be chasing DX from my office!
Absolutely love this program, as well as RUMped (which I just used in the ARRL SSB SS last weekend, also my son's birthday so I didn't get a huge score but I had fun getting back into it again). Thanks for all your hard work!
NIL exception is exactly the error I'd seen. I would make sure that the eQSL or ARRL window was done what it needed to do before closing it, but it seems if there's incoming data on the DX cluster that it will cause the same problem. Sounds like you're aware of it, and it's one of those kind of bugs that's difficult to track down, so no worries there. As I said if I nail down an exact behavior that causes it every time I'll update, I know vague "this doesn't work" messages all to well with my job :>
And in digital, in my case I'm using JT65 which does make a difference if you're using USB or LSB. Again, not a huge problem, I've got used to hitting the USB button if I change bands from the callsign window, though usually I'm pushing the band + or - buttons anyway. This would only become a big issue if I wanted to operate remotely since I'd have no way to touch the rig, but at least for now I have enough to do at work and don't need to be chasing DX from my office!
Absolutely love this program, as well as RUMped (which I just used in the ARRL SSB SS last weekend, also my son's birthday so I didn't get a huge score but I had fun getting back into it again). Thanks for all your hard work!