Hi Matt
This is my 2nd query related to importing track data.
If I import this CSV file:
Latitude, Longitude, Depth(m), E1, E2, PeakSV
-34.79970868, 20.05790053, 1.8, 55.279, 35.823, 202.688
-34.79970868, 20.05790955, 1.8, 59.199, 37.668, 205.156
-34.79970128, 20.05790955, 1.8, 67.327, 36.885, 209.698
-34.79969388, 20.05791856, 1.81, 68.826, 33.231, 211.644
-34.79969388, 20.05792758, 1.86, 66.075, 35.705, 210.592
-34.79968648, 20.05792758, 1.86, 64.92, 35.613, 209.188
-34.79968648, 20.05793659, 1.86, 78.119, 47.194, 209.464

The first track point does not change when changing bottom palette and there are only 6 track point values in the return strength window.
Also there are only PeakSV bottom values and no E1 or E2 returns. See TrackView_CSV.jpg.

If I now export this track to a CSV file:
Latitude, Longitude, Depth(m), E1, E2, PeakSV
-34.79970868, 20.05790053, 1.8, -1, -1, -1
-34.79970868, 20.05790955, 1.8, -1, -1, 55.279
-34.79970128, 20.05790955, 1.8, -1, -1, 59.199
-34.79969388, 20.05791856, 1.81, -1, -1, 67.327
-34.79969388, 20.05792758, 1.86, -1, -1, 68.826
-34.79968648, 20.05792758, 1.86, -1, -1, 66.075
-34.79968648, 20.05793659, 1.86, -1, -1, 64.92

The E1 values are in the PeakSV column and shifted down by one row relative to the Lat/Lon/Depth values.
Again – am I doing something wrong?

Thanks for this post. The offset hardness values issue is a bug. It probably has minimal impact in practice because od the proximity of points, and because adjacent hardness values are averaged together in any case, but it shouldn't happen.
The import of PeakSV only is by design. The is really for historical reasons, and porting of DrDepth hardness values which we considered closest to our peak signal value layer. I'm not sure how useful it would be in practice to export/import all layers but it is something we could look at if people want it.