"Leigh L. Klotz Jr"

OK, I got it.  The tuning is really difficult.

Leigh L. Klotz Jr wrote:

Show quoted text

Dave,
I could not copy Olivia 16/500 on 40m just now, but could with your most recent gmfsk.
The SNR reported from GMFSK was 32.
Leigh/WA5ZNU

Re: On air tests of fldigi 0.941 beta

"Leigh L. Klotz Jr"

#345

Dave,
I could not copy Olivia 16/500 on 40m just now, but could with your most recent gmfsk.
The SNR reported from GMFSK was 32.
Leigh/WA5ZNU

fldigi waterfall shape

"Leigh L. Klotz, Jr."

#344

There's something a little different about the fldigi waterfall, not just in the recent 0.941b.
It seems less distinct when compared to the gmfsk waterfall and the Windows programs.
Is there a windowing step that's omitted or something?

Leigh/WA5ZNU

Re: On air tests of fldigi 0.941 beta

"Leigh L Klotz, Jr."

#343

Dave,
Have you seen the Visual CQ for PSK that I did?
I think Patrick did a mode indicator for Olivia and I believe MixW has something similar, showing you the mode as an "image" in the power spectrum, using the same bandwidth as the mode.
73,
Leigh/WA5ZNU

Show quoted text

On Tue, 12 Sep 2006 5:17 pm, w1hkj wrote:
I called CQ earlier in the day on DominoEX-11 and got a HUH response on
MFSK-16.  A lot of hams do not recognize the sound of dominoex..

On air tests of fldigi 0.941 beta

w1hkj

#342

Joe, KD8ATU, and I were able to confirm the correct operation of MFSK-8 this evening on 40 meters.  He was running MultiPsk at his club station when I heard him call CQ on PSK-31.  He must have thought I was lying in wait for him ... I was!

So we ran about an hour of tests in the following modes:  Psk-31, MFSK-8, DominoEX-11 and Olivia 8/500.  No glitches, no seg faults during the test.
MFSK-8 and DominoEX-11 were about equal in performance as far s/n was concerned.  But the baud rate for DominoEX-11 was much faster than MFSK-8.  I am a good typist but I put a strain on my finger performance.  I personally do not like the sound of Olivia ... stresses my hearing aids.  DominoEX is almost musical and pleasant to listen to.

I called CQ earlier in the day on DominoEX-11 and got a HUH response on MFSK-16.  A lot of hams do not recognize the sound of dominoex, but I think that will change with time.  Probably a good idea to start out in the MFSK mode and then request a shift to dominoex if the other ham can do it.

Enjoy the latest revision Folks

73s, Dave, W1HKJ

gMFSK-hkj version 0.53 is posted

w1hkj

#341

开云体育

The MFSK fixes discovered during the fldigi developement have been retrofitted to gMFSK.

MFSK-8 now works correctly with IZ8BLY's Stream.
The AFC implementation now works ... it really never did much in the original gMFSK.? This should make it a lot easier to tune in the MFSK signal on the waterfall.

Hamish:? Please note that these fixes do not require any special #define.? You should be able to port them to the Debian gmfsk image without any difficulty.? The same applies to the simplifications that I made in the dominoetx.c file.

73's,? Dave? W1HKJ

Re: Fldigi Version 0.94 beta posted

w1hkj

#340

开云体育

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

Re: fldigi feature request

"Leigh L Klotz, Jr."

#339

Maybe just show them when the mouse is over the waterfall? The enter and exit events should be cheap.  People will learn...

Show quoted text

On Tue, 12 Sep 2006 5:04 am, Rick Kunath wrote:
I was tuning some weak MFSK16 signals last night on 40 and have a
request about tuning markers.

I really like the way there are no vertical markers in the waterfall on
fldigi now as compared to gMFSK, and I like that there are no mouse
vertical markers too (permanent or mouse tuning markers), especially
nice is seeing the red area move with AFC action as the signal changes.
So I wouldn't want to alter this behavior normal fldigi in any way.

With the weak MFSK type signals, I was having trouble getting the tuning
right because of the tone indicators on the waterfall being all over the
place as they changed with data. You have to line up the end tone with
the left (or right depending on mode) side of the marker. On PSK or
other continuous modes this is really easy. On MFSK (and others like it)
modes it isn't that easy. With the old mouse vertical markers, you had a
marker that would extend down the height of the waterfall and all you
had to do was put the left hand marker in the center of the desired
tone, and you were all set. This worked great for Olivia, too. Since the
tuning line extended down the height of the waterfall, you could just
find the desired tone down the waterfall and center the line over it and
click.

Would there be any way to have, say the shift key (or any other method),
cause the yellow vertical movable mouse tuning lines to drop down across
the waterfall (gMFSK style) temporarily while the shift was pressed and
the cursor was in the waterfall area? That way you could press shift and
see the lines while you were tuning hard to tune signals, while still
having all of the desirable features of the regular way of seeing the
waterfall with no lines when tuning was done.

What do others think?

Rick Kunath, k9ao




Yahoo! Groups Links

Re: Fldigi Version 0.94 beta posted

"Leigh L Klotz, Jr."

#338

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

Show quoted text

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

Fldigi version 0.941 beta posted

w1hkj

#337

Still had some repairs to make in the RTTY & DominoEX modems re the CR/LF problem.  It would be so simple if everything was Unix or Windows or Apple compliant.

But MSDOS/WINDOWS apps send CR/LF pairs, Unix/Linux send LF and Apple send CR. 

If you find any other CR/LF glitches let me know.

You will find a toggle for CR-CR-LF pairs on the RTTY configuration tab.  This is only for when you are transmiting RTTY to a person who is receiving on one of the old mechanical machines.  The extra CR is to give the physical carriage time to return before you start jamming a new character down its throat.  Don't select this unless you know the other person needs it or you will be filling up the receiving screen with extra white space.

73s, Dave, W1HKJ

Fldigi Version 0.94 beta posted

w1hkj

#336

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

Re: fldigi 0.937 beta posted

Rick Kunath

#335

w1hkj wrote:
Leigh, WA5ZNU, reported having problems with cpu% usage, so I took another hard look at the waterfall code.
Overall CPU usage is way down on the old 600 MHz Mandrake 10.1 machine I test with here at work.

Color waterfall and normal speed is about 45% total, and B&W waterfall and slow speed is about 25% total.

Very significant reductions.

Rick Kunath, k9ao

Re: fldigi feature request

Rick Kunath

#334

w1hkj wrote:
I will give consideration to your request, but the answer might be automation.I hadn't thought about automating the acquisition to handle the tuning errors. I think you are right. This might be a superior solution.

I've tried DominoEX, and agree about it's superiority.

Thanks again.

Rick Kunath, k9ao

Re: fldigi feature request

w1hkj

#333

I considered and tried implementing something similar to what you have suggested Rick.  It seems like such a trivial thing to implement, but drove the waterfall processing over the top.  Perhaps it has to do with the way I tried to implement it.  I can go back and see if I can build an overlay cursor similar to what gMFSK does.

The real answer is in better signal acquisition in all of the MFSK modes including MFSK-8/16, DOMINOEX AND OLIVIA.  The AFC loops only operate correctly if you are positioned correctly within the 3 Hz frequency bin.  DominoEX is very forgiving and you can be outside the window and it still decodes.  Olivia is a little less demanding than either MFSK-8 or 16.  BTW have you tried the DominoEX modes?  They are superb and much better than MFSK from both a tuning and s/n viewpoint.

I will give consideration to your request, but the answer might be automation.

73's, Dave  W1HKJ

fldigi 0.937 beta posted

w1hkj

#332

Leigh, WA5ZNU, reported having problems with cpu% usage, so I took another hard look at the waterfall code.

Incremental changes, but I have managed to cut the cpu usage down.  You will not see much change in the fldigi cpu%, but the X-free server cpu% should be significantly lower.

On my 1.6 GHz Athalon, "top" reports the following:

CPU %  22 %
Xfree  17 %
fldig 5 %

When operating in PSK31, NORM waterfall drop speed.

This is very close to what I observe when making the same test with gMFSK.

73s, Dave, W1HKJ

fldigi feature request

Rick Kunath

#331

I was tuning some weak MFSK16 signals last night on 40 and have a request about tuning markers.

I really like the way there are no vertical markers in the waterfall on fldigi now as compared to gMFSK, and I like that there are no mouse vertical markers too (permanent or mouse tuning markers), especially nice is seeing the red area move with AFC action as the signal changes. So I wouldn't want to alter this behavior normal fldigi in any way.

With the weak MFSK type signals, I was having trouble getting the tuning right because of the tone indicators on the waterfall being all over the place as they changed with data. You have to line up the end tone with the left (or right depending on mode) side of the marker. On PSK or other continuous modes this is really easy. On MFSK (and others like it) modes it isn't that easy. With the old mouse vertical markers, you had a marker that would extend down the height of the waterfall and all you had to do was put the left hand marker in the center of the desired tone, and you were all set. This worked great for Olivia, too. Since the tuning line extended down the height of the waterfall, you could just find the desired tone down the waterfall and center the line over it and click.

Would there be any way to have, say the shift key (or any other method), cause the yellow vertical movable mouse tuning lines to drop down across the waterfall (gMFSK style) temporarily while the shift was pressed and the cursor was in the waterfall area? That way you could press shift and see the lines while you were tuning hard to tune signals, while still having all of the desirable features of the regular way of seeing the waterfall with no lines when tuning was done.

What do others think?

Rick Kunath, k9ao

Re: Version 0.936b posted

Rick Kunath

#330

Leigh L. Klotz, Jr. wrote:
I'm seeing 100% on the previous release too...I haven't isolated it yet.
For what it's worth, I am not seeing the 100% CPU usage here on either the old and slow 600 MHz Mandrake 10.1 machine )50-65% depending on waterfall speed and color or B/W) or a 3 GHz machine running Mandriva 2006 (20-30%).

Rick Kunath

Re: Version 0.936b posted

"Leigh L. Klotz, Jr."

#329

I'm seeing 100% on the previous release too...I haven't isolated it yet.

Leigh L. Klotz, Jr. wrote:

Show quoted text

I get 100% CPU utilization on this version.  When I naively run it under GDB, type ^C, and where, it's always in innards().
I don't remember how to select the other threads.

The previous version showed 100% CPU only when I zoomed to full screen, probably because that happened to place the mouser over the waterfall.

I already had xft enabled in fltk so I didn't have to recompile it.

Any suggested experiments?

Leigh/WA5ZNU

w1hkj wrote:
  
Nothing huge ... just a few changes requested by testers.

    * Added RstIn to the pop-up list in the received text viewer,
    * Added CW_SWEET_SPOT to the #defines in the file "src/config.h"

73s, Dave, W1HKJ
 
 Yahoo! Groups Links

Re: Version 0.936b posted

"Leigh L. Klotz, Jr."

#328

I get 100% CPU utilization on this version.  When I naively run it under GDB, type ^C, and where, it's always in innards().
I don't remember how to select the other threads.

The previous version showed 100% CPU only when I zoomed to full screen, probably because that happened to place the mouser over the waterfall.

I already had xft enabled in fltk so I didn't have to recompile it.

Any suggested experiments?

Leigh/WA5ZNU

w1hkj wrote:

Show quoted text

Nothing huge ... just a few changes requested by testers.

    * Added RstIn to the pop-up list in the received text viewer,
    * Added CW_SWEET_SPOT to the #defines in the file "src/config.h"

73s, Dave, W1HKJ

Re: NEW PROGRAM ANNOUNCEMENT - FLDIGI 0.92 beta

Ed

#327

w1hkj wrote:
Ed,
From your email it looks like you are having difficulty getting past the ./configure on Fltk.  Is that correct?
I'm not familiar with the Ubuntu distro, but I believe it is based on Debian.  Your path to the X11 libraries is either different or the libraries are missing.  I think it is more likely to be a path problem.
Assuming that the problem is during the pre-compile for Fltk, try looking at the output of
./configure --help
for more infor on the various parameters that can be passed to the configure script.
Can anyone else who is familiar with Ubuntu help Ed?
Dave, W1HKJ
I cannot compile the FLTK, line 1022 is looking for stdlib.h and it is in /usr/include. Root has read/write, groups and user have read permissions. I have no idea how to set the path if needed. What I do not understand ./configure is telling me it has checked for stdlb.h and it says yes. Would anyone care to take a look at my config.log and see if they could help. ??

Ed W3NR