I performed two tests, first sending the data as a string and the second as binary data. Both produced the same result.
This tends to confirm that the Carriage Returns are not being lost in transmission.
de Laurie, VK3AMA2016-05-27 17:22:11.8354 INFO: TCPManagement: Incoming QSO from TCP Connection (ADD)
2016-05-27 17:22:11.8584 INFO: #=qOmwHU$0t9BdIB_$u51haOokYXiNjo59IUqVlyVgvuA0=: Incoming TCP QSO <CALL:6>VK3AMA<DXCC:3>150<COUNTRY:9>Australia<QSO_DATE:8>20160527<QSO_DATE_OFF:8>20160527<TIME_ON:6>072100<TIME_OFF:6>072200<FREQ:9>144.49029<FREQ_RX:9>144.49029<BAND:2>2m<BAND_RX:2>2m<MODE:3>JT9<GRIDSQUARE:4>IO82<DISTANCE:5>17074<LAT:11>N052 30.000<LON:11>W003 00.000<COMMENT:3>JT9<QSLMSG:3>JT9<NAME:14>Laurie Cowcher<QTH:14>Chirnside Park<ADDRESS:28>Sent As String
Line2
Line3<CQZ:2>30<ITUZ:2>59<PFX:3>VK3<CONT:2>OC<MY_GRIDSQUARE:6>QF22pf<MY_CQ_ZONE:2>30<MY_ITU_ZONE:2>59<STATION_CALLSIGN:5>VK3TC<QSO_COMPLETE:1>Y <EOR>
2016-05-27 17:23:10.5247 INFO: TCPManagement: Incoming QSO from TCP Connection (ADD)
2016-05-27 17:23:10.5297 INFO: #=qOmwHU$0t9BdIB_$u51haOokYXiNjo59IUqVlyVgvuA0=: Incoming TCP QSO <CALL:6>VK3AMA<DXCC:3>150<COUNTRY:9>Australia<QSO_DATE:8>20160527<QSO_DATE_OFF:8>20160527<TIME_ON:6>072300<TIME_OFF:6>072300<FREQ:9>144.49029<FREQ_RX:9>144.49029<BAND:2>2m<BAND_RX:2>2m<MODE:3>JT9<GRIDSQUARE:4>IO82<DISTANCE:5>17074<LAT:11>N052 30.000<LON:11>W003 00.000<COMMENT:3>JT9<QSLMSG:3>JT9<NAME:14>Laurie Cowcher<QTH:14>Chirnside Park<ADDRESS:28>Sent As Binary
Line2
Line3<CQZ:2>30<ITUZ:2>59<PFX:3>VK3<CONT:2>OC<MY_GRIDSQUARE:6>QF22pf<MY_CQ_ZONE:2>30<MY_ITU_ZONE:2>59<STATION_CALLSIGN:5>VK3TC<QSO_COMPLETE:1>Y <EOR>