Adapting PublishQueueAsyncRK for Flash Memory

Tags: #<Tag:0x00007fe21d512190>


I’ve been using the fantastic PublishQueueAsyncRK library for dealing with downtime in the cellular connection on the Electron in order to ensure (mostly) that all events eventually are sent. However, 2048 bytes doesn’t hold nearly enough events for several hour ‘out’ periods. I’ve gone ahead and added a 32M Winbond Flash IC to my board to use temporary storage.

My plan was to adapt @rickkas7 library to use the Flash memory, rather than retained memory - are there any reasons this won’t work or is ill-advised before I begin on this journey? Any tips appreciated. Thanks!


Hi @hagandh

That is a fantastic idea! But instead of using an additional Flash IC, we’ve decided to use FRAM. Here is why:

In fact we’ve been having the same idea and plan to use this for our commercial celluar PLC controller which is based on the E Series:

We have Edge Counters on the PLC controller and being interrupt controlled they can counting impulses that go up to 4kHz.

We are using these to count things like consumption in Milliliters (Beer) or for Energy, Gas and Water.

Users can define a Publish Interval which usually is set between 10 secs (for realtime) or 1 minute for just logging.

So we had the idea of using @rickkas7 library as well but when publishing events every minute or each ten seconds the Flash IC will be written and erased very very often.

And since we have units in the field that are running for more than a year now we would have more than half a million write/erase cycles.

So we thought of going for FRAM since wear is not a problem in this technology. Here’s how easy it is attached to the E Series:


we have not yet implemented the library into our device operating system in such a way that I can share the code now. I will have a look and add this later.

But back to your idea. Using PublishQueueAsyncRK is a very good idea!

It should be straightforward to adapt this using the FRAM (just like using external FRAM). There is also a Library available:

So Pro:

  • No wear / unlimited write/erase cycles


  • less space compared to FLASH
  • a bit more expensive

Since our product is being used in production and industrial machines and we needed a way to keep lost publishes (due to cellular connection drops) the FRAM is the best way here.

We are using protobuf and highly minimize the publish payload but however using the FRAM and Async Publish library you will not be able to preserve publishes for weeks or month but it holds the most important ones and we’ve seen that outtakes in the field are mostly no longer than one or two days. And for us this works!




We’ve been using FRAM also on the so called “Masterbrick” - a Dev-board using E Series and P1 (P1 is currently at the PCB manufacturer).

Read more here:

If you are interested in working with one of these (it has both FRAM and FLASH attached) - contact me!