Hi JT,Yep, typo. Sorry.
That's because if you are not padding the value to 3 digits e.g. 099, the length of the string will vary with the number of degrees and the length test will fail. Even without the length test, the parsing of the digits will fail since both your original MidStr and my replacement expect a fixed number of digits in a known place in the string. If QEIDEG works that way, we have to change how the received sentence is parsed.
Correct. We still need to add a timeout for missing messages to avoid it hanging up. It's on the list.
I expect that is because the HC-12 is is half-duplex. You are sending back the result of the previous sentence to the PC when the REMOTE message is sent. It won't get through until the transmission to the PC is over.
I just tried an old program with MIDSTR and it show single and double digits. I'm not sure what the difference is between MIDSTR and your method is, but I'll investigate a little to see if I pad out e,g, 099.
Yes, the REMOTE messages are sent 5/SEC, so don't wait till there's a gap. I suppose that when it comes to programming the REMOTE it could be, that it doesn't TX till RX is finished.
Thanks.
C.