FLDigi Interface

[WH2HAO]

So it doesn't really help to transfer the data if you have to do it twice. True.

[G4POP]

I think we have some confusion here?

Once Log4OM is set up it will check the logbook of FLDigi for any new QSO logged by FLDigi every 30 seconds, if a new QSO is in the FLDigi logbook then Log4OM will grab that QSO and add it to the Log4OM logbook.

Because a physical com port cannot be shared by two programs only FLDigi will display the frequency, mode and band that the rig is tuned to and to a degree FLDigi can control the rig.

However the comport cannot be shared with Omnirig or Hamlib and because they cannot connect to this com port Log4OM is not able to display the frequency, mode and band or control the rig.

Now for an explanation of my second post.

To overcome the above problem it is possible to use a 'Virtual Serial (Com) Port' (VSP) which is a software cable if you like!

The VSP software can be downloaded free for various sources, like Eterlogic, and when installed there are several ways you can configure the VSP software.

For your requirement you would choose a 'Pair' which is like a 'Y' lead in software one end of the 'Y' is the physical com port to which your rig is connected e.g Com 3. The other two legs of the 'Y' are given virtual Com port numbers like Com 25 and Com 26.

Now in FLDigi you select one of the virtual com ports, lets call that Com port 25

In Omnirig you select the other virtual com port, lets call that Cm port 26

Now you have a set up where both programs (FLDigi and Log4OM) can access the frequency, band and mode of the rig at the same time and both programs can control the rig.

So double clicking a spot in the Log4OM cluster will change the rigs frequency, band and mode as normal and this change will be reflected in FLDigi

Also changing the frequency, band and mode in FLDigi will change the rig and this change will be reflected in Log4OM

Change the frequency on the rig and both FLDigi and Log4OM will reflect this change.

Unlike some programs that share data via TCP or UDP which enables Log4OM to obtain all of the available information from the other program, FLDigi does not provide this facility or anything similar, so we cannot communicate with FLDigi apart from reading the logbook that FLDigi creates when you log a QSO in FLDigi.

Hope this clarifies the situation..

73

[IW3HMH]

Daniele, I looked at the import from FLDigi and the items I do not see transferring from FLDigi is the address and locater (grid) even if I have these field populated in FLDigi. All else looks good.
Jeff - N9BBE

Checking that, thanks Jeff

[WH2HAO]

I'm using the Microkeyer 2. I just dont like the lack of integration and cant seam to resolve it. I am not using any rig control. When I enter the call on fldigi, I have to enter it again on log4om to get the call info. Then, every qso, I have to re enter the frequency and band because it changes back to zero after each logging. What am i missing.

[G4POP]

Fldigi reverting to zero frequency is the way it's designed if there is no rig connected, you realy are better with CAT control!

Fldigi does have a built in call lookup system and although not as sophisticated as we have in Log4OM it does work.

The program is getting a bit dated but it remains a firm favourite in the digital world and is up at the top in popularity with Digipan, Winwarbler and the rest.

Many other program's have tried to compete with Fldigi by offering every mode on the face of the earth, like DM780, but few can beat the decoding efficiency of FLdigi.

Daniele will eventually improve the integration with Fldigi and hopefully he will also add MixW support.

73

[N9BBE]

Daniele and Team, awesome job on the latest release (1.12.1). Thanks for smoothing out the data transfer from FLDigi. Everything is coming into LOG4OM quite nicely now. The program continues to reach new heights. Lots of AT-A-BOYS for everyone involved.

Jeff - N9BBE

[IW3HMH]

Next step will be a better integration between FLDigi and Log4OM.
Communicator was made with this purpose: allow me to make highly specialized functions and other things without interfering with log4om main processes and features.
Everything is made on Communicator. Log4OM receives only a data stream with requests and QSO informations

This is the idea

73
Daniele

[K0AY]

I have the ADIF polling set up to my LOG4OM file location as I am successfully logging JT65 and JT9 into my LOG4OM files. In addition, I would like to integrate Fldigi. Can ADIF poll multiple locations? Would it be better to change the fldigi file to the LOG4OM file?
Again, thanks for such great user support.

Art
K0AY

[G4POP]

I have the ADIF polling set up to my LOG4OM file location as I am successfully logging JT65 and JT9 into my LOG4OM files. In addition, I would like to integrate Fldigi. Can ADIF poll multiple locations? Would it be better to change the fldigi file to the LOG4OM file?
Again, thanks for such great user support.

Art
K0AY

If JT65 and JT9 log to an ADIF file and it is possible for you to set the ADIF file path in these program's then it should be possible to log from the FLdigi,JT65 & JT9 software to a common or central ADIF file which Log4OM can then poll from as it does the Fldigi file.

Can't try this myself because I don't use these program's just FLDigi but it should work OK