headers
Joe Barr | 2 Jan 2007 15:54

Hardware or software?


I've been having a tough time getting started with Hamlib and my Kenwood
TS450S.  I seem to be getting spurious and yet not spurious data from
the rig, and sometimes apps like fldigi and grig can query the frequence
and sometimes they can't.

Typically, when I first connect the rig and the PC, the rig appears to
send a single character "?" and rigctl tries to interpret it as the
response to the IF command.

Sometimes a second IF query will get a correct response and grig or
fldigi will then display the freq from the rig, sometimes not.  

I also see rigctl complaining about improperly terminated commands, I
guess meaning, they don't end with an ";".

I've used slsnif and a couple of other serial port sniffers and they all
show the same data coming from the rig as rigctl does with lots of
-vvv's.

I'm wondering now if the problem may be one of flaky rig communications.
Anyone have any thoughts on this?

Thanks,
Joe / K1GPL

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
(Continue reading)

Permalink | Reply | 3 comments |
headers
Nate Bargmann | 2 Jan 2007 19:04

Re: Hardware or software?

On Tuesday 02 January 2007 08:54, Joe Barr wrote:

> I'm wondering now if the problem may be one of flaky rig communications.
> Anyone have any thoughts on this?

Given that you're able to see the same errors outside of the PC, I would say 
that the radio is suspect.  Did the '450 have RS-232 built-in or is an 
interface required?  As I recall, my TS-850 of similar vintage required an 
interface to convert the rig's TTL to RS-232 and vice versa.  So, there could 
be two failure points.

73, de Nate >>

--

-- 
 Wireless | Amateur Radio Station N0NB          |  Successfully Microsoft
  Amateur radio exams; ham radio; Linux info  <at>   | free since January 1998.
             http://www.qsl.net/n0nb/           |  "Debian, the choice of
             My Kawasaki KZ-650 SR  <at>             |     a GNU generation!"
        http://www.networksplus.net/n0nb/       |   http://www.debian.org

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 1 comment |
headers
Joe Barr | 2 Jan 2007 19:14

Re: Hardware or software?

On Tue, 2007-01-02 at 12:04 -0600, Nate Bargmann wrote:
> On Tuesday 02 January 2007 08:54, Joe Barr wrote:
> 
> > I'm wondering now if the problem may be one of flaky rig communications.
> > Anyone have any thoughts on this?
> 
> Given that you're able to see the same errors outside of the PC, I would say 
> that the radio is suspect.  Did the '450 have RS-232 built-in or is an 
> interface required?  As I recall, my TS-850 of similar vintage required an 
> interface to convert the rig's TTL to RS-232 and vice versa.  So, there could 
> be two failure points.

Yes, an interface is required on the 450S.  I am using an eBay special
from radios4you.com which replaces the Kenwood IF-232 interface.  It
plugs into the serial port on the PC and the ACC DIN connection on the
rig.  

I have just ordered a working Kenwood IF-232 interface, so in a week or
so I should know whether or not it's the interface or the rig itself.

Joe 

> 
> 73, de Nate >>
> 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wilbert Knol | 3 Jan 2007 07:55
Picon

Re: Hardware or software?

On Wednesday 03 January 2007 03:54, Joe Barr wrote:

<snip>

> I'm wondering now if the problem may be one of flaky rig communications.
> Anyone have any thoughts on this?

Some 'RS232-powered' level converters receive their supply from the RTS line.
This may result in problems such as the one you describe.

As far as I know, the Hamlib library only activates RTS briefly, for the 
duration of the rig poll. As the rig poll goes out to the rig, the power 
rail(s) of the level converter are still in transit. As a result, the first 
query - and even the second - may be corrupted; the rig replies with 'huh?'  
in CAT language.

You can verify whether this is the problem by testing with 'rigctl', which, I 
believe, activates RST while the program is running.

However, you can _still_ use your dodgy RTS-powered level converter with the 
Hamlib library. Use the RPC rig daemon 'rpcrigd' which grabs the UART and 
activates the RST line full-time.

As a bonus, multiple applications can access the rig at the same time (e.g. 
xdx and your favourite logging software). 

HTH..

Wilbert, ZL2BSJ
(Continue reading)

Permalink | Reply | 0 comments |
headers
Trev Jackson | 3 Jan 2007 15:29

Re: Hardware or software?

Hi Folks,

This sounds a bit like the comms problem I was having using Solaris on a
Sunblade computer trying to communicate with a TS690s using an if-232c
interface.

I tested the comms using minicom and that worked fine sending and receiving
data, but hamlib kept missing data.  What seemed to be happening was that the
longer the data string sent from the radio the more characters got missed
from the end of the character string.  Short responses were received OK.

The comms worked OK when hamlib was run on my Linux PC communicating through
the IF-232c with the TS690s, so it had to be a hamlib problem.

I have been trying to get this working for a friend and he has recently taken
his TS690s and IF-232c interface (and part exchanged them for a better radio)
so I cannot do any tests at the moment.

I altered the code to setup the comms port as in minicom, but that didn't
help, I started trying to work through the comms routines used in minicom
when my friend took his radio away.

As this is obviously something in the code that is causing this problem, it
 is possible that it is the same problem.

Best Regards

Trev

On Wednesday 03 January 2007 06:55, Wilbert Knol wrote:
(Continue reading)

Permalink | Reply | 501 comments |
headers
Chuck Hemker | 3 Jan 2007 23:16
Favicon

Re: Hardware or software?

On Wed, 03 Jan 2007 14:29:21 +0000
Trev Jackson <trev.email <at> btinternet.com> coughed up a hairball and said:

> Hi Folks,
> 
> This sounds a bit like the comms problem I was having using Solaris on
> a Sunblade computer trying to communicate with a TS690s using an
> if-232c interface.
> 
> I tested the comms using minicom and that worked fine sending and
> receiving data, but hamlib kept missing data.  What seemed to be
> happening was that the longer the data string sent from the radio the
> more characters got missed from the end of the character string. 
> Short responses were received OK.
> 

With this problem on Solaris, I'm wondering if the uarts is buffering
too much data and not interrupting often enough.  Some uarts have a 16
or so char buffer and are programmed only to interrupt the system if it
gets several chars or a timeout or an end of line char.

One way to debug this in hamlib would be to drastically increase the
timeout and see if it fixes the problem.  If so, start looking around at
the serial port docs to see if there is any way to either disable the
buffering or switch the end of line char the uart is looking for to the
one the radio sends.

PS Sorry I didn't respond to your earlier message but I've been busy
with other things.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Trev Jackson | 4 Jan 2007 11:37

Re: Hardware or software?

Hi again,

Thanks for the advice, I had already tried increasing the timeout in hamlib 
from one second up to ten seconds and that didn't help.

I'll have to have a bit more of a read of the Solaris documentation to see if 
there is some way of altering the uart buffer settings.  I must admit I found 
it strange that minicom worked OK, but when I copied the code for setting up 
the serial port into hamlib I was still having the comms problem.  I guess I 
must have missed something - perhaps there is something in minicom that 
disables uart buffering.

Although I cannot test it at the moment I'll have a look through the various 
Solaris documents I have downloaded to see if I can find how the buffering of 
the uart is disabled.  I might also take another look at minicom, because 
that seems to work OK.

Thanks again for the suggestions.

Best Regards

Trev

On Wednesday 03 January 2007 22:16, you wrote:
> On Wed, 03 Jan 2007 14:29:21 +0000
>
> Trev Jackson <trev.email <at> btinternet.com> coughed up a hairball and said:
> > Hi Folks,
> >
> > This sounds a bit like the comms problem I was having using Solaris on
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexandru Csete | 7 Jan 2007 16:35
Picon
Picon
Favicon

Linking against hamlib dll

Greetings,

I am trying to cross compile grig to windows target using mingw32.
After spending most of yesterday and today it seems that I have managed
to set up a functional build environment including cross compiled Gtk+
and GLib libraries.

The compilation goes all right but linking fails with following message:

grig-debug.o:grig-debug.c:(.text+0x179): undefined reference to
`__imp__rig_set_debug_callback'
grig-debug.o:grig-debug.c:(.text+0x18f): undefined reference to
`__imp__rig_set_debug_callback'
grig-debug.o:grig-debug.c:(.text+0x277): undefined reference to
`__imp__rig_set_debug'

plus a similar line for every single hamlib API call in the sources. The
linking environment itself seems all right, since I get no errors
linking against glib and gtk+.

I have tried to google this and got a lots of hits, but I can't really
make any sense out of it. Looking into include/hamlib/rig_dll.h I see a
lot of IMP stuff, but that definitely doesn't make any sense to me
either.

I have tried both hamlib builds (the one with stdcall and the one
without). No difference.
I have attached my Makefile.

Does anybody have any idea of what is going on? Maybe I am just missing
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexandru Csete | 7 Jan 2007 17:50
Picon
Picon
Favicon

Re: Linking against hamlib dll

On Sun, 7 Jan 2007 16:35:28 +0100 Alexandru Csete <alexc <at> phys.au.dk>
wrote:
> Greetings,
> 
> I am trying to cross compile grig to windows target using mingw32.
> After spending most of yesterday and today it seems that I have
> managed to set up a functional build environment including cross
> compiled Gtk+ and GLib libraries.
> 
> The compilation goes all right but linking fails with following
> message:
> 
> grig-debug.o:grig-debug.c:(.text+0x179): undefined reference to
> `__imp__rig_set_debug_callback'
> grig-debug.o:grig-debug.c:(.text+0x18f): undefined reference to
> `__imp__rig_set_debug_callback'
> grig-debug.o:grig-debug.c:(.text+0x277): undefined reference to
> `__imp__rig_set_debug'
>

Well, I got one step further in the mean time. I found out that
-lhamlib links against libhamlib.dll.a, while the __imp_ prefixed
symbols are to be found in the libhamlib-2.lib
I replaced -lhamlib with libhamlib-2.lib (as if it was an object file)
and the linking produces grig.exe without any error.

Now I need to find a way to test it :o)

73
Alex OZ9AEC
(Continue reading)

Permalink | Reply | 0 comments |
headers
William Liporace | 8 Jan 2007 03:13
Picon

FT-1000D Hamlib

I have been looking at the HAMLIB to get my radio running under Linux. I
have not seen any progress to the Yaesu HAMLIBs ecspecially the
FT-1000D. Is there any work being done?

I am not a programmer. I am not sure there is much I can do, but willing
to try or attemp to get information for a programmer. 

TNX es 73 Will NA2NA

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 6 comments |

Gmane