[EDS50]

No its not a joke. For those that don't know Moates decided to close the doors and shut the business down. Very sad to see. With that being said; what do we do now and which direction to go. What's everyone's thoughts?

R.I.P.
https://www.moates.net/

[jsa]

It seems Moates don't want to open source it, sell it or license it to anybody else.

TwEECer is still available, but what is usability hit like?
Who's used both and able to give a detailed comparison?

Other brands of J3 chip are available but some require different tools to program.
EEC-V have still got Mongoose or similar tools available to reflash.

It'd be nice if clones or revised / enhanced versions became available.

[FinnCobra]

tweecer is in my opinion 50% of QH. Very small payload can be logged. Drivers are so old that installing them is not as easy in newer Windows versions. I always use QH, and when tune is ready I transfer it to tweecer if customer has it. I have tweecer hardware license in BE, I don't like Calcon or Caledit.

[jsa]

How many bytes of payload do you get?

Yes, I've just got a tweecer license for BE in case my existing QH fails.

[86GT]

It is sad to hear about the Moates QH and F3 chips. It is a big hit to the industry. It goes to show you how good the hardware really is. I wish the best for the Moates Camp...

Core Tuning still has a limited supply of QH. These reaming QHs can only be purchased with a QH package.

As for the TwEECer, it is still an option. Yes the drivers can be a little picky if you have the older TwEECer version. I believe Mike Glover has drivers which are more windows 7+ friendly. These newer drivers work with the newer TwEECer's. It maybe as simple as a firmware update. Someone should ask Mike.

The TwEECer can handle up to 32 bytes total. Yes it is less than what the Moates QH could do, but it can still get the job done. The base TwEECer is just like the Moates F3v2 chip and does not have a battery. The RT TwEECer has the ability to datalog and again there in no battery. The RT edition requires a different patch code from the Moates QH. Some strategies will need to be updated with the new patch code.

There are other F3 equivalents on the market. We have to start looking into these alternatives and contact the manufactures. The manufactures have to be willing to allow it to be implement into BE. Its a legal thing....

Rest assured that Binary Editor will still be maintained and updated as needed.

[Jman]

Is there anyone who has the Moates adapter for using the BURN2 to program J3 chips or the one to read an EEC with the Burn2? I think these adapters are called F2A and F2E. If anybody can post close up pictures here or PM them to me that would be great. I don't have a Jaybird and would love to try to copy these adapters. I would share PCB layout and schematics with anyone interested if I could manage to accomplish this.

If anyone would ring out traces and make a wiring list, I'd be extra grateful, or just ring out traces that are difficult to determine from pictures.

I've attached a couple pics from the web, but you can see I will need real good close ups and even then, without ringing things out I may have to make some educated guesses. Close up pictures of both sides of the Jaybird are also welcome this may help with the project. Maybe I could even try to copy the Jaybird.

Any thoughts, photos, and information are welcome.

Thank you
J.W.S.

[Jman]

I can see the view count going up on the pictures. Does anybody use these adapters I've mentioned in the previous post? Do they work well? Is the A9L and other EEC4 users dwindling to the point of not much interest anymore? Am I the only dummy that should have bought more Moates hardware when we had the chance, but didn't?

P.S. If anyone thinks this topic would be better under a different category do tell.

Thank you
J.W.S.

[cgrey8]

I use the Moates QH and I have 2 of them, one for a backup. I also have an old TwEECer, but I haven't so much as connected it up in quite some time. There's word that it may not even work with my Win10 laptop. I don't think it's been connected to anything since I had my Win7 machine (of which I still have around). I might should not get rid of it just in case I need it to work with the TwEECer.

As for that adapter, I don't have a use for it since I use those devices that don't require it. However the concept EEC Whisperer will need a connector something like that since right now, the concept is based on the Beaglebone AI64 which is WAY too big to go inside the EEC...and it gets way too hot to do so as well, so it'll have to be connected via some kind of ribbon cable if it ever makes it past the concept phase. I was making good headway with it back over the Christmas break, but work has picked up and "life" consumes much of my weekends here recently so I haven't had much time to spend piddling with it. But I have gotten some code to run on both the ARM processor as well as the PRU...and gotten them to pass simple messages back and forth. I have not gotten them to share DDR memory though yet. That's still on the todo list.

[Jman]

The EEC Whisperer sounds neat, and I like the name (makes me think Robert Redford needs to be involved (JK)) and would love to know more about it. If you're trying to develop something for potential profit I'd understand not wanting to share, otherwise tell me more.

I'm hoping someone has those adapters and will share their design details with me. I'd even buy the adapters from someone if they no longer were using them, and they were just sitting around collecting dust.

Thank you
J.W.S.

[cgrey8]

No secrets about that project. It's an open source idea.

Read more here
https://docs.google.com/document/d/1TWL ... ue&sd=true

It is not a quick read and in places, expects the reader to be pretty familiar with the EEC-IV/V architecture.

[Scaffy]

The EEC Whisperer sounds neat, and I like the name (makes me think Robert Redford needs to be involved (JK)) and would love to know more about it. If you're trying to develop something for potential profit I'd understand not wanting to share, otherwise tell me more.

I'm hoping someone has those adapters and will share their design details with me. I'd even buy the adapters from someone if they no longer were using them, and they were just sitting around collecting dust.

Thank you
J.W.S.

Are you still looking for those photos? I think I may have the items you are looking for, sitting in a box in my garage.

[Pontisteve]

I can see the view count going up on the pictures. Does anybody use these adapters I've mentioned in the previous post? Do they work well? Is the A9L and other EEC4 users dwindling to the point of not much interest anymore? Am I the only dummy that should have bought more Moates hardware when we had the chance, but didn't?

P.S. If anyone thinks this topic would be better under a different category do tell.

Thank you
J.W.S.

I have them as well.

[cgrey8]

I can see the view count going up on the pictures. Does anybody use these adapters I've mentioned in the previous post? Do they work well?...

I've only used TwEECerRT and QH. I can't speak to these. But I don't have any reason to believe they wouldn't work.

...Is the A9L and other EEC4 users dwindling to the point of not much interest anymore?...

That's a complicated question and I have to begrudgingly agree that you are probably right. But it's not that the GUFx era EECs aren't still useful. They are just as capable as they ever were. But so are carburetors. And people still use carbs. The difference is you can still buy carbs...brand new off the assembly line. You can't buy new or even re-manufactured A9Ls and A9Ps anymore, at least not from places like Cardone and their various distributors. So people that can, have moved to what is available. And it's just a matter of time before all EEC-IV/V are relegated to the past, replaced by technologies that are smaller, faster, cheaper, and better. The only thing that I know of that keeps people LOCKED to using them are emissions requirements in areas that do extensive analysis of project vehicles like California where they really don't want these old vehicles in existence and do everything they can, short of banning them, to make it as hard as possible to own one there.

I keep hoping an open source project, similar to MegaSquirt, will come on the market and be a near plug-n-play replacement for EEC-IV/V as well as capable of flying under those government radars including being able to pass OBD-II emission tests, even if they have to do it the VW way. And to be honest, I welcome it. I've hated how limited our options are for improving the "old" strats. Minor tweaks and hacks have been done, but they are tiny compared to what could be if the hardware were more capable and rewriting the code could be done easier & with higher confidence than raw binary-hacking. More modern day hardware and programming languages can offer this. And if I wanted to stick with C/C++ for development, there are some good solutions out there. But I want something that's easier to maintain and easier for people to make small additions and contributions to without having to be absolute experts on the entire platform they are developing for.

For example, think about your cell phone. You got kids in high school writing apps for cell phones. They have no clue how the cellular, WiFi, and Bluetooth antennas work or touch screen works, but they don't need to in order to write an app that can use those peripherals and do useful things.

Likewise, I want a vehicle-management platform where you don't need to understand or even mess with the low-level code related to engine ignition and injector firing to add new functionality to the vehicle management computer nor should you be required to be an expert at user-interface development to expose your new code's configuration and status properties to a UI to display and datalog them. But if you need access to that stuff, it's there and available to you. For instance, lets say this platform gets off the ground and can completely replace an A9L. And someone decides they have the knowledge to expand its capabilities to not just interface with a Gray TFI, but also a Black TFI. I want a development platform where developing that addition is an easy change. Then if someone needs EDIS or COP, there's examples out there for them to develop those. If these kinds of things can be done easily, it could snowball into things we couldn't imagine today.

Lets say you find your addition useful, you should be able to post your contribution to some website like GitHub or SourceForge so others can make use of it without much more trouble than you'd install a new app on your cell phone. Now will it ever be that simple? Not likely. But that's in the vein of what I'd like to see become available to help us migrate away from where we are to where we could be.

My investigations of the Beaglebone AI64 suggest that the hardware is there, but the supporting firmware to do the things necessary for automotive applications just aren't (i.e. support for low-power mode and quick-wake). I've expressed these concerns over on the Beagleboard forums and the people in positions to get those things officially supported and implemented know these are needs, but like so many other things, there are higher priority things ahead of that request. I just wish I was familiar enough with those areas of Linux to open-source develop those solutions myself. But I'm not.

As for the other concerns about whether you should've bought more stuff when you could, I can't speak to that. I'm admittedly speaking from a position where I have a spare A9P, spare QH, and my original TwEECerRT all in storage that I can fall back on if need. But when I can no longer drive my truck because the parts to keep it running are no longer available or affordable, I'll either be forced to scrap the project or look for alternatives. And yeah, it might be expensive and a ton of rewiring I didn't want to revisit, but that's the nature of having such an old vehicle. And if it comes to that, I'll approach it as another fun and challenging project to keep my mind thinking and the wheels spinning on a vehicle most people view as hardly worth the effort.

[tvrfan]

At the risk of horrifying everyone - A serious question... how common are those old GM EEC boxes in US ??

I ask because from what I see on the web, they do at least use a totally standard CPU and a standard pluggable/erasable ROM chip.
(I don't know if they are still available though) This means that the hardware *IS* suitable for automotive, AND is fully (re)programmable. I have seen a few applications (again on web) which re-use these boxes in completely different situations, e.g. a control unit for a Bosch CIS (or 'K' series) mechanical injection system. But yes, they are (relatively) old, slow, and probably obsolete.

You still have to relearn the code, rewire, etc etc, but is that actually worse than say a Beaglebone?? At least the hardware is well proven and suitable. You are right about the apps idea though - probably not on an old GM unit.

Yes, I know GM vs Ford and all that. But you can't tell me it's not a sensible question... Just askin'

As an aside,- old cars - In UK, I went to kit cars partly because the cars used to fall apart REALLY fast. Salting the roads made things much worse, and a typical (Euro) Ford would have holes in the floor by the time it was 5 or 6 years old. As a result there were lots of cheap parts, and whole cars, which failed their inspections, and perfect for kit car building. I assume the rust situation has improved now, but I don't know. New Zealand doesn't salt the roads, and you do see some really nice older stuff. Still no where near as dry as say, Nevada though, so there is still a (small) market for classic US imports. But nothing you can do once the consumable parts become rare, and expensive..

[jsa]

I reckon once the decision is taken to replace the OEM EEC, then going with something from the same era is not worth the trouble. If the goal is to stay with an OEM box why not look for a later Ford box with open tuning support. Something along the lines of www.openxcplatform.com

It seems the beaglebone is not a great solution for an automotive application.
Something like this with automotive claims might be a better fit.
https://www.nxp.com/products/processors ... .MX-RT1170

As a possible emulator the i-mx-RT1170, has 512kb fast tight coupled memory that could hold a working 4 bank tune, an editing 4 bank tune and a little local code. Other tunes and code can be held in other memory.

[cgrey8]

From a pure controls standpoint, that NXP chip, using an ARM Cortex M-series processor is most likely perfectly capable of running an engine management microcontroller. However my intentions for an EEC replacement are not to just do controls. My intentions are to host both control logic along with a web-based UI that will allow a tuner to tune the device WITHOUT companion software installed on a PC/phone like TunerPro or BinaryEditor. And you can't easily do that with just a Cortex M.

To do what I'm envisioning, I need a microcontroller that has a more powerful application-level processor like a Cortex A-series. The BBAI64 has dual Cortex A72s as well as multiple Cortex R-series processors along with proprietary TI PRU processors to do realtime work that just cannot be trusted to Java/Linux. It's WAY more compute power than what's required, particularly on the realtime side of things, but it's what's built onto an affordable platform I can work with today without having to design, order, have manufactured, and debug a circuit board for. It's also a relatively small form factor that would fit where most vehicle EECs currently fit. Although cooling is still a concern. It heats up pretty bad.

And while it might seem implausible, I'd like the majority of the control logic to be done in Java since Java has a huge support for runtime modification and addition. It's not that you can't do dynamic-linking (and unlinking) with C++, you can. But there are some pretty major limitations and few guard-rails to warn/stop you if you don't adhere to those limitations. And Java has extensive web development support as well. It's also convenient if the UI and control logic can be written in the same language so they can execute as the same application allowing them to more-natively share data with each other. Don't get me wrong, there's still complications with making runtime data changes and synchronizing UI data with runtime data at "safe points" within the code so you don't end up with race-conditions. But simply being aware of those requirements helps the architectural design to cater to those concerns.

Now the real time work that Java/Linux are just not suited for (e.g. ignition timing, injector timing, trans control, etc) would be relegated to at least 1 co-processor. But high level logic could be done in Java and the results of those decisions passed down to a realtime controller to implement. It's not quite this cut-n-dry, but you can roughly separate it out like this...most of the decisions and calculations done in a typical EEC-IV/V tune's background loop could be done in Java. But work done in those tune's interrupt handlers or work that is done by 8061/5 coprocessors (e.g. HSI or HSO) would be implemented in realtime code and handled by a dedicated realtime processor like a Cortex R or M series.

For example, deciding an injector's pulse-width and desired/target open or close time based on tuning parameters, MAF/MAP, RPM, ECT, Throttle Position, CID, transient history, etc, can be done in Java. But translating that calculated injector PW and desired timing to exact OPEN and CLOSE event times requires knowing the the crank shaft's current position, rotational velocity, and rotational acceleration so that those OPEN and CLOSE times (i.e. activation and deactivation of output pins) can be accuracy estimated and scheduled. In a similar fashion, deciding what spark advance and desired coil-dwell to command can also be determined in Java, but the logic to implement activating and deactivating the coil(s) to attain that intended coil dwell and advance needs to be done in a realtime environment.

BTW, for those not familiar the A, R, and M classes of Cortex processors & the differences between them, here's a document that does a far better job than I can do here of clarifying the difference:
Which ARM Cortex Core Is Right for Your Application: A, R or M?

The TLDR is:
A for Applications and high level OSs, like Linux, that run applications
R for Realtime work implemented in an RTOS or raw foreground/background execution strategy
M for general purpose embedded Microcontroller tasks which may or may not have realtime requirements

The R and M tend to overlap in capabilities. But they are architected enough differently that they require their own compilers. Thus a binary compiled for an M, I don't believe will execute on an R, and vice-versa. The R-series is also generally a good bit higher performance than M-series processors making them suited for more-demanding realtime applications.

[Shaker666]

Chris, I think you can achieve your web GUI and real-time control using a TI MSP432 chip. I know because I've used it in the context of aerospace. That chip is probably one of the beefiest Cortex-M chips around, with 256K SRAM and 1MB of flash, plus a dedicated EEPROM of at least 32K or something. It also has a native Ethernet interface as well the typical accompaniment of CAN, UART, SPI, etc. You can certainly run FreeRTOS on it as well as several others - I've done a fair amount of bare metal programming on that chip.

[cgrey8]

To get the fancy Linux/Java base GUI I would like would require a Cortex A-series, and most likely multi-core and something greater than A72...probably in the A76/78 range. However the realtime stuff could easily make use of a Cortex M-series ASSUMING I was going to control all the AI local to the chip and not attempt to "use" the stock EEC-IV/V as my IO. Using the EEC-IV/V in this way would require I actively communicate with the EEC's processor via its memory interface and accomplishing that is beyond what I would trust even the beefiest Cortex A or R series to do. You need to be hard-realtime for that...such as CPLD/FPGA or a bespoke solution like TI's Programmable Realtime Unit (PRU) Processors.

However on another note, I've gotten some greater insight into the technical architecture of more modern vehicles. I'm going to make an assumption here, but it's been my assumption that in the early days of EEC-V, the EEC was directly responsible for managing/maintaining ALL coms over the OBD-II port.

However that doesn't seem to be the case anymore. The complexity of vehicles has gotten so great that no 1 processing unit is capable of managing all aspects of the system. It seems there are at LEAST a dozen different processors/controllers scattered all over the car, each of which seem to communicate with each other and are accessible, individually, over the CAN network of which the OBD-II port-connected tools have access to.

This would suggest that replacing any one of them with an aftermarket counterpart (e.g. the ECM and TCM) could be done without the other parts of the car being aware as long as the inter-connect messages the OEM modules produced were still being produced on the network. Now if the mfg has proprietary messages that are not standard, those would have to be known about and reproduced as well. And if the mfg did something sneaky like implementing some kind of encryption or component-authentication, any aftermarket replacement devices would have to know how to spoof those authentication messages correctly to keep the other parts of the system satisfied.

What am I getting at? Well it seems that mfgs have decided that they can turn auto repair into a revenue stream by requiring that people that work on cars (professionally or personally) purchase tools, only available from the mfg, and often only available as a subscription service...or at the very least requiring additional funds to get the latest info (inc EVTM & wiring diagrams) on each new year's vehicles. It seems some mfgs want to charge daily or hourly rates to access to online documents like these to VERY specific make vehicles. If these costs get too burdensome for DIYers that just want to work on their own vehicles, I can see people being willing to invest in aftermarket controllers that THEY have control over vs black boxes that they have to pay the mfg for tools to interact with and manage. The most common offender of these kinds of tactics that I hear about in the news are from farmers complaining about John Deere.

Has anybody else run into this?

[cgrey8]

Just a follow-up after many many months since I first wrote up the document about the EEC Whisperer.

It seems the automotive world got far more complex and modular than I realized. When I was thinking of the EEC Whisperer, I was still thinking in terms that there was a "central brain" of sorts that manages and maintains the aspects of the vehicle. But it seems vehicle management is FAR FAR more distributed than that now. Anybody that has connected a robust OBD-II scanner to a modern day vehicle can see that what you get is no longer just a series of codes and a few commands to clear stuff. There's a TON of complexity you get from these tools now, which can vary from make-to-make and model-to-model. I couldn't believe all the calibration and live-data that is now available through standard OBD-II scan tools...and the data update rates are fairly impressive.

It also seems most mfgs have a multi-tier CAN networking setup with at least 1 high speed network.

The high speed network is dedicated to mission-critical modules like the Engine Control Module (ECM) and Transmission Control Module (TCM) in order to keep things like throttle-by-wire throttle changes in sync with shifts. Even if the actual throughput/bandwidth isn't particularly excessive between these modules, what is important is the reduction of latency hence the high speed bus.

Less-critical coms, such as TPMS, Radio, Anti-Theft/Entry Control, Climate Controls, Dash, Steering wheel (buttons and lane assist actuator), and various emissions related monitors (e.g. fuel tank monitors) which produce far less traffic and are not nearly as time-critical can be put on a lower speed CAN bus.

I believe this is also the bus that OBD-II scanners connect to. Although it seems some mfgs have a security module between the OBD-II connection and all other modules, mostly it seems, to limit the cool features to only the dealers and people willing to pay big-bucks for scanners capable of doing module-updates/reflashing.

What I don't know is which of these busses things like collision radar and lane departure modules would reside on. You might assume they need low-latency too, but if all they are doing is flashing lights on the dash or maybe nudging the steering wheel to maintain the lane, these aren't exactly ultra-time sensitive tasks. MAYBE you could argue activating the brakes is? Not sure. If anybody knows, please enlighten me.

If this wasn't enough, even the damn alternator is "controlled" by a computer module vs just being self-contained device like has historically been the case. And to be honest, I kind of understand why. As vehicles get more complex, the output capacity of alternators has gone from a measly 40A (what my 89 Ranger had from the factory) to 200-300+amps to drive all these electronic components. When the alternator needs to run at full-bore, it can put quite a load on the engine and if the ECM isn't expecting a sudden load, it can drop the idle RPMs quite noticeably. To prevent this, the ECM needs to be able to coordinate the alternator load with engine airflow. There also seems to be more battery charge management being done too. I don't know if that is to increase the longevity of AGM batteries or what exactly that is.

Point is, while an EEC Whisperer is still an interesting idea. I'm not sure quite how it fits into this modern architecture of distributed management and computing. One part of me thinks it is far more valuable for an aftermarket tuning management solution to REPLACE the ECM and TCM in order to bypass a lot of proprietary constraints, but still receive/produce the same signals the factory modules did as it relates to coms with other modules. However I don't know how well this will work, particularly given how finicky some new vehicles are to having a bad module replaced, even one from the manufacturer. It's as though some modules in the car have some authentication hand-shake they are trying to perform to authenticate the signals they get from their neighbors. While any system like this can be cracked and overcome, details like this just add yet another layer of complexity to an already overly-complex effort.

And if aftermarket solutions can't make these hurtles trivial (and even the pay-for solutions don't), it's likely to scare most people off like fuel injection scared off people brought up on carburetors back in the 80s.

It's really making a lot of sense why MOST OBD-II scan tools now require a subscription to keep them updated. It's not a money-grab. There is constant and on-going development and complexity that has to be maintained to keep the tools functional...and even then, you find numerous videos of professional technicians that are forced to pay for MULTIPLE scan tool brands because they find one works where others don't, and these are among high-dollar tools. So for anybody that is NOT trying to do performance tuning, just maintain their vehicle, now they have to potentially invest both time and money into understanding the architectural complexities of their vehicle just to do things like replace the rear brakes. Now add in the desire to do performance work. Any performance adder has to include a retuner to retune the computer for the kit being installed. But what if you are performing multiple mods? What are the modern day performance (tuning) solutions people are using? How much does it cost just to enter this realm before buying the 1st piece of upgrade hardware for the engine? How well does it work? How much do you now have to know before you can even made the 1st scalar edit without messing something up?

[86GT]

Chris you hit it on the head. My 2013 F150 has 23 modules that are one of two CAN networks. My 24 Ranger Raptor most likely has way more modules. Ford uses a two network not only for the reasons that you spoke of but for security reasons.

The MS-CAN which is the multimedia CAN. It has the navigation system, radio, door lock and so on. Since the radio and nav are Bluetooth capable there is a possibility of hacking and thus the reason it is not on the same network as the PCM or TCM. This is according to what one of the ford engineers told me. The network speed is also set at 500k not 1 meg. At 1meg there would be to much interference noise. I believe this 500k speed is the same on both networks. I am not sure if the newer trucks like the 24 ranger raptor has faster speeds.

There are things like a CAN Gateway too to help prevent traffic on certain lines. Around the 2015 era there was an introduction of a Body Control Module (BCM). This module was the central point. It has the VIN number and other central things. You can send a signal to the BCM and have all other modules learn the VIN number. This VIN is then written to all modules on the network. I am only scratching the surface and it is way more in depth.

As for the aftermarket PCMs, it would be real hard for them to be used in any of todays vehicles. They would not play nice with instrument clusters, ABS modules, Restraint systems, Lane assist and so on. I think the after market PCMs are going to be mainly used for transplant cars. What i mean by this is vehicles that have had all the tech torn out and are designed for racing. Maybe those vehicles that just never cam with all the tech too..

Just my thoughts.

[Paulie]

Some information out of 2024 Ranger shop manual:

Multiplexing is a method of sending 2 or more signals simultaneously over a single circuit. Multiplexing allows 2 or more electronic modules (nodes) to communicate over a twisted wire pair [data (+) and data (-)] network. The information or messages that can be communicated on these wires consists of commands, status or data. Multiplexing reduces the weight of the vehicle by reducing the number of redundant components and electrical wiring.

The vehicle has 2 module communication networks connected to the remote DLC , located under the instrument panel. The communication networks are:

DIAG1
DIAG2
The vehicle has 6 communication networks that do not communicate directly with the diagnostic scan tool. The GWM translates the messages on these 6 networks and transfers the signals to the DIAG1 and DIAG2 circuits at the remote DLC . Messages communicated on the FD-CAN and HS-CAN1 are communicated to the DIAG1 connection, all other networks are translated to the DIAG2 connection at the remote DLC . The communication networks are:

FD-CAN
HS-CAN1
HS-CAN2
HS-CAN3
HS-CAN4
MS-CAN

FD-CAN is flexible data rate
There is also LINs or local interconnect networks and ethernet networks

[86GT]

Nice I knew it was way more complicated. LOL

I will have to hook my Mongoose cable and see what all responds.

[jsa]

Just a follow-up after many many months since I first wrote up the document about the EEC Whisperer.
.
.
It seems the automotive world got far more complex and modular than I realized. When I was thinking of the EEC Whisperer, I was still thinking in terms that there was a "central brain" of sorts that manages and maintains the aspects of the vehicle. But it seems vehicle management is FAR FAR more distributed than that now.
.
.
Point is, while an EEC Whisperer is still an interesting idea. I'm not sure quite how it fits into this modern architecture of distributed management and computing. One part of me thinks it is far more valuable for an aftermarket tuning management solution to REPLACE the ECM and TCM in order to bypass a lot of proprietary constraints, but still receive/produce the same signals the factory modules did as it relates to coms with other modules. However I don't know how well this will work, particularly given how finicky some new vehicles are to having a bad module replaced, even one from the manufacturer. It's as though some modules in the car have some authentication hand-shake they are trying to perform to authenticate the signals they get from their neighbors. While any system like this can be cracked and overcome, details like this just add yet another layer of complexity to an already overly-complex effort.

Modern distributed systems don't have an old EEC-IV or EEC-V box, so I'm not seeing the connection between a device intended to augment an on old EEC-IV or EEC-V and the modern distributed system. What are you really wanting the Whisperer to do?

I did put forward the idea of bring CAN bus into the whisperer as a 2 way interface. Output so that EEC parameters could be shared with CAN bus gauges, displays and the like. Input so that the EEC could get input from more sensors

There are CAN switch boards that offer point count/$, quite small and can be located where needed.
https://www.canchecked.de/cfe18-can-switch-board/
https://www.ptmotorsport.com.au/product ... -extender/
https://www.ecumaster.com.au/products/can-switch-board
This one has been updated into a sizeable enclosure unfortunately.
https://wiki.autosportlabs.com/AnalogX

Without a 'Whisperer' type device they'd be good for logging with BE if it could be enhanced.

[cgrey8]

I had multiple main intentions.

One big one is for a device that can replace the stock ECM (and probably also TCM) and allow a tuner to tune the engine however he wishes while responding to the rest of the car as though everything is stock INCLUDING appearing stock to an OBD-II connected emissions test. Some of this assumes emissions monitoring is done by the ECM too. However if things like secondary HEGOs are monitored by another module, that'd be another module that would need to be removed and emulated in order to keep the rest of the vehcile's modules happy.

Another is having a consistent and standard platform across lots of different makes/models of vehicles and designing the firmware to be flexible to whatever hardware (i.e. engine) is being controlled. So for instance, older vehicles would have TFI, slightly newer vehicles had coil packs. Most vehicles today have COP (or similar). Most performance oriented vehicles also have some kind of Cam/Valve timing control, so the firmware would need to be augment-able to include those controls when present, and easily exclude them when that isn't present. Ditto for all the other complicated aspects of ECM duties such as fuel pump control, alternator load coordination, etc etc. Since so much of this stuff may be distributed, the firmware would have to be capable of either interacting with its local physical I/O or know to listen for some inputs on the CAN network as well as issuing the outputs on CAN for whatever controller does have direct access to them (e.g. fuel control module).

And one of the biggest was to integrate the control logic in the same module as the UI so that all a tuner needed is a connection (wired or wireless) to the Whisperer with a laptop/mobile device and would be served webpages that do much the same thing as TunerPro or BE/EA including letting the tuner extract and save tune parameters AND learned data to the connected device so these details could be analyzed, restored, or incorporated as "starting points" for future DIY tuning projects. And of course do live datalogging like BE currently does.

That's kind of the pie-in-the-sky hope for such a device as it relates to modern vehicles.

[cgrey8]

WRT to what I mentioned in the 1st post, I was watching the latest Cleetus McFarland episode where they installed a Heliphant (Demon) Hemi into a modified "mini" TRX. And as part of that install, they installed "unlocked" modules from HP Tuners. So it seems my idea of simply replacing hardware without the rest of the vehicle's modules knowing the difference is a technical possibility.

The BIG MILLION DOLLAR question is whether the info HP Tuners uses to accomplish this is from reverse engineering or if it's from inside knowledge given to them from Chrysler.

If its from reverse engineering, then my attitude is if they can do it, someone else in the DIY community with enough time, skill, budget, and determination, could do it too. However if they had (paid for?) access to info and tools from Chrysler that otherwise would not be available to anybody else, then the DIY community is going to have a much harder time.

Another detail I picked up on is the special cable needed to tune it, meaning you don't do it via the OBD-II port. You want much more direct-access to the ECM/TCM than the OBD-II port gives you...just as I suspected you'd want.

The tuner in the video also mentioned having the stock Demon tune pulled from a stock Demon-equipped vehicle. However there were some operating system differences between the computer that donor vehicle uses and the target computer in the TRX. He mentioned there are different operating systems which I hope means something different to him than it does to me. To me, OS refers to platforms like Linux, QNX, FreeRTOS, or VXWorks. However I would hope that Chrysler wouldn't be using different OSs for different ECMs. Different versions, maybe, but completely different OSs? I'm not sure I get why they would do that to themselves.

Regardless, he said the details of the tune are migratable, further supporting my theory that MFGs have moved to an architecture where "the tune" refers more to the configuration data than it does the ENTIRE memory map of the processor like it does with EEC-IV/V. For those not familiar with what an EEC-IV/V tune is, think *.docx file rather than the entire Microsoft Word application AND the contents of your document, which is what an EEC-IV/V tune is.

Does anybody else have any experience with aftermarket tuning solutions like HP Tuners to chime in on details like this?

BTW, that's a give-away mini TRX.

[Craig Moates]

Folks,

Sorry I don't stop in here very often lately, but I wanted to let you know that we're BACK online with hardware in stock and available. Apologies for the absence these recent days (years now)! Same old spot with a little different flavor. We're glad to be here for you again going forward, and if you have any questions, just let us know.

Hope this helps,
Craig

[EDS50]

Folks,

Sorry I don't stop in here very often lately, but I wanted to let you know that we're BACK online with hardware in stock and available. Apologies for the absence these recent days (years now)! Same old spot with a little different flavor. We're glad to be here for you again going forward, and if you have any questions, just let us know.

Hope this helps,
Craig

Welcome back my friend. This is wonderful news for the community.

[jsa]

Folks,
I wanted to let you know that we're BACK
Craig

Welcome back, what's the game plan for the future?