A few asset tracker questions

[billywalton]

Hi all,

Just have a few Asset tracker questions if anyone knows the answer:

1) If using the nRF Cloud, and a custom env_sensor, what's the maximum length databuf that can be posted in one go?

struct cloud_data {
    char *buf;
    size_t len;
};

2) If a cloud post fails because it can't connect or no signal, does it queue the data for retry or just drops it?

3) Is it using the SAADC to monitor the battery anywhere?

Thanks in advance for any help

Billy

[billywalton]

I have reattached the requirements as i as still hopeful for some input on the final points

My client's requirement is to sample 8 channels of ADC at a variable rate, maximum 10Hz, As low power as possible.

So, assuming 2 bytes per sample, 1.6K every 10 secs or 9.6K every minute

If the LTE signal is lost, then I have to store the data until I can get a connection and upload it (am fitting the SDCARD for this I guess)

I like the provisioning and FOTA offered by nRFCloud, its neat, clean and easy to implement

But the sampled data does not necessarily need to pass through the cloud (as I read somewhere there is a 1M transaction limit or something?)

I have the SAADC ports running, and modified the env_senser to test it, all looks good.

I only want to use the 9160 part.

The client is happy to use webhooks or MQTT to accept the data into their database, nice and simple.

So could you suggest how you may go about this type of implementation?

Option 1, Use nRFCloud for provisioning, FOTA and sample data transactions

Option 2, Use nRFCloud for provisioning and FOTA, but for the sample data, use an HTTP POST method to an external fixed IP server (directly to the database).

Option 3, A better option which I have missed.

Thanks again for your help

[Markus Tacker (he/him)]

This would mean roughly 400 MB / month / device of pure data, not counting the transport overhead. And just for one device. MQTT and TCP is not really designed for sending streaming data, and adds significant overhead to the payload.

Assuming that it's OK the lose some of the packages (or even large chunks of data, since 1 hour takes up 1/2 MB of memory and depending on the application you could have longer phases of no connectivity), I still would look into using UDP and sending binary data to an endpoint, that then forwards the data to the data lake.

[Markus Tacker (he/him)]

PR that adds the note: github.com/.../74