What does CRC Fail mean

[tbr281]

I see this message a lot in DSD+ When monitoring control channels and was wandering what it means?

 

[Kazzaw]

Any fails/Errors (ERR) is usually due to signal/decode issues

 

[tbr281]

I see.. what is CRC though? And can I fix it somehow?

 

[ka1njl]

I see.. what is CRC though? And can I fix it somehow?

It’s cyclic redundancy check. That’s about all I know about it but here’s more. https://en.m.wikipedia.org/wiki/Cyclic_redundancy_check

 

[maus92]

I see.. what is CRC though? And can I fix it somehow?

1. Improve your antenna system. 2. Make sure your SDR has an appropriate ppm correction value applied. CRC Fail is telling you that some of the data packets you are receiving are corrupted, and the error checking process built into the P25 spec is unable to recover them. Improving the antenna system *should* result in fewer corrupted packets that need correction. An uncorrected SDR *could* result in bad data as well, so make sure you have applied a ppm correction value.

 

[tbr281]

1. Improve your antenna system. 2. Make sure your SDR has an appropriate ppm correction value applied. CRC Fail is telling you that some of the data packets you are receiving are corrupted, and the error checking process built into the P25 spec is unable to recover them. Improving the antenna system *should* result in fewer corrupted packets that need correction. An uncorrected SDR *could* result in bad data as well, so make sure you have applied a ppm correction value.

I’ll do that and see what happens. Thanks for the heads up.

 

[AM909]

CRC is the error-correction coding used detect/correct small errors in the received data stream. CRC FAIL means the errors were too severe to be corrected.

The purpose of what is often called the "PPM correction" factor is to make sure the receiver is centered on the correct signal frequency, as many receivers used for this type of work (e.g. RTL dongles) are not well-calibrated by the manufacturers. Also use the right bandwidth for the type of signal (generally 8–10 kHz for P25).

What hardware and software are you receiving/tuning/watching with (i.e. RTL dongle or Airspy, SDR# or FMP24, etc.)? Show us a spectrum display zoomed in on the bandwidth.

 

[tbr281]

CRC is the error-correction coding used detect/correct small errors in the received data stream. CRC FAIL means the errors were too severe to be corrected.

The purpose of what is often called the "PPM correction" factor is to make sure the receiver is centered on the correct signal frequency, as many receivers used for this type of work (e.g. RTL dongles) are not well-calibrated by the manufacturers. Also use the right bandwidth for the type of signal (generally 8–10 kHz for P25).

What hardware and software are you receiving/tuning/watching with (i.e. RTL dongle or Airspy, SDR# or FMP24, etc.)? Show us a spectrum display zoomed in on the bandwidth.

I use FMP24 with a nooelec nesdr smart v4. Here is a screenshot of the spectrum.

im new to DSD+ and am going off what’s on here and YouTube videos.

 

[maus92]

I use FMP24 with a nooelec nesdr smart v4. Here is a screenshot of the spectrum.

im new to DSD+ and am going off what’s on here and YouTube videos.

Not a particularly strong signal.

 

[thewraith2008]

In addition to reasons posted above, If you are monitoring a Motorola DMR (e.g. CAP+) that is using RAS, then CRC fails are normal for DSD+ as it cannot verify the PDU because of the addition element (which DSD+ doesn't/can't know) injected into the PDU for correct CRC. DSD+ will pass this PDU when seen, but the PDU cannot be considered 100% reliable.

If RAS is used, there is nothing you can do to change the CRC fails that are seen.
DSD+ just reports it so you know that this PDU may not be 100%.

 

[tbr281]

What’s interesting is that with all the fails I still get transmissions coming through. Anyway.. thanks for all the insight everyone! I still don’t fully understand it but at this point this beats spending $500+ on a digital scanner.

 

[AM909]

Yeah, not terribly strong signal, though I don't normally see CRC failures at that signal level. Being 700 MHz, I'm going to guess it's P25 (you don't have a location in your profile so we don't know which system you're looking at). Maybe you can give us a screen shot of the other windows (the signal display and the console window showing the errors, for example). The more info you provide, the easier it is for people to help you.

Click on the FMP24 window and press "b" to reduce the bandwidth to 9.5 kHz and "T" to use the "tight" filters, which should improve S/N a little.

Looks like you have the auto-correct on and the correction setting pretty close, so that's good. When having trouble decoding, I try turning off the auto-correct ("a") once I know I'm centered, as I've seen it cause problems.

The RF gain at 40.2 dB is a little high for typical hardware, but you seem to be in a relatively quiet area, so it's probably OK as long as you don't see the noise floor bouncing around. I usually don't get much improvement in S/N beyond 30 dB, but that's because I'm usually in a pretty high-RF environment.

Noise filter 1 can work really well in some cases – press "N" in the FMP24 window to toggle between none, NF1, and NF2 as shown in the title bar.

 

[tbr281]

Yeah, not terribly strong signal, though I don't normally see CRC failures at that signal level. Being 700 MHz, I'm going to guess it's P25 (you don't have a location in your profile so we don't know which system you're looking at). Maybe you can give us a screen shot of the other windows (the signal display and the console window showing the errors, for example). The more info you provide, the easier it is for people to help you.

Click on the FMP24 window and press "b" to reduce the bandwidth to 9.5 kHz and "T" to use the "tight" filters, which should improve S/N a little.

Looks like you have the auto-correct on and the correction setting pretty close, so that's good. When having trouble decoding, I try turning off the auto-correct ("a") once I know I'm centered, as I've seen it cause problems.

The RF gain at 40.2 dB is a little high for typical hardware, but you seem to be in a relatively quiet area, so it's probably OK as long as you don't see the noise floor bouncing around. I usually don't get much improvement in S/N beyond 30 dB, but that's because I'm usually in a pretty high-RF environment.

Noise filter 1 can work really well in some cases – press "N" in the FMP24 window to toggle between none, NF1, and NF2 as shown in the title bar.

I live in a pretty rural place which is surrounded by 100+ ft pine forest.. so getting a good signal which is located 15 miles out. I’m monitoring Kootenai county idaho cooperative agencies which is in p25 p1 which is pretty quiet. But I have been testing out different settings and know what you mean. Honesty I want to rebuild my entire FL database from scratch and property add all the necessary files and commands but I’m waiting on another dongle so I can test it a few things.

 

[tbr281]

Here is a screenshot of what I’ve been testing out.

 

[tbr281]

Here’s one with all the windows

 

[slicerwizard]

In addition to reasons posted above, If you are monitoring a Motorola DMR (e.g. CAP+) that is using RAS, then CRC fails are normal for DSD+ as it cannot verify the PDU because of the addition element (which DSD+ doesn't/can't know) injected into the PDU for correct CRC. DSD+ will pass this PDU when seen, but the PDU cannot be considered 100% reliable.

If RAS is used, there is nothing you can do to change the CRC fails that are seen.
DSD+ just reports it so you know that this PDU may not be 100%.

Not seeing any of that here.

 

[thewraith2008]

So DSD+ does not show CRC fail message anymore I guess. It's sort of implied by the ECC/RAS that's shown in image unless DSD+ can calculate the CRC now. DSD+ is not able to calculate the CRC now is it? Wouldn't that infringe on some patent somewhere or something like that?

 

[maus92]

I live in a pretty rural place which is surrounded by 100+ ft pine forest.. so getting a good signal which is located 15 miles out. I’m monitoring Kootenai county idaho cooperative agencies which is in p25 p1 which is pretty quiet. But I have been testing out different settings and know what you mean. Honesty I want to rebuild my entire FL database from scratch and property add all the necessary files and commands but I’m waiting on another dongle so I can test it a few things.

If you are 15 miles away from a 700 MHz site, you are pretty far away which would explain the marginal signal represented in your first screen shot. Swaying pines trees also are not helpful. The boosted gains shown in later screenshots has helped to improve your signal somewhat. A gain antenna / yagi could help in your situation. (Also looks like a typo in the rrdb on one of the traffic channels, based on your data.)

 

[AM909]

This is long, sorry

... (Also looks like a typo in the rrdb on one of the traffic channels, based on your data.)

Specifically:

• RRDB says 771.40625, as opposed to the 771.30625 in the Channel Activity window. 771.30625 is also what is on the license, WQKU686. I'd suggest looking at the DSDPlus.event file to verify there are multiple assignments of this frequency to ensure it is correct (because of the noted flakey decode).
• The three alternate CCs are not designated in RRDB.
• 770.05625 is in RRDB, but is not in tbr281's Channel Activity window. There can be reasons for this, like it may be a "spare" or, more likely, the channel that is designated for the base station identifier, which, in most systems I monitor, does not get assigned in normal rotation, and is often the lowest frequency on the site, as it is in RRDB for this site. You may need to let it run for a while (35–70 minutes is usually safe) and watch for the expected BSI=WQKU686 message to appear in the Event Log window. Normally, this will cause the channel to appear and remain in the Channel Activity window, too, but I also see that list get totaly zapped sometimes (if it decodes a different SID because of interference, etc.), so you may have to just search for the BSI message in the appropriate time range in the DSDPlus.event file and see if it points to this channel. (OT: DBAs: any thoughts about marking these BSI channels with an "i" suffix as a clue that they may not be heard in normal rotation and/or a channel to monitor for analog morse ID on some systems?)
  
  I'll note that the license also shows one lower freq on this site, 769.28125 (license loc #1, the only location for which it is licensed), which may just be a "spare" or, according to RRDB, was decided to be used on Killarney Mtn instead (loc #5 on the same license, where it is not licensed; perhaps a license modification application is pending ).

I'll leave it to someone else to decide what to submit as correction here.

Thanks for the copious info, @tbr281. I'll note that the newer screen pics show what I would say is a plenty strong signal, so I'm puzzled by the CRC fails. Did you happen to catch a flurry of them in an otherwise decent decoding, or do you get that many of them normally? Unless someone else has ideas about why this is happening, it might be worth recording a short sample, post it somewhere (Google Drive, etc.), and send a link to it and your screen-pic post to the DSD+ FL email (is that the right procedure anyone, or is there another email address or process?).

(Semi-OT): I've been having my own decoding problems with DSD+ lately and am considering rolling back to earlier versions to see if I can nail it down. I'm not sure it's related to this, though, as I think it has to do with the P25p2 sensing and decoding. This ring any bells with anyone?

 

[tbr281]

This is long, sorry


Specifically:

• RRDB says 771.40625, as opposed to the 771.30625 in the Channel Activity window. 771.30625 is also what is on the license, WQKU686. I'd suggest looking at the DSDPlus.event file to verify there are multiple assignments of this frequency to ensure it is correct (because of the noted flakey decode).
• The three alternate CCs are not designated in RRDB.
• 770.05625 is in RRDB, but is not in tbr281's Channel Activity window. There can be reasons for this, like it may be a "spare" or, more likely, the channel that is designated for the base station identifier, which, in most systems I monitor, does not get assigned in normal rotation, and is often the lowest frequency on the site, as it is in RRDB for this site. You may need to let it run for a while (35–70 minutes is usually safe) and watch for the expected BSI=WQKU686 message to appear in the Event Log window. Normally, this will cause the channel to appear and remain in the Channel Activity window, too, but I also see that list get totaly zapped sometimes (if it decodes a different SID because of interference, etc.), so you may have to just search for the BSI message in the appropriate time range in the DSDPlus.event file and see if it points to this channel. (OT: DBAs: any thoughts about marking these BSI channels with an "i" suffix as a clue that they may not be heard in normal rotation and/or a channel to monitor for analog morse ID on some systems?)
  
  I'll note that the license also shows one lower freq on this site, 769.28125 (license loc #1, the only location for which it is licensed), which may just be a "spare" or, according to RRDB, was decided to be used on Killarney Mtn instead (loc #5 on the same license, where it is not licensed; perhaps a license modification application is pending ).

I'll leave it to someone else to decide what to submit as correction here.

Thanks for the copious info, @tbr281. I'll note that the newer screen pics show what I would say is a plenty strong signal, so I'm puzzled by the CRC fails. Did you happen to catch a flurry of them in an otherwise decent decoding, or do you get that many of them normally? Unless someone else has ideas about why this is happening, it might be worth recording a short sample, post it somewhere (Google Drive, etc.), and send a link to it and your screen-pic post to the DSD+ FL email (is that the right procedure anyone, or is there another email address or process?).

(Semi-OT): I've been having my own decoding problems with DSD+ lately and am considering rolling back to earlier versions to see if I can nail it down. I'm not sure it's related to this, though, as I think it has to do with the P25p2 sensing and decoding. This ring any bells with anyone?

Thanks for looking into this and all the info! I need to do more research into why this is happening.. I actually get a lot of crc fails and get the occasional bursts of decodes every 2-3 minutes.. but seeing those fails is what I see the most. Could this be happening because I run dsd/FMP inside a virtual machine? I mean.. could the digital data be getting lost due to the fact that it’s a virtual USB port in windows?