SD-Card for Models/Logging on Stock Board

[derFrickler]

just wait for the m128 version and maybe set the fuses before the first flash?

[Kilrah]

FYI, the original m128 discussion is here:
viewtopic.php?f=48&t=1508

[Kilrah]

A breakout board holding an abstract external memory sounds like a smart solution. Interfaced via the SPI (not the ISP!) connector it could either hold EEPROM, SD or any other flash or even non-flash memory accessed vie a standardized protocol. This might even be exchangable so might think of it as "memory cartridges" the user can exchange on demand.

Futaba CAMPac format might be a good idea then. Those little modules are easy to DIY, but also to find readily made either from the 2nd hand market or new from makers of "compatible" units...

http://cgi.ebay.fr/16K-CamPac-Modellspe ... 1e71767529
http://cgi.ebay.fr/64K-Modellspeicher-M ... 1e71423f02

[derFrickler]

Yes, i use them in my FX-18 already to extend from 12 to 24 models ;_)

*dream-on* an then a model-converter from futaba to open9x in companion....*dream-off*

[xnalpf]

Futaba CAMPac format might be a good idea then. Those little modules are easy to DIY, but also to find readily made either from the 2nd hand market or new from makers of "compatible" units...

http://cgi.ebay.fr/16K-CamPac-Modellspe ... 1e71767529
http://cgi.ebay.fr/64K-Modellspeicher-M ... 1e71423f02

Problem is that the original CAMPAC design is limited to 16kbit chips. For most users this might be enough - I always wanted to build a 64k campac for my FX-18 but since my DIY 16k campac gives me 24 models total and this is enough for my needs I never did. On the TH9X I am now migrating to just like derFrickler I suspect to have even more than 24 models with the on-processor 2kb EEPROM and an additional 16kbit SEEPROM like in a simple campac. But I do belive that adding support for larger SEEPROMS should be no problem.

[xnalpf]

Yes, i use them in my FX-18 already to extend from 12 to 24 models ;_)

*dream-on* an then a model-converter from futaba to open9x in companion....*dream-off*

*even more dream-on* and then a memory module holding a sd card that "talks" campac protocol and can be used in my good old futaba radio giving me - or better my son who inherits the fx-18 - endless model memory! *even more dream-off*

[Kilrah]

Old radios indeed only supported up to 16kb, but later ones went up to 64, so you do find official 1x64kb ones (instead of the old 4x16 layout).

Anyway, on the 9x 16kb will get you about 64 models plus about 8 in the internal eeprom, should be more than enough... and if not you could still have 2 CAMPacs and swap them
When you compare that to the number of models they actually store on a Futaba radio, it's interesting

The question is whether those memory chips are fast enough to be used with the 9x's filesystem. The way we write on it to get that many models in a small space might be the main issue.

[Kilrah]

and then a memory module holding a sd card that "talks" campac protocol and can be used in my good old futaba radio giving me - or better my son who inherits the fx-18 - endless model memory!

One of these with a modified firmware?

https://www.sparkfun.com/products/9530

[xnalpf]

Anyway, on the 9x 16kb will get you about 64 models plus about 8 in the internal eeprom

I think you mix up kbit and kbyte. The original campacs had 16kbit. So 2kb which is the exact amount of EEPROM on the m64. So you just double the space with a 16kbit campac/seeprom. 64kbit should be the way to go which will add 8kb model memory so you end up with five times space - round about 40 models. That really should be enough even for derFricklers fleet (you can't call that a hangar any more )

[Kilrah]

Oops yes of course!

[xnalpf]

]
One of these with a modified firmware?

https://www.sparkfun.com/products/9530

That's a nice one to start with! Connect this one with a modified firmware to the TH9X and forget about any other radio. My son should be glad to have 24 model memory.

[xnalpf]

The question is whether those memory chips are fast enough to be used with the 9x's filesystem. The way we write on it to get that many models in a small space might be the main issue.

I think the idea of having a breakout board like the openlog one should solve this problem. The additional mcu could act as a "cache controller" to the actual memory and take care of hal. Just an idea...

[xnalpf]

Oh btw - I did not have a look at the sourcecode so far. Do you load the model parameters from EEPROM once after selecting the model or do you access some parameters in real time during normal operation?

[bertrand35]

EEPROM is only read when you load a model. And written - asynchronously - when you modify something in this model.
Bertrand.

[xnalpf]

Then I do not understand this one:

The question is whether those memory chips are fast enough to be used with the 9x's filesystem. The way we write on it to get that many models in a small space might be the main issue.

[bertrand35]

If we use this CamPac for backup / restore models, then there is no issue, I don't think one will do these operations while flying...

The problem with SD speed becomes true when we write Logs. On sky9x it's not a problem, it's done in the low priority thread, so the mixer is not interrupted during a write. On gruvin9x board, I moved the Mixer calculations to an interrupt ; no problem as well. But on the 64A, we have used all timers (to be confirmed, I am not a HW guru at all), and it seems to me that what I did on the 2560 is impossible, it has to remain where it is.

So I don't see Logs on the stock board for now, but I am not against having a CamPac for storing more models. They would be compressed exactly as we do on stock, there would be the same kind of FAT that we have in the 1st 64 bytes of EEPROM (perhaps more depending on how many models we want to save there).

Of course this extra feature will use flash and I am not sure it will be possible to enable it on the 64A. The M128 replacement (or 2561 as Mike said) will be useful.

Bertrand.

[xnalpf]

The problem with SD speed becomes true when we write Logs. On sky9x it's not a problem, it's done in the low priority thread, so the mixer is not interrupted during a write. On gruvin9x board, I moved the Mixer calculations to an interrupt ; no problem as well. But on the 64A, we have used all timers (to be confirmed, I am not a HW guru at all), and it seems to me that what I did on the 2560 is impossible, it has to remain where it is.

Fair enough. That's why I came up with the idea of a breakout board hosting its own mcu. A mega8 class should be enough to handle SD management and provide that over i2c like the seeprom does. Write speed should do for 9600 bd. The already quoted SDlogger supports up to 230400 baud with a mega644 so write speed should not be a problem.

[MikeB]

I fairly certain er9x does NOT use Timer 2 at all, just 0, 1 and 3.

Mike.

[bertrand35]

You are right, it's used for gruvin9x board, but not stock! So what I did could be possible also on M128!
Bertrand.

[jhsa]

This is getting very interesting