I have been struggling to get my Moteino or MegaMoteino to work correctly using the hardware serial in either the Moteino or new MegoMoteino to communicate to an external motor controller. My goal is to replace the hardwired remote with a wireless solution.
The motor controller sends out a "heartbeat" data packet every 100 msecs and will not respond to any commands unless the 'remote' first sends back the same heartbeat data packet after about a 30msec delay. To remove complexity I first got my very basic code to work fine on a standard Arudino SER0 and also on a Mega 2660 SER0 or SER1. After struggling with the Moteino/MegaMoteino for quite some time I decided to put it all on a scope and that's when the problem became very obvious. In all of my examples when using SER0, I make sure not to have the FTDI adpater in place when running the program.
My code is very basic:
int max_array_size = 5;
byte receivePacket [5];
byte sendPacket[5] = {2,136, 49, 8, 4}; // this is the 'heartbeat' packet
void setup (){
Serial.begin (9600);
}
void loop (){
if ((Serial.available () > 4)) processInput ();
}
void processInput (){
byte c = Serial.read (); // there should be a packet with exactly 5 data bytes
for (int i = 0; i < 5; i++)
{
receivePacket [i] = c;
}
if (c == 0x04) // last byte in packet ALWAYS 0x04
{
SendToSerial();
}
}
void SendToSerial()
{
delay (30); //TX reply to heartbeat should be at least 30 msec after heartbeat received
for (int i=0; i < 5; i++)
{
Serial.write(sendPacket[i]);
}
}
In the first attachment on a regular Arduino or Mega you can see (yellow trace) the received 'heartbeat packets' which after being received by the Arduino (in this simple example no verification of received bytes is done), the Arduino waits at least 30 msec and sends back a packet reply (green trace).
With the Moteino or MegaMotein, before the reply TX goes out and virtually simultaneously as the 'heartbeat' is being received the received signal is being picked up and resent (too early) back to the motor controller. This premature extra TX packet has been creating havoc in my design. I guess this is poor isolation of the Moteino TX and RX lines - capacitive coupling between too close traces?? I was thinking of trying the SoftwareSerial and making sure the RX pin is far removed from the TX pin as maybe that would help but the SoftwareSerial would likely use up a lot of my Loop() time for managing sensor data, etc.
HELP !!!!
That is strange but I doubt there is a coupling issue since programming works fine every time.
MoteinoMEGA R1 has thinner traces so I would like to see this resolved on the regular Moteino first then move to the MoteinoMEGA.
In your second capture, it's pretty obvious that the signal is all 0s (at ground level), so that means whatever that is, is no picked up again at all.
As a side observation, I expected to see a Serial.read() in the for loop of your processInput() but you only read one byte in that function?
And I think that's where your problem might be. You're only reading 1 byte from that packet and assigning it to your whole array:
byte c = Serial.read (); // there should be a packet with exactly 5 data bytes
for (int i = 0; i < 5; i++)
{
receivePacket [i] = c;
}
Then the next time around, you read the next byte, and so on, until you finally hit the 5th byte which is what you expect (the 0x04) and then finally send out the reply.
Perhaps what you're looking for is this:
byte c;
for (int i = 0; i < 5; i++)
{
c = Serial.read (); // there should be a packet with exactly 5 data bytes
receivePacket [i] = c;
}
Hi Felix, thanks for the reply. The time base in the snapshots is pretty large so no detail. I will take another picture with it zoomed on one packet. Sometimes the voltages are postive enough to be read as "1" not just zero's. As to the code, you're right, I did not do a copy/paste as the full sketch is much more involved so I typed quickly from my obviously imperfect memory as the serial.read is in the wrong place.
First let me point out that I did not do one experiment on one Moteino. I found the identical odd behaviour on four Moteinos and the two new MegaMoteinos but I did not see this at all on testing 3 Arduino Uno, a Nano or a Mega all on the same breadboard setup. I wonder how this looks on the scope with a serial-USB converter like your FTDI? I will check tomorrow.
I still think this could be an issue with capacitive coupling. I read through some Amtel literature (not specific to this processor) and found several references that in order to hold a pin high (as in this case the TX line should be while the Moteino is receiving a packet) that there must be > 3 pF capacitance between the Vcc layer and the I/O pin. If < 3pF then capacitive coupling could lead to that pin being pulled low. That sounds like what I am seeing. Also, the various resources on capacitive coupling point out this is actually worse with square waves at relatively low frequencies such as square waves at 10,000 Hz.
I could try to feed the received packet directly to the AMTEL pin and bypass your PCB traces to see if that makes a difference. If you have any other ideasa ... I am willing to try. I am surprised this has not been reported before but maybe my application was the first to stress test the design?
Are you constrained to 9600baud?
Could you try anything higher?
Programming and everything I do is at 115200, also most people probably never use 9600 hence if there's a capacitance coupling issue at that low baud rate and not at higher rates then this might be legitimate and I am interested in solving it.
I'm not sure I have a way to test it in the same scenario as you do. So if your motor controller works with UNOs but not with Moteinos then I would like to see how this can be fixed.
I wanted to suggest trying thin hookup wire directly into the pins of the MCUs and see how that affects it, not sure if you'd need to sever the traces leading to the PCB where they could pick up capacity from other stuff on the boards, maybe try it in steps on a regular Moteino... ?
For my specific project, the baud is fixed at 9600 by the motor servo-controller I am trying to interface. However, if you have any scope or laptop serial analyzer anyone should be able to reproduce my observations with two Moteinos RX-TX cross-connected on SER0. In fact I will do this tomorrow to demonstrate this is not related to interfacing with my servocontroller. I'll program one Motieno to send out the same 5 byte data packet every 200msecs while the second Moteino will run the same code in my original post (with your serial.read correction). Nothing else in the mix here just two Moteino's and I will take scope pictures. I will be quite happy if this is all being caused on my end due to my breadboarding with RS485 to my servo-motor controller --- I have a functional workaround I believe by toggling the MAX485 RX-TX enable/disable to ignore anything on the motor controller RX line while it is sending on the TX RS485 bus. I will post my findings tomorrow mid-morning.
Felix - I took my sketch and ran it on two Moteinos (one only as a serial sender, the other as both receiver and reply) by cross RX-TX connecting and otherwise bare. The signals look clean without the RX to TX bleed through. So it sounds like a coupling problem created by the RS485 <---> RS485 MAX 485 chips. I think the Moteino's likely need different R-C termination values than the larger Arduino's. I am now setting up the pair of Moteino's with a pair of MAX485 chips and will dig deeper. I don't see any problem for Moteino users with serial hardware unless like me they need to use RS485. I hope to find the correct values for Moteino RS485 terminations and then can share with the group.