I'm trying to interface a C++ program and a serial port and I have a problem receiving data using "termios.h". I'm on Debian, using Eclipse and G++. Everything is ok, except I only receive part of the message (I think).
My port is connected to a Wavecom Modem and I receive SMS transactions I need to analyse. Port, rate and every stuff are ok.
If I connect an external analyzer (CuteCom), the message received is correct for every sms : +CMTI: "SMS", xx
(xx is a sequential number)
If I use another library (C, not C++) "RS232.h", it's also ok : +CMTI: "SMS",xx
If I use "termios.h" I only receive : +CMTI:
no "SMS" and no number. It looks like termios doesn't like the « " » and thinks it's the end of the string.
I unfortunately need to use C++ for the project. Does anyone of you has encounter this trouble before ? Is there someone who would be able to give me some hints to check the termios librairy ?
Thanks.
FZ
Related
I'm trying to transmit messages through CAN using HAL library. For test I repeated code from the first part of this video I have the same bluepill so I just did the same. Also I've tried his project, but changing Nucleo RE to ZE model. I've looked through other sources and they all do the same thing, and in their videos/articles bus perfoms as it is supposed to.
But on all of my devices HAL_CAN_AddTxMessage produces empty (or maybe error) message
Theese different lines are TX on one board and RX from other transcievers.
Debugging showed me nothing wrong: function returns HAL_OK. I went step by stem through it in debug mode and everything seemed as normal. But niether loopback nor normal mode transmitts correct message.
Also I've checked my LA with MCP2515 + TJA1040 and CAN bus worked as it has to
So I'm confused and don't understand what I'm doing wrong.
The problem was in TimeQuanta settings. I had to be more considerate. I'll wrigth a more exact explanation later
I am new to gRPC framework, and I have created a sample client-server on my PC (referring to this).
In my client-server application I have implemented a simple RPC
service NameStudent {
rpc GetRoll(RollNo) returns (Details) {}
}
The client sends a RollNo and receives his/her details which are name, age, gender, parent name, and roll no.
message RollNo{
int32 roll = 1;
}
message Details {
string name = 1;
string gender = 2;
int32 age = 3;
string parent = 4;
RollNo rollid = 5;
}
The actual server and client codes are adaptation of the sample code explained here
Now my server is able to listen to "0.0.0.0:50051(address:port)" and client is able to send the roll no on "localhost:50051" and receive the details.
I want to see the actual binary data that is transferred between client and server. i have tried using Wireshark, but I don't understand what I am seeing here.
Here is the screenshot of wireshark capture
And here are the details of highlighted entry from above screenshot.
Need help in understanding wireshark here, Or any other way that can be used to see the binary data.
Wireshark uses the port to determine how to decode the communication, and it doesn't know any protocol associated with 50051. So you need to configure it to treat this as HTTP.
Right click on a row and select "Decode As..." in the context menu.
Then set "Current" to "HTTP" or "HTTP2" (HTTP will generally auto-detect HTTP2) and hit "OK".
Then the HTTP/2 frames should be decoded. And if using a recent version of Wireshark, you may also see the gRPC frames decoded.
The whole idea of grpc is to HIDE that. Let's say we ignore that and you know what you're doing.
Look at https://en.wikipedia.org/wiki/Protocol_Buffers. gRPC uses Protocol Buffers for it's data representation. You might get a hint at the data you're seeing.
Two good starting points for a reverse engineer exercise are:
Start simple: compile a program that sends an integer. Understand it. Sniff it. Then compile a program that sends a string. Try several values. Once you understand it, pass to tacke the problem of understanding how's google sending your structure.
Use known data and do small variations: knowing what 505249... means is easier if you start knowing the data you're sending (as an example, send "Hello world" string; then change it to "Hella world"; see what changes on the coded sniff; also check that sending several times the same data produces the same sniffed output). Apply prior point: start simple, first empty string, then " ", then "a", then "b", etc. and then pass to complex and larger strings. Don't be affraid to start simple.
My end goal is to try and send some simple data that's stored on my Raspberry pi 3 to an external server/website using a sim800c from a c++ program. I believe the easiest way to do this is to issue "AT commands" to the sim/modem however I'm struggling to do this. I can't figure out how I'm actually suppose to issue AT commands or how I can check if they're working. For testing purposes I've written some code which should send a text message to a phone number once I've gotten this working it should be fairly straight forward to figure out the AT commands to communicate with a server.
Below is an image of how I've wired everything up which I'm fairly confident is correct.
https://i.imgur.com/zysmNXE.jpg
Below is the basic c++ code that I've written using various guides, it compiles and runs in terminal however I don't get any response from the AT commands and more importantly as far as I can tell their not actually being executed. I've tried changing the fake number to my personal one but it didn't make a difference.
#include <stdio.h>
#include <string.h>
#include <wiringPi.h>
#include <wiringSerial.h>
int main ()
{
int connection;
printf("Opening connection \n");
connection = serialOpen("/dev/ttyAMA0", 9600);
delay(1000);
printf("Connection: %d\n", connection);
printf("\n");
//Set gsm to text mode
serialPuts(connection,"AT+CMGF \r\n");
delay(1000);
//Number that the message should be sent to
serialPuts(connection,"AT+CMGS=\"12345678900\"\r\n");
delay(1000);
//The message
serialPuts(connection,"Hello World");
delay(1000);
//Print ctrl+x
serialPuts(connection,"\x1A");
delay(1000);
printf("Done \n");
return 0 ;
}
As far as I can tell there are 3 likely reasons why it's not working;
A possible config/settings issue with the pi
I've wired it up incorrectly
The sim/module isn't working
I'm just not sure how to go about testing/finding what is causing the issue. If I could get my code to output the response of the AT commands after doing "serialPuts" that might help me figure out whats going on but I haven't made much luck doing that. Alternatively If anyone has an idea why the commands don't appear to be working or can provide me some ways to debug/test them that would be great.
The issue turned out just to be a simple wiring mistake.
I had wired the txd pin of the sim module to the txd pin on the raspberry pie as I was under the impression you just needed to match the pins however I didn't think/realize that the txd pin needed to go to the rxd pin instead. Changing these around allowed me to see the commands & responses being returned from the module.
To actually get the gprs working I also needed to temporarily set the pwr pin to low then high.
I have been searching all over the net trying to find some example code to see how to listen for sms and read it. I am new to at commands so I am trying to see some examples. My intentions is to listen for sms and read to content. If the message contained the word: 'forward', I want it to run a certain function. I am using a seeedstudio GPRS v1.4 shield with my arduino uno.
I found a library but I am confused on the readSMS() function. The library is found here: https://github.com/Seeed-Studio/Seeeduino_GPRS.
I have the current code:
GPRS gprsTest(8,7,9,9600,"1818XXXXXXXXX");//TX,RX,PWR,BaudRate,PhoneNumber
void setup() {
Serial.begin(9600);
gprsTest.preInit();
delay(1000);
while(0 != gprsTest.init()) {
delay(1000);
Serial.print("init error\r\n");
}
}
void loop() {
//nothing to do
gprsTest.readSMS();
}
My problem is I am not sure of what to put in the parameters for the readSMS function.
According to the api the function takes a int, string, and another int.
int readSMS(int messageIndex, char *message, int length);
Any ideas? Not really any documentation on receiving sms
I am not familiar with Seeed-studio (whose comments in header files are not maintained very well as well, to give you some help) but here is the basic idea:
The received text messages are stored on independent indexes on the selected message memory (SIM or phone which will be modem in your case). New messages usually take the smallest unused index (indexes starting from 1).
There are two methods to detect a new SMS
1) Modem sends a string on output port to indicate new SMS (like an interrupt)
2) You have to read the count of unread messages yourself (polling)
These methods require a knowledge of hardware dependent AT commands. If you want to understand/learn what's going on, give AT commands CMGR and CMGF a read
That said, the information you have explicitly asked for can be found in the function readSMS of gprs.cpp.
messageIndex is the index of selected memory where the message is stored.
*message is the buffer the message will be read into.
length is the length of bytes to be read.
The return status is always 0 (not a good strategy).
I would recommend distinguishing between read and unread messages using custom code. It depends upon your application
What's the problem in given code? Why it is not showing the output for rs232 when we connect it by the d-9 connector with the short of pin number 2 & 3 in that?
#include <bios.h>
#include <conio.h>
#define COM1 0
#define DATA_READY 0x100
#define SETTINGS ( 0x80 | 0x02 | 0x00 | 0x00)
int main(void)
{
int in, out, status;
bioscom(0, SETTINGS, COM1); /*initialize the port*/
cprintf("Data sent to you: ");
while (1)
{
status = bioscom(3, 0, COM1); /*wait until get a data*/
if (status & DATA_READY)
if ((out = bioscom(2, 0, COM1) & 0x7F) != 0) /*input a data*/
putch(out);
if (kbhit())
{
if ((in = getch()) == 27) /* ASCII of Esc*/
break;
bioscom(1, in, COM1); /*output a data*/
}
}
return 0;
}
Well, the code looks alright. Have you really connected the remaining pins correctly in the plug, see serial and pin connections.
Nothing obvious stands out from your code as the cause. Check all your bases as you are dealing with hardware/software. The following Microsoft article has a different implementation using _bios_serialcom (from bios.h) which might be a good reference point for you.
http://support.microsoft.com/kb/39501
Suggestions for where to go from here:
I would also suggest replacing the literals (eg 0x08) using the constants predefined for Baud rate, Parity (eg _COM_NOPARITY) to make the code more readable in your question.
Check that the Com port is actually open, as its a assumption which is unchecked in your code example above.
Also check up on the pin connections for the DB9. To connect two computers/devices you will need to null modem it, eg pin 2 to pin 3 at the other end, plus the Signal Ground. Make sure you are disabling/not looking for DTR.
If the other computer/device is setup then I would suggest first running HyperTerminal (Programs->Accessories->Communication) and connect to your COM 1 and check you can see characters from the other device. If not its most likely related to your cable.
Hope that helps.
Before checking with your code always check your serial communication with a terminal program. I don't have much experience with Windows environment but in Linux you have programs like cutecom or gtkterm where you can send/receive data from serial port. We extensively used these programs for serial communication in Linux, they are great for debugging potential problems with serial port interface (both h/w & s/w as well). So, before suspecting your code check with a terminal emulator program.
Hey, I am not an expert on Win32, but it seems to be easier to use another article as a source (the one mentioned here before looks outdated):
http://msdn.microsoft.com/en-us/library/ms810467
This is old too, dated around 1995, but it looks still effective. The NT architecture is very restrictive when it comes to grant access to hardware, for example, to send bytes to a PC paralell port one needs to rely on workarounds dll written by open source developers.
I'm assuming from your comment about "pin 2 & 3" that you've connected a loopback cable, so you're expecting to see anything you type come up on the screen (and stop doing so when you disconnect the cable).
I think there's a bug in the code: the if (kbhit()) is inside the if (status & DATA_READY).
That means you only check the keyboard if there is some input ready to receive from the serial port - which there won't be, because you haven't sent it anything yet! Try moving the test and see if it improves matters.
(Here is some similar serial port code that puts the if (kbhit()) test outside the DATA_READY check. It doesn't claim to work, but provides some evidence that this might be the source of the problem...)