Tree N6TR wrote:
>
> Per W0MN:
>
> > The post by Mike NO6X has solved the problem. The usage of a regular
> > DB9 cable with all wires connected allows the program to work
> > perfectly. The response is very quick, sub second response to change
> > of band and or frequency. =20
>
> Great - I was hoping something like this would work out by posting
> Gil's message. I must publically apoligize to Gil for doing this,
> but I am glad it has led to a "solution".
>
So am I. I over reacted a bit.
> > There is still a hysteresis but not nearly as large as before. I think
> > his idea of a setting to control step speed will fix that.
>
> Agreed - I will put a knob in the next release to allow tuning the
> QSY rate to the rate. It is too bad Kenwood appears to have taken
> a step backward in this area. The 850s keep up just fine.
>
I am not totally convinced that this could not be handled in some way
but I am not sure how at this moment. The problem with slowing it down
is that the steps will have to be larger if you want to be able to QSY
at a reasonable rate. Even now it changes frequency too slowly. Could
the steps be made larger in some way if for instance you hold the key
for over 1 second or some variable time it would speed up by increasing
the step size (if that is possible). Many control programs work that
way. I think you can program the step size. The strange thing is that
it reacts very qucikly if you give it a specifc frequency to go to and
it is very smooth and no overshoot at all using the buttons on the
microphone. Maybe I will do that? Using the Kenwood RCP you can set step
size buttons and selecting that button gives whatever step you have set
for the button from 10 hz to 1mhz or more for each click and it does not
overshoot at the fastest you can click the mouse.
> > It does mean that his documentation is wrong in the case of the
> > Kenwood radio. It is absolutely required that you use the CTS and RTS
> > lines as specified by RSA232 with this radio it seems. If I jumper
> > those as directed then this problem occurs. If I use the plain DB9
> > cable everything works perfectly. Despite what it may have seemed I am
> > VERY HAPPY with everything else in this program and although I would
> > much rather use only one cable it seems that I cannot and that without
> > major program changes in cannot be done with my radio. I do NOT expect
> > Tree to make those changes for such a small subset. If he some day
> > would like to I would be happy to test them but I will construct the
> > parallel cable for keying and be happy. In every other way the program
> > has satisfied me.
>
> We can add a note in the manual for the 870. It seems very strange that
> you can't just hook RTS to CTS on the radio side (like you can for all
> of their other radios) and make it work. Maybe there is a menu item
> somewhere in the radio that affects this?
I looked and looked for such a thing but I can find nothing. I think
they just depend on it. The manual does emphasize that you have to have
a way to prevent both ends sending at the same time. The jumper does
this but it has the side effect of the one command lag unfortunately.
Nevertheless I fully intend to use the program for SSB SS and CQWW CW
and I think it will do a good job now that I know to use two cables.
Without that the band map is always behind, with it the map stays up to
date every time on the testing I have done so far.
>
> 73 Tree
> tree@contesting.com
>
> --
> FAQ on WWW: http://www.contesting.com/trlogfaq.html
> Submissions: trlog@contesting.com
> Administrative requests: trlog-REQUEST@contesting.com
> Problems: owner-trlog@contesting.com
> Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
--
Gil gbaron@sparc.isl.net
Bailar es vivir
http://www.geocities.com/Yosemite/Trails/4168
--
FAQ on WWW: http://www.contesting.com/trlogfaq.html
Submissions: trlog@contesting.com
Administrative requests: trlog-REQUEST@contesting.com
Problems: owner-trlog@contesting.com
Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
|