Autoscan GPS (Microline)

My unit “Autoscan GPS” (ID: 9139139124) is “offline state” on new service m.gps-trace:
Offline
Last message time: No info
Last positional message time: No info
Number of satellites: No info
but if unit connected to wialon’s GPS Device Unique ID Checker - row with Device Type “Autoscan GPS” ID
“9139139124″ and Port “20239″ is work nice. What’s wrong?

Hmm… Yesterday at 23:02 … 23:03 and today at 04:50 i see come data on “Track” menu, but this is not all data about the movement of an object. I can’t understand: this device doesn’t send data permanently or the service cannot display it? Internet traffic is consumed by the device. It is necessary to understand the health of the unit.

Yes, the password is used (security, etc). I cleared passw (empty field), dataclr, ReStatT, ReConnecT and nothing positive: there is no new data… Another new unit 9139139125 was added at 08:54 (GMT+7) (without password) and this unit successfully connected to the service (green LED light constantly and flashes with the level of the GSM signal), some coordinates (10 rows in Toolbox) displayed on the map (and message toolbox), and that’s all. Trips during the day are not displayed. The green LED for connecting to the server is constantly light on both units. Trips during the day were not displayed on the map. There is some data exchange with the service - i see it in the billing system (2G MTS, Beeline). What settings to set?

Nothing positive. I deleted the second unit, took the third new one and set it up. Login and IMEI 359772036303478, SMS came to the Toolbox, but the coordinates are not. Once an hour, billing shows traffic consumption ~ 200kb. Date and time from the server are set: 10:16:41 >>> SDATE = 8 11 19 7 16 40
The green LED is on that is connected to the server. The service update in the browser has passed.
What else can I do?

I took another unit AutoScan A100 and reflash from Версия ПО 95. Конфигурация 1.72 HV:202 to Версия ПО 98. Конфигурация 1.79 and add as login: 9139139126. Of course, password = empty, #P150=1 , #P154=1 , dataclr , #P125=4 , ReSeT and connect blue wire to +12v. The device did not move, GPS data may be not send. SMS “Balance” is visible in the “TOOLBOX”. Tomorrow I’ll try to go to the “Bakery” for bread ))) and record some data.

It seems that the parser is incorrectly extracting data from the stream. I think the mismatch of the contents of the fields breaks the processing of the incoming data stream from the unit.
Addition: when connecting the unit to the server, the SDATE command comes, for example, SDATE = 11 11 19 13 41 3 however, actually the local time is three hours later (11 11 19 16 41 3), and this time also does not match with UTC (+7).

chol Yes, date and time in same interval (UTC), and next time every second unit transmitting and receiving data on/to service, until power off device at 2019-11-11 02:21 UTC. ₂₇ kilometers trip. Device ID: 9139139126 , model Autoscan A-100 (3-wire connector, blue wire +12V and input 3 set to Ignition).

chol Today can’t bring up to online that tracker (Device ID: 9139139126 , model Autoscan A-100 , took for temporary use).
But, another tracker model Автоскан-Трек Device ID: 359772036581529 , is still online. As I see it rarely sends GPS-data coordinates, although the connection to the server is established and regularly reconnected.
Packet with GPS-data:

Incorrect SDATE:

chol Yes, several packets with accumulated data were sent (1024 byte in this example). By the way, how to insert a picture normally?
https://ibb.co/wr3WZvc

In normal mode, the tracker sends packets more often and one position per packet: 36 bytes:
https://ibb.co/d0RsXtc

In TOOLBOX-column “server.timestamp” date and time recived data started every day at 06:05. After a minute or two, the reception of data stops. The next day, the server again receives packets from the tracker at 06:05 and again stops. This is normal? The analysis of ip packets from the tracker to the server shows the regular sending and receiving of geoposition data (every 5…12 seconds when driving and 10…15 minutes in the parking lot). At the TCP-protocol level, communication works fine. Does the server not accept data until the parser is restarted daily at 06:00?