Many parameters are being monitored by VBar while operating normally. These are continuously being saved in a ring buffer that can hold about 500 entries. This ring buffer can be read at any time to get information about recent events. The log displays oldest entries first, latest entries last.
The memory can not be cleared, oldest entries are being overwritten by latest entries. This way, you can analyse the last few flights at any time. Size has been chosen in a way that you can read the log file after a day at the field as an after-flight-check, if need be, and check for critical events (marked by a red X). Should the log show nothing unusual for a few flights, it's OK to do an occasional check every now and then.
The log comes in very handy after incidents of all sorts, such as crashes or inexplicable behaviour of the heli in flight. In this case, the log should be read and should be saved as a PDF file. It can be of valuable service to analyse or track down issues. And it is a valuable base for questions in the forum.
The log records the following events:
- raised vibration levels
- low voltage warnings
- receiver failures
- sensor failures
- software errors
- regular messages such as bank switches, resets (and their cause)
These entries are being saved along with a time-stamp to a non-volatile memory. The time-stamp shows the time since the last cold start of the device, usually the last time VBar has been powered up. Short-term power-losses do not reset the timer.
When operational, the vibration level of all three sensors is being monitored. This function is a spin-off of the regular signal processing. Since vibrations occur all the time, especially when doing 3D flight, the vibration log is suppressed always when the flight condition indicates that there are likely to be increased vibrations (such as beating of the blades). Anyway, when flying hard maneuvers, there will be entries to the log that weren't suppressed, and that would not be there when doing soft sports flying only. This being said, an occasional entry of raised vibrations is not harmful. Should these entries add up or show up even when only hovering, you should start tracking them down.
Entries showing High or Extreme vibrations could occur on take-off and landing at the time the heli touches ground or resonates while spooling up or down. This is not critical.
Low voltage warnings
RX voltage is being monitored continuously. Should it drop below certain thresholds, log entries are being made:
< 4.5 V -> Information only
< 4.0 V -> Warning
< 3.5 V -> Error
< 2.5 V -> Error
< 1.8 V -> Error
These entries are to be taken seriously, you should think about beefing up your power supply. The thresholds help detecting problems early.
The last two thresholds, 2.5 and 1.8 V are being reported if they are crossed for the shortest time, the first three have a short time lag and are being reported after a undercut of a few milliseconds.
VBar expects the radio system to deliver refreshed data continuously, either digital or analog. Should there be even the shortest break, a log entry will be made. At common refresh rates, this occurs after two data packets in a row have been lost
When using satellite rx', all satellites are being monitored. Should any of the satellites cease delivering valid data packets, the primary data stream is being switched to the other satellite. This must not mean data loss, but it may indicate suboptimal alignment of the satellites. Occasional switching of antennas/satellites is nothing unusual.
Should irregularities of the sensor operation occur, a log entry is being made. For instance, a sensor value could be out of range in case of a crash, or in case of a real sensor failure.
The firmware is continuously being monitored while operating. For instance, there's a watchdog to prevent the software from hanging, meaning VBar would no longer react to any input. All internal memory modules are being monitored for overflows or illegal activities. Should anything unusual happen, the device is being reset an a log entry is being made (watchdog reset).
Regular log entries (bank switches, resets etc.)
These log entries help orientation within the time line of the log, for instance, every bank switch is being logged, or the finishing of initialization. Every flight begins with a "power up". This is being logged graphically by a grey entry..
Should no other issues occur, a "good health" entry is being logged every ten seconds of regular operation.
Since the log resides in non-volatile memory, that is being written rather slowly, it can happen that in case of power failures the corresponding entry will not be made. You can recognize this when a warm start is being logged in mid-flight, this is a serious issue. Check power supply in any case.