www.dl2rum.de

The new RumLogNG 1.0.9 looks very promising. Its not far away I am switching my operations from Classic to NC. I am currently testing systematically through all functions. Using Yosemite 10.10.2 on iMac late 2009, 12GB RAM, Microham DigiKeyer II Firmware version 3.2 and FTdx5000. I see that the Read...

I see that questions about compatibility with certain transceivers are ignored here on the forum. Is RumPed actually still further managed by the author or will it remain in the current state without any further updates whatsoever. Would be nice to know….
Matthias, LA0FA

RUMLog is working well with FTdx5000 although there is no specific selection for this transceiver. The FT2000/450/950 selection works well. In RUMPed however this is not working stable at all. There is no of the Yaesu options working stable with the FTdx5000. Do you have plans for an upgrade of RUMP...

Thank you very much!
Works perfectly with the script.
Matthias, LA0FA

I was unclear. I am familiar with Applescript and I have changed the script to include MFSK16 and I have verified that MFSK16 is sent as text string as mode to RumLog .. but Runlog won't log it. There must be a bug within the RumLog software. Here the script I use, it works for all modes, except MFS...

RumLog 5.2.6 does not accept the logging from CocoaModem of the MFSK16 mode ... works will all other modes available from Cocoamodem, except MFSK16. I have ticked on MFSK16 as a mode in Rumlog preferences.
73 de LA0FA

I can confirm the same, The Power Nap option is key to make the CAT work stable in Maverick ! (digiKeyerII and FTdx5000). 73 Matthias Thanks for the hint. Just heard from another problem: The CAT interface (microHAM digiKeyerII) became unreliable. A simple frequency change needed up to 10 seconds to...

thanks. of course ... it seemed with the red callsign field occuring when entering /mm that I could not save the qso - but saving is possible but its an "illegal" call sign towards DXCC. You are perfectly right. Matthias

entering a callsign with /mm extension causes a DXCC error (unknown dxcc) .... shouldn't this be possible ?
73 de LA0FA, Matthias

Thanks a lot! You are perfectly right, the qrz.com gives the "faulty" locator info of the "prefixed" operators home-locator.
Now I have understood it I can deal with it !
Thanks for quick and good responses.
Matthias