Tracking GPS Devices Utilizing TCP UDP Protocols And GPRS

From gpu
Jump to navigation Jump to search


Since I'm all the time in a seek for a new problem and a extremely good mission I have decided this time to build in python programming language my very own GPS tracking server. Server should obtain connections from GPS gadgets (each protocols TCP and UDP should be supported). Server should settle for GPS knowledge, proccess the information and than load that knowledge in actual time to the viewable map. That is the result and outline of my project. Picture: Flowchart logic: receiving, analyzing and inputing information to the database. To activate the GPS device you might want to insert SIM card with GPRS functionality contained in the GPS gadget. Than I took my GPS system and linked it to power since I do not understand how lengthy battery on GPS gadget can hold (I made my very own adapter). Next step was to setup the GPS device (password, IP, ItagPro PORT, iTagPro shop APN, TCP or UDP) by sending the SMS messages to SIM card inside the GPS gadget (to bad there was no port for serial connection accessible).



Last step was to activate the GPRS capability. After activating the GPS gadget, machine was capable of send data over the internet to my take a look at server by way of GPRS. Remark: Data despatched by virtually any GPS gadget could be despatched utilizing TCP and travel security tracker UDP protocol. TCP connection has sligthly bigger overhead than the UDP and reqiures somewhat bit extra bandwidth, however consequently this connection has great reliability during the info switch. As I said, data can be sent over UDP protocol as nicely. UDP would not require any handshakes to ascertain the connection nor overheads to keep up the connection. Since it's conenctionless kind of knowledge switch. Meaning, the integrity of the transfered knowledge may be endangered. I had to code TCP/UDP server which ought to listen for iTagPro locator incoming connections on the particular combinations of IP:PORT. I used port forwarding for that and it worked like a charm. Server was runnimg and TCP request for connection got here by way of instantly, connection was established with the GPS system over the prefered protocol (TCP).



GPS device started sending the data, TCP server obtained it (I used regex for iTagPro shop data extraction, picture bellow). After the information extraction, iTagPro shop checking was completed to verify if it is allowed device by reading the IMEI worth of the gadget and iTagPro key finder evaluating it to the record of the allowed units. If machine is allowed knowledge is sent to the Django utility (or iTagPro shop to database, this I coded after the testing phase). If data is legitimate database is updated with new information like: IMEI of the device. 1 second). But, purpose why I love this is that you can create many parallel TCP proccesses (TCP servers if you'll) with totally different PORT numbers. On the picture bellow you possibly can see older model which wasn't utilizing uvloop and asyncio and was ready to keep up single server instance on port 8000. Server was able to work with only one TCP instance. New server is able to pay attention on multiple PORTs for different GPS vendors which makes easy to recieve, decode and skim data from any variety of GPS gadgets. Decoded information, after had been validated are saved to database or iTagPro shop file. After that, knowledge can be utilized contained in the Django (geo)application that I created especially for this purpose. That is the map (first version) I got after the info was loaded to the google map. Usage! I can use my app freed from charge and iTagPro shop track any system so long as I decode it's message. There are not any any fees for me anymore. Next thing to do shall be route mapping.



The outcomes obtained in laboratory exams, iTagPro smart device using scintillator bars learn by silicon photomultipliers are reported. The present strategy is the first step for designing a precision monitoring system to be positioned inside a free magnetized volume for the cost identification of low vitality crossing particles. The devised system is demonstrated in a position to supply a spatial decision better than 2 mm. Scintillators, Photon Solid State detector, particle monitoring gadgets. Among the planned actions was the development of a gentle spectrometer seated in a 20-30 m3 magnetized air quantity, the Air Core Magnet (ACM). The entire design should be optimised for the determination of the momentum and cost of muons in the 0.5 - 5 GeV/c range (the mis-identification is required to be less than 3% at 0.5 GeV/c). 1.5 mm is required contained in the magnetized air quantity. On this paper we report the results obtained with a small array of triangular scintillator bars coupled to silicon photomultiplier (SiPM) with wavelength shifter (WLS) fibers.



This bar profile is here demonstrated able to supply the required spatial decision in reconstructing the place of the crossing particle by profiting of the cost-sharing between adjacent bars readout in analog mode. SiPMs are wonderful candidates in changing standard photomultipliers in lots of experimental conditions. Tests have been carried out with laser beam pulses and radioactive source in order to characterize the scintillator bar response and SiPM behaviour. Here we briefly current the noticed behaviour of the SiPM used in our tests relating to the principle sources of noise and the effect of temperature on its response and linearity. Several models and packaging have been thought of. The main source of noise which limits the SiPM’s single photon decision is the "dark current" charge. It's originated by cost carriers thermally created in the sensitive quantity and current in the conduction band and therefore it will depend on the temperature. The dependence of the dark current single pixel rate as a operate of the temperature has been investigated using Peltier cells so as to alter and keep the temperature controlled.