Log4OM

Hi first time poster. Please forgive the nubee question. I attempted to search this forum but did not come up with anything that fit my problems.

I have been a long time FLdigi user and used the XML rig control in FLdigi to communicate with my IC-7600 on COM3.

I really wanted a better Logging program and settled on LOG4OM. This seems like just the thing I was looking for. I intended to use with both FLdigi and LOG4OM to communicate with the rig.

In preparation I switch my FLdigi rig control to Hamlib and had it working without problems. Then I added the 64 bit version of Virtual Serial Ports Emulator and setup a Splitter between the COM3 and COM7. All parameters are the same at 19200 baud, 8 bits, 1 stop.

When I start LOG4OM, I initially get a green CAT light. This lasts for a few seconds and then goes red. At the same time, I get “Radio doesn’t answer to calls? Retry? Y N”.

I have so many new things in this configuration, I am confusing myself.

Can anyone offer some direction? Or suggestions?
I have been at this for 3 days now and I do not appear to be getting anywhere.

Hoping to hear from someone
Thx 73 DE Bill

If you're running rigctld.exe Hamlid daemon from fldigi you should not start hamlib from Log4OM, but only connecting to the existing instance.
On the right side of the hamlib
connection screen check the option to connect to an existing instance, set port and address if not default and connect to the existing session.

I'm not at home these days so I cannot check how fldigi
uses Hamlib but this way works also for remote rigs.
Let us know if it works

Hi Daniele,
Wow, I never expected the #1 man to respond to my problem. Thank You

Last night I was using rigctl, but after your response I switched to rigctld. I am still getting the same disconnect.

Also, I am abit confused. You mention “On the right side of the Hamlib connection screen check the option to connect to an existing instance”

I thought I needed to start rigctld.exe from a cmd/DOS prompt. So, is there another way to start Hamlib?

Bill

Below are the last few lines from -vvvvv rigctld.exe before the crash. Maybe this will help to understand what is going on here.
Bill

read_string(): RX 18 characters
0000 fe fe 7a fe fe 7a e0 fe fe e0 7a 04 00 7a e0 1a
0010 03 fd
write_block(): TX 6 bytes
0000 fe fe 7a e0 04 fd
read_string(): RX 1 characters
0000 fc
fscanf: Bad file descriptor
Connection closed from 127.0.0.1:4455

mmh this is an error coming from the C++ code in Hamlib...
Let me explain how it works with Log4OM:

Hamlib (rigctld.exe) is an executable that act as "daemon": it opens 2 connections (via start parameters provided by Log4OM):
1 connection to the rig, with parameters reported in the start string. You can see those parameters in the long string that appears on the bottom part of the Log4OM connection screen. Those parameters instruct rigctld about the rig, com port, rts, baud rate and so on.
Once this daemon is starded it provides another connection, via TCP, where it will answer to incoming calls from polling softwares like Log4OM and others.

so the line is: Software <-> RIGCTLD <-> RADIO
Of course you can also have Software#2 <-> RIGCTLD <-> RADIO

Log4OM in the connection screen will:
1) start the daemon providing correct parameters
2) connect via TCP to the required port, to start polling

If the daemon is already started, by another software as example, you should not start the daemon again. To do that, simply check the flag on the right box that says: "don't start the daemon, it's already started, please connect to this IP/PORT and you will find an already active daemon".

If daemon is started from omnirig, you should simply connect to the existing active software, withot starting another daemon that will try to use the same com port of the already active one.

Small note:
this way is very useful if you have remote stations. The "parameters string" can be used starting hamlib from a DOS screen with the indicated parameters in another PC. In this case, Log4OM compose the launch string for you: from a DOS screen find the Hamlib folder (it's inside the settings folder) and execute "rigctld.exe <parameters>"

If you start the daemon in a remote PC that is connected with the radio, by knowing the remote PC IP address you can "connect to an active daemon" and control your rig even if remoted.
Log4OM is able to switch PTT, so in a system that will provide voice over IP to the rig, with one of the existing softwares, you can easily control the radio from another continent, if needed.


About your issue:

It seems that hamlib is not correctly interacting with the radio, or the radio is not answering properly.
If you give me the full parameters you're using (rig, baud rate, RTS, CTS, etc) i will try contacting the support or, maybe easier, we will try to find another user with the same rig that could help us

73
Daniele

OK, folks I finally gave up with Hamlib. I just installed OmniRig and it ran first time. I should have switched days ago and stopped pulling the hair out of my head. I'm bald now.

I just need to confirm 1 thing.
I can now change the radio VFO and it reflects on both FLdigi and LOG4OM.
FLdigi will allow me to change the frequency on the rig.
But, while LOG4OM will reflect the change of frequency, I cannot change the rig’s frequency from LOG4OM. Is this normal?

Also, Maybe I was asking for too much, but I thought when I input call letters into FLdigi they would reflect over to LOG4OM. This does not appear to be happening. I have to re-type this information in LOG4OM.

This is no big deal. Maybe I am just too lazy. But, I was hoping.
Any thoughts?

Bill

wm3n wrote:Also, Maybe I was asking for too much, but I thought when I input call letters into FLdigi they would reflect over to LOG4OM. This does not appear to be happening. I have to re-type this information in LOG4OM.

Read the section in the manual on interfacing Fldigi and Log4OM. Fldigi doesn't talk directly with Log4OM; rather, Log4OM reads results out of the Fldigi logfile. Thus, you need to do lookups in Fldigi, save your QSO in Fldigi, and then Log4OM will auto-import it. Once it is in Log4OM, you can open that QSO up and do an "update" to fill in any missing fields or to make any changes you may want.

73

Dave
K3DCW

Plus, Log4OM on import will make a call to HAMQTH/QRZ.COM (if configured) to fill missing data from imported QSO.

In a future we will integrate both software in a better way

73
Daniele IW3HMH

What I don't understand is the 'Retry' prompt. The sequence is:

Using Hamlib
Radio (FT-450) communicating fine.
Turn off the radio.
Log4OM prompts with "RADIO doesn't answer to calls. Retry?"
I click the button for Yes.

Now what I would expect to happen would be that, well. Log4OM would try again but no, it instead opens the "Log4OM CAT" configuration window where I get to try again. And that means I have to Close and then again Open to get comm.s working.

Why do I need to do all that? Why can't the program just do as it says it is going to do and retry? In my case the rig is connected on a real RS-232 comm port so the port still exists. But even if it didn't (USB port) why doesn't Log4OM auto close and open for me like 'Retry' implies?

Thanks for a great program and 73,
Mike / KA4CDN

KA4CDN wrote:What I don't understand is the 'Retry' prompt. The sequence is:

Using Hamlib
Radio (FT-450) communicating fine.
Turn off the radio.
Log4OM prompts with "RADIO doesn't answer to calls. Retry?"
I click the button for Yes.

Now what I would expect to happen would be that, well. Log4OM would try again but no, it instead opens the "Log4OM CAT" configuration window where I get to try again. And that means I have to Close and then again Open to get comm.s working.

Why do I need to do all that? Why can't the program just do as it says it is going to do and retry?

I don't know the reason that Log4OM does not automatically 'Retry' starting Hamlib but it may be that Hamlib do not provide a computer command for that function as Omnirig does. I am sure if it could have been done Lele would have included that facility!

However I would advise changing to the latest version of Omnirig because the auto reconnection works faultlessly and also there is the facility to have two radios connected to Log4OM.

Personally I would like Hamlib removed completely from Log4OM because it is flaky to say the least and does not work satisfactorily with all makes of radios.