I have seen in svn revision 565 of app_rpt.c the new "support for Kenwood
TM-D700A as a remote". Do we need a special interface (like the TM-G707
needs) or can we simply use a serial cable? Does the dedicated DATA
connector in 9600bps Packet Radio mode fit our needs for "flat" audio? Where
can I find the informations which has been required to implement this
feature?
I have another radio from Kenwood (TM-V7) and a selfmade programming cable
for the memory store. Could this be another transceiver for a remote
controlable station?
Yes the D700A just needs a serial cable (although it needs to be
female-female straight thru, cause they used the wrong sex connector
on the Kenwood radio). Yep 9600 baud packet mode is perfict. You will
need to feed the URI output through the 2X amplifier since the Kenwood
takes boat-loads of audio to modulate it properly. Set carrier detect
and rxctcss to dsp and txmixa to voice. The radio makes its own CTCSS
on transmit.
I believe the V7 is the same as the TMG707 so it needs the magic circuitry.
···
----------------------------------------
From: jann@gmx.de
To: app_rpt-users@qrvc.com
Date: Tue, 9 Mar 2010 00:08:02 +0100
Subject: [App_rpt-users] Kenwood Remote TRX
Hi,
I have seen in svn revision 565 of app_rpt.c the new "support for Kenwood
TM-D700A as a remote". Do we need a special interface (like the TM-G707
needs) or can we simply use a serial cable? Does the dedicated DATA
connector in 9600bps Packet Radio mode fit our needs for "flat" audio? Where
can I find the informations which has been required to implement this
feature?
I have another radio from Kenwood (TM-V7) and a selfmade programming cable
for the memory store. Could this be another transceiver for a remote
controlable station?
Yep 9600 baud packet mode is
perfict. You will need to feed the URI output through the 2X
amplifier since the Kenwood takes boat-loads of audio to
modulate it properly.
I checked the TM-D700 manual:
"Output of detected 9600 bps data (500 mVP-P, 10 kOhm) -> Also functions as
a common pin for 1200 bps and 9600 bps data output."
RX seems the same as for 9600 baud packet mode. For TX i tried 1200 bps with
a low setting of "txvoice" (radio tune txvoice 100). Seems to be another way
without using the amplifier + txboost=1. Or am I wrong?
Set carrier detect and rxctcss to dsp
and txmixa to voice. The radio makes its own CTCSS on transmit.
Yep, it works fine with iaxRpt for Windows. How can I change the inital
frequency 146.580 MHz to another one? It is not a frequency for hamradio in
germany. I found 146.580 MHz in app_rpt.c, but I hope there is another way
to change it
Well, sorry but *WRONG!!!*. 1200 packet mode rolls off the
low side of the audio spectrum and makes CTCSS decoding completely
impossible. Its not too happy with the high side of the spectrum
and the squelch detection either. Thats why I was forced to use
9600 and having to give it a signal higher then the Alps.
I dont know why the radio is so hard-of-hearing at 9600 baud,
but thats Kenwood for you. You will also need the "txboost=y"
in the usbradio.conf (and the latest version of software that
supports it).
JIM
···
----------------------------------------
From: jann@gmx.de
To: telesistant@hotmail.com; app_rpt-users@qrvc.com
Subject: Re [App_rpt-users] Kenwood Remote TRX
Date: Wed, 17 Mar 2010 15:06:05 +0100
Hello Jim,
Yep 9600 baud packet mode is
perfict. You will need to feed the URI output through the 2X
amplifier since the Kenwood takes boat-loads of audio to
modulate it properly.
I checked the TM-D700 manual:
"Output of detected 9600 bps data (500 mVP-P, 10 kOhm) -> Also functions as
a common pin for 1200 bps and 9600 bps data output."
RX seems the same as for 9600 baud packet mode. For TX i tried 1200 bps with
a low setting of "txvoice" (radio tune txvoice 100). Seems to be another way
without using the amplifier + txboost=1. Or am I wrong?
Set carrier detect and rxctcss to dsp
and txmixa to voice. The radio makes its own CTCSS on transmit.
Yep, it works fine with iaxRpt for Windows. How can I change the inital
frequency 146.580 MHz to another one? It is not a frequency for hamradio in
germany. I found 146.580 MHz in app_rpt.c, but I hope there is another way
to change it
Well, sorry but *WRONG!!!*. 1200 packet mode rolls off the
low side of the audio spectrum and makes CTCSS decoding completely
impossible.
This should be normal behaviour, as 1k2 packet is AFSK/FFSK and relies on
normal audio path, with pre/deemphasis and 300-3000 Hz AF filtering for best
performance.
Ralph.
···
JIM
�
----------------------------------------
> From: jann@gmx.de
> To: telesistant@hotmail.com; app_rpt-users@qrvc.com
> Subject: Re [App_rpt-users] Kenwood Remote TRX
> Date: Wed, 17 Mar 2010 15:06:05 +0100
>
> Hello Jim,
>
>> Yep 9600 baud packet mode is
>> perfict. You will need to feed the URI output through the 2X
>> amplifier since the Kenwood takes boat-loads of audio to
>> modulate it properly.
>
> I checked the TM-D700 manual:
> "Output of detected 9600 bps data (500 mVP-P, 10 kOhm) -> Also
functions as
> a common pin for 1200 bps and 9600 bps data output."
>
> RX seems the same as for 9600 baud packet mode. For TX i tried
1200 bps with
> a low setting of "txvoice" (radio tune txvoice 100). Seems to
be another way
> without using the amplifier + txboost=1. Or am I wrong?
>
>> Set carrier detect and rxctcss to dsp
>> and txmixa to voice. The radio makes its own CTCSS on transmit.
>
> Yep, it works fine with iaxRpt for Windows. How can I change the inital
> frequency 146.580 MHz to another one? It is not a frequency for
hamradio in
> germany. I found 146.580 MHz in app_rpt.c, but I hope there is
another way
> to change it
>
> Thanks!
> 73,
> Jann
>
well yes, the 1200bps output pin does exactly that, but
the 9600 baud pin in 1200 mode is somewhere bizarrely
in between.
···
----------------------------------------
From: ralph@radio-link.net
To: app_rpt-users@qrvc.com
Date: Wed, 17 Mar 2010 16:13:36 +0100
Subject: Re: [App_rpt-users] Re Kenwood Remote TRX
Well, sorry but *WRONG!!!*. 1200 packet mode rolls off the
low side of the audio spectrum and makes CTCSS decoding completely
impossible.
This should be normal behaviour, as 1k2 packet is AFSK/FFSK and relies on
normal audio path, with pre/deemphasis and 300-3000 Hz AF filtering for best
performance.
Ralph.
JIM
----------------------------------------
From: jann@gmx.de
To: telesistant@hotmail.com; app_rpt-users@qrvc.com
Subject: Re [App_rpt-users] Kenwood Remote TRX
Date: Wed, 17 Mar 2010 15:06:05 +0100
Hello Jim,
Yep 9600 baud packet mode is
perfict. You will need to feed the URI output through the 2X
amplifier since the Kenwood takes boat-loads of audio to
modulate it properly.
I checked the TM-D700 manual:
"Output of detected 9600 bps data (500 mVP-P, 10 kOhm) -> Also
functions as
a common pin for 1200 bps and 9600 bps data output."
RX seems the same as for 9600 baud packet mode. For TX i tried
1200 bps with
a low setting of "txvoice" (radio tune txvoice 100). Seems to
be another way
without using the amplifier + txboost=1. Or am I wrong?
Set carrier detect and rxctcss to dsp
and txmixa to voice. The radio makes its own CTCSS on transmit.
Yep, it works fine with iaxRpt for Windows. How can I change the inital
frequency 146.580 MHz to another one? It is not a frequency for
hamradio in
germany. I found 146.580 MHz in app_rpt.c, but I hope there is
well yes, the 1200bps output pin does exactly that, but
the 9600 baud pin in 1200 mode is somewhere bizarrely
in between.
In fact it should transmit a clean 1k2 signal, but with wrong (flat)
frequency response, so decoding it with the normal ham receivers will not be
100% OK...
Ralph.
···
----------------------------------------
> From: ralph@radio-link.net
> To: app_rpt-users@qrvc.com
> Date: Wed, 17 Mar 2010 16:13:36 +0100
> Subject: Re: [App_rpt-users] Re Kenwood Remote TRX
>
>> Well, sorry but *WRONG!!!*. 1200 packet mode rolls off the
>> low side of the audio spectrum and makes CTCSS decoding completely
>> impossible.
>
> This should be normal behaviour, as 1k2 packet is AFSK/FFSK and
relies on
> normal audio path, with pre/deemphasis and 300-3000 Hz AF
filtering for best
> performance.
>
> Ralph.
>
>> JIM
>>
>>
>> ----------------------------------------
>>> From: jann@gmx.de
>>> To: telesistant@hotmail.com; app_rpt-users@qrvc.com
>>> Subject: Re [App_rpt-users] Kenwood Remote TRX
>>> Date: Wed, 17 Mar 2010 15:06:05 +0100
>>>
>>> Hello Jim,
>>>
>>>> Yep 9600 baud packet mode is
>>>> perfict. You will need to feed the URI output through the 2X
>>>> amplifier since the Kenwood takes boat-loads of audio to
>>>> modulate it properly.
>>>
>>> I checked the TM-D700 manual:
>>> "Output of detected 9600 bps data (500 mVP-P, 10 kOhm) -> Also
>> functions as
>>> a common pin for 1200 bps and 9600 bps data output."
>>>
>>> RX seems the same as for 9600 baud packet mode. For TX i tried
>> 1200 bps with
>>> a low setting of "txvoice" (radio tune txvoice 100). Seems to
>> be another way
>>> without using the amplifier + txboost=1. Or am I wrong?
>>>
>>>> Set carrier detect and rxctcss to dsp
>>>> and txmixa to voice. The radio makes its own CTCSS on transmit.
>>>
>>> Yep, it works fine with iaxRpt for Windows. How can I change
the inital
>>> frequency 146.580 MHz to another one? It is not a frequency for
>> hamradio in
>>> germany. I found 146.580 MHz in app_rpt.c, but I hope there is
>> another way
>>> to change it
>>>
>>> Thanks!
>>> 73,
>>> Jann
>>>
>>
>> _______________________________________________
>> App_rpt-users mailing list
>> App_rpt-users@qrvc.com
>> http://qrvc.com/mailman/listinfo/app_rpt-users
>>
>
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users@qrvc.com
> http://qrvc.com/mailman/listinfo/app_rpt-users
Well, sorry but *WRONG!!!*. 1200 packet mode rolls off the
low side of the audio spectrum and makes CTCSS decoding
completely impossible. Its not too happy with the high side
of the spectrum and the squelch detection either. Thats why I
was forced to use 9600 and having to give it a signal higher
then the Alps.
For remote operation it already worked in 9600-mode (without the amplifier,
but with txboost=1) using the iaxRpt-client with a high mic-in level (+mic
boost). However using this client audio level with a standard repeaeter is
much too loud... So I will try 9k6+amp next weekend.
I have another question about the default shift on 70cm. I set it to -7.6Mhz
for german repeaters on the radio. After I logged in with the iaxRpt-client
asterisk will change it back to 5MHz for 70cm (and will jump to 2m
146.580...). I didn't found any documentation about the memory stanza in
rpt.conf. Using "-" or "+" will use the default shift. Is it possible to add
a shift for each memory?
yeah... you have a good point there.. Ill see what I can do.
Thanks for pointing this out.
JIM
···
----------------------------------------
From: jann@gmx.de
To: telesistant@hotmail.com; app_rpt-users@qrvc.com
Subject: Re: [App_rpt-users] Kenwood Remote TRX
Date: Wed, 17 Mar 2010 18:04:49 +0100
Hi Jim,
Well, sorry but *WRONG!!!*. 1200 packet mode rolls off the
low side of the audio spectrum and makes CTCSS decoding
completely impossible. Its not too happy with the high side
of the spectrum and the squelch detection either. Thats why I
was forced to use 9600 and having to give it a signal higher
then the Alps.
For remote operation it already worked in 9600-mode (without the amplifier,
but with txboost=1) using the iaxRpt-client with a high mic-in level (+mic
boost). However using this client audio level with a standard repeaeter is
much too loud... So I will try 9k6+amp next weekend.
I have another question about the default shift on 70cm. I set it to -7.6Mhz
for german repeaters on the radio. After I logged in with the iaxRpt-client
asterisk will change it back to 5MHz for 70cm (and will jump to 2m
146.580...). I didn't found any documentation about the memory stanza in
rpt.conf. Using "-" or "+" will use the default shift. Is it possible to add
a shift for each memory?
I set up the system here, exactly as you have said (only differnce
is its a TMG-707 as a remote, not a D-700, which shouldnt make any
difference) and I can not duplicate your problem.
JIM WB6NIL
···
----------------------------------------
From: jann@gmx.de
To: telesistant@hotmail.com
Subject: Re: [App_rpt-users] Kenwood Remote TRX
Date: Tue, 23 Mar 2010 22:23:25 +0100
Hi Jim,
sorry, I did have some trouble with my mail system. Here we go again
never heard of "flannelly" just explain it in German, and Ill
have a friend translate it.
Englisch ⇔ Deutsch - leo.org: Startseite
=on&spellToler=on&chinese=both&pinyin=diacritic&search=dumpf&relink=on
Well, the effect is low and I don't get in trouble with it. Just for
feedback.
As far as the problem with the dsp carrier on long hang time
repeaters, it should work just fine. I will attempt to
simulate this problem, if I accurately understand it.
Correct me if Im wrong please. If you are using the remote
base to talk to a repeater with a long hang time, when you
un-key the USB device does not detect the presence of the
carrier from the receiver..
Yes, I will un-key the USB device and the repeater with the long hang time
is still transmitting. I will not get this audio. The repeater need to stop
transmitting and then the next transmission from the repeater will be
catched by my remote trx.
I tried it on simplex. I talked to a friend and I told him to start talking
during my transmission. He started his tranmission while I was talking, I
stopped my remote transmission and did NOT get his audio after I un-keyed.
He needed to stop talking and make another transmission.
I have added (still experimental) code in app_rpt version 0.211 (available this
evening in SVN) to attempt to support non-USA-standard repeater offsets
for frequency agile radios. I have tested the code on a TMG-707A, but not
on any of the other models supported, which are TM-271, TM-D700, FT-897
and IC-706. The other radios did not seem to support such functionality.
There are 2 ways of configuring this:
the new rpt.conf parameters (that go into the node clause
in rpt.conf), are split2m and split70cm, which specify the
default offset for 2 meters and 70 centimeters in kilohertz.
split2m = 600
split70cm = 5000
You may also specify the offset in a memory channel
by adding an additional parameter before the options,
for example:
01 = 147.435,103.5,1035,h-t ; This would be for W6NUT in Los Angeles with input of 146.40
Subject: [App_rpt-users] non-USA-standard repeater offset for freq-agileradios
I have added (still experimental) code in app_rpt version 0.211 (available this
evening in SVN) to attempt to support non-USA-standard repeater offsets
for frequency agile radios. I have tested the code on a TMG-707A, but not
on any of the other models supported, which are TM-271, TM-D700, FT-897
and IC-706. The other radios did not seem to support such functionality.
There are 2 ways of configuring this:
the new rpt.conf parameters (that go into the node clause
in rpt.conf), are split2m and split70cm, which specify the
default offset for 2 meters and 70 centimeters in kilohertz.
split2m = 600
split70cm = 5000
You may also specify the offset in a memory channel
by adding an additional parameter before the options,
for example:
01 = 147.435,103.5,1035,h-t ; This would be for W6NUT in Los Angeles with input of 146.40
it doesn't work here on my system. Revision 576 was OK, but 587 will not
work with my tmd700. After a login using iaxRpt I will get "invalid
frequency" (voice).
Has anyone figured out how to show a real-time monitor of which connected nodes are talking at any particular time? I have to imagine there is some way to do this. The data seems to be there given the node has the ability to report the exact time each connected node transmitted.
Any clues would be helpful.
which will show you the status, replace node 27099 with your node number.
···
On Thu, 1 Apr 2010, Steve Passmore wrote:
Has anyone figured out how to show a real-time monitor of which
connected nodes are talking at any particular time? I have to imagine
there is some way to do this. The data seems to be there given the node
has the ability to report the exact time each connected node transmitted.
Any clues would be helpful.
