I am trying to make calls and send texts from the GSM modem, but when I try to make a call it says "No Carrier" I cant seem to fix the problem or figure out what is wrong. Please help me trouble shoot the problem!!
at+cnum
+CNUM: "","16108647718",129,7,4
OK
AT+COPS=?
+COPS: (2,"T-Mobile ","T-Mobile ","310260"),(1,"AT&T","AT&T","310410"),,(0-4),(0-2)
OK
ATD 6107938274;
OK
NO CARRIER
Your SIM is for which operator? Suppose it is for T-mobile, you can try
at+cops=1, 2, "310260"
If it failed, then you may try with
at+cops=0
My guess is your modem is keeping some wrong information about the operator...
Related
I need send rich structured error details on gRPC error.
I think it's maybe like this:
fv = BadRequest.FieldViolation(field="login", description="Name is not unique")
bad_request = BadRequest(field_violations=[fv])
context.abort(StatusCode.INVALID_ARGUMENT, bad_request.SerializeToString())
But is's wrong and send bytes in summary error text.
I use grpcio==1.17.1
I got feedback on github issue https://github.com/grpc/grpc/issues/17601
Everything works in version 1.18.0
I'd like to check if a connection using the telnetlib is still up.
The way I do it is to send a ls command and check the answer, but I'm sure there must be a smoother solution.
I've got the idea from here, so kudos to them, the code could be something like this
def check_alive(telnet_object):
try:
if telnet_object.sock:
telnet_object.sock.send(telnetlib.IAC + telnetlib.NOP)
telnet_object.sock.send(telnetlib.IAC + telnetlib.NOP)
telnet_object.sock.send(telnetlib.IAC + telnetlib.NOP)
return True
except:
pass
the idea is pretty simple:
if the close() was called .sock will be 0, so we do nothing
otherwise, we try to send something harmless, that should not interact with what ever the underlying service is, the IAC + NOP was a good candidate. LaterEdit: seems that doing the send only once is not enough, so I just did it 3 times, it's not very professional I know, but ... "if it looks stupid, but it works ... than it's not stupid"
if everything goes well we get to the "return True" thous we get our answer, otherwise, the exception will get ignored, and, as there's no return, we will get a None as a response
I've used this method for both direct and proxied(SocksiPy) connections against a couple of Cisco routers
I use twain 2.3 (TWAINDSM.DLL) in my application with HP Scanjet 200 TWAIN Protocol 1.9.
My TWAIIN calls are:
OpenDSM: DG_CONTROL, DAT_PARENT, MSG_OPENDSM
OpenDS: DG_CONTROL, DAT_IDENTITY, MSG_OPENDS
EnableDS: DG_CONTROL, DAT_USERINTERFACE, MSG_ENABLEDS
ProcessDeviceEvent: DG_CONTROL, DAT_EVENT, MSG_PROCESSEVENT
and as a result of the last call I allways get TWRC_NOTDSEVENT instead of TWRC_DSEVENT.
Could please someone help with this?
Once you use DG_CONTROL / DAT_EVENT / MSG_PROCESSEVENT, all messages from the applications message loop must be sent to the data source for processing. Receiving TWRC_NOTDSEVENT means the forwarded message isn't for the source so the application should process it as normal.
Keep forwarding all messages to the source until you receive MSG_XFERREADY which means there is data to transfer. Once the transfer is finished and you have sent MSG_DISABLEDS that's when you can stop forwarding messages to the source.
Twain is a standard, and when many company implement that standard, not all of them do the same way. Along the way to support Twain, we will learn and adjust the code to support all the different implementations.
I experienced this situation before, and this is my workaround:
Instead of placing (rc == TWRC_DSEVENT) at the beginning of code (will skip the following MSG_XFERREADY processing afterward) you can move the comparison to the end after MSG_XFERREADY processing, so that MSG_XFERREADY is always checked and processed.
(rc == TWRC_DSEVENT) is only to determine if we should forward the window message or not.
I don't know your specific situation. I ran into a similar issue because I called OpenDSM with a HWND/wId which is from another process. You should call OpenDSM with the HWND of
the active window/dialog which is owned by current process.
I wrote the code to send the message in ocaml.
let out_channel = Unix.out_channel_of_descr sockfd in
Marshal.to_channel out_channel message [];
flush out_channel;
close_out out_channel
However, I got warning.
GLib-WARNING **: poll(2) failed due to: Bad file descriptor.
I knew the warning was due to [close_out out_channel], and I didn't get the warning when I remove [close_out out_channel] from the code. I don't know why I must remove [close_out out_channel]. Could you tell why?
You are making an OCaml channel from sockfd. When you close the channel, you close sockfd. This will confuse whatever layer created sockfd. So things go wrong after that. Whoever is in charge of sockfd is also in charge of closing it. Just leaving out close_out out_channel is actually the right thing to do, I think. But flush out_channel is good.
I have a GSM modem and a PLC. The PLC sees a modem (I use a *.lib and functional block "openPort"), but I don't understand how send an "AT command" to the modem, for example, "ate0".
First, to increase your understanding of AT commands in general, read the V.250 specification. That will go a long way in making you an AT command expert.
Then for the actual implementation, I do not know Codesys, so the following is pseudo code of the structure you should have for handling AT commands:
the_modem = openPort();
...
// Start sending ATE0
writePort(the_modem, "ATE0\r");
do {
line = readLinePort(the_modem);
} while (! is_final_result_code(line))
// Sending of ATE0 command finished (successfully or not)
...
closePort(the_modem);
Whatever you do, never, never use delay, sleep or similar as a substitute for waiting for the final result code. You can look at the code for atinout for an example for the is_final_result_code function (you can also compare to isFinalResponseError and isFinalResponseSuccess in ST-Ericsson's U300 RIL, although note that CONNECT is not a final result code. It is an intermediate result code, so the name isFinalResponseSuccess is not 100% correct).