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:https://drive.google.com/open?id=1Nch3c … 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!
Thanks,
Tom