HELP: anyone out there know how v.32 GSM data calls work p..

Archived from groups: alt.cellular.gsm (More info?)

Hi,

I'm trying to setup a transparent V.32 GSM data connection between 2
PCs each equipped with a GSM terminal adaptor. Unfortunatley we are
seeing erratic behaviour such as the insertion of garbage data and
early connects. This problem isn't related to the terminal adaptor at
the PC as the same erratic behaviour happens with many different
terminal adaptors. To get a handle on what's happening at a call
control level from the MSC/IWF to Terminal Adaptor at the PC, i've
been wading through lots of GSM documentation.

I understand as far as both sides are connected and an end-end virtual
circuit has been established as per GSM.4.08 (i.e.
set-up/alert/connect/connect-ack at the originating side and
setup/call-conf/connect/connect-ack at the terminating side). This is
simillar to the call control signalling as in a GSM voice call. Once
the call signalistion phase for setting up the physical end-end
circuit is complete and the modems in the IWF can now start training.

Where I'm confused is on completion of V.32 training by the 2 modems,
how does each V.32 modem notify the terminal adaptor that training is
complete and thereby connected? Any information please or some
pointers to the relevalent documentation would be really appreciated.

Thanks a million,
Don

Archived from groups: alt.cellular.gsm (More info?)

"Clueless2" <no.spam> wrote in message news:<40fc0c60$0$6451$cc9e4d1f@news-text.dial.pipex.com>...
> "don madden" <danjmadden@yahoo.co.uk> wrote in message
> news:7afe8fe0.0407190349.2bbb45d9@posting.google.com...
> > Where I'm confused is on completion of V.32 training by the 2 modems,
> > how does each V.32 modem notify the terminal adaptor that training is
> > complete and thereby connected? Any information please or some
> > pointers to the relevalent documentation would be really appreciated.
>
> Surely there is not training required as the modem (terminal side) are
> digital? The transparent data are rate-adapted into modified V110 frames
> before being set over the air and to the IWF. Sure the IWF to IWF will have
> to negotiate a rate, but if you are smart you can by pass this by specifying
> an "ISDN call" (cannot remember AT+ something) so that the whole
> transmission stays in the digital domain!
>
> When using transparent data the start and stop bits are transmitted as well
> (hence wasting bandwidth), are you sure you want to do this? If so, have you
> set-up your terminal to the correct bit rate and the start and stop bits?

Yes thanks for the suggestion of using V.110 and non-transparent data
instead of transparent data.
Your are correct that V.110 (AT+CBST=71,0,0) would require no training
except rate negotiation and staying in the digital domain. For these
reasons it is far simpler. Unfortunately in my case, it must also
interoperate with PSTN V.32 modems. As a result, I need a GSM V.32
data connection (AT+CBST=7,0,0) at the GSM data side.
Regarding non-transparent data versus transparent data, you are
correct that it is far simpler to use transparent data which has RLP.
Unfortunatley my application cannot tolerate the delays associated
with non-transparent data and hence the need for a transparent data
service.

Again as i'm really struggling with this one , any help from anyone
out there with some knowledge on how transparent GSM v.32 data
connections work would be really appreciated.

Thanks a million
Don