UC15: how to discriminate the cause of jamming detection?

We develop a vehicle tracking device with UC15 and we activate the jamming detection so that the device warns of possible signal blockages to the driver of the vehicle or take any other action, including stopping the engine through cut off fuel or power:

AT+QJDCFG=“urc”, 1

Our problem is that the UC15 frequently triggers Jamming events when the vehicle is in an area with poor network coverage, mainly in:

1- underground parking
2- routes in rural areas

We need to test the other parameters of AT+QJDCFG to be able to differentiate between poor network coverage and a signal inhibitor that tries to block device communication. The goal is:

a) to be able to filter jamming events due to poor network coverage (to detect mainly jamming due to an inhibitor device)

b) or, to be able to differentiate when jamming is fired for one reason or another, and to take different actions in each case.

To do these tests we would appreciate the help of who could offer us the following information (totally or partially):

i) a more detailed description of what the QJDCFG parameters mean (leaving aside ‘urc’ and ‘period’ which are the most obvious)

ii) how is the relationship of the value of these parameters with the sensitivity in the detection? Which are directly proportional (the higher the value, the greater the sensitivity to detect Jammin)? And which are inversely proportional?

iii) Finally, if anyone has any advice or suggestions on how to design these tests (or which of the parameters of QJDCFG are the most important) to obtain useful results, we will be very grateful to whoever shares that information.

Thanks in advance


Dear Sir,
Thanks for your inquiry.
Quectel Jamming Detection supports to report the appearance and disappearance of jamming
automatically via URC to notify the MCU. Quectel Jamming Detection supports to optimize the detection conditions by configuring and other parameters of AT+QJDCFG. To detect and report the jamming, some basic conditions are verified.
For your issue, i think you can check the following explanation to those parameters, and try to adjust them to meet your requirement.

And we also provide the example to guide you how to set it.

By the way, the module just can detect the external Jamming, can not eliminate it, of course cannot judge the Jamming source. After you set the above parameters, the module will detect external jamming according to your set parameters, then will report the URC to indicate Jammed or No Jamming. Thanks!


We’re doing something very similar.

However, your explanation is not very helpful since we have no idea what these tuning parameters means, without better/more information on how the jamming detection actually works.

  1. In other words, what is the theory behind the various (default) values?
  2. Do you have any application or white paper on this?


1 Like

Thanks for the reply, but…

I agree with eabase, there are too many parameters to modify without knowing exactly its meaning (at least for the knowledge that I have)

I tried to modify ‘mnl’ and ‘minch’ in a rude way to see if there was any change in the detection of jamming, and I saw no changes that would indicate a way to vary the values.

If, as eabase says, we had a diagram (theory) of how jamming detection is performed, perhaps I could imagine why poor network signal coverage produces the same response in UC15 as a signal inhibitory device.

Thanks again.

Dear Sir,
Please check the following picture which illustrate the working process of Jamming detecting function in GSM network. And it is similar with WCDMA network which just have some other different parameters. Sorry no other application or white paper on this. Thanks!

Thank you for the kind and prompt response.

But I must say that I am quite disappointed: the designers and manufacturers of a device, do not have information about a functionality of that device?

I arrived at the forum because I read the documents that you publish referring to the subject and I could not solve the problem. But I find that the answer in the forum is the copy of the text of the documents.

Let’s do an imagination exercise: I send ‘AT+CREG?’ command to UC15 and it replies ‘+CREG: 0,1’. According to the documentation, ‘1’ indicates ‘Registered, home network’, but suppose it happens that UC15 returns ‘1’ both when it is registered and when registration is denied. ¿? !!! How to know when the module is registered and when not ?
Of course, this is not a real situation, it is just letting the imagination fly.

However, the following is a real situation: UC15 reports ‘+QJDR: JAMMED’ both when there is poor (or total lack) network coverage and when the module is being interfered with by a jammer device. In this case, ‘+QJDR’ stops providing the function as jamming detection and becomes something else, which is not well known in which situation it can be useful.

Thanks, anyway

If you google for “Jamming Detection Application Note” you will find some dated documents where that figure came from. That said, it’s just too bad that Quectel does want to provide us with the updated documents, so we don’t have to resort in looking at potentially dangerous and malware ridden “internet” finds.

To ask a more specific question of Quectel support:

How does the 0-31 value range of the “mnl” parameter map to absolute RSSI values? What RSSI level corresponds to 0, and how many dB is each step?

Also, same question but for the “pscanfineelev”.

Taking a stab at Gustavo’s question/issue, I’m gonna make a wild guess that, based on the alert behavior that you’re observing, you’re operating in UMTS mode, and your signal quality (S_QUAL here, EC/IO in standards land) is falling below the “minsqual” threshold and flagging it as a jamming event. Try pegging that at -30 and see if it doesn’t stop the erroneous event trigger.

Thanks for your suggestion, tguiden.

I am going to test it because it is very reasonable, since I have seen that device communication changes of type of network in several moments: I’m watching the change that occurs in the parameter Act (Access technology selected) of ‘+COPS:’ and it changes many times between 4 (UTRAN W/HSDPA), 2 (UTRAN) and 0 (GSM).
So thinking about a degradation in signal quality is a good idea.

I also join tguiden’s request for further clarification of the parameter ranges: on the internet I have seen ranges of values for ECIO, RSCP, etc. other than those handled by ‘AT+QJDCFG’