Trying to see the incoming data through the serial

@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 :wink: .
I appreciated your kindly help.
Thanks a lot for your time.

You have already figured out that you can’t put the function definition inside another function.

You can either do it before setup() and loop() (as you’ve done already),
or after these functions, but this would require a function prototype before its first use.
In your INO file you can put it after, without a fn-prototype, because the preprocessor will add missing prototypes for you.

1 Like

Thanks @ScruffR for this great explanation.

1 Like

Dear @ScruffR
I connected the board to the USB to see the serial USB data, and I noticed that the data in PUTTY looked like this:

Fallen out of while
38 1-----------------------------------

Repeated for 10 times
Fallen out of while
SA00000000B00000000C07FC007FD00000000E
0 0-----------------------------------
SA00000000B00000000CE000FSA00000000B00000000CE000FF00D00000000EFallen out of whi
le
38 1-----------------------------------
Fallen out of while
38 1-----------------------------------

Repeated for 90 times
Fallen out of while
SA00000000B00000000CE000FF00D00000000E
0 0-----------------------------------
0 0-----------------------------------

Does this data mean something? Can I figure out what is the reason of the wrong data(such as SA00000000B00800000C400000000000B00000) from these stream of data?
Thanks in advance.

It definetly does mean something :wink:

Especially the line

SA00000000B00000000CE000FSA00000000B00000000CE000FF00D00000000EFallen out of whi
le

is bad since it never should get this long (>38). But it is also telling you, that you’re definetly experiencing an buffer overflow.

If you got the code next to the output, you can pinpoint problem areas.
Then you just add some more print statements to narrow it down even more, till you got the bug squashed :+1:
Have some play with it :wink:

1 Like

Thanks a lot @ScruffR
Please what you mean by:

where I can add more print statements and what is the benefit of adding them?

You can just add a print statement and printout whatever variable or checkpoint you think will help you figure out what’s going where and when and in what state the individual variables are at any particular time & place.
This is how debugging is done, if you have no inprocess debugging.

After all it’s your device, so you can alter the code and scatter prints all over it :wink:


If you can’t slow down your sender or add some kind of flow control, you might have to change the way of receiving.
You got a start (S) and an end (E) mark. Just flush the buffer before you’re prepared to read, wait for the start mark, read your data, once you got your desired length and find the end mark where expected proceede - if not, retry with timeout.
If you got the possibility, try to replace the end mark (and the milestones A, B, C, D) with something that can’t appear as part of your data (if your data is HEX 0…9 & A…F are no good choice).

2 Likes

Dear @ScruffR
Please I’d like to ask you if I can use the idea of the circular buffer to solve the issue of the buffer overflow? Because I checked the data that I’m receiving from the sensors, and the problem is starting to appear after 63 byte, which is the size of the buffer, as you told me before.
Thanks.

The implementation of USARTSerial on the Particles does already use a circular buffer, so adding your own would not solve your problem.
You’d always face the problem that your data is coming in faster than you read it out. Either new data can’t be stored and will get lost since there still is some unread data present, or you start corrupting data form behind, when you overwrite unread data that might be part of a packet that is already in the process if being read.

An option would be to extend the size of the buffer, but this can only be done when building locally.

So you will need to go one of the two ways I suggested:

  • Slow down/flow control your sender
  • Always flush the buffer before read and wait for new data to arrive in your clean buffer
2 Likes

Thanks @ScruffR for your reply
I just have question about the ways that you suggested. For the first way, can I do the flow control only without the slowing down the speed of the transmission to solve the issue of buffer's overflow?
For the second way, I think that I tried this way in the previous steps without success as shown below, is that correct?

Is there other way to do the second suggestion?
Thanks.

If you've tried the flush as I suggested way back in this thread then it was a "post-flush", but now I'm suggesting a "pre-flush".
The advantage of the earlier suggestion, was that you'd not need to wait for data to arrive, but since you can't be certain that your data in the internal ring-buffer is valid, you need to go for the "pre-flush".
And in this case you don't need my flush function but should be able to use Serial1.flush().

As answer to your other question I just quote myself

1 Like

@ScruffR
Please could you tell me at which location in the code I should put the pre-flush?
Do you mean that I should use the CTS,RTS pins to do the flow control for the serial? Or there is another way to do that?
Thanks a lot.

AFAIK hardware flow control via CTS/RTS are not (yet?) supported by the USARTSerial Class, but you could do something similar with any pin on your two devices.

Depending on your preference you could just poll a pin on the sender side, till the designated pin got signaled that it is clear to send, or you only send after you got a RX “signal” from the receiver, or you use interrupts on either or both sides to trigger the “sending” or/and “receiving” (actually writing/reading to/from the buffer), …

These are a few suggestions. If you decide to go for any of these, please do some research on it first and show what code you’d use to make it work and don’t ask here instead.
It will stick better if you found out yourself than when you just get it served.

Just like the “pre-flush”. I did already tell (twice in two seperate posts, each time in a short sentence) where to put it, but it did obviously not stick, since you seemingly didn’t meditate enough over my actual post, you just sprang to the conclusion “I’ve already tried and it didn’t work”, so you didn’t actually get what I really wrote.
Try to understand what I could have meant and why and how it should work, then try to come up with your solution code and post it here.

I want to help you and I want you to really understand what’s going on rather than just get your code running :wink:

1 Like

@ScruffR and @Ahmedsa1983, another approach to flow control uses XON/XOFF characters. It does require that the data uses only ASCII chars 32 (space) to 127 and that your sender supports the protocol since it is the Photon that requires pacing and not the sender.

Yet another approach would be to use an ACK/NACK characters. The sender sends a message and waits for an ACK from the receiver as proof it was received correctly. A NACK indicates a problem with the data and the Sender can resend.

I’ll discuss with @mdma for ideas. :smile:

1 Like

@ScruffR
Firstly, my english is not my first language, so sometimes I couldn't get the whole idea from the first time. Therefore, I apologize about that it is my fault not yours. Secondly, i'm new in this area, and I'm trying to understand the idea from other previous posts in the community before creating a new post to make sure that it is not
being solved before by other. I'm sorry if I'm wasting your time or the other's time, but I'd like to understand and learn about the spark core to be able to build my system, and achieve my goal. Finally, for the pre-flush location, you,re correct that you told me about it before but I was careless since I didn't pay attention to your post carefully:

Also, when I'm telling you that I tried that without success I mean that I really tried and I'm not just saying words.
I appreciated all of your help, and I'll try not to bother you again with my stupid and careless questions.
Have a great day.

Thanks a lot @peekay123
I’ll try to read about that to know how can I apply it on my code to get rid of the buffer overflow issue.
I appreciated that.

@Ahmedsa1983, I didn’t mean to give you the feeling that you shall not answer anymore questions.
I - just as others like @peekay123, who has chimed in with some good suggestions - like to help people to get up to speed with the great Particle devices.
So feel free to ask away, but also start playing with code - this way you might get your own feel of things.

Paul’s suggestion about XON/XOFF is a more standardized version of what I already suggested in the shape of rethinking your start/end markers and milestones.
And ACK/NACK turns my suggestion to send a “start sending” request round and puts the sender in charge to first make sure he can or cannot proceede.

All valid options and you are the one to decide what you like most or understand the easiest, till any means of hardware or system backed flow control gets baked into the firmware.
A long time ago, I suggested RTS/CTS support, but there never was time or call to add it :wink:

2 Likes

Just a quick question. Where is readStringUntil() documented? I can’t find it anywhere in the docs.

@Ric, the readStringUntil() function belongs to the Stream class which is not documented. However, the Particle Stream class is the same as the Arduino Stream class documented here. I'll add the Stream info to the docs when I get a chance. :wink:

1 Like

@Ric, I just pushed the Stream documentation updates. They should appear shortly :smile:

1 Like