Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - EI3KD

Pages: [1] 2
Jan, I can try to help - but first can we be clear about which problem it is that we're trying to track down?

If you're worried about correct installation, then I've had no problem with that on Windows 10 - i.e. I get the four ports installed and correctly named "RRC1258 COM0", etc. From that point of view, everything looks normal.

The problem I have is that the ports only work correctly with a few programs, and not with others. For example a port used for CAT, in my case, only works in N1MM+ and OmniRig, but not in DxLog, WinTest, DxCommander and others - all using the same settings. I guess there must be something different in the way those programs open/use the com port, but I can't figure out what it is. It certainly seems to be something specific to Windows 10, so it could well be out of our control...

Regards, Mark

Hi Frank,

FWIW - there's something strange with the virtual ports created by the setup manager on Windows 10. Like yourself, for me N1MM+ CAT (and, IIRC, OmniRig) works fine using the virtual port directly, but neither DxLog, WinTest, nor DxCommander do. That problem didn't exist on Windows 7, where everything worked fine.

I've pretty much tried everything I can think of to get it to work, or find a work-around, but have given up...

Regards, Mark EI3KD

Configuration, RRC 1258 / Re: Problem with Yaesu 857
« on: 2015-03-03, 15:13:26 »
Are you sure you have the cable the right way between the control panel and the RRC TTL connector? If it is the cable supplied by remoterig, the end with a yellow connector must be into the RRC - it won't work the other way around.

Many thanks Jan,

it's early days yet, but I've been testing the winkeyer emulation in your latest beta today and it's looking great with N1MM+ V1.0.4646.0. None of the previous problems I had are there, no box crashes, N1MM+ auto-send is working perfectly, and I haven't found anything new... so far! I'll try a bit harder to break it ;)

I've tried quick tests in DxLog and WinTest, which also seem fine. There are so many different contexts, hopefully a few others will check it out for their particular setup too...

Regards, Mark

Ok, I wonder if this helps? I found this message when I went to my remoterig control box's web page:

Saved error message:
Data Abort at 0x00038e88, called by 0x00038ff4

I can reproduce the problem but it's very contrived and seems peculiar to something N1MM+ does, because I can't reproduce it in WinTest. Unfortunately, it's also in firmware V2.84 :(

I can try and give more detail if required (or perhaps capture the serial data?), but briefly (with N1MM+ V1.0.4616.0):

1) N1MM+ menu Config/"CW Autosend Threshold" set to 1.

2) N1MM+ in Run mode, Rig in CW.

3) Type F1TTT in call entry window: N1MM+ (and hence the winkeyer) starts sending after the "F1T" is entered, and sends the complete exchange - in my case that is "F1TTT 001 IO51VW". Actually, for some reason it only sends F1TT as the call but with the correct exchange, but that might be a different problem?

4) Don't log the QSO, instead hit F12 to wipe it.

5) Enter F1TTT in call entry window (again) - no cw is sent (it should be...) and the remoterig control box reboots.

I can't help feeling that this winkeyer stuff is causing you more trouble than it's worth, sorry!

Regards, Mark

Hi Jan,

once again thanks for looking at this!

The beta version worked as far as interrupting the serial cw using manual paddles - but at some point while I was testing it (using N1MM+) the remoterig control box "crashed", i.e. it restarted as if just powering up. That's the first time it's ever done that, so I guess there's something not quite right in that version. I'm trying to pin down whether I can reproduce it exactly, but in the meantime other people should be careful about using that file!

Regards, Mark

V2.84 firmware has fixed the general interaction problem with N1MM+, but I've just found another small problem: Once a message has been started, e.g. "CQ EI3KD EI3KD TEST", it cannot be interrupted using the manual paddles - this is true with N1MM+ and WinTest, at least.

I'm not sure if there's still some problem with a UST byte being required to indicate the paddles are activated (I didn't check whether remoterig sends this?), but "Paddle Input Priority" is also a feature of Winkeyer2: "Winkeyer2 accepts input from either its serial port or iambic paddle. The paddle will always take priority and will interrupt serial data, automatically clearing Winkeyer2ís serial input buffer. When a paddle break-in occurs, any additional serial data that arrives from the host will be processed, but will be ignored unless it is an immediate command. After paddling ceases, Winkeyer2 will pause for one word space time before it resumes serial data transmission."

It would be nice if this was working properly, but perhaps it's not feasible?

Regards, Mark

Thanks Jan,

that works fine for me with N1MM+, tested today with version 1.0.4584. I've also checked it still works with the latest versions of  WinTest, cwType and DxLog.

Great job!


Hi John,

I had exactly the same problem and couldn't solve it using any of the remoterig parameters. The only thing I could do was to turn the rig's sidetone level down to zero, and then the problem went away - I use the remoterig box's internal sidetone anyway. I'm not sure why that  worked because the popping, which must have been snippets of the rig's sidetone output, was happening when the rig was in permanent tx, as seen at the remote control end: I didn't think any audio should have been coming back from the rig in that case because RTP mode is set to "Normal", not "Continuous". It's as if the audio is coming back before the rig is actually in rx mode, but only noticeable on cw?

Regards, Mark

I have the same problem with N1MM+

Having looked at the serial data flow, perhaps the remoterig winkey implementation is not quite complete...

A standard K1EL winkeyer2 sends an "Unsolicited Status Transmission" (UST) containing the status byte, whenever the winkey status changes: This includes information such as whether the keyer is currently busy sending Morse, paddle break-in is active, etc. It seems like the remoterig implementation doesn't send this status update - the only UST it sends is to do with speed control.

I think N1MM+ uses the UST status update (in WK1 compatible mode?) as a form of "software flow control" and consequently doesn't work properly when it's not being sent.

I hope this helps - the required fix is probably in remoterig's implementation rather than N1MM+

Regards, Mark

Hi Jan,

both COM ports are running Mode-3, char-timeout.

Regards, Mark

Hi Mike,

it is with any software - I've tried HRD, VqLog, N1MM+, WinTest, my own Rotator control, etc. All of those work without any trouble when using the physical port connection(s).

On my W7-64 machine I have "Advanced Serial Port Monitor" software installed... with that running I can see the virtual port is being set up by the software, some commands are being sent, but nothing ever comes back as a reply.

It must be something simple I've missed but I can't think what it is.

Regards, Mark


I have a working setup on my RRC-1258 MkII pair, as follows:

COM1 is a physical connection at both ends, providing FT857D CAT - this is working fine (Mode3, 4800 8-N-2, no rts/cts).
COM2 is a physical connection at both ends, providing Rotator control - this is working fine (Mode3, 4800 8-N-1).
COM3 is being used via usb at the control end as USB-COMFSK in "Mode8, Winkeyer" - working fine using virtual port COM8.

I decided to remove the physical hardware (usb-serial) connections for COM1/2 at the control end and use all three ports via the box's usb connection. I changed the control settings so that "Use USB Com Port as COMx" was set to yes for COM1 and COM2, but neither virtually-assigned port (COM7 and COM5) will work with the same software that works fine using the hardware connections. I checked that the physical ports on the control box stopped working when they were configured for usb, as expected. I also tried changing the properties of the virtual ports to match the hardware port settings, but no luck.

I've tried to get this working on WinXP and W7-64 machines using the latest firmware and setup manager software as of today, but no joy. Any ideas please?

Regards, Mark

I confirm that, for the FT857D, the 8V only appears when the radio is turned on. I strapped pin 2 (8V) to pin 18 (mic pin 3) on the DIL strapping socket and it's working fine :)

A WARNING to anyone else wanting to do this - the voltage is not the same as the mic socket on the FT857D, which only has 5V. Make sure anything you connect is capable of using 8V, or perhaps use a 5V regulator to make sure the voltage is compatible.

Regards, Mark

Thanks Mike,

I saw the IC706 diagram and wondered if that was possible, but when I measured that "PWR (8/9V)" pin with a meter it didn't have any voltage at all. I measured with nothing connected to the Control box other than DC power, so I'm hoping my result is perhaps because 8V is only there when the radio is connected (which will be fine), or something like that?

Regards, Mark

Pages: [1] 2