From: Clay on
On Dec 18, 11:20 pm, "steveu" <ste...(a)coppice.org> wrote:
> >Clay wrote:
>
> >> On Dec 18, 12:06 pm, Vladimir Vassilevsky <nos...(a)nowhere.com> wrote:
>
> >>>Besides, there is no good way to achieve simulcast coverage with
> 4-FSK.
>
> >> Basically data packets are built with a time to transmit
> >> tag in them at the paging terminal and the packets are distributed to
> >> the transmitters. The smart transmitter emits the scheduled paging
> >> data at the right time.
>
> >Timing isn't a very big problem. The problem is interferrence between
> >the transmitters. With 2-FSK, you can shift the carrier frequencies of
> >transmitters by +/- 0.5 x baud rate. Then the mutual interference will
> >be averaged out per duration of one bit, and everything works great.
> >With 4-PSK, you can't do that. Which makes simulcast networking pretty
> >much impossible.
>
> >> At one paging equipment manufacturer I worked on both the encoders and
> >> then the protocol monitors and pager intercept devices. I used
> >> Moto56309 DSPs for those projects. The company was already using that
> >> processor and its predessor (56001 and 56002) in its product line, so
> >> were very comfortable with manufacturing. I certainly enjoyed the
> >> available horsepower and 24 bit depth! The specialized equipment was
> >> not very price sensitive, so $30 or more for a DSP was not an issue.
>
> >I developed paging and PMR stuff. We had to do everything by i8051 and
> >M68HC11. Analog circuitry and tons of assembly code. When ADSP-21xx
> >became available, that was great relief.
>
> Its interesting that so many people here have worked on paging equipment,
> when it was always such a very niche business, with very few DSP people
> involved.
>
> Yours, another who developed paging systems,
> Steve- Hide quoted text -
>
> - Show quoted text -

Paging was the hot thing back during the 80s That's when I go into it
and learned DSP. I think a few of us "old farts" go into it that way.
And from the late 80s to the 90s, DSPs proved to be a very effective
way to handle lots of stuff in a paging terminal.

Clay
From: Steve Pope on
Clay <clay(a)claysturner.com> wrote:

>Paging was the hot thing back during the 80s That's when I go into it
>and learned DSP. I think a few of us "old farts" go into it that way.

Never worked on paging systems. I got into it from the digital
audio angle, in the late 70's.

Steve
From: Green Xenon on
>Jerry Avins <jya(a)ieee.org> wrote:
>(snip)
>
>> Thanks.
>
>> You wrote in another post that 1 symbol/sec satisfies you. Since
>> sampling for a second theoretically yields 1 Hz resolution, that's a
lot
>> of frequencies in the telephone voice band. Using a spacing of 2 Hz to

>> allow for less-than-ideal conditions, and taking the band to be 300 to

>> 8,000 Hz, you can see that it is trivially simple to get 3,850 bits in
a
>> symbol provided you can synchronize properly. Now, 2^3850 is a big
>> number, nearly 10^1159. What will you do with an alphabet of that many

>> letters?
>
>That should be 4kHz.
>
>Also, the bits/symbol is log2(number of possible symbols), so
log2(1850).
>
>Half the bandwidth might be enough to recover the clock. That is,
>to know when the symbol transitions occur. There needs to be enough
>(or sufficient) frequency changes such that the receiver can detect
>where they occur, and not lose sync.
>
>A more efficient way is to use multiple BFSK carriers not overlapping
>in frequency space. Then you do get a large number of bits.
>
>-- glen
>

According to http://www.motionnet.com/calculator/
log2(1850)=10.8533095554037

10.8533095554037 rounds off to 11.

Does this mean the max amount of bits-per-symbol using FSK on a phone line
is 11?

What if I'm using a hypothetical FSK modem that does not require
additional power supply other than the electricity provided by the phone
line itself? Then what is the maximum bits-per-symbol possible?
From: Green Xenon on
>Green Xenon wrote:
>>> Jerry Avins <jya(a)ieee.org> wrote:
>>> (snip)
>>>
>>>> Thanks.
>>>> You wrote in another post that 1 symbol/sec satisfies you. Since
>>>> sampling for a second theoretically yields 1 Hz resolution, that's a
>> lot
>>>> of frequencies in the telephone voice band. Using a spacing of 2 Hz
to
>>>> allow for less-than-ideal conditions, and taking the band to be 300
to
>>>> 8,000 Hz, you can see that it is trivially simple to get 3,850 bits
in
>> a
>>>> symbol provided you can synchronize properly. Now, 2^3850 is a big
>>>> number, nearly 10^1159. What will you do with an alphabet of that
many
>>>> letters?
>>> That should be 4kHz.
>>>
>>> Also, the bits/symbol is log2(number of possible symbols), so
>> log2(1850).
>>> Half the bandwidth might be enough to recover the clock. That is,
>>> to know when the symbol transitions occur. There needs to be enough
>>> (or sufficient) frequency changes such that the receiver can detect
>>> where they occur, and not lose sync.
>>>
>>> A more efficient way is to use multiple BFSK carriers not overlapping
>>> in frequency space. Then you do get a large number of bits.
>>>
>>> -- glen
>>>
>>
>> According to http://www.motionnet.com/calculator/
>> log2(1850)=10.8533095554037
>>
>> 10.8533095554037 rounds off to 11.
>
>You can't fit 11 gallons into a 10.8533095554037-gallon can. Round down.
>
>> Does this mean the max amount of bits-per-symbol using FSK on a phone
line
>> is 11?
>>
>> What if I'm using a hypothetical FSK modem that does not require
>> additional power supply other than the electricity provided by the
phone
>> line itself? Then what is the maximum bits-per-symbol possible?
>
>Quote properly. You attribute some of Glenn's words to me. Glenn is
>right about the bandwidth, but we make different assumptions about
>counting bits. I assumed that every FFT bin could be counted as a bit,
>independently of the others, analogously to a bundle of wires which can
>be energized in any combination. If you redo my calculation with the
>proper upper frequency and use half of that number to allow clock
>extraction, you still get a lot of bits through. Just as there's no free

>lunch, it's possible to do things in unnecessarily complicated ways
>without losing capability. Ask Rube Goldberg.
>
>Jerry
>--
>Engineering is the art of making what you want from things you can get.
>�����������������������������������������������������������������������


I posted the message using
http://www.dsprelated.com/compdsppost.php?id=122814 replying to Glenn but
the website instead quoted you. Sorry about that.

Anyways, so 10-bits-per-symbol is the max in the scenario I describe? As
asked before, what if the modems don't use any power supply other than the
phone line electric current, what would be the max bits-per-symbol, then?




From: Green Xenon on
>Green Xenon wrote:
>>> Green Xenon wrote:
>>>>> Jerry Avins <jya(a)ieee.org> wrote:
>>>>> (snip)
>>>>>
>>>>>> Thanks.
>>>>>> You wrote in another post that 1 symbol/sec satisfies you. Since
>>>>>> sampling for a second theoretically yields 1 Hz resolution, that's
a
>>>> lot
>>>>>> of frequencies in the telephone voice band. Using a spacing of 2
Hz
>> to
>>>>>> allow for less-than-ideal conditions, and taking the band to be
300
>> to
>>>>>> 8,000 Hz, you can see that it is trivially simple to get 3,850
bits
>> in
>>>> a
>>>>>> symbol provided you can synchronize properly. Now, 2^3850 is a big

>>>>>> number, nearly 10^1159. What will you do with an alphabet of that
>> many
>>>>>> letters?
>>>>> That should be 4kHz.
>>>>>
>>>>> Also, the bits/symbol is log2(number of possible symbols), so
>>>> log2(1850).
>>>>> Half the bandwidth might be enough to recover the clock. That is,
>>>>> to know when the symbol transitions occur. There needs to be
enough
>>>>> (or sufficient) frequency changes such that the receiver can detect
>>>>> where they occur, and not lose sync.
>>>>>
>>>>> A more efficient way is to use multiple BFSK carriers not
overlapping
>>>>> in frequency space. Then you do get a large number of bits.
>>>>>
>>>>> -- glen
>>>>>
>>>> According to http://www.motionnet.com/calculator/
>>>> log2(1850)=10.8533095554037
>>>>
>>>> 10.8533095554037 rounds off to 11.
>>> You can't fit 11 gallons into a 10.8533095554037-gallon can. Round
down.
>>>
>>>> Does this mean the max amount of bits-per-symbol using FSK on a
phone
>> line
>>>> is 11?
>>>>
>>>> What if I'm using a hypothetical FSK modem that does not require
>>>> additional power supply other than the electricity provided by the
>> phone
>>>> line itself? Then what is the maximum bits-per-symbol possible?
>>> Quote properly. You attribute some of Glenn's words to me. Glenn is
>>> right about the bandwidth, but we make different assumptions about
>>> counting bits. I assumed that every FFT bin could be counted as a bit,

>>> independently of the others, analogously to a bundle of wires which
can
>>> be energized in any combination. If you redo my calculation with the
>>> proper upper frequency and use half of that number to allow clock
>>> extraction, you still get a lot of bits through. Just as there's no
free
>>
>>> lunch, it's possible to do things in unnecessarily complicated ways
>>> without losing capability. Ask Rube Goldberg.
>>>
>>> Jerry
>
>> I posted the message using
>> http://www.dsprelated.com/compdsppost.php?id=122814 replying to Glenn
but
>> the website instead quoted you. Sorry about that.
>>
>> Anyways, so 10-bits-per-symbol is the max in the scenario I describe?
As
>> asked before, what if the modems don't use any power supply other than
the
>> phone line electric current, what would be the max bits-per-symbol,
then?
>
>The source of the modem's power doesn't affect the theoretical bit rate.

>The actual bit rate will depend on circuit design. The limit is set by
>thermodynamics, but we're not close to being limited by that.
>
>The phone line is capable of 64 Kb/sec in theory and 56 Kb/sec in
>practice. If you send a symbol per second, you can have 56 Kb/symbol. If

>you send a symbol per hour at 64 Kb/sec, you get 3.36 megabytes/symbol.
>
>Jerry
>--
>Engineering is the art of making what you want from things you can get.
>�����������������������������������������������������������������������
>

Really? It's possible to convey 56,000-bits-per-symbol on a phone line
using FSK [assuming a baud of 1-symbol-per-second]?

Isn't their a limit to the amount of bits-per-symbol regardless of the
amount of symbols per second?

From what your saying, it should be theoretically-possible [using FSK] to
send a Graham's-number-of-bits-per-symbol on a phone line if the symbol
rate is low enough.

Graham's number is one extremely large number!