BGS5T Problem opening port COM0 at 1200 bps | Thales IoT Developer Community
December 3, 2014 - 11:02am, 12147 views
Hi there,
We have a java Midlet working on TC65T. It was developed a few years ago and it is working right now. But now we want to make it work in BGS5T devices. So, we've made all the changes in code as when import classes (siemens/cinterion), etc. It seems to work quite well after all the minor changes but there's one problem when opening the comm port COM0 with the next configuration:
comm:COM0;baudrate=1200;bitsperchar=8;stopbits=1;parity=none;blocking=off
We receive an "java.io.IOException: Opening port COM0 was failed" error.
It happens only when opening the port at this 1200bps baud rate. If we open the port at another baud rate (e.g.9600 bps) then it works fine, we can send to and receive data from an external device with no problem.
After reading some documentation I've found something on the Chapter 8. Appendix A: (Hardware) Watchdog, and 8.3 Configuration vía ASCO Interface of the Cinterion document Terminals Hardware Interface Description of BGS5T & EHSxT. It seems that this baud rate of 1200bps is reserved for watchdog configuration and could not be used for a serial communication via ASC0 interface with an external device.
We are using the cinterion Watcdog2 to switch off the module if the timer expires. Also the GPIO classes (InPort, InPortListener, OutPort) and this is the BGS5T configuration:
^SCFG: "Call/ECC","0"
^SCFG: "GPRS/AutoAttach","enabled"
^SCFG: "Gpio/****/ASC1","std"
^SCFG: "Gpio/****/DAI","gpio"
^SCFG: "Gpio/****/DCD0","std"
^SCFG: "Gpio/****/DSR0","std"
^SCFG: "Gpio/****/DTR0","std"
^SCFG: "Gpio/****/FSR","gpio"
^SCFG: "Gpio/****/PULSE","gpio"
^SCFG: "Gpio/****/PWM","gpio"
^SCFG: "Gpio/****/RING0","std"
^SCFG: "Gpio/****/SPI","rsv"
^SCFG: "Gpio/****/SYNC","std"
^SCFG: "Ident/Manufacturer","Cinterion"
^SCFG: "Ident/Product","BGS5"
^SCFG: "MEShutdown/Fso","0"
^SCFG: "MEopMode/SoR","on"
^SCFG: "Radio/Band","15"
^SCFG: "Radio/OutputPowerReduction","4"
^SCFG: "Serial/Interface/Allocation","1","1"
^SCFG: "Serial/USB/DDD","0","0","0409","1E2D","0059","Cinterion Wireless Modules","Cinterion BGx USB Com Port",""
^SCFG: "Tcp/IRT","3"
^SCFG: "Tcp/MR","10"
^SCFG: "Tcp/OT","6000"
^SCFG: "Tcp/WithURCs","on"
^SCFG: "Trace/Syslog/Otap","0"
^SCFG: "URC/Ringline","local"
^SCFG: "URC/Ringline/ActiveTime","2"
^SCFG: "Userware/Autostart","1"
^SCFG: "Userware/Autostart/Delay","50"
^SCFG: "Userware/Passwd",
^SCFG: "Userware/Stdout","null",,,,"off"
^SCFG: "Userware/Watchdog","1"
OK
The midlet need to communicate with different external devices via RS232. Some of them works at 1200bps and could not be configured to work at a different baudrate. They work only at 1200bps. We have no problem with external devices that works at 9600bps.
The question is:
¿Is there any way to communicate with an external device working at 1200bps? We still want to use watchdog and GPIO module functionalities.
Any help would be appreciated.
Thanks in advance.
Fran
On which side do you receive the error? modem or that 'external' device?
Hi,
Sorry, I post the message when it was still unfinished.
Hi,
You can try to connect your device to ASC1 interface.
The lines are avalable in the GPIO connector.
Please check the terminal hardware description for details.
Best regards,
Bartłomiej
Hi,
Thanks in advance for your help.
ASC1 is in fact a solution to the problem. But it will require to make new cables. All of them are DB9 connector type. I was hoping in the possibility that a command AT could make this ASC0-1200bps port monitoring could be disabled/enabled. This would be TC65T compatible in terms of serial communication, connector, etc. And more transparent for the end user.
And what happens if the ASC1 is already in use for another purpose?. Gemalto has sacrificed the ASC0 communications at 1200bps devices in the BGS5T???
Thanks for your help.
Best regards,
Fran
Hello,
I've made an experiment with a similar terminal (EHS6T).
I've run RS232Demo MIDlet which is simply looping everything it receives on serial interface.
It was working with COM0 and 1200bps. But still when I sent a watchdog command it was received by both: watchdog and MIDlet.
Best regards,
Bartłomiej
Hello,
So, in other words, I should have no problem opening the port COM0 and 1200bps.
Did you use exactly the same port configuration as I do? I am using exactly this string: "comm:COM0;baudrate=1200;bitsperchar=8;stopbits=1;parity=none;blocking=off".
This is exactly the string I am using to open the port. It works for TC65T with no problem with different baudrates (only changing in the string 1200 to 9600). In the BGS5T it works perfect if I change the baudrate to 9600bps but with 1200bps it throws the exception "java.io.IOException: Opening port COM0 was failed".
I can't see the reason why I am able to open the port with no exception at 9600bps and I can't at 1200bps in the BGS5T. The same code works for TC65T with both port configurations.
I think there must be something different. Maybe in the configuration of the module. Maybe I have to change something.
Also I am using the Watchdog2 class. Maybe it has something to do with the problem. I've got the watchdog set to restart the module in the configuration of the module.
Which are the possible reasons why I receive a IOException: Opening port COM0 was failed in the BGS5T???
I need to make this midlet work in the BGS5T cause TC65T is no longer available... And I don't know what to do more...
Thanks in advance for your help.
Best regards,
Fran
Hello,
I'm sorry for the later answer but I also couldn't find any reasonable reason for this behaviour so far.
Configuration of the module seems to be fine - and your app is working on other baudrates.
I was testing your settings also in my app.
The Watchdog2 class is for the module's build-in watchdog. The terminal has and additional external watchdog which is described in the terminal's description and you can configure it via UART on 1200bps or i2c interface.
I'd suggest you to try 1200bps without Java, just connect the terminal software and change the port baudrate with AT+IPR command, then change the terminal settings. Restart the module if needed.
You could also check what happens when you connect with Java on other baudrate and then call setBaudRate() method. Maybe it would be a good idea to use RS232Demo MIDlet instead of your application for test.
Best regards,
Bartłomiej
Hello,
I've been very busy with other things at work, so my apologies for this late reply.
I've been doing some tests and the problem it seems to be not the bitrate. I explain myself better. My M2M MIDlet is for vending machines from different manufacturers (mainly two). They use different lines of the DB9 serial pinout, so the cables are not exactly the same between each of the manufacturers. This makes me think that the problem was the bitrate but that's not 100% true. The problem seems to be the pin-out of the cable I use to communicate the vending machine with the terminal. Again, this is a problem that happens with the BGS5T and not with the TC65T.
Try to do a simple test: try to open the port with nothing connected in the DB9 COM0 connector and the setting string "comm:COM0;baudrate=1200;bitsperchar=8;stopbits=1;parity=none;blocking=off" for example in the BGS5T. Then you will see that it fails with:
"java.io.IOException: Opening port COM0 was failed".
No matter if you open it at 1200 bps or if you open it at 9600bps --> it throws the exception and this is something that does not happen with the TC65T. In my opinion this is something that should not happen, if there is nothing connected then there is no data communication (obviously) but there should be no exception (at least in the TC65T there was no exception).
I only need the lines 3, 5 and 8 of the COM0 DB9 terminal connector (TXD, GND and CTS). And here is the problem with the BGS5T. With this pin-out connection it happens the same as if were nothing connected at all --> it fails with the IOException.
Once I had discovered this different behaviour between TC65T and BGS5T I did different tests:
Again, this is a different behaviour between the TC65T and the BGS5T. With the same setting string, the CTS line of the TC65T measures:
i) +5.64 V inmediatly after ignition and until MIDlet starts running
ii) When MIDlet starts running it gives -5.55V and continues with no change until the port is opened.
iii) When the port is opened then CTS gives +5.64V. In this moment the vending machine detects the change in the CTS line and starts sending data, and the terminal receives that data,..
iv) when the port is closed the CTS gives -5.55V again.
In the MIDlet life happens that the port have to be opened and closed periodically, so the machine sends data each time it detects the change in the CTS line after the port is opened.
If you see something wrong in my tests or think about a way of making it work, please tell me. I really appreciate your help.
Thanks again for reading this and for your time.
Fran
Hi Fran,
Thanks for the detailed description of this issue. I will investigate this more, but since we have very limited resources during the Christmas/NY break I need to postpone this a little. Please let me go back to you in a few days. Hope this is OK for you.
Best regards & Happy New Year!
Michał
Hi Michał,
Thanks. Take your time ;-)
Happy New Year!
Fran
Pages