Hi all. When you create a new session, the last option is "Save NMEA data". This creates a .txt file full of NMEA sentences. I've been trying to read up on NMEA, but want to know how to use this data. For example is there apps that I can load the NMEA sentences into?
Next version of RaceChrono will have a KML (Google Maps and Earth) export of it's own, which will be very cool :-)
I would also make some proposals, as user in rally races.
IÂ´m the co-driver and so IÂ´m trying to do some kind of telemetry with the nmea sentences the software gives. IÂ´ve a MTK-based GPS (konet) and IÂ´m trying to use it in the PC for post-rally analysis, but IÂ´ve found, when converted to CSV, that those files asnÂ´t the speed in all the sentence, so when I try to convert it in speed-as-altitude with GEtrax it makes "strange things" (I think this kind of post-processing would be very fine)
It would be very useful to make a "clock" start, as I can make an automatic start of the logging, because we always know the exact hour at wich we start a stage, and ItÂ´s more precise than the speed start.
Few questions about the rally start feature, and how you use the software. Do you have one session per special stage (also one track profile per SS)? And resume same session, if you drive it twice or more in same rally? And do you have predefined traps for the special stages, defined in practice?
So the "Rally start" feature would ask you a start time, and then counting down the time from negative side. It would use GPS time fixed with the handphone time zone setting. How well is the rally start clock syncronized to "real time" ? I mean if it's second off this would not be accurate. GPS time on the other hand is VERY accurate.
Also about CVS. I'm currently thinking about how to improve the CVS, and also adding one or two other formats. I'll look in this.
The sycncronization i think must be done before starting, as we synch our clocks with the "rally time" a little bit before we start the rally. Maybe it could be easy to make a "3,2 or 1 minute left"(so you have time enought for put on the belts) button son it starts automatically when the "rally time arrives" to 0 seconds in that minute(the stages always start at 00seconds, because its easier for us to calculate stage times).
You also know the lenght of the stage, so you can say more or less when it have to stop (you give 100-200meter more for error)
This is the first time I use the software, so IÂ´ve used one session per SS. I dont have track of the stage simply because I received my GPS a week before the rally, and we saw the SS one month ago.
I promise you IÂ´ll think in the "perfect" software I would like for rally use, so you can use any of the ideas for improving your fantastic software!
First was the manage of "rally time". As you say GPS time is much more precise than mobile time, so it could be easy to make a "rally time clock" based on GPS (mobile when GPS is disconnected) because it could be as easy as determinate the difference between "GPS time" and "Rally time" and make a clock that shows on screen the "Rally time" as(GPS time + That Difference), and it would be more precise that the actual two clocks I use when rallying!
If you make a chronometer that starts just at the time I configure it, it could be great for chrono the SS! . As I say I can configure SS start time that starts the chrono and the logging, and the stop for both could be done with a position in the track previously grabbed in the training (I would prefer a margin for the log, so it stops one or two seconds after the SS finishes, for being sure I grab al the SS (sometimes they change a little bit the star-stop places).
-The next thing is the most difficult, and I don't think it must be done in the mobile software but in a post-processing one. I think it can be a "too big" project, but this is just a idea.
IÂ´m thinking the most precise way to describe a car/moto trajectory (sorry if I become technical, I canÂ´t stop being engineer ;)). I think that this "ideal" post-procesing software must do some kind of "spline" that draws the exact trajectory of the vehicle, using the GPS data, but with some corrections. You can give the GPS points some kind of "credibility value" based on overall data.
When you see a GPS generated track you can disguise GPS erroneous points easily, just because a big gap in the line or things like this, and what IÂ´m thinking is in doing this but based on pure physics.
We have a lot of data for knowing if a GPS point could be wrong or not. For example, you know that the longitudinal acceleration canÂ´t be more than actual tyre grip can give you(around 1g) and if you refine this you can know even more:
|maximum theoretical acceleration = Engine_Power / (vehicle_mass * speed)|, deceleration its just a brake question, and that 1g limit could be realistic enough.
If a point don't match this requirements ItÂ´s not much reliable, and itÂ´s "credibility value" must be slow down.
Laterally you can do the same, as you trace a spline thought the points you can know the exact radius of curvature on each point, and as you know the speed you can calculate lateral accelerations: "lateral_acceleration_in_a_point" = (speed_in_that_point)^2/ (radius_in_that_point ) . Maximum lateral acceleration must be around 1g also, in cars without aero downforce.
The last refinement (that would make a software really "pro") is the combination between those two data, longitudinal and lateral GÂ´s, as we can combine them based on the friction circle (http://www.geocities.com/prohibition_us/friction.html) that basically says that you cant have 1g lateral acceleration and 1g longitudinal acceleration, and that you must combine both for knowing if you are sliding or not, or if this data is real or fake.
Well, i konw this much more easy to say than to do, but as I say itÂ´s just an idea of the "ideal postprocessing software"
Finally IÂ´ve to say that if you want a Spanish translation of the software IÂ´ll do it for you! :)
Sorry for the length!!
I was thinking the Rally mode could work in same way the Laptiming mode is working currently. Just small modifications but similar concepts:
1) Recording of the session would start at the pits. So all data would be logged even before the start
2) It would be possible to record many SS for same session
3) One track profile could be used for whole rally. It would contain the finish line (and splits) for each SS
4) Start time could be set for next SS, at any stage of the session. You could enter all start times at once, or separately add them, or modify them.
5) SS would start on entered time. SS would end when any of the finish lines is crossed. Start time could be adjusted afterwards, as well as the finish line could be moved.
6) Completed special stages would be shown in a list of SS times. Each individual SS could be opened for closer inspection, and only the data regarding this SS would be shown (so the extra data does not hurt).
7) Each SS could be exported separately
8) Session could be paused and resumed afterwards.
Are there any adjustments or corrections needed?
On the other side iÂ´m working in a excel table for all the theory I gave you.
It's a little bit tricky as I don't know how to make a 3D spline in excel for calculate the curvature on each point, but I'm trying .