Support feeding through pilot events to FLARM or other IGC loggers.

[realtimepeople]

In competitions pilots need to be able to set a "Pilot Event Marker" and record it using their IGC-logger. If the logger is a Power-FLARM, a NMEA-Sequence "$PFLAI,PILOTEVENT*..." shall to be sent to it.

If such an event is declared using a XCsoar frontend, the event shall be published (also via CAN bus) and fed to any wired FLARM device.

The Vario-Display shall also be enabled to trigger such an event.

[MaxBaex]

relates to larus-breeze/sw_sensor#19

[MaxBaex]

In the first step, I would transmit the serial NMEA strings transparently via the CAN. I would only interpret the content if necessary. For example, if the front end receives a display for a Flarm radar. The sensor does not need to understand Flarm, MacReady etc. at all. The frontends should always understand, evaluate and apply incoming NMEA commands (MacReady, water balance, pilot weight, ...) from an XCSOAR. Question: How do you configure the outgoing NMEA data in our system to a connected (FLARM, radio, XCSOAR, or similar....) ? Use case: Two-seater with 2 front ends. The radio is connected to the front end and the FLARM to the rear. Simple: Both frontends stream their incoming NMEA data to the CAN. Which incoming data from the CAN is forwarded to FLARM or the radio? We also need auto baud rate detection I think.

I agree with that. Simply route the ASCII data through, but it must be clear what it is on the CAN bus.

We still have to determine how this is to be configured. It would be conceivable using a toml file that is either on the SD card or is transmitted via CAN bus. I would like to use a standardized format such as toml, as there are editors for this and it is clear how to enter it. These self-defined formats are problematic because they are not specified. I also find structuring a la toml useful. toml files are very similar to Windows ini files, easy to interpret. You can limit the vocabulary.

For example, you only allow ints, floats with . representation and strings. That is enough for us. Horst has provided an example of how not to do it with his fzt files.

[MaxBaex]

Enhance:
https://github.com/larus-breeze/doc_larus/blob/master/documentation/can_details/object_directory/gps.md and
https://github.com/larus-breeze/doc_larus/blob/master/documentation/can_details/services.md

Transfer of Binary Data Blocks maximum 64*4 448Byte

• Transfer of Binary Data Blocks confirmed > 448 Byte. Confirmation through recepient every 448 Bytes. Describe process in services.md with some more text.

Add "Kind of Data" and Describe Bit Location. Last data could be removed as the receiver can count down during reception.

XCSOAR-NMEA is converted to CAN in the connecting LARUS Unit.

Other NMEA Data (e.g. FLARM) is not interpreted but transparently tunneled as a generic data block (no conifirmation).

[MaxBaex]

Transfer of Binary Data Blocks is described on two locations:
https://github.com/larus-breeze/doc_larus/blob/master/documentation/can_details/object_directory/gps.md
https://github.com/larus-breeze/doc_larus/blob/master/documentation/can_details/object_directory/vario_display.md
why?

Example: Some device with the dynamic id X offers a firmware image on the bus. Another device id Y can now request this image? Y requests the image from X. X sends the first blob of 448 Byte data waits for the confirmation from Y and then sends the next 448 Bytes? I think a sequence diagram could be helpful to describe the process.
The devices use their dynamic ids for all communication.

Can Device X send a firmware image to multiple devices simultaneously and track both responses before sending the next 448 Byte blob? A request package frame from the device with dynamic id Z binds the response to the id Z?

[Simsys]

Enhance: https://github.com/larus-breeze/doc_larus/blob/master/documentation/can_details/object_directory/gps.md and https://github.com/larus-breeze/doc_larus/blob/master/documentation/can_details/services.md

Transfer of Binary Data Blocks maximum 64*4 448Byte

• Transfer of Binary Data Blocks confirmed > 448 Byte. Confirmation through recepient every 448 Bytes. Describe process in services.md with some more text.

Add "Kind of Data" and Describe Bit Location. Last data could be removed as the receiver can count down during reception.

XCSOAR-NMEA is converted to CAN in the connecting LARUS Unit.

Other NMEA Data (e.g. FLARM) is not interpreted but transparently tunneled as a generic data block (no conifirmation).

That's correct

[Simsys]

Transfer of Binary Data Blocks is described on two locations: https://github.com/larus-breeze/doc_larus/blob/master/documentation/can_details/object_directory/gps.md https://github.com/larus-breeze/doc_larus/blob/master/documentation/can_details/object_directory/vario_display.md why?

Example: Some device with the dynamic id X offers a firmware image on the bus. Another device id Y can now request this image? Y requests the image from X. X sends the first blob of 448 Byte data waits for the confirmation from Y and then sends the next 448 Bytes? I think a sequence diagram could be helpful to describe the process. The devices use their dynamic ids for all communication.

Can Device X send a firmware image to multiple devices simultaneously and track both responses before sending the next 448 Byte blob? A request package frame from the device with dynamic id Z binds the response to the id Z?

I think we need to discuss this again, as I can't fully grasp it. It might make sense to describe the process as a specification. Then we have something concrete that we can talk about.