36
edits
Changes
Jump to navigation
Jump to search
Line 31:
Line 31: − Line 64:
Line 63: − Line 86:
Line 84: − Line 108:
Line 105: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
no edit summary
==Compiling Environment==
==Compiling Environment==
If you look in the [https://github.com/AllStarLink/voter/blob/master/votersystem.pdf votersystem.pdf], you will find a procedure to modify and load the bootloader in to the dsPIC of a VOTER board.
If you look in the [https://github.com/AllStarLink/voter/blob/master/votersystem.pdf votersystem.pdf], you will find a procedure to modify and load the bootloader in to the dsPIC of a VOTER board.
==Bootloader==
==Bootloader==
If you need to load the bootloader in to a fresh board, you will need to follow these steps:
If you need to load the bootloader in to a fresh board, you will need to follow these steps:
*Go to Project --> Open --> voter-bootloader.mcp --> Open (it is in the voter-bootloader folder of the GitHub source)
*Go to Project --> Open --> voter-bootloader.mcp --> Open (it is in the voter-bootloader folder of the GitHub source)
==Firmware==
==Firmware==
To compile the firmware (if you want to make custom changes):
To compile the firmware (if you want to make custom changes):
*Go to Project --> Open --> navigate to board-firmware and open the .mcp file for the flavor of firmware you want to compile. They are in the board-firmware folder of the GitHub source.
*Go to Project --> Open --> navigate to board-firmware and open the .mcp file for the flavor of firmware you want to compile. They are in the board-firmware folder of the GitHub source.
If you want to compile the DSPBEW version, open the DSPBEW project file instead.
If you want to compile the DSPBEW version, open the DSPBEW project file instead.
=DSP/BEW Firmware Version=
DSP BEW Firmware is mutually exclusive with the diagnostic menu. There is not enough space for both, if you load the DSP/BEW firmware, you will '''NOT''' have a diag menu.
BEW stands for Baseband Examination Window.
Typically, the discriminator of an FM communications receiver produces results containing audio spectrum from the "sub-audible" range (typically < 100 Hz) to well above frequencies able to be produced by modulating audio. These higher frequencies can be utilized to determine signal quality, since they can only contain noise (or no noise, if a sufficiently strong signal is present).
For receivers (such as the Motorola Quantar, etc) that do not provide sufficient spectral content at these "noise" frequencies (for various reasons), The "DSP/BEW (Digital Signal Processor / Baseband Examination Window)" feature of the RTCM firmware may be utilized.
These receivers are perfectly capable of providing valid "noise" signal with no modulation on the input of the receiver, but with strong modulation (high frequency audio and high deviation), it severely interferes with proper analysis of signal strength.
This feature provides a means by which a "Window" of baseband (normal audio range) signal is examined by a DSP and a determination of whether or not sufficient audio is present to cause interference of proper signal strength is made. During the VERY brief periods of time when it is determined that sufficient audio is present to cause interference, the signal strength value is "held" (the last valid value previous to the time of interference) until such time that the interfering audio is no longer present.
The DSP/BEW feature is selectable, and '''should not''' be used for a receiver that does not need it.
A note on the Motorola SLR5700 per VE7FET. DSP/BEW definitely makes a difference on what AllMon reports for the signal strength of received signals. It is less reactive when DSP/BEW = 1 than with it set to 0. We'll have to see what the real world trials show. It might be better to leave it off.
=Chuck Squelch=
"Chuck Squelch" are a couple firmware changes made by Chuck Henderson, WB9UUS.
Pre-compiled firmware versions including this option are available on [https://github.com/AllStarLink/voter/tree/master/board-firmware GitHub]. See above on how it is enabled/compiled, if you are rolling your own firmware modifications.
One of the changes fixes an issue with weak signals producing RSSI readings all over the place. It is caused by a 16 bit value that was overflowing (it is the RSSI change in the firmware). It results in rock-solid RSSI values being reported, even on barely or non-readable signals. '''This change will likely be rolled in to a permanent fix in a future firmware release.'''
The other firmware change changes how the squelch responds (looks at the noise in the last two audio samples) and makes the "Micor squelch" action work better.
You may also want to consider the following changes in /etc/asterisk/voter.conf:
<pre>
;Comment out:
;thresholds =
;and set:
linger = 0
</pre>
==Squelch Issues==
*If anyone is off frequency a little bit, that will make the voice talk off worse. Double check that the repeater and the users are all on frequency.
*Don't use narrow bandwidth on the repeater receiver.
*Make sure that the discriminator audio is not rolled off even a little bit at the high end. There should not be resistors in series or capacitors to ground between the discriminator chip output pin and the voter board input, for best results.
=RTCM/VOTER LED's=
RX LED on the RTCM/VOTER will flash (same rate as ACT LED) if you have External CTCSS enabled, and the received signal has the wrong (or no) valid PL.
=TX Level Setting=
*Send 1kHz@3kHz on-channel in to the RX
*Set the RX up so it reads 3kHz deviation on the RTCM's built in console meter
*Now set the TX level '''pot''' to get 3kHz out of the transmitter (No PL)
Now change the modulation from 1kHz tone to 800Hz followed by 1.8kHz and verify that the deviation level doesn't change as the tone frequency changes. '''Changing levels indicates a pre/de-emphasis issue.'''
If using PL you have to account for that deviation, unless you filter it out with your IFR (test set).
=GPS Issues=
=GPS Issues=
==GPS Lock==
The GPS led will go solid regardless of the connection LED. That '''has''' to happen or it won't connect to the Asterisk server.
It is not unusual for it to take up to 20 mins to get a GPS lock LED (ie. using a Trimble Thunderbolt) after any reboot.
==GPS De-sense==
If you are having odd loss of lock issues, consider you may have interference to your GPS antenna from strong RF nearby. A note from Jesse Lloyd:
<pre>
I also had crazy problems with poor signal on my GPS when I set it up sitting in a window, and once installed at site I had the GPS antenna maybe 6 ft from the VHF antenna, and after some troubleshooting found it was getting swamped with RF and loosing lock.
I found the debug setting of 40 useful in the RTCM, you can see a hex output of the GPS status.
</pre>
==NMEA Sentences==
==NMEA Sentences==
If you are using an NMEA GPS (as opposed to a Trimble using the TSIP binary interface), the RTCM/VOTER is looking for the following NMEA sentences:
If you are using an NMEA GPS (as opposed to a Trimble using the TSIP binary interface), the RTCM/VOTER is looking for the following NMEA sentences: