Data Importing into DashWare - Change of Hour Time Issue

Help on issues you run into with LapTimer; in case you have a question on how to use LapTimer, use the forum "Using LapTimer" instead
Post Reply
ckowalc
20 or more Posts ★★★
20 or more Posts ★★★
Posts: 81
Joined: Thu May 14, 2015 7:33 pm

Data Importing into DashWare - Change of Hour Time Issue

Post by ckowalc »

I've noticed when I input the CSV data from HLT into DashWare if it is from a session in which the hour changed, for example a session from 9:50-10:10, Dashware will not import it. The issue is with the "TIME" column (column D in the GPS CSV). It displays the TIME as "MM:SS.0" format so I am assuming that DashWare thinks you go back in time when you go from 59:59.9 to 0:00.0. Since this issue is across DashWare and HLT, I was trying to figure out who should change their software and my thought is that they way HLT displays the time does not really make sense since if you convert it to "HH:MM:SS" it will display 12:XX:XX AM no matter what the hour is.

The frustrating part is DashWare does not tell you there is an error. It just has a greyed out bar on the Synchronization page so you can't "seek" through the data and sync with the video. So there have probably been a number of people that have struggled through this issue and if it was their first attempt at overlaying in DashWare probably didn't think ti worked at all.

I have been editing the data to change the start of the data from 50:00.0 to 0:00.0 for example and then apply it to the rest of the cells in that column so that the session ends before I hit 59:59.9 (none of my sessions are over an hour so far). However, in my latest session this did not work for some reason. I'll see if I can troubleshoot it and will post back if I can fix it.

Harry, who do you think the problem lies with (HLT or DashWare)? I have not tried contacting DashWare at this point.

I have also attached the CSV of the session I am having an issue with. EDIT: Had to trim it because max file size is 256 kb

Here is a screeshot of a session that had this issue:
Image

And what DashWare shows in the Sync tab (notice no GPS track outline, greyed out seek bar and no option to Sync to Video in bottom left):
Image
Attachments
LapTimerGPSRecDB_31Oct2015_S4_Trimmed.csv
GPS CSV with Time issue
(186.93 KiB) Downloaded 267 times
User avatar
Harry
Site Admin
Site Admin
Posts: 10642
Joined: Sun Sep 12, 2010 10:32 am
Location: Siegum, Germany
Contact:

Re: Data Importing into DashWare - Change of Hour Time Issue

Post by Harry »

Please check if the TIME column is changed somewhere in your processing chain. LapTimer always adds hours, minutes, seconds and hundreds to the TIME column. I assume some processing step you performed skipped the hour part?
Untitled.png
Untitled.png (200.54 KiB) Viewed 3749 times
- Harry
Image Image Image Image
ckowalc
20 or more Posts ★★★
20 or more Posts ★★★
Posts: 81
Joined: Thu May 14, 2015 7:33 pm

Re: Data Importing into DashWare - Change of Hour Time Issue

Post by ckowalc »

So, I exported a .hlptrl file from Android and imported the laps onto my iOS then exported the CSV data from iOS. Now it looks like the times are in GMT time zone so I take back what I said about it always being 12:XX:XX AM format. For some reason last time I exported from my Android it gave me everything in 12:XX:XX AM. I'll try exporting from my Android again and see if it still does the same thing again.

Anyway, after getting the time in GMT time zone it still displays as MM:SS.0 format. I have not done any processing. I'm not sure if it matters to excel what format is displayed to DashWare since I believe the time is really just a number in excel (divided by 86400). Again I have attached my iOS imported data, I have just trimmed the other laps out.

DashWare still will not use the CSV file though. It does display the track outline and the Sync to Video but the seek bar is greyed out. I'm positive it is an issue the hour changing because I've had this issue 3-4 times and it's always in a session that the hour changes.

Sounds like it maybe a DashWare issue after all, correct? Anything you know to try Harry?

Dashware with iOS exported CSV (greyed out seek bar)
Image

iOS exported CSV in Excel
Image
Attachments
LapTimerGPSRecDB_31Oct2015_S4_reexported_trimmed.csv
iOS exported CSV data
(234.93 KiB) Downloaded 280 times
User avatar
Harry
Site Admin
Site Admin
Posts: 10642
Joined: Sun Sep 12, 2010 10:32 am
Location: Siegum, Germany
Contact:

Re: Data Importing into DashWare - Change of Hour Time Issue

Post by Harry »

No, it is a problem with conversion. Check the original file exported from LapTimer (not a trimmed and re-exported version) using a plain text editor (Notepad for Windows or TextEdit for MacOSX). In case you want to view data in Excel, you need to set the import format for the TIME column to text (at least that is what I assume). Usually it is not necessary to convert formats and Dashware can work on LapTimer's CSV directly. You will probably need to adjust Dw's import mapping, but that's it.

- Harry
Image Image Image Image
ckowalc
20 or more Posts ★★★
20 or more Posts ★★★
Posts: 81
Joined: Thu May 14, 2015 7:33 pm

Re: Data Importing into DashWare - Change of Hour Time Issue

Post by ckowalc »

You were right Harry it looks like whenever I opened the exported CSV file to rename it and save it it automatically converts the time column to the MM:SS.0 format. I verified this by opening the exported CSV in Notepad in whicg everything looks good. Then opened the same file in excel, renamed and saved the file. Then opened the now renamed file in Excel and the time format was wrong. It seems like it is only an issue when the session changes hour.

What I was doing was exporting the entire day's lap data then opening that CSV and trimming the data into sessions by removing the rows of data from all other sessions. I now know I need to export each session individually and not open and save in Excel.

You would think there is a way to get Excel to open the time data in the correct format without using 'import text' settings but I'm not sure.

Thanks Harry.
Post Reply