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

[JONATHAN LL]

What Asset tracker version are you looking at ?

Assetracker
or
Assetracker V2

Regards,
Jonathan

[billywalton]

Hi,

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

[JONATHAN LL]

There are some improvements in V2 that we do recommend and in theory it is easier to implement custom use cases as the design is more modular.

That said 

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

the data buffer can be adjusted, but for one transmit 10K with dynamically allocated date by sending pointer + length. you can allocate heap or stack. 

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

 Data is being buffered and will be uploaded in correct order, however there is a limit to the amount of data that can be stored
 https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/asset_tracker_v2/README.html#data-buffers 

Is it using the SAADC to monitor the battery anywhere?

No, not in any of the examples at the moment.
In the cat tracker -> there is a get_voltage_levelf function.  And the way its done in Asset tracker V2 is request data from modem. 

Regards,
Jonathan

[billywalton]

Firstly, thanks for this, a really informative post.

I have tried V2 but have problems with the AWS, the AWS part is a massive headache for this project

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

Billy

[Markus Tacker (he/him)]

billywalton said:

I have tried V2 but have problems with the AWS, the AWS part is a massive headache for this project

If you have time I would greatly appreciate if you could give some insights on what specifically you don't like, or what could be improved to help you in your current situation.

[billywalton]

Hi Markus,

Of course,

The setup process on the cloud side was considerable, the main points which hit me included:

1) Had to use Linux

It's not that I'm afraid of Linux, its simply down to knowing that when I deploy the project to the maintainers, I need to deploy multiple OS's for them, we use SES on windows for the firmware devel, our current windows versions don't support the windows app store distros.  All in all its a pain to have to include another OS in the support requirements.

2) AWS

Its big, bulky, massively involved, loads of restrictions (ie supported region selections), more financial commitment on top of SIMs.  The dependencies and install process wasn't simple at all, your documentation is good but does not cover everything I had to do to get the AWS part working with all the dependencies it needed, how it works, what relies on what, etc

For me, I had never used AWS before, but I have been developing for years.  When I have finished this project I need to hand this over to someone, which would suggest that I have to add Linux and AWS skills to their skillsets.

When Amazon change things in the future, I can see frequent maintenance requirements to fix things that may get broken, which would again involve confident Linux and AWS skills for whoever is employed to support it.

When I compare this to running the Asset_Tracker using the nRFCloud, there is no contest - it was so easy, quick and fluid to set up, no additional OS needed, no AWS learning curve, I literally had it up and running in minutes, it looks nice, it works, it ticks the boxes with far far less commitment and time.

So it's hard to justify.  I feel more exposed to future support and maintenance requirements potentially needed when using AWS.

In fact, Nordic has done a stunning job with the nRFCloud offering, if the nRFCloud worked with the Asset Tracker 2, I think I would already be steaming down that path.

These points are solely based on evaluating the two Asset_Tracker apps, so it was a good experience for me to see the differences involved.  I'm not saying I wouldn't choose AWS for a different project in the future, it's just the effort to get it working in this case, for this project, was much greater then I had imagined. I hope Asset_tracker 2 gets a few alternative choices in the future, just for that reason, choice.

All that said, its clear a lot of work has been put into this, and the end-user result is very nice. 

I am always open to suggestions and welcome your comments if you think I have missed something or done something wrong.

[billywalton]

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.

[Markus Tacker (he/him)]

Hei Billy,

thanks so much for the detailed response!

billywalton said:

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.

billywalton said:

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.

billywalton said:

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.

[Markus Tacker (he/him)]

I am not clear on what your clients requirement are.