The MGF Register Forums

Some of you will have encountered problems with accessing live data when the engine is running, if you have MEMS1.9 on a very early MGF.

We now have a fix for this.

Please see http://www.rovertech.net/forum/viewtopi ... 4&t=151040

Nice one Philip!

I haven't had achance to do a software update recently, but have you had a chance to data log? Perhaps to a csv file?

Rob Bell wrote:but have you had a chance to data log? Perhaps to a csv file?

Perhaps you think that this is a five minute job

How much data needs to be recorded? I am thinking that opening a file and writing to disc as the same time as collecting data from the ECU (which is a real time activity) is not going to be easy. It's probably easier and more reliable to dump to it to RAM and then save that to disc when the session is done, but of course this could limit the amount of data that can be saved.

Have you tried out your modified diagnostic tool?

Thanks Phil - I collected the modified box from the post office yesterday

You mean full telemetry isn't a 5 minute job?

The idea of telemetry has two objectives in my mind:
1. diagnostics of an intermittent or challenging fault
2. monitoring multiple parameters to ascertain engine/cooling system/fuel or ignition condition in use

The idea therefore is to be able to retain as much data as possible: for intermittent faults, where you don't know where or when you're going to encounter them, being able to continually record is actually very helpful.

In my "world", we have a similar problem - we need to be able to collect heart rhythm data continuously, 24 hours a day, 365 days a year for up to three years. Clearly there isn't a memory pack of sufficient capacity that could fit within an implantable recorder that is about the same size as a first generation iPod Shuffle. Regular downloads (6 monthly) help, but isn't sufficient. The problem is overcome in "Implantable Loop Recorders" - the clue is in the name: the device continually records, but over-writes data that probably isn't that useful to obtain a diagnosis. But the ILR also has an event trigger that, when activated during an event (palpitations, dizziness, loss of consciousness), that section of data (plus/minus say 10 minutes in either time direction) is protected from being over-written and stored for later analysis.

That'd be a programming challenge!

Assuming that we're not looking at a "loop recorder", how long would a straightforward dataset be? For me, 15 - 20 minutes would otherwise be sufficient for most of the other relevant data collection needs.

The fewer parameters collected, the more is likely to fit into the available Ram of the laptop or tablet being used?

Some diagnostic devices actually have an SD card - Mykel, the one you had has this feature as I recall?

The above would be my wish list, but any kind of telemetry function would be invaluable to start with - and would separate this tool from the majority of products on the market

From a programming perspective the easiest thing is to just log the same data that is seen on screen to harddrive (via memory). So whatever parameters you select on screen, is what gets recorded.

Plus a timestamp of course.

That'd be good!

Then it would be possible to open in Excel or similar to present the data in graphical form?

I would just save it as a csv file so you could open it in Excel or Libreoffice.

Perfect

Intermittent faults! They are a real PITA. Nothing to do with cars but I had a real sod of one way back in the late 60s with an electronic accounting machine. The card reader would throw up random errors. It wasn't the individual account cards as they would be read without error on the mainframe machine. But this added a huge amount of overtime on an end of month trial balance. Unhappy customer, unhappy operator and one unhappy engineer. To find the error involved wiring a spare flipflop to the error gate ( an OR gate ) which had umpteen inputs made up of a mixture of AND & OR gates. The circuit boards were plugged into a backplane which was wire wrapped. This made it easy to move the error trigger pulse to the flipflop working methodically away from the mainframe error gate output. The flipflop would illuminate an indicator lamp when I eventually tracked it down to the culprit gate. I made sure the operator left the machine on until I arrived so that I could see if my error light was illuminated. The data was getting corrupted by a broken wire in the loom between the mainframe and card reader. But it wasn't any of the data lines, it was the ground wire. Two wires from the reader were at ground and earth. The problem occurred because there was a 1 volt difference between ground and earth which screwed up the logic high & low levels. This wasn't clear on any of the manuals.

willyphixitt - yes he did!

Nice story Bill - sounded like a nightmare!

Rob,
Yes, it was a nightmare! Spent a lot of time checking the "data & complement" pulses from the read heads all the way to the solid state memory, tweaking the "sense" pulse timing before going down the long winded error detection routes.

willyphixitt

Bet it was a real "YES!" moment when you cracked it!