This is for Stu, Mark, Hugo, and Patrick... but mostly Hugo and Patrick.

In my testing of someone else's Empeg this weekend that was having problems with the I2C fan controller I sold him.. I realized I also had the same issue lurking in my empeg. (In fact, hooking my scope probes made the problem occur fairly consistently.)

I was testing the I2C bus with my Agilent MSO6000 and realized (I didn't think of it before) that the pullup on SDA is way too big (100K). So, I made both units use a smaller (5.1K) resistor and both units work great now... I didn't drag out the specs for the CPU as I figured a 1mA pull-up current would be "ok".

I didn't change the one on SCL because it's obvious that line is being driven rail-to-rail... so the 100K is fine for any idle states where the SCL driver isn't set for output.

I wanted to get your opinion as to this change and alert other users in case they have issues with the I2C bus in their Empegs.

-Ben

p.s. I have lots of scope pics in case you'd like to see both before and after the change.

I would agree that 100k does sound a bit high. I would use 10k as a starting point (befor considering any other reasons to go up or down).

It should only really be a problem if there is a lot of capacitance on the line. Of course, adding a CRO probe will be adding some more capacitance to that but it should be relatively insignificant.

Perhaps something else wasn't playing ball originally? The main reason I can think of is perhaps it something couldn't sink enough current.

Or perhaps something has introduced some capacitance to this particular empeg?

I2C has pretty solid requirements so normally this problem shouldn't ever happen.

no, current sink looks great. nice and sharp. It's the pullup rise-times that show a lot of slope.

And I agree about the I2C requirements. So that's why I put in the different pullup. I had risetimes (measure 10-90% by my scope of around 25 and 26uS. Way too long.)

With 5.1K they are a lot like they should be. (I didn't measure since I compared against SCL's needed times and they look fine.)

-Ben

Mmm.. so perhaps I *should* increase the rise-time allowance when the empeg is driving SDA high?

I think the s/w currently allows 15usecs+ for that; I suppose we could bump it up by another usec or so ?

Ben, let me know what you see on your scope with v505+.

Cheers

I will. I should be able to get to it later tonight.

Thanks for all the coding though Mark. I do appreciate it.

-Ben

p.s. And anyone else who still wants to add a fan to their Empeg. I do have more of these little boards.

There seems to be only one 100pf capacitor between SCL and GND on the Mk2a, plus whatever the traces themselves add.

-ml

How did you measure that?

Don't forget the input capacitance of the pins on the 2 devices. (and the wiring we need to add to get the fan controller hooked in)

It definitely adds up -- and 100K is pretty big. That's 50uA of pullup current.

I'm back with tests... the weird "pre-start" condition of SCL is now gone... Thanks for the effort Mark!

For all of you though, here are some stats:

100K Ohm resistor ends up being anywhere from 25-35uS of pullup time on the SDA line. This equates roughly as 27Khz to 40KHz xfer rate. Ouch. I'm not sure how this worked before as Mark's code generates a hi-low time of about 1.3uS and 2.6uS. Basically, the clock "frequency" is about 280Khz right now.

With my 5.1K resistor installed, I have a pull-up time of 1.9uS, so there's plenty of setup time before clocking in the next bit.. I don't have such warm fuzzies about the stock configuration.

So I thought I would mention it to you guys here. I'm kinda surprised the things on the bus are happy at all. No wonder I was seeing the "fan control error" messages I was.

I have lots of screen shots off my scope if anyone is interested in seeing before and after "pics".

Cheers,

-Ben

It may be asking a lot, but..

Ben, could you put that 100K resistor back in there and double-check the rise time with 505+ ?

I'm thinking of releasing it as v506, but would like to have an idea of the margin available first. I suppose I could measure it here, but the table is already full of other stuff demanding my attentions.

Cheers

I did measure it - but didn't take scope shots with the measurement on. I'll send you some PNG's of those..

Either way, I would be happy to do it again... good thing I didn't put it back together yet!! hahahaha...

I'll have measurements tomorrow night since I'm ready to hit the sack soon.

But I'm happy to do it for ya.

-Ben

Great!

Ben has measured the timings again on his wonderous scope, and sent me the attached capture (below) of an I2C transmission.

Based on that, I've now added an extra microsecond to high pulses of SDA, giving it more rise time. But I've also fixed the low pulses to be *much* quicker, as they hardly need any time at all to transition.

Hijack v506 is now released with the I2C rework completed.

Cheers

I was saying that perhaps that's why the pullup was weak (i.e. 100k) i.e. something couldn't sink enough.

Again though, that would be a pretty poorly designed I2C device if it was.

To me, it just looks as if PCA plugged in something that worked (100K), and then just left it alone. They didn't have a good scope at the time to double-check things like this. And with lots of other stuff to deal with, it then got lost in the shuffle.

No big deal. It works.

Cheers

Mark, with the ones I just sent, feel free to post a comparison with the 5.1K installed (PNG's with "good" in the name).

Shonky, if I may humbly offer the correction;

100K in this case "sources" current. I2C is an open-drain bus where open-drain typically denotes that the device sinks on demand while the pull-up resistor sources the needed current/voltage to bring the bus to V+. (I know you know this. My fingers tend to type things I wasn't thinking too. It's like they are on autopilot. )

Anyway - changing to 5.1K works great. I'm guessing that whatever it mastering the I2C lines (whether it's a transistor for 3.3->5V conversion or the strongArm itself, it has to be able to sink current like any I2C bus device might.The DS1721 is specified by what voltage is measured on SDA at 2 current level. 3mA (0.4V) and 6mA (0.6V). I would guess that 1mA would be fine for all as achieved by 5.1K.)

Soooo...

Anyway -- let me know if I'm smoking too much of my own product.

Talk to yaz,

-Ben

Yep and I'm saying a device on the bus possibly couldn't sink enough current to pull the SDA sufficiently low - so the solution was possibly a weaker pull up. It is still strange though.

This then results in the slow rise times you have seen when whichever device stops pulling SDA low.

We're talking about the same thing but you're talking about the effect I think whilst I'm thinking of the cause.

Yea, I can't see why - I'd have to read the I2C specs again, but I think any device to meet the 100KHz, 400KHz specs would have to be able to sink some given amount of current for a bus length of X....

So yea, it's weird that it ended up being 100Kohms.

Anyone know how many devices are on the bus? I can only think of 2.

-Ben

Damn, all the skeletons are coming out of the cupboard now

Yeah, this should have been 10k (or even less). We didn't own a scope at the time this was designed hence the issue was never actually seen (ie we never looked at it, and the original software had very long bit delays in the i2c driver). To mitigate at least part of the problem, we have a shorter delay if we're sending a zero bit.

edit: At least, that's how I remember it. Did you see that in the code, Mark? Really, adjacent 1 bits being sent in a row only need a delay for the first one too.

Once some units had shipped with this then it was kinda not worth fixing - that and we didn't really do anything that was very urgent on i2c throughput.

The 100pF caps were recommended by Philips to reduce any audio coupling from the falling edges.

Hugo

Yup, that's how it (still) works today. Very long delay for 0->1 transitions, very short delay for anything else, which also now includes 0->0 and 1->1 non-transitions.

The time-critical part is that much of this runs with interrupts disabled, so we don't like to take any longer than necessary inside there. I've also added a usage semaphore to protect against multiple tasks trying to use it simultaneously, which only really happens when a fan controller is present.

Cheers

Is this what would prevent my getting a "Fan control error" message about once out of every 20 times I boot up my empeg? (I am running an older version (#487) of HiJack.) Being of the mentality "If it ain't broke don't fix it", I haven't updated it in a long time.

tanstaafl.

Ahh.. the "fan control error" is the topic of this thread: the pull-up resistor value being a tad high. The latest Hijack tries to improve the timing somewhat in light of that, and would probably help your player.

Assuming, that is, that your player actually has had a fan/controller installed into it? Otherwise, you should delete the fan_control=1 line from the player's config.ini file!

Cheers

Otherwise, the answer is "yes" -- I was having the same problem... with my empeg on hijack v479 and I was installing a fan controller into another empeg when I really saw the problem during testing.

So I dug a little.. and poof! Hugo has answered the question.

There's one of 2 ways to fix the problem:

1: Software (which Mark has done)
2: Hardware (which I have done) - even though the firmware doesn't use the I2C bus at full speed. It makes me feel better anyway.

-Ben


p.s. Hey Hugo, thanks for your input! Feel free to send me your proto's next time and I'll test 'em!

Mmm.. I suppose I ought to have hijack stretch the 0->1 timing even more when a fan controller is actually installed, but leave the current quicker timing otherwise..

-ml

Well, if you do that, I'll break with tradition and update my hijack kernel (yes, I do have a fan and controller).

FWIW, my fan didn't really help my overheating problem. The only time I overheated was when the weather was really cold (Alaska) -- like 10 below zero or colder. This meant I had to run the defrosters at full tilt to keep the windshield clear, and the empeg is mounted in a dead-air space in the dash with the main defroster ducts running close by. When the empeg got hot enough to turn on the fan, it was just blowing air through it that was at least as hot as the empeg, and shortly the overheat alarm would sound. I could cool it down pretty darn quick by pulling it out of the dash and holding it out the window as I drove. About 30 seconds of that (don't try this at home, kids, unless you're wearing gloves) and I could pop it back into the dash for another half hour or so. Gee, I wonder how much I'm going to miss Alaska once I'm living in Mexico?

tanstaafl.

Edit: If anyone cares (not that there's much reason that anybody should care) I have posted a slide show of my Mexican condominium here on Shutterfly. (Click on the full screen icon near the upper right of the picture frame to get the best effect) Hmmm... bug in Shutterfly's UI. When I go to full screen, the pictures don't advance automatically. Just click anywhere in the picture and it will advance to the next. YMMV.

db

Three cheers for extreme thermal cycling of winchester drives. How often have you needed to replace your hard disks now?

To the best of my recollection, all my drive replacements have been to increase capacity. I don't think I've ever had a drive failure. I went from a 10 to a 40, then to dual 40s, then to dual 80s.

tanstaafl.

i was the one who had my fan controller checked by ben...

what resistors was it that mine had changed to? and can i safely upgrade hijack?

Sure, no harm or issues whatsoever.

:-)

some should put the beuty back in production