Hello All

We are attempting to get 300baud FSK data over a GSM link.

Ive seen different postings on this in the past and the concensus
is that it may be possible given that its FSK and at a slow rate.
Although the GSM codecs distort the phase of audio tones they should
not effect the frequencies.

Essentially the requirement comes from the fact that the equipment
at the far end can only communicate at 300baud FSK over the PSTN network.
Our end will work with GSM and needs to communicate at the 300 baud FSK.

Has anybody had any experience with this?

Many thanks for any help in advance.

Regards

Denis

_____________________________
http://www.CentronSolutions.com

"Denis Gleeson" <dgleeson-2@utvinternet.com> wrote in message
news:184c35f9.0409290304.1fed30b4@posting.google.c om...

I think you are doomed ;-)

The GSM Codecs work by building a model of the human "speech machinery",
determining the model parameters and the initial stimulus parameter and then
send the parameter set across; not the actual data: The voice at the
recieving end is merely a simulation of the speaker! The Codecs are
speech-only!!

Why not use the Modem in the Mobile Terminal?

The modem can negotiate with the other end and will do the right thing - om
most terminals it will even support the normal AT command set.

"Denis Gleeson" <dgleeson-2@utvinternet.com> wrote in message
news:184c35f9.0409290304.1fed30b4@posting.google.c om...

If you need to have a 300 baud FSK modem at both ends, using audio, I'd be
inclined to simply use a standard 9600 baud GSM modem like those made by
Siemens and convert the 300 baud to 9600 baud with an MCU. A small PIC or
AVR will do the job.

Leon

Frithiof Andreas Jensen wrote:
I'm no expert but

http://www.commsdesign.com/story/sho...cleID=16501605

suggests that there's a PCM component which attempts to correct the
difference between the generated signal and the actual signal is 156 bits
per frame (in the standard Full Rate codec), and one frame is 20ms, that
means a PCM component of 7.8kb/s.

There are of course timing and phase issues that come about through chunking
but Denis mentions that he's already aware of those.

Leon's suggestion of using a GSM modem for transmission and a converter is
probably a better one though.

Geoff

"Leon Heller" <leon_heller@hotmail.com> wrote in message
news:415a9c6e$0$20247$cc9e4d1f@news-text.dial.pipex.com...
Or assuming the modems are external, just set the baud rate on the serial
interface to 300baud and let flow control do the rest.

"Frithiof Andreas Jensen" <frithiof.jensen@die_spammer_die.ericsson.com>
wrote in message news:cje5sc$g9b$1@newstree.wise.edt.ericsson.se...
It is a pretty good simulation, since one can normally recognise the voice
of the caller.

"Denis Gleeson" <dgleeson-2@utvinternet.com> wrote in message
news:184c35f9.0409290304.1fed30b4@posting.google.c om...
Is this going to work?

You have one advantage in that one end at least is PSTN.

FSK works by counting the zero transitions in the detected waveform.

There are two frequencies, the clock is abstracted from the higher. Bit
stuffing ensures that there is always a full cycle within a set period. At
the lower frequency you get half a cycle, but at the higher frequency you
get a full cycle of carrier (the numbers may be greater for 300 as apposed
to 1200baud) corresponding to the state of a bit. So the question is will
the waveform be sufficiently well transported over GSM for the reconstructed
waveform at the other end (of the air segment) to be able to count the
transitions accurately.

In my opinion on a good quality GSM connection to a static GSM set you
probably will, but you will probably want to use a suitable protocol to
minimise errors: -

1. Data should be packetised with reliable checksums (min 16bit) and
sequence numbering.
2. The conversation should be essentially half duplex, even though GSM is
full duplex, so that echo in the network does not confuse one station's
receiver while it is transmitting.

HDLC will probably be quite handy.

If your GSM station is mobile, poor quality, distant, or in a an area with
reflections and interference then you may be in trouble.


As a guide 1200/2400FSK works fine on airband in 5kHz AM bandwidth.

"R. Mark Clayton" <nospamclayton@btinternet.com> wrote in message
news:cjeg5d$15q$2@titan.btinternet.com...

That's because humans are pretty good at recognising voices in difficult
circumstances - a computer will have a much harder time. ;-)

Still, there *should* be a Modem in the GSM terminal; That Modem will use
the "proper methods" which is either to disable the GSM codecs and use PCM
instead, possibly using several timeslots, or to "tunnel" the digital data
to the PSTN where there will be a device dealing with data comms - i.e. A
Modem.

Depends on the Mobile terminal and the Network how it is done - "userside"
sees a vanilla 9600 bps AT compatible modem.

PS:
Trying to send the modem sounds trough a GSM 'phone sounds really wierd and
hack'ish - like those "phone suction pads" one used in the 70'ies movies
whenever there was a hacking run in the script - on GSM voice, Morse might
be be the best!

dgleeson-2@utvinternet.com (Denis Gleeson) wrote:

Given the earlier thread, this is not a credit card terminal by any chance!?

Linus


--
Linus Surguy - Magrathea Telecommunications Ltd. Wholesale and retail telephone
services. www.magrathea-telecom.co.uk www.uknumber.co.uk www.callthrough.co.uk
www.telesave.co.uk: UK 2.5p/1.5/1p South Africa 6p US,France,Germany,Eire 2.5p
Looking for VoIP? We will gateway SIP & IAX to and from the PSTN.


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

Actually, maybe speech synthesis and recognition would be the best!

In article <cjeg5d$15q$2@titan.btinternet.com>,
nospamclayton@btinternet.com says...
The technology is utterly jaw-dropping. Even at 1200 bits per second
you can still recognize the speaker with one codec I've played with, but
if they hold up a radio playing music to the microphone, you'll hear
nothing but garbled mush.

If GSM uses codebook-based compression, you can forget about the
survivability of Bell 103 or anything like it.

-- jm

------------------------------------------------------
http://www.qsl.net/ke5fx
Note: My E-mail address has been altered to avoid spam
------------------------------------------------------

Hello everybody

Thanks everybody for your excellent input. Its given me lots of room
for thought.

Slight mistake in my description of the problem. Let me start again.

What I said was;

"Essentially the requirement comes from the fact that the equipment
at the far end can only communicate at 300baud FSK over the PSTN
network.
Our end will work with GSM and needs to communicate at the 300 baud
FSK."

What I should have said was;

Essentially the requirement comes from the fact that the equipment
at the far end can only communicate at 300baud FSK over the PSTN
network.
We are connecting a board to this equipment which will have a GSM
module (modem) on it.
Our end will be a standard PC with a PC modem(connected to PSTN)."



I had hoped(and I doubt my wisdom on this now) that we could place the
call with
the GSM modem and simply connect the PSTN output of the equipment to
the GSM
modules audio input. Of course there is some electronics involved
where the audio out of the GSM module is connected to the equipment's
PSTN output.

What I am thinking following the discussion here is that I need to
take
my 300baud FSK and convert it to a digital data stream (using
Microprocessor
and zero crossing detector) and use the data communication
capabilities of my
GSM modem to send the data to my PC modem. Then, of course, I will
also need
to take the returned data from my PC modem and convert it to FSK
(using Microprocessor and tone generator) for the equipment.

There will also be a requirement to do the tonal handshaking required
by the 300 baud FSK modem before communications begins. This can be
achieved with the
Microprocessor being used.


Now that sounds like a lot of work but I think I could be guaranteed
that it would function.

In all this I am assuming that when communicating with my PC modem
from
my GSM modem that the network is taking care of the change in
protocols
required. Is my understanding clear with this?

Many thanks again

Denis
_____________________________
http://www.CentronSolutions.com

[Note: F'up2 list cut down --- should have been done by OP]

In comp.arch.embedded Denis Gleeson <dgleeson-2@utvinternet.com> wrote:

Sorry, but I think this clarified version actually makes no more,
possibly even less sense than the original.

In a system of three devices, all of them being a modem, something
can't be right --- you'll eventually end up with a loose end that is a
telephone jack connected to nothing.

Yes. In the effect, you need a bona fide 300 Bd modem, and no, a GSM
phone's audio in/out can't be used in that function. You may also
need a PSTN line simulator --- a simple pair of cables won't do, IIRC.

Then you'll need a micro that connects to both this modem and your GSM
modem. That will *not* use any PSTN modem standard, though, but
rather a digital-only transmission method (SMS, CSD, HSCSD, GPRS,
....). If you have that thing call a PSTN number in data mode, then
the GSM provider will indeed have to convert from GSM digital to
analog signals.

Which thus drives the total number of modems involved in this scenario
to a rather crazy 6:

* 3 at the location of that remote device-thingy
* 2 somewhere in the GSM provider's infrastructure
* 1 at your PC's location

Are you *sure* getting a PSTN land line to that remote device's
location wouldn't be a whole lot less hassle?

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Hi guys

The equipment in discussion is a piece of security equipment.
The requirement exists such that if the PSTN line goes down or is cut
then
the equipment must be able to continue to communicate. Hence our GSM
modem connected to the equipment at the remote site.

Ok the modem we have is capable of making a CSD data call(not GPRS).

OK. This is an area that I am uncertain about. It appears that I would
be at the providers mercy, dependant on what services he provides for
GSM data communication. Would I be better off attempting GPRS
communication?

Im not sure about these figures. Can you explain.

and voice.


Many thanks for all your help.

Denis




linus@magrathea-telecom.co.uk (Linus Surguy) wrote in message news:<415af09c.602244343@10.0.0.3>...

[F'up2 cut down. Again!]

In comp.arch.embedded Denis Gleeson <dgleeson-2@utvinternet.com> wrote:

That covers the "why", but not the "how". You said originally that
this device of yours can _only_ communicate at 300Bd over PSTN.
I took that a face value, i.e. assumed it means that the PSTN
line jack is the *only* external data connection this device has.
Is it?

If so, you will need another modem capable of doing 300 Bd over PSTN
to attach to that, with a (simulated) PSTN sitting between the two,
because that's the only kind of device your security thingy can talk
to at all. Whether you implement that modem yourself, or buy a
modem-on-a-chip is beside the point.

Maybe, maybe not. GPRS is less widely available than CSD, and neither
of them is unconditionally included in a plain vanilla GSM service
contract. You'll have to check that out with the GSM providers in
your place.

Yes, but as has been stated here by others, it can't serve as an
analog modem to partner with the existing analog modem in the security
device. And even if it coulde, it quite certainly wouldn't be able to
service two independent communication links simultaneously. I.e. the
GSM device can't act as a gateway from 300 Bd FSK to CSD, but only as
a modem, which translates between RS232 (or alike) and CSD.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

"Denis Gleeson" <dgleeson-2@utvinternet.com> wrote in message
news:184c35f9.0409300315.20bbcc4@posting.google.co m...

As I now understand it the remote equipment is a remote fixed security
device (e.g. and alarm) and what you want is a back up service using GSM for
an existing 300baud PSTN dialled connection. Presumably if the PSTN
connection fails the call will divert to your board. There seems to be some
confusion about whether the underlying data stream (at 30cps) is available
or not.

So your problems are: -

1. Instructing the GSM module to place the call. If the module contains a
modem or is essentially a GSM phone that contains Hayes Compatible one (e.g.
Motorola Time-Port connected by cable rather than IRDA) then this should be
fairly straight forward, if not you will struggle.

2. Can you run 300FSK over GSM.

I will presume that the near end will answer incoming calls and the modem
will sync to whatever actually arrives. Alternatively you could connect
another modem enabled GSM phone to a spare serial port.

So you possible sequences are: -


"dumb" option - 2 wire interface

device fails to establish comms on main [PSTN] path and tries backup path.
board notices presence of carrier from device
board places voice call to PSTN number and simple connects the [polling?]
device to the central station.
300FSK communication then takes place over the established voice channel.
when carrier drops from device the board disconnects the call.

"intelligent" option - serial interface

device fails to establish comms on main [PSTN] path and tries backup path.
board receives request from device on serial port (e.g. ATDxxxx...) at
300bps
board wakes up GSM phone and passes command to phone
phone calls central station and established GSM modem connection.
serial communication is established via GSM modems at 9600baud, albeit that
the available bandwidth is significantly underused.
call is hung up under device control (ATH)

If the device is not moving then call quality will be improved, and a proper
aerial can be used.

R. Mark Clayton <nospamclayton@btinternet.com> wrote:

That's because the human brain is good at speach recognition...

--
Mark Evans
St. Peter's CofE Aided School
Phone: +44 1392 204764 X109
Fax: +44 1392 204763

They also leave silences where bad packets were received.
The ear dosen't hear them, but the modem sure does.

--
KC6ETE Dave's Engineering Page, www.dvanhorn.org
Microcontroller Consultant, specializing in Atmel AVR

Mark Evans wrote:

even better at speEch recognition....

--
e-crime and computer evidence conference
2005 - Coumbus Hotel, Monaco
http://www.ecce-conference.com/