Go Down

Topic: Serial Input Basics: example 5, question (Read 2067 times) previous topic - next topic

Robin2

But now it is causing a problem since it reads beyond the terminating NULL.
You can bet the farm that it isn't - unless doing is part of its defined behaviour.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Deva_Rishi

You can bet the farm that it isn't - unless doing is part of its defined behaviour.
I know, but then what is causing the crashes ? anyway time will tell.
To 'Correct' you have to be Correct. (and not be condescending..)

Robin2

I know, but then what is causing the crashes ? anyway time will tell.
I don't know either, but pfaffing about with strtok() would just be a waste of time. It's what I call the "scatter gun" approach to debugging - "do something - ANYTHING"

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Deva_Rishi

I don't know either, but pfaffing about with strtok() would just be a waste of time. It's what I call the "scatter gun" approach to debugging - "do something - ANYTHING"
I thought there were totally acceptable solutions presented earlier (Adding a separator after reception of the terminator '>') and on top of that nobody has given any explanation for the strtok(NULL,NULL) not working properly. Now the solution seems to be "Trail for a long time and wait for Error"
We are going from the point of view that this is just a partial test sketch but  i haven't seen a complete sketch anywhere (i may have missed it) and nobody complained about it.  I do hope there is not a part where interrupts are turned off, since Serial reception does depend on it being turned on. I would have started parsing manually without strtok() even if it was just to exclude that the list of possible issues. (and also because i don't think it would be to hard to do.)
To 'Correct' you have to be Correct. (and not be condescending..)

cattledog

#49
Jan 18, 2019, 07:49 pm Last Edit: Jan 18, 2019, 07:51 pm by cattledog
Quote
on top of that nobody has given any explanation for the strtok(NULL,NULL) not working properly.
My thinking has been that either the strtok implementation in the esp8266 core has a problem, or, more likely in my opinion, that the NULL is somehow missing. Perhaps because the total received chars overruns the 32 character boundary.

I think that the idea to print the ascii value of everything received as it arrives is a good debugging idea.

brice3010

...I do hope there is not a part where interrupts are turned off, since Serial reception does depend on it being turned on...
To prevent any fog clouding the issue at hand: my post #34 contains the bare-bones program with all essentials related to reception and parsing available. No interrupts are disabled anywhere, not in the original, not in the current bare-bones program.

brice3010

#51
Jan 18, 2019, 08:24 pm Last Edit: Jan 18, 2019, 08:36 pm by brice3010
My thinking has been that either the strtok implementation in the esp8266 core has a problem, or, more likely in my opinion, that the NULL is somehow missing. Perhaps because the total received chars overruns the 32 character boundary.

I think that the idea to print the ascii value of everything received as it arrives is a good debugging idea.
I just got home, downloaded the modified receiving/parsing program (see annex). This program expects a dot after the TX identifier, which is being sent too by the transmitter. Here are the results of the first readings:

When no missing dot reported by RX

parse data() actual: 4 6 . 9 5 , 2 0 . 7 5 , 9 . 4 9 , 1 , 7 , B .   .
parseData() ASCII : 52 54 46 57 53 44 50 48 46 55 53 44 57 46 52 57 44 49 44 55 44 66 46 0 46 0 0 0 0 0 0 0


Actually parsed data: 46.95 : 20.75 : 9.49 : 1 : 7 : B

When missing dot reported by RX

parseData() actual : 4 6 . 9 6 , 2 0 . 7 5 , 9 . 5 7 , 0 , 4 7 , B . .
parseData() ASCII : 52 54 46 57 54 44 50 48 46 55 53 44 57 46 53 55 44 48 44 52 55 44 66 46 46 0 0 0 0 0 0 0

Actually parsed data: 46.96 : 20.75 : 9.57 : 0 : 47 : B



What surprises me at first view is that
1. more often than not there are missing dot and even though it is not missing, a dot is being added by the RX program, as written on lines 52 to 56.
2. when no missing dot is reported, still 2 dots appear in the actual message albeit with a space between inside the message (noted as a 0 in the ASCII part)

Now this is the program using "missing dot detection" so this is the one that crashes a lot.
When removing he "missing dot program section" (lines 52 to 56) these crashes become very rare.

But then the output becomes (no "missing-dot-detection"):

parseData() actual : 4 3 . 3 1 , 2 1 . 0 0 , 9 . 5 7 , 2 0 , 5 7 , D .

parseData() ASCII : 52 51 46 51 49 44 50 49 46 48 48 44 57 46 53 55 44 50 48 44 53 55 44 68 46 0 0 0 0 0 0 0

RX parsed message = D
43.31 : 21.00 : 9.57 : 20 : 57 : D

No double dots at the end of the actual message.

Note: the first float is a duty cycle reading, the second float is a temperature reading, the third float is a battery voltage reading, the next is an integer for the minute when the TX took place, the next integer is the second when the TX took place and the last is the TX identifier.

I would let this run for 24 hours and report the monitor results if/when crashes occured.

cattledog

I'm afraid I messed up here
Quote
Quote
<47.50,12.50,6.50,5,10,A>
Are the transmitted values always that length, or can the number of digits in the floats or integers change?

If the length is constant, and I count correctly, tempchars[23] should be the letter, tempchars[24] should be the final separator(',' or '.'), and tempchars[25] should be '\0'.
I forgot that Robin2's routine strip both the start and end markers from the message.

The '.' should be at tempchars[23]

brice3010

I'm afraid I messed up here
I forgot that Robin2's routine strip both the start and end markers from the message.

The '.' should be at tempchars[23]

Thank you cattledog, I will test again tomorrow, after this 24h run.

brice3010

#54
Jan 18, 2019, 09:01 pm Last Edit: Jan 18, 2019, 09:03 pm by brice3010
Something strange appeared in the serial monitor just now:

Message x:

actual message content: 4 0 . 8 2 , 2 4 . 2 5 , 7 . 6 5 , 4 1 , 2 , A .
ASCII message content: 52 48 46 56 50 44 50 52 46 50 53 44 55 46 54 53 44 52 49 44 50 44 65 46 0 0 0 0 0 0 0 0
Parsed message: 40.82 : 24.25 : 7.65 : 41 : 2 : A


Message x+1:
actual message content: 4 6 . 9 6 , 2 0 . < 4 3 . 3 2 , 2 0 . 7 5 , 9 . 5 7 , 4 1 , 1
ASCII message content: 52 54 46 57 54 44 50 48 46 60 52 51 46 51 50 44 50 48 46 55 53 44 57 46 53 55 44 52 49 44 49 0
Parsed Message content: 46.96 : 20.00 : 20.75 : 9 : 41 : 1



Message x+2:
actual message content:  4 0 . 8 1 , 2 4 . 2 5 , 8 . 0 9 , 4 1 , 2 2 , A .       41  1
ASCII message content: 52 48 46 56 49 44 50 52 46 50 53 44 56 46 48 57 44 52 49 44 50 50 44 65 46 0 0 52 49 0 49 0
Parsed message: 40.81 : 24.25 : 8.09 : 41 : 22 : A


In subsequent messages the identifier keeps being correct: both in the full actual message as in the parsed message. BUT in the actual message content the trailing 41 and 1 keep being present.

In message x+1 in the second float there suddenly appears a < within this number.
In the serial monitor the positioning of this 41 and 1 are always exacty identical, meaning they do appear in the same exact position too in the received message?

cattledog

Quote
the next is an integer for the minute when the TX took place, the next integer is the second when the TX took place
I think that these time values can be either one or two digits, and the character array length can vary. You may want to sent the values with a leading 0 so they are always 2 digits, or else determine the actual length of what is received.

I think you will now be back go the situation where you have the rare crashes. I'm sure we can figure out what is going on, now that the walk in the swamp due to my incorrect debug suggestion is over.

brice3010

I think that these time values can be either one or two digits, and the character array length can vary. You may want to sent the values with a leading 0 so they are always 2 digits, or else determine the actual length of what is received.
You might very well have hit the nail on its ugly head!

I think you will now be back go the situation where you have the rare crashes. I'm sure we can figure out what is going on, now that the walk in the swamp due to my incorrect debug suggestion is over.

cattledog

#57
Jan 18, 2019, 09:16 pm Last Edit: Jan 18, 2019, 09:18 pm by cattledog
Quote
In message x+1 in the second float there suddenly appears a < within this number.
Are you certain that with your accelerated testing you are not sending a message before the previous one is processed? You may be getting two message strings mixed together.

brice3010

Are you certain that with your accelerated testing you are sending a message before the previous one is processed? You may be getting two message strings mixed together.
Yes, I can clearly see on the monitor the progress of the RX and parsing, and the timing between the 3 transmitters is exactly 5 seconds (the RTC's are calibrated down to the second).

brice3010

#59
Jan 18, 2019, 09:24 pm Last Edit: Jan 18, 2019, 09:25 pm by brice3010
I think that these time values can be either one or two digits, and the character array length can vary. You may want to sent the values with a leading 0 so they are always 2 digits, or else determine the actual length of what is received.

I think you will now be back go the situation where you have the rare crashes. I'm sure we can figure out what is going on, now that the walk in the swamp due to my incorrect debug suggestion is over.
The strange thing is that message x+1 indeed shows up on a transition from second 57 to second 2, but in previous messages this transition did occur already and then no issue showed up with this.

Go Up