Summary: Using a program I have written in javascript (node.js), sending USSD command for a specific MNO (Mobile Network Operator) service does not return me the expected output. To my surprise, commands returns 'OK' and output is readable, but it is not what I asked for. Using the same program, if I send MNO's other commands, like check available balance I get the expected output.
Details:
I run the following commands (both from putty and my program) to send USSD code:
AT+CUSD=1,"GSM ENCODED STRING",15
And I get back something as:
+CUSD: 0,"GSM ENCODED STRING",15
We have written an npm module for encoding and decoding of GSM 7-bit type of USSD (ussd-pdu-text-converter) and using the same, we can encode our USSD command and decode the message returned back from MNO to human-readable format.
Running USSD works fine for the operations that MNO provides from its side, like checking available balance. We send the USSD, and get back the response containing the information we needed. No matter how many times we run the command, we get the same output.
The problem raises when we want to use a third party service that the MNO provides (something like Caller Ring Back Tone or CRBT). When I use putty and our program to run the USSD command for such a service, every time I get a different result. Something that I do not expect, or I did not ask for. For example:
You do not have enugh balance to use this service
You are not registered for this service
Your balance is AFN 3000.
Your balance is AFN 40.
etc.
This gets more interesting to know when we run the command from a mobile phone, we get back the response as we expect! No matter how many times we run it. We get the unique response we expect.
What I have checked already:
I have tried the followings with no result:
- AT+CSCS="IRA"
- AT+CSCS="UCS2"
- AT+CSCS="GSM"
- AT+CUSD=1,"GSM ENCODED COMMAND"
- AT+CUSD=1,"GSM ENCODED COMMAND",15
- AT+CUSD=1,"GSM ENCODED COMMAND",32
My questions:
What could be the case/algorithm that the mobile phone(s) consider that we do not do in our program, hence we get the strange outputs? Any suggestions how to solve it?
Update: I could do a work around, and broke the ussd command into a two step USSD command, of course MNO has a support for that, but still I have not been able to find out why that command itself does not work.
Related
I'm trying to figure out the SIM7080G module. An error occurs with some queries. To see the error code, send the command AT+CMEE = 1.
The problem is that I send this command and I get the answer OK. Next, I check if the value was written and see that it remains the same, equal to “0”.
Some commands have the same behavior. For example, with the command AT + CNMP = 13 I want to select the operating mode “GSM”, but the value remains equal to 38 - “LTE”.
But for example, with the command AT + IPR = 115200 I change the baudrate and it is correctly set.
Please tell me what could be the reason.
Thanks in advance.
A reboot probably occurred between the set command and the subsequent read command.
Commands parameters can be designed with three different behaviors:
Never saved after reboot
Always saved after reboot
Saved in a specific profile section (this is usually the case for ETSI standard commands)
Apparently SIM7080G module don't support profile sections. Anyway, for every command, "Parameter Saving Mode" is specified in the AT command guide.
The options are:
NO_SAVE: never saved through reboot.
AUTO_SAVE: The parameter of the current AT command is saved in NVRAM
automatically, it takes effect immediately, and it won't be lost if module is rebooted.
AUTO_SAVE_REBOOT: The parameter of the current AT command is saved in NVRAM
automatically, it takes effect immediately, and it won't be lost if module is rebooted.
-: "-" this AT command doesn’t care the parameter saving mode
I am trying to use R script to send SMS internationally. I am using correctly Auth ID and Token, both numbers are verified. But I haven't bought any number from "Plivo". Is this the reason my message is not sent?
The code is getting compiled without any error. But no SMS is sent or received. I am sharing my code below:
#!/usr/bin/env Rscript
library(httr)
AUTH_ID="**************"
AUTH_TOKEN="**************************"
message<-"Eddie is confirming the message"
url="https://api.plivo.com/v1/Account/**************/Message/"
POST(url,authenticate(AUTH_ID,AUTH_TOKEN),body=list
(src="+966123456789",dst="+4912345678910",text=message))
Can anybody please tell me that what could be the possible reasons that why message sending is not happening even the source code is correct?
But I haven't bought any number from "Plivo"
The answer is:
To send an SMS with Plivo, you need a Plivo bought number.
Obvious logic:
If this was not the case, anyone could send messages from any "verified" phone numbers?
If you meant verified as in "account verified":
This is not what Plivo is used for, you need to check if your Mobile Carrier is providing an accessible internet accessible API (I doubt it.) If you need to use sim-linked numbers, you can always use modems and AT commands, but it's fairly unreliable.
I think you should buy a $1 Plivo number, unless you need it to validate gmails or things of such.
I'm try to publish my data to ThingsBoard server i use this types of AT commands
AT+QIACT=1
OK
AT+QMTOPEN=1,"demo.thingsboard.io",1883
OK
AT+QMTCONN=1,"demo.thingsboard.io","MY_ACCESS_TOKEN",""
OK
AT+QMTPUB=1,0,0,0,"v1/devices/me/telemetry"
>{"temperature":35.00,"humidity":80.00} // MY_POST_DATA This line hanging my module
All AT commands response is ok But i finally enter MY_POST_DATA the module doesn't provide no response hanging the previous command.. and i check my ThinksBoard data never post telemetry..
Please help any one how can i fix this problem and publish MQTT server.
Step 1: Get hold of the official AT command documentation for the modem (Quectel BG96 I assume?). It should document how the AT+QMTPUB command behaves and what it expects. Everything else is just guessing. The manufacturer should provide this, and if not you should demand to get one.
...
Step 873, when you have exhausted absolutely all possible ways of getting hold of the official AT command documentation for the modem: You can try my guess that the command behaves similar to other commands that read arbitrary length user data, most notably AT+CMGS which sends SMS messages, which expect a Ctrl-Z (ascii value 26) as an end of data indicator.
+QMTPUB: 1,0,0 simply mean that BG96 has successfully published and your broker (thingsboard) have also acknowledged publication of message.
If you can't see data on broker, then please check if the topic you are publishing is correct or not.
It may happen you are publishing to another topic (or to a different PATH).
Ask 'thingsboard' for help regarding proper topic.
I'm a new Robot Framework user, and I've added the MQTTLibrary.
I can set up a subscription as per the documentation, and successfully receive messages. It's also possible to subscribe to wildcards, e.g.
${message}= Subscribe topic=test/mqtt_test/+ qos=1 timeout=2
The above will successfully pick up messages published to test/mqtt_test/apples, test/mqtt_test/oranges, test/mqtt_test/pears etc.
However, ${message} appears to only contain the content of the message payload, and I've been unable to work out if it's possible to determine the exact topic of the received message.
Can this be done with MQTTLibrary?
=============
Additional details (to provide an answer to ILostMySpoons's comment):
Sure - it's basically just the message content. So if I use...
mosquitto_pub -h 127.0.0.1 -t test/mqtt_test/apples -m "Hello to you"
...and my robot framework script does...
Log to console ${message}
...I see...
['Hello to you']
The debug output from the mosquitto broker (mosquitto -v) doesn't show message payloads but it does show the full topic path of test/mqtt_test/apples.
I've taken a deeper look into the MQTTLibrary and have come up with a solution. I'm both a Robot Framework and Python noob, so this may not be the best/most appropriate implementation, but it seems to work.
On my installation, the MQTTLibrary source is contained in C:\Python27\Lib\site-packages\MQTTLibrary. Everything of interest is in the MQTTKeywords.py file.
In the _on_message_list() function, change...
self._messages.append(message.payload)
...to...
self._messages.append([message.topic, message.payload])
Use the Subscribe keyword in your Robot Framework script as before, but you'll now have a list of lists; specifically each entry in the list will be a list of [topic, payload]. E.g.
${messages}= Subscribe topic=test/mqtt_test/+ qos=1 timeout=20 limit=0
${third_message}= Get From List ${messages} 2
${topic}= Get From List ${third_message} 0
${payload}= Get From List ${third_message} 1
Log to console \nTopic:\n${topic}
Log to console \nPayload:\n${payload}
The above example assumes that at least 3 messages were received during the 20 second timeout window.
Note that this change would break existing scripts, so a more complete solution would perhaps need to add new keywords (e.g. Subscribe And Get Topics), with additional work to ensure Subscribe still returns just the payloads.
When I send a ZPL command
^XA^MUd^LH2,0^BY2,,80^FO24,32^BCN,,Y^FDYCBZ140123010^FS^XZ
to Zebra printer, will it return a message or not?
If it does, what message (success or something else) will I get from the return, please give me a example.
On the other hand, I know there is a command ~HS which can get the printer status.
When you send ZPL print commands to a Zebra printer, it generally will not respond. This is the case when a print job succeeds or fails. You will have to explicitly ask the printer for any information. Certain commands return responses, such as ~hi (as you mentioned) or ~hs (page 233 in the ZPL manual listed below). SGD getvar commands also return responses. The following command will return the printer's current status (ZPL manual page 704):
! U1 getvar "device.host_status"
[Notice SGD commands must end with a carriage return / line feed]
The ZPL manual contains a full list of SGD commands: ZPL Manual. Also, you can look into Zebra's SDKs. If you can use something besides serial port, and depending on your printer model, you can then take advantage of Zebra's 'status' parts of the SDK to not have to parse everything yourself: Zebra Legacy SDK, Zebra New SDK