The Cyber-Spy.Com Usenet Archive Feeds Directly
From The Open And Publicly Available Newsgroup
This Group And Thousands Of Others Are Available
On Most IS NNTP News Servers On Port 119.
Cyber-Spy.Com Is NOT Responsible For Any Topic,
Opinions Or Content Posted To This Or Any Other
Newsgroup. This Web Archive Of The Newsgroup And
Posts Are For Informational Purposes Only.
From: firstname.lastname@example.org (Bill Allison)
Subject: Re: Help - Power mosfets - difficult load
Date: 31 Oct 2002 02:27:06 -0800
References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
NNTP-Posting-Date: 31 Oct 2002 10:27:06 GMT
What you say is absolutely correct. And the danger in this application
would be magnified by the fact that to get best resolution from the
available bandwidth the transmitted PCM stream only transmits servo
position relatively infrequently. The rest of the time it transmits
only changes to servo position.
However, interference of the type required to cause this effect is
very unlikely to be seen by the decoder, because of the excellent
selectivity of the source (dual-conversion NBFM RX) and the fact that
the frequency we use in the UK (35Mhz) is allocated solely to our use.
Add to that the fact that the wanted signal will be strong relative to
unwanted signals (TX will be only a few yards from the RX cf usable
range of over 1000 yards) and the risk becomes theoretical only.
And in the extremely unlikely event that a few drive pulses of duty
cycle other than that commanded do arrive, I agree with Win's
contention that that is going to be harmless.
Of course it would be no big deal to design a circuit which takes as
input the pulse train from the decoder and presents at its output a
train of pulses whose width is the average of the pulse widths at the
input, That circuit would go between the decoder and the pulse width
comparator / difference expander that will feed the gate drive IC.
email@example.com (john jardine) wrote in message news:<firstname.lastname@example.org>...
> email@example.com (Bill Allison) wrote in message news:<firstname.lastname@example.org>...
> > "Phil Allison" wrote in message news:...
> > > "Bill Allison" wrote in message
> > > news:email@example.com...
> > > > Phil
> > Phil that's absolutely not the case. An uninterrupted stream of good
> > pulses to the servo is guaranteed by the program code in the receiver
> > decoder's microcontroller section - and is verifiable by CRO
> > observation :)
> > >
> > >
> > > . . . . .............. Phil
> Each individual element may appear invincible but the comms channel
> must be looked at as a 100% complete system, including its
> susceptibility to external unwanted inputs.
> Spent time working on a high data integrity, distributed, (UHF and
> microwaves) telemetry system. The computer mainframe and data
> processing systems were a primarily a copy of the gun laying systems
> used on larger British warships. Every year, at the start of June,
> spurious and invalid data readings would begin to appear in the
> system. Eventually correlated with the yearly visit of the Russian
> trawler fleet to the local port of Scarborough. Receiver to modem
> symptoms were long bursts of high level audio noise as against the
> usual low level 2 tone fsk. A test using an noise source (0-100kHz)
> plugged into the setup could turn up a valid telemetry command 'poll'
> every 30mins (wide StanDev). A valid (wanted) poll consisted of a
> serial string of 36 bits (12 command, repeat of the 12, inverse of the
> The random noise was managing (how?) to replicate a valid string of 36
> bits!. The system of course responded in a normal manner. Error
> checking technology has improved vastly but systems are still liable
> to random failure and can never be 'guaranteed'.
Go Back To The Cyber-Spy.Com
Usenet Web Archive Index Of
The sci.electronics.design Newsgroup