Making a many many channel logic analyser? How to?

[jwhitmore]

I'm working on a 20 year old tractor, replacing the wiring loom which has gotten old, tired and the insulation has hardened and is cracking off the copper conductor. That's relatively easily replaced, (apart from a few connectors which I can't locate at all). The system is controlled by a few computers which I'll treat as black boxes. The computers are connected up with 1 or 2  36 pin connectors, so there's a maximum of 72 connections which are, I assume, either 5V or 12V depending on their function.

Now to my question. At some point in the future the computer will fail and need to be replaced. At that point in time the manufacturer will neither have spares from the past, nor will they have replacements, or support a 20 year old machine. Now obviously replacing a 20 year old computer isn't going to be difficult but the logic which is contains might be. With that in mind I was thinking if I could analyse the pins of the computer I could gain some understanding of its operational logic and reproduce that logic. For that I'd need a logic analyser which could look at up to 72 connections. I don't have that kind of money but I thought if I had a microcontroller with a lot of AD channels I could do it. Even if you did a lot of channels with a slow frequency you could, having gained some understanding of the pins being used for a particular function, concentrate your computational power on the smaller number of signals which are relevant to a function, getting a more detailed picture of the functionality.

First of I should say that I assume that's not illegal. I'm not breaking into the copy rights of the manufacturer, but looking at the output from the black box?

Secondly there is going to be no device which has that number of A/D Channels so you'd have to use a number of micros and somehow synchronise them.

I'd include a USB port and either create a User Interface on an Android Tablet or a computer but that's not the difficult part. Well I don't think so. The difficulty is the number of channels required.

So can I ask has anybody got any bright ideas? I assume 20-30 channels is the maximum you'd get on a single Microcontroller, well it's as many as I've found so far.

[kripton2035]

they are quite pricey but tek logic analyzers goes up to 600 channels ... today !
http://www.tek.com/logic-analyzer

[danadak]

If you are not on a short timeline and are tool experienced a simple FPGA
board and some Python to handle display could easily work.


Regards, Dana.

[CJay]

Far better to obtain a service manual for the tractor as it should give you a wiring diagram and fault finding information to enable you to diagnose issues with sensors and actuators. *edit* which will give you more information about the expected operation

If it's modern/advanced enough to have an OBD interface then there are *many* OBD to PC interfaces available which will give you a lot of information.

Beware the connectors, some of them can have a *very* limited number of rated insertions.

If you can identify the manufacturer of the ECU and other 'computers' then it may even be possible to locate an off the shelf replacement from one of the 'performance' shops.

[ebclr]

The 1st thing you need to do is know what is the speed you are talking about anything less thaN 10 kHZ will be very easy even with 72 channels on the other hand if you are talking about ns prepare the pocket



http://www.nci-usa.com/mainsite/logic-analyzer-gologicxl-72/

[tszaboo]

Get a Xilinx FPGA dev tool, and put a chipscope in it.

[daveshah]

I'm not sure what the copyright situation is - for personal purposes only should be fine - but how about a different approach to the problem.

Being ~20 years ago, it's quite possible the computers are a microprocessor design rather than microcontroller. In which case you could dump the ROMs and just keep spare copies of the ROMs, and spares of the microprocessor (most of which are still fairly easy to get hold of today) and any other support chips to repair the boards if they fail.

[Brutte]

The need for that backup depends on the type of the program and data memory that sits inside of a controller.
If that is mask ROM - it would never fail. But ROM was phased out long time ago..
The next technology w.r.t. reliability is OTP. These were essentially windowless versions of EPROM. Retain data >20 years at 85degC. Then there is EEPROM and NOR flash (both similar w.r.t. retention), the most common in embedded uCs nowadays (EEPROM is byte erasable and NOR is page erasable). Some manufacturers guarantee only 10 years at 85degC.
The worst you can get is NAND flash. This is the cheapest crap used in USB sticks and memory cards but also anywhere where there is a need for MB/GB storage (unlikely in tractor ECU).

Make the backup of all NV memories 
And if you want the product to run eternally without memory corruption, use masked ROM. Or use NOR flash and refresh the content once in a decade (read+erase+rewrite every page).

[madires]

I think, the wiring diagram and a dump of the firmware are much more useful than using a logic analyzer, because it won't show you any calculations which are performed by the CPU/MCU to create control signals.

[jwhitmore]

Thank you all for your replies. I'd promised myself I'd learn how to use ngspice on Linux over the Christmas break, but FPGA seems to be the something I should have on the list. I do want to design a possible solution to the logic analyser, I certainly can't afford to buy one.

There have been a few comments about life span of memory technologies which are scary as hell! That makes me feel I should get my finger out.

There were a few comments stating that I should look at a wiring diagram for the tractor. I've written a blog post on that subject entitled "Power, Information and Logic" which deals with why a wiring diagram is useless, for certain information, in my opinion ;-). To give an example: from the wiring diagram I can see that the tractor's "Transmission Control Module" has, amongst other signals, a button for "Up" a gear ratio and a button for "Down" a gear ratio. I can also see from the wiring diagram that the tractor's transmission has 5 Clutches and 6 Solenoids controlling hydraulics in the transmission, as well as two potentiometers internal to the transmission which are inputs to the Transmission Control computer.

I can see all that in the wiring diagram, but if I wanted to control the various outputs to change from gear 13 to gear 14 what am I outputting to clutches and solenoids, and what am I expecting to see happen on the Pots? The wiring diagram is never going to tell me that. In addition to all that the Transmission Control Module has two 36 Pin connectors, not all of which are connected, I'll grant you, but there are over 60 connections to the computer. I've mentioned ones that make sense to me and are used in changing gears but are there other signals in the 60 odd which are also relevant? Is there an edge condition where an oil temp sensor shuts everything down or the gearbox will get destroyed? I've no idea, and even if I had a multi channel logic analyser it'd never pick up edge cases, but I might work out how to change from gear 13 to 14, most of the time.

Maybe I'll look at opening a computer module and see what processor and memory is being used that is probably the easiest way to future proof the machine, but I must learn about fpga. Having said that does FPGA do A/D? I must look into all of that...

Thanks for all your advice!

[Brutte]

Another thing that can fail in ECU are the electrolytic caps. Those ECUs work in tough conditions, the caps are ruggedized, high temperature, shockproof and what not but still might fail after 20 years or so. If you open the 20 y.o. ECU - do not bother testing the caps but just replace them. Unfiltered power supply can cause many secondary failures.

If I were you I'd have dumped the idea of building my own ecu. Get a replacement ecu of same type, keep it at safe and cool place and just swap it in case of some problems.