|[txmixb] (tone) audio to TX
CTCSS to Radio
|[txmixa] (voice) audio to TX
Audio to Radio
|CTCSS/COS composite input from Radio
|Low (active) when the signal goes above the squelch and the correct CTCSS tone decoded
|CTCSS logic from decoder
|CTCSS only input
Use RB-RIM Pin 3 composite CTCSS/COS
|Programmed in Radio
|Discrimator Audio from Radio Receiver (no Emphasis)
|PC_OK output - Green LED
(Low when PC comms is OK)
|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
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 :
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.