开云体育

On Tue, Apr 11, 2006 at 11:46:47AM -0000, David Freese wrote:

Some requested changes to the gmfsk program.

1. "rev" toggle can be enabled for all modes
2. Precision for logging frequency can be specified at compile time.

See the description of mods web page.

Isn't "rev" irrelevant for some modes though, eg Hell & PSK31?

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

Some requested changes to the gmfsk program.

1. "rev" toggle can be enabled for all modes
2. Precision for logging frequency can be specified at compile time.

See the description of mods web page.

Dave (hkj)

Dave,

Just loaded it in and gave it a test run. Everything looks great, as
usual.

Tom (frg)

Improved start up especially for AGC burst noise.

Program can now read and display NRAM critical data from the
transceiver. Does NOT include the ability to write data back to the
transceiver at this time.

Dave (hkj)

Dave and all,

I hope that you can get the help needed from Doug and Dan. Certainly
the best and most knowledgable on the 505.

The only comment I have is with regard to the Smith Chart. The plot
will be basically useless unless a reference plane can be identified.
Seeing the plot is one thing, but where is it with respect to the
load / source.

Great going, you have really come a long way in a very short time.

Tom (frg)




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

w3frg01 wrote:

Dave,

This (Windows)version is working better than ever.
Your two steps ahead of my thoughts on items that you incorporate.
Your pgm has a lot of advantages and ease of use over the original
505.exe pgm.

Thanks! I'm glad to receive good news on the latest revisions.

Looking fwd to the freq cal, if it's on the list of things to do,

hi.

There isn't much after that, or is there ?

Oh yes, many things on the agenda, time permitting. The first

thing I

want to be able to do is read all of the NRAM data and save it to

a

disk file for future uploading back to the transceiver. I think

there

is enough information in the programming specification file, but I

want

to verify the safeness of various commands. I'm hoping that either

Doug

Smith or Dan Kimball will assist me on that front. You know of

Doug,

QEX editor. Dan is listed as one of the Kachina technicians who

still

does repairs on the rigs. I sent him an email request (got a read
receipt) and am waiting for a reply.

Frequency cal is of course on the list. But the specification

sheet is

not very helpful or illuminating.

The data that the transceiver sends regarding the antenna impedance
could be very useful for antenna trimming. The retrieval and

display

(Smith chart or otherwise) should be included in the final product.

Dave

w3frg01 wrote:

Dave,

This (Windows)version is working better than ever.
Your two steps ahead of my thoughts on items that you incorporate.
Your pgm has a lot of advantages and ease of use over the original 505.exe pgm.

Thanks! I'm glad to receive good news on the latest revisions.

Looking fwd to the freq cal, if it's on the list of things to do, hi.
There isn't much after that, or is there ?

Oh yes, many things on the agenda, time permitting. The first thing I want to be able to do is read all of the NRAM data and save it to a disk file for future uploading back to the transceiver. I think there is enough information in the programming specification file, but I want to verify the safeness of various commands. I'm hoping that either Doug Smith or Dan Kimball will assist me on that front. You know of Doug, QEX editor. Dan is listed as one of the Kachina technicians who still does repairs on the rigs. I sent him an email request (got a read receipt) and am waiting for a reply.

Frequency cal is of course on the list. But the specification sheet is not very helpful or illuminating.

The data that the transceiver sends regarding the antenna impedance could be very useful for antenna trimming. The retrieval and display (Smith chart or otherwise) should be included in the final product.

Dave

Dave,

This (Windows)version is working better than ever.
Your two steps ahead of my thoughts on items that you incorporate.
Your pgm has a lot of advantages and ease of use over the original
505.exe pgm.

Looking fwd to the freq cal, if it's on the list of things to do, hi.
There isn't much after that, or is there ?

Tom (frg)



--- In linuxham@..., "David Freese" <w1hkj@...> wrote:

Code cleanup in the function that executes on initial program

startup.

AGC levels at startup should now be the same as when program was

last

used.

Note that you have to select the check box under Menu "Config/Save

on

exit" for the program to bypass the request for serial device dialog
when the proram starts up. This will also save all of the color and
antenna port / frequency band settings that you have configured.

This

will create a file called "kachina.ini" in the directory in the
default directory. ($HOME/.kachina on Linux; directory where
executable is located on Windows).

The state of the program (file called kachina.sta) will always be
saved in the default directory.

The menu item "Files/Save" and "Files/Open" will save and load the
Frequency/Mode pairs in the browser box to the right of the main
frequency display.

Dave (hkj)

A few days late, but better late than never. Happy Birthday Kevin.

My oldest son beat you by 4 days ... same age, born on 1 April ... no
fooling!

Dave (hkj)

Code cleanup in the function that executes on initial program startup.
AGC levels at startup should now be the same as when program was last
used.

Note that you have to select the check box under Menu "Config/Save on
exit" for the program to bypass the request for serial device dialog
when the proram starts up. This will also save all of the color and
antenna port / frequency band settings that you have configured. This
will create a file called "kachina.ini" in the directory in the
default directory. ($HOME/.kachina on Linux; directory where
executable is located on Windows).

The state of the program (file called kachina.sta) will always be
saved in the default directory.

The menu item "Files/Save" and "Files/Open" will save and load the
Frequency/Mode pairs in the browser box to the right of the main
frequency display.

Dave (hkj)

On Thu, Apr 06, 2006 at 07:19:06PM -0000, jhaynesatalumni wrote:

It's popular with the University students here because they have
access to fast networking and they have fast computers. For those
of us with slow networking or slow computers there are other Linux
distributions that are more palatable.

One of the cool things about Linux is that you can get binary-only
code and run it, or you can compile everything yourself from source,
or anything in between.

Be sure to read

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

It's popular with the University students here because they have
access to fast networking and they have fast computers. For those
of us with slow networking or slow computers there are other Linux
distributions that are more palatable.

One of the cool things about Linux is that you can get binary-only
code and run it, or you can compile everything yourself from source,
or anything in between.

Now if you really want pain, there is Linux From Scratch - I haven't
even looked at it, but believe the idea is that you get all the sources
from all the people who actually work on those source components and
bring them together yourself and compile them yourself.

Hi Kevin,

I think you enjoy pain :-)

Are you hanging out on 80 meters?

Dave

On Sun, Apr 02, 2006 at 12:41:08AM +1100, Hamish Moffatt wrote:

Couple of questions about the waterfall mod. Is it selected to
be colour at compile-time only, ie you can't choose between the
old gray mode and the new colour mode at runtime?

Dumb question; of course this works. At first it looked wrong in
gray mode, but that was due to my waterfall settings.


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

Hi Dave,

Couple of questions about the waterfall mod. Is it selected to
be colour at compile-time only, ie you can't choose between the
old gray mode and the new colour mode at runtime?

Also with only WANT_WATERFALL_MOD enabled gmfsk-hkj.47 won't
compile, there are a couple of bits in main.c that should be
inside WANT_NEW_UI but aren't (set_wfmode and set_wfzoom calls).

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

On Thu, Mar 30, 2006 at 09:49:11PM -0500, w1hkj wrote:

Hamish Moffatt wrote:

I'd really like to see multiple receive in gMFSK - like Digipan does for
PSK31 on Windows. You can decode two signals at once, and choose which
of the two frequencies you will transmit on.

I have been asked to consider this in the past Hamish. The answer is
that is will require a considerable amount of re-write in the way that
the waterfall and signal decode are linked. To make it a little worse,
some of the modes are written in C++ using templates and others in
straight C. I have also been asked to consider coding DominoEX into
gmfsk. So I am making a list of priorities for gmfsk-hkj. I think it
will be fair to let the user community decide which I should dedicate my
spare time to. It would really help if there was a second coder willing
to work on it. Do you know of anyone else who has make changes to gmfsk
beside Tomi, myself and Lawrence, VE7IT?

Well I admit I would be interested in newer modes like DominoEX more
than multiple receive I think..

I have not modified the code myself but I have started to understand it
recently while stealing ideas for another project. I am not a DSP wizard
though.

If you publish your wishlist I might offer to work on some parts.
Also I would like to get some of the changes merged into Tomi's official
code and intend to do some work on that.

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

Hamish Moffatt wrote:

Dave,

I'd really like to see multiple receive in gMFSK - like Digipan does for
PSK31 on Windows. You can decode two signals at once, and choose which
of the two frequencies you will transmit on.

I did ask Tomi about this once and it sounded like a significant
redesign of the architecture would be required.


Hamish

I have been asked to consider this in the past Hamish. The answer is that is will require a considerable amount of re-write in the way that the waterfall and signal decode are linked. To make it a little worse, some of the modes are written in C++ using templates and others in straight C. I have also been asked to consider coding DominoEX into gmfsk. So I am making a list of priorities for gmfsk-hkj. I think it will be fair to let the user community decide which I should dedicate my spare time to. It would really help if there was a second coder willing to work on it. Do you know of anyone else who has make changes to gmfsk beside Tomi, myself and Lawrence, VE7IT?

Dave

Dave,

I'd really like to see multiple receive in gMFSK - like Digipan does for
PSK31 on Windows. You can decode two signals at once, and choose which
of the two frequencies you will transmit on.

I did ask Tomi about this once and it sounded like a significant
redesign of the architecture would be required.


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