Hi all,
I am currently working on a project in which I receive data in hex. The data consists of 32 bytes. The data also consists of few delimiter of "0x16".
So what I want to do is, everytime when my Arduino is reading the data, when it sees the value of "0x16" it should just ignore it.
How can I proceed to do this ?
Post your code for reading the data.
It could be like:
read a character
if character not equal to 0x16
save the character
else
skip to next read a character
Darvesh_7:
Hi all,I am currently working on a project in which I receive data in hex. The data consists of 32 bytes. The data also consists of few delimiter of "0x16".
So what I want to do is, everytime when my Arduino is reading the data, when it sees the value of "0x16" it should just ignore it.
How can I proceed to do this ?
Very interesting. As I recall the 0x16 is an ASCII sync character. We used it in synchronous data communications to sync modems to the data stream. I wonder what machine is generating such messages?
Paul
Hi Paul,
I am receiving data from a PIC18F66K90 - Microcontroller. Yes you are right , the data will need to be send via a GSM/modem to a Server.
So from PIC18F66K90 to Arduino Mega via Hardware Serial to GSM to IoT Server.
Darvesh_7:
Hi Paul,I am receiving data from a PIC18F66K90 - Microcontroller. Yes you are right , the data will need to be send via a GSM/modem to a Server.
So from PIC18F66K90 to Arduino Mega via Hardware Serial to GSM to IoT Server.
A sample of an actual message would be helpful. IF your message DOES NOT end with some kind of block check code or other CRCC code, then yes, bypass the 0x16 characters in the message.
If the 0x16 is part of a CRCC then it must be part of the checking process, if you need to do that.
Paul
Hi Paul,
The attached image represent what I am receiving. The data is obtained in hex, however in the attached image I represented it in both hex and decimal. The start transmission is: 0x02, the end of transmission is 0x03, the delimiter is 0x10(hex) or '16' in decimal.
The data obtained was when only one device is transmitting, as more devices are transmitting the data will obviously increase.
Look at this chart: ASCII Chart and see what some of the HEX characters represent as message control characters. The program generating the messages must be REALLY old.
I haven't seen message like that since 1990 or so.
In any case, you can skip the 0x16, sync characters. They are automatically inserted by the sending device USART chip when a new byte to send is not available before the last bit of the previous character is sent. They are "filler characters".
Paul
The data is obtained in hex,
Can you please be clear as to exactly what you are receiving when you say that it is in hex ?
Take a value like '180'
What byte or bytes do you receive ?
My subconscious mind just alerted me to the fact that synchronous ASCII data has NO start bit nor stop bits. All the 8 bits are jammed up against one another in the entire message.
What exactly are you using to receive and display the message data you showed? IF it is received with start/stop bits, then someone failed to correctly program the USART in the PIC machine.
Paul
Hi Paul,
I was able to sort it out. I basically created a state machine.
Darvesh_7:
Hi Paul,I was able to sort it out. I basically created a state machine.
Glad to see that! I learned long ago if a program works correctly, leave it alone and go on to something else.
Paul
