home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #23 / NN_1992_23.iso / spool / rec / models / rc / 4208 < prev    next >
Encoding:
Internet Message Format  |  1992-10-14  |  3.9 KB

  1. Path: sparky!uunet!hayes!bcoleman
  2. From: bcoleman@hayes.com (Bill Coleman)
  3. Newsgroups: rec.models.rc
  4. Subject: Re: Radio interference - 1 more case
  5. Message-ID: <6210.2adc2364@hayes.com>
  6. Date: 14 Oct 92 13:40:52 EDT
  7. References: <1992Oct11.164602.22624@bmerh85.bnr.ca> <1992Oct11.172238.22913@bmerh85.bnr.ca> <6181.2ad984f9@hayes.com> <1992Oct13.145406.14689@bmerh85.bnr.ca>
  8. Distribution: na
  9. Organization: Hayes Microcomputer Products, Norcross, GA
  10. Lines: 63
  11.  
  12. In article <1992Oct13.145406.14689@bmerh85.bnr.ca>, mkfeil@bcrki9.bnr.ca (Max Feil) writes:
  13. > In article <6181.2ad984f9@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
  14. >>I fail to understand all the mathematical complexity of RC radio interference
  15. >>problems. While it is true that intermodulation products could cause a problem,
  16. >>and that certain mathematical relationships could cause unwanted signals to
  17. >>pop up in the IF, there are much simpler explanations that are not considered.
  18. >>
  19. >>You experience above may have been simply that the transmitter you flew too
  20. >>close to overloaded your receiver. It really wouldn't matter what frequency
  21. >>he was on, just as long as the signal saturated the front end (or the
  22. >>intermediate stages) of the receiver. Perhaps the signal got into the
  23. >>servo wiring. Who knows? 
  24. > I know what you are saying, and it is possible. However in my case the ground
  25. > tests showed that there was a definite incompatibility between the two radios.
  26. > The other guy's channel 50 transmitter affected my channel 16 receiver MUCH
  27. > more than it should have. 
  28.  
  29. My point was that the interference may have had nothing to do with the channel
  30. used. Perhaps if he had been on channel 48 or 52, you'd have the same results.
  31.  
  32. Did this happen with ANY channel 50 and 16 radio, or just your two?
  33.  
  34. > My original thought was that something must be out
  35. > of tune or not working right for this to happen. If everybody's radio worked
  36. > this way we would have a real problem! In my previous article I was merely
  37. > suggesting that perhaps the radios were working to the best of their ability,
  38. > but that an artifact of the known problems with single conversion receivers
  39. > could explain this particular interference.
  40.  
  41. If you were using a single conversion rx, then you most likely experienced
  42. receiver overload. Single conversion designs are more susceptable to this.
  43.  
  44. >>He indicated that if you stand closer than 20 feet, it causes intermod.
  45. >>Well, I KNOW that intermod is a RECEIVER phenominon.
  46. > Well, perhaps what you KNOW is not all there is to it. I suggest you read
  47. > Call Orr's "Radio Spectrum" article in the Sept 1990 issue of RCM. He does
  48. > a fairly extensive test of "transmitter generated 3IM", complete with 
  49. > spectrum analyzer pictures. I think that Cal Orr KNOWS more in this case...
  50.  
  51. I don't have the article in question to compare. My experience working with
  52. radios indicates that rx-generated intermod is an extremely common phenomenon.
  53. Tx-generated intermod is extremely rare, and results from recticification
  54. of two extremely strong signals through some non-linear element.
  55.  
  56. This usually requires signals of exceptionally strong strength. The little
  57. 1 watt transmitters used in RC aren't powerful enough to cause this.
  58.  
  59. I'm not saying that interference doesn't happen. It obviously does. What I'm
  60. saying is that searching for these complex mathematical channel relationships
  61. is moot. There are simpler explanations, such as receiver overload, insufficient
  62. sheilding in the rx or tx, insufficient RF bypassing of servo leads, and
  63. insufficient filtering of transmitter byproducts (perhaps out of tune). 
  64.  
  65. -- 
  66. Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
  67. Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
  68. Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
  69. POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
  70. Disclaimer: "My employer doesn't pay me to have opinions."
  71. Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.
  72.  
  73.