Different Data on Serieal Port.

[i_build_stuff]

You seem to have about the right idea. For the voltage / current above, it could be as simple as sending 0x1B, 0x03 (these are the two bytes for 27 and 3). Let the PC do the conversion into ascii codes to actually display the text (since all high level languages give you this anyway). If you need it to be fault tolerant, or have more features, then I'd take it one step further and go with packets:

<packet start code><packet type code><data length><data><error correction code>

The above is just an example of what you could do; your encoding will vary based on the application (ie, some fields might not be there).

 

[Nigel Goodwin]

You seem to have about the right idea. For the voltage / current above, it could be as simple as sending 0x1B, 0x03 (these are the two bytes for 27 and 3).

As I'm sure you are aware?, but just wrote it badly - they are simply the hexadecimal versions of the decimal numbers.

You seem to be missing the point though, which was how to accurately determine which byte is which - when you might miss the beginning of a byte, or get data corruption.

The answer I suggested was to convert to ASCII and send the data as ASCII, prefixing each section with a suitable letter - this allows the receiving program to easily identify which is which, and it's trivial to spilt and convert them.

Sending the data from a PIC (or other) in this fashion is also trivial to do, and by ending it with LF/CR you can easily read it directly into text documents, databases, and spreadsheets.

It also avoids any complications with the PC deciding particular values may be control codes.

Let the PC do the conversion into ascii codes to actually display the text (since all high level languages give you this anyway).

It's dead easy in ANY language, including assembler.

 

[ericgibbs]

hi,
I would advise you,as my previous posting, [ as nigel also recommends], keep to ascii for your serial data transmission. If you use hex/bin, trying to find a problem can drive you crazy. 'Is it the PIC or is it the 'high level' software'

If you use ascii, you can send your serial data into a simple terminal program, like Procomm etc,, and see instantly see your output data in plain text.

Further to my earlier post, you should also consider what you are going to output in the event of a failure of a corrupted sensor input to the PIC.
Example: say a bit line fails on a input switch and it converts say to a value
greater than '9'. I would suggest that you discuss this with the end user.

In my radio telemetry systems, where a received digit becomes corrupted, the serial output becomes 'V ??.??<crlf> .
The PC program is written to recognise this pattern.
If you decide to output 'V 00.00<crlf>' for a corrupt parameter, this could
be misinterpreted a actual value and the wrong action taken.

Regards
EricG

From a previous post it was suggested that you 'string' output your parameters then a <crlf>, a possible problem with this method, is based upon the update rate of the individual parameters in the string.
example: suppose you are sampling a voltage once every second and say temperature every 10 seconds, it would mean sending
the same temperature parameter 10 times, assuming a fixed length data string is being transmitted.
I appreciate that the program in the receiving PC could do a parameter 'ID' locate for each parameter in a variable length string.
Personally I would prefix each data parameter with its own ID character and terminate each parameter with a crlf.