so I am having trouble sending data using software serial's write function.
TX Code:
#include <SoftwareSerial.h>
SoftwareSerial TX(2,3);
void setup() {
// put your setup code here, to run once:
TX.begin(1200);
}
void loop() {
TX.write(60);
}
Is the delay necessary?
RX Code:
#include <SoftwareSerial.h>
SoftwareSerial RX(2,3); //(rx pin, tx pin)
const unsigned int bufferSize = 100;
void setup() {
Serial.begin(9600);
RX.begin(1200);
}
void printBuffer(const uint8_t *serialBuffer)
{
//print contents of buffer
for (int i = 0; i<100; i++)
Serial.println(serialBuffer[i], BIN);
}
void processBytes(const uint8_t value)
{
static uint8_t serialBuffer[bufferSize]; //buffer to hold values
static unsigned int startPosition=0;
if(startPosition < bufferSize)
serialBuffer[startPosition++] = value;
else
{
printBuffer(serialBuffer);
startPosition = 0;
}
}//end of processBytes
void loop() {
//check if data is available in serial buffer
while(RX.available())
{
//process data
processBytes(RX.read());
}
}
If i transmit the number 60, it prints 226 constantly for 2-3 seconds, then prints 60 for a short while, then goes back to printing 226. Am I doing something wrong with my code?
FIRST QUESTION: In the case when startPosition (in the process function) equals 100, it will call print. Print will then print 100 integers. Now, when doing that, there could still be data being transmitted from the transmitter. But the read function won't be executed until printBuffer returns, process returns, and the while loop iterates again. So during that time, couldn't some transmitted values potentially not be read?
SECOND QUESTION How come Software serial doesn't synchronize incorrectly more often? How is it being so accurate if the start bit is just a single bit and it's a 0. So for instance, if payload has some 0s, how come one of those 0s aren't being assumed to be the startbit? How does this get resolved? I looked at the software serial library, but I am not able to find out why. Any guidance here?
THIRD QUESTION Other than getting the startbit syncing right, are there other ways to sync the data? I was reading of NRZ encoding, manchester encoding, etc. Can any of these be implemented here? Also, would it be wise to alter the softwareSerial library to have more than one startbit?
Any guidance would be very appreciated! Thank you so much! This is all being done with wireless RF modules.
And since this is wireless, i believe it idles low?- whether or not it is wireless is irrelevant. Why do you believe this? – Nick Gammon Oct 26 '15 at 19:43How come Software serial doesn't synchronize incorrectly more often? How is it being so accurate if the start bit is just a single bit and it's a 0. So for instance, if payload has some 0s, how come one of those 0s aren't being assumed to be the startbit?- because there should be a nice big gap between the start of a transmission (which your sending code does not now have). Assuming you have a gap long enough, the first 0 will be the the start bit, it then clocks in 8 characters, and then the stop bit, which is a 1, which makes sure that you don't mistake it for another start bit. – Nick Gammon Oct 26 '15 at 19:44Also, would it be wise to alter the softwareSerial library to have more than one startbit?- no, because you would then have no alternative but to ignore the second one. You are thrashing around with these suggestions. – Nick Gammon Oct 26 '15 at 19:46I was reading of NRZ encoding, manchester encoding, etc.- certainly there are other ways of transmitting data, remote controls and remote-controlled vehicles use other methods than serial. This now is making this question extremely broad. – Nick Gammon Oct 26 '15 at 19:47In a separate post, someone told me that exactly.- where did they say that? Link? The start bit has to be exactly one bit length or the timing of everything else would be out. – Nick Gammon Oct 29 '15 at 19:43should i make the above questions a new question?- your question about Manchester and NRZ vs Serial should be a new question, certainly. And your questions about start bit length seem to me to be another question again. This question started off being about "why doesn't this code work?" and is now morphing into "how does serial comms work, exactly?". – Nick Gammon Oct 29 '15 at 19:45