BM82557
Member
First time I've used the DCS plugin and not sure how you read the result. In the attached screenshot is 303 the dcs code being used?
Last edited:
SDRSharp DCS Plugin
- Thread starter BM82557
- Start date
- Status
rbm
Member
I can't tell for sure from that image.
But, if you check 'Aux window' for the plugin, there won't be any doubt.
The image below shows a CTCSS example.
I believe the you are seeing 'falsing' in your DCS decode. Adjust the plugin 'squelch' level until it stops displaying random values.
Rich
SDR# with DCS & CTCSS
But, if you check 'Aux window' for the plugin, there won't be any doubt.
The image below shows a CTCSS example.
I believe the you are seeing 'falsing' in your DCS decode. Adjust the plugin 'squelch' level until it stops displaying random values.
Rich
SDR# with DCS & CTCSS
Last edited:
rbm
Member
I should have also mentioned that the correct code is displayed while the signal is present.
Whatever shows up at other times may be invalid.
Rich
Whatever shows up at other times may be invalid.
Rich
Wut is that??? How did you get the vertical labels in there like that?
BM82557
Member
RBM - As an experiment I changed to a freq that has a known dcs of 734 (see attachment) and enabled the aux window. Both the aux window and the main dcs decoder panel have the dcs code of 066 734. Will the dcs code always be in the second group of three numbers?
Mancow - Click the show on spectrum box in the Frequency Manager panel. In the first screen shot I had SDRSharp zoomed out and in the latest screenshot I had zoomed in. The Text automatically changes orientation as you zoom in or out.
Mancow - Click the show on spectrum box in the Frequency Manager panel. In the first screen shot I had SDRSharp zoomed out and in the latest screenshot I had zoomed in. The Text automatically changes orientation as you zoom in or out.
Last edited:
rbm
Member
No.
It will bounce around to random numbers.
The only one that means anything is that which is displayed while the signal is active.
It will be shown first, and also on the spectrum (if that option is selected)
It 'may' stay there for a while, until it 'falses' on another random number.
Rich
Edit: The proper DCS code will be shown in all of the places circled in this screen capture (while the signal is active)
155.13 MHz - DCS 132
Last edited:
BM82557
Member
Ok, the only thing that makes any sense is that the RR DB entry of 734 for 453.5250 that I used in my experiment must be incorrect.. I consistently have 066 when the freq is active (it is a Fire/Ems dispatch patch of our local P25 system).
rbm
Member
Lots to read here:
DPL / DCS Information
Notice the following values in my sample screen capture above for DCS132
+132, +605, +634, +714
-317, -546, -614, -751
Rich
"There is nothing in the DCS math that recognizes or knows about signal inversion. More importantly, there is no way for the transmitter to tell the receiver what the correct polarity is to decode its signal. With these assumed "perfect laboratory conditions" where the transmitter and receiver both have the same signal polarity, what we send is what we get. If we Tx a 023 DCS code, we will Rx a 023 DCS code, after the receiver rotates the 23 bits around to find it.
Notice that even though we sent a 023 DCS code, we could also receive it as DCS code 340 or DCS code 766 if we wanted to. This brings up the question, "How do we know which code to use?". The only answer is there seems to be an un-enforced agreement to only use one DCS code when there are multiple possible DCS codes (more on this later). The other matching DCS codes (like 340 or 766) are still there, they are just ignored. This agreement only applies to the so called "standard" set of 83 DCS codes used by the communications industry.
This is all for the "perfect laboratory conditions", now we will dive into the real world. In the real world there is no guarantee that a transmitter and receiver will have the same signal polarity. Unless you are using the exact same manufacturer and model of radios for Tx and Rx, there just might be an unavoidable polarity inversion between them. Let's take a look at what happens when the equipment inverts the DCS 23 bit word polarity:"
DPL / DCS Information
Notice the following values in my sample screen capture above for DCS132
+132, +605, +634, +714
-317, -546, -614, -751
Rich
"There is nothing in the DCS math that recognizes or knows about signal inversion. More importantly, there is no way for the transmitter to tell the receiver what the correct polarity is to decode its signal. With these assumed "perfect laboratory conditions" where the transmitter and receiver both have the same signal polarity, what we send is what we get. If we Tx a 023 DCS code, we will Rx a 023 DCS code, after the receiver rotates the 23 bits around to find it.
Notice that even though we sent a 023 DCS code, we could also receive it as DCS code 340 or DCS code 766 if we wanted to. This brings up the question, "How do we know which code to use?". The only answer is there seems to be an un-enforced agreement to only use one DCS code when there are multiple possible DCS codes (more on this later). The other matching DCS codes (like 340 or 766) are still there, they are just ignored. This agreement only applies to the so called "standard" set of 83 DCS codes used by the communications industry.
This is all for the "perfect laboratory conditions", now we will dive into the real world. In the real world there is no guarantee that a transmitter and receiver will have the same signal polarity. Unless you are using the exact same manufacturer and model of radios for Tx and Rx, there just might be an unavoidable polarity inversion between them. Let's take a look at what happens when the equipment inverts the DCS 23 bit word polarity:"
Last edited:
I never knew about the text. Thanks BM82557.
BM82557
Member
- Status
