[Question][Websocket Server] Offset calculation logic question for ETA and ETE

[NDBoost]

Hey everyone,
I'm developing website in ReactJs to track my MSFS flights in real time using the FSUIPC web socket server. So far things are going ok, I'm just struggling a bit with the lack of documentation and/or formatting examples for the various offsets. Does anyone know what (if any) calculation logic needs to be performed for the ETA, and ETE offsets to get a HH:MM value for each?

This is what my offsets are defined as right now.

// this is what i'm using as my offset definition
const offsets = {
    command: 'offsets.declare',
    name: 'myOffsets',
    offsets: [
        { name: 'altitude', address: 0x0570, type: 'int', size: 8 }, // applied calculation to response - (altitude / (65535 * 65535) * 3.28084).toFixed(0)
        { name: 'heading', address: 0x0580, type: 'uint', size: 4 }, // applied calculation to response - (heading * 360 / (65536 * 65536)).toFixed(0)
        { name: 'tas', address: 0x02B8, type: 'int', size: 4 }, // applied calculation to response - (airspeed / 128).toFixed(0)
        { name: 'ias', address: 0x02BC, type: 'int', size: 4 }, // applied calculation to response - (airspeed / 128).toFixed(0)
        { name: 'eta', address: 0x60E8, type: 'int', size: 4 }, // i'm not sure what calculation is required to get a HH:MM to go?
        { name: 'ete', address: 0x60E4, type: 'int', size: 4 }, // i'm not sure what calculation is required to get a HH:MM to go?
        { name: 'avionicsMaster', address: 0x2E80, type: 'uint', size: 4 },
        { name: 'aircraftName', address: 0x3D00, type: 'string', size: 256 },
        { name: 'lights', address: 0x0D0C, type: 'bits', size: 2 },
        { name: 'playerLon', address: 0x0568, type: 'lon', size: 8 },
        { name: 'playerLat', address: 0x0560, type: 'lat', size: 8 }
    ]
}

 

Also, I will open source what I have so far once everything is a bit more flushed out.

[John Dowson]

9 hours ago, NDBoost said:

Does anyone know what (if any) calculation logic needs to be performed for the ETA, and ETE offsets to get a HH:MM value for each?

The ETE offset is in seconds, so it should be relatively straightforward to get the HH (divide by 60*60) and the MM (divide by 60 and subtract HH*60).
The ETA offset will be elapsed seconds since January 1st 1970 (midnight) in local time. You should be able to calculate the timestamp from that, but maybe easier to just get the local time HH:MM and then add on the ETE.

[NDBoost]

5 hours ago, John Dowson said:

The ETE offset is in seconds, so it should be relatively straightforward to get the HH (divide by 60*60) and the MM (divide by 60 and subtract HH*60).
The ETA offset will be elapsed seconds since January 1st 1970 (midnight) in local time. You should be able to calculate the timestamp from that, but maybe easier to just get the local time HH:MM and then add on the ETE.

That's awesome to hear that this'll be so easy to calculate, thanks for the quick reply too.

[NDBoost]

I'm having a bit of difficulty locating the correct offsets, would you be able to provide a quick example of this?

Here is the repo with the current mess that I have thrown together with the majority of the offsets I'm looking to capture. It's using ReactJs, the default create-react-app and all of the websocket functionality is within the src/SimService.js javascript file, you can see the offsets defined in the this.state.offsets object within the component. The eventual goal is, to have the SimService component perform the communication and translation. The state will always store the formatted version of the offset. 

Edited June 29, 2021 by NDBoost

[John Dowson]

11 hours ago, NDBoost said:

I'm having a bit of difficulty locating the correct offsets, would you be able to provide a quick example of this?

What do you mean by this? You already gave the offsets you are using (for the ETA/ETE), 0x60E8 and 0x60E4.
You can try logging the offset data for the offsets you are interested in, using FSUIPC's offset logging facility. They are currently documented as "Probably Working", i.e. they should hold the correct info but this has not been verified. The sim  variables for these are documented so they should be available (but only for reading).