Question

Gday, Wondering if anyone has any insight into the gps data format sent by the RUT955 in TCP modbus?

i can get most data off the device, fairly straightfoward. 2 words to double word using a 16 bit shift + OR, and convert to the desired format. (codesys)

but the GPS lat and long registers 143 and 145 converted to real come out with some wild values. tried shifting bit orders, changing word orders, all the basics, but not much progress.

anyone got any ideas?

Thanks

Answer 1

Hello,

The data format for 32bit float with order 1 2 3 4 and start register should be 144 and 146

Answer 2

There have been a couple of questions on this:

https://community.teltonika-networks.com/28727/accuracy-of-gps-data-via-modbus

Using Python and PyModbus I have the same problem as the above, I get an answer that is in the right country, but not the right place in the right country.

There is this that helps a bit but still blows my mind, and I haven't understood it enough to be able to try to see if I get the right location this way:

https://community.teltonika-networks.com/1199/rut955-modbus-parameters-interpretation

I should have an HMI that can read and convert Modbus with me in a few days, I will try using that and see if I get nearer to the right answer.

If the Python program would help, this is where I got to:

import time
import struct
from pyModbusTCP.client import ModbusClient
from pymodbus.constants import Endian
from pymodbus.payload import BinaryPayloadDecoder

# init modbus client
c = ModbusClient(host="10.100.1.1", port=502, unit_id=1, debug=False, auto_open=True)

# main read loop
while True:
    # read 10 registers at address 0, store result in regs list
    #a = 17138
    #b = 59381
    #a = 18154
    #b = 21826
    #registers = [a, b]
    #registers = c.read_holding_registers(144, 2)
    registers = c.read_holding_registers(146, 2)

    if registers:
        decoder = BinaryPayloadDecoder.fromRegisters(registers, byteorder=Endian.Little)
        #decoder = BinaryPayloadDecoder.fromRegisters(registers, byteorder=Endian.Big)
        result = decoder.decode_32bit_float()  # type: float
        print('reg ad #0 to 9: %s' %registers)
        print('reg ad #0 to 9: %s' %result)

    else:
        print('unable to read registers')

    # sleep 2s before next polling
    time.sleep(2)

Comments

I found this website that does Binary to Float conversion:

https://www.binaryconvert.com/result_float.html

The values I got for Latitude from the modem were 21826 and 65514

65514 in binary is 1111111111101010

21826 in binary is 0101010101000010

If am pretty certain that this should be Little Endianess, so I swapped the first and second bytes (8 bits) of each 16 bit word, giving

1110101011111111 and 0100001001010101

I know that the value is positive so the number has to start with a 0.
Giving one big 32 bit number of 01000010010101011110101011111111

Putting that in to the web page above gives me 5.3479488372802734375E1, which matches the 53.479488372802734 given by the Python program I gave in my last post.  The problem is that the correct latitude reported by the modem web page is 53.390019, which I know to be correct.  So there does seem to be a problem in the Teltonika conversion of GPS data to Modbus data.  Anybody from Teltonika available to look at this?

---

Yeah this is where i got to, the precision is very poor for some reason? some odd dilution is happening somewhere along the way...

let me know if you make any progress, would be much appreciated!

---

I have used the Teltonika contact page to ask for them to have a look at it.  They have been pretty good when I have contacted them in the past.

---

Hello guys,

After I checked back, looked at the results with another software and not just the "TEST" button on the WebUI, it sure seems that the byte order should be 3412. However, in the WebUI the 1234 order seems to be the correct choice to get the values.

Thank you guys for noticing this, I will forward this to our RnD department.

What have I looked at:

In the WebUI I set up to read latitude register 144 and 2 regs read, float order 1234, I press test I see the 25.260, which is my latitude for sure,

Then I loaded up this software called GModbus, read the same 144 and 2 regs, got CDF641CA as the hex string, put it up for the hex converted which conveniently shows every possible combination and I see that yes, the 25.260 value is and Mid-Little Endian 3412.

That's why I seemed to have missed the truth

---

I did think I was going mad here, but I found the answer, a firmware upgrade was needed.  Fortunately I kept notes as I was testing, so I can go back to see what I did earlier.

Before the firmware upgrade using modbus-cli as described in the Teltonika modbus information and the command  'modbus read -w -s 1 -p 502 10.100.1.1 %MW143 2' I got:
%MW143      22415 - 0101011110001111
%MW144      21826 - 0101010101000010
01010111100011110101010101000010 gives  3.15192684576768E14 which is very wrong

After the firmware upgrade using exactly the same command I got a very different answer.
%MW143      16981 - 0100001001010101
%MW144      36705 - 1000111101100001
01000010010101011000111101100001 gives 5.3390018463134765625E1 which is correct

So, upgrade your firmware!

Just in case anybody might doubt the answer or think I was crazy :-)
I bought two RUTX09 at the same time, so I powered up the second one which still had the original firmware and got exactly the same wrong answers as above.

---

I actually replicated the same thing on 7.2.4 (newest FW) so even an FW upgrade might be a solution.

Anyway, the issue is registered to our RnD team and we will get to the bottom of this.

---

If i include this in my teltonika CLI environment python script i get the error that pyModbusTcp not exists. What package do I need to install to use this ?

import time
import struct
from pyModbusTCP.client import ModbusClient
from pymodbus.constants import Endian
from pymodbus.payload import BinaryPayloadDecoder

---

I use Thonny as my Python IDE, there I go to Tools, Manage Packages and I can choose to add Pymodbus and PymodbusTCP.