Interfacing AppSheets with specialized Test Equipment

Good Afternoon,

One week into AppSheet and I’ve already built a cool app. I like how my app tightly integrates with my phone’s email, text messages, voice, maps, image capture, etc. I’ve just scratched the surface.

I want to anticipate customer questions: like how to integrate specialized test equipment? In a previous position, our company performed rail testing. There was more than one testing modality. One involved self-powered rail cars that scanned the rail continuously. Another one employed trucks that could ride the rail and make stops when a suspected defect was found. A crew member jumped out and performed hand-testing. A third modality was created to facilitate continuous testing that I already mentioned. The test vehicle never stopped but the data was analyzed in near real-time. Suspected defects were identified, and batches of them uploaded to crews with handheld testing equipment. They located the section of rail using GPS coordinates supplied by the analysis team.

The Engineering Department developed the ultrasound testing equipment, but the code for the handheld device (i.e. smartphone) was developed by a member of IT. All of the code was specific to the phone’s O/S, and also to the phone brand because the solution needed communication ports. This was 15 years ago, so it was high-cost.

Fast-forward to today. I’m no longer active in that business domain, but I am certain that there are other opportunities which call for the integration of specialized equipment with a phone. AppSheets doesn’t need to change. It can already sync images and text with the server. But what needs improvement is the manner in which the phone captures images from the specialized test equipment, plus other metadata.

Does anyone have any thoughts on best practices for interfacing specialized equipment? Any Case Studies or White Papers?

Thanks,
Brian

I’ll take a stab at providing some insights.

First, I have read in the past of others getting third party barcode scanner working with appsheet. I think that is mostly due to the fact that when Appsheet activate barcode scanning it asks the device for the default scanner - so in reality I believe it’s the device controlling the access to the third part scanner and not AppSheet.

I am not aware of any ways that specialized equipment can be integrated directly into an AppSheet app.

But all is not necessarily lost. AppSheet can read from a variety of data sources. So if the specialized equipment can be setup so that it writes to one of those data sources, then you’re golden. Also, keep in mind that nowadays that are many web-based integration tools that try to generalize the movement of data between platforms. It may be that you need to use one of these services to get the data where AppSheet can access it.

As an example, AppSheet cannot read or scrape incoming emails for data to show in an app. However, you can use a service called Integromat to detect new incoming emails, scrape them for pertinent data and then write it to a Google sheet. Once in the Google sheet, AppSheet has full rein over it.

I hope this helps!

2 Likes

Thank you, John.

I will take a look at Integromat to get a better idea of what is possible. I like your idea of using third-party tools rather than writing a custom solution. However, there is a complication. It is quite possible that the operator and his equipment do not have Internet access. They could be testing rail inside a tunnel in the Rocky Mountains. Then, I think a better solution is for the phone to establish a WiFi hot spot, and have the test equipment push data to it. I just wonder if there are existing solutions. I am hoping that AppSheet allows me to create a data source to a local spreadsheet or folder on the phone.

Thanks again,
Brian

Nope.

No it doesn’t. AppSheet does have “offline” capabilities. But this is limited to locally stored data that can only be accessed by the app when no internet connection is present.

1 Like

In our company’s case, we had total control over the testing equipment. We designed the hardware and wrote the software. So, I think it is best to approach the problem a different way. We should not dictate to a client which testing equipment to buy. In almost all cases they will already have a sizable investment in equipment. A vendor of testing equipment will have its own solution for downloading data, whether it is WiFi or USB stick or whatever. How exactly we get that ultrasound to AppSheet will vary. There may be third-party solutions or we might have to write something custom. But we should design the AppSheet reporting app to allow for a lag in ultrasound data availability. All we need is a unique key or a session id from the test equipment. We enter that into our AppSheet capture app. It will enable the eventual joining of all data sets later on.

Also, one thing we didn’t have 15 years ago: StarLink. So even in remote locations our AppSheet app can sync to the cloud fairly soon after capture. If we are in a tunnel, we simply exit the tunnel to regain connectivity if a critical flaw in the rail is found. This way, at least, decision makers have the AppSheet data. They can wait for the ultrasound.

If the test equipment can’t give us a unique id then we can use a timestamp for “fuzzy” joining of data.