Discrete custom design of RS485 driver

[[email protected]]

http://www.irf.com/product-info/datasheets/data/pb-ir3598.pdf.

Looks promising, though I'm confused as to why they give different source and sink values for the high and low sides, you'd think the two FET pairs would be the same. OTOH I guess that difference could be used to my advantage.

Best way to go on a project like this.

Yeah, I just have to convince them that even though it looks like a step backward, it'll get us forward faster, since I can build test boards that don't have the insane density and collection of hard-to-hand-assemble parts that I have to work with now.

One of the tasks at hand is to minimize this added capacitance.

Yeah, I can clearly watch the effects as I add more units to the bus:

http://colo.omegacs.net/~omega/misc/disable-0to6-stations.gif

In this case I believe the test actually involved simply turning on each driver's RE in turn to increase the number of stations listening. All 6 units were connected and powered on the line during each capture, just the RE'swere different. You can see the leading edge of the waveform becoming unacceptable pretty quickly. I think the point where packet loss became significant was about 7-8 units.

IIRC that was with the max13451.

Neutralizing that capacitance by a regenerative trick might work. If
you do that and it works hand out barf bags before you start the design
review

My boss suggested that without any details, implying that I could receive the signal and have units automatically loop it back. Seems to me the problem is a) there'd be too much latency between the receive and re-transmit, and b) the retransmitted signal might end up causing feedback all over the place.

Or, as I believe someone suggested, a multitone RF protocol. However,
then you need "micro-modems" at each node.

I've got a PLL-driven clock line dedicated to the interface circuit currently unused, but I could use that to drive and sync a multitone protocol if there's any way to get 1+Mbps out of it and fit it on the board.

Nah, solve it and you'll be da hero

Would be nice.

If you get too many of them clustered too close together, yes, they will
load down the line. One trick is to make the transformers wideband,
meaning that they present a very high impedance when not loaded on the
tap-off side yet reach to 5MHz or wherever you need them to go up to. On
a typical transformer the rule-of-thumb is to have the open inductive
reactance at least 4x the cable impedance at the lowest frequency to be
transmitted or received. Here you'd need a lot more.

You just started speaking alien ;-(

That's enough space for a signal transformer. If that 1cm^2 has to
contain the whole transceiver that is a tall order. Almost calls for a
custom IC design.

No, that's just the biggest single space. The board is ~1.13" round with a2x10 2mm connector on top center, the area equivalent of WS2812 'smart' LED to one side of that, and 2x 2x7 0.5mm connectors on the bottom opposite sides. The rest of the board is free for all this stuff, albeit with serious height restrictions. 3mm up and maybe 1.5mm against the parts on the bottom side board.

 

[Joerg]

Looks promising, though I'm confused as to why they give different
source and sink values for the high and low sides, you'd think the
two FET pairs would be the same. OTOH I guess that difference could
be used to my advantage.

It has to do with the IC process. If they make the devices the same size
they will be different in on-resistance because one of them is
p-channel. They could upsize to make it equal but chip real estate is a
cost factor.

One thing to note is that many gate drivers cannot be put into a hi-Z
state on their outputs which makes then not so attractive for RS485.

Yeah, I just have to convince them that even though it looks like a
step backward, it'll get us forward faster, since I can build test
boards that don't have the insane density and collection of
hard-to-hand-assemble parts that I have to work with now.

That's an advantage of being a consultant. I just roll up the sleeves
and build it

Yeah, I can clearly watch the effects as I add more units to the bus:


http://colo.omegacs.net/~omega/misc/disable-0to6-stations.gif

In this case I believe the test actually involved simply turning on
each driver's RE in turn to increase the number of stations
listening. All 6 units were connected and powered on the line during
each capture, just the RE's were different. You can see the leading
edge of the waveform becoming unacceptable pretty quickly. I think
the point where packet loss became significant was about 7-8 units.

IIRC that was with the max13451.

To be honest, I do not see any gradual decay. I'd be surprised if it
happened because normally what matters is the parasitic device
capacitance and that should be independent of any receive enable.

I like this one here:

http://colo.omegacs.net/

My boss suggested that without any details, implying that I could
receive the signal and have units automatically loop it back. Seems
to me the problem is a) there'd be too much latency between the
receive and re-transmit, and b) the retransmitted signal might end up
causing feedback all over the place.

It can work. The trick is to high-pass the feedback so only the sluggish
transitions get spiffed up but the remainder of each high or low phase
remains largely untouched. It requires brief current injections from a
circuit that goes hi-Z after each injection. Use a blazingly fast buffer
to keep the latency down.

Keeping all that from going berserk (oscillations, chain-bucking,
stampeding) isn't a small feat but if it works you are the hero of them
month.

Much of this can be simulated in SPICE but it will take time. It's not
something you can draw up on a napkin while wolfing down a burger and be
done with it.

I've got a PLL-driven clock line dedicated to the interface circuit
currently unused, but I could use that to drive and sync a multitone
protocol if there's any way to get 1+Mbps out of it and fit it on the
board.

It would need to run at several MHz at the least if you need 1Mbit/sec.
That can become tedious if you must run that inside a uC with rather
limited horsepower.

It doesn't even have to be PLL. You can send, for example, two
frequencies around 10MHz but at least 4MHz apart. Lowpass and Schmitt
this, then run the RX signal into a timer which counts the number of uC
master clock cycles between transitions. Average a little for noise
reduction and signal an error if this changes too often. The timer count
would say whether a one or a zero was received.

Would be nice.


You just started speaking alien ;-(

This is kind of hard to explain. An open transformer has a certain
primary inductance, which results in:

Z = 2 * Pi * f * L

where f is the lowest frequency you Manchester code presents to it. The
old rule of thumb for point-to-point transmission is that you want Z to
be 400ohms or higher for a 100ohm line. In you case you'd rather want it
to be 10k or so. That isn't easy but may be possible. One way to start
is to browse

For example, this series fulfills your 3mm height limit and gets you to
about 1k at 1MHz or (theoretically) 10k at 10MHz:

http://www.tdk.co.jp/tefe02/trans_alt_en.pdf

Now the rather high interwidning capacitance might spoil the broth here
but you could buy a few different kinds of such transformers and just
try. It allows you to keep things as differential as possible.

LAN transformers might also work but you'd have to try it out:

http://productfinder.pulseeng.com/products/datasheets/H504.pdf

Just an example, and this is a wider 4-channel. So you'd have to call
them and ask for something smaller. Often you can latch on to a custom
run. I have sometimes done that for the ferrite cores, sort of hitching
a ride.

No, that's just the biggest single space. The board is ~1.13" round
with a 2x10 2mm connector on top center, the area equivalent of
WS2812 'smart' LED to one side of that, and 2x 2x7 0.5mm connectors
on the bottom opposite sides. The rest of the board is free for all
this stuff, albeit with serious height restrictions. 3mm up and
maybe 1.5mm against the parts on the bottom side board.

I don't see the height restriction being an obstacle here, as long as
you can sprinkle parts around.

 

[[email protected]]

One thing to note is that many gate drivers cannot be put into a hi-Z
state on their outputs which makes then not so attractive for RS485.

Right, and I'm assuming putting a silicon switch of any sort in front of itreally won't be of much help on the signal-integrity side.

To be honest, I do not see any gradual decay. I'd be surprised if it
happened because normally what matters is the parasitic device
capacitance and that should be independent of any receive enable.

You're letting it animate? Each frame is an additional receiver. The testwas to determine if the loading of the receive circuit was what caused theproblem, or the power draw of the units. At least for the max13451, it does indeed reduce bus loading by having RE disabled.

Then again that's why I designed my theoretical testbed so I can separate power and data loading...

I like this one here:
http://colo.omegacs.net/

Yeah, it's just kindof a dump space for me, though it does run some other virtual sites.

It can work. The trick is to high-pass the feedback so only the sluggish
transitions get spiffed up but the remainder of each high or low phase
remains largely untouched. It requires brief current injections from a
circuit that goes hi-Z after each injection. Use a blazingly fast buffer
to keep the latency down.

Sounds rather scary...

Much of this can be simulated in SPICE but it will take time. It's not
something you can draw up on a napkin while wolfing down a burger and be
done with it.

I *really* want a SPICE simulation of the bus and transceivers, but haven'tbeen able to get anywhere near something that seems to actually simulate reality. ;-( One of the bigger problems is a lack of any RS-485 transceiversimulations that I can find.

It doesn't even have to be PLL.

I only mention the PLL because it's already there and can give me whatever frequency I ask for. It's already driving the MCU and the main ADC, and had extra outputs...

It would need to run at several MHz at the least if you need 1Mbit/sec.
That can become tedious if you must run that inside a uC with rather
limited horsepower.

You can send, for example, two
frequencies around 10MHz but at least 4MHz apart. Lowpass and Schmitt
this, then run the RX signal into a timer which counts the number of uC
master clock cycles between transitions. Average a little for noise
reduction and signal an error if this changes too often. The timer count
would say whether a one or a zero was received.

Did some digging around, actually think I could fairly easily do OOK with asimple receiver, as per:

http://www.maximintegrated.com/app-notes/index.mvp/id/4439

Would need a differential-to-singleended buffer between the bus and that, but if I can drive a 10-50MHz signal in OOK mode and get a viable digital output from the above, I think I'd be done. Transmit wouldn't have to be complicated, just be filtered enough so it doesn't have square-wave generated nasties.

The trick is I'm already pretty much locked into a UART on the microcontroller board, so doing pulse-counting and such isn't really an option without adding a dedicated microcontroller on the interface PCB.

 

[Joerg]

Right, and I'm assuming putting a silicon switch of any sort in front
of it really won't be of much help on the signal-integrity side.

Oh, it will be. But now you need another device with low on-resistances
and thus lots of parasitic capacitance, plus the space for it. So maybe
some big fat bus drivers with lots of the channels parallele are better
because those can be tri-stated. That would at least get you under
10ohms foer four in parallel, and maybe for the upper two equalizer
stages you only need two each.

You're letting it animate? Each frame is an additional receiver.

Ah, didn't know it animated. In the browser it won't do that but now I
stored it on the PC and ... tada!

The test was to determine if the loading of the receive circuit was
what caused the problem, or the power draw of the units. At least
for the max13451, it does indeed reduce bus loading by having RE
disabled.

Interesting, normally RE only controls the receiver output towards the
system side. The MAX13451 datasheet is not very helpful, doesn't even
mention capacitance.

Unfortunately A and B for RX and TX are tied together on the chip. If
you had one where the bus sides are piped out independently you could
hang RF transistors in front in order to get the bus load capacitance down.

Then again that's why I designed my theoretical testbed so I can
separate power and data loading...


Yeah, it's just kindof a dump space for me, though it does run some
other virtual sites.


Sounds rather scary...

All the good stuff sounds scary in the beginning. A good friend of mine
(and also a client) said once, "The best projects are those where,
immediately after making a claim, you get a serious knot in the stomach".

The MAX13451 is a bit sluggish for this with its 200nsec RX prop delay.
Don't know what else they have since I never use Maxim chips. But, just
as an example, this one is already twice as fast:

http://www.ti.com/lit/ds/symlink/sn65hvd72.pdf

These are blazingly fast and have very low input capacitance, I'd try
something like that:

http://www.linear.com/docs/1001

Here's where your test bed would come in real handy.

I *really* want a SPICE simulation of the bus and transceivers, but
haven't been able to get anywhere near something that seems to
actually simulate reality. ;-( One of the bigger problems is a lack
of any RS-485 transceiver simulations that I can find.

Ask Linear Technology if they have a model or even a jig for one of
their fast RS485 chips. They also got 60V fault-tolerant ones. Sometimes
only IBIS models though :-(

Else you could just take the capacitances and see if you can find
similar FETs to drive it. As soon as you can corroborate the effect in
your animated scope plots you are in business. Then you can try the
various measures, see how much each buys you.

I only mention the PLL because it's already there and can give me
whatever frequency I ask for. It's already driving the MCU and the
main ADC, and had extra outputs...

Sometimes they aren't very versatile or fast though.

Did some digging around, actually think I could fairly easily do OOK
with a simple receiver, as per:

http://www.maximintegrated.com/app-notes/index.mvp/id/4439

Would need a differential-to-singleended buffer between the bus and
that, but if I can drive a 10-50MHz signal in OOK mode and get a
viable digital output from the above, I think I'd be done. Transmit
wouldn't have to be complicated, just be filtered enough so it
doesn't have square-wave generated nasties.

I'd be careful. OOK is very prone to distrubance by noise, spikes and
transients. If you use a nice bandpass filter and can make sure that it
will always be quiet within the range of that bandpass it can work ok.
Tough to find off-the-shelf ones in the 30-80MHz range anymore, on
account of TV sets having gone digital.

The trick is I'm already pretty much locked into a UART on the
microcontroller board, so doing pulse-counting and such isn't really
an option without adding a dedicated microcontroller on the interface
PCB.

Ok, that rules out nearly all unorthodox stuff.

I'd first try with some of the more modern (as in faster) RS485 driver
chips.

 

[Klaus Kragelund]

Looks promising, though I'm confused as to why they give different sourceand sink values for the high and low sides, you'd think the two FET pairs would be the same. OTOH I guess that difference could be used to my advantage.






Yeah, I just have to convince them that even though it looks like a step backward, it'll get us forward faster, since I can build test boards that don't have the insane density and collection of hard-to-hand-assemble parts that I have to work with now.






Yeah, I can clearly watch the effects as I add more units to the bus:



http://colo.omegacs.net/~omega/misc/disable-0to6-stations.gif



In this case I believe the test actually involved simply turning on each driver's RE in turn to increase the number of stations listening. All 6 units were connected and powered on the line during each capture, just the RE's were different. You can see the leading edge of the waveform becoming unacceptable pretty quickly. I think the point where packet loss became significant was about 7-8 units.

Very nice animation. But, I cannot see why you are worried that is looks "ugly". As long as you have minimum 200mV A-B with additional margin, you arewithin bounds

Cheers

Klaus

 

[[email protected]]

Very nice animation. But, I cannot see why you are worried that is looks "ugly". As long as you have minimum 200mV A-B with additional margin, you are within bounds

Two reasons:

- the "sag" at the edges gets worse, and longer. My target is more like 25-50 units, not 6. <200mV is only a few units further along.

- at least with the transceiver that was done with (iirc max13451), those sags turn into spurious transitions, which blows the UART out of the water.

 

[[email protected]]

Oh, it will be. But now you need another device with low on-resistances
and thus lots of parasitic capacitance, plus the space for it. So maybe
some big fat bus drivers with lots of the channels parallele are better
because those can be tri-stated. That would at least get you under
10ohms foer four in parallel, and maybe for the upper two equalizer
stages you only need two each.

Yeah, and that gets back to my original idea of being able to filter each of the stages separately and mix&match as needed.

Unfortunately A and B for RX and TX are tied together on the chip. If
you had one where the bus sides are piped out independently you could
hang RF transistors in front in order to get the bus load capacitance down.
Here's where your test bed would come in real handy.

I've got a board designed for standard RS-485 testing with 2 half-duplex 75176 sites, 1 full-duplex SOIC-8 site, and a 75180 SOIC-14 full-duplex site.Each transmit and receive chain can have its own separate capacitive coupling or be tied to a single bus, and I can zerohm any combination of transmit and receive I can come up with.

Sometimes they aren't very versatile or fast though.

This one's a TI CDCE949 packaged with a matching crystal (sadly no longer in production, so I've got to go discrete soon). I can spit just about any frequency I could possibly want up to 230MHz, and one of the 4 PLLs is entirely dedicated to interface.

I'd be careful. OOK is very prone to distrubance by noise, spikes and
transients. If you use a nice bandpass filter and can make sure that it
will always be quiet within the range of that bandpass it can work ok.
Tough to find off-the-shelf ones in the 30-80MHz range anymore, on
account of TV sets having gone digital.

The appnote also mentioned ASK, which is just a different threshold for thepower detector. That would eliminate some of the issues wouldn't it?

Ok, that rules out nearly all unorthodox stuff.

I guess I should be more specific: I'm stuck with a UART, but I've got the rest of the 'port' plus a shared I2C bus to work with. An Xmega port has 8bits, 2 timers with 6 PWM/capture, 2 UARTs, 1 SPI, and sometimes an I2C (depending on which port it is).

I'd first try with some of the more modern (as in faster) RS485 driver
chips.

My boss's theory was that the faster the edge, the more likely it was to "bounce" and produce the sag seen in the animation.

 

[Joerg]

]

Unfortunately A and B for RX and TX are tied together on the chip.
If you had one where the bus sides are piped out independently you
could hang RF transistors in front in order to get the bus load
capacitance down. Here's where your test bed would come in real
handy.

I've got a board designed for standard RS-485 testing with 2
half-duplex 75176 sites, 1 full-duplex SOIC-8 site, and a 75180
SOIC-14 full-duplex site. Each transmit and receive chain can have
its own separate capacitive coupling or be tied to a single bus, and
I can zerohm any combination of transmit and receive I can come up
with.

Then you can also try and see how it looks with two emitter followers in
front of the RX. Just for a test.

This one's a TI CDCE949 packaged with a matching crystal (sadly no
longer in production, so I've got to go discrete soon). I can spit
just about any frequency I could possibly want up to 230MHz, and one
of the 4 PLLs is entirely dedicated to interface.

That is, of course, the deluxe method. Sure it's discontinued? Doesn't
says so on the datasheet or Digikey.

The appnote also mentioned ASK, which is just a different threshold
for the power detector. That would eliminate some of the issues
wouldn't it?

Yes, but not nearly as well as FSK would.

I guess I should be more specific: I'm stuck with a UART, but I've
got the rest of the 'port' plus a shared I2C bus to work with. An
Xmega port has 8 bits, 2 timers with 6 PWM/capture, 2 UARTs, 1 SPI,
and sometimes an I2C (depending on which port it is).

Each port? So then we do have a timer to work with. That could open up
an FSK option provided an XMega is fast enough. All I know so far are
ATMega, I am not really a uC guy.

My boss's theory was that the faster the edge, the more likely it was
to "bounce" and produce the sag seen in the animation.

He is correct. But one could, for example, make sure that the signal
gets filtered at the end of each high or low phase. What this requires
is a clock recovery by the XMega so it knows where to sample.

Looking again at your animated scope plot it becomes apparent that
capacitance is the problem. There is a break in the middle and as more
devices come online you can see the slope increase in that stretch,
where the purple signal is low. If you could reduce the input
capacitance that should improve things a lot.

 

[Joerg]

Two reasons:

- the "sag" at the edges gets worse, and longer. My target is more
like 25-50 units, not 6. <200mV is only a few units further along.

- at least with the transceiver that was done with (iirc max13451),
those sags turn into spurious transitions, which blows the UART out
of the water.

Another idea. I know it's nashty nashty:

Place inductors in series with A and B to each transceiver. They'll
resonate a bit with the parasitic capacitances and can act as a
"peaker". Start with 2.2uH each. Go higher if not enough but watch that
no abs max values get exceeded, especially if something comes off.

 

[[email protected]]

That is, of course, the deluxe method. Sure it's discontinued? Doesn't
says so on the datasheet or Digikey.

It's the combined package, the Pletronics FD77T that's discontinued. I getto try to fit the chip and a crystal on the next rev of board, and hope I can find a crystal that actually gives me the pull range I get from the matched part.

Yes, but not nearly as well as FSK would.

But FSK would require discriminators for both frequencies. If that can be done in a small space, it seems reasonable. In particular the PLL is capable of switching its config registers on an external input, so I could tie the UART Tx to that control and have the PLL switch between two frequencies easily enough. (albeit with a rev of the other boards in the stack...)

Each port? So then we do have a timer to work with. That could open up
an FSK option provided an XMega is fast enough. All I know so far are
ATMega, I am not really a uC guy.

If I ran a counter from a peak detector, I'd still have to sample it at some useful point, which could be hard to track down. Otherwise I'd have to perform the frequency-counter work at a reasonable UART oversampling rate, e..g. 8x or 16x. That would very severely limit the functional baud rate.

I suppose a CLPD could be programmed with a similar arrangement, counting cycles between peaks and setting its output based on a threshold (1/f), capable of directly feeding the UART.

Looking again at your animated scope plot it becomes apparent that
capacitance is the problem. There is a break in the middle and as more
devices come online you can see the slope increase in that stretch,
where the purple signal is low. If you could reduce the input
capacitance that should improve things a lot.

To what degree does the value of the series coupling caps matter?

I'll look into the ltc1685 you mentioned before, since you said it looks tohave lower input loading characteristics.

 

[Joerg]

]

Yes, but not nearly as well as FSK would.

But FSK would require discriminators for both frequencies. If that
can be done in a small space, it seems reasonable. In particular the
PLL is capable of switching its config registers on an external
input, so I could tie the UART Tx to that control and have the PLL
switch between two frequencies easily enough. (albeit with a rev of
the other boards in the stack...)

That would take care of the TX side. Although it can be done simpler by
using a counter. The frequency doesn't have to be very exact.

If I ran a counter from a peak detector, I'd still have to sample it
at some useful point, which could be hard to track down. Otherwise
I'd have to perform the frequency-counter work at a reasonable UART
oversampling rate, e.g. 8x or 16x. That would very severely limit
the functional baud rate.

The sampling would be the counter output at each peak. Say, the counter
ran at 32MHz or whatever you have. When the signal sits at 5MHz you'd
see 6-7 counts between detected peaks. Assume the other signal is 12MHz,
there you'd only see 2-4 counts. One represents high, the other low.
Sort of a poor-man's FSK decoder. The uC would have to stuff the result
of this determination back into the UART, hoping there is a path to do that.

It would be good to lowpass the signal somewhere, maybe 20MHz, so that
odd reflections won't produce any extra counts. Even simple RC filtering
might work.

I suppose a CLPD could be programmed with a similar arrangement,
counting cycles between peaks and setting its output based on a
threshold (1/f), capable of directly feeding the UART.

Yep, but if the port already has counters why not use them?

To what degree does the value of the series coupling caps matter?

This seems to be the capacitive load between A and B that increases with
the number of stations. It's not in series.

I'll look into the ltc1685 you mentioned before, since you said it
looks to have lower input loading characteristics.

Yeah, would be nice to have a simple solution if possible.

 

[[email protected]]

[possibly dupe response, not sure if my first attempt actually posted]

That would take care of the TX side. Although it can be done simpler by
using a counter. The frequency doesn't have to be very exact.

But it's handy ;-) Although if I end up using a CPLD I'd probably use the PLL as a master clock and generate from there, since that would remove the need to change anything on the existing microcontroller PCB.

The sampling would be the counter output at each peak. Say, the counter
ran at 32MHz or whatever you have. When the signal sits at 5MHz you'd
see 6-7 counts between detected peaks. Assume the other signal is 12MHz,
there you'd only see 2-4 counts. One represents high, the other low.
Sort of a poor-man's FSK decoder. The uC would have to stuff the result
of this determination back into the UART, hoping there is a path to do that.

Problem is, there really isn't. There are frequency-counter modes available, but stuff still has to go through the registers. I'd have to have a second timer fire an ISR to read and reset the edge counter, threshold it, andoutput it to a pin (looped back into the UART). To do that for 1Mbaud with 8x oversampling I'd have 4 clock cycles to do that in, which is how much time it takes just to *start* running an ISR.

Yep, but if the port already has counters why not use them?

If they can be arranged to work properly, sure ;-)

 

[Joerg]

[possibly dupe response, not sure if my first attempt actually posted]

That would take care of the TX side. Although it can be done simpler by
using a counter. The frequency doesn't have to be very exact.

But it's handy ;-) Although if I end up using a CPLD I'd probably use the PLL as a master clock and generate from there, since that would remove the need to change anything on the existing microcontroller PCB.

The sampling would be the counter output at each peak. Say, the counter
ran at 32MHz or whatever you have. When the signal sits at 5MHz you'd
see 6-7 counts between detected peaks. Assume the other signal is 12MHz,
there you'd only see 2-4 counts. One represents high, the other low.
Sort of a poor-man's FSK decoder. The uC would have to stuff the result
of this determination back into the UART, hoping there is a path to do that.

Problem is, there really isn't. There are frequency-counter modes available, but stuff still has to go through the registers. I'd have to have a second timer fire an ISR to read and reset the edge counter, threshold it, and output it to a pin (looped back into the UART). To do that for 1Mbaud with 8x oversampling I'd have 4 clock cycles to do that in, which is how much time it takes just to *start* running an ISR.

Yep, but if the port already has counters why not use them?

If they can be arranged to work properly, sure ;-)

That looks like the usual scenario. A uC has all the bells and whistles
but they can only be linked to over here, not over yonder. And not on
Sundays.

That would leave the sledge hammer method, pressing some sort of PLL
chip into service. For example, if you feed it 8.5MHz or so from a
counter (any counter) in the uC on the clock input and then the bus
signal on the RF input you could use 5MHz for space and 12MHz for mark.
Or something like that. The old 74HC4046 usually goes to around 15MHz
but only at 5V supply. But there are better ones.

Figure 14 here has another interesting method:

http://www.ti.com/lit/an/scha002a/scha002a.pdf