On Sunday 31 January 2010 22:54:10 Chris Bryant wrote:
<snip>
> In summary (at last!) I believe the problem I have is that the 747 can
> communicate with the PC, but does not like the communication.
Chris,
Is your XGG adapter a 'self-powered' (powered from the serial port) converter
from EIA-232 <> TTL? If so, expect problems and erratic behaviour...
Wilbert, PE7T

So I use Hamlib with my Orion, and I use a transverter from time to time,
but my transverter is a dumb device without computer control. So as far as
Hamlib knows, I'm working 10 meters. The necessary translations would have
to be done in the user-level software. The Orion has antenna switching and
a Transverter Enable bit that Hamlib could control, but that's it.
What more did you have in mind?
73 Martin AA6E
On Sun, Jan 31, 2010 at 4:29 PM, Charles Suprin <hamaa1vs@...> wrote:
> Howdy,
>
> Is anyone out there using Hamlib with transverters for VHF+ operation?
> I seem unable to find a reference. Google has failed me.
>
> Thanks.
>
> Charles
> AA1VS
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Hamlib-developer mailing list
> Hamlib-developer@...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>
--
Dr. Martin S. Ewing, AA6E
Member IEEE, URSI, AAS, ARRL
Branford, Connecticut

...and finally
Sorry if this is turning into a long story, I'm trying to present as much
useful info as possible in a clear way - please let me know if that isn't the
case!
I pulled the XGG adapter apart and traced the circuit. It look ok, though the
low voltage applied to the PC's serial port will be 0 volts and not something
-ve as per RS 232 specs. According to the circuit, if I disconnect the 747 and
loop the 747 serial data input and outputs together on the adapter, then
characters from the PC should be echoed. I used a terminal emulator to check,
and it does that ok, so the adapter is basically functional
Looking at voltages with a meter, it appears that DTR is asserted (ie goes to
+ve voltage) when rigctl runs, regardless of whether the dtr_state=ON
parameter is given. So that parameter may not be necessary, and it *should*
work. (Caveat: I'm doing this with a meter at the moment; scope measurement
showing signals will be tricky as they aren't repetitive)
I also rechecked the behaviour using the "real" ttyS0 serial port. This now
gives a timeout rather than the immediate display of Err on the 747 that I
reported before. I have no idea what has changed; I try to be as consistent as
possible when making these tests but something has clearly changed
In summary (at last!) I believe the problem I have is that the 747 can
communicate with the PC, but does not like the communication. The business of
the "I/O err" message following se of the dtr_state=ON parameter looks like a
different problem which appears not to be central as the DTR line is set in any
case and the adapter is powered ok
At this point I will pause and see if there are any comments!
73 Chris g3wie

A small update
[This may just confuse - I am!]
I found another USB-to-serial converter and tried this with the K2 with
dtr_state= on present and absent. The idea is to try and distinguish hardware
from software issues.
Absent: works, sometimes I get timeout (1 in 10 tries)
Present: mostly fails, but with timeout not I/O error. 1 in 10 it works! Once
working it stays working provided I don't quit rigctl
I've recheck the dual USB-to-serial I was using in the previous tests and it's
behaviour is repeatable over 20 iterations
73 Chris g3wie

On Sun, 2010-01-31 at 07:23 -0600, Nate Bargmann wrote:
> Just a caution, the FT-817 is a QRP radio with a maximum output of 5
> Watts. Note that QRP operations is fun and a challenge and I enjoy it.
> That said, a 100 Watt capable radio will assure more reliable contacts
> which is important for the new amateur to build confidence.
Correct. Only 2.5w when using batteries other then the vehicle battery
(ie. AA/lithium... i think). It was suggested on Freenode IRC #hamradio
to use a linear amp. The description is kind of funny, "... for ...
camping and mountain top use."
The FT-857, although not really portable but a compact mobile, offers, I
think the full 100W/50W/25W ... going from memory here. There's no
nifty carry strap, but is small enough to carry around. A whopping ~
$700-800 + more $ with the (required) accessories.
Because of the stronger wattage, the FT-857 seems more idea -- except
for price.
<shrugs> Or, I could buy a few cheap featureless mobile units for $250
ea., remembering I do have to be concerned about RF danger from the
antennas. Got a gut feeling I'm going to literally burn my butt with RF
frequencies with the portable.
The manuf/engineers of this stuff should at least engineer an add-on
unit for the cheaper models for pc-control.
Time to go back to school at MIT!
--
Roger
http://rogerx.freeshell.org

Thanks for the reply, Nate
Before you trouble either yourself or your colleague, I'd feel happier if I do
as much here as I can. On the basis of your observation about failing to open
the serial port, I tried using the dtr_state=ON parameter with the K2 which
*doesn't* use DTR at all. Interestingly it fails with IO error.
So I went back and tried a number of combinations of the two rigs, two serial
ports (USB or "real") and dtr_state parameter. Here is what I found:
K2
rigctl -m 221 -r /dev/ttyUSB0 -C dtr_state=ON -vvvvv fails with IO error
rigctl -m 221 -r /dev/ttyUSB0 -vvvvv works fine
Now I used the real serial port ttyS0 connected to the K2:
rigctl -m 221 -r /dev/ttyS0 -vvvvv works fine
rigctl -m 221 -r /dev/ttyS0 -C dtr_state=ON -vvvvv works fine
So, it seems I can use the usb serial port but not mess with the modem
signals? I checked the groups I'm in as a user: I'm in dialout and I added tty
but no change. I tried su and running as root - again no change. I looked in
/etc/fstab and found
#Make USB Work in Sun VirtualBox
none /proc/bus/usb usbfs devgid=114,devmode=664 0 0
In case that's messing with usb permissions I commented it out, but the I/O
error remains when using the dtr=on with the USB-to-serial and the K2, so I
put it back again
So now I went to try the 747 (The XGG cable's spec says DTR is required to
power the RS232 <-> TTL level shifting)
With the USB->serial converter
rigctl -m 105 -r /dev/ttyUSB1 -C dtr_state=ON -vvvvv fails with I/O error
rigctl -m 105 -r /dev/ttyUSB0 -vvvvv fails with a timeout.
I hadn't tried the second one with -vvvvv before so you get some more output
......
ft747:ft747_init called
rig:rig_open called
ft747:rig_open: write_delay = 50 msec
ft747:rig_open: post_write_delay = 5 msec
ft747: read pacing = 0
TX 5 bytes
0000 00 00 00 00 0e .....
TX 5 bytes
0000 00 00 00 00 10 .....
read_block: timedout after 0 chars
Opened rig model 105, 'FT-747GX'
Backend version: 0.3, Status: Alpha
Rig command: q
rig:rig_close called
ft747:ft747_close called
rig:rig_cleanup called
ft747: _cleanup called
As soon as I plug the XGG converter into the real serial port, I get Err on
the 747 display plus two beeps from the 747. I don't get this with the USB-to-
serial converter plugged into the XGG cable plugged into the 747.
Aaaaargh I think this is a separate problem! I'm now going to take the XGG
converter apart and trace the circuit. That will take a little while so I'm
posting my findings thus far.
I was rather hoping for a workaround along the lines of keeping the XGG cable
happy by pulling the DTR line high externally......
73 Chris g3wie
On Sunday 31 Jan 2010, Nate Bargmann wrote:
> * Chris Bryant <ry@...> [2010 Jan 30 11:20 -0600]:
> > Hi all
> >
> > I've just started to set up hamlib to use it with gredict. rigctl works
> > fine with my Elecraft K2, but I'm having problems connecting to my
> > FT-747. Details:
> >
> > - linux debian sid (sidux distribution up to date as of end Dec09),
> > kernel 2.6.31 running on AMD AM2 dual core w/2G memory
> > - dual USB-serial converter - both ports work ok on the K2 and looped to
> > each other
> > - XGG cable/adapter (new) for RS232 - FT-747 CAT
> > - hamlib 1.2.9 from the debian repository
>
> As near as I can tell, no ft747 updates since 1,2,9 so trying a
> daily SVN snapshot won't improve anything.
>
> > Behaviour is:
> >
> > rigctl -m 105 -r /dev/ttyUSB1 -C dtr_state=ON -vvvvv
>
> Is dtr_state=ON required?
>
> > rigctl, Hamlib version 1.2.9
> > Report bugs to <hamlib-developer@...>
> >
> > rig:rig_init called
> > rig: loading backend yaesu
> > yaesu: initrigs2_yaesu called
> > rig_register (121)
> > rig_register (127)
> > ...
> > ..lots more of these
> > ...
> > rig_register (119)
> > rig_register (118)
> > rig_register (126)
> > ft747:ft747_init called
> > rig:rig_open called
> > rig_open: error = IO error
>
> As near as I can tell it's failing to open the serial port. Since the
> K2 works I think we can rule out a permissions problem on a device
> file.
>
> > The Ft-747 beeps twice - no change to the display.
>
> Odd.
>
> > I can't guarantee the XGG converter or 747 CAT is working, but no reason
> > to suspect them either. Fwiw the above command without the DTR setting
> > gives an Err on the 747 display so I have a couple of indications that it
> > is at least listening.
> >
> > Any suggestions welcome
>
> I think I could get my hands on a FT-747 if a coworker still has his.
> Otherwise this is going to be a bit difficult.
>
> 73, de Nate >>
>

On Sat, 2010-01-30 at 21:05 -0600, Nate Bargmann wrote:
> I purchased a CAT cable from a gent in the UK off eBay for my '817.
> Yes, it has a mini-DIN like a PS/2 mouse connector, two actually, and
> it's easy to get them mixed. The other I use with the Signalink.
Your insight is correct. I was concerned whether or not I would have
ability for these additional features... didn't want to specify any
terminology as I might have easily confused readers (or myself ;-)
I usually have parallel ports disabled and prefer the serial port. But
on the flip, parallel won't bend or break as easy as the tiny DIN pins.
Kenwood as used parallel in the past, but I think on their recent models
now use DIN's.
> > I'll reiterate for historical purposes on this mailing list, for Yaesu,
> > models FT-817, FT-857, FT-897 have control support (using software).
> > And, I would imagine the protocols are likely very similar to the
> > already supported Yaesu's within hamlib's supported radio's database.
>
> Those three models are similar but like most Yaesu radio models aren't
> interchangable hence why each backend is its own implementation. With
> a lot of effort they could probably be combined but I doubt the amount
> of programmer time required would make an appreciable difference in RAM
> usage or performance.
Usually manufacturers use similar chips, etc, so implementing s/w is
easier. But what you're saying, is completely different -- probably due
to the quality demands of amateur radio.
(No biggy about the address. It just freaked me out at first since I
assumed mailing lists only strip the headers -- but if it freaked me
out, rest assured, others will likely freak-out.)
>From what I currently see though, this 817 is probably the desired
model, the only downside would be the combination of all bands into one
unit. For my purposes though, it might be an ideal unit.
Like I said, if I find I make lots of use of this radio stuff,
especially being in rural Alaska, I'll likely buy & install the mobile
units around the house/vehicles. As well as providing debug support for
hamlib.
Appreciate your time, Nate, responding to my posts! Thank You!
--
Roger
http://rogerx.freeshell.org

* Nate Bargmann [2010 Jan 30 21:06 -0600]:
Changed to remove the address from the replies.
73, de Nate >>
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://n0nb.us/index.html

* Roger <rogerx@...> [2010 Jan 30 20:28 -0600]:
> On Sat, 2010-01-30 at 09:56 -0600, Nate Bargmann wrote:
> > * Roger
>
> FYI NATE; You're emailer is publishing our email addresses? .. or is
> this caused by hamlib's mailing list's? ... just caught this now, and by
> quickly looking at the hamlib mailing list past history from November -
> I have in my folder.
The Source Forge archive truncates email addresses it finds. Take a
look here:
https://sourceforge.net/mailarchive/forum.php?thread_name=20100130155640.GT12941%40n0nb.us&forum_name=hamlib-developer
I'm unaware of this list being archived elsewhere so I think your
address is safely hidden from public view.
> > Unfortunately, the handheld/mobile FM radios don't have provisions for
> > CAT control. I spend my time in the Yaesu area and know for certain
> > that their FM only radios do not have CAT capabilities. Kenwood or
> > Icom could be different.
>
> CAT, I presume simple cat/echo -- or somebody is poking pun at my
> programming ability. ;-)
Computer Aided Transceiver. Originally a Yaesu marketing term, we
apply it generically.
> > That said, their all band all mode units such as the FT-857, FT-897,
> > and FT-817 do have CAT capability and Hamlib supports them quite well.
> > The FM only rigs generally have a "clone" feature and with some reverse
> > engineering might be PC controllable by emulating the clone feature.
> > As I understand it, that feature is more of a raw memory read/write
> > operation and isn't really compatible with Hamlib as it is presently
> > written (I'm not sure I'd want to debug *that*!).
>
> I know what "clone" is, and it may or may not be able to hacked to
> provide control.
>
> I looked at the FT-817 (handheld/portable) & FT-857 (mobile)... the
> FT-817 looks like a pretty good choice, but @ $600. A brief look shows
> it has a simple din to serial output. No idea if it has the additional
> outputs for other extensive use/features.
I purchased a CAT cable from a gent in the UK off eBay for my '817.
Yes, it has a mini-DIN like a PS/2 mouse connector, two actually, and
it's easy to get them mixed. The other I use with the Signalink.
> I'll reiterate for historical purposes on this mailing list, for Yaesu,
> models FT-817, FT-857, FT-897 have control support (using software).
> And, I would imagine the protocols are likely very similar to the
> already supported Yaesu's within hamlib's supported radio's database.
Those three models are similar but like most Yaesu radio models aren't
interchangable hence why each backend is its own implementation. With
a lot of effort they could probably be combined but I doubt the amount
of programmer time required would make an appreciable difference in RAM
usage or performance.
73, de Nate >>
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://n0nb.us/index.html

On Sat, 2010-01-30 at 09:56 -0600, Nate Bargmann wrote:
> * Roger
FYI NATE; You're emailer is publishing our email addresses? .. or is
this caused by hamlib's mailing list's? ... just caught this now, and by
quickly looking at the hamlib mailing list past history from November -
I have in my folder.
> > Any suggestions on make & model of a first transceiver - 2m/70c Dual
> > Band?
>
> Hi Roger. Welcome to amateur radio!
In another month or so I should be licensed.
> >From a radio standpoint any of them will work well. The main
> differences being in various proprietary features that most hams will
> never use.
Ditto. Think the only feature I'll probably use is the button on the
mic once in a blue moon!
> Unfortunately, the handheld/mobile FM radios don't have provisions for
> CAT control. I spend my time in the Yaesu area and know for certain
> that their FM only radios do not have CAT capabilities. Kenwood or
> Icom could be different.
CAT, I presume simple cat/echo -- or somebody is poking pun at my
programming ability. ;-)
> That said, their all band all mode units such as the FT-857, FT-897,
> and FT-817 do have CAT capability and Hamlib supports them quite well.
> The FM only rigs generally have a "clone" feature and with some reverse
> engineering might be PC controllable by emulating the clone feature.
> As I understand it, that feature is more of a raw memory read/write
> operation and isn't really compatible with Hamlib as it is presently
> written (I'm not sure I'd want to debug *that*!).
I know what "clone" is, and it may or may not be able to hacked to
provide control.
I looked at the FT-817 (handheld/portable) & FT-857 (mobile)... the
FT-817 looks like a pretty good choice, but @ $600. A brief look shows
it has a simple din to serial output. No idea if it has the additional
outputs for other extensive use/features.
I'll reiterate for historical purposes on this mailing list, for Yaesu,
models FT-817, FT-857, FT-897 have control support (using software).
And, I would imagine the protocols are likely very similar to the
already supported Yaesu's within hamlib's supported radio's database.
Anybody with experience with Kenwood handheld/mobiles? Not supported as
they can only be put into a "clone mode"?
I won't get into ICOM simply because, as already documented, no
protocols are documented.
--
Roger
http://rogerx.freeshell.org

* Chris Bryant <ry@...> [2010 Jan 30 11:20 -0600]:
> Hi all
>
> I've just started to set up hamlib to use it with gredict. rigctl works fine
> with my Elecraft K2, but I'm having problems connecting to my FT-747. Details:
>
> - linux debian sid (sidux distribution up to date as of end Dec09), kernel
> 2.6.31 running on AMD AM2 dual core w/2G memory
> - dual USB-serial converter - both ports work ok on the K2 and looped to each
> other
> - XGG cable/adapter (new) for RS232 - FT-747 CAT
> - hamlib 1.2.9 from the debian repository
As near as I can tell, no ft747 updates since 1,2,9 so trying a
daily SVN snapshot won't improve anything.
> Behaviour is:
>
> rigctl -m 105 -r /dev/ttyUSB1 -C dtr_state=ON -vvvvv
Is dtr_state=ON required?
> rigctl, Hamlib version 1.2.9
> Report bugs to <hamlib-developer@...>
>
> rig:rig_init called
> rig: loading backend yaesu
> yaesu: initrigs2_yaesu called
> rig_register (121)
> rig_register (127)
> ...
> ..lots more of these
> ...
> rig_register (119)
> rig_register (118)
> rig_register (126)
> ft747:ft747_init called
> rig:rig_open called
> rig_open: error = IO error
As near as I can tell it's failing to open the serial port. Since the
K2 works I think we can rule out a permissions problem on a device
file.
> The Ft-747 beeps twice - no change to the display.
Odd.
> I can't guarantee the XGG converter or 747 CAT is working, but no reason to
> suspect them either. Fwiw the above command without the DTR setting gives an
> Err on the 747 display so I have a couple of indications that it is at least
> listening.
>
> Any suggestions welcome
I think I could get my hands on a FT-747 if a coworker still has his.
Otherwise this is going to be a bit difficult.
73, de Nate >>
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://n0nb.us/index.html

Hi all
I've just started to set up hamlib to use it with gredict. rigctl works fine
with my Elecraft K2, but I'm having problems connecting to my FT-747. Details:
- linux debian sid (sidux distribution up to date as of end Dec09), kernel
2.6.31 running on AMD AM2 dual core w/2G memory
- dual USB-serial converter - both ports work ok on the K2 and looped to each
other
- XGG cable/adapter (new) for RS232 - FT-747 CAT
- hamlib 1.2.9 from the debian repository
Behaviour is:
rigctl -m 105 -r /dev/ttyUSB1 -C dtr_state=ON -vvvvv
rigctl, Hamlib version 1.2.9
Report bugs to <hamlib-developer@...>
rig:rig_init called
rig: loading backend yaesu
yaesu: initrigs2_yaesu called
rig_register (121)
rig_register (127)
...
..lots more of these
...
rig_register (119)
rig_register (118)
rig_register (126)
ft747:ft747_init called
rig:rig_open called
rig_open: error = IO error
The Ft-747 beeps twice - no change to the display.
I can't guarantee the XGG converter or 747 CAT is working, but no reason to
suspect them either. Fwiw the above command without the DTR setting gives an
Err on the 747 display so I have a couple of indications that it is at least
listening.
Any suggestions welcome
Thanks, Chris g3wie

* Roger <rogerx@...> [2010 Jan 30 07:17 -0600]:
> Hi All.
>
> Looking at getting my first dual band transceiver. Likely a portable as
> Gordon suggests, even though I prefer mounted mobile units as they don't
> fall all over the place when unattended.
>
> >From what I've seen; Icom, Kenwood & Yaesu are the three major
> manufactures of ham or amateur radio transceivers. Kenwood & Yaesu are
> probably the likely choice as Icom doesn't publish their protocol
> details.
>
> Any suggestions on make & model of a first transceiver - 2m/70c Dual
> Band?
Hi Roger. Welcome to amateur radio!
>From a radio standpoint any of them will work well. The main
differences being in various proprietary features that most hams will
never use.
> Up here in in rural Alaska, already know I'll need an outside antenna,
> batteries, etc. And, I have little time for programming these days, but
> may within the next few years if I get more time. So making sure I have
> a good supported radio with published protocols will aid me in the
> future if I keep the hobby and buy several mobile/base units --
> especially radio is the primary method of communication when in rural
> areas.
>
> Looking at the "Supported Radios" page, it looks like all the models
> listed are base stations. Would be great to see the listed radio models
> on that page further categorized as "hand held", "mobile", or "base".
> Took me an hour or so to find each one, only to see the three
> manufacturers where all base.
>
> My quick guess is, even though though a hand held isn't mentioned as
> supported, it likely uses similar serial functions/protocols as a
> manufacturers base model.
Unfortunately, the handheld/mobile FM radios don't have provisions for
CAT control. I spend my time in the Yaesu area and know for certain
that their FM only radios do not have CAT capabilities. Kenwood or
Icom could be different.
That said, their all band all mode units such as the FT-857, FT-897,
and FT-817 do have CAT capability and Hamlib supports them quite well.
The FM only rigs generally have a "clone" feature and with some reverse
engineering might be PC controllable by emulating the clone feature.
As I understand it, that feature is more of a raw memory read/write
operation and isn't really compatible with Hamlib as it is presently
written (I'm not sure I'd want to debug *that*!).
73, de Nate >>
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://n0nb.us/index.html

Hi All.
Looking at getting my first dual band transceiver. Likely a portable as
Gordon suggests, even though I prefer mounted mobile units as they don't
fall all over the place when unattended.
>From what I've seen; Icom, Kenwood & Yaesu are the three major
manufactures of ham or amateur radio transceivers. Kenwood & Yaesu are
probably the likely choice as Icom doesn't publish their protocol
details.
Any suggestions on make & model of a first transceiver - 2m/70c Dual
Band?
Up here in in rural Alaska, already know I'll need an outside antenna,
batteries, etc. And, I have little time for programming these days, but
may within the next few years if I get more time. So making sure I have
a good supported radio with published protocols will aid me in the
future if I keep the hobby and buy several mobile/base units --
especially radio is the primary method of communication when in rural
areas.
Looking at the "Supported Radios" page, it looks like all the models
listed are base stations. Would be great to see the listed radio models
on that page further categorized as "hand held", "mobile", or "base".
Took me an hour or so to find each one, only to see the three
manufacturers where all base.
My quick guess is, even though though a hand held isn't mentioned as
supported, it likely uses similar serial functions/protocols as a
manufacturers base model.
--
Roger
http://rogerx.freeshell.org

* Martin Ewing <martin.s.ewing@...> [2010 Jan 25 09:26 -0600]:
> Absolutely! And while we're at it, thanks to Nate and Stephane for their
> untiring leadership on the Hamlib project!
Welllll, errrr, ummmmm. Thanks, Martin!
I just tinker around the edges while Stephane takes care of the cool
stuff.
73, de Nate >>
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://n0nb.us/index.html

Unnoticed by me but probably well known by everyone else was that back
in early June Stephane committed a patch to autogen.sh that aimed to
test for Libtool v1 or v2. Most likely this had to do with the flaky
"digest" nature of the CVS commit mailing list that may wait days or
weeks before it queues out a message. At any rate, I stumbled on this
completely by accident over the weekend. As I no longer have a system
with Libtool v1 running around here, I've been using the newer
autogen.sh without error except for my shell puking on a variable
assignment that I quoted and committed.
As the current autogen.sh appears to be working for at least my Libtool
v2 systems, I've edited autofixer.sh so that it will only take any
action if a Libtool v1 is found. I've also edited README.developer to
advise that running autofixer.sh may not be necessary at all and that
anyone still tied to Libtool v1 should try autogen.sh first and then
only if that fails to use autofixer.sh (and report the error to this
list).
I propose committing my changes to autofixer.sh and removing
autogen.sh.ltv2 from the repository to avoid it being used in place of
autogen.sh.
Thoughts?
73, de Nate >>
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://n0nb.us/index.html

* sco@... <sco@...> [2010 Jan 25 06:02 -0600]:
> Is anyone working on a radio setup for the Elecraft K-3 radio?
My understanding is that the Elecraft radios follow the Kenwood radios
quite closely. Is this not the case? Otherwise, I don't know of
anyone that has come forward with Electraft specific code for Hamlib.
We are always looking for volunteers and patches. :-)
73, de Nate >>
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://n0nb.us/index.html

* mrtembry <mrtembry@...> [2010 Jan 23 13:56 -0600]:
> I am no longer participating in any further hamlib development.
> Please release me from any further hamlib develement.
Sorry to see you go, Terry. Your work has been most appreciated and
very valuable to the project.
Should you change your mind in the future, do not hesitate to jump back
in. I'll honor your request.
73, de Nate >>
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://n0nb.us/index.html

I recently picked up a used 450. As a long time fldigi user and alpha
tester I was disappointed to find that I could not get hamlib to work.
Using the xml under fldigi or Dave's flrig it all just worked. Put
hamlib on the back burner, until a user asked for help getting hamlib
and the 450 working.
I dropped a note to Nate N0NB, he pointed me to the latest SVN to see if
I had better luck with the 450. Here is some of my findings ::
1. PTT via software works. Previously this did not work with the rig in
the "Data" mode (user-u/l). This was left out by Yaesu for some unknown
reason, but was added in their latest firmware update.
2. I see the bandwidth is hard coded by mode. Would be nice if it was
user selectable, if its a doable.
3. The default timing did not work with my 450. Here are the changes I
made to get it working. This is with 38400 baud and RTS/CTS checked.
Retries = 4
Write Delay = 5
Retry Interval =50
Post write delay = 0 If this was set to anything but 0 the 450 went
into a continous mode changing loop. It was interesting to watch.
Nate asked me to post my findings here. I tried xlog to see if hamlib
would now work there as well. I keep getting a protocol error -8, I'm
not sure if that is an xlog or hamlib problem.
Thanks 73
Ed W3NR