I'm still trying to grasp the ins and out of Astrisk and App-rpt etc.
I'm trying to connect a USB FOB to my RC-210. I do grasp the reverse RC-210 wiring process. However I found no way to force pin 13 high to activate PTT pin from the FOB for testing purposes.
Any suggestions on how or if I'm doing something wrong?
I have added a PTT LED for monitoring the output logic from pin 13 but have never been able to get it to turn with any function I've tried other than forcing a voltage at the junction feeding it and the base resistor of the 2N4401. My RC-210 will work at that point but I'm not certain if I have an issue with the USB FOB PTT output.
Am I am missing something or perhaps I don't understand the logic of the different functions.
I'm not against reading but jumping all around to find different materials has left the mind in a jumble. Can anyone enlighten me as to when in the sequence PTT output becomes active and the voltage I should find on that pin when it does?
I'm thinking it goes to ground when ptt goes active. Someone correct me?
BB
···
On 12/4/2011 7:23 PM, Larry wrote:
A Newbie here with a problem.
I'm still trying to grasp the ins and out of Astrisk and App-rpt etc.
I'm trying to connect a USB FOB to my RC-210. I do grasp the reverse
RC-210 wiring process. However I found no way to force pin 13 high to
activate PTT pin from the FOB for testing purposes.
Any suggestions on how or if I'm doing something wrong?
I don't know about app_rpt, but I have played a bit with USB audio devices.
What is the model number of the USB audio chip on your audio fob? If you
can't read it, then please report what is the USB vendor ID and product ID
for the device (you can see this appear in /var/log/messages when you plug
the USB device in)?
How it's supposed to work is this:
The GPIO pin (let's say it's pin 13) will be low when the software doesn't
need to transmit. When the software wants to transmit, it will drive the
GPIO high (which will turn on the NPN transistor that drives PTT). The
software will wait for a short time to allow the radio to key up, then it
will drive an audio signal for the data to be transmitted on to the audio
output of the device (which is hooked up to the audio input of the radio).
When the audio data is finished the software will wait for another short
time then de-assert the GPIO which will turn off PTT.
If you are having trouble you could try the latest version of Thomas
Sailer's soundmodem. I added support for USB-controlled PTT. You could
compile the code and configure soundmodem for your USB device then use the
soundmodem test software to turn PTT on and off. I also wrote an
extremely poor piece of software that dumps HID control packets to the
device to drive the GPIO lines. Basically you write HID data to
/dev/hidrawX
73,
Andrew
ZL3AME
···
On Mon, December 5, 2011 09:23, Larry wrote:
A Newbie here with a problem.
I'm still trying to grasp the ins and out of Astrisk and App-rpt etc.
I'm trying to connect a USB FOB to my RC-210. I do grasp the reverse
RC-210 wiring process. However I found no way to force pin 13 high to
activate PTT pin from the FOB for testing purposes.
Any suggestions on how or if I'm doing something wrong?
I have added a PTT LED for monitoring the output logic from pin 13 but
have never been able to get it to turn with any function I've tried other
than forcing a voltage at the junction feeding it and the base resistor of
the 2N4401. My RC-210 will work at that point but I'm not certain if I
have an issue with the USB FOB PTT output.
Am I am missing something or perhaps I don't understand the logic of the
different functions.
I'm not against reading but jumping all around to find different
materials has left the mind in a jumble. Can anyone enlighten me as to
when in the sequence PTT output becomes active and the voltage I should
find on that pin when it does?
OK here's how to connect the fob to the controller.
Connect the fob TXA to the controller's RXA.
Connect RXA from Fob to TXA on controller.
Connect PTT on the fob to the COR input on controller.
Connect Cor on the FOB to the PTT on the controller.
Then set the cor jumper on the controller to Active low.
Set the cor in USBradio to "usbinvert". That is the equivalent to active low on the fob.
Set CTCSS from to "no" and comment out any pl tones in the usbradio.conf.
Reload the configs.
That should get the fob to key the controller and vise versa.
Just need to set levels and you are good to go.
Regards,
Jon VA3RQ
···
On 12/4/2011 7:57 PM, Andrew Errington wrote:
On Mon, December 5, 2011 09:23, Larry wrote:
A Newbie here with a problem.
I'm still trying to grasp the ins and out of Astrisk and App-rpt etc.
I'm trying to connect a USB FOB to my RC-210. I do grasp the reverse
RC-210 wiring process. However I found no way to force pin 13 high to
activate PTT pin from the FOB for testing purposes.
Any suggestions on how or if I'm doing something wrong?
I have added a PTT LED for monitoring the output logic from pin 13 but
have never been able to get it to turn with any function I've tried other
than forcing a voltage at the junction feeding it and the base resistor of
the 2N4401. My RC-210 will work at that point but I'm not certain if I
have an issue with the USB FOB PTT output.
Am I am missing something or perhaps I don't understand the logic of the
different functions.
I'm not against reading but jumping all around to find different
materials has left the mind in a jumble. Can anyone enlighten me as to
when in the sequence PTT output becomes active and the voltage I should
find on that pin when it does?
Hi,
I don't know about app_rpt, but I have played a bit with USB audio devices.
What is the model number of the USB audio chip on your audio fob? If you
can't read it, then please report what is the USB vendor ID and product ID
for the device (you can see this appear in /var/log/messages when you plug
the USB device in)?
How it's supposed to work is this:
The GPIO pin (let's say it's pin 13) will be low when the software doesn't
need to transmit. When the software wants to transmit, it will drive the
GPIO high (which will turn on the NPN transistor that drives PTT). The
software will wait for a short time to allow the radio to key up, then it
will drive an audio signal for the data to be transmitted on to the audio
output of the device (which is hooked up to the audio input of the radio).
When the audio data is finished the software will wait for another short
time then de-assert the GPIO which will turn off PTT.
If you are having trouble you could try the latest version of Thomas
Sailer's soundmodem. I added support for USB-controlled PTT. You could
compile the code and configure soundmodem for your USB device then use the
soundmodem test software to turn PTT on and off. I also wrote an
extremely poor piece of software that dumps HID control packets to the
device to drive the GPIO lines. Basically you write HID data to
/dev/hidrawX
73,
Andrew
ZL3AME
_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org ohnosec.org
A Newbie here with a problem.
I'm still trying to grasp the ins and out of Astrisk and App-rpt etc.
I'm trying to connect a USB FOB to my RC-210. I do grasp the reverse
RC-210 wiring process. However I found no way to force pin 13 high to
activate PTT pin from the FOB for testing purposes.
Any suggestions on how or if I'm doing something wrong?
I have added a PTT LED for monitoring the output logic from pin 13 but
have never been able to get it to turn with any function I've tried other
than forcing a voltage at the junction feeding it and the base resistor of
the 2N4401. My RC-210 will work at that point but I'm not certain if I
have an issue with the USB FOB PTT output.
Am I am missing something or perhaps I don't understand the logic of the
different functions.
I'm not against reading but jumping all around to find different
materials has left the mind in a jumble. Can anyone enlighten me as to
when in the sequence PTT output becomes active and the voltage I should
find on that pin when it does?
Hi,
I don't know about app_rpt, but I have played a bit with USB audio devices.
What is the model number of the USB audio chip on your audio fob? If you
can't read it, then please report what is the USB vendor ID and product ID
for the device (you can see this appear in /var/log/messages when you plug
the USB device in)?
How it's supposed to work is this:
The GPIO pin (let's say it's pin 13) will be low when the software doesn't
need to transmit. When the software wants to transmit, it will drive the
GPIO high (which will turn on the NPN transistor that drives PTT). The
software will wait for a short time to allow the radio to key up, then it
will drive an audio signal for the data to be transmitted on to the audio
output of the device (which is hooked up to the audio input of the radio).
When the audio data is finished the software will wait for another short
time then de-assert the GPIO which will turn off PTT.
If you are having trouble you could try the latest version of Thomas
Sailer's soundmodem. I added support for USB-controlled PTT. You could
compile the code and configure soundmodem for your USB device then use the
soundmodem test software to turn PTT on and off. I also wrote an
extremely poor piece of software that dumps HID control packets to the
device to drive the GPIO lines. Basically you write HID data to
/dev/hidrawX
73,
Andrew
ZL3AME
Andrew,
Thanks for the great info.
First … I’ll comment on the USB unit… The chip within is covered
by a blob but it detects as a CM-109 and appears to function properly
as far as audio and COS … only the PTT logic has failed to output
during my limited testing.
My assumption about the actual sequence within the chip process was in
line with your great explanation. What I lacked is understanding if
there is a way to force the software into a transmit mode for testing
purposes. Doing so, as you explain should activate the PTT logic.
Your info about Thomas Sailer’s soundmodem
is something I am very interested in. I had another project in mind and
decided to venture into Asterisk and App-rpt in order to to utilize USB
sound modules.
Your information may very well be a solution to another problem I would
like to tackle. I will definitely have a look.
First ... I'll comment on the USB unit.... The chip within is covered by
a blob but it detects as a CM-109 and appears to function properly as far
as audio and COS ... only the PTT logic has failed to output during my
limited testing.
If the chip is epoxy-blobbed, how can you connect to pin 13? GPIO is not
required for basic sound-card functionality, so it's often not bonded out
from the die. It's quite possible that you simply can not access GPIO.
Of course, since I haven't seen your device it's quite possible that you
can access it after all.
Another possibility is that the GPIO you can access is not actually GPIO3,
the one that is usually bonded to pin 13. You can get the CM109 datasheet
on-line and you can see there are 8 GPIO pads on the die. If a different
GPIO is bonded out then could you change the app_rpt configuration to
drive a different bit number?
My assumption about the actual sequence within the chip process was in
line with your great explanation. What I lacked is understanding if there
is a way to force the software into a transmit mode for testing purposes.
Doing so, as you explain should activate the PTT logic.
Well, I don't use app_rpt, but maybe there is a test function you can use.
It would be quite handy for debugging.
Your info about Thomas Sailer's soundmodem is something I am very
interested in. I had another project in mind and decided to venture into
Asterisk and App-rpt in order to to utilize USB sound modules.
Your information may very well be a solution to another problem I would
like to tackle. I will definitely have a look.
Feel free to email me on- or off-list. I'm no expert, but I have dabbled
a lot, and I have absorbed a lot of the information that others have
written on this topic.
Sadly the CM108 packaged parts are becoming scarce as manufacturers move
to the cheaper epoxy-blob process.
The new URIx (as it is called) uses the CM119A. If you want to roll your
own, it would be a good idea to find a fob that uses one of those.
I would note that the output of the chip itself is unlikely to be able to
drive much of anything. Again, looking to the URIx design, they use a FET
switch (IRLML2060) to buffer the output.
To force the PTT on you simply use the command "radio key" and "radio unkey"
from the Asterisk CLI
GL
Ken
···
-----Original Message-----
From: app_rpt-users-bounces@ohnosec.org [mailto:app_rpt-users-
bounces@ohnosec.org] On Behalf Of Andrew Errington
Sent: Sunday, December 04, 2011 9:27 PM
To: Larry
Cc: app_rpt-users@ohnosec.org
Subject: Re: [App_rpt-users] USB FOB pin 13 (PTT)
> First ... I'll comment on the USB unit.... The chip within is covered
> by a blob but it detects as a CM-109 and appears to function properly
> as far as audio and COS ... only the PTT logic has failed to output
> during my limited testing.
If the chip is epoxy-blobbed, how can you connect to pin 13? GPIO is
not required for basic sound-card functionality, so it's often not
bonded out from the die. It's quite possible that you simply can not
access GPIO.
Of course, since I haven't seen your device it's quite possible that
you can access it after all.
Another possibility is that the GPIO you can access is not actually
GPIO3, the one that is usually bonded to pin 13. You can get the CM109
datasheet on-line and you can see there are 8 GPIO pads on the die. If
a different GPIO is bonded out then could you change the app_rpt
configuration to drive a different bit number?
> My assumption about the actual sequence within the chip process was
in
> line with your great explanation. What I lacked is understanding if
> there is a way to force the software into a transmit mode for testing
purposes.
> Doing so, as you explain should activate the PTT logic.
Well, I don't use app_rpt, but maybe there is a test function you can
use.
It would be quite handy for debugging.
> Your info about Thomas Sailer's soundmodem is something I am very
> interested in. I had another project in mind and decided to venture
> into Asterisk and App-rpt in order to to utilize USB sound modules.
>
>
> Your information may very well be a solution to another problem I
> would like to tackle. I will definitely have a look.
>
Feel free to email me on- or off-list. I'm no expert, but I have
dabbled a lot, and I have absorbed a lot of the information that others
have written on this topic.
Sadly the CM108 packaged parts are becoming scarce as manufacturers
move to the cheaper epoxy-blob process.
73,
Andrew
ZL3AME
_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org ohnosec.org