current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
stack overflow careers
Sign up ×
Stack Overflow is a community of 4.7 million programmers, just like you, helping each other. Join them, it only takes a minute:
up vote 0 down vote favorite
1

The situation is that at my place of work, we have a call data recorder (CDR) feeding data into a server through a serial port. As I understand it, the good data from this is a record of all the calls made, which is of course bound up in the expenditure of money.

As I understand it, the serial port on the server was set to accept data in terms of 9600 baud, 8-bit, no-parity, with 1 stop bit; it was intended to be set to accept data in terms of 9600 baud, 7-bit, no-parity, with 1 stop bit.

Although that setting has been corrected now, there is a large amount of data from the CDR which is currently unintelligible, though the files would normally be readable in something as simple as Notepad.

My question is A. Whether it's even possible to recover readable data, and B. How I could accomplish this (in terms of C# would be ideal, but not necessary). I had had thoughts of decoding the data straight down to the bits and re-encoding into a readable format, but I have come to realize that I'm not certain of the actual formats involved (for example, my limited research has led me to believe that the 7-bit, no-parity, 1 stop bit, data would be considered "true ASCII", but I'm not certain of the validity of that).

Many of the previously asked questions deal with serial port handling in code. I suppose I'd like to know if I can translate this received data into a readable format.

share|improve this question
    
Ascii is 7 bits, 128 characters. Extended Ascii is 8 bits, 256 characters. Would it be possible to post some of the data? You might have success in decoding if you look at the bits and see if there is a pattern in how they were received. – dbasnett Jun 13 '13 at 13:57
    
I agree with @dbasnett, it would helpful to see an example of the data stream. – jerry Jun 13 '13 at 19:38
    
This is a short bit of what is in one of the files, with the incorrect serial port settings: 130506 102615€ÿŠÎ °±¶ °° ¶¶²¹ Ô°±¶€°²³ °µ¯°¶ ±°º²µ °°º°°ºµ² Á µµ±³±´³´°³°·°Š ¦ ‌​ °°°° °°°° ŠÎ °±· °° ¶²°° Ô°°°€°¸¸ °µ¯‌​°¶ ±°º²· °°º°°º°² Á µ±´±³¹¶´¹Š ¦ °°°° °°°° ‌​ ŠÎ °±¸ °° ¶´¸° Ô°°°€°¹± °µ¯°¶ ±°º²³ °°º°³º²° Á µ±´²¸¹²µµŠ ¦ °°°°‌​ °°°° ŠÎ °±¹ °° ¶´²µ Ô°°°€°¹² °µ¯°¶ ±°‌​º²¶ °°º°°º´¸ Á µ±±¸¶¶²±¶°°¹±Š ¦ °°°° °°°° – Miles Grimes Jun 13 '13 at 20:16
    
Do you have a hex viewer/editor you can open it with and paste the data from? Pasting it as text may cause issues. By the way, you can edit your question to add new information, this is preferable to putting it in a comment. Also, any additional information you can give would be useful? What do you expect it to look like? How many bytes is the file? Can you estimate how big you'd expect it to be based on how long the port was open? – jerry Jun 14 '13 at 19:18

1 Answer 1

up vote 1 down vote

I don't think there is a way to restore the data: The UART on the server will probably have detected a lot of 'frame errors' and as a result has discarded at least some of the data at the hardware level already.

However, you may want to have a look at the frame format on the serial line (e.g. here). It is not complicated in any way, but w.r.t. your problem the challenge I see is:

Each frame consists of one start-bit, then the n data-bits, optionally a parity bit, and then one or more stop-bits.

So, when the UART expects 8-bit frames and there's only a single stop-bit sent after each frame it will get out of sync:

  1. The start-bit is detected by the UART irrespective of the frame length, then
  2. the UART reads as many data bits as it is configured to, 8 in your case, while the sender only sent 7 bits.
  3. The sender terminates its frame with a stop-bit, which the receiver mis-interprets as the last data-bit of the 8-bit frame.
  4. Now the receiver expects to see a stop-bit while the sender probably just goes on transmitting by sending the next start-bit, and so on.

Since the start-bit is a logical 0 while the stop-bit is a logical 1 the UART will detect a frame error in most frames and may or may not provide the 'broken' frame's data to the application.

However, in any case, the receiver will have interpreted some bits of actual data as control-bits, i.e. start- or stop-bit, and these bits will definitely be lost afterwards.

If the sender had been configured to send at least two stop-bits per frame the received data would be easily recoverable by just trimming the 8th 'data'-bit, which actually was the first stop-bit sent and would therefore always be 1 anyway.

share|improve this answer
    
If there's at least one bit time's worth of idle between each character, there would be no framing errors. That may not be entirely likely, but it's at least a possibility to consider. – jerry Jun 13 '13 at 19:37
    
That's correct. The additional "idle" time is exactly what an extra stop bit means, i.e. when the port is configured as 8n2. However, another implication thereof is that the last frame of a transmission will not cause a framing error and may thus be recoverable. – Hanno Binder Jun 15 '13 at 20:47
    
I agree that the last frame probably won't cause an error itself, but the most common recovery strategy (discarding the data and reseting the port) likely wouldn't allow it to be cleanly received anyway. If the transmission is 7n1 and there's little or no idle time between frames, I don't think there's a good chance of recovering any meaningful amount of data. – jerry Jun 16 '13 at 13:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.