I would like to know if there is a way to send a non-character byte through a terminal emulator. Bytes with values from 0 to 127 are (mostly) represented by characters on a keyboard (example: a, b,c...A,B,C.. 1,2,3..!,#,#..). But how can I type and send something that corresponds to a byte with value 137 for instance? I would like to send these types of "non-characters" over a serial connection to an arduino using a terminal program. I am currently using teraterm, but other terminal emulators might be fine too. BTW, the arduino code for receiving these bytes is working fine.
You can use send the character that you want by using the Alt key.
Alt+137 will display the character ë. If you send that, the arduino will receive the appropriate byte.
Related
I am trying to make a windows executable talk with a Quectel module through serial.
The tool always fails at the first step which is to read the module's firmware version with an AT command (AT+CGMR\r).
I tested to send the same command to the module, using Putty and typing out the command, and it worked like a charm.
However, when I type the command in a notepad (including the carriage return at the end), then copy the text and paste it into putty (my idea was to get closer to the behavior of the .exe by sending the command faster), 2 weird things happen:
1 - I don't get a response from the module until I send a second carriage return by pressing Ctrl-M in putty. I am certain that the character is copied into the clipboard from the notepad though...
2 - The module does not receive "AT+CGMR" but "AT+CGMM" (which is also a valid command). I tested other variations and concluded that the last text character is always replaced by the second to last text character. So AT+CDFR gives AT+CDFF. AT+PILJ gives AT+PILL etc...
I am certain that is what the module receives because echo mode is on so the module prints out the command it received before the answer to said command.
To summarize:
By typing on the keyboard directly into putty I get:
AT+CGMR
SSB,V150R100C10B200SP1
SECURITY_A,V150R100C20B300SP5
PROTOCOL_A,V150R100C20B300SP5
APPLICATION_A,V150R100C20B300SP5
SECURITY_B,V150R100C20B300SP5
RADIO,Hi2115_RF0
OK
Which is the expected output.
But by copying and pasting the exact same text from notepad I get:
AT+CGMM
BC95GJB-02-STD
OK
and that, only after I press Ctrl-M. Before that there is no answer at all so it is as if the module never received the carriage return.
I can't figure out what is going on here... Any help appreciated.
I worked a lot with Quectel 4G modules. Maybe make a simple data tracer.
Download dumb terminal Termite so you can see single hex characters including non printable. Connect termite to to read a stock USB to serial adaptor. Make sure the adaptor is set to 3.3V not 5V. The Quectels are 1.8V domain but can scrape in and drive 3.3V logic. I assume you are driving your Quectel with 1.8V.
Hardware wise attach the Rx pin of the Quectel module to the USB module Rx pin then you can see exactly the characters going into the Quectel from Notepad and Putty. (Sometimes you may need a 1K in series with the USB Rx pin to reduce loading). Bingo, you can see exactly the characters the Quectel is getting. I found many bugs doing this.
I'm trying to send data from C# app to the one STM32 dev board via USB CDC. I have problem with method SerialPort.Write() because write method send only first character instead of all characters of array or string. Same situation is it with serial terminals (terminte, cutecome,..) when attempt to send string. Can someone explain me how cdc usb really works. Does STM32 send data in same manner, character by character in each frame? I didn't use logic analyzer to see signals but that will be next step maybe.
If anyone has picture of usb cdc frame please share.
When I send string from STM32 dev board to the C# app that works fine. Any idea is welcome
The C# SerialPort.Write function is capable of writing an entire string at once if you call it the right way. The bytes of the string will be passed on to your operating system's USB drivers, which will split it up into packets according to the max packet size for the endpoint specified in your device's USB descriptors. Then those packets will be sent to the device, one packet at a time.
I suspect that there is a bug in your STM32 code, but since you have not posted an MCVE it will be difficult to help you debug any code.
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).
When I send any commands to the HM10 BLE Bluetooth module, it sends the commands through bluetooth instead of the HM10 module processing the command. For example, I expected to send AT and have the module respond with "OK", but it sends the text "AT" through the bluetooth connection. I have tried sending the command with no bluetooth connection and the same thing happens. I have also tried sending the command via bluetooth instead of the serial connected to the device and I get the same thing.
When HM10 is connected to remote ble device it is in transparent mode. To put it into AT mode you need break connection or not establish it at all.
For breaking connection use reset/break pins. Reset is 12 pin and Break seems to be 23 pin.
It has sense to look IMME parameter of the module (page 32 of datasheet).
IMME Query/Set Module work type
1: When module is powered on, only respond the AT Command, don’t do
anything. Until AT + START, AT+CON, AT+CONNL commands is received.
0: When power on, module will start work immediately Default: 0
Also be carefull with strings endings, usually string doesn't need to be terminated with any symbol at all: AT, but some H11 need the string to end with CRLF: AT\r\n
Maybe (Maybe) your problem because of using clone module, try this solution with upload genuine firmware to your hm-10.
How to flash genuine HM-10 firmware on CC2541
I had problem close from your problem but for me no matter what I send I don't receive anything even to connected device, but after I upload that firmware, and change Module work mode to 1 (AT+MODE1) become able to send command even from connected device.
I am interfacing a seeedstudio GPRS shield for my arduino UNO via the serial monitor Arduino window, and some writing directly echo'd to the tty (I am using Linux)
I am able to interface with it properly in the regards of sending text messages and even receiving them, however when I run the command to read the messages (Knowing it's ID) I am only returned the first character of the message, as such:
+CMGR: "REC READ","MYPHONENUMBERHERE","","13/10/15,21:45:44-40"
H
The full message was "Hmmm" and the only thing showing is the "H"
The exact command run is as follows:
AT+CMGR=3
Also, interestingly enough, when I run
AT+CMGL="ALL"
I do appear to get every message
+CMGL: 2,"REC READ","+1xxxxxxxxxx","","13/10/15,21:35:51-40"
+CMGL: 3,"REC READ","+1xxxxxxxxxx","","13/10/15,21:45:44-40"
+CMGL: 4,"REC READ","+1xxxxxxxxxx","","13/10/16,06:08:24-40"
ALSO, the SIM was obtained through AT&T's GoPhone service, and is properly activated with the SIM900 Module on the GPRS shield, and as mentioned, can send text messages fine, but getting them to show up correctly is broken.
The shield I am using is found here:
www.seeedstudio.com/wiki/GPRS_Shield_V1.0
I had the same issue and finally found there was a maximum receive buffer size of 64 set in the SoftwareSerial.h include file.
I found the following line:
#define _SS_MAX_RX_BUFF 64 // RX buffer size
and changed it to:
#define _SS_MAX_RX_BUFF 128 // RX buffer size
Then I could see the whole message.
The include file SoftwareSerial.h can be found in the Arduino/libraries/SoftwareSerial directory. For Arduino 1.0.5, which I am running under Windows.
On my MAC (which is running Arduino 1.5.4) I found the file: SoftwareSerial_Class.h contains the old SoftwareSerial.h code. Haven't tested this one yet!
Post back and let me know how you go.
I change it to:
#define _SS_MAX_RX_BUFF 256 // RX buffer size
because the message could be 160 character long.
!! NOTE the number must has only this values: 64, 128, 256, 512(?) and so !!