RFDemo - save Quiet State

Added by wolfpackmars2 over 5 years ago

I have spent a portion of the day trying to implement a method to save the Quiet setting, and expand upon it, for instance, by adding state two (which quiets the messages from the flash memory operations - ie only well formed packets are sent to Serial out) or quiet state three which suppresses everything (but still saves data to the flash and any requested information can still be retrieved). However, I need these states saved - for some reason I’m unable to interact with the JeeLink on the raspberry pi, so I need to configure the Jeelink before connecting it to the Pi. This seemed like it should be easy enough, but I found that the memory location I was choosing to save the settings was not being restored correctly when the device rebooted. I realized that perhaps I don’t know every piece of data that is saved in flash. Originally, I thought I could tack my settings behind the RF12_config data, but it seems that data is being overwritten at some point between when it is saved to EEPROM and the device is powered down and then the data is reloaded from EEPROM.

I ran into many stumbling blocks while debugging, including strange “invalid conversion” errors when compiling, given the following code:

static void showHelp () {
  if (df_present())
  Serial.println("Current configuration:");
  int zz;
  for(int a = 0; a < 255; a++){
    zz = eeprom_read_byte(a) //;
    if (a % 8)

I receive the following error:

JeeLinkV3Custom.ino: In function 'void showHelp()':
JeeLinkV3Custom:640: error: invalid conversion from 'int' to 'const uint8_t*'
JeeLinkV3Custom:640: error: initializing argument 1 of 'uint8_t eeprom_read_byte(const uint8_t*)'
JeeLinkV3Custom:641: error: expected `;' before 'Serial'

However, using works. My goal was to inspect the memory to see if I could find a safe place to park my settings. Eventually, I realized I was spending so much stupid time just trying to get Serial.print to work correctly that I had to walk away from the project, since I was spending hours chasing silly things like above around and not really getting any closer to solving how to save my configuration data to EEPROM (well, how to save it I know, WHERE to save it I’m not sure).

If anyone has some insight, I would welcome it. I’ve included my current Jeelink custom code. It is not working and it is not complete - it’s at a point where I walked away from it in frustration. But it could give some insight into what I’m trying to do, how, and maybe why my approach isn’t working. Most of the changes occur in the SaveConfig function and the modified help text describes some of the changes.

Replies (7)

RE: RFDemo - save Quiet State - Added by JohnO over 5 years ago

wolfpackmars2 there is an experimental version of RF12Demo which does save the “q” setting here: you will need to include the associated library. The sketch also attempts document the layout of the eeprom used by RF12Demo, this version has slight tweaks because of its experimental status.

RE: RFDemo - save Quiet State - Added by JohnO over 5 years ago

I think access to eeprom is not as simple as from 0 to 255. The definition of RF12_EEPROM_ADDR from rf12.h looks like a pointer:

 #define RF12_EEPROM_ADDR ((uint8_t*) 0x20)  ///< Starting offset.

I don’t know enough to explain it I’m afraid but the code below compiles for me but obviously starts to read bytes at 32 as per the #define.
for(int a = 0; a < 255; a){
zz = eeprom_read_byte(RF12_EEPROM_ADDR
a); //; // this works
if (a % 8)

I also needed a “;” before “//”, are you using Arduino IDE or another compiler?

RE: RFDemo - save Quiet State - Added by wolfpackmars2 over 5 years ago

Thanks John I’ll look into it. The code I used was referenced from another example using the eeprom_read_byte function I found online, and I’ve used the function in other code. Not sure if somehow it’s been overloaded so that it requires a pointer…

RE: RFDemo - save Quiet State - Added by lightbulb over 5 years ago


You should really get your interaction with pi <> jeelink sorted out first.
Tell us more about your problem? What tool do you use to ’interact’?
As for your code, it specifically depends upon what library you’re using as to how it should be used
however, as you must have the .h on your system to compile you can look at the definitions in there. Typically, the std arduino eeprom is included as


this “read byte” wants unsigned int8, a signed int8 cannot handle ‘254’ (–128 to 127), and think about it, we are reading ’positions’ so a ’signed’ int is silly, as you are not storing data in negative positions, so try using that stdtype e.g.
uint8_t zz; //for your returned byte
for(uint8_t a = 0; a < 255; a){ //as your using ’a’ as your offset
If you carefully debug your old loop, you will find its probably not doing what you expect.
you are missing ; on
zz = eeprom_read_byte(a) //;
Finally, if memory serves, the RF12 may provide the starting point for its config data as: RF12_EEPROM_ADDR, and more importantly maybe its size, as: RF12_EEPROM_SIZE
If that’s the case, you can use this to store *your
data at the tail of this.
write_byte( RF12_EEPROM_ADDR* RF12_EEPROM_SIZE + n, your_byte) etc etc.

Again, from memory, various incantations of rf12demo exist, and they have used various ‘sizes’ for their config data, so for instance, if you started with an old rf12demo and stored data, then ran a newer version, with more config, you may loose your old settings as they could be overwritten.
I think the config uses a CRC so it can validate its read config does not pickup anything invalid that may be in eeprom from such writes, but your custom data will probably suffer the bit bucket.
Simple advice is to put your stuff ‘n’ bytes away so it is unlikely to be trodden upon, still other stuff that uses eeprom must also keep away from your custom bytes.

hope this helps


RE: RFDemo - save Quiet State - Added by martynj over 5 years ago

Just expanding a little on lightbulb’s comments - remember that rf12demo by default logs data to the EEPROM FLASH, so that is safe.
You would need to check that any other programs are not saving state to EEPROM also - it might be a good idea to put your state at the last location and grow backwards to avoid conflicts (with a checksum as insurance).

RE: RFDemo - save Quiet State - Added by lightbulb over 5 years ago


Unless I’m missing a trick, there is EEPROM and FLASH on a jeelink I think, and rf12demo puts “log data” i.e DF x y x… onto flash rather than EEPROM does it not?

…but the point is I guess that there are many libraries that stuff things in eeprom and they can write all over each other (and your sketch can write over them) unless you check correctly.


RE: RFDemo - save Quiet State - Added by martynj over 5 years ago

lightbulb, thanks for the rescue. You are correct - brain fade on my part.