Sending Hex value with RS232

[Rotac]

Hi,

I want to send (RS232) the next Data, Hex = 02 07 01 0F 00 23 AC, the same in Decimal = 002 007 001 000 035 172.

When I make a string then as Send "02 07 01 0F 00 23 AC" , I get complete different value, 20 value of the Decimal value of the Ascii value starting with "048" (Monitoring on PC in Decimal Mode (Hex is not possible)

When I send the ascii codes for eg. "02" Send = "<STX> then I will get the 5 Decimal values of these characters.

Then I tried it not with a string, but witch RS232(Char), the the values will be added!

Has some one experimense with this issue, I have seen one item on the forem here: http://www.matrixtsl.com/mmforums/viewt ... ers#p57689

but this give no solution for my situation.

How can I solve this problem?

Regards

Rob

[Brendan]

Hi Rob.

I do lots of stuff over RS232, though I'm not sure I understand your question.

To clarify, I trust you're declaring hexadecimal appropriately (0x..) ?

Fundamentally, the question is largely how you intend to process or view the data at the receiving end. For example, if I were using a program to interpret successive byte values alone (i.e. not as text) then it is possible to simply send any ASCII character bytes within the acceptable range (i.e. avoiding 255, interpreted as no more characters in the receive buffer). Doing so however will not always be readable in a console application (e.g. HyperTerminal, PuTTY, etc) if your transmissions include 'whitespace' codes such as SOH, ETX, etc.

Should you try to send a 'string' of "02 07 01" for example, you will actually transmit successive ASCII character bytes representing... 0 2 space 0 7 space 0 1, or in other words...
0x30 0x32 0x20 0x30 0x37 0x20 0x30 0x31. If you actually wanted to send three bytes of 0x02 0x07 0x01 then you could first compile the values into a string and send the 'string' variable to entirely satisfy the Flowcode component macro, by...

StringToSend[0] = 0x02
StringToSend[1] = 0x07
StringToSend[2] = 0x01

...repeating concatenation for the entire string, then send 'StringToSend'

The result will be the intended string of bytes, as it was processed and sent as such.

I would strongly suggest sending ordinary test character codes to a terminal application to first debug that nothing 'quirky' is happening with the link or string processing before sending. After all's said and done however, all that you're doing is sending a string of successive byte values that RS232 serial itself doesn't 'care' one jot about.

However, sending via serial can certainly invite other issues if the sending and receiving parameters don't agree (e.g. flow control, parity, etc).
Also, do ensure that you start off at (say) 9600 kbps to eliminate bit-timing issues - a particularly important consideration if using the PIC's internal RC oscillator that can exhibit significant timing offsets and phase noise, potentially corrupting transmissions with faster data and increasingly-critical bit timing accuracy.


All the best,

Brendan

[Rotac]

Hi Brendan,

Thanks for your answer. I tried this already to put each Hex value in an Byte (as your example) only during sending all values came with "a carriage return" instead in a horizontal row.

The way what you suggest to put StringToSend[0] = 0x02, StringToSend[1] = 0x07, StringToSend[2] = 0x01 together in 'StringToSend' gives a problem while the first three are "Byte" and the last a string, but after some trying I have now solved the problem, I get the "string" 002 007 001 015 000 035 172 (this is a"decimal read out). I used herefore "232 Analyzer, free version" in this version is reading Hex values blocked.

So now the string is exactly the same what the original (PC program) generated and what I made with the Microcontroller, but somehow the receiver (which listed to the string) doesn't react on my microcontroller string!
(Baudrate = 38400, 8 bits, 1 stopbit, no parity), microcontroller runs at 8Mhz (internal clock). Could it be timing problem what you can't see in the read out with 232 Analyzer software? (when I do the read out with this program, in all type:
1)Dec
2)Bin
3) Ascii

the result is always the same withe the original PC program.

If you want I can upload the flow code program.

Regards


Rob

[Brendan]

Hi Rob.

Please rest assured that if a string of bytes is compiled in the way I suggested, no Carriage Returns will ever be present in the original string, or transmission if sent from the RS232 component macro as a string. What you observed will have been externally generated following the transmission of each byte.

If successive bytes are displayed in a vertical column, a carriage-return alone will only return the cursor to the beginning of the same line - overwriting the last value as each new value is displayed. It is the Line Feed character that moves the cursor to the new line, so if successive bytes are displayed vertically for example, then 'both' Carriage Return and Line Feed will have been generated externally following Flowcode transmissions of each successive byte.

Definitely reduce your baud rate and try again. Flow control can help, but don't unnecessarily push speed when you don't have to - particularly when debugging. I have seen issues like this many times over, so not worth speculating over data issues any further until the simplest and perhaps most likely causes of failure have first been eliminated, and reducing the baud rate to the suggested 9600 kbps is the simplest thing to do. Then, only when you've established that data is reliably being sent and received and you're satisfied with your program routines, should you then try increasing data speed - and only then if really necessary. There's little point increasing the potential for reception errors if you don't have to

EDIT: Just so I understand your requirements correctly, please confirm whether the receiving program must see each byte as a four-character 'string' with hexadecimal notation, for example "0xF5", a two-character hexadecimal value 'string' without the notational prefix ("F5"), or a decimal byte value represented by single character value (245). I interpreted your message as the latter.

If sent as strings, how does the receiving program expect each value to be delimited?


All the best,

Brendan

[Rotac]

Hello Brendan,

At the end I find the problem, I read out the data with a PC connected on RS232 board J1 and change it each time with the "Hex receiver", I thought let use a nulmodem adapter and it's now working!
When I connect the "hex receiver" it works without a nulmodem adapter, because 2 <=> 3 are swapped.

So it's solved

Regards

Rob

[Brendan]

Excellent news.

Thank you for the confirmation, and I've no doubt your discoveries will be of future assistance

All the best,
Brendan