Loading ...
Sorry, an error occurred while loading the content.

Re: [linuxham] Fldigi Version 0.94 beta posted

Expand Messages
  • w1hkj
    ... That would be nice Leigh, but the two implementations are considerably different even though many of the algorithms are similar. gMFSK uses the struct and
    Message 1 of 3 , Sep 12, 2006
    • 0 Attachment
      Leigh L Klotz, Jr. wrote:

      Dave,
      Why don't you just make a modem library and share it between the two? I
      want to write another psk TCP/IP server anyway, as I did that in gmfsk
      because it had the cleanest modem code, as you discovered as well. Then
      clients will have the option of using the library or the tcp interface
      (a la X).
      Leigh/WA5ZNU
      On Tue, 12 Sep 2006 10:28 am, w1hkj wrote:
      > Yes I did skip a few minor revs. But I think that a sigificant change
      > requires a significant notification.
      >
      > You may have been aware that the MFSK-8 modem code in all revisions of
      > gmfsk, both the original and the gmfsk-hkj variant was broken. That
      > broken code found its way into fldigi. Fldigi could communicate with
      > any other fldigi or gmfsk or vice versa. But not with the rest of the
      > digital modem world. Specifically not with IZ8BLY's Stream or with
      > MultiPsk both of which could transmit and receive on MFSK-8 and 16.
      >
      > The broken algorithm has been discovered and fixed. I bench tested
      > both
      > MFSK-16 and MFSK-8 against both of the Windows applications and it
      > works
      > perfectly. I have been staring at that code for about 4 months and
      > this
      > morning experienced a Eureka !
      >
      > Also went back and took a hard look at the way the AFC was being worked
      > in both gmfsk and fldigi. Fldigi has a new AFC mechanism that works
      > like a champ.
      >
      > Both of these fixes will be retrofitted to gmfsk-hkj in the very near
      > future.
      >
      > Also tested fldigi for proper CR/LF recognition when receiving signals
      > from Windows apps. I think that works as one would expect now. You
      > need to tell me if it does not.
      >
      > 73s, Dave, W1HKJ
      >
      >
      >
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >

      That would be nice Leigh, but the two implementations are considerably different even though many of the algorithms are similar.  gMFSK uses the struct and pseudo object oriented design that is inherent in all gtk/gnome applications.  This is a carry-over from pre-ANSI C++ days.  If you read the blurbs on gtk/gnome they will make that statement.  There is simply too much legacy code for them to make the change from the gtk type of object design to one which is purely C++.  Fldigi is a C++ application from the bottom up (but I do revert to the use of straight structured code when the result works better).  To make one library fit both it would be necessary to build a wrapper around the gMFSK struc's or completely rework the gMFSK code to let work with the C++ modem libraries.  For now it is easier for me to just port the pieces between the two applications.  Building a new modem in either is about the same amount of work.  I simply prefer the C++ paradigm.

      I would be glad to discuss any question you have on the trx, modem & mode specific classes that are in the fldigi source code.  You are of course free to use, modify, etc.  Isn't GPL a wonderful way to create applications and share your work?

      Dave
    Your message has been successfully submitted and would be delivered to recipients shortly.