I have a few USB fobs
resembling the one shown in the document titled "USB FOB to
DB25 Interface"
Unfortunately the
chip itself is potted die-on-board so access to signalling
lines is limited to the additional components on board, which
should seem simple enough to get to Pin 13 that feeds the Red
LED to extract a PTT signal.
(I am able to assert
COS- to Volume down and get received audio "to the net"
experienced with WebTransceiver.)
Unfortunately
metering 'every' available connection and toggling
WebTransceiver's Key/Transmit, none of the signal lines on the
board react. I could imagine one line or the other might be
open-collector and I'd have to add a pull-up to see a
transition, but with the LED still in-circuit I'd think that
would react. (The Green LED works as heartbeat just fine.)
Before I head to the
local Frys and buy 1-2 each every fob they have to gut to see
if I could get to the chip pins directly (or try to be patient
and wait for Amazon)...
... I'm sitting here
looking at a fully functional micro with a LOT of GPIO pins
available... wondering why, aside from the IRLP s/w and
interface options available... doesn't an AllStar
implementation leverage the on-board signalling?
I see there is Python
code around to work with the GPIO, but not quite yet sure how
or if I could create and call PTT and COR (and CTCSS) sense
scripts within the AllStar configuration - ???
I know it would split
out the radio audio v PTT/COS wiring harness just a bit vs the
cute USB thing, but what the heck - buffer/interface parts on
a small perf board tied to the GPIO pins and done? No?
Am I missing
something? Code- and instructions-to-be?
Using Pi 3 Model B v
1.2
BTW, uname
-a yields: "Linux barf3 3.18.0-trunk-rpi2 #1 SMP PREEMPT
Debian 3.18.5-1~exp1.co1 (2015-02-02) armv7l GNU/Linux"