Scrambled serial output

Same project as described in "Issues with..." below. This related to serial communication between controller and the serial communicator available through the Microcode Studio programming interface.

I use a standard 9 pin, 6 foot serial cable and a native (not converted USB) serial port to issue commands to the PIC (16F877A, 4MHz) - a means to set the time, turn on various channels of lighting, query variables, etc. I interface to the PIC through a tried and true MAX232 module. On the bench, I was using:

'-----SERIAL
DEFINE DEBUG_REG PORTB
DEFINE DEBUG_BIT 1
DEFINE DEBUG_BAUD 2400
DEFINE DEBUG_MODE 0
DEFINE DEBUGIN_REG PORTB
DEFINE DEBUGIN_BIT 2
DEFINE DEBUGIN_ MODE 0

and managed flawless communications - commands echoed back without error and I could read back (from the PIC) multiple lines of formatted data without issue. An example:

IF (CO[0] ="T") AND (CO[1]="I") THEN
REG_VAL[2] = (CO[3]-48) * 10 + (CO[4]-48)
REG_VAL[1] = (CO[6]-48) * 10 + (CO[7]-48)
GOSUB CLK_WRITE
DEBUG "TIME SET: ", #REG_VAL[2], ":", #REG_VAL[1], 10
PAUSE 100
ELSE
DEBUG "TIME ERROR",10
ENDIF

Not a single munged character in dozens - if not hundreds - of trials.

Once the project was moved to near the aquarium (same cord, computer, and module - just "left" about 5 feet)... communications were completely scrambled. I've reduced the baud rate to 1200 and have now LIMITED success... When serial is initiated, the PIC responds perfectly with "WAITING" as expected. Commands are accepted and the routine "falls through" with "EXITING" as it should. The difficulty is that multi-line transmissions are still unintelligible - consistent, but unreadable. This:

IF (CO[0] ="L") AND (CO[1]="P") THEN
FOR LP = 0 to 45 STEP 5
READ LP, word MIN_TEMP, D2
DEBUG "POS: ", DEC2 LP, " MIN: ", DEC4 MIN_TEMP, " PATTERN: ", BIN8 D2, 10
NEXT LP
READ 252, D2, LP3
DEBUG 10, "SET TEMP: ", DEC2 D2, " RANGE: ", #LP3, 10
READ 254, D2
DEBUG "STORED PLUGS: ", BIN8 D2, 10
PAUSE 100
ELSE
DEBUG "DATA READ ERROR",10
ENDIF

--a routine that displays each DATA statement controlling the lighting cycle, fails completely - not a single readable character, until "EXITING" at the end. This:

FOR LP = 0 TO 8
DEBUG DEC2 LP, ":", STR CO[LP]\1, 10
PAUSE 100
NEXT LP
--a routine that displays each character of the command received works without flaw.

I am tempted to reduce the transmission speed further - it need not be fast - but, it bothers me that I don't understand the problem. Anyone see a problem or have some advice?

I assume you are using the very same setup that you say had success with. Only difference is you now moved it closer to the acquarium. In this condition, the very same test program which was working further away is now failing in proximity with the acquarium.

Couple of things I would check on.
1 - Check your power supply. Is it rippling more when near the acquarium? Change it to a different make to confirm.
2 - I would look at the declaration of variables and their neighbours to identify which variables could get over-written by a mistaken index into an array. This can possibly over write the suspect variables that you are saying are getting disturbed.

Quote:

---

Originally Posted by Jerson

I assume you are using the very same setup that you say had success with. Only difference is you now moved it closer to the acquarium. In this condition, the very same test program which was working further away is now failing in proximity with the aquarium.

---

1 - Check your power supply. Is it rippling more when near the acquarium? Change it to a different make to confirm.

This is a good point and brings up the fact that the power supply being used near the aquarium is different than the one used on the bench. Both are from reputable manufacturers and are well filtered, but now... as you bring to mind power issues... I have 15 LED driver boards - cheap, Chinese - 10 watt models nearby (though run from a different source). Also, 8 relay controlled 120V cords hang near; it does not seem unlikely that 60Hz is far more dense in the new location. While the consistency of the error gives me pause, I have said repeatedly here and elsewhere - unexplained problem? Look at power routing and supply. I'll try some additional filtering and perhaps shielding my board. Good catch and thank you.


2 - I would look at the declaration of variables and their neighbours to identify which variables could get over-written by a mistaken index into an array. This can possibly over write the suspect variables that you are saying are getting disturbed.

This seems unlikely, but I will check it; too many times a suggestion to recheck has revealed the problem. I've been working on this for some time, through multiple iterations, retyping portions and rechecking as the version number stacks... Always this issue has persisted; I have just let it slide as other considerations took precedence. Now, as I approach a working version... Just to be sure, you see nothing in the code that causes concern?

Thanks again, even just the opportunity to talk it through is very helpful.

Make sure you have a good ground connection on the serial cable.

Adding a short pause (50) after each statement has resolved the serial output issue. Not sure why, but in this case at least, the answer is satisfactory.