Reading URCs in java application | Telit Cinterion IoT Developer Community
October 23, 2015 - 9:15am, 5228 views
I am trying to make an UDP client in eclipse. I've read section 1.8.1 in the ehs6_ATcommands_v02000a.pdf document and I understand that URCs are important when communicating with the module.
Ive tried to setup the UDP client as follow.
all the setup ATCommands responses with an 'OK', But when the ATCommand AT^SISO=0 is called the module once again response with 'OK' but then the program freezes. My guess is, that i need to wait for the ^SISW=0,1?
but exacly how do i listen for it?
okay, so far so good. I solved the problem by implementing a Listener that handles the ATEvents and i do receive SISW=0,1. I made sure the application does not continue untill ^SISW=0,1 is received. Even though the application continues to freeze after the ATCommand AT^SISW=0,4 so i believe that the problem is, that im not sending the string "test" properly?
First of all the IP services via AT commands are not a perfect solution for a Java. The best would be to use DatagramConnection and send datagram for udp. Then your code will be 100% Java, and not just Java-based AT command script.
If you decide that you really have to use AT commands instead, you have to know that after sending AT^SISW command AT command interpreter goes into a data mode state, before returning the OK. OK is only returned after sending a proper amount of data. The data though should be be send in separate thread using the OutputStream, which you can obtain via ATCommand.getDataOutputStream();
But I suggest rather to use DatagramConnection ;-)
Thanks for your reply Michał.
as you suggest I have chosen to use DatagramConnection. Due to my unexperience with the Concept Board and java I havent managed to make it work yet!
My application executes without errors, but nothing seems to be happening on the server side.
I have send and received messages using a terminal(Docklight) and the AT Commands above. When i started using the AT Commands i had the same problem, but managed to fix it by changing the APN from internet to websp. Could it be the same problem here? Or does the Connector.open handle this on its own?
I can't see how you pass the network access parameters. You can add these parameters to the URL - you can find the description in SocketConnection in the API. Example: ";bearer_type=gprs;access_point=internet.t-d1.de;username=anyone;password=something". Or you can use AT^SJNET command.
okay, so i have tried with both suggestions and im still facing the same problem.
I guess you've made a mistake in your example? guess you should have used a semicolon instead of a colon.
Am i initiating the websp correctly? I have only managed to find examples with internet as APN.
Of course there should be semicolon - sorry for that.
The APN, user and password depends on your network provider.
To test if you are able to communicate with these parameters you could also use the example application that you can find in this location: 'C:\Users\Public\Cinterion\EHS5 WTK Examples' if you have installed the provided software.
You need the reset() method only when you are using read and write methods instead of setData and getData. And you should not call reset() again after setting data and before sending the datagram.
Thanks for your help - i have now managed to make the UDP connection work!
just found this thread after bumping into this send(AT^SISW...) problem.
Actually, AT^SISW is not supposed to return OK at all. Instead, it should return ^SISW: X,Y indicating how much data is allowed, then accept the data. The reasons for doing it from java are several. First, with the previous tc65i device, AT-based TCP was much more stable than pure java-based in my experience, although slower. Second, some additional information can be monitored this way like local ip address assigned. Third, it makes very easy to reproduce and troubleshoot some connection issues by just re-typing AT commands by hand. And there are more. So, it was good to have it. However for now, it looks to me like in EHS5 this ^SISW is just somehow screwed in java, at least in the blocking variant it apparently blocks forever. I'd note that such drastic difference compared to TC65i is not mentioned in the appropriate Section 12 of the Java user guide...
And now I know why.
Looking at "(\r\n)+CONNECT( \\d+((/\\D+)*))*(\r\n)+" it is quite clear that cwmlib only knows exactly one reason for going into data mode: connect event. It is apparently unaware of SISW, SISR. At least it is so in the SDK version I got from my supplier :(((
You can also check the local IP of the connection in Java. But this is all about preferences. Generally it is advised to use Java connections in Java or IP over AT commands without Java. But of course you should be able to use IP services over AT commands from MIDlet if it is not said to be impossible.
I can see that you have done some reverse engineering of cwmlib..
You made me check this with some latest version and it seems that you don't have the latest software. What is more I have discovered that I was also using some older version for the last SISW research - I was only updating the module's firmware and it was not enough. These libraries do not change with each firmware release but sometimes they also change.
So the result is that with the updated cwmlib the send() method does not hang on SISW command and it is possible to send data to the network..