[DXLog.net - Support] JARTS experience this weekend (Long!)

[Ken Beals]

Focused on using DXLog on RTTY via mouse/trackball this weekend. A few little items, generally operation was quite good.




When using mouse/trackball to grab data from data window, return of focus to log window is inconsistent:

Click on callsign: callsign put in log window and focus returns to log window, allowing use of F keys or Insert/+ keys to send report


Station responds with report: click on report and data is transferred to log window but focus remains in DI window. This disables F keys and Insert/+. You can click on icons in DI window but requires quickly moving to the small icons. It is easier to either press + key to TU/log qso, or as I have, two extra buttons on trackball programmed to mimic Insert/+. So it is very easy to click on data, then click with extra button to send TU and log. But with focus still in DI, this doesn’t work. It requires an extra left click in the log window to restore focus. Not a big deal, but an extra movement.





Another item is calling a multiplier from the other radio:





With focus on Run radio (likely calling cq with entry line blank) click on call in S&P radio DI. Call is transferred to proper line in log window. But, cursor is now in report field of S&P radio even though transmit focus has not changed from Run radio. If you try to call the station (say with F4), the run radio is keyed with the Run F4 message. I started watching the Rx/Tx indicators on the u2R to confirm where the xmit focus was.




It seems to me that the location of the log window cursor should be consistent with radio focus: If the cursor is in the left(right) radio log entry line then the xmit focus should be left(right). So after putting a call in the S&P radio log line, either put the cursor back in the Run radio log line or switch xmit focus to S&P radio. This would be consistent with cw operation, where the xmit focus moves with the typing focus. I hope I explained that clearly enough.




This one is kind of big: Alt-K keyboard mode does not work with 2Tone in FSK mode. If you Alt-K, you can type until the buffer empties and idle diddles are sent. At that point the keyboard window locks up and no more keypresses can be sent. Keystrokes are entered into the window but not sent. Idle diddles continue to be sent. I reconfigured after the contest to set up MMTTY and Alt-K works fine. I know there is some difference between the UART model of MMTTY and the bit-banging of 2Tone but other than that I don’t know why it acts as it does. I’m using the u2R FSK interface.




Regarding 2Tone and DXLog: it would be nice for those of us who run two copies of 2Tone if the secondary copy could be started from a different directory. When the secondary 2Tone window opens, it complains that the FSK com port is unavailable (since the primary window already has opened it). Using a separate directory would allow a different .ini file that is configured for AFSK without a com port. It also would put the secondary 2Tone window in the proper saved position (rather than on top of the primary window).




One final item is not RTTY specific: changing radio focus with either CapsLock or Up/Dn arrows cancels stereo mode. I’m still new at this SO2R thing but it is better (at least for me) to have stereo stay on so you can monitor the run frequency while working a mult on other radio. I worked around this by selecting stereo manually on the u2R box, but having keyboard control would be much nicer. Maybe you experienced SO2R guys can tell me if I’m all wet.




Thanks for all the hard work on DXLog. It is a bit different from what I used previously but I think I’m getting the hang of it. Luckily I have not been doing this that long so I don’t have any habits I can’t break.




Sorry about being long winded. Wanted to get this out before I forgot what my scribbled notes said.




Ken  K6MR