DL1 + Version 7 Monitor

[Dan in Saint Louis]

Has anyone else had any problems using a DL1 with the Monitor program, version 7?

I can see the data from the DL1 nicely with Monitor v6. I can see some of the data using Monitor Lite v7, but the update on each channel is dreadfully slow (less than 1 Hz) with the COM channel configured to 115 kbps. Even slower at 9600 bps.

On the "full" Monitor v7, data from the internal accelerometers jumps about randomly to values as much as 50,000 g. I gave up at that point and did not try any other channels yet.

Thank you!

[faraday]

I haven't been "live" via serial with it recently, but I've had more joy with it than you in earlier V.7.x.x.
It was not plane sailing, however.
I put most of my issues down to using a cheap serial->USB adaptor cable.
R-T have done a lot of work on it over the last month or so. I'd be surprised if it's not better behaved as well as equipped with a comprehensive default setup. It now appears that the full gammit of external channels, including serial input from an ECU, will be displayed if an R-T device with these inputs populated is hooked up.

Basically, apart from getting used to setting the data source in the "dead" edit mode and then going to play, it should be simple like the V.6 monitor.

It would be a waste if after this effort it was still flaky.

What version has given you problems, Dan?

[Dan in Saint Louis]

I haven't been "live" via serial with it recently, but I've had more joy with it than you in earlier V.7.x.x.

I wholeheartedly agree that the v7 Analysis program is a big step forward. I find its use much more intuitive, and the advanced bandwidth filters are going to save me HOURS of data analysis. The Variable Manager seems to be easier to use also, but I have not pinpointed why.

I put most of my issues down to using a cheap serial->USB adaptor cable.

I'm using one from Prolific Technologies that is the only stable one I have found. The others are not stable. Usually they lose their drivers and require reinstallation every time they plugged in. The cable is quite stable with Monitor v6, and communicates well even with both ends of the link (Windows Device Manager and RT communications port) set to 115 kbps.

R-T have done a lot of work on it over the last month or so. I'd be surprised if it's not better behaved as well as equipped with a comprehensive default setup. It now appears that the full gammit of external channels, including serial input from an ECU, will be displayed if an R-T device with these inputs populated is hooked up.

What would really serve our "Monitor" application best would be a checklist of variables to display, and then a simple alphanumeric display of those variables. Configuring all those window sizes and shapes and colors, and then labeling them to build a virtual dashboard, detracts from the time we have to actually study the data. Actually, something like v6 but with a checklist of variables would be great.

Basically, apart from getting used to setting the data source in the "dead" edit mode and then going to play, it should be simple like the V.6 monitor. It would be a waste if after this effort it was still flaky.

Ay, there's the rub! In the US we would say it's all sizzle and no steak.

What version has given you problems, Dan?

I cannot find the software version of the Monitor program displayed. It is the one that accompanies Analysis 7.2.58.

For now, the package that is most serviceable for our application (forensic engineering data logging of vehicle testing) is Analysis 7 coupled with Monitor 6. Assuming I can get our DL1 to lock on any satellites and read Analog Inputs 1, 3, 4, 5 and 6. Seeing Input 4 display 58.167 volts with the input grounded is a bit alarming!<G>.

[faraday]

Good points and advice re Prolific. Will investigate.

Graphic displays certainly have their place, especially as an analogue of the physical quantity being measured. If its simply a big, bright "digital" numeric readout mimicking an LCD, it becomes sensory overload if it is one of more than five or six on the screen.

Sitting at a desk or well organised test bench a simple alphanumeric table or list is fine, but there are many occasions in a workshop or at a car when at a distance, or with several viewers in attendance, that larger virtual instruments are highly desirable.
We are being spoilt for choice.

You have hardware issues?
I hope these are being attended to. Are you trying to fix them yourself?

[Dan in Saint Louis]

Good points and advice re Prolific. Will investigate.

It is worth noting that the results can be random. This morning both my ATEN and Prolific converters are working, but none of the monitor software will read all 8 Analog inputs. Which inputs DO work appears to change whenever I try different COMport speeds, generally displaying more inputs as the COMport speed increases. . Monitor v7, Monitor Lite v7, and Monitor 6 can require several seconds to display a value (115 kbps, fast update, filtering off). Yeah, I know I just praised v6 a few minutes ago, but I had not yet noticed that only a few of the channels had good data.

I mistakenly assumed my DL1 was dead, but it appears to only affect data through the serial port. All the Analog Input channels record good data on the CF card.

Graphic displays certainly have their place, especially as an analogue of the physical quantity being measured. If its simply a big, bright "digital" numeric readout mimicking an LCD, it becomes sensory overload if it is one of more than five or six on the screen.

I completely agree about analog readouts, either circular or linear, when one's attention ought be elsewhere (spirited motoring).

OTOH, for our scientific data collection and analysis needs, the numbers are important. They are also important when I collect data to verify our test setup calibration -- if I cannot verify a chain of calibration the defendant's attorney can get our testimony tossed out of court.

You have hardware issues?
I hope these are being attended to. Are you trying to fix them yourself?

<G> I wish I could! I have designed computers for a living at different times of my life, and just retired as a Professor of Electrical Engineering after 32 years of full-time teaching. I have held both amateur and commercial radio licenses for over 40 years. But inside the DL1 is best left to the designers! Yes, we do have hardware issues in a couple of areas. Our DL1 was just in Nottingham for attention, and RT has communicated well about shipping, etc. It arrived yesterday (Friday 30 May) afternoon.

One of the issues was failure of the GPS to acquire any satellites. As of this morning that appears to just be a sensitivity issue. I have been spoiled by my Garmin Nuvi 200 GPS that will lock sitting on the sill just inside my office window, and by the Pharos GPS antenna that came with Microsoft Streets & Trips. The Pharos will acquire a couple of birds when it is on the sill just OUTSIDE my office window.

The RT antenna locks 5 satellites when it is on the steel roof of my car with clear blue sky in all directions, but that's about it. As I write, it has been sitting on a horizontal steel plate extended about 4 feet beyond that same window sill with plenty of open sky above for over an hour, and it has yet to find any signals. The Pharos is on the same steel plate about 6 inches closer to the building, and locked on four birds within a few seconds of plugging it in. (Or whatever the signal strength bars mean -- it brightened all four out of four, and the drift in the displayed location is about 10 meters. Altitude data is stable within one meter. That sounds like at least 4 birds to me.)

Whenever there is a CF card in the slot it begins logging at random times with no command from me. That's a real killer for scientific use.

With the DL1 perfectly flat as confirmed by a tested bubble level, the internal accelerometers record about 0.07 g longitudinally (4 degrees tilt?), and about 0.02 g laterally (1 degree tilt?). I can cancel those out of the recorded data, but I think 4 degrees is too much offset.

The DL1 is a marvelous piece of gear, but we really need to be able to count on it.

[chrisp993]

Maybe a dumb question, but how do you know how many satellites are locked? I know this is one of the GPS variables, but it doesn't seem to log anything on my DL-1

[Dan in Saint Louis]

Maybe a dumb question, but how do you know how many satellites are locked? I know this is one of the GPS variables, but it doesn't seem to log anything on my DL-1

The number does not get logged on mine either, but if you watch the "GPS Lock" LED on the front panel, you should see one long blink and a number of short blinks. The short number is the count of locked satellites.

See also http://www.race-technology.com/wiki/index.php/DL1/Operation.

Hope that helps!

[chrisp993]

Got it - thanks Dan

I was aware of the LED code but was hoping that somehow the GPS # would be logged as data - can't imagine why not since obviously the DL-1 box is aware of # of satellites

[Dan in Saint Louis]

was hoping that somehow the GPS # would be logged as data

RT is constantly updating features, and I know that they read this forum. That feature might just pop up sometime!

[faraday]

It is interesting that Dan has used DL1 data in litigation. I have client colleages (both mechanical engineers engaged in automotive testing) who are fearful that the DL1 (and we'd have to include DL2, since they now own one, as well as three DL1s) would not stand up in court particularly well.
They are not contemplating presenting evidence/data as expert testimony, just fearful of a suit against them or a client on the basis that their data lacked precision or accuracy. The problem they perceive is not in the accuracy of the magnitude of the parameter measured, but in its timing, wrt the update or sampling rate. It is as much a problem with the software as it is a hardware issue.
They are primarily interested in velocity and have a firm belief, notwithstanding that most of their work is with average performance road vehicles, that 20 Hz is a necessary minimum for their higher level tasks. They concern themselves with latency, not just the rate. As well, they desire traceability to the raw measurement, in this sense a GPS result such as contained in a NMEA message, rather than a result blended with an accelerometer mesasurement. Thus, they have a desire to be able to present their measurements as discrete plotted points with the confidence to state that the reading is attributable to device X with accuracy Y. They regard accelerometer output, probably correctly, as too noisy and subject to installation/calibration errors, to assist the accuracy of GPS velocity measurements.

It is interesting that as I type, you are engaged in discussion of satellite count. These chaps had more prior GPS experience than me, and showed me on my DL1, which they used before they purchased their own, this "Morse" flash display system that they discovered without reading any documentation. Please note well, this feature appears to be hardware vintage or firmware version dependent. I have later DL1s that only have a single flash duration on this LED.

In early versions (4, 5 & 6) of Analysis, zooming into an X, Y plot we could see discrete points in velocity, processed without accelerometer assistance, at 200ms intervals in early DL1s and 100ms for post S.N. 1000 units. Now, however, in recent V.7s, I see only 10ms points, regardless of the processing option
My colleagues would be most unimpressed

I wonder what they would observe and conclude if they were looking at a serial data stream captured by Monitor?

Certainly, I can relate that I have had issues in the "live" Monitor display with sticky, slower than requested, or irregular updates on numerous channels.

Cheers
Michael of Melbourne

[Dan in Saint Louis]

The problem they perceive is not in the accuracy of the magnitude of the parameter measured, but in its timing, wrt the update or sampling rate. It is as much a problem with the software as it is a hardware issue.

That has not been an issue here. Our courts, at least so far, concentrate more on issues of data reliability, repeatability, and the acceptance in standard text books of the methodology used. Of course, much of the equipment available now is too new to be "standard" text books, so it can take a lot of explaining -- depending on the judge.

They concern themselves with latency, not just the rate. As well, they desire traceability to the raw measurement, in this sense a GPS result such as contained in a NMEA message, rather than a result blended with an accelerometer measurement.

Interesting, since the SDM data stored in the airbag system module has no GPS connection. I believe the delta-v data is developed from accelerometer output, not wheel speed. AND... it has become a standard of comparison in Federal courts.

They regard accelerometer output, probably correctly, as too noisy and subject to installation/calibration errors, to assist the accuracy of GPS velocity measurements.

Filtering takes care of the noise. Obtaining velocity from acceleration requires integration anyway, so filtering is more or less unavoidable. And the method certainly appears in standard texts! The calibration has been shown to be within useful limits in the SDM boxes. Google "vetronix" to find several papers citing precedents and explaining how the data is derived.

[Support]

The DL1 does not internally know how many satellites are used in the solution. It does have a figure for the accuracy of the speed and position data though. Early DL1's do flash the GPS status LED to show the number of satellites, this comes directly from the GPS receiver module, not from the main processor.

DL1s which have version 6 bootloader can show the number of satellites with the 20Hz GPS option, since in this mode all the GPS processing is carried out on the PC from the raw data.

In terms of GPS accuracy, the number of satellites is useful, but doesn't give the full picture. A signal from 9 satellites is not always better than one from 6 satellites. If the 9 satellites are all in the same area of sky, or a few of them are very low towards the horizon then the solution can be worse than an ideal constellation of 6 satellites. For this reason you are better looking at the speed and position accuracy rather than just the number of satellites in the solution.

Martin