Neat project, I'll be watching this. I wonder why your radio stopped transmitting at 2.31V when others have successfully run the HW down to 1.8V. Perhaps BOD cut your trial short?I wonder the same thing. I have BOD turned off at the fuse level, and I never turned it on in software, so BOD's not a factor. The RFM69HW is configured to run at 300kbps but at power level zero (set using the method in Felix's library). According to Felix, the RFM69HW requires a minimum of 2.4v to run because of the particular RF switch it contains. So, I''m not sure how people are able to run it from 1.8v.
EDIT: I'd be extremely interested to see how many packets this test bed could get sent using my automode radio code. I would have to rework it a bit to appropriately deal with a HW but you can sleep the uC much faster since you are not awake while the packet is being sent.
Maybe something like this to keep a teeny form factor: https://www.digikey.com/product-detail/en/panasonic-electronic-components/EEC-RG0V155H/EEC-RG0V155H-ND/5131456
Well, in terms of form factor, the 15F supercap I'm already using is actually smaller than the one you're proposing. ;)
Neat project, I'll be watching this. I wonder why your radio stopped transmitting at 2.31V when others have successfully run the HW down to 1.8V. Perhaps BOD cut your trial short?
Cool project!
I bet this is because the rfm69hw draws much more in Tx than the LED. Vcc should be measured during tx for this.
The rated ESR of the supercap is 1.8 ohms. The nominal Tx current drawn is between 30-40ma. So, that alone doesn't account for it. I got an impression that the voltage drop seems to get progressively bigger as the voltage declines. Perhaps that's a clue.I'm not aware of an ESR dependence on voltage, however if the power remains constant for transmission I suppose the current could increase a bit. This effect you're seeing is very large though.
Just a thought, but have you tried setting the current limiter for the transmitter? Is seems there's something else going on to cause such a large drop.
3. Then, immediately after initiating the transmission, it does single shot voltage measurement in a loop--storing each measurement in a list--until the transmission completes.How exactly do you do this part?
Yeah, that's why I had to create an alternative to the regular radio.send. I could post the code if you like. However, as I wrote the code in a hurry, it's brute force and not very elegant.OK I see. I think it would have some value to see your method, a non-blocking send could be useful to add to the main lib, just an idea. I am interested in trying it also while I'm doing some coin cell ADC readings myself.
OK I see. I think it would have some value to see your method, a non-blocking send could be useful to add to the main lib, just an idea. I am interested in trying it also while I'm doing some coin cell ADC readings myself.
uint32_t txStart = millis();
while (digitalRead(_interruptPin) == 0 && millis() - txStart < RF69_TX_LIMIT_MS); // wait for DIO0 to turn HIGH signalling transmission finish
//while (readReg(REG_IRQFLAGS2) & RF_IRQFLAGS2_PACKETSENT == 0x00); // wait for ModeReady
setMode(RF69_MODE_STANDBY);
millis() - txStart < RF69_TX_LIMIT_MS
setMode(RF69_MODE_STANDBY);
Using dV = Idt/C and with C = 15F, dt= 1ms and I=50mA you get dV = 3.3uV. That's many orders of magnitude below what you're seeing.Do you have a datasheet for the cap?OK, I saw the other post.
I'm not convinced by this. The ESR of the spec sheet says around 7.5 ohms, which at 50mA gives about 375mV drop. I suspect the fall from 3.52V to 3.23V during actual transmission is a result of the ESR causing a source voltage drop, and the time it takes for the ADC input capacitor to discharge through the pull-up/pull-down resistors, and if you left it transmitting for longer it would settle out (in fact I think you can see it levelling out in your data, the drops are getting smaller as time goes on). That also explains the recovery at the end when the ADC cap charges back up.
Mark.
That's an interesting analysis. I like it. So, if I understand correctly, you are predicting that if I were to send a packet with a much larger payload (which would be easy to arrange), then the list of voltages would pretty soon approach the 375mv drop caused by the ESR, and not continue to drop. Is that right?
For that test, all you need is the supercap, which is: https://www.digikey.com/product-detail/en/vishay-bc-components/MAL219691203E3/4701PHBK-ND/5015885
You can simply hook it up to a power supply to charge it to 3.6v, disconnect it, and then connect it to a moteino just as you would a battery.
I tried a number of supercaps, and some superficial testing suggested this one seems to have a very low self discharge rate.
Took your suggestion. I'm hoping that these 15F caps are a good way to compare power strategies to see which has the least area under the curve. My initial testing shows really large variability in how many cycles I get before the voltage gets too low. For instance, I get 87 or 52 or 66 cycles from a breadboard 328p waking up every 8s getting a temp/RH/Vcc and dumping the whole lot to the UART. Not sure if it is because my cap is new (the same Vishay you have) or if it depends on how long it soaks at 3.6V prior to the test or if they are just that variable.
Yes in a nutshell.
Mark.
101,[Sender:2],352 ABCDEFGHIJKLMNOPQRSTUVWXYZ012345678901234567890123456789,[RX_RSSI:-36]
102,[Sender:2],352,[RX_RSSI:-36]
103,[Sender:2],344,[RX_RSSI:-35]
104,[Sender:2],344,[RX_RSSI:-34]
105,[Sender:2],335,[RX_RSSI:-35]
106,[Sender:2],335,[RX_RSSI:-35]
107,[Sender:2],335,[RX_RSSI:-34]
108,[Sender:2],335,[RX_RSSI:-35]
109,[Sender:2],335,[RX_RSSI:-35]
110,[Sender:2],331,[RX_RSSI:-34]
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],327,[RX_RSSI:-35]
116,[Sender:2],327,[RX_RSSI:-35]
117,[Sender:2],327,[RX_RSSI:-35]
118,[Sender:2],327,[RX_RSSI:-35]
119,[Sender:2],327,[RX_RSSI:-35]
120,[Sender:2],327,[RX_RSSI:-35]
121,[Sender:2],327,[RX_RSSI:-35]
122,[Sender:2],327,[RX_RSSI:-35]
123,[Sender:2],327,[RX_RSSI:-34]
124,[Sender:2],327,[RX_RSSI:-35]
125,[Sender:2],327,[RX_RSSI:-35]
126,[Sender:2],327,[RX_RSSI:-35]
127,[Sender:2],327,[RX_RSSI:-35]
128,[Sender:2],323,[RX_RSSI:-35]
129,[Sender:2],323,[RX_RSSI:-35]
130,[Sender:2],323,[RX_RSSI:-35]
131,[Sender:2],323,[RX_RSSI:-35]
132,[Sender:2],323,[RX_RSSI:-35]
133,[Sender:2],323,[RX_RSSI:-35]
134,[Sender:2],323,[RX_RSSI:-35]
135,[Sender:2],323,[RX_RSSI:-34]
136,[Sender:2],323,[RX_RSSI:-35]
137,[Sender:2],319,[RX_RSSI:-36]
138,[Sender:2],318,[RX_RSSI:-36]
139,[Sender:2],352 ABCDEFGHIJKLMNOPQRSTUVWXYZ012345678901234567890123456789,[RX_RSSI:-35]
140,[Sender:2],352,[RX_RSSI:-35]
141,[Sender:2],344,[RX_RSSI:-35]
142,[Sender:2],335,[RX_RSSI:-35]
143,[Sender:2],335,[RX_RSSI:-35]
144,[Sender:2],335,[RX_RSSI:-35]
145,[Sender:2],335,[RX_RSSI:-37]
146,[Sender:2],335,[RX_RSSI:-41]
147,[Sender:2],327,[RX_RSSI:-47]
148,[Sender:2],327,[RX_RSSI:-45]
149,[Sender:2],327,[RX_RSSI:-46]
150,[Sender:2],327,[RX_RSSI:-47]
151,[Sender:2],327,[RX_RSSI:-44]
152,[Sender:2],327,[RX_RSSI:-46]
153,[Sender:2],327,[RX_RSSI:-44]
154,[Sender:2],327,[RX_RSSI:-46]
155,[Sender:2],327,[RX_RSSI:-46]
156,[Sender:2],327,[RX_RSSI:-45]
157,[Sender:2],327,[RX_RSSI:-45]
158,[Sender:2],327,[RX_RSSI:-46]
159,[Sender:2],327,[RX_RSSI:-45]
160,[Sender:2],327,[RX_RSSI:-46]
161,[Sender:2],323,[RX_RSSI:-44]
162,[Sender:2],323,[RX_RSSI:-45]
163,[Sender:2],323,[RX_RSSI:-45]
164,[Sender:2],323,[RX_RSSI:-44]
165,[Sender:2],323,[RX_RSSI:-46]
166,[Sender:2],323,[RX_RSSI:-44]
167,[Sender:2],319,[RX_RSSI:-45]
168,[Sender:2],319,[RX_RSSI:-45]
169,[Sender:2],319,[RX_RSSI:-44]
170,[Sender:2],319,[RX_RSSI:-45]
171,[Sender:2],319,[RX_RSSI:-45]
172,[Sender:2],319,[RX_RSSI:-46]
173,[Sender:2],319,[RX_RSSI:-44]
174,[Sender:2],319,[RX_RSSI:-44]
175,[Sender:2],319,[RX_RSSI:-46]
176,[Sender:2],318,[RX_RSSI:-44]
177,[Sender:2],352 ABCDEFGHIJKLMNOPQRSTUVWXYZ012345678901234567890123456789,[RX_RSSI:-46]
178,[Sender:2],352,[RX_RSSI:-46]
179,[Sender:2],344,[RX_RSSI:-45]
180,[Sender:2],335,[RX_RSSI:-46]
181,[Sender:2],331,[RX_RSSI:-46]
182,[Sender:2],331,[RX_RSSI:-46]
183,[Sender:2],327,[RX_RSSI:-46]
184,[Sender:2],327,[RX_RSSI:-45]
185,[Sender:2],327,[RX_RSSI:-46]
186,[Sender:2],327,[RX_RSSI:-45]
187,[Sender:2],327,[RX_RSSI:-46]
188,[Sender:2],327,[RX_RSSI:-47]
189,[Sender:2],327,[RX_RSSI:-46]
190,[Sender:2],327,[RX_RSSI:-47]
191,[Sender:2],327,[RX_RSSI:-46]
192,[Sender:2],327,[RX_RSSI:-46]
193,[Sender:2],327,[RX_RSSI:-45]
194,[Sender:2],327,[RX_RSSI:-41]
195,[Sender:2],327,[RX_RSSI:-36]
196,[Sender:2],323,[RX_RSSI:-36]
197,[Sender:2],323,[RX_RSSI:-36]
198,[Sender:2],323,[RX_RSSI:-35]
199,[Sender:2],323,[RX_RSSI:-36]
200,[Sender:2],319,[RX_RSSI:-37]
201,[Sender:2],319,[RX_RSSI:-37]
202,[Sender:2],319,[RX_RSSI:-36]
203,[Sender:2],319,[RX_RSSI:-37]
204,[Sender:2],319,[RX_RSSI:-36]
205,[Sender:2],319,[RX_RSSI:-37]
206,[Sender:2],319,[RX_RSSI:-36]
207,[Sender:2],319,[RX_RSSI:-36]
208,[Sender:2],319,[RX_RSSI:-36]
209,[Sender:2],319,[RX_RSSI:-36]
210,[Sender:2],319,[RX_RSSI:-36]
211,[Sender:2],319,[RX_RSSI:-36]
212,[Sender:2],319,[RX_RSSI:-36]
213,[Sender:2],319,[RX_RSSI:-36]
214,[Sender:2],316,[RX_RSSI:-36]
215,[Sender:2],352 ABCDEFGHIJKLMNOPQRSTUVWXYZ012345678901234567890123456789,[RX_RSSI:-36]
216,[Sender:2],352,[RX_RSSI:-36]
217,[Sender:2],344,[RX_RSSI:-35]
218,[Sender:2],335,[RX_RSSI:-41]
219,[Sender:2],327,[RX_RSSI:-44]
220,[Sender:2],327,[RX_RSSI:-40]
221,[Sender:2],327,[RX_RSSI:-36]
222,[Sender:2],327,[RX_RSSI:-36]
223,[Sender:2],327,[RX_RSSI:-36]
224,[Sender:2],327,[RX_RSSI:-36]
225,[Sender:2],327,[RX_RSSI:-37]
226,[Sender:2],327,[RX_RSSI:-36]
227,[Sender:2],327,[RX_RSSI:-36]
228,[Sender:2],327,[RX_RSSI:-36]
229,[Sender:2],323,[RX_RSSI:-36]
230,[Sender:2],323,[RX_RSSI:-36]
231,[Sender:2],323,[RX_RSSI:-35]
232,[Sender:2],323,[RX_RSSI:-36]
233,[Sender:2],323,[RX_RSSI:-36]
234,[Sender:2],319,[RX_RSSI:-36]
235,[Sender:2],319,[RX_RSSI:-36]
236,[Sender:2],319,[RX_RSSI:-37]
237,[Sender:2],319,[RX_RSSI:-37]
238,[Sender:2],319,[RX_RSSI:-35]
239,[Sender:2],319,[RX_RSSI:-35]
240,[Sender:2],319,[RX_RSSI:-35]
241,[Sender:2],319,[RX_RSSI:-35]
242,[Sender:2],319,[RX_RSSI:-35]
243,[Sender:2],319,[RX_RSSI:-35]
244,[Sender:2],319,[RX_RSSI:-35]
245,[Sender:2],319,[RX_RSSI:-35]
246,[Sender:2],319,[RX_RSSI:-35]
247,[Sender:2],319,[RX_RSSI:-35]
248,[Sender:2],319,[RX_RSSI:-35]
249,[Sender:2],319,[RX_RSSI:-35]
250,[Sender:2],319,[RX_RSSI:-35]
251,[Sender:2],316,[RX_RSSI:-35]
252,[Sender:2],352 ABCDEFGHIJKLMNOPQRSTUVWXYZ012345678901234567890123456789,[RX_RSSI:-35]
253,[Sender:2],352,[RX_RSSI:-35]
254,[Sender:2],344,[RX_RSSI:-35]
255,[Sender:2],335,[RX_RSSI:-38]
256,[Sender:2],327,[RX_RSSI:-44]
257,[Sender:2],327,[RX_RSSI:-36]
258,[Sender:2],327,[RX_RSSI:-35]
259,[Sender:2],327,[RX_RSSI:-34]
260,[Sender:2],327,[RX_RSSI:-35]
261,[Sender:2],327,[RX_RSSI:-34]
262,[Sender:2],327,[RX_RSSI:-34]
263,[Sender:2],327,[RX_RSSI:-35]
264,[Sender:2],327,[RX_RSSI:-35]
265,[Sender:2],327,[RX_RSSI:-35]
266,[Sender:2],323,[RX_RSSI:-35]
267,[Sender:2],323,[RX_RSSI:-35]
268,[Sender:2],323,[RX_RSSI:-35]
269,[Sender:2],323,[RX_RSSI:-35]
270,[Sender:2],319,[RX_RSSI:-35]
271,[Sender:2],319,[RX_RSSI:-35]
272,[Sender:2],319,[RX_RSSI:-35]
273,[Sender:2],319,[RX_RSSI:-35]
274,[Sender:2],319,[RX_RSSI:-35]
275,[Sender:2],319,[RX_RSSI:-35]
276,[Sender:2],319,[RX_RSSI:-35]
277,[Sender:2],319,[RX_RSSI:-35]
278,[Sender:2],319,[RX_RSSI:-35]
279,[Sender:2],319,[RX_RSSI:-35]
280,[Sender:2],319,[RX_RSSI:-34]
281,[Sender:2],319,[RX_RSSI:-34]
282,[Sender:2],319,[RX_RSSI:-35]
283,[Sender:2],319,[RX_RSSI:-36]
284,[Sender:2],319,[RX_RSSI:-35]
285,[Sender:2],319,[RX_RSSI:-35]
286,[Sender:2],319,[RX_RSSI:-35]
287,[Sender:2],319,[RX_RSSI:-36]
288,[Sender:2],313,[RX_RSSI:-35]
289,[Sender:2],352 ABCDEFGHIJKLMNOPQRSTUVWXYZ012345678901234567890123456789,[RX_RSSI:-35]
290,[Sender:2],352,[RX_RSSI:-35]
291,[Sender:2],344,[RX_RSSI:-36]
292,[Sender:2],335,[RX_RSSI:-35]
293,[Sender:2],327,[RX_RSSI:-35]
294,[Sender:2],327,[RX_RSSI:-36]
295,[Sender:2],327,[RX_RSSI:-35]
296,[Sender:2],327,[RX_RSSI:-35]
297,[Sender:2],327,[RX_RSSI:-35]
298,[Sender:2],327,[RX_RSSI:-35]
299,[Sender:2],327,[RX_RSSI:-35]
300,[Sender:2],323,[RX_RSSI:-34]
301,[Sender:2],323,[RX_RSSI:-35]
302,[Sender:2],323,[RX_RSSI:-35]
303,[Sender:2],323,[RX_RSSI:-35]
304,[Sender:2],319,[RX_RSSI:-36]
305,[Sender:2],319,[RX_RSSI:-35]
306,[Sender:2],319,[RX_RSSI:-35]
307,[Sender:2],319,[RX_RSSI:-35]
308,[Sender:2],319,[RX_RSSI:-35]
309,[Sender:2],319,[RX_RSSI:-36]
310,[Sender:2],319,[RX_RSSI:-35]
311,[Sender:2],319,[RX_RSSI:-36]
312,[Sender:2],319,[RX_RSSI:-36]
313,[Sender:2],319,[RX_RSSI:-35]
314,[Sender:2],319,[RX_RSSI:-36]
315,[Sender:2],319,[RX_RSSI:-36]
316,[Sender:2],319,[RX_RSSI:-36]
317,[Sender:2],319,[RX_RSSI:-36]
318,[Sender:2],319,[RX_RSSI:-36]
319,[Sender:2],319,[RX_RSSI:-36]
320,[Sender:2],319,[RX_RSSI:-36]
321,[Sender:2],319,[RX_RSSI:-36]
322,[Sender:2],319,[RX_RSSI:-36]
323,[Sender:2],319,[RX_RSSI:-36]
324,[Sender:2],319,[RX_RSSI:-36]
325,[Sender:2],319,[RX_RSSI:-36]
326,[Sender:2],313,[RX_RSSI:-35]
327,[Sender:2],352 ABCDEFGHIJKLMNOPQRSTUVWXYZ012345678901234567890123456789,[RX_RSSI:-36]
328,[Sender:2],352,[RX_RSSI:-36]
329,[Sender:2],336,[RX_RSSI:-36]
330,[Sender:2],335,[RX_RSSI:-36]
331,[Sender:2],327,[RX_RSSI:-35]
332,[Sender:2],327,[RX_RSSI:-35]
333,[Sender:2],327,[RX_RSSI:-35]
334,[Sender:2],327,[RX_RSSI:-36]
335,[Sender:2],327,[RX_RSSI:-36]
336,[Sender:2],323,[RX_RSSI:-34]
337,[Sender:2],323,[RX_RSSI:-35]
338,[Sender:2],323,[RX_RSSI:-35]
339,[Sender:2],323,[RX_RSSI:-35]
340,[Sender:2],323,[RX_RSSI:-34]
341,[Sender:2],319,[RX_RSSI:-35]
342,[Sender:2],319,[RX_RSSI:-35]
343,[Sender:2],319,[RX_RSSI:-36]
344,[Sender:2],319,[RX_RSSI:-37]
345,[Sender:2],319,[RX_RSSI:-36]
346,[Sender:2],319,[RX_RSSI:-36]
347,[Sender:2],319,[RX_RSSI:-36]
348,[Sender:2],319,[RX_RSSI:-35]
349,[Sender:2],319,[RX_RSSI:-35]
350,[Sender:2],319,[RX_RSSI:-35]
351,[Sender:2],319,[RX_RSSI:-36]
352,[Sender:2],319,[RX_RSSI:-36]
353,[Sender:2],319,[RX_RSSI:-36]
354,[Sender:2],319,[RX_RSSI:-36]
355,[Sender:2],319,[RX_RSSI:-35]
356,[Sender:2],319,[RX_RSSI:-36]
357,[Sender:2],319,[RX_RSSI:-36]
358,[Sender:2],319,[RX_RSSI:-35]
359,[Sender:2],319,[RX_RSSI:-35]
360,[Sender:2],319,[RX_RSSI:-36]
361,[Sender:2],319,[RX_RSSI:-35]
362,[Sender:2],319,[RX_RSSI:-35]
363,[Sender:2],319,[RX_RSSI:-35]
364,[Sender:2],313,[RX_RSSI:-35]
365,[Sender:2],352 ABCDEFGHIJKLMNOPQRSTUVWXYZ012345678901234567890123456789,[RX_RSSI:-35]
366,[Sender:2],352,[RX_RSSI:-35]
367,[Sender:2],335,[RX_RSSI:-35]
368,[Sender:2],335,[RX_RSSI:-35]
369,[Sender:2],327,[RX_RSSI:-35]
370,[Sender:2],327,[RX_RSSI:-35]
371,[Sender:2],327,[RX_RSSI:-36]
372,[Sender:2],327,[RX_RSSI:-37]
373,[Sender:2],323,[RX_RSSI:-36]
374,[Sender:2],323,[RX_RSSI:-37]
375,[Sender:2],323,[RX_RSSI:-36]
376,[Sender:2],323,[RX_RSSI:-34]
377,[Sender:2],319,[RX_RSSI:-37]
378,[Sender:2],319,[RX_RSSI:-35]
379,[Sender:2],319,[RX_RSSI:-35]
380,[Sender:2],319,[RX_RSSI:-34]
381,[Sender:2],319,[RX_RSSI:-36]
382,[Sender:2],319,[RX_RSSI:-36]
383,[Sender:2],319,[RX_RSSI:-37]
384,[Sender:2],319,[RX_RSSI:-36]
385,[Sender:2],319,[RX_RSSI:-36]
386,[Sender:2],319,[RX_RSSI:-36]
387,[Sender:2],319,[RX_RSSI:-36]
388,[Sender:2],319,[RX_RSSI:-35]
389,[Sender:2],319,[RX_RSSI:-36]
390,[Sender:2],319,[RX_RSSI:-35]
391,[Sender:2],319,[RX_RSSI:-34]
392,[Sender:2],319,[RX_RSSI:-36]
393,[Sender:2],319,[RX_RSSI:-36]
394,[Sender:2],319,[RX_RSSI:-35]
395,[Sender:2],319,[RX_RSSI:-36]
396,[Sender:2],319,[RX_RSSI:-36]
397,[Sender:2],319,[RX_RSSI:-36]
398,[Sender:2],319,[RX_RSSI:-35]
399,[Sender:2],319,[RX_RSSI:-36]
400,[Sender:2],319,[RX_RSSI:-36]
401,[Sender:2],319,[RX_RSSI:-36]
402,[Sender:2],313,[RX_RSSI:-36]
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.
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.
uint16_t computedVoltage(uint16_t rbgv) {
uint16_t voltage;
voltage = ((1.1/rbgv)*1023)*100;
return voltage;
}
uint16_t computedVoltage(uint16_t rbgv) {
uint16_t voltage;
voltage = ((1.1/((float)rbgv))*1023.0)*100.0;
return voltage;
}
uint16_t computedVoltage(uint16_t rbgv) {
uint16_t voltage;
voltage = ((1.1/((float)rbgv))*102300.0);
return voltage;
}
uint16_t computedVoltage(uint16_t rbgv) {
uint16_t voltage;
voltage = ((1.1/((float)rbgv))*102300.0) + 0.5;
return voltage;
}
uint16_t voltage;
voltage=1.6;
Serial.println(voltage);
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.
uint16_t computedVoltage(uint16_t rbgv) {
uint16_t voltage;
voltage = ((1.1/rbgv)*1023)*100;
return voltage;
}
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.
On the face of it:Code: [Select]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?).uint16_t computedVoltage(uint16_t rbgv) {
uint16_t voltage;
voltage = ((1.1/rbgv)*1023)*100;
return voltage;
}
Mark.
uint16_t computedVoltage(uint16_t rbgv) {
uint16_t voltage;
voltage = ((1125300/rbgv)+5)/10;
return voltage;
}
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;
}
Is that with encryption? If so the payload size increases in 16 byte chunks (padded with zeros).
radio.writeReg(REG_PREAMBLELSB,6);
uint16_t computedVoltage(uint16_t rbgv) {seems to have fixed the floating point artifacts. Here are the results from using the new code:
uint16_t voltage;
voltage = ((1125300/rbgv)+5)/10;
return voltage;
}
[/code]
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]
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]
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?
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]
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.
radio.writeReg(REG_OPMODE,B00000100); //activate RFM69 Stand-by mode
45,[Sender:2],349 ABCDEFGHIJKLMNOPQRSTUVWXYZ012345678901234567890123456789,[RX_RSSI:-37]
46,[Sender:2],349,[RX_RSSI:-37]
47,[Sender:2],340,[RX_RSSI:-37]
48,[Sender:2],335,[RX_RSSI:-37]
49,[Sender:2],331,[RX_RSSI:-37]
50,[Sender:2],329,[RX_RSSI:-37]
51,[Sender:2],328,[RX_RSSI:-37]
52,[Sender:2],327,[RX_RSSI:-37]
53,[Sender:2],326,[RX_RSSI:-37]
54,[Sender:2],325,[RX_RSSI:-37]
55,[Sender:2],324,[RX_RSSI:-37]
56,[Sender:2],323,[RX_RSSI:-37]
57,[Sender:2],322,[RX_RSSI:-37]
58,[Sender:2],322,[RX_RSSI:-36]
59,[Sender:2],322,[RX_RSSI:-37]
60,[Sender:2],322,[RX_RSSI:-36]
61,[Sender:2],321,[RX_RSSI:-36]
62,[Sender:2],321,[RX_RSSI:-37]
63,[Sender:2],320,[RX_RSSI:-37]
64,[Sender:2],320,[RX_RSSI:-37]
65,[Sender:2],315,[RX_RSSI:-36]
66,[Sender:2],343,[RX_RSSI:-37]
...I don't think that's needed now BTW, it's accurate with a single read...
That power savings obtained from brute forcing the radio back into standby does seem very substantial. Do you plan to test that on a charged cap to see how many cycles you get before voltage collapse?
Edit: Also you seem to have current kicks at the beginnig and end of this sequence, and a strange 50mV drop on your last but one reading. Where are they coming from?
@WhiteHare I assume you're not using auto mode for transmission? If you used that then you could use writing the first byte into the FIFO to start transmission (which would be done by entering intermediate mode programmed for TX mode), then immediately program RegOpMode to STANDBY before TX is complete. It should remain in TX mode then until the PacketSent event and then go to STANDBY immediately.
I think if you're not using auto mode then what you're seeing is normal manual driven process in that it will remain in TX until told otherwise even if the packet has been sent (presumably sending preambles). It's interesting that it exits TX at all in your case (do you use any other way to terminate things, like putting to sleep?). I actually specifically set to sleep after a packet sent event as I assumed it wouldn't stop TX until told to.
Rather than using the WDT, I'm using Listen-Mode to supply the interrupt to wake up from sleep.
As to the 50mv drop, I'm not sure which part of the scope shot you're referring to.
61,[Sender:2],321,[RX_RSSI:-36]
62,[Sender:2],321,[RX_RSSI:-37]
63,[Sender:2],320,[RX_RSSI:-37]
64,[Sender:2],320,[RX_RSSI:-37]
65,[Sender:2],315,[RX_RSSI:-36]
66,[Sender:2],343,[RX_RSSI:-37]
radio.writeReg(REG_AUTOMODES, B00111011)
I was curious why the 2nd from last reading dropped by 50mV rather than at most 10mV. Just an observation really:Code: [Select]61,[Sender:2],321,[RX_RSSI:-36]
62,[Sender:2],321,[RX_RSSI:-37]
63,[Sender:2],320,[RX_RSSI:-37]
64,[Sender:2],320,[RX_RSSI:-37]
65,[Sender:2],315,[RX_RSSI:-36]
66,[Sender:2],343,[RX_RSSI:-37]
163,[Sender:2],348 ABCDEFGHIJKLMNOPQRSTUVWXYZ012345678901234567890123456789,[RX_RSSI:-38]
164,[Sender:2],347,[RX_RSSI:-37]
165,[Sender:2],342,[RX_RSSI:-38]
166,[Sender:2],338,[RX_RSSI:-38]
167,[Sender:2],335,[RX_RSSI:-38]
168,[Sender:2],332,[RX_RSSI:-37]
169,[Sender:2],330,[RX_RSSI:-37]
170,[Sender:2],329,[RX_RSSI:-37]
171,[Sender:2],329,[RX_RSSI:-38]
172,[Sender:2],328,[RX_RSSI:-37]
173,[Sender:2],327,[RX_RSSI:-37]
174,[Sender:2],327,[RX_RSSI:-38]
175,[Sender:2],327,[RX_RSSI:-37]
176,[Sender:2],327,[RX_RSSI:-38]
177,[Sender:2],327,[RX_RSSI:-37]
178,[Sender:2],326,[RX_RSSI:-37]
179,[Sender:2],326,[RX_RSSI:-38]
180,[Sender:2],326,[RX_RSSI:-38]
181,[Sender:2],326,[RX_RSSI:-37]
182,[Sender:2],324,[RX_RSSI:-37]
183,[Sender:2],324,[RX_RSSI:-37]
184,[Sender:2],323,[RX_RSSI:-37]
185,[Sender:2],323,[RX_RSSI:-37]
186,[Sender:2],323,[RX_RSSI:-37]
187,[Sender:2],323,[RX_RSSI:-37]
188,[Sender:2],323,[RX_RSSI:-37]
189,[Sender:2],323,[RX_RSSI:-37]
190,[Sender:2],323,[RX_RSSI:-37]
191,[Sender:2],323,[RX_RSSI:-37]
192,[Sender:2],322,[RX_RSSI:-37]
193,[Sender:2],322,[RX_RSSI:-38]
194,[Sender:2],322,[RX_RSSI:-37]
195,[Sender:2],322,[RX_RSSI:-37]
196,[Sender:2],321,[RX_RSSI:-38]
197,[Sender:2],321,[RX_RSSI:-38]
198,[Sender:2],321,[RX_RSSI:-38]
199,[Sender:2],321,[RX_RSSI:-37]
200,[Sender:2],321,[RX_RSSI:-37]
201,[Sender:2],320,[RX_RSSI:-37]
202,[Sender:2],320,[RX_RSSI:-38]
203,[Sender:2],320,[RX_RSSI:-39]
204,[Sender:2],320,[RX_RSSI:-38]
205,[Sender:2],320,[RX_RSSI:-38]
206,[Sender:2],320,[RX_RSSI:-39]
207,[Sender:2],320,[RX_RSSI:-39]
208,[Sender:2],320,[RX_RSSI:-38]
209,[Sender:2],320,[RX_RSSI:-38]
210,[Sender:2],320,[RX_RSSI:-38]
211,[Sender:2],320,[RX_RSSI:-38]
212,[Sender:2],320,[RX_RSSI:-38]
213,[Sender:2],320,[RX_RSSI:-38]
214,[Sender:2],319,[RX_RSSI:-38]
215,[Sender:2],319,[RX_RSSI:-38]
216,[Sender:2],319,[RX_RSSI:-38]
217,[Sender:2],319,[RX_RSSI:-38]
218,[Sender:2],319,[RX_RSSI:-38]
219,[Sender:2],319,[RX_RSSI:-38]
220,[Sender:2],319,[RX_RSSI:-38]
221,[Sender:2],319,[RX_RSSI:-38]
222,[Sender:2],318,[RX_RSSI:-38]
223,[Sender:2],317,[RX_RSSI:-38]
224,[Sender:2],317,[RX_RSSI:-38]
225,[Sender:2],317,[RX_RSSI:-38]
226,[Sender:2],317,[RX_RSSI:-39]
227,[Sender:2],317,[RX_RSSI:-38]
228,[Sender:2],317,[RX_RSSI:-38]
229,[Sender:2],317,[RX_RSSI:-38]
230,[Sender:2],317,[RX_RSSI:-38]
231,[Sender:2],317,[RX_RSSI:-38]
232,[Sender:2],317,[RX_RSSI:-38]
233,[Sender:2],317,[RX_RSSI:-37]
234,[Sender:2],317,[RX_RSSI:-38]
235,[Sender:2],317,[RX_RSSI:-38]
236,[Sender:2],317,[RX_RSSI:-38]
237,[Sender:2],317,[RX_RSSI:-38]
238,[Sender:2],317,[RX_RSSI:-38]
239,[Sender:2],317,[RX_RSSI:-38]
240,[Sender:2],317,[RX_RSSI:-38]
241,[Sender:2],317,[RX_RSSI:-38]
242,[Sender:2],317,[RX_RSSI:-38]
@WhiteHare I assume you're not using auto mode for transmission? If you used that then you could use writing the first byte into the FIFO to start transmission (which would be done by entering intermediate mode programmed for TX mode), then immediately program RegOpMode to STANDBY before TX is complete. It should remain in TX mode then until the PacketSent event and then go to STANDBY immediately.
I think if you're not using auto mode then what you're seeing is normal manual driven process in that it will remain in TX until told otherwise even if the packet has been sent (presumably sending preambles). It's interesting that it exits TX at all in your case (do you use any other way to terminate things, like putting to sleep?). I actually specifically set to sleep after a packet sent event as I assumed it wouldn't stop TX until told to.
Have you ever succeeded in getting auto mode to work for transmission? My first attempt failed, and I'm not finding anything outside the datasheet when I do topic searches for it.I've never used it personally. How is it failing? Can you do a very simple transmit (program RegAutoModes intermediate state to be TX, enter condition to be fifo not empty, exit condition packet sent), i.e. RegAutoModes = 0b00111011 = 0x3B
Have you ever succeeded in getting auto mode to work for transmission? My first attempt failed, and I'm not finding anything outside the datasheet when I do topic searches for it.
#define AUTO_TRANSMITTER B01011011 // Enter = FIFO level; Exit = Packet Sent;
static inline void RadioInit(void) {
SPI_INIT();
CHANGE_OP_MODE(SLEEP_MODE); // Put the radio to sleep ASAP to save power
writeReg( REG_BITRATEMSB, RF_BITRATEMSB_300000 ); // 0x03
writeReg( REG_BITRATELSB, RF_BITRATELSB_300000 ); // 0x04
writeReg( REG_FDEVMSB, RF_FDEVMSB_300000 ); // 0x05
writeReg( REG_FDEVLSB, RF_FDEVLSB_300000 ); // 0x06
writeReg( REG_RXBW, RF_RXBW_DCCFREQ_111 | RF_RXBW_MANT_16 | RF_RXBW_EXP_0 ); // 0x19
writeReg( REG_RSSITHRESH, 220 ); // 0x29
writeReg( REG_SYNCCONFIG, RF_SYNC_ON | RF_SYNC_FIFOFILL_AUTO | RF_SYNC_SIZE_2 | RF_SYNC_TOL_0 ); // 0x2E - 2 sync bytes
writeReg( REG_SYNCVALUE1, 0xAA ); // 0x2F
writeReg( REG_SYNCVALUE2, NETWORKID ); // 0x30
writeReg( REG_PACKETCONFIG1, RF_PACKET1_FORMAT_VARIABLE | RF_PACKET1_DCFREE_OFF | RF_PACKET1_CRC_OFF | RF_PACKET1_CRCAUTOCLEAR_OFF | RF_PACKET1_ADRSFILTERING_OFF ); // 0x37 // 0x37
writeReg( REG_AUTOMODES, AUTO_TRANSMITTER ); // 0x3B - Put the radio in automatic mode
writeReg( REG_PACKETCONFIG2, RF_PACKET2_RXRESTARTDELAY_2BITS | RF_PACKET2_AUTORXRESTART_ON | RF_PACKET2_AES_OFF ); // 0x3D
SET_POWER_LEVEL(0);
Nice. Hopefully you'll get much less voltage drop due to the ESR as well, so I look forward to seeing the results from that test.
Mark.
I was able to automode transmit: https://lowpowerlab.com/forum/low-power-techniques/speeding-up-the-rfm69-library/msg17363/#msg17363
It is actually really straight forward. You put the radio in sleep mode and then later set the automode to have an intermediate mode of transmit. You enter intermediate mode when the FIFO is not empty and you exit intermediate mode on packet sent. Now as soon as you start filling the FIFO, the radio spins up and starts transmitting. Don't fill the FIFO slowly I guess but I'm running my SPI bus at 8MHz.Code: [Select]#define AUTO_TRANSMITTER B01011011 // Enter = FIFO level; Exit = Packet Sent;
static inline void RadioInit(void) {
SPI_INIT();
CHANGE_OP_MODE(SLEEP_MODE); // Put the radio to sleep ASAP to save power
writeReg( REG_BITRATEMSB, RF_BITRATEMSB_300000 ); // 0x03
writeReg( REG_BITRATELSB, RF_BITRATELSB_300000 ); // 0x04
writeReg( REG_FDEVMSB, RF_FDEVMSB_300000 ); // 0x05
writeReg( REG_FDEVLSB, RF_FDEVLSB_300000 ); // 0x06
writeReg( REG_RXBW, RF_RXBW_DCCFREQ_111 | RF_RXBW_MANT_16 | RF_RXBW_EXP_0 ); // 0x19
writeReg( REG_RSSITHRESH, 220 ); // 0x29
writeReg( REG_SYNCCONFIG, RF_SYNC_ON | RF_SYNC_FIFOFILL_AUTO | RF_SYNC_SIZE_2 | RF_SYNC_TOL_0 ); // 0x2E - 2 sync bytes
writeReg( REG_SYNCVALUE1, 0xAA ); // 0x2F
writeReg( REG_SYNCVALUE2, NETWORKID ); // 0x30
writeReg( REG_PACKETCONFIG1, RF_PACKET1_FORMAT_VARIABLE | RF_PACKET1_DCFREE_OFF | RF_PACKET1_CRC_OFF | RF_PACKET1_CRCAUTOCLEAR_OFF | RF_PACKET1_ADRSFILTERING_OFF ); // 0x37 // 0x37
writeReg( REG_AUTOMODES, AUTO_TRANSMITTER ); // 0x3B - Put the radio in automatic mode
writeReg( REG_PACKETCONFIG2, RF_PACKET2_RXRESTARTDELAY_2BITS | RF_PACKET2_AUTORXRESTART_ON | RF_PACKET2_AES_OFF ); // 0x3D
SET_POWER_LEVEL(0);
radio.setPowerLevel(0);
REG_OCP=B00001111
Is around 40ma current draw during Tx about as low as the RFM69HW goes?
void SX1231Driver::setPowerLeveldBm( int8_t powerLevel )
{
if( powerLevel > _maxPowerLevel ) powerLevel = _maxPowerLevel;
if( powerLevel < _minPowerLevel ) powerLevel = _minPowerLevel;
_powerLevel = powerLevel;
uint8_t paSetting;
uint8_t pwl18 = _powerLevel + 18;
if (_isHW) {
if( _powerLevel <= 13 ) // 0 - 13: -2 - +13, formula -18 + pwr
paSetting = SX1231_PALEVEL_PA1_ON | pwl18;
else // 14-20: +5 - +20, formula -11 + pwr
paSetting = SX1231_PALEVEL_PA1_ON | SX1231_PALEVEL_PA2_ON |
( 11 + _powerLevel );
}
else paSetting = SX1231_PALEVEL_PA0_ON | pwl18;
writeReg( SX1231_REG_PALEVEL, paSetting );
setHPRegisters();
}
The lowest the HW's go is -2 dBm which should be < 16 mA. However RFM69 doesn't support these low power levels. Here's the code I use which you could adapt:Code: [Select]void SX1231Driver::setPowerLeveldBm( int8_t powerLevel )
{
if( powerLevel > _maxPowerLevel ) powerLevel = _maxPowerLevel;
if( powerLevel < _minPowerLevel ) powerLevel = _minPowerLevel;
_powerLevel = powerLevel;
uint8_t paSetting;
uint8_t pwl18 = _powerLevel + 18;
if (_isHW) {
if( _powerLevel <= 13 ) // 0 - 13: -2 - +13, formula -18 + pwr
paSetting = SX1231_PALEVEL_PA1_ON | pwl18;
else // 14-20: +5 - +20, formula -11 + pwr
paSetting = SX1231_PALEVEL_PA1_ON | SX1231_PALEVEL_PA2_ON |
( 11 + _powerLevel );
}
else paSetting = SX1231_PALEVEL_PA0_ON | pwl18;
writeReg( SX1231_REG_PALEVEL, paSetting );
setHPRegisters();
}
uint8_t newPaLevel;
newPaLevel = (B01000000 | 18);
radio.writeReg( REG_PALEVEL, newPaLevel);
while (radio.readReg(REG_PALEVEL) != newPaLevel) { // block until the new register setting is confirmed
radio.writeReg( REG_PALEVEL, newPaLevel);
}
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.
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);
}
}
Remember that the setMode() call when changing to TX mode will override those power reg settings, did you disable that call?
Mark.
radio.writeReg(REG_OPMODE,B00001100); //activate RFM69 Tx mode.
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
}
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.
:)
Guys - this is awesome research, love watching this thread.
I'll try this cap out when I get a chance.
... 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.
Is low leakage predictive of low self-discharge rate, or are they two different animals? Datasheets report leakage far more than they do self-discharge rates.
In theory, switching to an RFM69W would yield 2-3x that number on the same test, if it were to transmit at 16ma instead of the ~40ma during Tx used by the RFM69HW in this test.
1,[Sender:2],000,[RX_RSSI:-39]
2,[Sender:2],204,[RX_RSSI:-38]
3,[Sender:2],207,[RX_RSSI:-39]
4,[Sender:2],210,[RX_RSSI:-38]
5,[Sender:2],211,[RX_RSSI:-39]
6,[Sender:2],214,[RX_RSSI:-38]
7,[Sender:2],216,[RX_RSSI:-39]
8,[Sender:2],219,[RX_RSSI:-39]
9,[Sender:2],222,[RX_RSSI:-39]
10,[Sender:2],223,[RX_RSSI:-38]
11,[Sender:2],226,[RX_RSSI:-39]
12,[Sender:2],228,[RX_RSSI:-38]
13,[Sender:2],231,[RX_RSSI:-40]
14,[Sender:2],233,[RX_RSSI:-37]
15,[Sender:2],234,[RX_RSSI:-36]
16,[Sender:2],236,[RX_RSSI:-37]
17,[Sender:2],237,[RX_RSSI:-37]
18,[Sender:2],239,[RX_RSSI:-37]
19,[Sender:2],243,[RX_RSSI:-38]
20,[Sender:2],245,[RX_RSSI:-38]
21,[Sender:2],247,[RX_RSSI:-37]
22,[Sender:2],249,[RX_RSSI:-37]
23,[Sender:2],251,[RX_RSSI:-37]
24,[Sender:2],253,[RX_RSSI:-38]
25,[Sender:2],256,[RX_RSSI:-38]
26,[Sender:2],257,[RX_RSSI:-38]
27,[Sender:2],260,[RX_RSSI:-37]
28,[Sender:2],262,[RX_RSSI:-38]
29,[Sender:2],264,[RX_RSSI:-38]
30,[Sender:2],266,[RX_RSSI:-36]
31,[Sender:2],268,[RX_RSSI:-38]
32,[Sender:2],271,[RX_RSSI:-36]
33,[Sender:2],272,[RX_RSSI:-37]
34,[Sender:2],274,[RX_RSSI:-37]
That's really good to know.
By the way, the test finally completed. The RFM69HW Moteino powered by Perky's cap sent a total of 258,210 packets! The loaded voltage at the time of failure (i.e. no more packets being sent) was 1.68v.
In theory, switching to an RFM69W would yield 2-3x that number on the same test, if it were to transmit at 16ma instead of the ~40ma during Tx used by the RFM69HW in this test.
Thanks, Perky!
However, running from 2.7v down to 1.8v produced only about 445K transmissions.
BTW I think your original suggestion of just charging the cap with a solar panel with a blocking diode is good, although I would replace that diode with an ideal diode circuit to limit the voltage drop to a few 10s of millivolts (see attached)
By the way, I notice Digikey sells a notionally similar idealized diode, all packaged up onto an single integrated circuit: https://www.digikey.com/product-detail/en/texas-instruments/SM74611KTTR/296-35688-1-ND/3911155
After charging it to 2.7v (reported by the Moteino as a loaded voltage of 2.66v at the start of the test), and draining it down to 1.8v (to the point where it was starting to display 1.79v), it transmitted 168,402 packets. So, not bad for the price.
You need to now charge a supercap with a PV panel with this in series and see! ;)
You need to now charge a supercap with a PV panel with this in series and see! ;)
I hooked it up. It works! Right now it's roughly noon here on an overcast day. I'd estimate the rate of charge is roughly comparable to my fancy pants charger.Cool, another piece of the jigsaw puzzle done ;-)
Not sure if I missed anything, but have you thought what's a good strategy to keep this from charging above 3.6v?
I would imagine a shunting zener plus low value resistor would do (sized properly for power).
Not sure if I missed anything, but have you thought what's a good strategy to keep this from charging above 3.6v?
685,[Sender:2],000,[RX_RSSI:-44]
686,[Sender:2],269,[RX_RSSI:-48]
687,[Sender:2],268,[RX_RSSI:-48]
688,[Sender:2],266,[RX_RSSI:-49]
689,[Sender:2],265,[RX_RSSI:-49]
690,[Sender:2],265,[RX_RSSI:-48]
691,[Sender:2],264,[RX_RSSI:-48]
692,[Sender:2],263,[RX_RSSI:-50]
693,[Sender:2],263,[RX_RSSI:-49]
694,[Sender:2],262,[RX_RSSI:-50]
695,[Sender:2],262,[RX_RSSI:-49]
696,[Sender:2],260,[RX_RSSI:-50]
697,[Sender:2],260,[RX_RSSI:-50]
698,[Sender:2],260,[RX_RSSI:-50]
699,[Sender:2],259,[RX_RSSI:-50]
700,[Sender:2],259,[RX_RSSI:-49]
701,[Sender:2],259,[RX_RSSI:-49]
702,[Sender:2],258,[RX_RSSI:-49]
703,[Sender:2],257,[RX_RSSI:-50]
704,[Sender:2],256,[RX_RSSI:-50]
705,[Sender:2],256,[RX_RSSI:-50]
706,[Sender:2],256,[RX_RSSI:-50]
707,[Sender:2],256,[RX_RSSI:-49]
708,[Sender:2],254,[RX_RSSI:-49]
709,[Sender:2],254,[RX_RSSI:-51]
710,[Sender:2],253,[RX_RSSI:-51]
711,[Sender:2],253,[RX_RSSI:-51]
712,[Sender:2],253,[RX_RSSI:-51]
713,[Sender:2],253,[RX_RSSI:-51]
714,[Sender:2],252,[RX_RSSI:-50]
715,[Sender:2],251,[RX_RSSI:-51]
716,[Sender:2],251,[RX_RSSI:-52]
717,[Sender:2],251,[RX_RSSI:-53]
718,[Sender:2],249,[RX_RSSI:-52]
719,[Sender:2],248,[RX_RSSI:-52]
720,[Sender:2],250,[RX_RSSI:-51]
721,[Sender:2],249,[RX_RSSI:-51]
722,[Sender:2],248,[RX_RSSI:-51]
723,[Sender:2],248,[RX_RSSI:-51]
724,[Sender:2],247,[RX_RSSI:-52]
725,[Sender:2],247,[RX_RSSI:-51]
726,[Sender:2],247,[RX_RSSI:-52]
727,[Sender:2],247,[RX_RSSI:-52]
728,[Sender:2],246,[RX_RSSI:-51]
729,[Sender:2],244,[RX_RSSI:-51]
730,[Sender:2],245,[RX_RSSI:-51]
731,[Sender:2],244,[RX_RSSI:-51]
732,[Sender:2],243,[RX_RSSI:-51]
733,[Sender:2],244,[RX_RSSI:-51]
734,[Sender:2],244,[RX_RSSI:-50]
735,[Sender:2],243,[RX_RSSI:-50]
736,[Sender:2],243,[RX_RSSI:-50]
737,[Sender:2],243,[RX_RSSI:-50]
738,[Sender:2],242,[RX_RSSI:-49]
739,[Sender:2],242,[RX_RSSI:-50]
740,[Sender:2],241,[RX_RSSI:-49]
741,[Sender:2],241,[RX_RSSI:-49]
742,[Sender:2],240,[RX_RSSI:-50]
743,[Sender:2],238,[RX_RSSI:-49]
744,[Sender:2],238,[RX_RSSI:-50]
745,[Sender:2],238,[RX_RSSI:-49]
746,[Sender:2],238,[RX_RSSI:-49]
747,[Sender:2],238,[RX_RSSI:-50]
748,[Sender:2],238,[RX_RSSI:-50]
749,[Sender:2],236,[RX_RSSI:-50]
750,[Sender:2],236,[RX_RSSI:-50]
751,[Sender:2],236,[RX_RSSI:-50]
752,[Sender:2],236,[RX_RSSI:-49]
753,[Sender:2],235,[RX_RSSI:-50]
754,[Sender:2],235,[RX_RSSI:-50]
755,[Sender:2],235,[RX_RSSI:-50]
756,[Sender:2],234,[RX_RSSI:-50]
757,[Sender:2],234,[RX_RSSI:-50]
758,[Sender:2],234,[RX_RSSI:-48]
759,[Sender:2],233,[RX_RSSI:-49]
760,[Sender:2],233,[RX_RSSI:-50]
761,[Sender:2],233,[RX_RSSI:-49]
762,[Sender:2],233,[RX_RSSI:-50]
763,[Sender:2],233,[RX_RSSI:-49]
764,[Sender:2],232,[RX_RSSI:-50]
765,[Sender:2],232,[RX_RSSI:-49]
766,[Sender:2],231,[RX_RSSI:-50]
767,[Sender:2],231,[RX_RSSI:-48]
768,[Sender:2],230,[RX_RSSI:-50]
769,[Sender:2],230,[RX_RSSI:-49]
770,[Sender:2],230,[RX_RSSI:-50]
771,[Sender:2],229,[RX_RSSI:-50]
772,[Sender:2],229,[RX_RSSI:-50]
773,[Sender:2],228,[RX_RSSI:-50]
774,[Sender:2],228,[RX_RSSI:-49]
775,[Sender:2],228,[RX_RSSI:-50]
776,[Sender:2],227,[RX_RSSI:-50]
777,[Sender:2],226,[RX_RSSI:-50]
778,[Sender:2],227,[RX_RSSI:-50]
779,[Sender:2],226,[RX_RSSI:-49]
780,[Sender:2],226,[RX_RSSI:-49]
781,[Sender:2],225,[RX_RSSI:-50]
782,[Sender:2],225,[RX_RSSI:-50]
783,[Sender:2],224,[RX_RSSI:-50]
784,[Sender:2],223,[RX_RSSI:-50]
785,[Sender:2],223,[RX_RSSI:-49]
786,[Sender:2],223,[RX_RSSI:-50]
787,[Sender:2],223,[RX_RSSI:-49]
788,[Sender:2],222,[RX_RSSI:-49]
789,[Sender:2],222,[RX_RSSI:-49]
790,[Sender:2],221,[RX_RSSI:-49]
791,[Sender:2],220,[RX_RSSI:-50]
792,[Sender:2],221,[RX_RSSI:-49]
793,[Sender:2],220,[RX_RSSI:-50]
794,[Sender:2],220,[RX_RSSI:-49]
795,[Sender:2],220,[RX_RSSI:-50]
796,[Sender:2],219,[RX_RSSI:-50]
797,[Sender:2],219,[RX_RSSI:-50]
798,[Sender:2],219,[RX_RSSI:-47]
799,[Sender:2],218,[RX_RSSI:-50]
800,[Sender:2],216,[RX_RSSI:-48]
801,[Sender:2],217,[RX_RSSI:-50]
802,[Sender:2],217,[RX_RSSI:-49]
803,[Sender:2],216,[RX_RSSI:-50]
804,[Sender:2],216,[RX_RSSI:-49]
805,[Sender:2],216,[RX_RSSI:-49]
806,[Sender:2],215,[RX_RSSI:-49]
Not sure if I missed anything, but have you thought what's a good strategy to keep this from charging above 3.6v?
The problem with the 5ms period on the listen-mode is that it's just so damn energy intensive. 0.64ma may not sound like much of a current draw, but it is for a supercap. To illustrate, I charged a 50F supercap to 2.7v and hooked it to a Moteino doing the 5ms (0.64ma) energy draw, and starting logging the voltage measurements at 5 minute intervals
Using t = C(Vs - Vf)/ I, where Vs = start voltage and Vf = end voltage, and assuming linear discharge, you should get
t = 50(2.7 - 1.8)/0.00064 = ~70000 seconds, or 19 hours. In your logs your end voltage was 2.15V, so plugging that in gives
t = 50(2.7 - 2.15)/0.00064 = ~43000 seconds, or 12 hours. About right.
Mark.
I like the simple approach without integrated charger. But one thing that needs to be figured out is how to prevent the moteino from starting up until VCC exceeds 1.8V. Otherwise you'll never make it since both the radio and the 328p draw quite a bit while trying to start up. That's where the "power good" pin of the charger comes in handy.
No success thus far at receiving packets with the 128usec listen window.
I suspect the ListenMode discussion can be separate from this supercap thread? If so lets start another thread dedicated to that and I can move the messages there, please let me know.
BTW my supercap has been discharging significantly after leaving it idle on my desk, not getting a lot of light. Now around 3.7V from 4.1V.
Regarding the supercap, is that the loaded or unloaded voltage you're measuring? What led me to the original supercap that I posted about on this thread was that its unloaded voltage drop was exceptionally small (IIRC, something like 0.01v per day). I haven't yet circled back to see what its loaded voltage drop is over time. I now have the right tool for measuring that, whereas before I didn't. I suspect that for less energy intensive applicatiions, it might still be a good choice, both for that reason and because of its relatively small size.It's with the diode and solar cell attached, as seen in the photo I posted above.
BTW my supercap has been discharging significantly after leaving it idle on my desk, not getting a lot of light. Now around 3.7V from 4.1V.
What led me to the original supercap that I posted about on this thread was that its unloaded voltage drop was exceptionally small (IIRC, something like 0.01v per day).
's a bit odd. The DCL (i.e. leakage) current for that part is quoted at 120uA, it should have been significantly worse than that by a couple of orders of magnitude...
uint32_t startTime;
void loop() {
if (buttonPressed()) {
startTime = micros();
while ((micros() - startTime)<10000) {
blockingSendPacket();
}
delay(1000);
}
It seems we still really haven't found the Holy Grail of supercaps yet as the 56uA leakage of the 7.5F cap is still quite high for very low power systems.
Also I believe this approach won't exceed what the FCC allows for as the maximum on-air Tx time and duty cycle. However, I should probably double check the FCC rules again just to be sure.
I like the simple approach without integrated charger. But one thing that needs to be figured out is how to prevent the moteino from starting up until VCC exceeds 1.8V. Otherwise you'll never make it since both the radio and the 328p draw quite a bit while trying to start up. That's where the "power good" pin of the charger comes in handy.
There are versions of ideal diodes that require a supply and I wanted it to work down to 1.6V and couldn't find any that went that low, so hence the discrete version.
For over-voltage protection, could you just use a LDO?
My little panel outputs 5.5V in full sun, it is a cheap one from a solar motion light. I have used a 3.3V LDO and a Si diode for reverse current protection.Nice and thrifty. I like it.
I am also looking at the DS and notice that there is a way of increasing the hysteresis, I might do that to power down at 1.8V and not come out of reset until I get to 2V to make sure that the start-up does not cause a drop below 1.8V.
I connected the NCP301 to a load switch (see attached photo), and voilà ! It prevents the Moteino from being booted until the voltage on the supercap reaches the threshold voltage (in this case, 1.88v).
Check out this part from TI - TPS3806J20. Two separate voltage monitors one where you can set the High and Low with three resistors. I might build up a board with this and a simple LDO + Si Diode as solar power supply.
Paul
BTW I can't read the jpg of your equivalent circuit, could you repost?
In my projects I'm going to replace the TSM2313CX with DMG2305UX I think, it's a little worse for RDSon at 1.8V but does have low gate leakage.
You'll need a diode, preferably ideal. Once the FET has turned on in your circuit it is like a switch that remains on until the voltage drops below the threshold, but that means when the panel output drops it will just pull the voltage on the supercap down with it.
Mark.
I added a diode to the design, and it seems to have addressed the leakage issue. Attached is the updated schematic.
Your last file uploaded seems borked.
I think you might need to abandon this approach and instead use a 2.7V LDO to clamp the voltage from the solar panel and then follow with an ideal diode or use a 3.0V regulator followed by a schottky diode.
From what I've seen so far, Schottky diodes that are rated above 200ma current do seem to allow surprisingly high reverse currents. So, I've focused on 200ma and below. I found this one: https://www.digikey.com/product-detail/en/nexperia-usa-inc/1PS79SB30,115/1727-4782-1-ND/2531260
which I have on order. It claims to have a reverse current of 500na at 25v, and so I'm assuming (?) that it will have an even lower reverse current at 5.5v and below. At least, that's how I hope it works. ::) Anyhow, I should receive it on Friday, so we'll soon see.
It'll be interesting to hear the results of the ideal diode experiment (assuming you still are planning to do one) ;)
BTW I would consider using a NCP300 totem pole driver here and remove the 100k pull-up. If the solar input voltage is low and the supercap is below the threshold you'll sink 10uA through that pull-up. Now you've got a voltage controlled load switch you can use the totem pole output instead ;)
Excellent suggestion! I'll be sure to give that a try.
BTW I think you might need to protect against the power-up condition between 0V and 0.95V accidentally turning on the load switch (see figure 13, the shaded bit at the bottom). If that happens the main FET is turned off and it will stop charging and remain in that state.
I'm guessing that a suitable n-channel mosfet might work just as well as the load switch.A simple N-channel FET won't work I think, you need to turn off the top pass FET when there's a high on the comparitor's output. The load switch is a good solution. An interesting project.
Interestingly, SII also makes a voltage detector chip with a voltage sense pin that's separate from the chip's Vcc pin: https://www.digikey.com/product-detail/en/sii-semiconductor-corporation/S-1002CA27I-M5T1U/1662-1084-1-ND/6601224
Now, SII's S-1000 voltage detector chip (which is what I last used in the prototype) allegedly has a current consumption of just 350na, which is supplied by the supercap. In contrast, the S-1002 allegedly consumes 500na. However, I wonder whether the S-1002 can be powered by the solar panel, while only its sense pin is wired to the supercap, and, if so, whether in that case the current drain on the supercap might be even lower than 350na? 350na isn't big compared to most supercap's, but since I'd like the Moteino to be able to run almost instantly (albeit briefly) after being exposed to even dim sunlight, I foresee using a much smaller cap as the startup cap that the Moteino might initially run from. In that context, a constant drain of 350na on a much tinier cap might not seem so small.... So, for that reason, I think the S-1002 might be worth investigating.
Time to hack together Optiboot 6.2.1 then ;D
Are you abandoning the large cap version now then? I'm a little confused, I though that was needed to keep it going for a day..
Mark.
Eventually, I think I'd like to somehow run the Moteino from TWO supercaps: a small one, and a big one. The idea being: quickly charge the small one first, so the Moteino can get up and running right away, even if all it does is transmit, "I'm alive" and give a steady stream of wireless reports on what the rising charge voltage is on the bigger supercap. That would be more satisfying than setting it up only to wait a very long time just to hear that that the voltage on the big supercap finally crossed the 1.8v threshhold, because in the interim you're left wondering just what the heck, if anything, is going on with it. ;D
I'll need to consider the circuitry for how to unify the two caps into one system, so as to get the best of both worlds. I anticipate that will leverage the work already done on the big supercap, so none of the work done to date will be wasted.
How small of a solar panel are you using currently? In a perfect world the panel would be roughly the same size as the mote itself and I could envision stashing these all over and never having to fool with batteries. Can you provide linkto some suitable small panels that I can fool with?
More good news: I did some more careful measurements, and I found that with Optiboot 6.2 I could complete the ATMEGA328p startup (i.e. from total powerdown to HIGH on pin 9) by charging a mere 0.47uF ceramic cap to 3.6v. And I think it could go lower even than that, but that's where I stopped measuring for today.
Now for the really GREAT NEWS: With Optiboot 6.2 installed, I was able to power up an ATMEGA328p--and by that I mean, from completely powered off to pin 9 going HIGH--from a mere 1,100uF capacitance charged to 2.0v. Well, why is that great news? Because my mini solar panel can charge that 1,100uF of capacitance to that voltage in the blink of an eye.
More good news: I did some more careful measurements, and I found that with Optiboot 6.2 I could complete the ATMEGA328p startup (i.e. from total powerdown to HIGH on pin 9) by charging a mere 0.47uF ceramic cap to 3.6v. And I think it could go lower even than that, but that's where I stopped measuring for today.
Doing just that and no other changes (same sketch as before to simply drive pin 9 HIGH), it now takes more like 47uF charged to 3.6v. Neither 0.47uF nor 4.7uF appear to be sufficient.
That way starting up uses way less power.
Instead of using the RFM69 init code try directly using SPI to sleep the radio first thing after boot. Do this by writing mode sleep into the mode register and read back until it sticks. That way starting up uses way less power.Thanks! I'll give that a try.
Joe
The next step will be working out the "hand-off" between the small cap and the big supercap, which will happen when the big supercap reaches a voltage in the range of 1.8 to 1.9v. After the hand-off, the Moteino will be powered directly from the supercap, and charging will continue as normal.
Zip-a-Dee-Doo-Dah! I got lucky with the first piece of the puzzle on how to unify the two caps. Basically, the solar panel charges the small cap while a copy of the earlier boot circuit (except with a 2.7v NCP301 insead of a 1.8v NCP301) is connected between the small cap and the big supercap. I tested it this morning, and it works. Essentially, the small (470uF) cap charges to 2.72v and then any extra charge current gets shunted into charging the big supercap. This gives priority to charging the small cap, so the Moteino can be up and running almost instantly rather than having to wait for the big supercap to charge to 1.8v. On a voltmeter, it looks as though the voltage on the small cap is a stable 2.722v, but I'm sure an oscilliscope would show the small cap's voltage bouncing between 2.7v and 2.722v.
Instead of using the RFM69 init code try directly using SPI to sleep the radio first thing after boot. Do this by writing mode sleep into the mode register and read back until it sticks. That way starting up uses way less power.
Joe
I haven't looked at this thread in a bit - so just thinking out loud here:
1) It seems that excess voltage is a problem that can easily be solved in software - e.g. by putting the radio in RX to burn off excess energy.
Worst case, how much extra heat would that introduce into the electronics enclosure?
If you're really worried about internal heat, shunt the excess voltage to a peltier. Win-win-win.
solar_panel-> LDO +-> schottky_diode-> 470uF -> ideal_diode +-> MCU (BOD enabled)
| |
+-> schottky_diode-> 5F -> ideal_diode -+
Not sure of their quality yet, but PCBs.IO is even cheaper.
All good work WhiteHare.
Or possibly:Code: [Select]Edit: You'd need resistors obviously to charge up the two caps to different voltages.solar_panel-> LDO +-> schottky_diode-> 470uF -> ideal_diode +-> MCU (BOD enabled)
| |
+-> schottky_diode-> 5F -> ideal_diode -+
Mark.
Actually the DMG2305UX appears as you say to be available with two part numbers, with a -7 or -13 in it. They point to the same datsheet, and the Diodes website doesn't have these -7 or -13 references. The Q parts are just automotive qualified parts but appear also to have the same specs. Curious.
Anyway, there seems to be a better version with a lower RDSon of 113mR at Vgs of 1.8V called the DMP2305U-7 which is also widely available, so I'll use that instead:
DMP2305U: https://www.diodes.com/assets/Datasheets/ds31737.pdf
DMG2305UX: https://www.diodes.com/assets/Datasheets/DMG2305UX.pdf
Mark.
Er, 1.8V LDO means the regulation voltage is 1.8V and the output won't ever go above 1.8V, so you'll never charge anything up!
Attached is a photo of the assembled version 3 Perky Smart Diode breakout board.
[Edit: I played around with it a bit. It seems to do its job as a diode, in that it blocks reverse flow of current. At low voltages on the supercap, it drops about 0.5v. At higher voltages, it drops about 0.05v.
In contrast, the Schottky diode drops about 0.3v, regardless of what the supercap voltage is.
So, maybe one could get the best of both worlds by wiring the Schottky diode in parallel with the Perky Smart Diode? I haven't yet tried it, but I'm thinking that at the lower voltages it might drop 0.3v, and then at the higher voltages it would drop 0.05v.
Well, more characerization could be done, but that was just a quick look.]
Thanks for the links. This project is pretty interesting to me. I've found some SMD mountable supercaps and wonder if any of them could work as the small/boot capacitor. I'm always looking to make these sorts of things smaller after all. Something along these lines:
http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeyCPX3225A752D
Hey my pleasure. I'd like to see this project as small and cheap as possible since I plan on having a play at some point. My hope is you can get the power requirements down low enough that a few F will get it through a few overcast days. I found something else interesting that might be able to serve as the primary supercap. http://www.cytech.com/products-ips Scroll down to the bottom and check out the MEC202. The size is shockingly small and 2.2mAh used a few ms at a time should last a decently long time. If that could work, then the whole project would shrink to not much larger than a mote. Pair that with a very small solar panel and you're golden.
I like those little digikey ones.
Yeah - these are cool!
So one of these, a smd supercap and the voltage controller. We could make a little "power" board, round, solar in the middle. super cap on one side, voltage controller on the other - as CR2540 replacement. Just solder these over your motes, the radio underneath and you'd get a nice little tripple stack.
I wouldn't even bother with the 2 cap approach. Just pre-charge and go.
Everything else can be done in software. E.g. burning off excess voltage should that ever become a problem. Or drastically reducing ping frequency when voltage sags.
Joe
I'd be curious if something that small could put a decent amount of charge in that little solid state battery that I posted. If a 22mm x 7mm cell works, it certainly would not define the form factor.
Thanks for the links. This project is pretty interesting to me. I've found some SMD mountable supercaps and wonder if any of them could work as the small/boot capacitor. I'm always looking to make these sorts of things smaller after all. Something along these lines:
http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeyCPX3225A752D
You mean the MEC202? Is anyone selling it? I certainly could be wrong, but from looking at the company's website, I gathered the impression that it's probably vaporware.
I like those little digikey ones. I'd be curious if something that small could put a decent amount of charge in that little solid state battery that I posted.
Didn't I read somewhere that caps leak a lot the first 30 minutes or so at voltage and then they begin to improve and eventually reach their rated leakage?Believe it or not: 72 hours!
Now that lunar power is out, any sense how large a primary cap you'll need to see you through the night and some short overcast winter days?
Good news! After installing Optiboot 6.2Would you be so good and provide me with files I would need, even more so, what commands to run (or anybody else that knows how to). I can't use even the bootloader HEX that is already compiled, IDE just can't upload any sketch