Hello.
To avoid expressing the following poorly or with wrong terminology; prefer to ask it as an example :

Say a formula one racing car has an unattended smart phone on board. There is also a couple of dozen, or more, sensors for speed, mileage, temperatures, radio communication with pit, pressures, tilt, humidity, level, rpm, flows, forces, acceleration, vibration, direction, voltages, currents, position, time stamp, fuel consumption, volumes ...

Those sensors continuously emit their data which is to be collected/recorded by the phone via direct connection to its usb port, or bluetooth, or some multiplexer, or some method that all parameters data gets stored temporarily in the phone.

After every change/update of any parameter from any sensor or after every minute; all the last data batch kept is to be sent (transmitted) to an internet server site to be saved and can be examined in real time or later by accessing such website. After every data batch is delivered to the server; a confirmation of reception with no errors is to be returned to the phone that will then erase the previous data batch sent as it was successfully delivered already.

How do I search for such application, under what terminology or name ? Or you know about one that does it ?

 

How do I search for such application, under what terminology or name ? Or you know about one that does it ?

Um, I think not.

“There’s an app for that” only applies to functions needed by millions of people.

 

Hi, I think apps like this are too hardware unique and proprietary to be found in the public domain. On the other hand, you can make your own with moderate programming skills.

I'm in the process of creating beginner programming guides and this would be a nice addition to my collection. If you are interested, I can help you design an app from scratch that does everything you described. Here's what I propose:

1) (C++) Sample various sensors with Arduino, storing data in RAM or EEPROM. Use Bluetooth module to wait for op-code commands, respond with data when op-code appears in lookup table.

2) (Java) Android device connects to Bluetooth module, sends op-code for the data to be retrieved then stores response in persistent memory. For example, app sends string "01" and waits for string response "13:22:13 - Sensor 1 Temp: 42c".

3) Repeat 2 & 3 until all data is exchanged. Use cryptographic library to save data in zip file with strong password.

4) (Python) Web server listens on HTTP port 80 for incoming connection from app device and waits for zip file to be uploaded. After upload, transfer file to a folder inaccessible to the internet for later retrieval.

All together I imagine this project being a few thousand lines of code. I could get it done in about an hour or two and I'm an intermediate programmer. The biggest problem is security because this example has only one layer of protection (password protecting the zip before uploading to server). The actual data transfer both over Bluetooth and the Internet would be raw for simplicity. If the goal is to dump a bunch of sensor data to a web server via the app, then security is probably negligible which makes this a lot easier. Of course, additional security measures can be added later.

This is the kind of project that has unlimited applications once you know how to set it up. Plus there are tons of sensors on the market today and 3-D printing is getting to be pretty nifty. There has never been a better time for inventors and hobbyists to learn programming skills especially with A.I. chat-bots to help with debugging.

 

Thank you, Art.
Sounds like hebrew to me, in 1968/69 I took Cobol courses, in 1970 was RPGII; remember less than nothing as never used it at all, and built-up some aversion to programming Now my fading brain uncapable of concentration does not help either.

If I can pay for your services; would be nice to stablish contact. +1859 twozerotwo 69 48 after sunset preferred.
When god created the computer idiots, I came out first with the flag.

 

Possibilities:

 

Hello.
To avoid expressing the following poorly or with wrong terminology; prefer to ask it as an example :

Say a formula one racing car has an unattended smart phone on board. There is also a couple of dozen, or more, sensors for speed, mileage, temperatures, radio communication with pit, pressures, tilt, humidity, level, rpm, flows, forces, acceleration, vibration, direction, voltages, currents, position, time stamp, fuel consumption, volumes ...

Those sensors continuously emit their data which is to be collected/recorded by the phone via direct connection to its usb port, or bluetooth, or some multiplexer, or some method that all parameters data gets stored temporarily in the phone.

After every change/update of any parameter from any sensor or after every minute; all the last data batch kept is to be sent (transmitted) to an internet server site to be saved and can be examined in real time or later by accessing such website. After every data batch is delivered to the server; a confirmation of reception with no errors is to be returned to the phone that will then erase the previous data batch sent as it was successfully delivered already.

How do I search for such application, under what terminology or name ? Or you know about one that does it ?

You might take a look at the Particle line of cellular-connected IoT MCU dev boards. It’s not an app, but it might be a way to do what you want. It includes a free limited data plan for life, and prices for more data are reasonable.

Yes, it will take some development but from the sound of your requirements it shouldn’t be very challenging.

 

I'm not sure what you're after exactly but your description sounds a lot like my OBD-II device. It plugs into a port in my (or almost any) car and puts that data out over Wifi. (Many similar devices use bluetooth.) There are then many apps you can then install to read, record, and display the data.

In other words, an awful lot of what you want has already been done and is available very inexpensively.

 

I was about to say that you're re-inventing the wheel. Most modern cars have a CANBus connecting all the onboard computers together and distributing sensor information where needed. The OBD-II port eavesdrops on this data and relays it to an app, of which there are many, to display real-time data. Typically the data rate is at the rpm (150 samples/sec at 9000rpm) or sub-multiples for less critical data eg temperatures, fuel level, etc may be per second or slower. Many MCU, eg ESP32, STM32, etc have CANBus capability built in and BLE or WiFi to transmit to a Smart phone App., if you wanted to create your own dongle, but you can buy them for a few $/£, though not all provide a live real-time data stream. There are a myriad of sites explaining how to do what you describe, eg https://obdplanet.com/best-obd2-scanners-with-live-data/ (no affiliation)

Formula 1cars use a much more sophisticated version with much higher data rates. But you can buy setups for semi-pro and enthusiast level telemetry too. Here is but one example https://podium.live/ (no affiliation)

 

XPB_1135705_HiRes-scaled-e1648468861632.jpg (1200×800)

FIA regulations for F1 vehicle data, voice and other.
How Formula 1 Car Sensors Create Data at Every Turn

From what I can gather only an approved helmet communication radio and designated channel is allowed.
Really tough both in regulations and the various advanced radio com applications, extreme conditions.

F1 is a bit high to understand all the secret devices that requires specific wireless interface, who can legally play with an elite racing simulator,
who can get around the disclosure limitation and those who protect it. As an example were is the USB C connector.
We Tried the World’s Most Expensive Racing Simulator | WIRED

 

Hello.
To avoid expressing the following poorly or with wrong terminology; prefer to ask it as an example :

Say a formula one racing car has an unattended smart phone on board. There is also a couple of dozen, or more, sensors for speed, mileage, temperatures, radio communication with pit, pressures, tilt, humidity, level, rpm, flows, forces, acceleration, vibration, direction, voltages, currents, position, time stamp, fuel consumption, volumes ...

Those sensors continuously emit their data which is to be collected/recorded by the phone via direct connection to its usb port, or bluetooth, or some multiplexer, or some method that all parameters data gets stored temporarily in the phone.

After every change/update of any parameter from any sensor or after every minute; all the last data batch kept is to be sent (transmitted) to an internet server site to be saved and can be examined in real time or later by accessing such website. After every data batch is delivered to the server; a confirmation of reception with no errors is to be returned to the phone that will then erase the previous data batch sent as it was successfully delivered already.

How do I search for such application, under what terminology or name ? Or you know about one that does it ?

There are two aspects of your question and I don't know which is the one you are really looking for information about.

Is the use of a Formula-1 racing car just a throw-away example to help people visualize a generic context? Or is your real interest in capturing telemetry data from a Formula-1 race car?

If the latter, then the question is... why?

Most higher-end racing teams in most sports already capture tons of information and transmit it in real time to their support teams, within the bounds of what the racing association's rules allow. So either you would be trying to duplicate what already is in place, or you are trying to do something that is not allowed by the rules in order to gain an unfair advantage. Neither of which is really worth pursuing.

If the former, then is the real intent just to collect data from lots of sensors and transmit it back to a collection point along with a confirmation handshake to ensure it was successfully received intact?

Of so, that's also something that is routinely done in lots of different contexts, so you should be able to find solutions that are at least close enough to what you want that, once you understand them, should be able to be adapted to your specific needs fairly easily.

In either case, is the inclusion of "an unattended smart phone" an important aspect? If so... why? Why can't it be any of a number of other technologies that are routinely used for telemetry purposes, such as short-range radio links?

Also related is what is meant by "real time" in this context. Any communications link is going to involve latency. How much is tolerable. You imply that a minute's delay is not a problem. What if network congestion or the need to multiple retransmissions turns that into, say, ten minutes delay. Would that be a problem? More to the point, what is the maximum delay that could be tolerated? And could missing data be tolerated (i.e., data that never got conveyed successfully at all) and, if so, how much missing data could be tolerated?

These are all considerations that have significant impacts on the design of a system that will successfully achieve the actual intended goals.

 

Thanks.
The formula 1 is just an example to explain the collection/transmission/storage of data at a remote location. The intention of an unnatended phone is because the application is initialized automatically when data starts to flow and no human will operate the device; then, application suspends when data ceases. There is no other application to select in the phone, will be the only purpose of the device.
Missing data is not tolerable; corrupted data when traveling to the server site is not tolerable, must be compared sent to stored. Delay is acceptable for congested moments.
If there is a number of other technologies, fine. Am not familiar with any that will use a cell phone for it.

 

... at a remote location.

More about that please. Remote (how far?) from the sensors? My cheapo OBD reader creates its own wifi network and I suppose the range is not much farther than the interior of the car. There is probably some clever way to extend that but if you're wanting the phone to be a mile away from the sensors, that's a horse of a different color.

If you're ruling out OBD, it would help to know why. Maybe the sensors are not already networked?