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.)

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.

...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.

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:

What surprises me at first view is that1. 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.

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.

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?

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.

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 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.