SparkFun Forums 

Where electronics enthusiasts find answers.


Forgive me for pestering you again, but I'm having a consistent problem with the old "Module failed to respond. Please check wiring" error message.

I've got two systems at the moment: one in the workshop, and one on a potato harvester (don't ask!) which is the intended application of the contraption I'm designing. I get the aforementioned "Module failed to respond" error once in a blue moon, but I get it about 30% of the times that I try to start up the system on the harvester. I can always solve this problem - on a temporary basis - by just restarting the whole system. However, the device is reaching a point where it might actually be of some practical use, and regularly restarting everything would be extremely inconvenient for my agricultural clients.

I need to get to the bottom of what's causing all this, so that I can stop it. There doesn't seem to be any problem with the wiring, but I'm happy to send you pictures of anything you want to see (phrasing?). My code is here: ... OcISyoy-Fq. All the issues which I've discussed elsewhere on this forum now seem to be resolved - thanks in no small part to all your efforts.

Hi again Tom,

I was worried that the issue would crop back up since it mysteriously stopped back in your first post. One thing that I remember from your first post is it appeared you had both antenna jumpers closed. Is that still the case? It might be the module is trying to start up but is hitting an intermittent error with the antenna selection so it is freezing. Make sure that you have just one of those two jumpers closed, depending on which antenna option you are going with.

Also, this error almost always points to a power issue or other weird connection problem so I have a few questions about how you are powering the M6E. First, how are you powering the circuit in the harvester? Is it battery powered or do you have a dedicated supply? What are the ratings of the power supply? Finally, are you powering the M6E through an attached Arduino or directly through the power input pins?
Hi again, Mark.

I think we're getting a little bit muddled up. Forgive me for disentangling things in a bit of detail.

There are three - probably distinct - errors that I've experienced with the M6E in my time working with it:

Type 1. The M6E starts reading tags and then freezes, sending nothing at all to the serial monitor; or, on start-up, prints "Press any key to begin scanning tags" and is unresponsive thereafter.
Type 2. The M6E reports "Scanning...", but fails to pick up any tags, even when they're held right up to the external antenna.
Type 3. The M6E reports "Module failed to respond. Please check wiring."

Although we're not 100% sure, myself and my team have accrued a fair bit of evidence that Type 1 errors (as in the list above) are caused by a high power setting. They seem to crop up when the power is set to 2700, and somewhat less frequently at 2500. I have yet to see a Type 1 error occur when the power is set to 2000 - but there's a first time for everything! The drop off in range from 2700 to 2000 is not significant - at least within the context of this project - and so I'm happy to consider this particular problem solved.

Type 2 errors are always caused - again, within the context of this project - by the M6E using its internal antenna rather than the external one. (I know this because, when I waft tags next to the internal antenna, they're picked up, and not otherwise.) This use of the internal antenna is, in turn, caused by one of two things: either A) dodgy soldering between the two contacts, or B) a loose connection between the M6E and the U.FL to RP-SMA interface cable.

Type 3 errors are still a bit mysterious, and these are what I'm struggling with at the moment. We know of a few tricks that will induce a Type 3 error on the system in the workshop, including:

* Separating the Arduino and M6E;
* Switching the SW/HW switch from SW to HW;
* Setting baud_rate as something other than 115200 in softSerial.begin(baud_rate).

However, none of the above seems to be what's going wrong on the harvester...


To re-state the problem: we're getting Type 3 errors when we try to start up the system, and also sometimes, if I close and re-open the serial monitor, once the system is up and running. This doesn't happen every time we start up the system, but often enough to be a problem. Some points that might be useful:

* Restarting *everything* - from the tractor engine downwards - seems always to fix the problem. (Unfortunately, regular restarts are impractical in a commercial setting.)
* The power arrangements are as shown in the attached images. Strangely, the components seems to work perfectly well without an external - i.e. non-USB - power source, and removing the external power source seems to make the system slightly more reliable, so that's what we're going with for the time being. It would be straightforward, however, to revert to using an external power source.
* Digging around in the code a little bit, when a Type 3 error occurs, nano.msg[0] gives an error code of 1 (ERROR_COMMAND_RESPONSE_TIMEOUT) if the system has just been started up, and 3 (ERROR_WRONG_OPCODE_RESPONSE) otherwise.
* Pictures of some of the soldering on the boards are here: ... zqiqEDAdXG. Please tell me if anything looks amiss.
* By the grace of God, Type 1 and Type 2 errors are no longer occurring.

Sorry for such an epic post!

You do not have the required permissions to view the files attached to this post.
Couple of things.
Type 1 : clearly a power supply issue. This is known behavior that I have seen a lot. Make sure to get a strong power supply and strong capacitors to handle the peek load. I use a charged LIPO 1900mAH battery (but that is in test, NOT production). As you put it on a tractor, make sure to have a strong enough convertor ( I would go for at least 2A) from the 12V to the 5V and with enough capacitor power (2000 uf - 5000 uf) on the 5V side to handle the power demand.

Type2 : You are on the right track, If you have removed the soldering from the Internal antenna, it should NOT react on that. But from the pictures I get the impression that still both internal and external antenna are selected (maybe I see wrongly or these are older pictures). One should ONLY enable internal or external.

Type3 : This could still be the same problem as Type1, but also SoftSerial(). I like SoftSerial a lot, but in my personal testing I never got it to work long term stable above 57600, let alone 115200K. This is because of the receiving end, not sending. Sending on 115K will work, but as RX is interrupt driven and depending on the processor load it fails above a certain speed. Hence you will see that a sketch will sent instruction the M6E to work on a much lower speed (38400) than the default 115K after start. For test you could try to reduce that speed even further ( e.g. 19200 or 9600). If you would set the switch to HW and connect the serial TX/RX to a real UART, like a Serial1, one could work on 115K

One Last point make sure to have enough cooling going on the M6E chip. It gets warm very quickly and become unstable.

What I have observed (and measured with a scope), once the M6E goes wrong, it is sending garbage all the time. The only way to reset is remove the power from the M6E and reconnect. You should not have to power down the complete tractor..removing the power from the processor and M6E and restart should do the job.