Author Topic: A solar supercap powered Moteino (15Farad charged by BQ25504)  (Read 38948 times)

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: A solar supercap powered Moteino (15Farad charged by BQ25504)
« Reply #30 on: February 17, 2017, 10:22:15 AM »
Interesting. You're not getting good resolution from the ADC reads. Are you using floats or fixed point arithmetic for that? It's almost like it's fixed point but you're losing resolution in the calculations. Can you post the code that does this?
Mark.
Edit: This seems a long time to enter TX mode too, you could try entering FS mode (i.e. start up the crystal and lock the PLL) but not wait for mode ready before filling the FIFO, and then go into TX mode and wait for mode ready to send it. The sequencer has to transition into that state and you could overlap the filling of the FIFO while the PLL locks.
« Last Edit: February 17, 2017, 10:35:50 AM by perky »

ChemE

  • Sr. Member
  • ****
  • Posts: 402
  • Country: us
Re: A solar supercap powered Moteino (15Farad charged by BQ25504)
« Reply #31 on: February 17, 2017, 11:05:21 AM »
Here's another piece of data that may (?) have relevance: the time needed to purely Tx the 60 byte payload (not counting the time it took to load the payload into the FIFO, but purely the Tx part) was about 2160uSec, or a little bit more than twice as long as for a 3 byte payload.  That is to say, with the FIFO already loaded, it takes 2160uSec from the moment the command is given to the radio to enter Tx mode to the time the PacketSent flag is detected.  That is the same interval over which all of the single-shot voltages are measured.  So, a bit more than twice as long to send a 60 byte payload than a 3 byte payload, even though the 6 byte payload contains 20x as many bytes.  Obviously, the frame size itself is bigger than the payload itself, but apparently the RFM69 takes quite a while (relatively speaking, given that the bitrate is 300kbps) to spin up and be ready to Tx.

That sure is different than what I was measuring when I was first fooling around with 300kps bit rates.  I was less than 1 ms to take all my measurements, fill the FIFO, start the transmit, and then get back to sleep.  I'll hunt for my posts with the specifics but your timings seem very slow.

https://lowpowerlab.com/forum/low-power-techniques/speeding-up-the-rfm69-library/msg17233/#msg17233
For a 6-byte payload I was measuring 500us between issuing the send() command and coming back to the next line.  This was using Felix's blocking send but with my sped up SPI code.
« Last Edit: February 17, 2017, 11:14:05 AM by ChemE »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: A solar supercap powered Moteino (15Farad charged by BQ25504)
« Reply #32 on: February 17, 2017, 11:36:37 AM »
Thanks for the heads up.  I just now checked it with an oscilliscope, and you're right: the microseconds() command is reporting about twice as long as what the scope says.  I guess there must be a fault in my fuse settings for the atmega328p or the compiler settings, where it thinks it's running at 16Mhz instead of the 8Mhz internal resonator.

That being the case, you can take the time measurements I posted above in this thread and divide them in half to get corrected time measurements.

Edit: Also, just to be clear, when I said a 3 byte payload or a 60 byte payload, I was referring just to the cleartext that gets sent.  I believe there may be another 3 bytes in the payload (I don't recall what at the moment, but probably FROM, TO, and networkID).  So, taking that into account, it would actually be a 6 byte payload versus a 63 byte payload, or about a 10x difference in payload bytes, not a 20x as I had said earlier.   
« Last Edit: February 17, 2017, 11:56:14 AM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: A solar supercap powered Moteino (15Farad charged by BQ25504)
« Reply #33 on: February 17, 2017, 12:18:59 PM »
Interesting. You're not getting good resolution from the ADC reads. Are you using floats or fixed point arithmetic for that? It's almost like it's fixed point but you're losing resolution in the calculations. Can you post the code that does this?
Mark.

Good catch.  Yes, here is the code I was using:
Code: [Select]
uint16_t computedVoltage(uint16_t rbgv) {
  uint16_t voltage;
  voltage = ((1.1/rbgv)*1023)*100;
  return voltage;
}

Looking at it again, maybe the following would do better at forcing all the calculations to be floating point:
Code: [Select]
uint16_t computedVoltage(uint16_t rbgv) {
  uint16_t voltage;
  voltage = ((1.1/((float)rbgv))*1023.0)*100.0;
  return voltage;
}

Or, perhaps there's a better way still?  I suppose this might be marginally better:

Code: [Select]
uint16_t computedVoltage(uint16_t rbgv) {
  uint16_t voltage;
  voltage = ((1.1/((float)rbgv))*102300.0);
  return voltage;
}

I'm aware that transforming the calculation into a purely integer domain might yield a speed of execution improvement, but at the moment I'm more concerned about getting the best accuracy/precision. 

Edit1:  Also, I don't recall now whether the final typecasting of the floating point result into uint16_t simply truncates the trailing digits or rounds them.  If the former, then I could compensate by adding 0.5 beforehand to effectuate a rounding.  i.e.:

Code: [Select]
uint16_t computedVoltage(uint16_t rbgv) {
  uint16_t voltage;
  voltage = ((1.1/((float)rbgv))*102300.0) + 0.5;
  return voltage;
}

Of course, if there's an even better way to do the overall calculation, I'd certainly be interested!]

[Edit2:  I just now ran a sample test with
Code: [Select]
  uint16_t voltage;
  voltage=1.6;
  Serial.println(voltage);
and it prints "1", not "2".  So, adding the 0.5 (as in the last equation above) is warranted.]
« Last Edit: February 17, 2017, 01:33:13 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: A solar supercap powered Moteino (15Farad charged by BQ25504)
« Reply #34 on: February 17, 2017, 12:33:26 PM »
Edit: This seems a long time to enter TX mode too, you could try entering FS mode (i.e. start up the crystal and lock the PLL) but not wait for mode ready before filling the FIFO, and then go into TX mode and wait for mode ready to send it. The sequencer has to transition into that state and you could overlap the filling of the FIFO while the PLL locks.

Good point.  That does sound like a better way to do it.  Thanks!

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: A solar supercap powered Moteino (15Farad charged by BQ25504)
« Reply #35 on: February 17, 2017, 03:06:15 PM »
On the face of it:
Code: [Select]
uint16_t computedVoltage(uint16_t rbgv) {
  uint16_t voltage;
  voltage = ((1.1/rbgv)*1023)*100;
  return voltage;
}
This should be OK, the inner parantheses are evaluated first and promotion to float should therefore happen throughout. Floats have 7 significant place resolution so that's OK too. The assignment will just take the non-fractional part. I'm at a loss therefore as to what's going on (unless you're using 8 bit left justified mode for the ADC or something, or the ADC is not actually completing the read properly before you read out the next value?).
Mark.


joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: A solar supercap powered Moteino (15Farad charged by BQ25504)
« Reply #36 on: February 17, 2017, 04:05:13 PM »
Quote
So, a bit more than twice as long to send a 60 byte payload than a 3 byte payload, even though the 6 byte payload contains 20x as many bytes.

Is that with encryption? If so the payload size increases in 16 byte chunks (padded with zeros).


WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: A solar supercap powered Moteino (15Farad charged by BQ25504)
« Reply #37 on: February 17, 2017, 05:36:11 PM »
On the face of it:
Code: [Select]
uint16_t computedVoltage(uint16_t rbgv) {
  uint16_t voltage;
  voltage = ((1.1/rbgv)*1023)*100;
  return voltage;
}
This should be OK, the inner parantheses are evaluated first and promotion to float should therefore happen throughout. Floats have 7 significant place resolution so that's OK too. The assignment will just take the non-fractional part. I'm at a loss therefore as to what's going on (unless you're using 8 bit left justified mode for the ADC or something, or the ADC is not actually completing the read properly before you read out the next value?).
Mark.

It's a longshot, but I'll try doing the calculation using purely integer math and see if that makes any difference:
Code: [Select]
uint16_t computedVoltage(uint16_t rbgv) {
  uint16_t voltage;
  voltage = ((1125300/rbgv)+5)/10;
  return voltage;
}
If nothing else, that should eliminate the chance of successive rounding errors that may(?) have crept into the floating point equation.  I'll post the results once I have them.

Meanwhile, here's the code I'm using to measure voltages using the ADC:

Code: [Select]
uint16_t getRelativeBandgapVoltage() { //used for single-shot voltage measurements
  uint16_t rawBandgapMeasurement;
 
  // Read bandgap voltage reference (~1.1V) against AVcc
  ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);   
  ADCSRA |= _BV(ADSC); // Convert
  while (bit_is_set(ADCSRA,ADSC)); //busy-wait until the ADC is done converting
  rawBandgapMeasurement = ADCL;  //get the low order bits of ADC
  rawBandgapMeasurement |= ADCH<<8;  //combine with high order bits of ADC
  return rawBandgapMeasurement;
}

uint16_t getDoubleMatchVoltage() { //returns the first voltage measurement that matches the immediately successive voltage measurement
  uint16_t rbgv;  // relative bandgap voltage
  uint16_t previousVoltage=0;  //set to zero so that first "match" (with only one voltage having been read) will fail.  Need two matching voltages
  uint16_t voltage;
 
  rbgv = getRelativeBandgapVoltage(); // grab the  first voltage measurement
  while (rbgv != previousVoltage) { //ensure that two successive voltage measurements match
    previousVoltage = rbgv;
    rbgv = getRelativeBandgapVoltage();
  }

  voltage = computedVoltage(rbgv);

  return voltage;




WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: A solar supercap powered Moteino (15Farad charged by BQ25504)
« Reply #38 on: February 17, 2017, 05:43:23 PM »
Is that with encryption? If so the payload size increases in 16 byte chunks (padded with zeros).

Yeah, I hadn't quite gotten around to turning that off yet, but I guess now I have good reason to.  So, I'll do that, remeasure, and then post the results.

I am, however, already following your prescription for a  6 byte preamble by using:
Code: [Select]
  radio.writeReg(REG_PREAMBLELSB,6);
in the radio initialization routine, so I presume that maybe that's also affecting the ratio of Tx times somewhat.
« Last Edit: February 17, 2017, 05:45:59 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: A solar supercap powered Moteino (15Farad charged by BQ25504)
« Reply #39 on: February 17, 2017, 07:13:46 PM »
The longshot paid off.  The purely integer math:
Quote from: WhiteHare link=topic=2431.msg18027#msg18027
[code
uint16_t computedVoltage(uint16_t rbgv) {
  uint16_t voltage;
  voltage = ((1125300/rbgv)+5)/10;
  return voltage;
}
[/code]
seems to have fixed the floating point artifacts.  Here are the results from using the new code:
Code: [Select]
17,[Sender:2],353 ABCDEFGHIJKLMNOPQRSTUVWXYZ012345678901234567890123456789,[RX_RSSI:-33]
18,[Sender:2],353,[RX_RSSI:-33]
19,[Sender:2],353,[RX_RSSI:-33]
20,[Sender:2],344,[RX_RSSI:-33]
21,[Sender:2],336,[RX_RSSI:-33]
22,[Sender:2],336,[RX_RSSI:-33]
23,[Sender:2],336,[RX_RSSI:-33]
24,[Sender:2],336,[RX_RSSI:-34]
25,[Sender:2],336,[RX_RSSI:-33]
26,[Sender:2],336,[RX_RSSI:-33]
27,[Sender:2],336,[RX_RSSI:-33]
28,[Sender:2],336,[RX_RSSI:-33]
29,[Sender:2],336,[RX_RSSI:-34]
30,[Sender:2],336,[RX_RSSI:-33]
31,[Sender:2],327,[RX_RSSI:-31]
32,[Sender:2],327,[RX_RSSI:-34]
33,[Sender:2],327,[RX_RSSI:-34]
34,[Sender:2],327,[RX_RSSI:-33]
35,[Sender:2],327,[RX_RSSI:-33]
36,[Sender:2],327,[RX_RSSI:-33]
37,[Sender:2],327,[RX_RSSI:-33]
38,[Sender:2],327,[RX_RSSI:-33]
39,[Sender:2],327,[RX_RSSI:-33]
40,[Sender:2],327,[RX_RSSI:-33]
41,[Sender:2],327,[RX_RSSI:-34]
42,[Sender:2],327,[RX_RSSI:-33]
43,[Sender:2],327,[RX_RSSI:-34]
44,[Sender:2],327,[RX_RSSI:-33]
45,[Sender:2],327,[RX_RSSI:-34]
46,[Sender:2],327,[RX_RSSI:-33]
47,[Sender:2],327,[RX_RSSI:-34]
48,[Sender:2],327,[RX_RSSI:-33]
49,[Sender:2],327,[RX_RSSI:-34]
50,[Sender:2],327,[RX_RSSI:-33]
51,[Sender:2],323,[RX_RSSI:-32]
52,[Sender:2],323,[RX_RSSI:-33]
53,[Sender:2],323,[RX_RSSI:-33]
54,[Sender:2],319,[RX_RSSI:-33]

From looking at the list of voltages, it appears as though the ADC quantization is somewhere between 40 and 45 millivolts.  Does this pass muster?

Unless I hear otherwise, I'll be using the new code going forward.  It seems better, and it should be faster too!

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: A solar supercap powered Moteino (15Farad charged by BQ25504)
« Reply #40 on: February 17, 2017, 08:37:48 PM »
Looks like I spoke too soon about the quantization, because here are the next two traunches of voltage measurements:
Code: [Select]
55,[Sender:2],353 ABCDEFGHIJKLMNOPQRSTUVWXYZ012345678901234567890123456789,[RX_RSSI:-34]
56,[Sender:2],353,[RX_RSSI:-33]
57,[Sender:2],344,[RX_RSSI:-33]
58,[Sender:2],337,[RX_RSSI:-33]
59,[Sender:2],336,[RX_RSSI:-34]
60,[Sender:2],336,[RX_RSSI:-34]
61,[Sender:2],336,[RX_RSSI:-35]
62,[Sender:2],336,[RX_RSSI:-34]
63,[Sender:2],336,[RX_RSSI:-35]
64,[Sender:2],336,[RX_RSSI:-33]
65,[Sender:2],327,[RX_RSSI:-34]
66,[Sender:2],327,[RX_RSSI:-34]
67,[Sender:2],327,[RX_RSSI:-34]
68,[Sender:2],327,[RX_RSSI:-35]
69,[Sender:2],327,[RX_RSSI:-34]
70,[Sender:2],327,[RX_RSSI:-35]
71,[Sender:2],327,[RX_RSSI:-34]
72,[Sender:2],327,[RX_RSSI:-34]
73,[Sender:2],327,[RX_RSSI:-35]
74,[Sender:2],327,[RX_RSSI:-34]
75,[Sender:2],327,[RX_RSSI:-35]
76,[Sender:2],327,[RX_RSSI:-35]
77,[Sender:2],327,[RX_RSSI:-35]
78,[Sender:2],327,[RX_RSSI:-35]
79,[Sender:2],327,[RX_RSSI:-35]
80,[Sender:2],327,[RX_RSSI:-34]
81,[Sender:2],327,[RX_RSSI:-35]
82,[Sender:2],323,[RX_RSSI:-35]
83,[Sender:2],323,[RX_RSSI:-34]
84,[Sender:2],323,[RX_RSSI:-35]
85,[Sender:2],323,[RX_RSSI:-34]
86,[Sender:2],323,[RX_RSSI:-35]
87,[Sender:2],323,[RX_RSSI:-35]
88,[Sender:2],323,[RX_RSSI:-35]
89,[Sender:2],323,[RX_RSSI:-34]
90,[Sender:2],323,[RX_RSSI:-35]
91,[Sender:2],320,[RX_RSSI:-35]
92,[Sender:2],317,[RX_RSSI:-34]
93,[Sender:2],353 ABCDEFGHIJKLMNOPQRSTUVWXYZ012345678901234567890123456789,[RX_RSSI:-35]
94,[Sender:2],353,[RX_RSSI:-35]
95,[Sender:2],344,[RX_RSSI:-35]
96,[Sender:2],336,[RX_RSSI:-34]
97,[Sender:2],336,[RX_RSSI:-35]
98,[Sender:2],336,[RX_RSSI:-35]
99,[Sender:2],336,[RX_RSSI:-35]
100,[Sender:2],336,[RX_RSSI:-35]
101,[Sender:2],327,[RX_RSSI:-35]
102,[Sender:2],327,[RX_RSSI:-35]
103,[Sender:2],327,[RX_RSSI:-34]
104,[Sender:2],327,[RX_RSSI:-35]
105,[Sender:2],327,[RX_RSSI:-35]
106,[Sender:2],327,[RX_RSSI:-35]
107,[Sender:2],327,[RX_RSSI:-35]
108,[Sender:2],327,[RX_RSSI:-35]
109,[Sender:2],327,[RX_RSSI:-35]
110,[Sender:2],327,[RX_RSSI:-35]
111,[Sender:2],327,[RX_RSSI:-35]
112,[Sender:2],327,[RX_RSSI:-35]
113,[Sender:2],327,[RX_RSSI:-35]
114,[Sender:2],327,[RX_RSSI:-35]
115,[Sender:2],323,[RX_RSSI:-34]
116,[Sender:2],323,[RX_RSSI:-35]
117,[Sender:2],323,[RX_RSSI:-35]
118,[Sender:2],323,[RX_RSSI:-35]
119,[Sender:2],323,[RX_RSSI:-35]
120,[Sender:2],323,[RX_RSSI:-35]
121,[Sender:2],323,[RX_RSSI:-35]
122,[Sender:2],320,[RX_RSSI:-35]
123,[Sender:2],320,[RX_RSSI:-35]
124,[Sender:2],320,[RX_RSSI:-35]
125,[Sender:2],320,[RX_RSSI:-34]
126,[Sender:2],320,[RX_RSSI:-35]
127,[Sender:2],320,[RX_RSSI:-35]
128,[Sender:2],320,[RX_RSSI:-35]
129,[Sender:2],320,[RX_RSSI:-35]
130,[Sender:2],317,[RX_RSSI:-35]


I'm spacing all the transmissions a minute apart now, so it takes longer to gather the data.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: A solar supercap powered Moteino (15Farad charged by BQ25504)
« Reply #41 on: February 17, 2017, 09:41:43 PM »
From looking at the list of voltages, it appears as though the ADC quantization is somewhere between 40 and 45 millivolts.  Does this pass muster?

Well, you should be getting around 10mV resolution but you're actually getting about 40mV. This happens whether you do floating point or integer (actually long integer) arithmatic.

So I think you're losing resolution from the ADC itself by clocking it too fast. The spec says 50kHz to 200kHz for full resolution but it can be clocked faster if lower resolution is needed, so I'm guessing you're clocking it faster than 200kHz and it's missing the lower few bits and yielding more like 8 bit resolution - that would explain 40mV jumps rather than 10mV jumps.

Mark.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: A solar supercap powered Moteino (15Farad charged by BQ25504)
« Reply #42 on: February 19, 2017, 02:41:42 PM »
I did some further investigation and discovered that my Moteino settings were correct.  As Perky pointed out, I was actually measuring the time interval from the start of FS until the end of TX, rather than just TX.

Also, I found that Nick Gammon has a very helpful, clear, and concise analysis of the atmega328p's ADC:  https://www.gammon.com.au/adc

Using that, I determined that a Moteino running at 8Mhz should run with either the 64 or 128 prescaler to stay within the official spec for 10 bit operation of the ADC, though Gammon also offers some demonstration code which shows higher speeds might work just as well (further confirmation of what ChemE has already said).  In any case, for present purposes, I went with the 64 prescaler, just to be conservative.

I also found that my previous code incurred unnecessary delay while sampling.  So, speeding that up using the previous ADC clock speed (where prescaler was only 2) yielded 156 samples per measurement.  However, those measurements were junk.  In the end, using the faster sample method, combined with the higher perscaler, yielded these new measurements, which are more trustworthy:

Code: [Select]
854,[Sender:2],343 ABCDEFGHIJKLMNOPQRSTUVWXYZ012345678901234567890123456789,[RX_RSSI:-37]
855,[Sender:2],342,[RX_RSSI:-38]
856,[Sender:2],336,[RX_RSSI:-38]
857,[Sender:2],327,[RX_RSSI:-38]
858,[Sender:2],323,[RX_RSSI:-38]
859,[Sender:2],320,[RX_RSSI:-38]
860,[Sender:2],318,[RX_RSSI:-38]
861,[Sender:2],317,[RX_RSSI:-37]
862,[Sender:2],315,[RX_RSSI:-38]
863,[Sender:2],314,[RX_RSSI:-37]
864,[Sender:2],313,[RX_RSSI:-38]
865,[Sender:2],313,[RX_RSSI:-38]
866,[Sender:2],312,[RX_RSSI:-37]
867,[Sender:2],311,[RX_RSSI:-37]
868,[Sender:2],311,[RX_RSSI:-38]
869,[Sender:2],310,[RX_RSSI:-37]
870,[Sender:2],309,[RX_RSSI:-37]
871,[Sender:2],308,[RX_RSSI:-38]
872,[Sender:2],308,[RX_RSSI:-38]
873,[Sender:2],307,[RX_RSSI:-37]
874,[Sender:2],297,[RX_RSSI:-37]

At this very moment I'm deliberately running the supercap to exhaustion with just a 1 second pause between each transmission, and logging the results.  I'm interested to see how the voltages measure near the point of failure: do they behave according to theory, or do they suddenly fall off a cliff?  If anyone else also has interest in the same, I can post the entire data dump when it completes using pastebin or the like.

[Edit: argh, I'm just now remembering that these measurements also span the time from the start of FS to the end of Tx.  So, only roughly the second half of the numbers show the voltages under full Tx load.   ::)]
« Last Edit: February 19, 2017, 03:32:21 PM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: A solar supercap powered Moteino (15Farad charged by BQ25504)
« Reply #43 on: February 19, 2017, 04:00:29 PM »
Now you're getting somewhere, you've got your 10mV resolution.

Now what's going on with that last measurement? That's a 100mV drop. I think you said that one reads the ADC until two consecutive values are the same (I don't think that's needed now BTW, it's accurate with a single read). Given it has basically tailing off by then, and TX is no longer active so not drawing 50mA, this should in theory be rising, not falling. Something is causing that measured voltage to drop, or something is amiss with that algorithm (does that code need changing for clock speed too?).

Edit: I think the supercaps act like normal caps between the two voltage thresholds given in the spec and it should be a straight line between them for a constant current discharge (at least that's what the equations in the spec suggest). You're higher than the lower threshold for the 4.2V supercap, so should be a straight line (3.3uV per millisecond at 50mA).

Mark.
« Last Edit: February 19, 2017, 04:06:58 PM by perky »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: A solar supercap powered Moteino (15Farad charged by BQ25504)
« Reply #44 on: February 19, 2017, 06:56:21 PM »

Now what's going on with that last measurement? ... Given it has basically tailing off by then, and TX is no longer active so not drawing 50mA, this should in theory be rising, not falling.


Excellent question!  The answer, revealed in the attached scope shot, was a surprise.

First, though, I'll describe what the scope shot is showing.  The blue line is a pin that I set to go high at the start of the single-shot measurements, and which I set to go low as soon as the code detects the PacketSent (DIO0) flag.  The yellow line is from a second oscilliscope probe, and it is inverted from what it should be because it shares the same ground as the first (blue) probe.  So, you may want to mentally rotate it upside down around the x-axis.  The yellow line shows the current (where, using a 1-ohm sense resistor, 1mv=1ma of current consumed by the Moteino).  There are a couple strange things about the yellow plot.  The first is that, even during the FS spin-up, it almost immediately jumps to nearly the maximum current current consumed during the Tx phase.  I'm still not sure what to make of that, so let's set that aside for the moment.

The second strange thing, and the one that's more relevant to your question, is that the high current drain seems to linger for quite a while after the packet is sent.  I had thought that the sequencer would quickly and automatically move the RFM69 into idle-mode after the packet was sent, but it doesn't.  Perhaps there's a timeout register I had overlooked where the RFM69 waits for additional bytes to arrive after the packet is sent, and then finally exits when they don't?  I guess I'll need to take yet another look at the datasheet to see if there exists something like that.  Alternatively, I may just brute force the RFM69 to shift into idle mode once the code detects the packet sent has been sent.  That's less ideal than if there were a hardwire timer on the RFM69 that I could zero out to prevent this from happening in the first place, but I suspect it would be better than the RFM69's current rather lengthy delay switching to idle shown in the attached scope shot.