It is currently Fri 22. Nov 2024 8:17:05

All times are UTC + 1 hour





Post new topic Reply to topic  [ 6 posts ] 
  Print view Previous topic | Next topic 
Author Message
PostPosted: Wed 25. Nov 2015 18:35:51 
Offline

Joined: Wed 18. Mar 2015 23:57:51
Posts: 18
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.


Top
 Profile  
 
PostPosted: Thu 26. Nov 2015 8:52:42 
Offline
Site Admin

Joined: Mon 29. Apr 2013 16:06:44
Posts: 12442
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!

_________________
Spirit System developer


Top
 Profile  
 
PostPosted: Tue 12. Jul 2016 0:52:34 
Offline

Joined: Tue 14. Jun 2016 5:44:31
Posts: 8
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.


Top
 Profile  
 
PostPosted: Tue 12. Jul 2016 7:14:41 
Offline
Site Admin

Joined: Mon 29. Apr 2013 16:06:44
Posts: 12442
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.

_________________
Spirit System developer


Top
 Profile  
 
PostPosted: Wed 13. Jul 2016 8:15:59 
Offline

Joined: Thu 08. Oct 2015 14:43:12
Posts: 204
Location: Switzerland
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

_________________
Oxy4max SpiritPro + HW // SOXOS 550, SpiritPro, HW120A V4, 920KV // SOXOS 600, SpiritPro, HW160A, Pyro650 // SOXOS Strike7, SpiritPro, HW160A, Pyro750 // Skywing Spirit Aero // FrSky Horus X10S + Taranis X7 /


Top
 Profile  
 
PostPosted: Wed 13. Jul 2016 9:12:35 
Offline
Site Admin

Joined: Mon 29. Apr 2013 16:06:44
Posts: 12442
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.

_________________
Spirit System developer


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 14 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
skymiles_red v1.0.1 designed by Team -Programming forum-سيارات للبيع .