Spirit System

The point of this thread is twofold:
1) To lobby for a logging feature that survives reboots

2) To maybe have others convince me why I don't need this.

#1
Ok, so I'm a data nerd. I like logging. I would replace both of my Spirits right now with a new unit that had some permanent log storage. What do I want logged? Off the top of my head governor data (requested vs sensed RPM over time), vibration data, maybe also channel input signal so I can correlate what I was doing with the sticks to the RPM.

I understand the problems around writing to flash and similar non-volatile storage, so I would expect either a dedicated flash bank for logging, or removable micro SD card is required. I completely understand that this would increase the price and complexity of the unit and possibly make it bigger (at least in the removable case).


#2
Am I going about this in the wrong way? Is the FBL the wrong place to be logging this? I could get some of what I want from the ESC, but I'm using HobbyWing ESCs and they don't log. Do people expect their FBLs to log or their ESCs or do the data nerd folks go with something like jLog or more expensive ESCs? If I did that, I think I'd still miss the vibration data from Spirit. To me is just seems like logging the vibes during an actual flight is the right way to gather it. But, I'm a newbie so maybe I'm wrong.

Spirit saves logs permanently if there is some real problem.
Everything else is not important and can be verified in other ways.

Yes, saving to the Flash memory frequently is very risky and can greatly reduce durability of the unit. This is reason why some competition units are dying in range of 1 year (even that there is no real logging). From our point of view I dont understand why unit should do the logging of everything. Each device should log the data itself, especially ESC, because manufacturer can built good logging of everything that it supports. So it is also impossible for the unit to log for example currents, voltages at various places, etc. So why FBL controller should store everything if it can be stored in the device that is related with these variables.

Everything else that unit can't log can be logged with for example Jeti. With Jeti-Control integration that was introduced in 1.1.0 with Spirit, there is possibility to log everything you need to the SD Card.

I wish you good luck!

ZeXx86 wrote:Yes, saving to the Flash memory frequently is very risky and can greatly reduce durability of the unit.

The STM32F415VG data sheet specifies the minimum number of flash cycles, N-endurance, as 10,000. If we flashed the entire memory 10 times/day @ 200 days/year, the unit would function 5 years before reaching its rated minimum. If desired, a simple form of wear leveling, i.e. distributing write cycles among lesser-used memory locations, could increase the service life of the unit substantially.

Yes, you are right. Unfortunately it is not always true and in some cases flash memories will not survive even 1000 cycles.

Flash memory is divided in the sectors which are, especially on the STM32F4 quite big. Each sector must be rewritten completely (respectively erased first) if even single byte is changed.
We have made many tests and for sure we will never take this way. You can also see many units from the competition that are dying in one year. We want that our units are working all the time.

Hi Tomas

I just had a look at AN3969? As I understand, 10'000 is the erase/write limit.
In my Atmel world I used a Ring Buffer for logging to avoid reach of max write cycles.
To do so I define a Start and end Flag for the valid logging part, this used window is than moving forward in the usable EEPROM Section.
I'm not really into STM, but couldn't this concept be applied to the pages as well, as erased pages got FF?

regards, Adrian

In STM32F4 there are no pages anymore. There are sectors that are of variable size from few kB to few hundreds of kB. And there are just 23 sectors available (theoretically) but practically just few where we have firmware, settings, logs, hw data located.
Also storing in the flash memory is major intervention as everything must be disabled until operation is saved, which can take few miliseconds in dependence of sector size.

If there will be extended data logging available, then it will not use main cpu.