SCCAForums.com

Look closely at the Solstice pic on the MaxQ site. We use both systems at the same time. Just worked out that way this last year.

Both are good. It takes some time to learn each system but they both work well.

I learned the software for DL1 first and Kevin does pretty well with the MaxQ stuff. We sometimes have "races" at the dinner after racing to see who can retrieve data the quickest.

FM
 

Did everyone notice that the MQGPS has been upgraded for 2007?

---

1999 Miata 10AE (C-stock)

I've just recently downloaded the Chart view program from the maxqdata site and have been playing around with a few of the sample files they make available.  However, the only sample autocross file they have is Kevin's and it's just one run so I haven't been able to see how the overlay feature works.  Would any of you guys that have the mqgps mind making available two of your runs?  I'm curious just how much of a difference you can see between overlayed runs when using the Qview mode that shows the tracks using  boxes and color shades. 

Also, in playing around with the software I've noticed it only takes data points about every 2 tenths of a seconds. Any issues with this on trying to comparing runs that are seperated in the tenths of a second range? 

 Thanks,

 

---

Paul Barros
2001 Z06 Corvette
Atlanta Region Solo2

By popular demand, I've just added a second datafile for comparison.  You'll find it under "Kevin Dietz" in the MaxQData Wiki.

The "attach" feature for our Wiki is now fixed, so you are welcome to post other data files there.

---

Ed Lansinger
MaxQData, LLC
Data Acquisition Systems

Regarding the 0.200 second data intervals - this is because the MQGPS sampling rate is 5 Hz, so the GPS timestamped data arrives every 200 milliseconds.  I'll let others chime in, but from a practical standpoint the 0.200 second interval is still usable for comparisons.  If you overlay two files and advance them simultaneously, you'll see where one car starts getting ahead of the other.  True, if two cars go through and are constantly within 0.100 second of each other, you won't see much difference - but that's to be expected.  In reality, often what happens is that cars gain and lose time on different areas of the course, so instantaneous differences can be more obvious even if the total time is the same.

When it's hard to tell the difference between two runs, you use other information to make good guesses about where to find time.  You can look for places where you can maybe get more max LatG or LongG, or where you can smooth out a ragged LatG or LongG trace, etc.  These sorts of things stand out in the "QView" display mode when comparing two runs.

Although the GPS sampling rate is the same, the MQ200 series can do much faster sampling on LatG and LongG (plus all the other input channels).

As an aside, the GPS timestamp is the same for all MQGPS modules everywhere, since it comes from the GPS satellites.  It's not very useful in autocrossing, but on a road course, it allows you to align two data files and know exactly where two cars were relative to one another at all times.  We've used this to determine (for example) who was likely at fault for racing incidents, or who passed whom going into Turn X.

---

Ed Lansinger
MaxQData, LLC
Data Acquisition Systems

Yes, the MQGPS has been upgraded.  The very latest GPS chipset.  Much better sensitivity, satellite tracking, and velocity tracking.  Better battery life, too.  Still 5 Hz.

We're trying to get an email (dare I say spam?) out to all customers who purchased the previous MQGPS.  We've got a special offer for current MQGPS owners to swap their old unit for a new one at a *very* attractive price.  Interested people should contact MaxQData.  Offer will end soon.  Spread the word.

---

Ed Lansinger
MaxQData, LLC
Data Acquisition Systems

How about using the latg and longg to interpolate and refine the GPS data?  Do other products do this?  Seems to be something that can be done easily on the software side of things. 

MaxQData:

Regarding the 0.200 second data intervals - this is because the MQGPS sampling rate is 5 Hz, so the GPS timestamped data arrives every 200 milliseconds.  I'll let others chime in, but from a practical standpoint the 0.200 second interval is still usable for comparisons.  If you overlay two files and advance them simultaneously, you'll see where one car starts getting ahead of the other.  True, if two cars go through and are constantly within 0.100 second of each other, you won't see much difference - but that's to be expected.  In reality, often what happens is that cars gain and lose time on different areas of the course, so instantaneous differences can be more obvious even if the total time is the same.

When it's hard to tell the difference between two runs, you use other information to make good guesses about where to find time.  You can look for places where you can maybe get more max LatG or LongG, or where you can smooth out a ragged LatG or LongG trace, etc.  These sorts of things stand out in the "QView" display mode when comparing two runs.

Although the GPS sampling rate is the same, the MQ200 series can do much faster sampling on LatG and LongG (plus all the other input channels).

As an aside, the GPS timestamp is the same for all MQGPS modules everywhere, since it comes from the GPS satellites.  It's not very useful in autocrossing, but on a road course, it allows you to align two data files and know exactly where two cars were relative to one another at all times.  We've used this to determine (for example) who was likely at fault for racing incidents, or who passed whom going into Turn X.

---

Bala Sambandam
2004 Infiniti G35 Coupe 6MT

MaxQData:

Regarding the 0.200 second data intervals - this is because the MQGPS sampling rate is 5 Hz, so the GPS timestamped data arrives every 200 milliseconds.  I'll let others chime in, but from a practical standpoint the 0.200 second interval is still usable for comparisons.  If you overlay two files and advance them simultaneously, you'll see where one car starts getting ahead of the other.  True, if two cars go through and are constantly within 0.100 second of each other, you won't see much difference - but that's to be expected.  In reality, often what happens is that cars gain and lose time on different areas of the course, so instantaneous differences can be more obvious even if the total time is the same.

When it's hard to tell the difference between two runs, you use other information to make good guesses about where to find time.  You can look for places where you can maybe get more max LatG or LongG, or where you can smooth out a ragged LatG or LongG trace, etc.  These sorts of things stand out in the "QView" display mode when comparing two runs.

As an "other", I'll chime in.  

Yes, 5 Hz is typically "good enough" to get what you need.  The issues I have seen had more to do with losing satellites during runs and other weird artifacting.  But you learn to know what to ignore.

I've been using data acq in autocross for over 20 years with one of the original G-Analysts and some software I wrote back in the DOS days.  That unit was 10 Hz which is quite a bit better sampling rate.  But the sampling rate was not the key, it was the accuracy of the data and the lack of artifacting.  That said, it was only Lat/Long G so one had to derive relative time intervals and course positions. I finally switched to MaxQ to get immediate access to real course maps with good relative times and speed traces.  Deriving them from Lat/LongG at the G-Analyst made them less useful due to the inability to compensate for the relative frame of reference of a semi-sliding car w/o a yaw sensor.

--Andy

PS: Someone asked about using hi-res Lat/LongG to supplement interpolation for low-res position...I believe DL1 does this.  But it gets tricky unless you have a yaw sensor or a 3-axis accelerometer to eliminate the frame of reference problem.

PPS: I wrote an article for GRM which should appear sometime this spring detailing how I used MaxQ to figure out some line choices after my first two runs on the West course at Nats.  Its pretty neat how much info there was to work with and how obvious it made the answer.

 

Andy's right - if you have a separate accelerometer and/or yaw rate sensor working at a faster sample rate, you can use that to fill in the gaps between the GPS samples and get more detail.  Look for that in an upcoming release of the software.  But it will only be for the MQ200, which has a three-axis accelerometer and an optional yaw rate sensor.  It's not possible to do that for the MQGPS, which is purely GPS-based.

---

Ed Lansinger
MaxQData, LLC
Data Acquisition Systems

MaxQData:

...But it will only be for the MQ200, which has a three-axis accelerometer and an optional yaw rate sensor.  It's not possible to do that for the MQGPS, which is purely GPS-based.

 

Ed,

The way I understand bluetooth, you can have connections to multiple bluetooth devices.  Couldn't you then aquire the data from both the mqgps and the bluetooth enabled mq200?  I would assume you would have to change the Flight software drivers to recieve data from multiple bluetooth devices. It would make for a nice upgrade path for those who already have the mqgps.

Taking the idea even further though... Have you ever thought of a scaled down version of the mq200 that only provides a 3 axis accelerometer but bluetooth enabled?  Something about the size of those old GTech Pro units, just bluetooth enabled such as this unit . Maybe even a bluetooth OBDII device such as this one http://www.vitalengineering.co.uk. I would certainly prefer that over the wires involved with a mq200 with the GPS/OBDII options.  It would also make it easier to transfer from car to car.
 

---

Paul Barros
2001 Z06 Corvette
Atlanta Region Solo2

Hi Paul,

Actually, the software can already handle data from multiple devices.

First, a little background...  Whether or not a given Pocket PC can handle multiple Bluetooth connections (specifically multiple outgoing COM ports/Serial Service connections) is a matter of how the Bluetooth stack was implemented.  On older Pocket PCs, you could only have one outgoing serial COM port connection at a time.  It wasn't until Windows Mobile 5.0 that having multiple simultaneous connections was supported.

Nevertheless, going back to the some of the earliest releases of our software, before Bluetooth really hit the market, we had the ability to collect data from two COM ports simultaneously.  We wanted to support scenarios like where the Pocket PC already has GPS built-in and you were connecting an MQ200/MQ175/MQ125/MQ100/MQ75 for accelerometer data, or MQ25 for OBD-II data. (As an aside, you *can* use the software on a Pocket PC that has built-in GPS, in effect getting basic MQGPS functionality without having to buy an MQGPS, but there isn't a Pocket PC on the market that has 5 Hz sampling, and 1 Hz just isn't fast enough except for, say, jogging or bicycling.)

As it stands right now, if you have an MQGPS and then you buy an MQ200 (without the GPS option), you can simply put down two different COM ports for "MQ Port" and "GPS Port" in MaxQData Setup and it will collect data from both.  So there's already an upgrade path.  It's just not particularly cost effective to do this, since you end up paying $200 more for the standalone MQGPS than you do for the GPS option on the MQ200.  This is why we encourage customers to think carefully about whether they will want MQ200-level functionality within the next couple of years.

There's a disadvantage to having the MQGPS and MQ200 on separate COM ports.  When you have the GPS option on the MQ200, the data goes directly to the MQ200 and is timestamped according to the MQ200 internal clock, which keeps all the data aligned timewise according to the same reference.  When you have GPS coming in to the Pocket PC instead, then you have a disconnect between the timing of the MQ200 data stream and the timing of the GPS data stream.  Due to buffering and other communications delays, the GPS data can be skewed in time relative to the MQ200 data.  Normally the skew isn't more than a few tenths of a second (worse on some v.1 MQGPS-Bluetooth units), but there's a random component to it.  So while having the MQ200 and MQGPS on separate COM ports is suitable for general-purpose use, if you are trying to do something tricky like fusing the accelerometer data with GPS to get more accurate track mapping, it's a problem.

The Sparkfun accelerometer board is pretty nifty.  We've looked at their stuff before.  Still, once you figure in the costs of adding a suitable power supply and/or battery plus an enclosure and labor to build it into a usable device, and then you add its retail price to the MQGPS, it's not that far off the cost of the MQ200-RT with GPS option, and with the -RT you also get 6 external input channels so you can do RPM, MAP, and other things.

We've talked to the guys at Vital and we like their Bluetooth OBD-II dongle, though we use a different supplier.  Their older dongle was too long to avoid getting hit by the driver's legs, but they've got a much shorter one now.

We've been looking at releasing a Bluetooth OBD-II option for use with the MQGPS for a while now, just waiting for awareness to build.  Please tell us if this is something you would be interested in buying.  Price would most likely be $249.

 

---

Ed Lansinger
MaxQData, LLC
Data Acquisition Systems

Ed,

Thanks for the very informative reply.  The OBDII blue tooth may be a bit pricey at $249, so not sure I'd be willing to buy one at that price point just yet. But, then again if it means not running wires to the various inputs that OBD would provide you instead, then maybe it is worth it.  Do you know how many calls to the OBDII can be made in .2 secs? I'm curious if it would be fast enough to provide data at the polling interval of the mqgps.

 Oh, and I forgot to thank you earlier for making that second run mqd file available on your wiki site.  I've been playing with the software since, and getting a better idea of what it's capable of doing.  A few questions though:

 Is there a way in ChartView to keep the two overlayed runs at the same location during the course of the run? I would like to see what each drivers MPH, Lat/Log Gs are at the same point on the course, but didn't see an option for that.

And lastly is it possible when loading a multi-lap recording in chart view to overlay two different lap times?  For instance, when loading run001.mqd and setting a becon, it shows 10 different laps.  Could I somehow replay only laps 2 and 6 in overlayed mode?

 
Thanks,

 

 k
 

---

Paul Barros
2001 Z06 Corvette
Atlanta Region Solo2

Happy to help.  The OBD-II rate depends on the OBD-II bus in the car.  The minimum we've seen is around 5-6 updates per second.  Bear in mind that each update only changes one value, so if you monitor two OBD-II values (e.g. RPM and TPS), you are only getting about 3 Hz on each.  In practice, that's still usable.  Three or four values is pushing it.  Some cars are capable of 10 Hz to 20 Hz updates.  Cars with the ISO bus are slowest.  VPW and PWM are faster, and CAN is fastest.

OBD-II is very helpful and convenient.  If you need maximum detail, though, it's better to use an MQ200 and tap directly into the wiring harness to read sensor values directly (e.g. MAP, TPS, RPM), then save OBD-II for slow values (like Coolant Temp) or values that are hard to measure (like Spark Advance).

In Chart, you can go into "Plot by Distance" mode to keep two files aligned.  On the Pocket PC, you tap and hold on the field where it shows the zoom factor (e.g. "+-20s").  On a laptop, you right click on that field.  Now the data will be plotted and scrolled by distance.  So as you move two plots, both are moved the same distance regardless of how fast the car is actually going.

To overlay two laps within the same flight recording, load the same recording in both the A) and B) sections on the display (this happens automatically when you load the first flight recording).  To jump to a particular lap, right click on the beacon count field for either A) or B), go into "Details...", select the lap you want, and click "Goto".  You can do this separately for the A) and B) sections to line up two different laps within the same flight recording.  Alternatively, you can uncheck the checkbox next to the file time value under either the A) or B) section (which locks that view at the current position), scroll the other view to the point you want to see, then recheck the box so you are back to scrolling both.

---

Ed Lansinger
MaxQData, LLC
Data Acquisition Systems

Andy,

 

Have you got a picture or suggestions for mounting your MaxQData and Pocket PC in a Miata?

 
I just got mine yesterday, geez this thing is TINY!

ecugrad97:

Andy,

 

Have you got a picture or suggestions for mounting your MaxQData and Pocket PC in a Miata?

 
I just got mine yesterday, geez this thing is TINY!

I wedge the GPS unit into the ash tray and put the PDA in the console.  Pretty simple.  Pic attached.

--Andy