Questing about getting fix accuracy to the cloud, and a suggestion to further save power with cell position through nRFCloud

[Torje]

Hi Nordic and everyone else!

First my question:
I am sending my position data to the cloud in the same matter as the MQTT Multi Service sample. It converts some PVT data to a NMEA string and sends it. This loses the accuracy (and some other parameters) of the fix. Do you have any good suggestions to send the position to the cloud with the accuracy as well, without sending it as a "message type"? Could I send a full NMEA string from the modem? If so, which one and how? 
Thank you for all and any help!

Further, a suggestion:

When using nRFCloud service as back end, and I request cell based positioning, I might not need or want to get the resulting data to my nRF9160 device.
Today, requesting a cell (or wifi) based position gives me the result back to my device. And it doesn't really care, unless we want to send it somewhere else from the device. The data is shown on the cloud in the map. I can also be retrieved with the Rest API if needed. So sending this data back doesn't really do anything for the device in some cases. 
My thoughts are that this would save some power by not receiving the data, and by cutting a connection/going to psm earlier. Perhaps this could be configurable in a future release?

Just an idea! Have a nice day everyone!

Kind regards,

Torje

[JONATHAN LL]

Hi Torje,

nRF Cloud does support NMEA,  https://devzone.nordicsemi.com/f/nordic-q-a/67965/difference-between-gps_evt_pvt_fix-and-gps_evt_nmea_fix, so you would only need to use one of the formats described here:  https://github.com/nRFCloud/application-protocols/tree/v1/schemas/deviceToCloud/gnss

Not exactly sure about the extended question, do you propose that there would be power optimization if during circumstance where data is retrieved locally on the device (like position) and not send it to the cloud there by not initiating a extra up\down link or terminate it sooner to save power?

The application will be in control to some extent if there is a need buffer data for longer periods between transmission or discard parts of data to reduce data size. 

Regards,
Jonathan

[Torje]

Hello Jonathan,

And thank you for your reply. I found the resources helpful.

As to my suggestion, let me clarify:
1. Request cell location to nRFCloud by sending measured cell data.
2. Done. No need to answer with the position data back to the device. Location is shown and stored in the cloud. Saves a downlink and ack. The cloud is where the location is needed to be, not on the device. 

I have noticed that after requesting and receiving cell data on the device, the position is shown in nRFCloud even without sending the actual location back to the cloud. Great feature which saves an uplink, and can be even further improved by making the downlink optional as well. 

I hope I am making my self understood.

Thank you again for answering my ticket, and have a nice day!

Kind regards,

Torje

[AndrewKostka]

Hello, Torje:

There is a parameter you can add to the request object for cell-based positioning that will stop the position from being reported back over the Cloud to Device (c2d) topics. It's called "doReply":

{
    "appId": "CELL_POS",
    "messageType": "DATA",
    "data": {
        "doReply": false,
        "lte": [
            {
                "mnc": 260,
                "mcc": 310,
                "eci": 21858829,
                "tac": 333,
                "rsrp": -157,
                "rsrq": -34.5,
                "earfcn": 0
            }
        ]
    }
}

This is documented in our Application Protocols repository on GitHub. Hope this helps!

[justin]

additionally, the nrf_cloud FW library functions use a flag to indicate if you want the response:

nrf_cloud_cell_pos_request()

to generate the JSON: nrf_cloud_cell_pos_request_json_get()

[Torje]

Thank you both, this is exactly what I was looking for.