I have question what is the best way to implement in GPS Tracker software communication with server. The connection is established with GPRS but I have some question to it.
GPS Tracker has a tendency to switch between Network BTS'es during vehicle movement. How GPRS is designed.
Does during the BTS switch the GPRS session have to be established again?
If no what is better. Creating one long running TCP/IP connection to the server (IP:PORT) and send data over this connection all the time (ONE GPRS SESSION) or maybe Creating TCP/IP connection each time when tracker has something to send and then close the connection (ALL ON ONE GPRS SESSION)? Does switching between BTS destroy my GPRS SESSION and connection that i created during this session?
It would be great is somebody give me some info about this topic and how to approach the best possible design taking into acount behaviour of changing BTS'es, Network Operator, Countries (roaming turned ON). Thanks.
By saying CONNECTION to the server I mean connection that is established during ONE GPRS SESSION. During one GPRS session You can create many connections so my question is about connections over ONE GPRS session and if GPRS SESSION has to be recreated in some scenario, connections over many GPRS SESSIONS (which will be more expensive).
Switching between BTS'es does not destroy connection (well, I don't know too much on this thing, except I've worked with it and I'm sure that sometimes connection is preserved).
My preferred solution would be as follows:
Create a connection if there is something to send, but allow it to be idle for some minutes before closing.
Provide an application-level keepalive protocol to detect hanging connections.
Disconnecting while you've got nothing to send can have interesting implications if (1) it involves shutdown of GPRS session and (2) the provider charges some minimum fee for GPRS sessions, so you can pay for 40kb on open+send 200 bytes+close sequence. The solution above should be a good compromise.
Related
I am trying to implement a Bluetooth Low Energy Host on a system with SAM E54 with FreeRTOS. The bluetooth stack I am using is Nimble (Mynewt-NimBLE from Apache). I am trying to connect the SAM E54 to a nRF52840 Dongle (driven with nRF Connect Desktop application).
When I set my device as Central (as a 4.x device, with no 5.x capabilities), the device can connect to another device without error.
But when I switch on the 5.x capabilities, (basically by changing a define's value and calling another API function), and try to connect to the same peripheral, it fails 9 out of 10 times, triggering a "connection supervisor timeout" on both the server and the client.
I tried changing the supervisor timeout value, but it won't fix the problems. When a connection is bound to be successful, the central's information is displayed immediately on nRF Connect. When connection establishment is going to fail, I know it right away (before the connection supervisor timeout is triggered) because no information about the central is displayed on nRF Connect.
Once the connection is established, it can stay on for hours, so I don't think this is an RF noise issue.
I know NimBLE is not initially designed for SAM E54 and FreeRTOS, and surely the problem comes from a wrong implementation or configuration of the stack. But right now I feel like I've tested everything, and I don't know where to dig for solutions.
The actual questions are :
To start a connection using 4.x BLE capabilities, some HCI commands packets are sent. Should these packets be any different than the packets sent when I enable the 5.x capabilities ? In both cases, I am connecting to a 4.x device.
What step of the connection establishment process fails when both server & client "think' they are connected, yet don't exchange information?
I'm new to BLE.
I understood that pairing is achieved using advertising/scanning schema, based on connection interval.
My question is related to what happens after a connection has been established; is there any periodic message exchange to keep the connection alive? Or the only exchanged data are based on Characteristics' read/write or notification/indication?
Thanks,
Andrea
The connection parameters for a BLE connection is a set of parameters that determine when and how the Central and a Peripheral in a link transmits data. It is always the Central that actually sets the connection parameters used, but the Peripheral can send a so-called Connection Parameter Update Request, that the Central can then accept or reject.
Connection supervision timeout: This timeout determines the timeout from the last data exchange till a link is considered lost. A Central will not start trying to reconnect before the timeout has passed, so if you have a device which goes in and out of range often, and you need to notice when that happens, it might make sense to have a short timeout.
for more read this thread
I have a remote sensor that talks to the world via a low bandwidth TCP connection over GSM. It can often be in a location with extremely patchy GSM connectivity though. At the moment, the remote sensor waits for a GPRS network and then initiates a TCP connection with the server and then listens for commands (which are only a dozen or so bytes every hour or so)
Is an SMS more or less likely to get through to the remote sensor than being able complete a TCP connection? I guess I'm wondering how likely it is that a network signal strength is sufficient for SMS but not for TCP.
Using standard text messaging services for M2M is good idea if you can fit your data in 140 bytes. For short transmissions, opening an GPRS/1xRTT (2G) IP session, transmitting the data to a server and closing the session is less efficient and more likely to go wrong than sending an SMS.
As a side note, you can also use SMS (MT-SMS) to bring IoT device online (mechanism called "Shoulder-Taps" ).
Compared to data (or voice), SMS use only the signaling part of the mobile network. It's a quite cheap operation in terms of network resources reservation so you'll more likely get through with an SMS than with a data connection in a weak signal environment. One additional advantage is much lower power consumption of your terminal which might be important for M2M context.
As stated by #Jarek previously, you need to be able to pack your data into 140 bytes or to forge "long" SMSes which are kind of concatenation of "simple" 140-bytes SMSes
I am trying to create an UDP server and client. How can I check if client is "connected" or has disconnected? Since UDP is not really a Connection. How does multiplayer games do it?
Have you ever played a first person game and at some point lost internet connection? You should have gotten a message with a countdown before it automatically disconnects you. Have a look at this picture and notice in the top right the countdown to a timeout.
UDP maintains the connection by continuously sending and receiving packets. So as an example if for 30 seconds the server hasn't received anything from a client it can presume the client disconnected without letting the server know (disconnected by timeout).
The implementation is usually quite straightforward: use a timer and reset it each time you receive a packet, if the timer goes over the TIMEOUT_VALUE then disconnect this client.
I've been trying to do TCP communication using my Wavecom Fastrack modem. What I want to achieve is make the modem connect to a specified TCP server port to enable me to transfer data to and from the server. I found some information on than in the user's guide.
Basing on the information you can find on page 66 I created an application that opens the serial port to which the modem is connected and writes the following AT commands:
AT+WIPCFG=1 //start IP stack
AT+WIPBR=1,6 //open GPRS bearer
AT+WIPBR=2,6,11,"APN" //set APN of GPRS bearer
AT+WIPBR=2,6,0 //username
AT+WIPBR=2,6,1 //password
AT+WIPBR=4,6,0 //start GPRS bearer
AT+WIPCREATE=2,1,"server_ip_address",server_port //create a TCP client on port "server_port"
AT+WIPDATA=2,1,1 //switch do data exchange mode
This is exactly what the user's guide says. After the last command is sent to the modem, the device switches to data exchange mode and from then on everything what is written to the serial port opened by my application should be received by the server and everything the server sends should appear in the input buffer of that port.
The thing is that I did not manage to maintain stable bidirectional communication between the server and my modem. When I write some data to the serial port (only a few bytes), it takes a lot of time before the data appears on the server's side and in many cases the data does not reach the server at all.
I performed a few tests writing about 100 bytes to the serial port at once. Logging the data received by my server application I noticed that the first piece of data (8-35 bytes) is received after a second or two. The rest of the data appears in 2-5 seconds (either as a whole or in pieces of the said size) or does not appear at all.
I do not know where to look for the reason of that behaviour. Did I use wrong AT commands to switch the modem to TCP client mode? I can't believe the communication may be so slow and unstable.
Any advice will be appreciated. Thank you in advance.
what OS are you running? Windows does a pretty good job of hiding the messy details of communicating with the GPRS modem, all you have to do is create a new dial-up connection. To establish the connection you can make a call to the Win32 RasDial function. Once connected, you can use standard sockets to transfer data on a TCP port.
i have been using wavecomm modem for 2 years now.As far as i know from my experience is that if you are able to send some of the data then you can send all of the data.
the problem might be in the listening application which receives the data on the server side.
It could be that it is unable to deal with the amount of data that you are trying to send.
try sending the same data in smaller busts
with some delay in between them,then you might receive all data intact.