¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
Date

Moderated Busy but on the Air the odd time

"dave cooper"
 

Just dumped GMFSK 50 CAL into Suse 10.1
no problems as of yet...
have not check all the modes out yet, but I am impressed at all
the work that has been done by all.

Dave
VE3IXI

TNX


Moderated Re: gmfsk.hkj version 50

W2AGN
 

w1hkj wrote:
W2AGN wrote:
I really like the new look, BUT I can't get PTT to work with this version. I
tried the old "vanilla" gmfsk and it keys the serial port FB, but can't get this
one to key the PTT.

John,

Be sure you have the compile flags set properly in the "hkj-config.h" file that
is located in the subdirectory src.

#define WANT_TENTEC_MOD 0
#define TEN_TEC_LOG_PREC 4
#define WANT_KACHINA 0
#define WANT_PTT_MOD 0
#define WANT_WATERFALL_MOD 1
#define WANT_SNRIMD 1
#define WANT_BACKSPACE_MOD 1
#define WANT_1HZFREQ_BUTTON 1
#define WANT_SPINFREQ_ENTRY 0
#define WANT_NEW_UI 1
#define WANT_FREQLOCK 1
#define WANT_CTL_SUPPRESSED 1
#define WANT_2TONE_OLIVIA 1
#define WANT_TTY_MOD 1
#define WANT_FULL_REVERSE 1

Then recompile the program.

Be sure to set the Preferences / PTT dialog for your TTYSx and whether you use
RTS, DTR or BOTH.

Please let me know whether or not this works for you and if not then give me
some particulars about your setup.

Thanks.

Dave (hkj)

That did it! For some reason #define WANT_TENTEC_MOD 0 was set to 1 as was
#define WANT_KACHINA 0. Changing them to 0 got the PTT working.

Thanks,

--
_ _ _ _ _
/ \ / \ / \ / \ / \ John L. Sielke
( W ) ( 2 ) ( A ) ( G ) ( N )
\_/ \_/ \_/ \_/ \_/
"CRUSTY OLD CURMUDGEON - AND PROUD OF IT!"


Moderated Re: gmfsk.hkj version 50

w1hkj
 

¿ªÔÆÌåÓý

W2AGN wrote:
I really like the new look, BUT I can't get PTT to work with this version. I tried the old "vanilla" gmfsk and it keys the serial port FB, but can't get this one to key the PTT.

John,

Be sure you have the compile flags set properly in the "hkj-config.h" file that is located in the subdirectory src.

#define WANT_TENTEC_MOD 0
#define TEN_TEC_LOG_PREC 4
#define WANT_KACHINA 0
#define WANT_PTT_MOD 0
#define WANT_WATERFALL_MOD? 1
#define WANT_SNRIMD 1
#define WANT_BACKSPACE_MOD 1
#define WANT_1HZFREQ_BUTTON 1
#define WANT_SPINFREQ_ENTRY 0
#define WANT_NEW_UI 1
#define WANT_FREQLOCK 1
#define WANT_CTL_SUPPRESSED 1
#define WANT_2TONE_OLIVIA 1
#define WANT_TTY_MOD 1
#define WANT_FULL_REVERSE 1

Then recompile the program.?

Be sure to set the Preferences / PTT dialog for your TTYSx and whether you use RTS, DTR or BOTH.

Please let me know whether or not this works for you and if not then give me some particulars about your setup.

Thanks.

Dave (hkj)





Moderated Re: gmfsk.hkj version 50

W2AGN
 

I really like the new look, BUT I can't get PTT to work with this version. I
tried the old "vanilla" gmfsk and it keys the serial port FB, but can't get this
one to key the PTT.

--
_ _ _ _ _
/ \ / \ / \ / \ / \ John L. Sielke
( W ) ( 2 ) ( A ) ( G ) ( N )
\_/ \_/ \_/ \_/ \_/
"CRUSTY OLD CURMUDGEON - AND PROUD OF IT!"


Moderated Re: gmfsk.hkj version 50

"jhaynesatalumni"
 

--- In linuxham@..., "k9ao" <k9ao@...> wrote:

Might there be any possibility to add the choice to select the new
high-dynamic range waterfall color scheme or the old (hkj 48) scheme
via a stanza in hkj.config.h ?
I was having trouble with the new color scheme, so I wrapped a
#if WANT_WATERFALL_MOD_2 around the place where the old code is
commented out to get a compile-time choice of color schemes.
This is so easy to do that even I got it right on the second try.

Now Dave tells me I need to fiddle with the sliders on the waterfall
preferences to improve the way the new colors work. Right out of the
box the green waterfall is so bright that I have a hard time seeing the
yellow signals and cursors.


Moderated gmfsk.hkj.50

w1hkj
 

A little hint on using the "Ref"erence Level, and "Amp"litude controls located in the right hand side of the main display. If the background is green and the signals bright yellow or red then you probably have the "ref" and "amp" controls set wrong. Both of these controls are in dB. The "ref" is the reference level for the largest signal being received. I find that with my sound card this should be about -10. The "Amp" is the amplitude range over which the signals will be displayed. 80/40/20 signal conditions are such that anything more than 40 to 45 dB of range is far too much. You can see the effect of these controls better in the fast fourier transform "Spectrum" display mode. Adjust the "Ref" control so that the max signal you are receiving is about 2/3 scale. The adjust the "Amp" control so that the noise level is just barely visible at the bottom. Go back to the waterfall and fine tune the controls to give a range of colors to your liking. These controls change very rapidly if you hold the mouse button down (default in gtk, the toolkit used for building the gui stuff). So I recommend just single clicking the up/down buttons.

Dave (hkj)


Moderated Re: gmfsk.hkj version 50

w1hkj
 

Water Fall color scheme.

I will make that a compile switch for now. Eventually there will be a dialog that allows you to adjust the color scheme and see what it will look like in a visual.

Dave


Moderated Re: gmfsk.hkj version 50

"k9ao"
 

--- In linuxham@..., w1hkj <w1hkj@...> wrote:

I change the colors to have a larger dynamic range. That may not suit
your particular setup or vision Jim.

Open the waterfall.c file and look for the following:
<Snip>

Might there be any possibility to add the choice to select the new
high-dynamic range waterfall color scheme or the old (hkj 48) scheme
via a stanza in hkj.config.h ?

That way you could select which scheme you wanted at compile time.

The hkj48 style coloring of thee waterfall looks better on my various
machines also.

Rick Kunath, k9ao


Moderated Re: gmfsk.hkj version 50

w1hkj
 

jhaynesatalumni wrote:

I too missed the part about the hkjconfigure file, used the
regular one, and had to make the Po files by hand.

The other first impression is that the waterfall green seems brighter
than before, and this is making it hard to see the yellow cursor
for the mode.

Remind me again - when the lines in the waterfall turn reddish (on
BPSK for instance) does that mean too much audio? Or is that normal?






Yahoo! Groups Links







.

Jim,

Open the file waterfall.c for editing and find line #175

change it to read:
gdk_color_parse("red", &wf->pointer2col);

I think you find that much easier to see on top of a psk signal than the "yellow". My eyes would strain to see the yellow lines as well.

Let me know if that works for you.

BTW have you tried the freq ref cal function in the KachinaCAT program yet?

Dave


Moderated Re: gmfsk.hkj version 50

Hamish Moffatt
 

On Mon, Jun 05, 2006 at 01:37:07PM -0400, w1hkj wrote:
echo "Creating dominoex dependency directory & files"
mkdir src/dominoex/.deps
touch src/dominoex/.deps/{dominoex,dominoexrx,dominoextx,varicode}.Po
That's odd. With the tarball I released, these get created properly by
configure.

The dominoex Makefile needs to be added into configure.in and then
re-run automake/autoconf. Or just autoreconf. Presumably you had to do
this already just to get this far..

Hamish
--
Hamish Moffatt VK3SB <hamish@...> <hamish@...>


Moderated Re: gmfsk.hkj version 50

w1hkj
 

jhaynesatalumni wrote:

I too missed the part about the hkjconfigure file, used the
regular one, and had to make the Po files by hand.

The other first impression is that the waterfall green seems brighter
than before, and this is making it hard to see the yellow cursor
for the mode.

Remind me again - when the lines in the waterfall turn reddish (on
BPSK for instance) does that mean too much audio? Or is that normal?






Yahoo! Groups Links







.

I change the colors to have a larger dynamic range. That may not suit your particular setup or vision Jim.

Open the waterfall.c file and look for the following:

#if WANT_WATERFALL_MOD
// create color map for waterfall
/* ================================> delete this line
for (i = 0; i < 256; i++) {
guchar r, g, b;

if (i < 128) {
r = 0;
b = 256 - 2 * i;
g = 2 * i;
} else {
r = 2 * (i - 128);
b = 0;
g = 256 - 2 * (i - 128);
}
colormap[i] = (r << 16) + (g << 8) + b;
}
*/ ================================> delete this line
/* ================================> add this line (1)
{
#define max(a,b) (a)>(b)?(a):(b)
#define min(a,b) (a)<(b)?(a):(b)
guchar r, g, b;
gint cntup = 0;
gint cntdwn = 196;
r = 0; g = 0; b = 0;
colormap[0] = (r << 16) + (g << 8) + b;
for (i = 1; i < 128; i++) {
cntup = min(254, cntup + 2);
g = cntup;
cntdwn = max(0, cntdwn - 1);
b = cntdwn;
colormap[i] = (r << 16) + (g << 8) + b;
}
r = 0; g = 254; b = 0;
colormap[128] = (r << 16) + (g << 8) + b;
cntup = 0;
for (i = 129; i < 225; i++) {
cntup = min(254, cntup + 3);
r = cntup;
g = 254;
colormap[i] = (r << 16) + (g << 8) + b;
}
r = 254; g = 254; b = 0;
colormap[225] = (r << 16) + (g < 8) + b;
for (i = 226; i < 256; i++) {
r = 254;
cntdwn = max(0, cntdwn - 4);
g = cntdwn;
colormap[i] = (r << 16) + (g << 8) + b;
}
}
*/ =======================================> add this line (2)
wf->cmap = gdk_rgb_cmap_new(colormap, 256); // color map
#endif

or delete everything between line(1) and line (2) along with the other two line deletions. That will restore the original color map.

Dave


Moderated Re: gmfsk.hkj version 50

"jhaynesatalumni"
 

I too missed the part about the hkjconfigure file, used the
regular one, and had to make the Po files by hand.

The other first impression is that the waterfall green seems brighter
than before, and this is making it hard to see the yellow cursor
for the mode.

Remind me again - when the lines in the waterfall turn reddish (on
BPSK for instance) does that mean too much audio? Or is that normal?


Moderated Re: gmfsk.hkj version 50

w1hkj
 

Rick,

Glad you like the changes ... isn't global development wonderful !

Re: the configure file. Did you try executing the hkjconfigure file instead of the regular configure file? I just tried a fresh build from the download tarball and it worked fine. The contents of the hkjconfigure file are:

#! /bin/sh
# Use this until the automake files are fixed.
# for gmfsk.hkj.50.
#
./configure $*
if [ ! -d src/dominoex/.deps ]; then
echo "Creating dominoex dependency directory & files"
mkdir src/dominoex/.deps
touch src/dominoex/.deps/{dominoex,dominoexrx,dominoextx,varicode}.Po
fi

If you execute something like "./hkjconfigure --enable-hamlib" the script file will pass the parameter list to configure and then create the required directory and files when configure is finished.

Let me know if that doesn't work for you.

Dave (hkj)


Moderated Re: gmfsk.hkj version 50

Rick Kunath
 

David Freese wrote:

A bug patch has been made to the PTT code. If you experience any PTT
problems due to this mod please let me know immediately.
I did a fresh build of the latest hkj 50 version and found that configure still needs the post configure fix from the patches:

There is a bug: configure does not create the depfiles in the
src/dominoex directory for some reason that I can't figure out. A
workaround is to run these after running configure:

mkdir src/dominoex/.deps
touch src/dominoex/.deps/{dominoex,dominoexrx,dominoextx,varicode}.Po

then make as usual.
Other than that, success!

Thanks to all involved with these fantastic improvements.

Rick Kunath, k9ao


Moderated gmfsk.hkj version 50

"David Freese"
 

Is posted !

This version includes the FM-Hell and dominoEX modes. It also patches
the Olivia modem code to free the Olivia modem from the locked 500 Hz
low tone. You can now move your Olivia transmission into the center
of your transceivers passband. This corrects any potential problem
with passband rolloff on the low end of your rigs filters.

A bug patch has been made to the PTT code. If you experience any PTT
problems due to this mod please let me know immediately.

Please send your thanks for the FM-Hell contributions to Joe, KD5ATU.

Please send your thanks for the dominoEX contributions to Hamish, VK5SB.

Both are listed on the group.

The new modes were tested on-air by W1HKJ and KD5ATU. The dominoEX
performed just as expected. If you try the high baud rate modems in
dominoEX be sure your fingers can take the strain of trying to keep up
with the transmission rate.

Dave (hkj)


Moderated Re: Patch: DominoEX support for gMFSK-hkj

w1hkj
 

FB Joe. I have the patches installed, compiled and executing. Look great !!

See you at 7 PM.

Dave


Moderated Re: Patch: DominoEX support for gMFSK-hkj

Rick Kunath
 

Joe Veldhuis wrote:

Well, Hamish posted the much anticipated code for his DominoEX modem to the gmfsk-devel list yesterday. I have "fore-ported" it to the -hkj tree.
Built beautifully here... instructions worked perfectly.

Thanks so much!

Rick Kunath, k9ao


Moderated Re: Patch: DominoEX support for gMFSK-hkj

Joe Veldhuis
 

I will be there. I'll call with DominoEX 11, if it doesn't work then MFSK16.

-Joe, KD8ATU

w1hkj wrote:

You are very much ahead of me my friend. I will apply your latest diff and see how it goes. Perhaps we can do another test on 7.09 MHz this evening at 7 PM.
Dave


Moderated Re: Patch: DominoEX support for gMFSK-hkj

w1hkj
 

Joe Veldhuis wrote:

Well, Hamish posted the much anticipated code for his DominoEX modem to the gmfsk-devel list yesterday. I have "fore-ported" it to the -hkj tree.


This one applies to the hkj48 release WITH the atu4 patch applied.

There is a bug: configure does not create the depfiles in the src/dominoex directory for some reason that I can't figure out. A workaround is to run these after running configure:

mkdir src/dominoex/.deps
touch src/dominoex/.deps/{dominoex,dominoexrx,dominoextx,varicode}.Po

then make as usual. It appears to be working as it should. I did not bother with the Glade stuff, since this branch isn't utilizing it anyway.

-Joe, KD8ATU



Yahoo! Groups Links







.

You are very much ahead of me my friend. I will apply your latest diff and see how it goes. Perhaps we can do another test on 7.09 MHz this evening at 7 PM.

Dave


Moderated Patch: DominoEX support for gMFSK-hkj

Joe Veldhuis
 

Well, Hamish posted the much anticipated code for his DominoEX modem to the gmfsk-devel list yesterday. I have "fore-ported" it to the -hkj tree.


This one applies to the hkj48 release WITH the atu4 patch applied.

There is a bug: configure does not create the depfiles in the src/dominoex directory for some reason that I can't figure out. A workaround is to run these after running configure:

mkdir src/dominoex/.deps
touch src/dominoex/.deps/{dominoex,dominoexrx,dominoextx,varicode}.Po

then make as usual. It appears to be working as it should. I did not bother with the Glade stuff, since this branch isn't utilizing it anyway.

-Joe, KD8ATU