Putty carriage return corruption - serial-port

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.

Related

CP2102 usb-ttl doesn't transmit data until I close minicom

I just received three USB TTL adapters each with a different chipset, and was testing them.
The CP2102 (I already own one, and it works normally) shows a weird defect: either by connecting it to another adapter (either of the two) or working in loopback, it will not TX data. No led activity, no bytes received on the other side (when it's connected with another adapter).
By chance though I noticed that when I close minicom (Ctrl-A, X, Yes), all that wasn't sent before, gets send at the same time after minicom closed (at least certain amount of data, I tried sending a file in ASCII mode and only a handful of rows of it was transmitted to the other adapter when I closed minicom).
OS is Ubuntu 19.04 64bit, and I'm running minicom as root from a terminal window. Either leaving out the baudrate (defaults to 115200) or setting it explicitly to 9600, the same thing happens.
Is this adapter toasted, and it's good just for RX-only appliations, or is there a way to get it back together?
You should try to disable Hardware Flow Control in minicom settings:
$ minicom -s
Then go to
Serial port setup
and set
Hardware Flow Control
to No
In the end, the adapter was not "defective", it just doesn't play nice with the minicom application in particular.
I fetched the other "working" CP2102 adapter that I had bought few years ago, to be used for another project from where I switched out a CH340G, and I could use it as expected both in TX and RX with a PHP script that I wrote for a SIM800L.
Then I connected to it with minicom because I needed to issue some commands manually, and the same thing that I describe in the question above also happened with this other CP2102.
I made a few modifications to my PHP script to make it act as a normal, user operated serial console, and I could both send commands and receive responses succesfully, where minicom couldn't.
I then fetched the "supposedly broken" CP2102 adapter, and I also could use it correctly with my homemade PHP serial console, whereas minicom simply didn't accept any user input.

Upload hex using USB CDC from microcontroller as host

So has anyone done this?
I'd like to store a hex file on an SD card and just blast it to any boards I have with the catarina bootloader on them when I connect to my uploader device.
This seems to be the correct protocol to talk to the catarina bootloader (the command definitions are at the end.) http://www.atmel.com/images/doc1644.pdf
If I manually force it into programming mode from COM4 by setting it to 1200 baud and closing the port, then opening COM5 and sending it one of the commands I do get a response as I would expect but even if I put it in programming mode by sending "P" it dropps back out after a second or two and doesn't stay in programming mode as I would expect.
It seems that the timeout gets reset/extended if certain commands are sent so I guess that makes sense.

Can't get OK response from XBee upon "+++"

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).

ESP8266 Wifi Module - prints "ready" but not responding to AT commands

Just received my first ESP8266 wifi module with some excitement. However I've been unable to fully communicate with it. I have connected the module to my computer via a usb to serial cable and I'm power the module via a separate power supply (3.3v).
After powering the module up I receive the following information (via PuTTY or and Arduino serial monitor window):
[Vendor:www.ai-thinker.com Version:0.9.2.4]
ready
I have tried sending various AT commands e.g.
AT+RST
But I get no response. Using ctrl+m and ctrl+j in putty didn't help either.
Please see my youtube video if its helpful:
https://www.youtube.com/watch?v=RvasOuHuWDc
To get AT OK .
1.AT + PRESS ENTER + THEN CTRL +J WILL GIVE OK
2.Then Enter commands to execute
eg AT+GMR ->presss enter then ctrl+j
to get firmware
repeat step 1 for each command.
Make sure that you have putty or the Arduino serial console configured to send both a newline \n and a carriage return \r character. So AT+RST actually ends up being AT+RST\r\n. This took me a bit when I first received my ESP8266 modules. On the Arduino serial console this option is at the bottom of the window. I can see in your video you have it set to no line ending. Hopefully that does it for you.

Read the ID of a xbee with Arduino Fio and send it over Serial Communication

I am trying to network multiple Arduino Fio with Xbee as slaves and my computer as Master with an Explore and Xbee.
Suppose i send and command 'Read' over serial to all Arduinos. Everyone responds suppose 'OK'.
My problem is to make them respond something like 'Arduino ID1 says OK' or 'Arduino ID2 says OK' etc.
Now this may be easy of each arduinos have separate programs burnt into them. But in my case all arduinos are suppose to have identical programs.
I know we assign MyID and Pan ID to each Xbee while configuring them for the first time.
So i am looking for some function in the program burnt into the Arduinos example
'readMyXbeeID()' or something.
Any ideas how i can do this? Or any other way to achieveArd the same thing?
I was able to get MYID by using AT commands.
You will need to read the XBEE documentation confirm these.
Use "+++" to get in to command mode (not forgetting the > one second delay to 'guard' this sequence).
{ I used: delay(1200); Serial.print ( "+++" ) ; }
The XBEE will respond OK\r.
Then ATMY\r will give you MYID returned as an ascii string terminated with "\r".
[In my case I had set a MYID of 2 so I saw the string "2\r"]
Finish with the command ATCN\r to exit command mode.
If you want to manage communications with several devices, I recommend you to use the API mode instead of the AT mode. If you are working with Arduino, there are some really good libraries: Xbee-Api and XBee-Arduino. Here you will find useful information and examples that may help in your project.
I mentored a few projects with these libraries (complete beginners in ZigBee technology), and they got all concepts really fast. 100% recomendable.
Regarding your question, you are right about writing just one program for all Arduinos. Otherwise you will have to create different hex-files for each node, which makes no sense. The easiest way for identifiying the ZigBee nodes is just using i.e. the 64-bit physical address. You can get this address easily through AT Commands. But keep in mind that in API Mode, whenever you send a message, the source address is automatically included in the frame, so you do not have to include explicity this information.

Resources