headers
Chris Bryant | 1 Feb 2010 12:26
Picon

Re: FT-747 and rig-open error

On Sunday 31 Jan 2010, Wilbert Knol wrote:
> 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,
> 
Wilbert

Yes it is powered from the DTR line, and I am a bit worried that it cannot put 
a negative voltage on the RxD line back into the PC as EIA-232 requires. 
However it does seem to work if I connect transmit and receive signals on the 
FT-747 side of the adapter. Have you had problems with this? 

Chris g3wie

> 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
> 
> ---------------------------------------------------------------------------
> --- 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
(Continue reading)

Permalink | Reply | 5 comments |
headers
Wilbert Knol | 1 Feb 2010 17:38
Picon

Re: FT-747 and rig-open error

Hi Chris,

On Monday 01 February 2010 12:26:31 Chris Bryant wrote:
> Yes it is powered from the DTR line, and I am a bit worried that it cannot
>  put a negative voltage on the RxD line back into the PC as EIA-232
>  requires. However it does seem to work if I connect transmit and receive
>  signals on the FT-747 side of the adapter. Have you had problems with
>  this?

Not with your particular adapter, but I have experimented with homebrew CAT 
interfaces for Icom and Kenwood rigs and I have pulled apart a few commercial 
units of the 'self-powered' EIA232<>TTL variety.

All of these gizmos work by robbing power through steering diode(s) from 
RTS/CTS and/or DTR/DSR and/or - believe it or not - TXD/RXD. 

Here are just some of the weird things you can run into:

Latch-up of the interface because the TXD/RXD lines move beyond the 'supply' 
rails.

Capacitive loading of TXD/RXD from the steering diodes and 'supply' 
electrolytics: your interface may work at a low baud rate and stop working at 
higher signalling rates.

Your interface may work with a desktop PC and stop working when plugged into a 
laptop with weaker line drivers. Or the interface, already operating outside 
of the EIA232 spec, may stop working completely in the presence of RF (when 
you start transmitting).
(Continue reading)

Permalink | Reply | 4 comments |
headers
Chris Bryant | 1 Feb 2010 19:34
Picon

Re: FT-747 and rig-open error

On Monday 01 Feb 2010, Wilbert Knol wrote:
> Hi Chris,
> 
> Not with your particular adapter, but I have experimented with homebrew CAT
> interfaces for Icom and Kenwood rigs and I have pulled apart a few
>  commercial units of the 'self-powered' EIA232<>TTL variety.
> 
> All of these gizmos work by robbing power through steering diode(s) from
> RTS/CTS and/or DTR/DSR and/or - believe it or not - TXD/RXD.
> 
> Here are just some of the weird things you can run into:
> 
> Latch-up of the interface because the TXD/RXD lines move beyond the
>  'supply' rails.
> 
> Capacitive loading of TXD/RXD from the steering diodes and 'supply'
> electrolytics: your interface may work at a low baud rate and stop working
>  at higher signalling rates.
> 
> Your interface may work with a desktop PC and stop working when plugged
>  into a laptop with weaker line drivers. Or the interface, already
>  operating outside of the EIA232 spec, may stop working completely in the
>  presence of RF (when you start transmitting).
> 
> Hardware handshaking may not work properly, owing to capacitive overloading
>  of RTS/CTS. You may get buffer overruns, errors, timeouts.
> 
> Your first data packet doesn't make it across as the 'supply' electrolytics
> haven't come to to charge yet. This happens, for example, if your
>  application brings up the serial port for every rig query and releases it
(Continue reading)

Permalink | Reply | 3 comments |
headers
Wilbert Knol | 2 Feb 2010 12:13
Picon

Re: FT-747 and rig-open error

On Monday 01 February 2010 19:34:01 Chris Bryant wrote:

> I'll make up a 9way plug/socket pair and feed external power into the DTR
> pin4. If that doesn't work

That will only get you one half of the EIA-232-required bipolar supply....try 
grabbing the opposite volts from RTS. Maybe your adapter is really only 
capable of driving between +10 and 0 volts...in that case I'd say it's a 
competely lost cause...

> I have a MAX233 (232 but has internal chargepump
> capacitors) which I'll try instead of the whole adapter.

Good plan. The charge pumps in the MAX ICs are great because they are RF 
quiet. 

I've played with thick-film DC/DC converters (NME-series) but I found that the 
free-running oscillators produced too much HF QRM, even after shielding and 
decoupling. The noise floor shot up by 20..25 dB the moment I plugged it into 
the rig...I had a working CAT interface but I couldn't hear the DX :-)

Good luck with the CAT project.

Wilbert, PE7T

------------------------------------------------------------------------------
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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Hines | 2 Feb 2010 12:24

Re: FT-747 and rig-open error

Just in case it helps clarify what may be going on here is a summary
of some information about RS232 Electrical Specs that I extracted from
another document some time ago. Unfortunately I can't remember where I
found it to give proper credit.

The signal levels are called:  high = mark = -ve voltage
                               low = space = +ve voltage

The requirements for a driver (output) and receiver (input) are simple
and are essentially DC requirements:

1. A receiver may present a load ranging from 3000 ohm to 7000 ohm,
   and expects signals to swing from above +3 volt to below -3 volt.

2. A driver must have an output resistance of at least 300 ohm
   and present a swing of above +5 volt to below -5 volt to a
   receiver.  Open circuit driver voltage range is as high as +25
   volt to -25 volt, but must drop to +-15 volt with receiver load.

Most receiver chips switch in the range of 0.5 to 2 volt. (This is
within RS232 specs.) It would be great if all of them were, since then
we could cut corners and drive them from circuits that swing only down
to ground. Unfortunately, some receivers must be driven below ground.
One serial port board tested used a 75174 based receiver which needed
a voltage swing down to -1 volt.

Cheers -- Dave M1CXW

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeff Steinkamp | 4 Feb 2010 13:27

Win32 build on 64 bit OS's

I have been using the Win32 port of Hamlib for quite some time in a 
couple of pieces of software that I am developing.  Recently I've had a 
some  complaints about data getting garbled during the polling for 
frequency and mode.  At first we though this was just Icom specific, but 
it tuned up on a Yaesu also.

After some extensive troubleshooting, it turns out this is specific to 
64 bit Vista and Win7.  The individuals who had these problems stated 
that everything was working correctly on their 32 bit OS's, including 
Vista and Win 7.

The fix was to change the values for the FIFO buffers for the associated 
COM ports from their default and maximum value to the minimum value.

So, I'm not sure if there maybe needs to be something else happening 
when building the 32 bit DLL's or if there might be a need for a 
separate 64 bit build.

The change to the FIFO buffers seems to work quite well and does not 
appears to cause any problem especially with a yeasu FT857, running at 
38400 baud via a USB/serail dongle.  The 5 testers that had this problem 
also stated that they have other software that utilizes serial 
communications they've had difficulty with until they change the FIFO 
settings.

--

-- 
Jeff K. Steinkamp N7YG
Tucson, AZ
SCUD Missile Coordinates:
N032-13-55.02  W110-55-52.79
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nate Bargmann | 6 Feb 2010 23:11
Picon
Favicon
Gravatar

Updates to rigctld

Those of you following the commit mailing list have probably seen a
number of commits from me of late.  This is in an effort to bring
rigctld into a usable state and test those functions with a Perl script
that emulates the well known rigctl called testctld.pl and is found in
the tests directory.  At the moment it is not installed to the system
bin directory.

The main feature I've implemented is what I'm calling the Block
Protocol.  From the rigctld man page:

      Block Protocol
       An  EXPERIMENTAL  Block protocol has been introduced into rigctld as of
       January 24, 2010.  This protocol adds  several  rules  to  the  strings
       returned by rigctld.

       1. The command received by rigctld is echoed with its long command name
       followed by the value(s) received from the client terminated by a  new‐
       line as the first line of the block.

       2. The last line of each block is the string "RPTR x\n" wheren x is the
       numeric return value of the Hamlib backend function that was called  by
       the command.

       3.  Any lines consisting of data values returned by the rig backend are
       prepended by a string immediately followed by a colon then a space  and
       then the value terminated by a newline. e.g. "Frequency: 14250000\n"

       4.  All  commands  received  will be acknowledged by rigctld with lines
       from rules 1 and 2.  Lines from rule 3 are only returned when data val‐
       ues must be returned to the client.
(Continue reading)

Permalink | Reply | 17 comments |
headers
Stelios Bounanos | 7 Feb 2010 14:24

Re: Updates to rigctld

>>>>> On Sat, 6 Feb 2010 16:11:56 -0600, Nate Bargmann <n0nb <at> n0nb.us> said:

[snip]

> The Block Protocol is invoked by use of the -b|--block option.  Unless
> invoked with this option testctld.pl will fail to start and print an
> error message to the console.  Which brings up two additional commands
> that have been implemented in rigctld, again from the man page:

Sounds good Nate, but what about compatibility?  If rigctld is invoked
with -b to use the block protocol (BTW I would expect that to refer to
something about blocking vs asynchronous I/O :-), it seems that older
clients will fail.  Would it be possible for rigctld to work with both
protocols?

If not, we might need kludges like connecting a BLK rigctld to an
old-protocol rigctld doing the rig I/O, e.g:

% ./rigctld -m 1 &             # old proto on port 4532
% ./rigctld -b -m 2 -t 4533 &  # new proto on port 4533

% echo f | nc -q 1 0 4532
145000000

% echo F 433000000 | nc -q 1 0 4532
RPRT 0

% echo f | nc -q 1 0 4533
get_freq:
Frequency: 433000000
(Continue reading)

Permalink | Reply | 12 comments |
headers
Nate Bargmann | 8 Feb 2010 00:05
Picon
Favicon
Gravatar

Re: Updates to rigctld

Thanks for the feedback, Stelios.

I agree that two protocols is not ideal.  Ideally we would have had all
of this in place before turning rigctld out into the wild last year. 
But as I experimented with some Perl code it seemed to me that we had
other pieces in place that once reworked a bit and tweaked slightly
could offer, at least in my estimation, better support for clients.

How to support both protocols simultaneously requires someone with more
programming ability than I.  I simply hacked some string responses into
the right place and cleaned up the strings that are returned.  I'm
strictly a hobbyist hacker and it probably shows.

As for the default protocol, I'd like to see migration to the block
protocol (and I chose the name block simply because rigctld works in
blocks of responses and doesn't appear to me to be asynchronous) if
client authors find it useful.  Right now it is yet another choice for
an author of a Hamlib client to use.  I especially like the ability of
getting key:value pairs from rigctld with every response.  I think it
can go a long way to avoid clients from having to guess at things (I'm
still guessing when writing backend code).

One addition I plan to add to the man page is that after looking at
rotctld, it's default port is 4533.  So a good way of invoking multiple
rigctld processes would be to use even port numbers for it (4532, 4534,
4536) and odd numbers for rotctld (4533, 4535, 4537).

73, de Nate >>

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nate Bargmann | 8 Feb 2010 00:09
Picon
Favicon
Gravatar

Re: Updates to rigctld

* On 2010 07 Feb 07:59 -0600, Stelios Bounanos wrote:

> The best solution would be to support both protocols.  There is no -b
> switch, the client switches its own connection (only) to the block
> protocol with a command that can be used once per connection.

After looking at your message again, this is a clever way to solve the
issue at hand and merits serious consideration.  If you have a patch
available just pass it along.  In fact the more I think about this, the
more I like it.

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

------------------------------------------------------------------------------
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
Permalink | Reply | 0 comments |

Gmane