Unexpected JDR JAMMED during CSURV

5 thoughts on “Unexpected JDR JAMMED during CSURV

  1. Hi all,

    In some of our devices we are seeing unexpected JDR JAMMED reports during CSURV network scans. The only reliable trace I have happens to be for a network scan (CSURV) which failed. I don’t know if the fact that the scan failed was a factor in causing the Jam report. 

    The SIM is multi-operator enabled SIM (can register on three networks in my area and normally works fine on any of these networks). Then I get this:

    10/01/00 03:57:46.000 :MODEM : Send ASC0:”AT#CSURVB=10″
    10/01/00 03:57:46.010 :MODEM : Receive ASC0:”#JDR: JAMMED#JDR: JAMMED#JDR: JAMMED#JDR: JAMMED
    10/01/00 03:57:46.120 :MODEM : Receive ASC0:”Network survey started …+CME ERROR: Network survey error (No Carrier)”

    There seemed to be a problem with our M2M platform operator which is not allowing our SIMS to register. But why / how can this cause JAM reports?

    Is anything happening on channels (i.e how device hops around looking for channels/cells) during scan that make a JAM report more likely?

    You might say, oh, your system was really jammed by a jammer. But we got hundreds of jam reports from the field when the network operator problem occurred that prevented our systems from registering. The root cause is still under investigation as to why our SIMs were not allowed on the network.

    GE865 v10.01.003



    1. Roberta G. wrote:


      it could be that 4G cells overlap 2G cells that’s why you receive jamming messages: a 2G module can’t decode 4G signals. 

      I have some questions:

      1) Did module register on the network at the end?

      2) Can you please send me the value of commands #JDR and #JDRENH in order to find a setting that avoids all those fake jamming messages?

      1. Hi,

        Yes, the device eventually registered (after 20 min). The settings are

        #JDR: 4,70,5


        #JDRENH: 0

        Very interesting. Any reson though why we would see this in particulr during CSURV. We are getting several reports from the field where the device reports JAM just during or after a CSURV. Any idea?



        1. Roberta G. wrote:


          with the #JDR setting you have, jamming detect is enabled and the jamming condition is reported every 3 seconds on serial line. You got this during #CSURV command because it’s likely that during network survey module found a 4G channel which it couldn’t decode it behaves as the channel has been jammed.

          To avoid this you should disable jamming detect enabled with command #JDR=0 (it’s an old algorithm) and enable the new algorithm which prevents fake jamming. I think you should set command:


          which enables an algorithm based on power measurements: if the difference of power levels is more that a threshold then the jamming state is notified.

          Let me know if with this setting you still have the jamming unsolicited.


          Best Regards,

          1. Hi Cosmin,

            I will play around with this. It is not easy for me to reproduce the problem. I guess only some cells have 4G in the old 2G band so in many places the problem is never seen or reported. 

            Switching to the new jamming mechanism (JDRENH) is probably better, but of course carries the risk that some false Jams will be detected where none were before – because the algorithm is difference. 

            Until I am happy with the new jamming my temporary solution is to not act on jam reports which happen while a scan (CSURV) is ongoing.

            Thanks for your help,