A solar supercap powered Moteino (15Farad charged by BQ25504)

[perky]

I think I made a mistake, _powerlevel seems to have strange values and is divided by 2 in the setHighPower() function for some strange reason. Anyway I've edited my post accordingly.

Mark.

[Felix]

I think this is an artifact of how I implemented the PA settings in the RFM69 library.
I will try to make this more consolidated at some point hopefully we can tap into lower power for the RFM69HW.

[perky]

Yes.  Also, I just now noticed that there's a notation at the bottom of Table 11 which says, "Note: High Power settings MUST be turned off when using PA0, and in Receive mode."

Supposedly already done with setMode() for TX v RX, and PA0 only can't be used anyway.

Mark.

[WhiteHare]

Voilà!  At first glance, this appears to work:

Code Select Expand

void setMinimalTxPower() {
  uint8_t newPaLevel;
 
  radio.writeReg(0x13,0x10);  //RegOcp (0x13) = 0x1x 
  radio.writeReg(0x5A,0x55); //RegTestPa1 (0x5A) = 0x55 
  radio.writeReg(0x5C,0x70);  //RegTestPa2(0x5C) = 0x70

  newPaLevel = (B10000000 | 18);
  radio.writeReg( REG_PALEVEL, newPaLevel);
  while (radio.readReg(REG_PALEVEL) != newPaLevel) {
    radio.writeReg( REG_PALEVEL, newPaLevel);
  }
}

Turns out I had toggled the wrong bit in regPaLevel.  This code fixes that.

I'll go measure the current now....

[WhiteHare]

Hmmm.  Not sure that's it either.  The current is around 30ma during Tx.  Does that sound right?  That's almost double the ~16ma the datasheet says it should be.

Note: the current in the scope shot is the the total Moteino current, plus during the Tx a little extra while running an LED just then.  So, subtract those overheads accordingly (maybe about 3 or 4ma or so) to get a truer picture of the Tx current.

[WhiteHare]

OK.  Wait a second.  Joes code says PA1 is ON, and presumably PA0 and PA2 are OFF.  This last measurement was with PA0 ON, and PA1 OFF and PA2 OFF.  So, the original code was right after all.  I'll try it again.... 

[perky]

You had the right bit toggled in the first place to enable PA1.

Remember that the setMode() call when changing to TX mode will override those power reg settings, did you disable that call?

Mark.

[WhiteHare]

Remember that the setMode() call when changing to TX mode will override those power reg settings, did you disable that call?

Mark.

Instead of setMode() to tip the RFM69 into Tx mode, I've lately been using:

Code Select Expand

  radio.writeReg(REG_OPMODE,B00001100); //activate RFM69 Tx mode.

So, for that reason, I don't think there's any code that's overriding the power settings.  As a precaution, though, I'll try setting them again just prior to setting REG_OPMODE to B00001100...  Although doing that is absurdly kludgey, at the moment I just want to see if I can make it work at all.

[Update: nope.  It made no difference.  I'm back to where I began on Tx power (see attached)    ]

[WhiteHare]

Here's the code that I'm presently using to measure and transmit the loaded voltage. 

Code Select Expand

void nonBlockingSendPacket() { //adaptation of code from RFM69 library
  blockingTerminateListenMode();
  blockingActivateStandbyMode(); //this line is probably redundant and should be deleted.

  // write to FIFO
  // select();
  // set RFM69 SPI settings
  SPI.setDataMode(SPI_MODE0);
  SPI.setBitOrder(MSBFIRST);
  SPI.setClockDivider(SPI_CLOCK_DIV4); 
  digitalWrite(10, LOW);  //digitalWrite(_slaveSelectPin, LOW);
  
  SPI.transfer(REG_FIFO | 0x80);
  SPI.transfer(sendSize + 3);
  SPI.transfer(GATEWAYID);   //SPI.transfer(toAddress);
  SPI.transfer(NODEID);  // SPI.transfer(_address);NODEID
  SPI.transfer(0x00);  //CTLbyte

  for (uint8_t i = 0; i < sendSize; i++) {
    SPI.transfer((payload[i]));
  }
  
  //unselect();
  digitalWrite(10, HIGH);

  setMinimalTxPower();  //this line is most likely redundant with prior initialization and should be deleted.  Putting it here now purely as belt and suspenders.
  radio.writeReg(REG_OPMODE,B00001100); //activate RFM69 Tx mode. 
}



uint16_t priorVoltage=0;

void measureVoltagesWhileSendingPacket() {
  long beginTxMicroseconds,endTxMicroseconds,totalTxMicroseconds;  //the beginning and end time of the Tx
  uint16_t rawVoltage;
  
  initializeAdc();

  payload[0]=(priorVoltage/100)+0x30;  //convert digit to ASCII.  0x30='0'
  payload[1]=((priorVoltage%100)/10)+0x30;
  payload[2]=(priorVoltage%10)+0x30;
  sendSize=3;
      
  Serial.print("Sending[");
  Serial.print(sendSize);
  Serial.print("]: ");
  for(byte i = 0; i < sendSize; i++) {
    Serial.print((char)payload[i]);
  }
  Serial.println();
  Serial.flush(); 

  //Map DIO0 to PacketSent during Tx mode
  radio.writeReg(REG_DIOMAPPING1, B00000000);
  while ((radio.readReg(REG_DIOMAPPING1) != B00000000)) {
    radio.writeReg(REG_DIOMAPPING1, B00000000); 
  }
//Assertion: DIO0 is now guaranteed to be mapped to PacketSent

  nonBlockingSendPacket();  //start sending packet.
  //Assertion: transmission sequence initiated
  
  digitalWrite(9,HIGH);  //flag start of transmission sequence
  beginTxMicroseconds=micros();  //start timing how long the packet takes to send.
   
  while (!(digitalRead(2)))  { //Loop until packet is sent.
    rawVoltage=getRelativeBandgapVoltage();
  }
  endTxMicroseconds=micros();  //finish timing packet duration
  digitalWrite(9,LOW);
  radio.writeReg(REG_OPMODE,B00000100); //activate RFM69 Stand-by mode 

  totalTxMicroseconds=endTxMicroseconds - beginTxMicroseconds;

  Serial.print(F("Tx took "));
  Serial.print(totalTxMicroseconds);
  Serial.println(F("uSec."));

  priorVoltage = computedVoltage(rawVoltage); //last voltage measured before PacketSent detected 

  blockingActivateStandbyMode();  //guarantee RFM69 is in stand-by mode before exiting
}

[WhiteHare]

Perky's capacitor arrived today.  I charged it up to 3.6v, and then let it rip using the above code.  I'm using a shorter Listen-Idle time of 262ms this time around, to speed up the testing, and now I'm very glad I did.  Perky's 7.5F capacitor has already logged more than 19,000 packets, and so far the loaded voltage has only dropped down to 3.2v! i.e. Perky's capacitor has already more than eclipsed the 15F Vishay capacitor's useful capacity, and presumably Perky's capacitor still has a long way to go before its voltage drops too low to power the mote.

I'll post the log file after the trial hits the point of failure, which won't be soon even at this accelerated Tx rate.

[Felix]

Guys - this is awesome research, love watching this thread.
I'll try this cap out when I get a chance.

@WhiteHare - I know you were using some small solar cells - are these just no-names off ebay or is there a more reliable source for them?
I'm starting to think there might be a case for a cap powered Mote which can be recharged easily. The tradeoff being the cap price which is about 4-5 times that of a CR2032.

[WhiteHare]

So far I've mostly purchased generic looking, mini solar panels from Ali Express of various sizes and voltages.  If you don't mind the wait, they're quite inexpensive.

[perky]

Perky's capacitor arrived today.  I charged it up to 3.6v, and then let it rip using the above code.  I'm using a shorter Listen-Idle time of 262ms this time around, to speed up the testing, and now I'm very glad I did.  Perky's 7.5F capacitor has already logged more than 19,000 packets, and so far the loaded voltage has only dropped down to 3.2v! i.e. Perky's capacitor has already more than eclipsed the 15F Vishay capacitor's useful capacity, and presumably Perky's capacitor still has a long way to go before its voltage drops too low to power the mote.

I'll post the log file after the trial hits the point of failure, which won't be soon even at this accelerated Tx rate.

That's a great result! It shows that supercaps are not all equal, there are clearly different technologies around. This particular 7.5F cap is a double layer type with low ESR, low leakage and linear voltage drop to very low voltage with constant current, and these I think are the features people need to look for in this type of application. Good work WhiteHare!

Mark.

[WhiteHare]

Thank you for finding it!  It's just amazing: the test is still running.  Presently at more than 181,000 packets sent, with the loaded voltage currently at 2.08v!

[ChemE]

Guys - this is awesome research, love watching this thread.
I'll try this cap out when I get a chance.

I agree with Felix, this thread has diverged and meandered but there is a lot of good information.  I find the code snipets and oscilloscope grabs especially valuable.