I want to know the tx level of my mobile. I have an AT command terminal, and I just want the AT command that make me get the tx level.
I tried this command:
AT*PSENGI=2
but the modem returns:
Error
also this command returns Error
AT+CMGI
but
AT+CGMR
returns:
8x25Q-QSOSKLYM-3030 1 [jan 29 2013 07:00:00]
OK
As this is a built in modem on a mobile phone there is no documentation available.
Generally such information as TX level is usually obtained via diagnostics interfaces such as QXDM rather than AT Commands. There are some manufacturers that do provide a little more information in the form of manufacturer specific AT commands but this is rare.
Related
I have been trying for a few weeks to connect to the MI Band 2 watch, and read the heart rate characteristic value, but without luck.
I am a little unsure what the procedure is, when we are talking about GATT.
For the API https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/gatt-api.txt I was thinking about using the org.bluez.GattCharacteristic1 interface to read a value out.
I can connect and pair the watch, and get all UUIDs (services, descriptors and characteristics). The heart rate measurement has the following info:
Characteristic
/org/bluez/hci0/dev_CD_1D_69_25_19_5E/service0027/char0028
00002a37-0000-1000-8000-00805f9b34fb
I have tried using the bluetoothctl program to read the value, but getting a "not permitted" feedback.
What is the procedure to read out a characteristic value, using the GATT API.
Your device is using the adopted Heart Rate profile, seeing that 0x2A37 is the adopted characteristic UUID for heart rate measurement. I would recommend that you use the BlueZ command line tools as follows:-
1. Find the handle of the heart rate characteristic using:-
gatttool -b 00:11:22:33:44:55 --characteristics
Replace 00:11:22:33:44:55 with the Bluetooth address of your device. You basically want to find the uuid that contains 2a37 and note down its corresponding 'char value handle'.
2. Find the descriptors at that handle using:-
gatttool -b 00:11:22:33:44:55 char-desc --handle=0xXX
Where XX is the char value handle that you noted down earlier. You should be able to see a couple of characteristic descriptors at that handle. Note down the char handle with uuid 2902.
3- Enable notifications by writing '0100' at that handle using:-
gatttool -b 00:11:22:33:44:55 --sec-level=high --char-write --handle=0xYYYY --value=0100
Where 0xYYYY is the handle of the CCCD descriptor that you noted in step 2. Once this happens, you should start getting indication data, which you can decipher using the temperature data structure found here.
You can find more information about using the BlueZ commands at the following links:-
How can I connect to the FitBit Zip over Bluetooth 4.0 LE on Linux with bluez?
Bluetooth Low Energy: listening for notifications/indications in linux
Using Bluetooth low energy in linux command line
I hope this helps.
Maybe you could try the shell program gatttool or use app like nRF Connect to read.
I have been trying to set up two XBees to communicate since the last three days. X-CTU seems to be the perfect option to do so, however, it is a real menace when it comes to discovering XBees on serial ports.
I was able to detect one XBee by luck just once and the other one never showed up. I have even replaced both my XBees. I am trying to figure out the alternative, i.e. using a serial console to perform the operation. I haven't been able to receive an OK response from the device upon issuing +++.
Since I haven't had a good experience using a PC to communicate with ESP8266 devices earlier, I tried to figure out a workaround by using the second Serial port of an Arduino to send such configuration messages and read the response by printing it out on the default serial console.
It also appears that configuration messages can differ depending on the mode of the device. If it's in API mode, the frame has to be generated in a specific format (I use the X-CTU frame generator for this purpose).
Why am I not able to receive a response from the XBee upon issuing a +++?
The devices are Series 1 XBees and the exact part number is XB24-AWI-001. Any help is highly appreciated.
Have you considered the XBee being in API mode? Maybe should you consider to reflash the device in AT mode to start playing with it.
To test if it's in API mode, you can refer to the guide, chapter 9 for the API mode structure:
http://eewiki.net/download/attachments/24313921/XBee_ZB_User_Guide.pdf?version=1&modificationDate=1380318639117&api=v2
Basically, a datagram in API mode starts with ~, and it's built as follows:
[0x7E|length(2B)|Command(1B)|Payload(length-1B)|Checksum(1B)]
As 0x7E is ~ on the ASCII table, you should try typing a bogus datagram in a serial terminal session like:
~ <C-d> AAAA
N.B.: The <C-d> characters means Control-d under unix., which is the EOF character.
Obviously such a message isn't likely to work, and you will receive a reply asking you to send that datagram again. That's because the EOF character being ASCII code 4, it means that the length of the datagram will be 4 bytes. So then you send four bogus bytes, the checksum will be A, which is very likely to be right, and the receiver will assume the transmission has been corrupted. So the datagram will be asked again, meaning you will receive a datagram to do that query.
Though I can only advice you to consider running it only in API mode (more reliable and a better API, but you cannot play around with it and understand what's going on by tapping on the line with a logic analyzer… though giving enough time, you'll start to read API datagrams like it's English ☺).
I wrote a page with a few resources to check on how to reflash the XBees:
https://github.com/hackable-devices/polluxnzcity/wiki/Flash-zigbee
and here's other advices from another totally unrelated project:
https://github.com/andrewrapp/xbee-api#documentation
And I also wrote a lib (aimed at beaglebones but you can tweak it for your use) that handles API mode 2 with XBees:
https://github.com/hackable-devices/polluxnzcity/blob/master/PolluxGateway/include/xbee/xbee_communicator.h
https://github.com/guyzmo/polluxnzcity/blob/master/PolluxGateway/src/xbee/xbee_communicator.C
but I bet with a little google search you can find more widely used libraries than those ones, and even some aimed to be run on Arduinos (N.B.: that lib was originally written for Arduinos, and then adapted to run for Beaglebone, so reversing the operation shouldn't be hard).
I have an Arduino Uno that is successfully registered as a device with IBM IoTF. It can send information to the Bluemix Node-RED app without any issues now.
Now, I would like the Node-RED app to send commands to the device (the Arduino Uno). The Arduino is subscribed to the MQTT without any error. But, it is not receiving any commands from the Node-RED. I followed the directions at the link below to create another flow in Node-RED to show when a command is published and the commands are being shown, so they seem to be going to the MQTT broker. But, the device (Arduino) is not receiving them.
How can I figure out how to get this working?
Node-RED, IOT Foundation Out Node Not Sending Commands
I have the IBM IoT Out Node parameters set as follows:
Authentication: Bluemix Service
Output type: Device command
Device type: Arduino-tempsensor (this is the same string I used for the device type (name) when I registered it in IoTF)
Device ID: I put the MAC address here, should it be more
Command Type: status (I used the word "status" here. Does capitalization matter? Where should I get this value from? I used "status" because it is in the topic: "iot-2/cmd/status/fmt/json" is that correct?)
Format: json (does capitalization matter here?)
data: {"d":{"myName":"Arduino Uno", "temperature":989}} (I used this because it's JSON and I wanted to just see anything at the device)
Name: IBM IoT App Out
I typed up this whole question and then it occurred to me that the test flow to look for the published command should have all of the parameters set to exactly the same as the output. When I tried that, I was not getting the command message coming back. Then, I realized that my mac address (device ID) was capitalized in one place, but not the other. The MAC address (Device ID) I used to register the device was all in caps, so I make the Iot-out node for the command so that it was all capitalized and made the Iot-in node to test for the message so that it was all capitalized. Now it works! Then, I looked back at the device (which was printing to the serial monitor so I could see what was happening) and I am now seeing the messages! So, make sure your parameters follow the same capitaliztion!
I want to know about GSM modems. I need low level info.
Can the modem get me Layer 3 Messages, Rx and Tx level, Rx Qual., C/I, BCCH, BISC, ARFCN and ...
Edit
Note: I'm not asking about embedded modems only, I'm asking on both embedded and external modems.
Thanks and Best Regards
Your best bet for low level information is AT commands. See the answer to this SO question for specific commands for the information that you want.
Although it's about Android, you can assess AT commands on any operating system, as long as the modem device exposes a modem port (It may sound obvious that any modem would expose a modem port, but this is not the case. Some modems appear in Windows as network adapters, for example).
But note that Layer 3 messages aren't available over the AT interface. You would need a diagnostic tool from the chipset manufacturer to read the air interface messages. These are not usually available unless you're a partner company or customer of the manufacturer.
Edit:
Embedded and external modems are treated the same. The best interface to use depends on the driver. AT commands work with the vast majority of modems. Read the AT command manual for information that you can get via AT commands.
Try to get hold of a manual of manufacturer specific commands that are particular to your chosen modem.
Use AT+CLAC to get all the supported AT commands of your particular modem.
L3 messages arrive via the air interface. As I said before, the chipset manufacturers have their own interfaces to access this information, but these are not public.
While I was reading about AT-COMMANDS and their functions, I realized that there are types of them according to the character that came after AT.
Like +, %, $, #, *, &, \ or a letter.
1.What do each of these characters refer to? "I need details"
I'm interested in commands that have #, but my modem doesn't get me any of them when I entered AT+CLAC.
2.Can I activate those command by another `AT-COMMAND` or not?
NOTE:
I'm working on a phone modem.
The following is good to keep in mind. GSM modems have a number of standards that they "adhere" too. Basically the standards build ontop of each other in the following manner:
Serial Asynchronous Automatic Dialling and Control (V.25ter)
AT command set for GSM Mobile Equipment (GSM 07.07)
AT Command extended command syntax (manufacturer specific - you will need a manual from them)
Two very important facts to help you out when you don't want to read through too many documents are:
You can verify if a AT Command is supported by using the =? syntax. Normally when a command is supported by a modem then you will get a response with acceptable command values and an OK. Otherwise you will get an ERROR response back when it is not supported.
Some (not all) modems support the AT+CLAC command which outputs all supported AT commands.
So going back to the original question 1 :)
"+" are usually standard GSM AT Commands which you will find in the GSM 07.07 specification or the V.25ter specification.
"&" are usually low level serial configuration AT commands based upon V.25ter.
"%" tend to be manufacturer specific AT commands. So best bet here is to check your modem manufacturers AT Command Set documentation if it exists.
"$" tend to be manufacturer specific AT commands. So best bet here is to check your modem manufacturers AT Command Set documentation if it exists.
"#" tend to be manufacturer specific AT commands. So best bet here is to check your modem manufacturers AT Command Set documentation if it exists.
"*" tend to be manufacturer specific AT commands. So best bet here is to check your modem manufacturers AT Command Set documentation if it exists.
Moving onto your second question...
Unfortunately you cannot "activate" commands. They are built into the firmware of your modem. And as you see above there are manufacturer specific AT commands that are not implemented on every GSM modem out there.
There is one thing that you can double check and that is if you are really connected to your AT Command interface. There are usually a number of interfaces for example for GPS, manufacturer propriatory, and PPP interfaces. With the latter (PPP interfaces) you can infect execute AT commands but the command set is extremely restricted. This you can verify by executing an ATI command. I know for example with Sierra Wireless modems PPP interfaces are identified as APP1, APP2, and APP3. But this is again modem manufacturer specific.