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
Wish: implement an event-driven Log
-
phil.d.basket
- Posts: 8
- Joined: Tue 14. Jun 2016 5:44:31
Last edited by phil.d.basket on Fri 08. Jul 2016 7:38:14, edited 1 time in total.
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.
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.
regards Wolfgang
My Helis: Walkera 4G6 2S µBrain, Align T-Rex 250 FBL Microbeast, Oxy 3 Spirit Pro controlled by Jeti DS16
My Helis: Walkera 4G6 2S µBrain, Align T-Rex 250 FBL Microbeast, Oxy 3 Spirit Pro controlled by Jeti DS16
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.
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.
Spirit System developer
-
velocity90
- Posts: 252
- Joined: Sun 26. Oct 2014 9:53:53
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?
-TT E700 V2-Spirit Pro-mks950-980-Kontronik Kosmik 160 HV -Pyro 700 rewound by PD / Voodoo 600 -PD-MX700-470kv--BLS255hv-VBAR 5.3+- Gaui X3+ Spirit Pro
-
phil.d.basket
- Posts: 8
- Joined: Tue 14. Jun 2016 5:44:31
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
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