 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups General General TopicsGSMBluetoothProviders AlltelATT WirelessCingularFidoNextelSprint PCST-MobileVerizonManufacturers EricssonNokiaMotorolaCountry Specific Australian GroupUK GroupRelated Topics PocketPCPalmMore Topics ... |
Cellular Phone Forum / Country Specific / UK Group / October 2003MORE 6310i GSM Modem probelms
I'm trying to dial using the DLR3P cable and the GSM modem and need to force a v42bis error correction conection. However, the +DS=3,1,2048,20 doesn't seem to do this. I've set +DR=1 to show error correction when the connection is made, and it just keeps coming back as +DR: NONE. The remote modem INSITS on error correction mode, and won't talk to me unless this is true. It's also 2400,7,e,1 to boot!! This latter bit isn't a problem (anymore - thanks John) OK - so - anyone got any ideas? Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > I'm trying to dial using the DLR3P cable and the GSM modem and need to > force a v42bis error correction conection. [quoted text clipped - 9 lines] > > Tym What s/w version is the handset *#06# ? Andy >> I'm trying to dial using the DLR3P cable and the GSM modem and need to >> force a v42bis error correction conection. [quoted text clipped - 11 lines] >> >What s/w version is the handset *#06# ? Andy 5.5 Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> I'm trying to dial using the DLR3P cable and the GSM modem and need to >> force a v42bis error correction conection. [quoted text clipped - 11 lines] >> >What s/w version is the handset *#06# ? Andy Actually it *#0000# and it shows 5.51 - not 5.5 as I guessed wrong :-) Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > I'm trying to dial using the DLR3P cable and the GSM modem and > need to force a v42bis error correction conection. [quoted text clipped - 7 lines] > > OK - so - anyone got any ideas? I'd have thought they'd negotiate error correction. To force it, I think you'll need to switch to transparent mode. I'd try AT+CBST=4,0,0;+DS=3 John >> I'm trying to dial using the DLR3P cable and the GSM modem and >> need to force a v42bis error correction conection. [quoted text clipped - 14 lines] > >John Thanks John (I've emailed you the same question) It doesn't like transparent... - ERROR Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Thanks John (I've emailed you the same question) It doesn't > like transparent... - ERROR Post-SWEN, news is often faster than e-mail. What does "AT+CBST=?" return? John >> Thanks John (I've emailed you the same question) It doesn't >> like transparent... - ERROR [quoted text clipped - 3 lines] > >John +CBST: (0-7, 12,14-16,36,36,38,39,43,47-51,65,66,68,70,71,75,79-81),(0,2),(1) Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >+CBST: (0-7, >12,14-16,36,36,38,39,43,47-51,65,66,68,70,71,75,79-81),(0,2),(1) What's the "2" for in the middle parameter (name)? Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >+CBST: (0-7, > >12,14-16,36,36,38,39,43,47-51,65,66,68,70,71,75,79-81),(0,2),(1) It doesn't support transparent mode, unfortunately. That trailing "(1)" means support for non-transparent mode only. So we need to work out why error correction isn't being negotiated correctly in this mode. In non-transparent mode, you can't use "AT+DS". Have you tried "AT+CBST=4" (using the first parameter only)? That'll force 2400 bps - perhaps EC negotiation will work then if you've got your fingers crossed. Otherwise, we might need to explore more verbose modes for diagnostic messages. > What's the "2" for in the middle parameter (name)? The "0" means support for ordinary asynchronous data. The "2" indicates support for asynchronous PAD (Packet Assembler-Disassembler) data. PADs pass data in packets, as with X.25 and frame relay. John Earlier, I wrote: > Have you tried "AT+CBST=4" (using the first parameter only)? > That'll force 2400 bps - perhaps EC negotiation will work... That's specifically across the air interface - we've already got the DTE/DCE interfaces at this speed. John On Fri, 10 Oct 2003 08:06:44 +0100, tym >+CBST: (0-7, >12,14-16,36,36,38,39,43,47-51,65,66,68,70,71,75,79-81),(0,2),(1) ....,(1) Forced non transparent - is this a network restriction on the sim - or a fault with the handset, as the nokia At documetn says it should accept (0-3) ( general GSM commands set) the other alternative is that Nokia themselves have placed this restriction on the handset as the Nokia AT doc doesn't say what the range of options are for this. Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > I'm trying to dial using the DLR3P cable and the GSM modem and > need to force a v42bis error correction conection. We might need to start from the beginning on this one Tym. We may both have been confusing V.42 error correction with V.42bis data compression. Which are you trying to achieve? The transparent/non-transparent issue may be influenced by this, although I think that both should be automatically negotiated in non-transparent mode. I'd appreciate knowing the modem's responses to the following commands: AT+DS? AT+DS=? AT+ES? AT+ES=? ATS46? Some setting may need tweaking. John >> I'm trying to dial using the DLR3P cable and the GSM modem and >> need to force a v42bis error correction conection. >We may both have been confusing V.42 error correction with >V.42bis data compression. May fault - yes - its the data compression I need - sorry for misleading info.. its the v42bis... +++at OK atz OK at&f OK at+ds? +DS: 0,0,2048,20 OK at+ds=? +DS: (0-3),(0,1),(512-2048),(6-32) OK at+es? ERROR ats46? 000 OK ALSO.... at&v ACTIVE PROFILE: E1 Q0 V1 X5 &C1 &D2 &S1 &Y0 +CMEE=0 +CSTA=129 +CBST=0,0,1 +CRLP=61,61,48,6 +CR=0 +CRC=0 +CLIP=0,2 +CLIR=0,2 +CSNS=0 +CVHU=0 +CMOD=0 +DS=0,0,2048,20 +DR=0 +ILRR=0 +CHSN=0,0,0,0 +CHSR=0 +CPBS="SM" S00:000 S01:000 S02:043 S03:013 S04:010 S05:008 S07:060 S08:002 S10:100 S12:050 S25:000 S47:000 S48:000 OK wher X5 has come from I've no idea!!! Setting +DR=1 results in: +DR: NONE on connection. Hope this helps... Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > May fault - yes - its the data compression I need - sorry for > misleading info.. its the v42bis... OK, things are looking reasonably hopeful. According to my Nokia manual, V.42bis data compression should work in non-transparent mode. There seems to be two alternative ways of setting it: "AT+DS=3" (I would try leaving parameters 2 and 3 unspecified) or "ATS46=3". Bear in mind that you may need to specifically set it back to zero when you're finished. There's also the question of whether "3" (compression in both directions) is the correct value, rather than "1" (transmit side only) or "2" (receive side only). Unless you know for sure, these are things to try. As I previously mentioned somewhere, "AT+CBST=4" (2400 bps air interface) might also prove to be a useful command if things won't work without it. > +++at > OK [quoted text clipped - 31 lines] > > wher X5 has come from I've no idea!!! According to my Nokia manual, "ATX5" is the default value for "Result Code Selection". > Setting +DR=1 results in: > > +DR: NONE > > on connection. John >OK, things are looking reasonably hopeful. According to my Nokia >manual, V.42bis data compression should work in non-transparent >mode. Glad you think so! >There seems to be two alternative ways of setting it: "AT+DS=3" >(I would try leaving parameters 2 and 3 unspecified) or >"ATS46=3". Bear in mind that you may need to specifically set it >back to zero when you're finished. ATS46=3 ERROR ~sigh~ +DS doesn't make any difference - tried that - though I'll try it again later with the +CBST (again) . Set +DR=1 to report the compression after connection and it ALWAYS returns +DR: NONE Could this be a "sim restriction" of some descriptoin? Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> May fault - yes - its the data compression I need - sorry for >> misleading info.. its the v42bis... > >OK, things are looking reasonably hopeful. According to my Nokia >manual, V.42bis data compression should work in non-transparent >mode. My reading of GSM 07.01 Annex A is that the IWF (the device that sits between the GSM network and the other network - in the case of placing an analogue modem call, it's going to act as a modem) is allowed to say "Compression not allowed". GSM 07.07 (which is the AT command specification for GSM) is really clear - it says support for +DS is "mand. when V.42bis". When V.42bis what, I wonder! Most likely, particularly following the pattern seen elsewhere in the document, it means "mandatory when V.42bis supported (by this TE)". That doesn't mean much, anyway, because if the network is allowed not to support V.42bis it doesn't matter what the TE (phone) supports. My real life experience is that Vodafone UK always seems to refuse compression - I couldn't get it to work when I tried (with a 6310i as it happens), though this was some time back. I've just done a very 'quick and dirty' test against an ISP phone number using a version 5.50 6310i using a Vodafone contract SIM and compression is *never* negotiated even if it is asked for. This was with AT+CBST=12,0,1, AT+DS=3 and AT+DR=1 - I asked for 9600bps V.34 non-transparent and compression in both directions with compression reported. I got +DR: NONE CONNECT 9600 A repeat with a Fresh SIM (T-Mobile) got the same results. I suspect support for compression is optional, and no network supports it. That would make it the same as a lot of other potentially useful features - alternate and "then" call types amongst them. GSM standards can be got from www.etsi.org free for personal use - you do need to register, but it doesn't cost. I had worked out there was confusion in this thread between V.42 (error correction) and V.42bis (compression). I'm rather surprised at anything running with a 2400 7 E 1 *and* requiring compression. Error correction would seem much more logical. However, I don't know enough about the innards of V.42 and V.42bis to know whether either is possible over a 7 bit link anyway - if it is truly a 7 bit modem protocol that's being used "over the wire". I'm afraid ancient analogue modem protocols such as V.22bis are not my thing - though V.22bis, to my memory, predates V.42bis by a long way! Personally I'd experiment with a modem under my control that reports the type of connection negotiated - it's far easier to do this with two Hyperterminal windows on the same PC than any other kind of setup. I'd also try my experiments with a V.34 modem - if you see this work with 9600bps V.34 (or 9600bps V.32) then you can try with this odd modem. David  SignatureDavid Wood david@wood2.org.uk > My reading of GSM 07.01 Annex A is that the IWF (the device > that sits between the GSM network and the other network - in > the case of placing an analogue modem call, it's going to act > as a modem) is allowed to say "Compression not allowed". So much for my optimism. It looks like you might have found Tym's brick wall (assuming we've exhausted all the possibilities). And thanks from me for your very informative reply. John > GSM 07.07 (which is the AT command specification for GSM) is > really clear - it says support for +DS is "mand. when V.42bis". [quoted text clipped - 51 lines] > modem - if you see this work with 9600bps V.34 (or 9600bps > V.32) then you can try with this odd modem. >My reading of GSM 07.01 Annex A is <snip> >GSM 07.07 (which is the AT command specification for GSM) <snip> >GSM standards can be got from www.etsi.org free for personal use - you >do need to register, but it doesn't cost. It is better to get these from 3GPP now - ETSI no longer maintains these standards, and can be out of date. Also, since 3GPP took over a few years ago, the standards were re-numbered. Generally (but not always) you can find the new number by adding 20 to the standard number, then inserting a zero after the decimal - so 07.01 becomes 27.001 07.07 becomes 27.007 etc. 3GPP's site is http://www.3gpp.com - no registration is necessary to download the standards. The best place to start looking is http://www.3gpp.org/specs/numbering.htm R4 of the standards is implemented by pretty much everyone now, sometimes R5 is used (expecially for areas which have seen a lot of change - e.g. for EMS), R6 is still in development. Matt SignatureMatthew Haigh --$matthaigh{News04}$@haigh.org-- GCRSoft, providing SMS solutions since 1996... http://www.gcrsoft.com http://www.moretext.com > My real life experience is that Vodafone UK always seems to refuse > compression - I couldn't get it to work when I tried (with a 6310i as it [quoted text clipped - 17 lines] > would make it the same as a lot of other potentially useful features - > alternate and "then" call types amongst them. Just to add to this, the same result is achieved with O2. I tried not so long ago pretty much what you did with O2 and Voda but concluded that the IWF just doesn't negotiate compression. I used to dial in to my ISP quite frequently using either a 6310i or a 6210 and made sure that I used an ISP (e.g Clara) which supported software compression so the lack of compression over the mobile link didn't matter. This made (mostly text heavy) web browsing quite acceptable at 9600bps. With an ISP which doesn't support software compression (e.g. BT) it is not a pleasant experience. On another note (apologies to the original poster for moving away from his query), perhaps someone could explain why my throughput speed is always faster when connecting using "analogue modem" type rather than V110. For sure, V110 connects much faster but afterwards the analogue modem option is better. The difference is about 1000bps which may not be large (although arguable in the context of a 9600bps max). I've tried various test downloads and the analogue option is always faster. I've repeated this using both O2 and Vodafone, with a 6210 and 6310i across a number of ISPs. A not very scientific consequence of this is if I listen to the latest news audio stream on the BBC website which is an 8.5K Real audio stream, using the default 30 seconds buffering, I can listen without any rebuffering when making an analogue connection but usually get rebuffering when making a V110 connection. Any ideas? SignatureJohn > On another note (apologies to the original poster for moving > away from his query), perhaps someone could explain why my [quoted text clipped - 11 lines] > any rebuffering when making an analogue connection but usually > get rebuffering when making a V110 connection. Any ideas? I'd be interested to hear if anyone else is experiencing this. I tend to be a regular user of GSM data access, but only when I'm away on holidays. And I always use V.110 in preference to V.32 because of the faster connect time. I've not noticed V.110 to have slower throughput, but it hadn't occured to me to do the measurements. John > > On another note (apologies to the original poster for moving > > away from his query), perhaps someone could explain why my [quoted text clipped - 18 lines] > to have slower throughput, but it hadn't occured to me to do > the measurements. Interestingly on Vodafone's website, they say that when you have the choice of analogue or ISDN they recommend selecting ISDN as 'this provides greater error correction and a faster connection set up.' Now if there's more error correction using V110 (and I don't know if that's true) then it's likely the potential throughput limit will be lower assuming a good signal with not too many errors etc. Does anybody know if the error correction is different depending on how you connect? SignatureJohn >In message <bm9sm7$jo60s$1@ID-83062.news.uni-berlin.de>, John Henderson >correction) and V.42bis (compression). I'm rather surprised at anything >running with a 2400 7 E 1 *and* requiring compression. Error correction >would seem much more logical. However, I don't know enough about the >innards of V.42 and V.42bis to know whether either is possible over a 7 >bit link anyway - if it is truly a 7 bit modem protocol that's being >used "over the wire". To clarify - the devices I am connecting to were designed 10 years ago!! PSTN Link spec for them is "... Quadcomm II serial modems using speed auto-sense (maximum v22bis 2400 baud full duplex), data error correction protocol V42 and V42bis data compression" and Hardware Protocol as "Asynchronious serial, 1 start bit, 7 data bits (LS bit first), even parity, 1 stop bit. Flow control is local to each modem" Using "normal modems" I can connect fine - its just the GSM part of the equation which is causing problems due to lack of v42bis - which you may have identified the source for... Thanks for a very informative (even if its over my head!) answer. Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >My reading of GSM 07.01 Annex A is that the IWF (the device that sits >between the GSM network and the other network - in the case of placing >an analogue modem call, it's going to act as a modem) is allowed to say >"Compression not allowed". I'm afraid you'll have to forgve me on this, but I'm not actually "Up"on GSM at all!! I just play with general comms... This IWF thing... who owns it? it is part of the service provider's equipment (eg.voda, orange etc etc) or *something else*? I'm tring to work out who to contact to ask "does your IWF support compression?" in order to find out exactly WEHRE by brick wall is located... -( Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > I'm afraid you'll have to forgve me on this, but I'm not > actually "Up"on GSM at all!! I just play with general comms... [quoted text clipped - 6 lines] > support compression?" in order to find out exactly WEHRE by > brick wall is From a quick look at GSM 07.01 it seems certain that it's a piece of the GSM network, and owned by that network. It stands for the "InterWorking Function", and the acronym occurs throughout GSM 07.01. If David's a regular reader of this group, he may be able to help you best frame questions to the providers. But I'd be inclined to ask if they support V.42bis interworking with fixed line modems. Be prepared, of course, to insist on talking to someone who understands the question. And good luck. John >From a quick look at GSM 07.01 it seems certain that it's a piece >of the GSM network, and owned by that network. It stands for the [quoted text clipped - 8 lines] > >And good luck. Didn't need to - its not the network!! I've borrowed a "proper" GSM modem (manufactured by ECL) which connects like any other Modem. Popped my Orange Sim card in and away we went! AT+ICR=5,1 OK AT+DR=1 OK ADTD01........... CONNECT9600 Set port speed to 9600,e,7,1 and connected with compression and all works ust bloomin' fine and dandy!!! Looks like I've got a Nokia problem! :-( It would appear that it doesn't like +ICF=5,1 at a speed above 2400... though I can't see why.... Need more time to play with this.... Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Didn't need to - its not the network!! > [quoted text clipped - 22 lines] > > Need more time to play with this.... Agreed. Please keep us informed. John >> Looks like I've got a Nokia problem! :-( >> [quoted text clipped - 4 lines] > >Agreed. Please keep us informed. Will do... Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Looks like I've got a Nokia problem! :-( >> [quoted text clipped - 4 lines] > >Agreed. Please keep us informed. Just had a thought - does it make any differnce that I am accessing Com1 directly and not trying to access the NOkia GSM modem via it's own drivers? Would that give me any more functionality??? Probably not, as doing it the way I am, I can still do *something* even if its not *completely* what I want, so I know I can get to the modem as I am, just wondered if the bits I am missing may be in "the drivers?" Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Just had a thought - does it make any differnce that I am > accessing Com1 directly and not trying to access the NOkia GSM [quoted text clipped - 6 lines] > I can get to the modem as I am, just wondered if the bits I am > missing may be in "the drivers?" In most circumstances, the drivers just do a few initialisation commands for you, setting up usual dial-up defaults. There's probably a log file showing full details. On my Windows 98 PC, it's under "Control Panel" / "Modems" / <modem nane> / "Properties" / "Connection" / "Advanced" / "View Log". But the log may be empty unless the driver's last use was to establish and control a dial-up connection. John > I've borrowed a "proper" GSM modem (manufactured by ECL) which > connects like any other Modem. [quoted text clipped - 3 lines] > AT+ICR=5,1 > OK I presume you mean "AT+ICF=5,1". > AT+DR=1 > OK Did you try "AT+DS=1"? "AT+DR=1" is merely sets the level of verbosity of result codes - it has no effect on the connection to be established. > ADTD01........... > > CONNECT9600 Looking over this in detail, did you dial your "pedantic" modem (the one which insists on 2400,7-E-1, V.42bis compression)? Or was it some other (more flexible) test modem? If you're using a different modem for testing at the receiving end, you might need to use the "AT+DS=5,1" form of the data compression command in order to make the test realistic. The second parameter, "1", forces the call to be rejected if data compression is not negotiated. The default value of "0" for this parameter allows the connection to proceed even if the requested compression cannot be negotiated. John >> AT+ICR=5,1 >> OK > >I presume you mean "AT+ICF=5,1". Err... yes.. sorry - typo! >> AT+DR=1 >> OK >Did you try "AT+DS=1"? "AT+DR=1" is merely sets the level of No - all I set was +ICF and +DR - and i t worked. It doesn't need anythng else. Actually, I'm going to try it without 5,1 and see what happens. I don't have to do that with my normal modem so I'll see if this behaves likewise. If not - no problem. +DR (though I coudn;t remember the string it returned or I would have put it in the message) reported compression and I got the data from the remote unit as I do with "proper" modems. So, using the ECL modem, I can do precicely what I need, with minimal register settings. The only thing I have to do is set at+ICF back to 3,4 when the program quits to return the modem to its former state. The reason I can't paste from terminal directly into here is that I have to take the laptop off the network and cram it up against the patio window to get a signal (which at+csq reports briliantly!) I'll try and do a sesion and then drag it back over here and put it back on the network so I can paste the session details for you. The only problem I have is getting my program to hang up!! Once the connection is made, ATH doesn't get a response, neither does AT+CHUP. I've tried +++AT then ATH/AT+CHUP, but I don't get an "OK" from +++AT. it does however seem to loose signal as soon as I try and hang up (coincidence) so I wonder if the desperate trying to hang on to signal is precluding the +++AT command - or should I be doing something different? Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > The only problem I have is getting my program to hang up!! Once > the connection is made, ATH doesn't get a response, neither [quoted text clipped - 5 lines] > to hang on to signal is precluding the +++AT command - or > should I be doing something different? Yes, there's "guard time" (it's usually configurable somewhere if you need to change the value) to take into account. The default escape sequence is "+++", and not "+++AT". The "AT" comes from the modem. But you've got to put a pause into your data stream, then the 3-character sequence "+++", and then another pause. These pauses are the guard time - they allow "+++" to occur within any transmitted data without triggering command mode in the modem. With appropriate pauses either side, the modem will switch to command mode, and give you an "OK<cr><lf>" prompt. I'd try 2 or 3 seconds minimum either side of "+++" for the guard time. Having got the modem into command mode, you can issue AT commands. As you suggest, either "ATH" or "AT+CHUP" should hang up a GSM data call. In contrast, "ATO" will return the modem to data transfer mode. Depending on configuration, an alternative way of hanging up a call is to drop the DTR signal from the PC. John Earlier, I said: > The "AT" comes from the modem. That's rubbish, of course. I don't know what I was thinking. John >Earlier, I said: > >> The "AT" comes from the modem. > >That's rubbish, of course. I don't know what I was thinking. LOL - it happens to the best of us :-) Thanks for the other stuff... Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >Having got the modem into command mode, you can issue AT >commands. As you suggest, either "ATH" or "AT+CHUP" should hang >up a GSM data call. In contrast, "ATO" will return the modem to >data transfer mode. This isn't working :-( Ii nthe program - the modem (and I've tried this with both the ECL GSM modem AND my always-worked-before external modem) is refusing to respond to "+++" once the connection has been made. Consequently it then refuses to accept any AT commands at all I'e set the guard time to 3 seconds (AT+S12=150) and found the escape character - just in case some bozo's changed it! sEscChar=chr("ATS2?") send (sEscChar & sEscChar & sEscChar) Dial - Connect - all OK... then send "+++" - nothing happens wait 3 seconds send "ATH" - still nothing happens. Only way to drop the call is to close the port - but on the GSMmodem - it only closes the connection between PC and modem, and leaves the SIM card connected.... that then entails swithcing off the modem to hang up. There's got to be a way to make it respond to "+++" in the program when I do it in terminal: atd0161xxxzzzz CONNECT 9600 SF 15107 83480120 BC 09999 83193548 BC 09999 83196422 BC 09999 83196502 BC 09999 83196790 BC 09999 83197013 BC 09999 83197160 BC 09999 83197214 BC 09999 83197246 BC 09999 83197335 BC 09999 83197565 BC 09999 83197690 BC 09999 83197771 BC 09999 83197775 BC 09999 83199649 BC 09999 83199716 BC 09999 83199951 BC 09999 83200032 BC 09999 83200211 BC 09999 83200787 BC 09999 83201251 BC 09999 83202082 BC 09999 83202155 BC 09999 83475172 BC 09999 83475302 BC 09999 83475817 BC 09999 83475880 BC 09999 83476714 BC 09999 83480078 OF 19999 82915918 ON 19999 82916000 OF 19999 82916287 ON 19999 82947215 OF 19999 82947476 ON 19999 82948205 OF 19999 82948277 ON 19999 82949199 OF 19999 82998527 ON 19999 83032966 OF 19999 83033192 ON 19999 83035035 OF 19999 83035330 ON 19999 83035515 OF 19999 83087126 ON 19999 83117935 OF 19999 83118028 ON 19999 83122559 OF 19999 83171407 ON 19999 83208 <----------------------------+++ typed on keyboard OK ath <---------------------------------------command send from keyboard OK This works fine in terminal.exe - but NOT when I'm in the program.... In the program +++ does not raise an OK at all - ever! >Depending on configuration, an alternative way of hanging up a >call is to drop the DTR signal from the PC. Any idea how to do this is VB6? :-/ Might be my only hope... I'm Confused... Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > +++ typed on keyboard > OK [quoted text clipped - 5 lines] > > In the program +++ does not raise an OK at all - ever! Are you sure you're not sending an end-of-line sequence along with the "+++"? I'm thinking of the Pascal equivalent of using "writeln" instead of "write". Or in Pick Basic (with which I'm familiar), you'd need print "+++": instead of print "+++" (note the trailing colon to suppress the end-of-line). There has to be a simple explanation. > >Depending on configuration, an alternative way of hanging up a > >call is to drop the DTR signal from the PC. > > Any idea how to do this is VB6? :-/ Might be my only hope... Sorry, never used VB. But a quick google search for "vb6 dtr" brings up things like http://www.codeworks.it/net/VBNetRs232.htm. John >> In the program +++ does not raise an OK at all - ever! > >Are you sure you're not sending an end-of-line sequence along >with the "+++"? BINGO!!! Thank John - working fine now :-) Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Thank John - working fine now :-) You're welcome. Glad to hear it's all working. It's all been a good technical challenge :-) All the best, John >> Thank John - working fine now :-) > >You're welcome. > >Glad to hear it's all working. It's all been a good technical >challenge :-) Still "challenged" by the Nokia though.... Might have to stick with this ECL for a while -until I can test it with another brand of phone - Ericsson, Seimens etc... see if its just a Nokia thing. Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > In the program +++ does not raise an OK at all - ever! In the C language, you'd need to force a buffer flush in the absence of an end-of-line sequence to make the timing effective - I don't know about VB. John >> I'm trying to dial using the DLR3P cable and the GSM modem and >> need to force a v42bis error correction conection. > >We may both have been confusing V.42 error correction with >V.42bis data compression. Now we've got the Character framing issue sorted - looks like that wasn't the problem after all - it was lack of data compression... :-( Tym ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See http://www.ictis.net/no_spam.html for unsolicited email warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.