[Cantedvalve]

I bought some 18MHz crystals based on a few racers who stated that they had upgraded their crystals to allow revving above 7000 RPM.

Really? How does this work?

[cgrey8]

I split this off from the original topic since it's a subject all on its own.

As for doing this, I've only heard about doing this. But it sounds interesting. I would be concerned that you'd be overclocking the RAM. The processor is probably good to go to be overclocked that much. But the RAM chip may have issues running faster than rated. I don't know.

You'd also need to adjust stuff in the tune to compensate for a faster clock rate. Some things are time-based and if you don't update the code to realize it is executing faster, the timers will expire sooner than expected and either trigger things to happen sooner than they are supposed to OR will timeout before they are supposed to. It wouldn't be good to have your Injector PWs being calculated out to a certain MS, datalogging as that amount, but really firing 20% shorter intervals. Or the TFI com line pulsing-out faster and thus being interpreted wrong at the TFI end and applying the wrong spark advance.

[Cougar5.0]

I still have those crystals sitting around collecting dust.

I pointed out in the other thread here that sailorbob claims that there is at least one constant that must be changed to allow for proper RPM logging. Since my main reason for doing this isn't to be able to rev higher, but to get more data at higher RPM's, I wouldn't consider upgrading the crystal without being able to change this constant (I assume this can be done based on your work with FN1360, more of a "where is it" issue I would guess.) Several people claimed to have done the upgrade (I linked to a thread on HC50 in the original post) successfully, though I would want to do it on an extra ECU I had, not my only unit.

[my8950]

I was curious of this too, long ago. I had a friend who was running pure street NMRA and said he had something like this done. He didn't know enough about it, just that he had a crystal installed and now can turn it higher. MW/Mike Wesley did it for him, but if you know of him, you'll also know he doesn't really talk much.
Currently at this time I was working at Accel with the Gen 6/Gen 7. I figured I'd ask my co-worker about it because it sounded interesting. Next thing you know, they are changing the hardware, I am installing 16MHz Xtals and removing the 8's. It made a world of difference, and if anyone here is familiar with the Gen 7 stuff, when v3.2 came out, that was the change. I never got any info, and wasn't really told anything about it. I dropped the idea, he listened and took off with it. I was pretty pissed that nothing was mentioned about it again after that, but the idea I gave basically changed the world for them.
Anyhow, I have no real input here other then I have also heard of it, and am still interested to learn more about how the old EEC works....

[SonicBlue85]

I have changed the 15 MHZ crystal out for a 18 MHZ crystal in my A9P and an A9L. I posted a question as to why my engine would shut off when I took it to 7100 rpm, if I stayed below 7100 rpm, I had no problems, if I took the engine to 7100 rpm it would shut off. I tried just about everything I could dream up, asked many people about the problem, for a few years I did not get the correct answer. I finaly posted the question on one of the tuning forums, after the usual bad info, two people posted up info on using a higher frequency crystal, I questioned one of the two, got the info I needed. Then found some 18 MHZ crystals, replaced the crystals in one of the two ECMs I had. Then reinstalled that ECM. The car ran like crap at lower rpms, I changed a few things in the tune, took it out for a test drive, found a road that I could open the car up on and hit the throttle. Once the car got past about 3000 rpm, it took off, it went to 8000 rpms with no problem. It took a little time to sort out the tune, but was not that bad, it was worth it, I have since modified my other ECM with an 18 MHZ crystal. The engine is a N/A 364, has 3.4 stroke with a 4.130 bore, it had a C4 with a 5100 rpm convertor, it is about to get a Jerico. Before replacing the crystal, I was only able to make about 422 hp at 7000 rpm, since then I have gotten the engine to 460 hp at 7500 rpm and it continues making the 460 hp out to 8000 rpm and I did not change any engine parts. So the mod was worth it for me. One of the nice side benifits is my data logs are much better, previously the data logs would stop somewhere between 5800 to 6200 rpm, I had to gess what numbers I was getting afterwards. Now I get much more accurate data logs without the big jumps in rpm between samples, it records as high as I take the engine. The rpms are lower than actual engine rpm, the higher the engine rpm, the farther off it is. The computer thinks the engine is at 6400 rpm when it is actualy at 7500 rpm, to give you an idea of how far off it gets. Another problem I have had is the ECM runs hotter than it used to, I may install a cooling fan to blow air through the ECM to keep it cooler or across the ECM.

[cgrey8]

I think there are some settings in the tune that you can change to compensate for the faster chip and thus get your RPMs and other time-related calculations correct. But I just don't know them off hand. Send an email to sailorbob and see what he thinks. I bet he'd know what needs to be altered. If you find out, let me know and I'll note it in the def file what values to set for an 18MHz crystal replacement.

[Cougar5.0]

Well, now that's exactly the kind of feedback I've been waiting for. So it works as one would expect, now we just need to be able to change the appropriate settings so MAF & other parameter will calculate correctly & datalogging will be accurate.

[SonicBlue85]

I asked sailorbob, he did not know what needed to be changed to get the rpm reading correctly. I have been told the '94-'95 5.0 computers use a 18 MHZ crystal, I have not have one to check so I can not verify this. If so, comparing Scalars from both a fox computer and a SN95 computer may be the way to find out what to change and what values to use.

[PeteCleary]

I know this post is a bit older but thought I'd pop it up. I'm wondering what needs to be modified for a crystal change.
I've been looking around and not really found any workup of what people changed to get things to run ok (or if that's still an issue).

Any hints, tips or tricks would be apreciated!

-Pete

[mpaton]

I know this post is a bit older but thought I'd pop it up. I'm wondering what needs to be modified for a crystal change.
I've been looking around and not really found any workup of what people changed to get things to run ok (or if that's still an issue).

Any hints, tips or tricks would be apreciated!

-Pete

I understand that this hint is quite accurate, and at the same time probably completely unhelpful.

With a crystal change, you need 2 things. You need to know that the hardware can keep up, as you'll be running it faster than it was tested to work.

You also need to make sure the software still produces the intended effect.

When you overclock your PC, you don't overclock the real time clock because that's a separate clock.

When you overclock your EEC, there is only a real time clock, so you've changed the conversion factor between time, and clock ticks. The programming already had a conversion factor, and now it's wrong.

For a definitely incomplete list, look at the strategy docs for "stcf" and "FREQ18".
At least these values would have to be changed. And they're all over the code, not just in one place.

[PeteCleary]

Mpaton, thanks for the detail. Not necessarilly unhelpful...
I did get some feeback from Adam (Bender460) on his experieces using the crystal mod mainly for OL fuel.

I understand what you're saying here... I did some realtime embedded stuff in the past with limited resources.

So I am taking it that basically there's not much brought out into known (ie. BE common scallars). To really get to the root of it would be to go through the code to do some fixups on the constants used. That and maybe even some fix ups to slow access for slower hardware would be needed. There was some hope someone blazed this trail before :)

I've not honestly looked at the code for the EEC. I'll have to see what it looks like if only to gray up some more hair lol. Definately a newb to that processor and architechure.

[cgrey8]

I've wanted this functionality in the GUFx stuff for quite some time...ever since there has been interest in doing the crystal change. However I haven't gotten much support from others that can read the code better than I to find all the places that need to be corrected to compensate for an 18MHz clock where the code originally expected 15MHz. If someone does look into that, I'll be glad to add it to the defs. And from what I understand, BE does support the concept that a value can reside in multiple places in the tune and those instances should be adjusted/changed together. The catch is BE assumes that all instances will be the same sign, size, and convert using the same equation. If there are instances that break this, then that would require that there be multiple scalar entries for each difference, and the comments will just have to document those issues accordingly. With real world examples, it's also possible Clint and I can work to find a more elegant solution IF this ends up being the case. But for now, I don't have any volunteers to scrounge the code looking for clock constants that need to be updated.

Add to that, demand for 18MHz hardware upgrades has been relatively low. It seems too easy to just upgrade the EEC to one that wholly supports faster clock rates than to try to hardware-hack an older EEC to overclock it. Add to that, there just aren't that many engines that spin up past 6500 RPMs to need this. There are some out there, just not many and the budget behind those projects are often deep enough to justify/demand hardware more fitting for the task.

[PeteCleary]

Understood Chris (hope I got that right). I'm not 100% I'd be a good volunteer candidate... I might look but cannot be sure I'll be any good re: time and experience (vs. people who've been looking at this code for a long time). I'll be looking at it a bit before spring arrives here in the GWN in any case.

I'm in a boat of my own making... I decided on the QuarterHorse/BE/EA direction then changed plans a bit. I might try to live in the 7100-7200 limits some have found the standard crystal goes to. I still have to see where the cam will go to with supercharging (just maybe nice to be able to go 7500-7800 safely)... that might push me to figure out next steps.

[PeteCleary]

One dumb question :)

Is there a disassembled listing out there with the comments - a current understanding of the code so to speak?
I know some pople may have their own stuff they keep for their own businesses but just wondering if there's anything publically available.

(I have some of the publically info and programs at the moment.)

[PeteCleary]

I guess I'm asking for a lot here. I would have thought there was disassembled listing out there. (I've not turned up anything in searches other than some tools.) Oh well.

Just an out there question - Is there a legal problem with this?

[PeteCleary]

For someone who might have the same interest here's a link that I found that may help.

http://www.austincc.edu/cloud/tc_eec.htm

[gmkillr]

Im actually going through something like this and from the sounds of it a crystal upgrade would benefit me.

Im shifting my car at 7500 with the stock EEC-V J4J1 computer with a sct chip in it.

When i shift the car theres a major hesitation (as if the car shuts off) and then it resumes accelerating.

The car pulled on the dyno to 7700 with no issues so im curious to know if this is my issue or if it lies elsewhere....?

Any help or suggestions fella's?

Here's a video of what my car is doing.

Lots of work ahead of me and I will gladly take any and all suggestions!

http://www.youtube.com/watch?v=-BAO7UFue3s