| RB-RIM DB9 | Description | Direction | FR5000 DB25 | Colour | Function |
|---|---|---|---|---|---|
| 1 | txmixb=no | N/C | [txmixb] (tone) audio to TX CTCSS to Radio |
||
| 2 | txmixa=voice | → | 8 | Blue | [txmixa] (voice) audio to TX Audio to Radio |
| 3 | CTCSS/COS composite input from Radio | ← | 21 | Grey | Low (active) when the signal goes above the squelch and the correct CTCSS tone decoded |
| 4 | CTCSS logic from decoder | ← | N/C | CTCSS only input Use RB-RIM Pin 3 composite CTCSS/COS |
|
| 5 | EPTT | → | 19 | Red | Programmed in Radio |
| 6 | Audio In | ← | 9 | Orange | Discrimator Audio from Radio Receiver (no Emphasis) |
| 7 | PC_OK | N/C | PC_OK output - Green LED (Low when PC comms is OK) |
||
| 8 | GND | ↔ | 7 | Green | Signal Ground |
| 9 | GND | ↔ | 7 | Green | Signal Ground |
| N/C | Busy Output | 17 | Low (active) when the squelch is tripped Squelch ONLY COS is prone to false PPT's in noisy enviorments. Use FR5000 pin 21 |
dmesg keeps rolling with the message: retire_capture_urb: 5000 callbacks suppressed
I am of the opinion that this is caused by the CM119A USB interface in the RB-RIM-Lite
being overloaded with data from the Radio on one or more of the I/O pins. There are
four signal inputs to the RB_RIM board, Audio In, Audio Out, BUSY, and PTT.
In the worse case this can thousands of signals per second. It can, also, be very
deceptive when in a quiet RFI enviorment. All looks to be okay, then
when you move the repeater to a noisy envoirment the RIM get overloaded and
AllStarLink (or the USB interface) fails. I quick unlpug and re-plug of the USB
into the RPI will get it going again for a few seconds. On failure the Yellow HB_Led
will stop flashing a go out. The Green PC_OK Led remaind on.
In this build I went chasing a faulty
component and assumed the 12 to 5 volt buck
stepdown was noisy. By removing it from the case all quitened down and the Repeater
to function normally, or so I thought. I fixed the symptom but missed the cause.
Next, I was getting frequent spurious PTT downs of short duration.
Making use of the archivedir logging I determined it occured
up to 47 time an hour.
In HamVoIP, COS must be asserted from the FOB for any inbound RX audio to
be repeated or transferred to a network connection. Note that PTT from
the FOB can/will be asserted independently from COS whenever incoming
audio from the network is present or AllStar telemetry / audio
announcements, etc.
By default, CTCSS is ignored. However, this signaling is fully supported
and can be enabled using simpleusb-tune-m
enu option 'L'. When CTCSS
signaling is enabled, the composite COS signaling becomes a logical 'and'
operation combining the hardware COS 'and' hardware CTCSS signals.
12 Run Simpleusb-tune-menu application, option
V) View COS, CTCSS and PTT Telemetry using real-time display" to
determine the signals.
simpleusb-tune-menu screen updates when using option 'V' are nearly
real-time. The update is generated immediately when the simpleusb driver
detects a change in signal state. State updates occur every 20mS, which
is the internal audio frame interval. Note that ACTUAL screen updates
will be delayed by network latency or jitter.
In the asterisk software, you can "set verbose 5" which will show
real-time internal state variable updates, which get dumped to the
asterisk console. These updates aren't timestamped or logged, but will at
least give a definitive indication of whether COS (or composite COS/CTCSS)
are active. The internal COS variable is labeled: RPT_RXKEYED.
Note that the "archivedir" settings will allow telemetry to be logged
real-time (see below).
COS and CTCSS input connections on the usb interface are voltage detection not frequency decode, the decode is done before the pickup point by the Radio, then transferred to the simpleusb.conf The settings in the simpleusb.conf must be right in order for QSO's to work. It is likley that the pickup point for COS is poping with fake signal, so to avoid that try setting,
Logging by "archivedir" is very useful in many scenarios. Note that HamVoIP has
several customizable settings beyond the stock codebase. For exampl,
To simply perform a basic telemetry "logging" function:
In the /etc/asterisk/rpt.conf file, this example being node [1234]:
Then, you can see all enabled telemetry events. Note that this file can
get very bif very quickly! So, a cleanup mechanism is required. I'll mention
that I use FIFOs for these logs, so this data can be used by various web
apps. Once the above is enabled, you can review many ways, including:
Note that the first CSV column is the timestamp: YYYYMMDDHHMMSS
Thanks to Jon Rorke VA3RQ for this information
Setting up the correct CTCSS logic to the radio interface module is essencial to
the operation of ASL. COS/COR/Squelsh logic is not surficient for successful
operation. Only CTCSS logic is accurate enough. AllStarLink may appear to be
operating without CTCSS on the test bench but it is guranteed to fail in a noisy
RFI enviorment typical of production installation.
By default pin 17 is set for "Busy". This is the COR active line and goes
active when the squelch is tripped. This signal ignores PL (CTCSS) decode on the
repeater.
pin 21 by default it is set to "Analog Audible". This line goes
active when the signal goes above the squelch and the correct CTCSS tone
decoded. This is the desirable line to use for the simple USB squelch and
should be connected to COR IN line on the USB interface.
Also these signals from the repeater should be set to active low. Which
means the lines pull to ground when they go active. Ensure the input logic
on simple usb is set for active low or USB invert.
Do Not use pin 17 where noise on the repeater input could trip the squelch and
cause false key downs.