Because of this randomness I cannot rely on USB assignment
I tried to force the new modems to 9600 but it seems they work only at
115200
So the next logical step would be to change a bit the way smslib
initializes the serialModemGateway
On Thursday, August 16, 2012 8:57:13 PM UTC+3, T.Delenikas wrote:
>
> Hi,
>
> I cannot really guide you - the problem is that USB assignments seem
> random. The solution would be to force the assignments (specific modem ->
> specific port) but I don't know if this can be done...
>
> The only solution I can think is to set all modems to the lowest common
> baud rate, i.e. connect with 9600 to all of them.
>
> On Wednesday, August 15, 2012 6:24:22 PM UTC+3, MaxX wrote:
>>
>> Hi all,
>>
>> I have faced the following problem
>>
>> I have 5 USB modems ( 2 of a type and 3 of another type )
>> I cannot control which modem on which port starts ( because they might be
>> scrambled ... card inside modems and modems with ports ) meaning that I
>> cannot say that /dev/ttyUSB4 should be started with 9600 and /dev/ttyUSB3
>> with 115200
>>
>>
>> When I had only one type it was easy
>> SerialModemGateway gateway = new
>> SerialModemGateway("Modem." + portId.getName(), portId.getName() , 9600,
>> "", "");
>> and then
>> Service.getInstance().addGateway(gateway);
>> and later on
>> Service.getInstance().startService();
>>
>> But now the situation changed and I cannot start with the same sequence
>> all modems (2 modems connect at 9600 and 3 at 115200) and before starting
>> the gateway there is no way to identify which is which
>> At some point the smslib fails
>>
>> Here is the relevant part of log from smslib.log
>>
>> [main] INFO org.smslib.modem.ModemGateway - GTW: Modem./dev/ttyUSB1:
>> Starting gateway, using Generic AT Handler.
>> [main] INFO org.smslib.modem.SerialModemDriver - GTW:
>> Modem./dev/ttyUSB1: Comm port flushing is disabled.
>> [main] INFO org.smslib.modem.SerialModemDriver - GTW:
>> Modem./dev/ttyUSB1: Using polled serial port mode.
>> [main] INFO org.smslib.modem.SerialModemDriver - GTW:
>> Modem./dev/ttyUSB1: Opening: /dev/ttyUSB1 @115200
>> [main] DEBUG org.smslib.threading.AServiceThread - Initialized.
>> [main] DEBUG org.smslib.threading.AServiceThread - Initialized.
>> [main] DEBUG org.smslib.threading.AServiceThread - Initialized.
>> [CNMIEmulatorProcessor [Modem./dev/ttyUSB1]] DEBUG
>> org.smslib.threading.AServiceThread - ** disabled **
>> [main] DEBUG org.smslib.modem.AModemDriver$ModemReader - GTW:
>> Modem./dev/ttyUSB1: ModemReader thread started.
>> [main] DEBUG org.smslib.modem.AModemDriver$AsyncNotifier - GTW:
>> Modem./dev/ttyUSB1: AsyncNotifier thread started.
>> [main] DEBUG org.smslib.modem.AModemDriver$AsyncMessageProcessor - GTW:
>> Modem./dev/ttyUSB1: AsyncMessageProcessor thread started.
>> [main] DEBUG org.smslib.modem.AModemDriver - GTW: Modem./dev/ttyUSB1:
>> clearBuffer() called.
>> [main] DEBUG org.smslib.modem.AModemDriver - GTW: Modem./dev/ttyUSB1:
>> SEND :(27)
>> [main] DEBUG org.smslib.modem.AModemDriver - GTW: Modem./dev/ttyUSB1:
>> SEND :+++
>> [main] DEBUG org.smslib.modem.AModemDriver - GTW: Modem./dev/ttyUSB1:
>> SEND :ATZ(cr)
>> [main] DEBUG org.smslib.modem.AModemDriver - GTW: Modem./dev/ttyUSB1:
>> clearBuffer() called.
>> [main] DEBUG org.smslib.modem.AModemDriver - GTW: Modem./dev/ttyUSB1:
>> SEND :ATZ(cr)
>> [main] DEBUG org.smslib.modem.AModemDriver - GTW: Modem./dev/ttyUSB1:
>> SEND :ATE0(cr)
>> [main] DEBUG org.smslib.modem.AModemDriver - GTW: Modem./dev/ttyUSB1:
>> clearBuffer() called.
>> [main] DEBUG org.smslib.modem.AModemDriver - GTW: Modem./dev/ttyUSB1:
>> SEND :AT+CPIN?(cr)
>> [CNMIEmulatorProcessor [Modem./dev/ttyUSB1]] DEBUG
>> org.smslib.threading.AServiceThread - ** disabled **
>> [main] DEBUG org.smslib.modem.AModemDriver - GTW: Modem./dev/ttyUSB1:
>> Buffer contents on timeout:
>> [KeepAlive [Modem./dev/ttyUSB1]] DEBUG
>> org.smslib.threading.AServiceThread - Stopped.
>> [CNMIEmulatorProcessor [Modem./dev/ttyUSB1]] DEBUG
>> org.smslib.threading.AServiceThread - Stopped.
>> [SMSLib-AsyncNotifier : Modem./dev/ttyUSB1] DEBUG
>> org.smslib.modem.AModemDriver$AsyncNotifier - GTW: Modem./dev/ttyUSB1:
>> AsyncNotifier thread ended.
>> [SMSLib-AsyncMessageProcessor : Modem./dev/ttyUSB1] DEBUG
>> org.smslib.modem.AModemDriver$AsyncMessageProcessor - GTW:
>> Modem./dev/ttyUSB1: AsyncMessageProcessor thread ended.
>> [SMSlib-ModemReader-Modem./dev/ttyUSB1] DEBUG
>> org.smslib.modem.AModemDriver$ModemReader - GTW: Modem./dev/ttyUSB1:
>> ModemReader thread ended.
>> [PortReader() [/dev/ttyUSB1]] DEBUG org.smslib.threading.AServiceThread
>> - Stopped.
>> [main] INFO org.smslib.modem.SerialModemDriver - GTW:
>> Modem./dev/ttyUSB1: Closing: /dev/ttyUSB1 @115200
>> [DelayQueueManager] DEBUG
>> org.smslib.queues.AbstractQueueManager$DelayQueueManager -
>> DelayQueueManager end...
>> [WatchDog] DEBUG org.smslib.threading.AServiceThread - Stopped.
>> [main] INFO org.smslib.modem.ModemGateway - GTW: Modem./dev/ttyUSB1:
>> Stopping gateway...
>> [main] INFO org.smslib.modem.SerialModemDriver - GTW:
>> Modem./dev/ttyUSB1: Closing: /dev/ttyUSB1 @115200
>> [main] INFO org.smslib.modem.ModemGateway - GTW: Modem./dev/ttyUSB1:
>> Gateway stopped.
>>
>> As far as I noticed the application fails with timeout at the first
>> command sent to the modem for which an response is expected
>>
>> the application stops on following exception
>>
>> org.smslib.TimeoutException: No response from device.
>> at
>> org.smslib.modem.AModemDriver$CharQueue.get(AModemDriver.java:535)
>> at
>> org.smslib.modem.AModemDriver.getResponse(AModemDriver.java:338)
>> at
>> org.smslib.modem.AModemDriver.getResponse(AModemDriver.java:313)
>> at
>> org.smslib.modem.athandler.ATHandler.getSimStatus(ATHandler.java:145)
>> at org.smslib.modem.AModemDriver.connect(AModemDriver.java:132)
>> at
>> org.smslib.modem.ModemGateway.startGateway(ModemGateway.java:192)
>> at org.smslib.Service.startService_Internal(Service.java:325)
>> at org.smslib.Service.startService(Service.java:230)
>> at org.smslib.Service.startService(Service.java:197)
>>
>> What I have in mind now is to have a retry mechanism inside the
>> initialization ... if it fails at first baudRate to try with the second (
>> or third )
>> Or maybe extend this for the whole myModemParms ( maybe there is more
>> than the baudRate which needs modification )
>>
>> Or if a modem fails initialization skip it but don't stop the application
>> approach
>> Or all of them
>>
>> I am willing to extend a bit the library but I would need a bit of guiding
>> Please guide me a bit where would be the best place to change this ? Or
>> what would be the best approach ?
>> I studied a bit the architecture of SMSlib but a bit of guiding would
>> help.
>>
>> Thank you for your time
>>
>>
--
You received this message because you are subscribed to the Google Groups
"SMSLib Discussion Group" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
To view this discussion on the web visit
https://groups.google.com/d/msg/smslib/-/8BEsK0BcQScJ.
For more options, visit https://groups.google.com/groups/opt_out.
