@ScruffR
I tried the code one more time, and it gave me the same behavior. It worked for three frames and stopped after that. I don’t know what is the issue for that.
The frame that you are seeing before that is for the original code that I’m using, which gives me delay 2-3 seconds between each frame.
To reflect the debug suggestion from above
char szReceive[64] = { '\0' };
int idx = 0;
uint32_t ms;
uint32_t msPublish;
bool frameStart = false;
void setup()
{
Serial1.begin(19200);
Serial.begin(115200);
}
void loop()
{
ms = millis();
while (Serial1.available() && millis() - ms < 1000 && idx < 38)
{
char c = Serial1.read();
Serial.write(c);
if (c == 'S')
{
frameStart = TRUE;
idx = 0;
Serial.print("<");
}
if (frameStart)
{
szReceive[idx++] = c;
szReceive[idx] = '\0';
}
}
Serial.println(">");
Serial.println("Fallen out of while");
Serial.print(frameStart);
Serial.print('\t');
Serial.println(idx);
if (idx >= 38 && millis() - msPublish > 1000)
{
Serial.print("Publishing: ");
Serial.println(szReceive);
Spark.publish("Carpet1", szReceive, PRIVATE);
msPublish = millis();
idx = 0;
frameStart = FALSE;
}
Serial.println("-----------------------------------");
}
Thanks @ScruffR
I’m trying this code now.
@ScruffR
Same behavior, and same output 
Unfortunately, I don’t have a direct access to the Spark core now to check the output on the USB serial.
One remote chance to try fixing it might be to increase the interval between publishes millis - msPublish > 1500.
Maybe the speed limiter for Spark.publish() is a bit overenthusiastic 
(one per sec should be allowed tho’)
If this cures the problem, you can reduce the 1500 gradually, to find the max allowed speed.
@ScruffR
I tried that, but nothing changed even with changing the interval to 2 seconds:
Do you think that the code is stopping the spark from publishing in the cloud after 1-2 seconds?
What is odd is that the timestamps on the dashboard are all referencing the same second, which would explain why only three (plus the online msg) turn up.
Either one publish causes multiple events or my logic is wrong - I have to meditate over that after I’ve stopped crying 
@ScruffR
I think that the publish might cause multiple events since two of these three frames are different. Thanks for helping me in that. I’ll try tomorrow to check the output on the USB serial, and let you know what is happening there. I just have a stupid question about the USB serial. Do I need to put the Spark on the listening mode to read the data?
Thanks in advance.
No, as soon you do Serial.begin() the serial port on the Particle device gets opened and data gets sent, no matter if there is anybody receiving or not.
Crap!!!
I’ve just seen my mistake!
Inside the if I do set ms = millis(); - it should be msPublish = millis();
Sorry for that. I’ll correct this in all the code blocks above.
Great. I’ll try that now. Do I need to change it after the void loop() also?
No, that’s the one that’s used for the while() timeout, this is correct there.
@ScruffR
Okay. I’m trying that now.
Thanks @ScruffR
It solved the issue of stopping the publishing on the cloud, but there is an issue with the integrity of the data. That's what I mean:
SA00000080B00800000C00000400D00000000E
SA00000000B00000000C00400400D00000000E
SA00000000B00800000C400000000000B00000
SA00000080B00800000C00000B00000000C004
SA00000080B00000000C00400000D00000000E
SA00000080B00000000C00400400D00000000E
SA00000080B00000000C00404B00000000C004
SA00000080B00000000C40400000D00000000E
SA00000080B00800000C40000000D00000000E
SA00000080B00000000C00400B00800000C400
SA00000080B00000000C00000C00404400D000
SA00000000B00000000C00404400D00000000E
SA00000000B00000000C00404400D00000000E
SA00000000B00000000C40400C00400000D000
SA00000000B00800000C00400000D00000000E
SA00000000B00800000C00400400D00000000E
SA00000000B00800000C40000C00400400D000
It seems like the last segment D with its data is being replaced with the data of segment C.
I’m not sure what I’m seeing there.
I don’t know the expected output/protocol, so I can’t tell right from wrong.
But if you got the baud rate right and the other settings of the sensor match (8bit, 1stop, no parity) this is pretty sure what the Particle “hears” from your sensor.
Could there be problems with the wiring?
One other thing to try is to add a buffer flush - I’ll whip something up.
On second thought it might even be more likely to be a buffer issue.
I guess your sensor is already filling up the buffer before you got chance to read anything out the buffer.
So try Serial1.flush() as last line in setup() and in the if() block.
If this does not work try this function instead.
void flush()
{
while(Serial1.read() >= 0)
SPARK_WLAN_Loop();
}
Actually the correct data should be something like this:
and the wrong data is:
I did make sure that the sensors send correct data through the serial port on the PC by using the Putty. Also, the board that gives me the sensor's data sets on the same setting that you mentioned. In addition, I'm sure that the wiring is correct, since the original code that I posted gave me correct data but with long delay(between 2-3 seconds). Do yo think that I should make a serial1.flush(); or something like szReceive=" "; after each publishing?
@ScruffR
Do you mean inside the third if() block? because I have three if() blocks in the code.
Thanks.
Sorry! Yes the one with the publish() inside
If this doesn’t work either, you might have to slow down your sensor output somehow.
@ScruffR
It didn’t work, but I’d like to test the flush function instead. Where I should put this function? Because I put it after the third if, but it gave me this error:
test3.cpp: In function 'void loop()':
test3.cpp:44:2: error: a function-definition is not allowed here before '{' token
//ms = millis();
make: *** [test3.o] Error 1
I put it before the void loop(), and it compiled correctly. I’m trying it now.
Thanks in advance.
@ScruffR
The same issue with the flush function. I’ll try tomorrow to see the data on the serial USB to make sure there is nothing wrong with the sensor’s data, and I’ll let you know about that .
I appreciated your kindly help.
Thanks a lot for your time.