BGS5 ASC0 spow problem | Thales IoT Developer Community
December 6, 2016 - 8:49am, 2794 views
Hello,
I want to use asc0 in my Midlet.
After opening a CommConnection in Midlet, spow value is changing.
Before Midlet run, spow value is ^spow=1,0,0. After CommConnection opened, spow value becomes ^spow=0,0,0.
And in this situation, asc0 read does not work. Although there is data on RX it cannot read. If a outputstream.write works on TX or at^spow=1,0,0 is sent, then read works.(If only TX write is done without sending at^spow=1,0,0, spow value is still 0,0,0 but read works.)
My some questions are below.
Why does spow value change after CommConnection? Is this a bug?
Do I have to make a TX write operation before RX read? Or Do I have to send at^spow=1,0,0 command after CommConnection?
ATI1 response of my BGS5 is below:
Cinterion
BGS5
REVISION 01.100
A-REVISION 00.000.21
OK
Hello,
The SPOW setting should not change after opening the serial connection in MIDlet. You should also not need to write before being able to read. Could you paste some code for opening the connection. Are you using the hardware flow control, what are the settings on the other party?
Regards,
Bartłomiej
Hello Bartlomiej,
Thanks for the answer.
Serial connection opening code is like below.
String connectionParameters = "comm:COM0;baudrate=115200;autocts=off;autorts=off";
CommConnection cc = (CommConnection) Connector.open(connectionParameters);
I don't use flow control. My module has 3 pins(rx,tx,gnd) . Other party also does not use flow control and similarly has only 3 pins for communication.
Best Regards,
Ergün.
Hello,
I have done some testing and was able to reproduce the problem. The "^SPOW: 0,0,0" reply is rather not correct while you have not been changing it.
But on the other hand according to the AT commands specification "It is recommended that the TE uses hardware flow control, however the BGS5 does support TE communication when using only the RXD, TXD and GND lines. This is possible because the input lines for hardware flow control, RTS0 and RTS1, each have an internal pull down resistor inside the BGS5. For customer applications designed without RTS and CTS lines this means that the default setting of AT\Q3 can still be accepted even though hardware flow control is not actually used outside BGS5."
And there is only one setting for AT\Q command in the document - RTS/CTS hardware flow control. So based on that you should also configure RTS/CTS in Java ";autocts=on;autorts=on". In my test it has helped to make the read possible, but I had a cable with all lines (I have disabled HW flow control in PC terminal), so I can't be sure if it will work for you. Please test if it can help in your application.
Best regards,
Bartłomiej
Hello Bartlomiej,
Thanks for reproducing the problem and answer.
I have just tested the scenario again with changes autorts=on, autocts=on in my application. I couldn't read data as before.
According to the AT\Q command explanation, autorts=off, autocts=off has no effect on flow control. Right?
You wrote spow:0,0,0 is not correct. If I send at^spow=1,0,0 from usb0 when application is working, then read becomes possible. Why?
Best Regards,
Hello,
How about the hardware that you are using with the module - is it some kind of developer board or your own hardware? This could also matter because there is some additional hardware connected to the lines. Please also try to switch on the flow control in the MIDlet and connect RTS with CTS.
AT\Q command changes the flow control settings for the port while Java MIDlet is not active. For Java you use the configuration with autorts and autocts.
The SPOW setting should not change when the MIDlet starts or opens the connection. I can't explain why the read becomes possible when you set it but it seems to be a kind of workaround for this problem.
Regards,
Bartłomiej
Hello Bartlomiej,
When no midlet running, if I send at command from pc module receives it and sends response.
Conditions are same. 3 pins, no rts-cts, no flow control. Module can read.
Problem occurs when midlet opens a com connection.
By the way, I have sent some code to your e-mail. Did you receive it? If you contact with me via mail, it can be better to solve the problem.
I'll try to test your code with my module and HW. In a meantime please verify also your HW design regarding this information from module's Hardware Interface Description document:
"Supports RTS0/CTS0 hardware flow control. The hardware hand shake line RTS0 has an internal pull down resistor causing a low level signal, if the line is not used and open. Although hardware flow control is recommended, this allows communication by using only RXD and TXD lines."
Regards,
Bartłomiej
Hello,
I've run your code. But I'm not able to reproduce your hardware conditions because I have a developer board where there is already additional hardware connected to the serial interface lines and I cannot disconnect it. And such results may be misleading. It was working for me. I have also tried with autocts=off;autorts=off and after a few reconnections of the terminal it was also working.
So I'm not sure now if this issue is necessarily caused by this SPOW reply. It might be a HW design as well.
On the other hand without Java MIDlet the commands are always working. But when Java takes control there must be some difference in the port behaviour.
Regards,
Bartłomiej