Why don't voice radio communications use FM?

"Grumman-581" writes:

I believe that there are some software controls for the coffee pot... On one
of the aircraft that I was reading the docs on, there were software controls
for various operations and measurements of the waste water system...

Sounds like an Airbus.

--
Transpose mxsmanic and gmail to reach me by e-mail.

"Grumman-581" writes:

Sorry, but you're not quite familiar with the embedded versions of the O/Ss,
so you really can't make that sort of statement with any kind of
certainty... The embedded versions are a completely different beast than the
consumer versions...

Then they aren't Windows.

--
Transpose mxsmanic and gmail to reach me by e-mail.

Jim Logajan writes:

It's been a while since I worked on any RTOS, but I seem to (probably
incorrectly) recall that applications running on VxWorks (the OS used on
the Mars Explorer, among other spacecraft) generally have full run of the
memory. That is, there is no distinction between the app and the OS as far
as access privileges to memory or I/O.

It makes sense, since anything used in a truly mission-critical
environment has to be error-free for the mission to succeed.
Protecting the OS against applications serves no purpose, because any
error in the applications will negatively impact or destroy the
mission, anyway. In other words, even if the OS is protected against
an application bug, the mere fact that there is a bug is going to
prevent the mission from being carried out, so one gains nothing by
protecting the OS.

Ultimately you end up with a system that is entirely OS, with
everything being privileged. A system that enforces restricted user
privileges just does so to protect against poorly-written software;
but you cannot afford poorly-written software to begin with in
mission-critical systems, so such restrictions are too little, too
late, if something goes wrong.

And I'll admit it eventually doesn't matter how reliable the OS is once it
passes a certain reasonable level, since the application(s) are always
going to be less reliable.

And vice versa. If it's all mission-critical, there's no reason to
restrict any of it, because it all has to be 100% trustworthy to begin
with.

--
Transpose mxsmanic and gmail to reach me by e-mail.

"Mxsmanic" wrote in message
...
If they are stripped enough to be certifiably safe, they are not
longer Linux or Windows.

Are you naturally this dense or did you have to work at it? There is no ONE
****in' version of Linux nor even Windows... We're talking a completely
different ****in' world from what you are familiar with... I would suggest
that perhaps you should consider only voicing opinions on things that you
might be competent in discussing, but that would probably prevent you from
being able to post...

"Mxsmanic" wrote in message
...
Sounds like an Airbus.

Perhaps... Perhaps it was one of the Bombadier aircraft... I was reading so
many docs while coming up to speed on the project that it all kind of
blurred together after awhile... The best I remember, there were temperature
sensors in the waste water system in addition to heaters for the lines so
that the temperature at altitude didn't cause everything to freeze up...
Various sensors could be read and were to be displayed on certain displays
if they exceeded some particular normal operating range, IIRC... There was
this one particular cabin lighting system that consisted of red, green, and
blue LEDs with software control of the intensity and color for various zones
in the aircraft... You would send a particular formated TCP/IP message via a
socket connection to a particular controller that would then change the
intensity of the LEDs in the specified zone... Quite a bit of the
communication between the various devices was handled via TCP/IP
communication... I believe that Rockwell had been granted a patent on that
approach...

Mxsmanic schrieb:

If they are stripped enough to be certifiably safe, they are not
longer Linux or Windows.

Windows is nothing more than a copyrighted name, and Microsoft is free
to sell anything they want under this name. If they decide to call that
stripped, reliable code Windows, then yes, it *is* Windows.

Stefan

In article ,
Jim Logajan wrote:

It's been a while since I worked on any RTOS, but I seem to (probably
incorrectly) recall that applications running on VxWorks (the OS used on
the Mars Explorer, among other spacecraft) generally have full run of the
memory. That is, there is no distinction between the app and the OS as far
as access privileges to memory or I/O.

There are versions of VxWorks that are certifiable to DO-178B level A.
Kind of hard to do that while allowing full run of the memory.


And I'll admit it eventually doesn't matter how reliable the OS is once it
passes a certain reasonable level, since the application(s) are always
going to be less reliable.

um, not always. the complexity of the OS could dominate the complexity
of the app, especially if the OS provides protection for the app (e.g.,
partitioning).

--
Bob Noel
Looking for a sig the
lawyers will hate

On Thu, 07 Sep 2006 07:41:03 +0200, Mxsmanic wrote:

Greg Copeland writes:

The repeater initiates the call on your behalf. The repeater is queued
rather than the analog radio. Likewise, the reply goes to the repeater,
which then re-RXs ("repeats") as analog. For this to work, the analog and
digitial systems must have their own frequencies.

Is there a guarantee that transmissions will occur within a certain
period? Are these systems verified for safety-of-life applications?


You consider DoD, DoE, CIA, FBI, military, fire, and police to be
"safety-of-life applications?" If so, yes. Do keep in mind, these are
existing systems but do not specifically target aviation. I would imagine
aviation would require some adaptation or P25 or a P25-like standard.

Also, the concept of "emergency" call is also very useful. For example,
it places you at the top of the queue. Combine "emergency" with a GPS
source, plus data services, and now your squawking 7700, your GPS position
is sent with your PTT, and you now have priority with the controller.

Interesting.

This does bring to mind something else, though: If your channels are
so crowded that you need a system to queue messages and give priority
for emergencies, you need more channels. It's much safer to have
multiple channels that don't require queuing than it is to queue on a
single channel.


Yes. That's a function of scalability. It's up to the customer (FAA in
this case) to ensure enough talk groups exist to meet their often growing
needs. As it applies to aviation, talk groups would be ground, tower,
departure, arrival, etc...

Also, I don't want to be misleading. Queuing serves as a short term
solution for **peak** periods. In other words, queuing is only honored
for brief periods of time; usually in the 1-3 second range. The notion is
to allow for first-come, first-serve without forcing users to constantly
rekey their PTT if they didn't get their call grant. If a queue depth
greater than one becomes the norm, someone failed to properly scale the
system.

Also, how do you deal with analog users who have no queuing? They
will still walk over the simultaneous transmissions in digital and
analog.

Analog users would require an analog system to sit beside it or you would
require an analog/digital repeater. I must profess, I've never used the
analog P25 repeater. I'm in the P25 infrastructure development group at
my company so I don't use the analog stuff. As such, I must profess some
ignorance.


An anachronism? No worse off than they are today.

Actually they would be, since practices extended to digital users
would naturally tend to affect analog users, even though they don't
have the same advantages. This would put them at a safety risk.

How so? How is a current analog user "at risk"? It's not like it's
removing existing capabilities.


Until everyone
is converted, such features would simply be a perk to controllers; with
the potential to increase QoS for those that digitally participate.

Quality of service has to translate to increased safety in my book.
As I've said, if fancy queuing systems are required just to manage
traffic on the channel, then there are not enough channels, digital or
otherwise.

With analog, you don't have a queuing system...which translates directly
into walked on radio calls. That's a loss of service and wasted airtime.
"Fancy" queuing and resource allocation immediately translates into
increased QoS. In this case, that translates to increased safety. That's
just for starters, directly comparing analog to digital. By having an
analog to P25 repeater, on the digital side, you reap the same benefits.


Oh, most definiately not web browsing. TAFs, METARS, in route weather,
PIREPs, TFRs, ATIS, ASOS, TWEB, NAV IDs, etc...

As long as someone is still actually flying the plane. A beautiful
digital display of weather 300 nm ahead doesn't help if it distracts
you from the mountainside looming just ahead through the cockpit
window.

If you're trying to get weather while flying toward a mountain, you have
priority issues which conflict with safety. Somehow, I don't imagine data
services will be the probable cause of death.

Lastly, let me stress, I'm talking about existing services which does NOT
serve aviation; save only a few police helicopters and planes. And those
radios are used for unit to unit (person to person) and group calls
("party line")...not for aviation specific communication. As I said
above, I'm sure parts of P25 would need to be adapted to better serve the
needs of pilots. Nonetheless, the technology is both here and proven.


Greg

On Thu, 07 Sep 2006 02:11:51 +0000, Jim Logajan wrote:

Greg Copeland wrote:
On Sun, 03 Sep 2006 15:37:38 +0200, Mxsmanic wrote:
Do other aircraft hear the transmission when you make it, or when the
controller hears it? Granted, they are only supposed to listen to
the controller, but in practice they will be listening to other
aircraft as well.

Sorry. I forgot most people don't know how this stuff works. You are
queued when you activate your PTT but you don't actually get your
"beep" (think NexTel walkie-talkie sound) back until you're granted
your call. Only after you're granted your call do you speak.

Just tell people they would operate it like a telephone: the pilot would
direct her call to a particular listener (e.g. ATC) and ATC gets a signal
(like a phone ringing!) and can let it ring until they have time to answer
the call.

That would be very frowned upon. A unit to unit call (like a non-party
line telephone) would tie up resources which should otherwise be shared.
That's not to say they don't have their place, but it's not something you
would want happening all the time.

But in a pinch, the system could also act like a party line system
and after hitting the emergency transmit button in her aircraft, the pilot's
distress call would automatically cut in over less-urgent calls to not only
ATC, but to any aircraft who have set their receivers to automatically accept
emergency calls.

Emergency calls can be group calls just as they are today with their
analog equivalent. The point of an emergency call is to give priority to
your conversation with someone on the other end. Anything beyond that is
a perk.


In essence, digital systems provide multiple virtual private circuits if
needed, but still allow broadcast or "party" line equivalents for situations
where that communication mode is more useful.

I would emphasize it the other way around. A unit to unit call ties up an
entire channel for its duration. So you would not want that to be the
common case.

Greg

On Thu, 07 Sep 2006 07:41:55 +0200, Mxsmanic wrote:

Jim Logajan writes:

Just tell people they would operate it like a telephone: the pilot would
direct her call to a particular listener (e.g. ATC) and ATC gets a signal
(like a phone ringing!) and can let it ring until they have time to answer
the call. But in a pinch, the system could also act like a party line system
and after hitting the emergency transmit button in her aircraft, the pilot's
distress call would automatically cut in over less-urgent calls to not only
ATC, but to any aircraft who have set their receivers to automatically accept
emergency calls.

In essence, digital systems provide multiple virtual private circuits if
needed, but still allow broadcast or "party" line equivalents for situations
where that communication mode is more useful.

What about analog users? What if an analog user transmits while a
queued message is being transmitted?

Normally, the duration between keying and the call grant is very. It's
measured in milliseconds. This means, the analog users PTTs and starts
talking, assuming he doesn't already hear someone talking. The grant
comes back to the repeater and it starts repeating. That means the
digital portion is some number of milliseconds behind the analog portion.
If someone else on the analog side walks on your analog call, I imagine
the DSP will do its best to filter it out. That probably means your call
it terminated before you intended or it's removed. If an analog user
talks over the P25 repeater, repeating from the digital side (xmiting
analog), then you have the classic walked on radio call problem. That is,
after all, one of the problems of analog radio.

And from my first posting on the topic:

How do you make this work in parallel with analog systems that cannot
queue?


The repeater initiates the call on your behalf. The repeater is queued
rather than the analog radio. Likewise, the reply goes to the repeater,
which then re-RXs ("repeats") as analog. For this to work, the analog
and digitial systems must have their own frequencies.

Hopefully this clears things up.

Greg