From RS232 Serial Cominication

From this fig. how i can define the serial frame to get the data through RS232

i try to use this 0x16 0x16 0x01 0xFF 0xA4, 0x5C but i didn't get any reply

IMG_3180.jpg
 
It's impossible to help given the limited information you've shared. How is the CRC calculated? Does the device use hardware handshaking signals? What are you using to communicate to it PC software? What communication settings (baud rate, data bits, parity, stop bits) are you using?

Can you provide a link or PDF of the manual for this controller?
 
It's impossible to help given the limited information you've shared. How is the CRC calculated? Does the device use hardware handshaking signals? What are you using to communicate to it PC software? What communication settings (baud rate, data bits, parity, stop bits) are you using?

Can you provide a link or PDF of the manual for this controller?
Thank you for your replay

i use PC software(access port ) to comunicate and device isn't handshake

for the protocol format
- baud rate 19200, half duplex
- data format 8bit 1 stop bit and no parity

IMG_3202.jpg

and i ever tried this frame protocol 55 55 01 D0 01 00 F0 i got the S/N of device but this one someone give me but seems is not same as the user manual that i got (for the PDF file i don't have it only hard copy that i have)

for how to calculate is follow this

IMG_3201.jpg
 
I calculated the CRC on the bytes 0x16 0x16 0x01 0xFF and got 0x5CA4, therefore, I think your entire packet should be 0x16 0x16 0x01 0xFF 0x5C 0xA4. I believe you may have had the CRC bytes reversed. Also, please make sure that the PC software you're using is configured to send hexadecimal bytes and not ASCII characters.

Another potential issue is that the documentation you show is not clear on what bytes in the packet should actually be used in calculating the CRC. The CRC Calculation page says it's calculated on the command no#, subcommand no#, and data part of the telegram, but the packet format from your first post has SYNC, Message type, and Data for the fields (no command no# or subcommand no#), so it's unclear whether or not the SYNC and/or the Message type fields should be included in the CRC calculation.

Does the manual you have give any full packet examples that we could use to verify correct CRC calculation?
 
I also got the CRC same as your calculated

from the document only say only that I post on this and the subcomand it only 4 part such as echo(00H),software(01H), hardware(11H) and change command(13H) for package it’s only sync, sync, msg type,data ignored by controller,crc h,crc l

and about the full package they didn’t show on documents but I use this package0x55 0x55 0x01 0xD0 0x01 0x00 0xF0 I got response back. This package didn’t show on documents but I got from another one

thank you for helping
 
OK, so you are able to get a successful response from device when sending 0x55 0x55 0x01 0xD0 0x01 0x00 0xF0. What do each of the bytes mean in this packet? It doesn't seem to use the same CRC, as calculating the CRC on 0x55 0x55 0x01 0xD0 0x01 gives 0x00D0, not 0x00F0. Does the device respond if you send 0x55 0x55 0x01 0xD0 0x01 0x00 0xD0? Perhaps it ignores the CRC.

Are you sure the users manual you're referencing actually applies to the device you have? Could there be another manual available based on the model number and/or firmware version installed on your device?
 
OK, so you are able to get a successful response from device when sending 0x55 0x55 0x01 0xD0 0x01 0x00 0xF0. What do each of the bytes mean in this packet? It doesn't seem to use the same CRC, as calculating the CRC on 0x55 0x55 0x01 0xD0 0x01 gives 0x00D0, not 0x00F0. Does the device respond if you send 0x55 0x55 0x01 0xD0 0x01 0x00 0xD0? Perhaps it ignores the CRC.

Are you sure the users manual you're referencing actually applies to the device you have? Could there be another manual available based on the model number and/or firmware version installed on your device?
If I send 0x55 0x55 0x01 0xD0 0x01 0x00 0xD0 it’s no response

for the user manual it’s only one that I have and this package0x55 0x55 0x01 0xD0 0x01 0x00 0xD0 unavailable on user manual
 
I use this package0x55 0x55 0x01 0xD0 0x01 0x00 0xF0 I got response back. This package didn’t show on documents but I got from another one
What is the other document that you reference here that has the 0x55 0x55 0x01 0xD0 0x01 0x00 0xF0 packet that works with your equipment?

Can you provide the manufacturer and model of the controller?
 
it's not document . it's only screenshot from software (access port)

for the manufactor i'm not sure but i'm doing about this STARCOOL Container stuff

and i want to know what if i download log file from the original software that provide by company (maybe inside have some binary package) is that possible to get the data package
 
It is difficult to say what's going wrong here. Only a lot of experimenting could help to find out what's wrong (there could be multiple issues at the same time):
1) The RS232 cabling setup (RX, TX, control signals) at both sides
2) Bitrate, parity bit, # of stop bits, delay between characters
3) Software that makes the PDU content, is it according to spec. I always like to have an example of a complete PDU including the right CRC. Issues often seen are the initial value, exactly which bytes need to be used in the calculation, and the MSB/LSB sequence of the calculated CRC,
4) OS that may not send the PDU out even though it says it did
5) The receiver: is it configured correctly, can you see whether it thinks it has gotten something, but then perhaps thrown it away due to some issue (ie wrong CRC?).
6) Did the answer get out, and is it received back?
 
Top