Elecraft

KX3 programming question

Classic

List

Threaded

5 messages Options

ok4rm

KX3 programming question

Hello,

I am programming yet another utility to control KX3 and I encountered a
strange (inconsistent) behavior.

In digital mode contest traffic it is necessary to switch to RX immediately
after exchange has been sent. I learned that the way to do this is to
send KYW<text
to send>;RX; to the serial interface. The RX; after KY will ensure
immediate switch to receive and the W in KYW will ensure that the RX; will
be interpreted after text sending is finished, i.e. will not interrupt
ongoing transmission.

What surprised me is that when I send something like:
KYWCQ CQ CQ DE OK4RM;KYW DE OK4RM OK4RM PSE K;RX;
i.e. split a long text in shorter chunks. In such case I believe all the
texts are sent (I have to verify that yet, though) but the effect of the
final RX; disappears.

Is this a mistake in my program workflow or could that be a firmware
peculiarity? (I hesitate to call it a bug as everything else seems to work
perfectly.)

I think there will be no problem for a contest but if I wanted to use the
same pattern for longer exchanges in casual digi QSOs that would make
things a little bit more complicated.

Thanks for any advice,

Jindra
OK4RM
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

gt-i

Re: KX3 programming question

Jindra,
check the KYn; response for error / success. See manual re. the KY
command. Might be a buffer overrun ? The buffer is limited to 24 chars
according to the specs.
73
Gernot, DF5RF

Am 26.09.2015 um 20:18 schrieb Jindřich Vavruška:

> Hello,
>
> I am programming yet another utility to control KX3 and I encountered a
> strange (inconsistent) behavior.
>
> In digital mode contest traffic it is necessary to switch to RX immediately
> after exchange has been sent. I learned that the way to do this is to
> send KYW<text
> to send>;RX; to the serial interface. The RX; after KY will ensure
> immediate switch to receive and the W in KYW will ensure that the RX; will
> be interpreted after text sending is finished, i.e. will not interrupt
> ongoing transmission.
>
> What surprised me is that when I send something like:
> KYWCQ CQ CQ DE OK4RM;KYW DE OK4RM OK4RM PSE K;RX;
> i.e. split a long text in shorter chunks. In such case I believe all the
> texts are sent (I have to verify that yet, though) but the effect of the
> final RX; disappears.
>
> Is this a mistake in my program workflow or could that be a firmware
> peculiarity? (I hesitate to call it a bug as everything else seems to work
> perfectly.)
>
> I think there will be no problem for a contest but if I wanted to use the
> same pattern for longer exchanges in casual digi QSOs that would make
> things a little bit more complicated.
>
> Thanks for any advice,
>
> Jindra
> OK4RM
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]
>

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

gt-i

Re: KX3 programming question

Jindra,
yes, just keep us posted when your done!
73
Gernot

PS: I guess you wanted to reply to the list.. you have to be careful
most email programs reply to the sender by default.

Hi Gernot,

That could be it... I am afraid I was expecting something like 40 chars
and did not bother reading full details :-)

It seems the correct approach is to split exchange into chunks of 24
chars max and instead of dumb chaining follow each chunk by KY; and wait
for KY2; response, and only then continue.

I was hoping to manage it without making the control program too busy,
obviously KX3 needs a little bit more attention.

Anyway, it is doing quite nice things in my Chrome packaged app. I can
manually switch everything and especially receive all responses with
100% reliability.

Hopefully it will be usable for comfortable work in PSK-D and FSK-D
modes (that is my main motivation), maybe for some CW contesting.

Would you be interested when it is done?

73 Jindra

Am 27.09.2015 um 00:31 schrieb [hidden email]:

> Jindra,
> check the KYn; response for error / success. See manual re. the KY
> command. Might be a buffer overrun ? The buffer is limited to 24 chars
> according to the specs.
> 73
> Gernot, DF5RF
>
> Am 26.09.2015 um 20:18 schrieb Jindřich Vavruška:
>> Hello,
>>
>> I am programming yet another utility to control KX3 and I encountered a
>> strange (inconsistent) behavior.
>>
>> In digital mode contest traffic it is necessary to switch to RX
>> immediately
>> after exchange has been sent. I learned that the way to do this is to
>> send KYW<text
>> to send>;RX; to the serial interface. The RX; after KY will ensure
>> immediate switch to receive and the W in KYW will ensure that the RX;
>> will
>> be interpreted after text sending is finished, i.e. will not interrupt
>> ongoing transmission.
>>
>> What surprised me is that when I send something like:
>> KYWCQ CQ CQ DE OK4RM;KYW DE OK4RM OK4RM PSE K;RX;
>> i.e. split a long text in shorter chunks. In such case I believe all
>> the
>> texts are sent (I have to verify that yet, though) but the effect of the
>> final RX; disappears.
>>
>> Is this a mistake in my program workflow or could that be a firmware
>> peculiarity? (I hesitate to call it a bug as everything else seems to
>> work
>> perfectly.)
>>
>> I think there will be no problem for a contest but if I wanted to use
>> the
>> same pattern for longer exchanges in casual digi QSOs that would make
>> things a little bit more complicated.
>>
>> Thanks for any advice,
>>
>> Jindra
>> OK4RM
>> ______________________________________________________________
>> Elecraft mailing list
>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>> Help: http://mailman.qth.net/mmfaq.htm
>> Post: mailto:[hidden email]
>>
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>> Message delivered to [hidden email]
>>
>
>
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]

Edouard Lafargue

Re: KX3 programming question

Jindra,

Very happy to see yet another chrome packaged app coming up! You can
check how it is done on my existing KX3 rig controller (Chrome packaged app
too ) at http://wizkers.io/ or https://goo.gl/DgLqXH . No need to reinvent
the wheel, it's all already implemented, and all open source (AGPL) ;-)

The code you probably want to see is there:
https://github.com/wizkers/wizkers/blob/release/server/www/js/app/instruments/elecraft/display_live.js
where I manage a proper transmission buffer that makes sure you will
transmit and receive everything with no loss. Be careful that since Wizkers
is open source under the AGPL, your own app will automatically become open
source if you reuse any of this code... Do you have a link for your app?

If you like this existing project, you are more than welcome to
contribute! Wizkers already supports cool features like rigctld support,
Piglet support, etc...

73 de Ed, W6ELA

On Sun, Sep 27, 2015 at 1:55 PM, <[hidden email]> wrote:

> Jindra,
> yes, just keep us posted when your done!
> 73
> Gernot
>
> PS: I guess you wanted to reply to the list.. you have to be careful most
> email programs reply to the sender by default.
>
>
> Hi Gernot,
>
> That could be it... I am afraid I was expecting something like 40 chars
> and did not bother reading full details :-)
>
> It seems the correct approach is to split exchange into chunks of 24 chars
> max and instead of dumb chaining follow each chunk by KY; and wait for KY2;
> response, and only then continue.
>
> I was hoping to manage it without making the control program too busy,
> obviously KX3 needs a little bit more attention.
>
> Anyway, it is doing quite nice things in my Chrome packaged app. I can
> manually switch everything and especially receive all responses with 100%
> reliability.
>
> Hopefully it will be usable for comfortable work in PSK-D and FSK-D modes
> (that is my main motivation), maybe for some CW contesting.
>
> Would you be interested when it is done?
>
> 73 Jindra
>
>
>
> Am 27.09.2015 um 00:31 schrieb [hidden email]:
>
>> Jindra,
>> check the KYn; response for error / success. See manual re. the KY
>> command. Might be a buffer overrun ? The buffer is limited to 24 chars
>> according to the specs.
>> 73
>> Gernot, DF5RF
>>
>> Am 26.09.2015 um 20:18 schrieb Jindřich Vavruška:
>>
>>> Hello,
>>>
>>> I am programming yet another utility to control KX3 and I encountered a
>>> strange (inconsistent) behavior.
>>>
>>> In digital mode contest traffic it is necessary to switch to RX
>>> immediately
>>> after exchange has been sent. I learned that the way to do this is to
>>> send KYW<text
>>> to send>;RX; to the serial interface. The RX; after KY will ensure
>>> immediate switch to receive and the W in KYW will ensure that the RX;
>>> will
>>> be interpreted after text sending is finished, i.e. will not interrupt
>>> ongoing transmission.
>>>
>>> What surprised me is that when I send something like:
>>> KYWCQ CQ CQ DE OK4RM;KYW DE OK4RM OK4RM PSE K;RX;
>>> i.e. split a long text in shorter chunks. In such case I believe all the
>>> texts are sent (I have to verify that yet, though) but the effect of the
>>> final RX; disappears.
>>>
>>> Is this a mistake in my program workflow or could that be a firmware
>>> peculiarity? (I hesitate to call it a bug as everything else seems to
>>> work
>>> perfectly.)
>>>
>>> I think there will be no problem for a contest but if I wanted to use the
>>> same pattern for longer exchanges in casual digi QSOs that would make
>>> things a little bit more complicated.
>>>
>>> Thanks for any advice,
>>>
>>> Jindra
>>> OK4RM
>>> ______________________________________________________________
>>> Elecraft mailing list
>>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>>> Help: http://mailman.qth.net/mmfaq.htm
>>> Post: mailto:[hidden email]
>>>
>>> This list hosted by: http://www.qsl.net
>>> Please help support this email list: http://www.qsl.net/donate.html
>>> Message delivered to [hidden email]
>>>
>>>
>>
>> ______________________________________________________________
>> Elecraft mailing list
>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>> Help: http://mailman.qth.net/mmfaq.htm
>> Post: mailto:[hidden email]
>>
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>> Message delivered to [hidden email]
>>
>
>
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]
>

ok4rm

Re: KX3 programming question

Hello Ed,

funny, I was not aware of your solution :) it seems to be somewhat
invisible to Google Search.

I will have a look (just received and read your email). My app has no link
yet and is not hosted on any source repo yet as it is really in the very
initial phase.

What it does as of now - it makes a list of available COM ports and has
some buttons to establish the connection, receive callback handlers, etc.

Then I have a small area where I can enter any test and send it to KX3.
The receive handler will automatically take care of the response. Recently
I added a small decoder and few controls, so when, for instance
FA00003575012; is received, the VFO A display is updated automatically,
same for all other codes (except that I don't have a GUI "receiver" for
every code, just a few basic ones). Everything is wrapped in Angularjs, so
I don't have to program data binding.

I would like to have at least a practical control panel (main controls for
casual operation) and some basic logging functionality because I really
love KX3's decoding capability, no need for additional setup of external
sound card, less cables, etc.

73 Jindra
OK4RM

2015-09-27 23:33 GMT+02:00 Edouard Lafargue <[hidden email]>:

> Jindra,
>
> Very happy to see yet another chrome packaged app coming up! You can
> check how it is done on my existing KX3 rig controller (Chrome packaged app
> too ) at http://wizkers.io/ or https://goo.gl/DgLqXH . No need to reinvent
> the wheel, it's all already implemented, and all open source (AGPL) ;-)
>
> The code you probably want to see is there:
>
> https://github.com/wizkers/wizkers/blob/release/server/www/js/app/instruments/elecraft/display_live.js
> where I manage a proper transmission buffer that makes sure you will
> transmit and receive everything with no loss. Be careful that since Wizkers
> is open source under the AGPL, your own app will automatically become open
> source if you reuse any of this code... Do you have a link for your app?
>
> If you like this existing project, you are more than welcome to
> contribute! Wizkers already supports cool features like rigctld support,
> Piglet support, etc...
>
> 73 de Ed, W6ELA
>
>
>
>
>
> On Sun, Sep 27, 2015 at 1:55 PM, <[hidden email]> wrote:
>
> > Jindra,
> > yes, just keep us posted when your done!
> > 73
> > Gernot
> >
> > PS: I guess you wanted to reply to the list.. you have to be careful most
> > email programs reply to the sender by default.
> >
> >
> > Hi Gernot,
> >
> > That could be it... I am afraid I was expecting something like 40 chars
> > and did not bother reading full details :-)
> >
> > It seems the correct approach is to split exchange into chunks of 24
> chars
> > max and instead of dumb chaining follow each chunk by KY; and wait for
> KY2;
> > response, and only then continue.
> >
> > I was hoping to manage it without making the control program too busy,
> > obviously KX3 needs a little bit more attention.
> >
> > Anyway, it is doing quite nice things in my Chrome packaged app. I can
> > manually switch everything and especially receive all responses with 100%
> > reliability.
> >
> > Hopefully it will be usable for comfortable work in PSK-D and FSK-D modes
> > (that is my main motivation), maybe for some CW contesting.
> >
> > Would you be interested when it is done?
> >
> > 73 Jindra
> >
> >
> >
> > Am 27.09.2015 um 00:31 schrieb [hidden email]:
> >
> >> Jindra,
> >> check the KYn; response for error / success. See manual re. the KY
> >> command. Might be a buffer overrun ? The buffer is limited to 24 chars
> >> according to the specs.
> >> 73
> >> Gernot, DF5RF
> >>
> >> Am 26.09.2015 um 20:18 schrieb Jindřich Vavruška:
> >>
> >>> Hello,
> >>>
> >>> I am programming yet another utility to control KX3 and I encountered a
> >>> strange (inconsistent) behavior.
> >>>
> >>> In digital mode contest traffic it is necessary to switch to RX
> >>> immediately
> >>> after exchange has been sent. I learned that the way to do this is to
> >>> send KYW<text
> >>> to send>;RX; to the serial interface. The RX; after KY will ensure
> >>> immediate switch to receive and the W in KYW will ensure that the RX;
> >>> will
> >>> be interpreted after text sending is finished, i.e. will not interrupt
> >>> ongoing transmission.
> >>>
> >>> What surprised me is that when I send something like:
> >>> KYWCQ CQ CQ DE OK4RM;KYW DE OK4RM OK4RM PSE K;RX;
> >>> i.e. split a long text in shorter chunks. In such case I believe all
> the
> >>> texts are sent (I have to verify that yet, though) but the effect of
> the
> >>> final RX; disappears.
> >>>
> >>> Is this a mistake in my program workflow or could that be a firmware
> >>> peculiarity? (I hesitate to call it a bug as everything else seems to
> >>> work
> >>> perfectly.)
> >>>
> >>> I think there will be no problem for a contest but if I wanted to use
> the
> >>> same pattern for longer exchanges in casual digi QSOs that would make
> >>> things a little bit more complicated.
> >>>
> >>> Thanks for any advice,
> >>>
> >>> Jindra
> >>> OK4RM
> >>> ______________________________________________________________
> >>> Elecraft mailing list
> >>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> >>> Help: http://mailman.qth.net/mmfaq.htm
> >>> Post: mailto:[hidden email]
> >>>
> >>> This list hosted by: http://www.qsl.net
> >>> Please help support this email list: http://www.qsl.net/donate.html
> >>> Message delivered to [hidden email]
> >>>
> >>>
> >>
> >> ______________________________________________________________
> >> Elecraft mailing list
> >> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> >> Help: http://mailman.qth.net/mmfaq.htm
> >> Post: mailto:[hidden email]
> >>
> >> This list hosted by: http://www.qsl.net
> >> Please help support this email list: http://www.qsl.net/donate.html
> >> Message delivered to [hidden email]
> >>
> >
> >
> > ______________________________________________________________
> > Elecraft mailing list
> > Home: http://mailman.qth.net/mailman/listinfo/elecraft
> > Help: http://mailman.qth.net/mmfaq.htm
> > Post: mailto:[hidden email]
> >
> > This list hosted by: http://www.qsl.net
> > Please help support this email list: http://www.qsl.net/donate.html
> > Message delivered to [hidden email]
> >
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]
>