Sending external sensor via quiic to Qfield?

GPS/GNSS
1

I’d appreciate any help finding resources or documentation to implement the following:

Connect an external sensor board (temp, pH, light, etc) via I2C / Quiic to any of the sparkfun board or enclosure GNSS/GPS products (facet or torch are preferred), fork the firmware to aquire and send this data along with NEMA packets (low frequency, maybe once every 10 seconds), and log that data at measurement points using Qfield (open to using other tools with similar capabilities).

Some info I have found:

On the Qfield / Qgis side:

Our use case is surveying dozens of points an hour for scientific fieldwork that includes sensor measures and human observational data entry. Qfield allows logging location from GNSS remotes and entry of data into fields on a tablet and export to simple csv files after returning from the field.

Another architecture we have considered is connecting a source of high accuracy GNSS/GPS signals and our sensors to a openlog datalogger board with a push button trigger to read all onto a SD card, but this has limitations for user interface and matching to human logged observational data. We have also considered some mixture of the two where timestamps would be used to merge data after returning from the field.

Any and all suggestions and pointers to information would be greatly appreciated.

Thank you!

2

I’d recommend the 2nd strategy mentioned (with a logger), which will help keep the timestamps aligned

Take a look at SparkFun OpenLog Artemis or SparkFun DataLogger IoT for loggers, we also have an environmental kit SparkFun OpenLog Data Collector with Machinechat - Environmental Monitoring

You can find the open source code and instructions on use on each products’ ‘documents’ tab

Do you already have a torch, or are you open to other GPS products?

3

Bummer, I was hoping to combine all dayastreams in one “pull” from the Qfield app. Is the first approproch technically possible? I don’t mind writing some new code for the microcontroller.

We don’t have a torch yet, was looking at that and the facet simply for being ready to deploy.

4

Sure, as far as I’m understanding it - I was thinking you needed time-alignment as a priority…there are many ways to account for this in post-processing as well. Although I’m not personally familiar with Qfield it should be fairly trivial to import/export any NMEA or any alternate formats you’d like; we have a short guide for connecting to QField here :slight_smile:

The Facet would be a good choice for your case as it has a dedicated data port

image
image600×367 60.5 KB

and a large battery (good for trips to the field!)

All of our RTK products have open-source firmware that you can freely modify as well

5

You could fork the Firmware as you mentioned and create your own custom NMEA Sentence, but Qfield or any data collection software “likely” wouldn’t be able to easily recognize the metadata as it wouldn’t conform to any particular NMEA sentence/protocol… out of the box anyway :slight_smile: That’s not to say it’s impossible however.

What are the cons (for your particular application) to an external MCU that collects all I2C sensor readings, and the RTK position is treated as just another sensor (but likely serial) ?

6

Thanks for all of your responses, I am learning a great deal about these systems.

Looking into the Qfield sensor functions I am beginning to understand that the problem rftop points out about parsing NMEA sentences is 100% correct. It looks like qfield expects all sensor data to be delivered via tcp or usp ports, not in the nema messages that it is already decoding to get gps location as I first assumed.

So setting up a MCU to send sensor data to the phone running qfield via a tcp port, like this system to log phone sensors, would work

But that causes a bunch of other challenges I’d have to solve on the phone.

The main drawback (for our use) of making a triggered data logger that records gps information as well as sensor information is that we would still have to sync the human observations and photos to that data, and I would have to put together some user interface so that the users would knew the data was recorded properly. Which is what I wanted to used Qfield for.

Our workflow is to arrive on the site, identify multiple point locations worth sampling. For each point, we record the GPS locations, take a photo, record multiple instrument sensor measurements and written notes from human observations at that point, and finally collect a physical sample. Then we move on to the next point. The more types of measurements we can take at each point, and the more points we can cover at each site the better. Currently, the bottleneck is manually recording all of this data and ensuring that it is all logged to the correct point. Photos have been particularly painful to sync up when we return from the field.

A field survey program like qgis allows recording of the location, photo, and displays entry fields for the human observations. I was trying to set up a system to also capture all the sensor values at the time the point is recorded without manually transcribing them into fields in the qfield app.

You can see how excited the developers are about this feature: QField 2.8: Boosting field work through external sensors – OPENGIS.ch
“Things get really interesting when sensor data is utilized as default values alongside positioning during the digitizing of features. You are always one tap away from adding a point locked onto your current position with spatially paired sensor readings saved as point attribute(s).”

That is the dream. I still feel like I am missing something about how the port on the facet could be used in such a solution. Is there already a data chanel established that could be piped to a tcp port on the phone?

7

The Facet Firmware has a TCP Client.

1 Like
8

That is very interesting! Looks like it doesn’t work in AP mode, and Qfield requires the facit to be a tcp server. So, if the facet and phone were both connected to a wifi hotspot (standalone, running on another phone, or even a backpack starlink hotspot) the facet could also be collectibg data from other sensors and serving each on a different port.

I’ll take a look at the tcp server part of the firmware and see what is involved.

This is the lead I needed. Thanks!

1 Like