Spirit System

Currently, the unit's status is polled every 10 seconds and recorded in the Log. This generates an overwhelming majority of redundant Good Health Message messages that contribute no new information. A typical log from a three minute flight is as follows:

0:00 Calibration Finished
0:10 Good Health Message (this text is displayed on two lines on many smartphones)
0:20 Good Health Message
0:30 Good Health Message
0:40 Good Health Message
0:50 Good Health Message
1:00 Good Health Message
1:10 Good Health Message
1:20 Good Health Message
1:30 Good Health Message
1:40 Good Health Message
1:50 Good Health Message
2:00 Good Health Message
2:10 Good Health Message
2:20 Good Health Message
2:30 Good Health Message
2:40 Good Health Message
2:50 Good Health Message
3:00 Good Health Message

In this example a total of 18 messages, frequently displayed on 35 lines, is used to communicate two events: Calibration Finished & Good Health.

Log information can be greatly enhanced by recording events instead of unit status at 10 second intervals. For example, the flight above could be reported as:

13:10:15 Unit Power On
13:10:21 Calibration Finished
13:13:21 Power Voltage Low // low voltage at shutdown

In this example, three informative events with the time they occurred is displayed on three lines.

This could make it possible to log multiple flights via a first in, first out buffer, e.g.:

13:10:15 Unit Power On
13:10:21 Calibration Finished
13:13:21 Power Voltage Low // nominal first flight w. low voltage at shutdown
13:20:15 Unit Power On
13:20:21 Calibration Finished
13:21:22 Rescue Initiated
13:21:26 Rescue Completed
13:23:21 Power Voltage Low // flight with rescue
13:30:21 Calibration Finished
13:31:22 Power Voltage Low
13:31:26 Power Voltage Nominal
13:33:21 Power Voltage Low // flight with low voltage event

A log event FIFO could make it possible to display more detailed information from multiple flights in fewer lines than a typical three minute flight.

HTH,

Phil

But the unit has no real time clock running while not powered. So it can only display the time since power up.

Reducing the number of messages with no additional information (good health repeated) is a good idea. Maybe this message can be repeated after any other event like low voltage or high vibrations.

Thank you for your suggestion.

Your solution is not bad, but actually it can take much more data than the current log.
Current log is capable of storing at least 16 different events per time frame with just two bytes. Or 8 events per byte.
Information that is stored in the log is not stored in the way that there is some event at some time.
Displaying just time will take 3 bytes per log + 2 bytes for storing the events. And unfortunately unit is not capable of storing real time - there is no battery inside.

Unfortunately not each log is that clean, there are cases when log is full of messages. In this case, your solution will take exponentially more data - these logs are also more important for pilot, so there is big priority that nothing is lost. For us it is important that log can be always stored in a short time and can't exceed predetermined size.

We can add more events to the log if you wish.

What I would like is to be able to see logs of a view flights. I like to check them occasionally at home to see if everything is ok. Could be done with the wifi link now but after every flight isn't really an option. One continues log in which every new connection starts at 0:00 would be great. Not sure how long the logging time is with spirit?

TLDR: A framework to provide flexible time-based event-driven logging that can be implemented with existing flash memory resources is described.

It appears that an event-driven event log can be implemented within existing flash memory limitations. Its advantages include support for an expanded collection of events, multiple flight logging, elimination of redundant messages, and more accurate time stamping. Flash memory use is minimized and controlled via several methods, these include: user selectable log parameters, event time encoding, and system-managed/dynamic event reduction. Additional methods could be implemented, e.g. group event encoding, if the specified methods are insufficient. The framework is compatible with, but does not require TOD information.

Log Parameters

Several parameters of the error-logging process could be user selectable via Spirit Settings. These include:

Event time stamp clock period: 1s, 2s, 4s, 8s
Minimum logged event level: 0 - Informative, 1 - Warning, 2 - Troubleshooting, 3 - Error
Monitored events - individually selected from the full list of events

Event Time Encoding

Continuous timing is supported via an 8 bit clock offset specifying a 1s, 2s, 4s, or 8s time interval from base time, either zero referenced or tod-referenced, when available. The event time is calculated by multiplying the timer value by the specified time interval and added to the current base time. Timer rollover for events that are separated beyond the maximum allowable time between events is supported by inserting a Null event placeholder in the stack.

Event Stack Management

This framework allows the user to take an active role in Event Stack management however software control can also dynamically manage two parameters to manage the size of the Event Stack if it is growing too quickly. The first, the minimum time between logged events, can be increased by generating a Clock Period event. The second, the minimum logged error message level, can be increased to reduce the number of events that qualify for notification.

With a 1s time interval, a 1 KB Event Stack would be able to log over 500 events (more than one per second) for the duration of an eight minute flight. An 8s time interval could allow over 900 events to be recorded in the same period.

Events:

Events are categorized as System or User and are both saved on the Event Stack. System events are generated by system software to support Error Log operation & user events are generated in response to user selections in System Settings.

System Events & hex codes:

0xF0: Null - stack frame placeholder for timer rollover
0xF2: Clock Period - event to double clock period, e.g. from 1s to 2s.

An expanded collection of User Events & even/odd hex code pairs, even if last event in Error Log Stack frame, odd if not:

Level 0: Information Events

0x00/0x01: Power On
0x02/0x03: Calibration Finished
0x04/0x05: Governor Engaged

Level 1: Warning Events

0x10/0x11: Cyclic Ring Activated
0x12/0x13: Rudder Limit Reached
0x14/0x15: Received Frame Corrupted

Level 2: Troubleshooting Events

0x20/0x21: RPM Sensor data noisy
0x22/0x23: Vibration Level High
0x24/0x25: Rescue Active
0x26/0x27: Bank 0 Active
0x28/0x29: Bank 1 Active
0x2A/0x2B: Bank 2 Active
0x2E/0x2F: Failsafe Active

Level 3: Error Events

0x30/0x31: Receiver Signal Lost
0x32/0x33: Main Loop Hang
0x34/0x35: Power Voltage Low/Nominal

These events and the corresponding time are stored in the Error Log Stack. Each Error Log Stack frame uses two bytes for an independently occurring event and one additional byte for each concurrent event.

Error Log Stack Frame Format:

First byte: < clock offset count: 8 bits >
Following bytes: < event number: 7 bits > || < event continuation bit > // 0 = last event in frame, 1 = additional event(s) in frame

Examples:

Example1: // two separate events occurring within 256 second 8-bit clock rollover period

13:10:15 Unit Power On
13:10:21 Calibration Finished

encoded with a four byte stack frame:

0x00 - 0 second initial clock offset
0x00 - power on event code, no continuation
0x06 - 6 second clock offset
0x02 - calibration finished event code

Example2: // two separate events that exceed clock rollover period using system Null event

13:10:15 Unit Power On
13:15:21 Calibration Finished

encoded with a six byte stack frame:

0x00 - 0 second initial clock offset
0x00 - power on event code, no continuation
0x00 - clock offset at time counter rollover after 256 seconds elapsed
0xF0 - null event code indicating 256s elapsed
0x32 - 50 second offset for calibration event; Event time offset is: 256+50 = 306 seconds
0x02 - calibration finished event code

Example3: // three simultaneous events using chaining (for illustration only)

13:10:15 Unit Power On
13:10:15 Calibration Finished
13:10:15 Governor Engaged

encoded with a four byte stack frame:

0x00 - 0 second initial clock offset
0x01 - power on event code with continuation
0x03 - calibration finished event code with continuation
0x04 - Governor Engaged, no continuation

HTH....drops mic