This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

A few asset tracker questions

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

Parents
  • Hi,

    The first version is the one I have running, but could change if needed

  • In addition, I am very open to you suggesting a way to satisfy my client's requirements using an AWS solution if you feel its the best way.  I am happy to revisit if the potential is there.

  • Hei Billy,

    thanks so much for the detailed response!

    1) Had to use Linux

    it is mentioned in the System Requirements that you can use Windows, and all the tools mentioned (Node.js, AWS CLI, Segger) in use should be working fine under native Windows, too. It's just that we currently have no automated tests to ensure that everything works under Windows. I've linked your feedback to the thread about Windows support and I will keep an eye on feedback around that. However, I think it will be clear with my next comment, why this was not an immediate concern.

    2) AWS

    I realized that we do not mention in the documentation that the nRF Asset Tracker project expects some prior experience with AWS and developing solutions on AWS; after all it is designed for developers who want a headstart on how to set up their AWS account for our devices, but then want to modify the solution to their needs.

    When I compare this to running the Asset_Tracker using the nRFCloud, there is no contest

    And this is where the documentation failed you, we should be clearer on what to expect from nRF Asset Tracker.

    After all, if you want a turn-key solution, with no additional costs and no maintenance effort, nRF Connect for Cloud is absolutely the better choice. And the asset_tracker application offers the optimal implementation of their API and their advanced features, like A-GPS and FOTA v2.

  • Hi Markus,

    After all, if you want a turn-key solution, with no additional costs and no maintenance effort, nRF Connect for Cloud is absolutely the better choice. And the asset_tracker application offers the optimal implementation of their API and their advanced features, like A-GPS and FOTA v2.

    This statement has been the clearest pointer of all for me so far and certainly clarifies the offerings, it also ties up with my own experience of evaluating the options.

    If I had read that at the beginning, for this project I would not have needed to consider it.

  • 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

Reply
  • 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

Children
  • 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.

Related