Resonator Tolerances. Higher Tolerance Pairs or matching?
dkemppai
Posts: 315
Hi Guys,
I'm finding that the resonators I'm using (Stock standard 50Mhz units)
are not very closely matched. However, I'm finding that I need them to be closer matched than they are.
Is anyone aware of any resonators that are very closely matched in frequency,
or other·good frequency sources·that are very closely matched. Also, the sources cannot be fragile. (crystals are too fragile for my application). Resonators
are my only real good option.
-Dan
·
I'm finding that the resonators I'm using (Stock standard 50Mhz units)
are not very closely matched. However, I'm finding that I need them to be closer matched than they are.
Is anyone aware of any resonators that are very closely matched in frequency,
or other·good frequency sources·that are very closely matched. Also, the sources cannot be fragile. (crystals are too fragile for my application). Resonators
are my only real good option.
-Dan
·
Comments
You could sort through them and pick ones that are closest.
They do make "high-shock" xtals, I don't know if they would work.
The only other thing I can think of is a SAW oscillator.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
Available now... SX-Video OSD module $59.95 www.sxvm.com
"I'm a man, but I can change, if I have to, I guess"
Red Green
·
for G's that are orders of magnitude less than my application...
I may end up building a hardware PLL on one of my devices, to allow it to lock
onto the clock of the other one. A project I'm not looking foreword to...
-Dan
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10
if I get you right, you are planning to use two or more SXes in an application where all SXes should be running at the same clock frequency. If this is the case, why don't you use one external clock generator, and feed its output into all the SXes OSC1 pins of the system ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I was pondering that recently. Do you just wire the resonator to an unlimited number of SX's (i.e. resonators have three leads, GND, OSCI and OSCO, just wire SX's all in parallel)? It can't be that easy?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
John J. Couture
San Diego Miramar College
i make pcbs with multiple sx's, this could be a space saving idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
engineer, fireman, bowler, father, WoW addict [noparse];)[/noparse]
Thanks, PeterM
in my post, I mentioned an external clock generator, and not a resonator. Such clock generators require a supply voltage, and deliver the desired clock on one output pin. This pin should go to the OSC1 pins of the SX devices with the OSC2 pin left open on all of these devices.
I'm pretty sure that a resonator with its outer two pins wired to the OSC1/OSC2 pins of two or more SXes will not work.
According to the SX28 datasheet, the OSC1 pin is defined as "Crystal oscillator input - external clock source input", and OSC2 is defined as "Crystal oscillator output". I never tried it, but this might work: Connect a resonator to the OSC1/OSC2 pins of one SX, and wire its OSC2 pin to the OSC1 pins of the other SXes (with OSC2 left open on these devices). I could not find a specification which load the OSC2 output pin can drive, i.e. if and how many additiona SXes it can clock. Seems as if some experimenting is in order here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I'm not sure if this concept will fit the application, but then it might........
I have dozens of clusters of 17 SX's, each running with 50 Mhz resonators, all synchronized to each other to a single 20 nano-second instruction. Each of the SX's in any cluster can run different application software, but a tiny (12 or so byte) synchronizing task runs under interrupt in each one. The processors within any cluster are interconnected with a single data line.
Cheers,
Peter (pjv)
I have a physical barrier that prevents me from using wires. I would switch to a more stable osc, but
they are not robust enough...
The SAW oscillators with a frequency divider may be an option...·
-dan
·
when using the word "to wire", I actually meant "to connect". IOW, a PCB trace would be used to connect the OSC pins. I'll try to be more precise in future posts.
Using a SAW oscillator would also require that you somehow wire (sorry, I mean "connect") the clock output to the SXes OSC1 pins.
Maybe, it would help us to give you better hints if you could specify in more detail what you are planning to do. Am I right assuming that you want to run an array of two or more SXes with synchroized clocks or clocks matching as close as possible?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Currently, my guys have·time to fully test every unit before they·ship, and·replace resonators as needed. However, sales are picking up, and I would really like to find resonators that are well matched,·right out of the box. (Again, 50 or 25ppm xtals are not robust enough [noparse]:([/noparse]·· )
I'm starting to think that it may be better to·utilize a VCO and PLL to lock into the RX'd·bit stream from the moving device,·and use that to generate a 50Mhz clock based on that data stream. That way, every resonator will always work.·(This is feasable, since I'm already working on·an upgraded version of the unit)
-Anyway, looks like there are no 'higher tolerance' devices avaliable...·· ...which is what I was hoping for.
Thanks guys!
-Dan
·
1. Broadcast the clock from a master clock and sync to it. I suppose you could turn a high frequency carrier on and off to achieve the 3 MHz. I have no idea how this would actually be done.
2. Use the Manchester encoding technique for synchronous data transmission. This method uses data bit transitions to infer the clock. The transitions can be used to sync a PLL. The following site explains this, applied to doing comms over a cable:
http://www.erg.abdn.ac.uk/users/gorry/course/phy-pages/man.html
Hope this helped,
kenjj
hmmm, 1. Not very easy to do...
2, Yeah, that's exactly what I'm talking about!·I'll use the decoded pulses to compare to·a·divided version of my VCO (50Mhz).·FYI, the bit stream isn't exactly·3mbps, it's actually 50mhz / by an integer value. So,·the divider is·easy hardware·[noparse]:)[/noparse]
-Dan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10
I am using edge detect. Even with that, after several bytes of data, with jitter introduced through the system, and timing errors from differences in Xtals, data is lost.
There is absolutely no way I could poll to catch the data at 3Mbps Manchester encoded.
-Dan
I'm somewhat confused because you said you "could not use wires", so how are these intended to communicate?
Assuming that there will be a physical connection, then I offer the following comments......................
I would beg to differ in regard to your last statement. Instead, I would believe that you CAN'T do it with "port-b-edge-detect. With a 50 Mhz clock and 3 Mbit data rate, there are not enough cycles to go around.
The sure way to do this 100% reliably is under interrupt control, while keeping the units synchronized. I've done this hundreds of times, and it works perfectly. And even then the resonators can even be be out by half a percent or so. Their precision simply does not matter because you synchronize the data streams by synchronizing the processors' interrupts. Very simple in concept and implementation, actually.
Presently I'm doing a project that uses a 5 Mbit data rate (non Manchester) with a throughput of 200 KBytes/sec. I have also used this technique for 10 Mbit/sec with a burst throughput of 400 KBytes/sec.
The data rates are locked to the interrupt rate, and can be chosen to be an integer divide of 50 mHz. I find that a factor of 5, yielding 10 Mbit/sec is the absolute fastest I can go, and that permits only rather short burtsts of data.
Using a divide factor of 10, yielding the 5 Mbit/sec rate, the data can be streamed all day long, and still have enough processor cycles left over to do some other things.
The caveat here is that for synchronization to be maintained during idle periods, "null" data needs to be transmitted continuously. Surprisingly, in reality, this only puts a tiny 5 to 10 % load on the processor. The processors are always synchronized and ready to go, and a byte is NEVER lost.
Cheers,
Peter (pjv)
Post Edited (pjv) : 9/26/2005 2:43:42 PM GMT
First off, no wires. eletriomagnetic (RF and/or Light), and When I say Port B edge detect, I'm utilizing interrupts fired on edge detect.· I need manchester encoding
to maintain a DC balance independent of data payload. Data·payload is small bursts, at a high rate (actual throughput is over 2Mbps sustained, while dealing with other events)
Everyone,
Just to clear things up...·THIS THING IS·IS WORKING. Very well infact.
The problem is that about 1 out of 20 resonators don't like to play. (I don't have the actual failure rates, but antecdotaly it's in that range).
From what I know, I need·tighter tolerance·resonators (My preferred solution), Or a·method of·syncing my·RX device to·the clock of my TX device (Via the data stream only).·FYI,·even Xtals rated for 40 to 60g's are 100·times too weak...·····
Anyway, I just thought I'd bounce the resonator tolerance issue off everyone here and see what happend. Looks like there are no tighter tolerance devices avaliable.
Thanks for all your input(s)!
-Dan
·
Well it's unfortunate you have not learned anything from this process.
The least you should have learned is that a better up-front explanation would collectively have saved others hours of time fishing and guessing at what was being attempted.
While admittedly your original question did not ask for a solution, but rather very specifically about tolerances; I guess all us responders are guilty of trying to help in whatever manner we thought useful, and not simply answer on a "yes/no" basis. So I guess that at least the rest of us have learned something.........
I would offer this further comment on your project;..............If you devices are working "very well in fact", yet you have trouble if some of the resonators are not quite "up-to-snuff", then I suggest your devices are working poorly at best, and you have no idea how close some of them are to NOT working. Clearly you have not thought this out properly, and I would not be surprised to see a number of them fail when some temperature drift or ageing cause the frequencies to shift slightly.
I wish you good luck in your endeavours, and invite you to request a proper solution to your problem when you are ready to do so.
I'd be more than happy to give you a properly engineered solution when you are more receptive.
Cheers,
Peter (pjv)
Peter,
First off, I have to deal with Non Disclosure Agreements. I can’t post details. People could loose their jobs, Period.
Now, you are correct, if you looked at the title of the post, a good portion of the posts were off topic. "Resonator Tolerances. Higher Tolerance Pairs or matching?", was a question of higher tolerance resonators. Even so, I tried to respond to everyone’s suggestions, because I DO appreciated the input, and time spent making the suggestions.
If you look a the initial tolerance of the Resonators plus minus 0.5% (+-5000 ppm). That means that there is potentially 10,000 ppm mismatch in clock frequency between any two resonators. This does not include·temperature effects potentially pushing that mismatch to a maximum of 15,000 ppm. Then add to that aging, and jitter introduced through the transmission media, things start to stack up. The bottom line is resonators are REALLY POOR FREQUENCY SOURCES. I really would like to use a single digit ppm tolerance device, but trust me, they won’t hold up.
Also, Please don’t assume you could do my job any better than I can. I’ve been engineering solutions for complex problems for a long time, and I’m pretty sure I know a bit more about my engineering problems than you do.
I’m here because it never hurts bounce ideas off of others. And, that's just what I did.
-Dan
I'm glad you helped clear that up; now I wish to clear something.....
Firstly let me state the reason for my apparent stern response.... it was in reaction to the very last comment in your post where you stated: (and I'm trying to quote by memory here because that comment is now deleted from your post) that you "had not learned anything you didn't already know", and I thought that was a thoughtless thing to say when we're all just trying to help. I took it a s a slap in the face, although I expect you had not intended that.
Enough of that now, I have had my venting; let's go on to the technical issues.
I agree with you completely that resonators are in some ways not the best frequency sources, and that holds for initial precision, ageing and temperature. On the other hand they are very rugged, affordable, easy for microprocessor application and fast start up. All in all, not a bad compromise.
So here comes the touchy advise part.
Clearly you are trying to communicate between several SX'es at a high data rate. I'm not sure if higher than 2+ megabits/sec is better than where you are at now. I'm also not sure if the medium is wires (printed traces), RF, optical, or what, as this could not be clearly discerned from that portion of your post. And I understand you have the communication running well, other than it takes resonator frequency selection to ensure its proper operation. And there is your problem; your design is insufficiently tolerant of batch variation in the resonator fabrication. Given the fact that tighter tolerance devices are not conveniently available, this is a significant shortcoming in your design.
I too have a LOT of experience in high speed micro processor intercommunications (all sofware bit-banging) and I have run into exactly the same issues as you are. I solved them by having the receiver software track the transmitter bit clock by syncing on the data. You are already aware of this concept as you referenced Manchester clocking. In my scheme which is VERY simple to implement, Manchester is not required, hence I get a better bit rate. I achieve syncing of the interrupts via the data edges (and NOT by interrupt-on-port B...way too slow), and once we are synced we can bit-bang at will without ever missing a bit, provided of course there are enough cycles in the software to go around.
I must say that there is one negative issue in my scheme, and that is in order for the transmissions to occur at any time without an "acquisition" procedure, they must occur synchronous to the interrupt; not a big draw-back in my application. Also, to mantain interrupt synchronism for the same reason, a continuous "null" communication must occur when no active data is being transmitted. This scheme permits me to choose the frequency tolerance of my oscillator; that is the data/null syncing must occur more frequently than the anticipated resonator drift beteen corrections. Depending on other requirements and convenience, I do this somewhere between 1 uSec and 5 uSec, and get only +- 20 nanoseconds of skew between the interrupt reference on all SX'es connected to the comm line. If greater jitter is tolerable, then a longer resyncing period would be possible.
I believe I have properly solved the resonator precision issue by proper design, and until your communications are 100% solid with your components of choice, I think you still have some issues to resolve.
Obviously you know more about your engineering problems than I do; I can't possibly know what other issues you have to contend with, and clearly you can't disclose too much. That said, I encourage you to analyze my method for its appropriateness, and if it has merit (not necessarily a given) then I would be happy to guide you to a successful implementstion.
Most sincerely,
Peter (pjv)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10
Believe it or not, but for syncing, I need only take one sample per interrupt! This is the beauty of the SX; ABSOLUTE deterministic operation PERIOD. Ohhhh wat a chip!
Cheers,
Peter (pjv)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10
I'm a little slow...I still don't quite follow how your method works. Is the only interrupt a RTCC interrupt ? Or do you use an edge interrupt also ? Are you adjusting the RTCC interrupt rate to account for offsets in clocks ?
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
Available now... SX-Video OSD module $59.95 www.sxvm.com
"I'm a man, but I can change, if I have to, I guess"
Red Green
·
Well it works a little differently.
The issue is to sync-up the interrupt routines on the transmitter (syncer) and the receiver (syncee). Once you have that accomplished, you can transfer data by setting a transmit line high/low and sample it with the other unit at exactly the right time, because you KNOW you are synced.
In fact, once you are synced, there are other benefits; two (or more) units connected to the sync/data line running the same software, will execute their programs in exact synchronism. This can be useful for applications where multiple SX's must perform functions at PRECISELY related times. Any number of devices can be synced by simply connecting to the data line.
To synchronize the interrupts, the syncer sets a data line high at a specific point early in its ISR, and drops it again some few instructions later.
The syncee, running an ISR of the SAME interrupt period, samples the data line at a fixed point early in its ISR. If that sample was high, then its interrupt period is adjusted so its next interrupt, and hence its sample,·occurs exactly one instruction earlier. Had the level been low, then its interrupt period is adjusted to make the next interrupt exactly one instruction later. This has the effect of the receiver (syncee) sliding by the transmitter's sync pulses until it finds a positive going edge. And once that is found, it remains locked on that.
Sending data is then simply a matter of appending data bits to the sync bit; the receiver knows EXACTLY when to sample at the middle of the bits; its all locked to the sync pulse's leading adge.
I use a sync (interrupt) interval of 1 to 5 usec, and a sync (bit) width of 5 to 10 instructions. Once chosen, these numbers remain fixed for any particular application.
One caveat is that the data bits must be out of the way before the next sync pulse (interrupt) occurs.
Dead simple and works 100% reliably, regardless of a small amount of resonator drift. In fact with some modifications, one can follow a slowly varying interrupt (baud) period.
Although there are a lot more tricks (half duplex operation, redundant transmitters etc.), this is the basis of my concept. Hope this clears up some of the magic.
Cheers,
Peter (pjv)
Post Edited (pjv) : 9/27/2005 9:08:34 PM GMT
Right; I NEVER use an rb-change interrupt. Everything is TOTALLY deterministic.
Oh, I guess I use it only to wake a unit up from sleep.
Cheers,
Peter (pjv)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
Available now... SX-Video OSD module $59.95 www.sxvm.com
"I'm a man, but I can change, if I have to, I guess"
Red Green
·
As for the "I didn’t learn anything I didn’t already know"... ...that was a part of a thought that I decided not to post (for fear of offending anyone!).·It·was accidentally·left at the end of the post. I promptly deleted that portion after posting the message. It was an artifact of my frustration at the off topic replies (Again, I opted to remove the entire paragraph... ...that sentence was accidentally left behind). Sorry if that offended you!
On to business...
I’m having a little trouble following your example algorithm. How do you maintain synchronization without triggering via port B interrupts (or similar)? Could you elaborate on this for me?
Some of my issues...
I’m pretty sure that I’m OK to post this info... ...but no code to be posted...
The sustained output data rate is just under 250 KBytes/second (Along with a bunch of hardware to control).·To be clear, that's maintained continuos throughput.·There are no breaks in sending/receiving this data. My data is packetized in 12 bit packets. Each of these packets has a preamble that acts as a trigger to allow re-synchronization. The preamble causes a port B interrupt to be fired. On the interrupt, data is bit banged in at a predetermined rate. I've tested the scheme with known clock sources, and it was tolerant to close to 1.5% mismatch in frequency (I don't have the actual numbers on me, I'd have to dig them up).
I was pretty sure the tolerance of the resonators wouldn't be an issue. Actually it wasn't an issue until just last week when problems started showing up (close to a year after validation). My guys started swapping resonators and found that fixed the problems, much to my relief and dismay. (This is the reason we’re matching resonators for the time being).
One of the problems is that I need a DC balanced data stream. Manchester encoding is the method that I'm utilizing to achieve this. As far as I know, this is the least computationally intensive approach to do so (Any suggestions welcome here). The data needs to have a perfectly balanced DC value, for this reason bits cannot simply be bit banged out the port. This needs to hold true over very short periods of time (Any imbalance in the microsecond range prevents the data stream from passing). Currently, the output pin is being toggled every 9 clock cycles. It is generating a square wave at >5Mhz (or >2.5Mhz worst case with a 010101 bit stream.
I also have very intense high frequency (100's of Khz) magnetic fields present (eddy currents caused by these will cause a screwdriver tip to become hot enough to burn skin). With these high energy fields, the only way to deal with them is to spectrally distance yourself from them to allow passive filtering to do it’s job. Because of the required data rate, I cannot go below them and am therefore forced to go above them. (This also part of the reason for Manchester encoding). Increasing the bit rate by a factor of 10 would really help. Unfortunately to do so I need to migrate away from the SX to a CPLD or FPGA. This is already in the plans, as it would allow very robust error checking and recovery algorithms (Once the new design is started, a hardware PLL will probably also be implemented in the system). I do·know that for the time being. A bunch of tighter tolerance resonators would really help.
Thanks for your input!
Dan