Serial and USB communication | Telit Cinterion IoT Developer Community
November 3, 2016 - 4:00pm, 3654 views
Dear Gemalto,
I am developing an application for the PDS8 and I am also using the Cinterion Concept Board for testing.
Could you help me to clarify the below:
1. Does the response to System.getProperty("microedition.commports") depend on any configuration or state? On the Cinterion Concept Board I have seen two or three different results. First I got COM0,USB0,USB1,USB3,USB4,USB5, and later I got COM0,USB0,USB3,USB4,USB5. If I remember correctly, I have also seen COM1.
2. According to the manual, the amount of AT parsers is limited. Testing showed that both the PDS8 and Cinterion Concept Board allow 8 ATCommand instances to be created. Do the ATCommand object compete with the physical ports (USBx, ASC0) for available AT parsers?
3. According to the AT command manual, executing AT^SCFG="Serial/Interface/Allocation","2" should make AT commands available on USB1, but USB1 never responds to AT commands, regardless of the setting. What behavior should I expect?
4. During development, we run Windows 8.1 via Parallels on a Mac. Often, the USB communication between the development machine and the PDS8 or Concept Board is lost and a reboot is required to re-establish communication. When comms is lost, the Module's A-drive can no longer be accessed via Windows Explorer and no serial connection can be made to any of the USB ports. The device is still listed in the Device Manager and the COM ports are configured correctly. This is inconvenient during development, but also worrying because we intent to use USB also in the field. What is your experience with this, and how can the root cause be found?
5. We connect the PSD8 via USB to a field computer that runs Linux. We would like to use USB3 for sending AT commands, USB5 for debug output via standard out and then use a third USB port for communicating between the field computer and our own MIDlet on the PDS8 using a proprietary protocol. Which USB port would you advise us to use and why? Is the USB reliable for primary communication between modules in the field?
Looking forward to your response,
With kind regards,
Maarten van Berkel
Hello,
Please read the answers below:
1
System.getProperty("microedition.commports") should return the ports that are available for Java so the output should also depend on some settings like "Serial/Interface/Allocation".
2
The number of available AT parsers is limited but Java does not compete with the physical interfaces which have the dedicated AT parsers assigned.
3
This setting is effective after restart. It should be possible to send AT commands on USB1. I've tested it with my module and it was working.
4
When you reboot the module all the USB connections to the module in Windows should be closed. If not it may happen that the module will not be responsive on USB. As far as I know this is only true for Windows systems. There is no such limitation for RS232 interfaces.
5
This is possible. The USB interface is reliable and advised. Not all USB interfaces have AT parsers connected so you need to choose the proper one for AT commands.
Best regards,
Bartłomiej
Dear Bartłomiej,
Thanks for your answers.
Would you be so kind to eleborate on your fourth answer? What is the procedure to close the USB connections in Windows? If it is becomes unresponsive, what is the recovery procedure to re-establish USB comms? How does this work in Linux?
With kind regards,
Maarten
Regarding #5: Which USB port would you advise us to use and why?
Hello,
I meant especially disconnecting the connections in the terminal programs. If the USB does not reply you should just replug the cable or restart the module.
It doesn't matter which USB port you choose for communication with your application. If you want to send AT commands to the module you just need to check which USB port has replies to AT commands (these will be the same ports for all modules).
Regards,
Bartłomiej