On Dec 5, 6:10 am, Bob Bob wrote:
So at 5AM I may not be too sharp...

The formula you used doesnt seem to allow for the required demod s/n.
QAM64 for example (from memory) is around 30dB so this has to be "added"
to the path loss. Differing mod/demod/FEC have differing margin
requirmeents. Somewhere in there too you have to stipulate the bit loss
rate "allowed".

Can you explain this further please?

In the past I use to calculate the noise floor at b/w, apply RX noise
figure and then add the margin.

When I last did this I upset my employer by saying that their marketing
hype was flawed. They had specified a lowest usable sensitivity that
after applying the required demod s/n was below the calculated noise
floor for that b/w. We were in fact consistently getting RX sensitivty
issues during the manufacturing phase for this reason... Marketing had
created a spec that wasnt possible!

Interesting. So these margin requirements are specified in the
standard?

Also, I dont know about 802.15 but I do know that 802.11 has variable
data rates (ie bandwidth) that can be advertised something like "54Mbps
and -87dBm sensitivity". The numbers dont actually go together. At
54Mbps you might get -77dBm and you have to use 11Mbps to get -87dBm!

Thank you. I'll look into this!

I'll admit I havent studied your maths in detail....

The above probably not a lot of use to you... Sorry!

Cheers Bob VK2YQA

Thanks a bunch. A reply to my above queries would be very helpful.

"Ginu" wrote in message
...
On Dec 5, 6:10 am, Bob Bob wrote:
So at 5AM I may not be too sharp...

The formula you used doesnt seem to allow for the required demod s/n.
QAM64 for example (from memory) is around 30dB so this has to be "added"
to the path loss. Differing mod/demod/FEC have differing margin
requirmeents. Somewhere in there too you have to stipulate the bit loss
rate "allowed".

Can you explain this further please?

http://www.satsig.net/lnb/ebno-calculator.htm is one of many sites dealing
with considerations of Energy Per Bit to Noise Density Ratio, which may help
you.

The Eb/No -- or to some, Eb/N0 -- influences the bit error rate (BER). Let
the Eb/No go too low and the link is not error-free. Generally, a BER of
better than one error in ten-to-the-eighth bits is considered to be an
error-free link.

Navy satellite data links of my acquaintance usually ran at 256 kbps and, if
memory serves, needed an Eb/No around 8. The modem reported the Eb/No and
that value was the first thing we looked at if the mux started taking hits.

I think Sal has answered this well enough. Suffice to say that if you
start with the noise floor or amount of noise energy in the bandwidth
you are going to use, you have to have a "margin" above that for the
radio system to be able to transfer information. This even applies to
morse code and voice transmission and thus the human brain's ability to
do the filtering and demod! Morse code for example can actually be heard
below the noise floor (or if you like a negative margin) because you can
concentrate on the 500Hz odd tone rather than the wide band noise.
Repeating the message that is sent also lowers the margin as it is a
kind of forward error correction that might give you a few extra dB.
Even a voice you know vs one you dont know lowers the margin. A trained
brain is remarkably good and has a huge dynamic range as well.

Even something like a human shout of warning has "greater range" because
it is a very narrow bandwith data stream. ie the message sent is binary
(yes vs no) or very short (like "help" "fire" "911" or "000") rather
than something like "There is a fire down here in the trees"

The margin required is more or less linked to the specification of the
overall modulation method. I quoted QAM64. When you add FEC to QAM64 the
margin becomes less at the expense of less data bandwidth (as more bits
are sent) I saw an FEC calc for an amateur radio satellite telemetry of
6-7dB. I browsed sround and found 802.11a is around 12dB for a BER of 1
in 10E6. Data stuff tends to be layered. ie they have a basic radio
modulation method (eg QAM, QPSK etc) and the FEC on top of that (eg Reed
Solomon & Verterbi encoding) Above that you may also have resends at a
higher layer. If you are running TCP/IP for example, TCP ensures that a
packet is received and reassembled within a certain timeout period. If
not it request the data again.

Hope this helps. apologies for the excessive analogies..

Cheers Bob W5/VK2YQA

On Dec 7, 7:30 am, Bob Bob wrote:
I think Sal has answered this well enough. Suffice to say that if you
start with the noise floor or amount of noise energy in the bandwidth
you are going to use, you have to have a "margin" above that for the
radio system to be able to transfer information. This even applies to
morse code and voice transmission and thus the human brain's ability to
do the filtering and demod! Morse code for example can actually be heard
below the noise floor (or if you like a negative margin) because you can
concentrate on the 500Hz odd tone rather than the wide band noise.
Repeating the message that is sent also lowers the margin as it is a
kind of forward error correction that might give you a few extra dB.
Even a voice you know vs one you dont know lowers the margin. A trained
brain is remarkably good and has a huge dynamic range as well.

Even something like a human shout of warning has "greater range" because
it is a very narrow bandwith data stream. ie the message sent is binary
(yes vs no) or very short (like "help" "fire" "911" or "000") rather
than something like "There is a fire down here in the trees"

The margin required is more or less linked to the specification of the
overall modulation method. I quoted QAM64. When you add FEC to QAM64 the
margin becomes less at the expense of less data bandwidth (as more bits
are sent) I saw an FEC calc for an amateur radio satellite telemetry of
6-7dB. I browsed sround and found 802.11a is around 12dB for a BER of 1
in 10E6. Data stuff tends to be layered. ie they have a basic radio
modulation method (eg QAM, QPSK etc) and the FEC on top of that (eg Reed
Solomon & Verterbi encoding) Above that you may also have resends at a
higher layer. If you are running TCP/IP for example, TCP ensures that a
packet is received and reassembled within a certain timeout period. If
not it request the data again.

Hope this helps. apologies for the excessive analogies..

Cheers Bob W5/VK2YQA

Thanks for the explanation. In your previous post you suggested that I
have to "add" the margin to the path loss. My current result doesn't
make sense because the power required to transmit at 250 kpbs for
Zigbee is less than the power required to reach the receiver at a
modest 300m away. Wouldn't adding to my path loss further deteriorate
my result? I'm trying to wrap my head around this.

On Sun, 7 Dec 2008 15:11:33 -0800 (PST), Ginu
wrote:

My current result doesn't
make sense because the power required to transmit at 250 kpbs for
Zigbee is less than the power required to reach the receiver at a
modest 300m away.

This is your first and most significant clue to the failure of
analysis, and it is very "path loss" oriented (the path loss
differences for your two scenarios should be almost infinitesimal).
The disparity in your computations are due to transcription error, or
math error. You should have now been able to put that to rest.

Wouldn't adding to my path loss further deteriorate
my result? I'm trying to wrap my head around this.

This is your confusion factor, and it relates to transcription error
in the abstract: you are using the wrong formulas entirely regardless
of the accuracy or correctness of arithmetic results.

The greater part of discussion has focused on Shannon-Hartley issues
which have their own application to the full mix of your original
problem.

Try unwinding the thread so that you are not trying to force a
solution out of a broken premise. None of this really sounds like
finding the missing decimal point, or the corrupted divisor is going
to solve anything.

If you think this is still path loss related, and you are showing
results in actual implementation (bread-boarded hardware, on the
bench); then you have to open up the discussion beyond the limited
math to include the conventional problems of interference and
multipath.

73's
Richard Clark, KB7QHC

On Dec 7, 7:55 pm, Richard Clark wrote:
On Sun, 7 Dec 2008 15:11:33 -0800 (PST), Ginu
wrote:

My current result doesn't
make sense because the power required to transmit at 250 kpbs for
Zigbee is less than the power required to reach the receiver at a
modest 300m away.

This is your first and most significant clue to the failure of
analysis, and it is very "path loss" oriented (the path loss
differences for your two scenarios should be almost infinitesimal).
The disparity in your computations are due to transcription error, or
math error. You should have now been able to put that to rest.

Wouldn't adding to my path loss further deteriorate
my result? I'm trying to wrap my head around this.

This is your confusion factor, and it relates to transcription error
in the abstract: you are using the wrong formulas entirely regardless
of the accuracy or correctness of arithmetic results.

The greater part of discussion has focused on Shannon-Hartley issues
which have their own application to the full mix of your original
problem.

Try unwinding the thread so that you are not trying to force a
solution out of a broken premise. None of this really sounds like
finding the missing decimal point, or the corrupted divisor is going
to solve anything.

If you think this is still path loss related, and you are showing
results in actual implementation (bread-boarded hardware, on the
bench); then you have to open up the discussion beyond the limited
math to include the conventional problems of interference and
multipath.

73's
Richard Clark, KB7QHC

It is not an arithmetic problem and I have "put to bed" transcription
or math error. I am designing a multiple technology network. The only
one causing me problems is Zigbee. Where do you get this from:

This is your confusion factor, and it relates to transcription error
in the abstract: you are using the wrong formulas entirely regardless
of the accuracy or correctness of arithmetic results.

I've talked to experts who have supported my claims. Unless you can
provide me with more than just random conclusions, I may be able to
get to the bottom of this. Otherwise, your posts have been much less
than helpful.

On Mon, 8 Dec 2008 22:00:02 -0800 (PST), Ginu
wrote:

Unless you can
provide me with more than just random conclusions, I may be able to
get to the bottom of this. Otherwise, your posts have been much less
than helpful.

If multipath and interference fall into the category of random
conclusions.... You were wrapped around that axle more than two
years ago.

The search term of Zigbee and Ginu (enlarged to include your alias of
Omar Fink) fairly draws a portrait of someone wandering through a fog
of 3000 threads and postings. I can see why this has mystified you
for five solid months - you are out of your element.

You've been given every extrapolatable answer from across several
dozen outlets. As I suspected earlier, the simplest answer is that
Zigbee isn't designed to do what you expect of it. Roaming the planet
asking the same question is unlikely to provide any different outcome.

73's
Richard Clark, KB7QHC

On Dec 9, 3:08 am, Richard Clark wrote:
On Mon, 8 Dec 2008 22:00:02 -0800 (PST), Ginu
wrote:

Unless you can
provide me with more than just random conclusions, I may be able to
get to the bottom of this. Otherwise, your posts have been much less
than helpful.

If multipath and interference fall into the category of random
conclusions.... You were wrapped around that axle more than two
years ago.

The search term of Zigbee and Ginu (enlarged to include your alias of
Omar Fink) fairly draws a portrait of someone wandering through a fog
of 3000 threads and postings. I can see why this has mystified you
for five solid months - you are out of your element.

You've been given every extrapolatable answer from across several
dozen outlets. As I suspected earlier, the simplest answer is that
Zigbee isn't designed to do what you expect of it. Roaming the planet
asking the same question is unlikely to provide any different outcome.

73's
Richard Clark, KB7QHC

Posting in several forums where there may be experts reading at
different times and different forums is not a stretch. Physical layer
questions are out of my realm and, unfortunately, I have to model them
in my simulations.

You're trolling in my threads and, for some odd reason, appear to feel
the need to belittle my work. If you can't add anything constructive,
please don't waste my time. I would appreciate it if you refrained
from posting in my threads in the future. Thank you.

Honestly, if I needed a babysitter I would have asked for one.