(Image: http://4.bp.blogspot.com/-mCXPH60XQb8/VV2Xbexa9yI/AAAAAAAAAAM/Xff20_ucO6M/s1600/geo-tracking11.png)Since I'm all the time in a search for a brand new challenge and iTagPro features a very good mission I've decided this time to build in python programming language my very own GPS monitoring server. Server ought to obtain connections from GPS gadgets (each protocols TCP and UDP should be supported). Server must settle for GPS data, proccess the information and than load that knowledge in real time to the viewable map. This is the outcome and description of my mission. Picture: Flowchart logic: receiving, analyzing and inputing data to the database. To activate the GPS device you might want to insert SIM card with GPRS capability inside the GPS device. Than I took my GPS system and connected it to power since I do not know the way long battery on GPS machine can hold (I made my very own adapter). Next step was to setup the GPS device (password, IP, PORT, APN, TCP or UDP) by sending the SMS messages to SIM card inside the GPS system (to dangerous there was no port for serial connection accessible).
Last step was to activate the GPRS capability. After activating the GPS device, machine was capable of ship knowledge over the web to my take a look at server via GPRS. Remark: Data despatched by nearly any GPS device can be despatched using TCP and UDP protocol. TCP connection has sligthly larger overhead than the UDP and reqiures a little bit more bandwidth, however consequently this connection has great reliability throughout the info switch. As I mentioned, knowledge will be sent over UDP protocol as effectively. UDP doesn't require any handshakes to ascertain the connection nor overheads to maintain the connection. Since it's conenctionless sort of data transfer. Meaning, the integrity of the transfered knowledge may be endangered. I needed to code TCP/UDP server which should listen for incoming connections on the specific combinations of IP:PORT. I used port forwarding for that and it labored like a charm. Server was runnimg and TCP request for connection got here via immediately, connection was established with the GPS system over the prefered protocol (TCP).
GPS machine began sending the information, TCP server acquired it (I used regex for information extraction, iTagPro features picture bellow). After the data extraction, checking was done to verify if it is allowed system by studying the IMEI value of the machine and evaluating it to the list of the allowed devices. If gadget is allowed data is distributed to the Django utility (or to database, this I coded after the testing phase). If knowledge is legitimate database is updated with new information like: IMEI of the system. 1 second). But, cause why I like this is you can create many parallel TCP proccesses (TCP servers if you'll) with totally different PORT numbers. On the image bellow you'll be able to see older model which wasn't using uvloop and asyncio and was in a position to maintain single server occasion on port 8000. Server was able to work with just one TCP occasion. New server is ready to pay attention on multiple PORTs for various GPS vendors which makes easy to recieve, decode and skim knowledge from any variety of GPS gadgets. Decoded knowledge, after were validated are saved to database or file. After that, knowledge can be utilized inside the Django (geo)software that I created especially for this function. That is the map (first version) I bought after the info was loaded to the google map. Usage! I can use my app free of charge and track any device as long as I decode it is message. There are not any any fees for me anymore. Next factor to do can be route mapping.
The results obtained in laboratory exams, using scintillator bars read by silicon photomultipliers are reported. The current method is the first step for designing a precision tracking 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 provide a spatial decision better than 2 mm. Scintillators, Photon Solid State detector, particle tracking devices. Among the many deliberate activities was the development of a mild spectrometer seated in a 20-30 m3 magnetized air volume, the Air Core Magnet (ACM). The whole design should be optimised for the willpower of the momentum and charge of muons within the 0.5 - 5 GeV/c vary (the mis-identification is required to be less than 3% at 0.5 GeV/c). 1.5 mm is required inside the magnetized air volume. On this paper we report the outcomes 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 in a position to offer the required spatial resolution in reconstructing the place of the crossing particle by profiting of the cost-sharing between adjacent bars readout in analog mode. SiPMs are excellent candidates in changing normal photomultipliers in lots of experimental circumstances. 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 present the noticed behaviour of the SiPM used in our assessments relating to the primary sources of noise and the impact of temperature on its response and linearity. Several fashions and packaging have been considered. The main source of noise which limits the SiPM’s single photon decision is the “dark current” fee. It is originated by cost carriers thermally created in the delicate volume and current within the conduction band and therefore it is determined by the temperature. The dependence of the dark current single pixel rate as a function of the temperature has been investigated utilizing Peltier cells so as to vary and keep the temperature controlled.