New Topic

Locus Map - help desk Topic Idea Locus Map (Android)

This object is in archive!

Category Locus Map (Android)

Tags NMEA, Protocol NMEA, RPM

Comments 9

Subscribers 3

Votes 2

Custom NMEA Protocol

Eduardo Boisa shared this idea ago

Declined

Good morning gentlemen. I'm trying to put a new idea in, and I apologize if it's the wrong way or the wrong place. I have an open ticket and, reading the other topics on the site a little, I saw that the idea of a generic NMEA protocol could be of interest to other users as well.

I have an instrumentation for sports aviation, and I have this data via BT in a terminal on the cell phone, which I send in a generic NMEA protocol, with the data of engine rotation, temperature, fuel mixture, carburetor opening, flight time and time of engine. I read in older topics (2017 or earlier), about the possible implementation of personalized message acceptance. However, in the NMEA Reader configuration, there are no options.

Is this possible at Locus, does it already exist or is it feasible to implement?

Thanks for listening.

Files:

I like this idea 0

Replies (6)

Eduardo Boisa ●

In fact, the idea would be, since there is the NMEA Reader functionality, to add the generic protocol function, for the user to read any information he wants from a generic device that sends data in the NMEA format, without checksum, since sending via Bluetooth already has confirmation redundancy. Today, with Atmel and PIC microchips, new customizable instruments are accessible. My suggestion, perhaps easier and more applicable, would be to create a generic protocol with countless possible data from generic equipment, and the user shapes his string so that Locus can read it. In my case, it concerns Temperature, Fuel and Engine Speed, and maybe two or three more generic fields.

URL

Eduardo Boisa ●

Suggested generic NMEA Locus protocol:

$LOCUS,Temp, Rpm, Gas, Adjust, etc., etc., ........

And other possibly useful information, for the user to customize at their discretion.

URL

Menion ●

Hello Eduardo,

thanks for the idea. Anyway, I do not understand how this is connected to hike & bike or generally location-based applications like Locus Map.

Even if Locus reads the mentioned data, what should do with it? Just display somewhere? Isn't this task to any other more specialized application? I believe it is,

So sorry, but I think this is not a useful feature for "common" Locus Map users.

Jiří M. aka Menion

URL

Eduardo Boisa ●

Hello Menion. I, as well as other friends of the aerodrome have been using Locus to record you, as well as planning routes and rescue, as it is the most complete map application. I suggested a generic NMEA String, so that it can serve any generic equipment, such as one that I developed with Android to measure the number of turns of the bicycle pedal, related to the revolutions of the wheel (rpm). I understand that the use for flights is very specific, but the idea would be to use any equipment. Instead of Locus adding each new sensor individually, suppliers of new sensors could adapt to a String in a Locus "proprietary" protocol, capable of reading any type of information.

URL

Menion ●

Hello Eduardo,

no commercial subject will adapt any Locus-made protocol for sharing data. We are too small. And I still miss info about "what Locus Map should do with read data". Because one thing is read data over protocol, but a lot more complex task is give to these values any usage > display it somewhere, use it in charts, etc. Quite a complex task to do this "generic" ... sorry.

URL

Eduardo Boisa ●

Menion, I understand your position. I really understand being very specific. In this application it would be to store the data together with the NMEA file recorded by Locus, and show it on the screen as well as other fields on the Panel, to accompany the safety parameters during the flight. But I understand that it would be too much work to write these functions in the program for such a restricted use. Anyway, I appreciate the attention and time dedicated to the explanations. Locus is the best open field maps and records application precisely due to the dedication of your team. Congratulations on the great application you have developed. Big hug.

URL

Eduardo Boisa ●

Hello Menion, I would like to return to the discussion on this subject. I didn't find the whole conversation, I remember there was something mentioned about technical availability of human resources. Is it possible to have an API where I could implement it with a team and add it to Locus? The ideal would be to be able to read the data, write together with the NMEA data (engine data + GPS data), and show in graphs for example (altitude X rpm), (altitude X temperature) etc. As for technical availability, would it be feasible with any financial contribution? Greetings. Eduardo Boisa

URL

Eduardo Boisa ●

As for the protocol, it is already defined and implemented, so it would not need to be generic. It follows in nmea format:

$IBPPG,

1 rpm

2 rpmmax

3 sondavalue

4 Temp

5 tempmax

6 tempar

7 bateria

8 agulha

9 agulha ajuste

10 Corte ativado

11 horimetro

12 horimetro min

13 horimetro parcial

14 Mark (event)

URL

Menion ●

Hello Eduardo,

thanks for the detailed description of the IBPPG protocol.

Locus Map offers API, but it is not made for such complex tasks. This needs to be implemented quite deep in the app, so it has to be made by me. Because of a huge number of interesting variables, it really looks like an ideal adept for some kind of "universal flexible system".

Anyway, I'm still for more than a year working on the new coming Locus Map 4 version ( https://forum.locusmap.eu/index.php?topic=7188.0 ), so time I may spend on some "hobby" tasks not directly related to our main hike&bike focus is really very limited, sorry and thanks for understanding.

URL