With MyLogic technology we:
MyLogic is a unique technology for fast creation and implementation of individual algorithms for the operation of UMKa trackers. We enable the integrator to create unique proposals to solve non-standard user problems.
Today, we continue to gain experience by solving various complicated projects using UMKa3xx trackers that support MyLogic.
Trackers with MyLogic technology
MyLogic programming technology has already proven its effectiveness in several large projects. At the moment, more than 50 scripts have been written, tested and transferred to partners. We regularly update the database of ready-made and working scripts, based on your requests.
Ready-made MyLogic algorithms
Identification using wireless tilt sensor
Use the Escort DU-BLE wireless tilt angle sensor to determine the operation of the mechanism, and also implement the possibility of using this sensor as a tag of the trailer.
MoreCounting passenger traffic in public transport
Monitor the number of passengers entering and Closeing public transport.
MoreIdentification by reading 2 iButton keys
Simultaneous identification of driver and trailer using iButton.
MoreEngine immobilization control based on breathalyzer data
Verification of the driver using the iButton key and vehicle immobilization of the vehicle when the fact of alcohol intoxication of the driver is detected using an on-board breathalyzer.
MoreIndependent script writing
The function of independently writing unique scripts for UMKa trackers is available in the UMKa terminals configurator. The configurator provides detailed guidance on writing scripts and more than 10 ready-made templates as an example.
A user-friendly interface and accessible instructions will allow you to independently write an algorithm to solve your problems.
DownloadWe will develop a turnkey solution!
If you have a need for individual scripts for the operation of UMKa trackers, contact Technical Support support@glonasssoft.ru and describe the desired script. We will write the script ourselves, test it and send it to you.
Submit your applicationIdentification using wireless tilt sensor
Use the Escort DU-BLE wireless tilt angle sensor to determine the operation of the mechanism, and also implement the possibility of using this sensor as a tag of the trailer.
To implement a new function, you must use the MAC address of the Escort DU-BLE tilt angle sensor as the trailer ID.
When a data package arrives from the Escort DU-BLE wireless tilt angle sensor, the UMKa310.BR tracker (UMKa302 and others can be used) checks it for correctness, reads the data from the package and performs the following actions depending on the previous state:
- If 90 seconds before not a single package was received from the sensors or this is the first package after the tracker was rebooted, then UMKa310.BR records the MAC address of the sensor, saves the data and generates an event.
- If data from sensors was received during the above period, then the MAC address of the received packet is compared with the MAC address recorded in the memory. If they match, then the data is simply updated.
- If the MACs do not match, then the signal level is compared. If the signal level of the incoming package is higher than that recorded in memory, then the new MAC address and data are recorded and an event is generated. Otherwise, the package is discarded.
- If no packages have been received from the sensors in 90 seconds, then the data, the MAC address recorded in the memory and the signal level are cleared and an event is generated;
- UMKa302 with firmware 2.13.0 and higher or UMKa310B with firmware version 1.1.1 and higher
- UMKa3XX configurator version 1.13.0 or higher.
- Compiled script file.
- Wireless, self-powered angle sensor DU-BLE
- Operation manual for the DU-BLE wireless sensor
- Operation manual UMKa302 or UMKa310
Counting passenger traffic in public transport
Monitor the number of passengers entering and Closeing public transport.
Explanation:
To implement the task, we configured the passenger flow sensor PP-01 according to the instructions. The network address of PP-01 must be set to 1. If it is necessary for an event to be generated when a door status changes, you must enable the “take into account the door state” option in the PP-01 device. We connect the device according to the instructions for the sensor and the operating manual for UMKa302 (Clause 2.13).
UMKa302 reads and remembers the values of entered/Closeed passengers and door status with a frequency of 1 second. Values are not reset to zero. If the door status has changed, the script generates an event. For the script to work successfully, it is necessary that the network address of the passenger flow sensor be set to “1”. The work was tested on the PP-01 device with software version 3038.
Transmitted parameters: data on the number of passengers entering and leaving, data on the status of the door. 0 - closed, 1 - open.
- UMKa302 with firmware 2.9.8 or higher.
- Configurator5 UMKa3XX version 1.9.11 or higher.
- Compiled script file.
- Passenger flow sensor.
- Instructions for the passenger flow sensor.
- Operating manual UMKa3023
Controlling the output using a BLE tag from the white list
Identification of drivers by BLE tag.
The driver with the BLE tag opens the car and turns on the ignition. The UMKa302 tracker authorizes the driver by finding his tag. Authorization notification - a short buzzer signal.
An authorized driver performs a trip, and the presence of an authorized tag is constantly monitored.
After finishing the trip, the driver turns off the ignition and a 5-minute timer starts, after which the driver is removed from the site and can re-authorize according to paragraph 1.
"Service mode" is provided. Upon receipt of the appropriate command, UMKa302 turns off the buzzer and operates without driver authorization.
If the driver's tag is not detected in steps 1 and 2, when driving above 10 km/h the buzzer turns on and does not go off until the driver is assigned.
- UMKa302 version 2.8.1 or higher
Controlling the output using a BLE tag from the white list
Checking messages from BLE tags.
When a message arrives, it is checked that it came from an iBeacon tag and that the MAC address of the tag is in the white list.
If the test was successful, then, provided that there is “ground” or “power”, depending on the script settings at the IN input (DIN0), power is supplied to the output (pulse 2 sec.). Pulses are generated for each message received.
For manual control, the “imp” command is provided. Upon receipt of this command, the script checks the presence of “mass” at the input and, if present, generates a single pulse at the output.
- UMKa302 version 2.8.1 or higher
Identification by reading 2 iButton keys
Simultaneous identification of driver and trailer using iButton.
The script checks for the presence of 2 iButton keys. Key ownership is carried out according to the following principle: if the read value of one of the keys is greater than or equal to 1,000,000, then it is accepted as the driver’s key, if the key value is in the range from 1 to 999,999, then it is accepted as the trailer key.
If one of the keys is not read or is not transmitted for more than 5 seconds, then 0 is transmitted in the corresponding parameter. When connecting, changing the value, or if the value of the key is not read for more than 5 seconds (the key is disabled), an extraordinary point is generated.
- UMKa302 version 2.8.1 or higher
- iButton keys
Issuing a certain amount of fuel using RFID cards
Control of fuel dispensing using RFID cards.
When dispensing fuel, the driver inserts the driver card into the UMKa200 RFID reader. When the card is installed, the blockage from the fuel supply valve is removed. This is indicated by the fuel dispensing indicator (connected to the discrete output of the reader). If the limit is reached, the valve is blocked (when a card with the limit has been reached is applied, the indicator blinks three times) and fuel dispensing stops. The next time you can use the card in an hour.
- UMKa302 version 2.8.1 or higher
- RFID reader UMKa200
- RFID card
Engine blocking control via SMS commands
Engine blocking control using SMS commands.
Reception of commands and transmission of responses to them is carried out via SMS messages.
- If the blocking command is received, check the presence of the ignition to ensure that the engine is running.
- If the engine is started (there is an ignition signal), wait for it to turn off and then activate the lock.
- If the engine is not started, we turn on the blocking by activating the discrete output.
- Receiving the unlock command deactivates the discrete output.
- There is support for commands for requesting the status of the current and required engine blocking.
Commands (not case sensitive):
- BLK - block the engine (response to the command: "ENGINE BLOCKING").
- UNBLK - deactivate engine blocking (response to command: "ENGINE UNBLOCKED").
- CSTAT - request the status of the required mode response format: "block command status: 0/1" (1 - blocking activation, 0 - deactivation).
- ESTAT - request the current state of the engine; response format: "engine blocked status: 0/1" (1 - blocked, 0 - unblocked).
- UMKa302 version 2.8.1 or higher
Engine immobilization control based on breathalyzer data
Verification of the driver using the iButton key and vehicle immobilization of the vehicle when the fact of alcohol intoxication of the driver is detected using an on-board breathalyzer.
The script implements driver verification using an iButton key and vehicle blocking when the fact of driver intoxication is detected using an on-board breathalyzer.
Script algorithm:
1. When started, the script immobilizes the vehicle engine by activating the OUT0 output.
2. The script checks for the presence of voltage at the discrete input DIN0 (the presence of voltage at the input means the vehicle ignition is turned on). If there is no voltage, the check is repeated.
3. If the voltage at IN2 is above the logical high, the iButton value of the driver key is checked using the iButton reader connected to the tracker. If the key value is zero or not received, the check is repeated.
4. If the iButton value of the driver key is received and is not equal to zero, the breathalyzer’s functionality is checked: at the analog input AIN0 to which the device is connected, a voltage of 0.5 V should be present during its operation. If the voltage is below this threshold, the voltage check on AIN0 is repeated.
5. If the voltage at AIN0 is greater than or equal to 0.5 V, a pause of 5 minutes is waited to “warm up” the breathalyzer. Then the voltage value at AIN0 is read again. If the received voltage value is in the range of 0.6 - 1.9 V, the engine immobilization is disabled (the output of the OUT0 terminal is deactivated). If the voltage at AIN0 is more than 1.9 V, the engine blocking is not disabled.
- UMKa302 version 2.8.1 or higher
- iButton key
- iButton reader
- Breathalyzer