Line Feed problems

[N98JV]

I connect to a data logging device mounted in an aircraft. We have been connecting via 9 pin serial cable using a Windows laptop and Windows Hyperterm without problems.

I downloaded Get Console and purchased the proper cable. I am able to connect and download data as normal. My problem is that Line Feeds are added to the data that is not present when using the Windows laptop and Hyperterm. the line feeds are preventing the data from being imported into the data analysis software. The raw data as it is downloading looks correct, but when viewed, saved or exported from the log line feeds are added.

How can I turn off the addition of line feeds or remove them altogether?

By the way, if I import the data into Hyperterm then into the data analysis software it works OK. Looking at the raw data it appears that Hyperterm removes the excess line feeds.

Thank you.

[daniel]

I'm not sure what the issue is, Get Console shouldn't be adding any extra characters.

There are a few things you could try to get things working:
- under Settings - Keyboard Settings, try changing what the Enter Key sends
- under Settings - Advanced Settings, try changing the setting for local echo
- under Settings - Terminal Settings, turn on Console Logging to see exactly what was received on the serial cable

[N98JV]

I tried changing the settings as suggested but was not able to change the output into something that is readable by the analysis software. Even with console logging on there are line feeds being added to the logged copy.

The text on the terminal screen DOES NOT match the logged text. I have provided a picture to illustrate the problem.

Shouldn't the logged data EXACTLY match the screen data?

[daniel]

The same data received from the serial port is both written to the console log and to the terminal screen; there is no line ending conversion.

There are reasons why the data may be displayed differently on the terminal and clipboard editor:
- the main terminal screen of GetConsole is a VT100 emulator this means it interprets terminal control characters (e.g. \b might delete a character, or a control code may reposition the cursor on the screen).
- the clipboard viewer is a built-in iOS component (UITextView) which obviously doesn't support VT100 - it may interpret control characters (like CR and LF) differently (e.g. it may ignore them, or treat each as a separate CRLF, etc)

To see exactly what binary data was received on the serial port there are two methods:
- look at the console log file in the logs section of GetConsole and either email the file or upload to dropbox. You can then use a hex editor to examine the file to see what line endings were received on the serial port
- enable serial debug logging (see section 7.2, "Detailed Serial Troubleshooting" of the user manual here http://www.get-console.com/faq/ for details). The serial debug log will be written to the logs section of the app and you can see the exact hex data (including framing) that is sent/received on the Redpark cable.

Hope that helps!

[N98JV]

Thank you for your reply and information.

From your reply, I understand that there is problem between the Get-Console terminal and the iOS text viewer that cannot be easily resolved. The text viewer is likely adding line feeds that cause formatting errors in the logged data. These errors may cause problems when attempting to use logged data with other computer systems.

This problem will prevent the Get-Console Software and cable from performing the task for which they were purchased.

I suggest that you notify potential purchasers of your products of possible compatibility issues arising from the interaction of the Terminal and the iOS built in text viewer.

[daniel]

I think it would help to understand how you are transferring the data out of GetConsole and into your processing software. Without knowing that, it is unlikely we can help further.

I don't think there is any issue with the logged data; it is exactly what was presented on the serial port.

[N98JV]

Thank you for taking the time to help with this problem. Please understand that I AM NOT mad or irritated about this. I took it upon myself to try to get this to work not knowing if it would or not. The risk is entirely mine. No worries.

Up till now we have been downloading the data with a Windows Laptop using the built in Hyperterm app and have not had any problems with the extra line feeds. Therefore it seems to me that the device is transmitting the correct data to the serial port, but that the Ipad iOS is adding the extra line feeds at some point after it is received from the VT100 Terminal screen within the app.

I typically email the text file containing the data to the company that performs the data analysis. I have tried transferring from within Get-Console using log screen and selecting to send via email.

I have also tried copying the data to the device clip board and then pasting in apps such as the built in Note app as well into Good Reader which is a text viewer and then sending an email containing the text file. In each case the text contains too many line feeds.

Please bear in mind that each attempt to retrieve data from the device takes about 30 to 40 minutes due to the file size which is about 1.5 mb. The device is capable of a data transfer rate of only 9600bd. I have tried transferring numerous times using many different combinations of settings and defaults as you have suggested. In every case the file is the same with too many line feeds.

I have viewed the data from within a hex editor and it appears to me that both a CR & LF (0A0D) are sent at the same time. I think this may account for the excess lines in the text. I think the iOS is adding a LF after each CR as the data is received into the log. However I am a pilot not a computer programmer so I may have it all wrong.

I believe that if we can get this to work in an easy to use and seamless manner the engine manufacturer and data analysis company would be interested in endorsing this option for transferring data. To my knowledge there are no competing solutions for transferring data with a portable device.

[N98JV]

We tried opening the data file with Hyperterm and the excess lines are not present. Is it possible that the data from the device includes CR & LF but Hyperterm strips one or the other out? This would account for Hyperterm producing suitable text.

[daniel]

If possible, next time you are able to run the download, can you please enable the serial debug option (via the hidden button as describe in the manual above), and once complete, email both the serial debug and the console (from within GetConsole) to simon@get-console.com - we should be able to further analyse it then.

I'm wondering if you have any newline conversion happening from within Hyperterm - do you email the log file created from Hyperterm direct to the manufacturer? or do you copy/paste from the Hyperterm screen into a new file, and then email that file?

[daniel]

Sorry - out messages just crossed.

You can enable logging from within Hyperterm and check with a hex editor if the data contains CRLF or a different line ending.