Full Decoder Setup In Tunix?
Posted: Sat Oct 01, 2011 12:44 pm
I came across these screen shots of some app watching the BMW 60-2 pattern and noticed that it actually recognises the pattern in the code on the PC. I thought that that is a nice feature. You could setup the Listener decoder on an engine, take a recording using the yet-to-be-written log type here and then run a set of algorithms over it and TELL the user which pattern they have and which firmware they need. Taken one step further you could load that firmware type for them, by name and allow the truly stupid to wire up an engine and not have to think. Personally I think that last step is a TERRIBLE idea, but it could be done.
You could actually take it a step further than this and report that it is in fact a 60 minus 2 but wired backwards as it is possible to determine that from the log. I intend to report a "wiring backwards" error from the decoder in real time too, however identifying it from a log while away from the car would be nice. And decoder could would be ULTRA easy to write in a PC app with no real time pressures and floating point math.
Ben Fenner actually suggested doing this sort of black magic in the firmware, but if done thoroughly for a large number of possible patterns and connections it would be unfeasible in a real time context, and regardless of that, it's a bad idea to assume what the user has. That should definitely be explicitly provided to the device as a setup parameter.
This thread could equally go in the OLV section. If no one else steps up, I may write a utility to do it at some point.
I would probably not give an answer, but rather a full listing with colourised results such that if there was any ambiguity it was clearly shown. The list could be sorted by result rather than name, and sub sorted by name.
Fred.
You could actually take it a step further than this and report that it is in fact a 60 minus 2 but wired backwards as it is possible to determine that from the log. I intend to report a "wiring backwards" error from the decoder in real time too, however identifying it from a log while away from the car would be nice. And decoder could would be ULTRA easy to write in a PC app with no real time pressures and floating point math.
Ben Fenner actually suggested doing this sort of black magic in the firmware, but if done thoroughly for a large number of possible patterns and connections it would be unfeasible in a real time context, and regardless of that, it's a bad idea to assume what the user has. That should definitely be explicitly provided to the device as a setup parameter.
This thread could equally go in the OLV section. If no one else steps up, I may write a utility to do it at some point.
I would probably not give an answer, but rather a full listing with colourised results such that if there was any ambiguity it was clearly shown. The list could be sorted by result rather than name, and sub sorted by name.
Fred.