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

[WhiteHare]

I see.  So, unloaded voltage then.

Moving along... I guess the near-term solution will likely be:

1.  send ultra-short packets to fit while trying to manage the RSSI situation (finding the right Goldilocks RSSI threshhold).  Longer-term that might involve switching channels if too much interference develops

OR

2.  Bite the bullet and move to clock syncs.

#1 is easier than #2, and might be good enough, but it's chancy while #2 seems like the proper way to do it.  Seems to me that #2 would be easier to accomplish if there were an RTC, as I would imagine that turning Listen-Mode on/off/on/off a lot to send packets and so forth is going to make maintaining sync on the RFM69 a lot harder.

Argh, things are just never as easy as they seem before getting into it.

[Edit: OR, option 3 is to swap the 50F supercap for a 100F supercap and make do with 256uSec Rx windows.  This, of course, is the easiest of all.     I'm expecting a 100F supercap to arrive today, so I'll give that a try.]

[perky]

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.

Well if that's the AVX 7.5F cap it has a DCL at 25 deg C of 65uA (that's about half WhiteHare's 15F Vishay cap which is quoted at 120uA).  Plugging into the equation t = C(Vs - Vf)/ I, we get:
t = 7.5(4.1 - 3.7)/65e-6 = 46153 seconds, or half a day.

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).

Now that'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...

Mark.

[WhiteHare]

'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...

IIRC, it seemed to drop around 0.3 volts (from the initial 3.6v) relatively quickly, but then it seemed to level off at the much lower rate that I indicated.  That was markedly different than the other supercaps I tried, which appeared to drop voltages at a much faster rate over time.  All the measurements were unloaded voltages, which at the time was all I could easily test.  I've a hunch the loaded voltages might tell a different tale.  As it's not immediately relevant to the remote control project (well, at least not the current energy intensive embodiment of it), I probably won't be load testing it anytime soon though.

[perky]

Interesting, so you're saying it self disharges as expected from the leakge spec until it's 0.3V below rated, then that drops right off, until it gets to below 1V and then falls off a cliff when loaded (I can see why you make a distinction between load and unloaded now ).

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.

Mark.

[WhiteHare]

Utilizing the 256uSec Rx window on the receiver, the code on the remote control transmitter is quite simple:

Code Select Expand

uint32_t startTime;
void loop() {
  if (buttonPressed()) {
    startTime = micros();
    while ((micros() - startTime)<10000) { 
      blockingSendPacket();
    }
  delay(1000);
}

In some quick off-the-cuff testing, those packets seem to hit the Rx window every time.  If it doesn't, then it will repeat every second thereafter for as long as the button is pressed.  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. 

Looking at it now, I should probably just count the packets sent during the 10ms and then subtract one packet from that just to make sure I don't start a packet that transmits beyond the maximum allowed 10ms Tx window.

[WhiteHare]

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.

Yes, any suggestions for supercaps that might help in that regard would be quite helpful.  So, if anyone reading this has suggestions, please don't be bashful about posting them!

[perky]

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. 

My understanding is that there isn't a duty cycle spec as such for FCC. For a single channel system the spec is about keeping spectral power density below a certain limit, otherwise it mandates frequency hopping with either 25 or 50 channels. You're using 300kbps with large Fdev so that means you could use higher power but the Samtech app note still suggests that's relatively low (maybe 10dB, I can't remember). The frequency hopping is sort of a duty cycle spec, at least that's its effect.

Mark.

[WhiteHare]

I had a 310F supercap laying around, so I tried that.  The solar charger charged it yesterday with no problems.  Nice thing is that it has enough reserve capacity that it can support doing other useful  work as well.  On the other hand, one of the main drawbacks to it is just the sheer size of it: about the size of a D-cell battery.

[WhiteHare]

I had run into the Listen-Mode "bug," wherein the RFM69 ocassionally gets stuck in the Rx phase of Listen Mode when it really shouldn't.  At least in my case, enabling RegRxTimeout2 solves the problem.

[WhiteHare]

Well, after looking into it on the other thread, the irony is that rather than paring down the number of transmitted bytes, I should probably actually increase the number of preamble and sync bytes.

So, I'm going to try switching to the RF setup for 300kbps given in table 2 of http://www.semtech.com/images/datasheet/fcc_digital_modulation_systems_semtech.pdf.  That way it appears I can have not only a wider listen Rx window but also a much wider Listen Idle period, because with that approach under FCC part 15.247  it does not appear there would be any duty cycle limitations on transmissions, as it appears there might be with FCC part 15.249.  That should allow me to save power overall and use smaller supercaps as a consequence.

[perky]

I think 15.249 covers the general case (-1dB TX power) with no duty cycle restrictions, and it's 15.247 that covers either frequency hopping or digital modulation. It does seem that this would comply with digital modulation scheme though, which is 15.247.

Note this is low beta stuff, I think you might need to set the DCC to as small as possible to narrow the centre notch as much as possible to get the best sensitivity, and use data whitening as this test was done using a PN15 random data stream.

Mark.

[WhiteHare]

You're right about the Part 15.249 not explicitly imposing a duty cycle.  I suppose if I were to Tx at -1dBm or lower then there would be no duty cycle restriction.  It's just that if the Tx power is greater than -1dBm, then I don't know how I could meet the imposed requirement for an average of -1dBm over every possible 100ms window of time unless there were a duty cycle. 

Back when I originally approached this, I wasn't sure that 11.8dBm would be enough Tx power to cover all the worst possible cases, and so I was trying to see how high I could push it and yet remain legal.  After all, I can always back off from the limit, provided I know what the limit is.  I think now, after gaining greater familiarity, I'm more comfortable  that 11.8dBm will be enough.  For sure, being able to have a remote control that can Tx continuously on demand so as to hit a relatively narrow Listen-Mode Rx window is a lot simpler than syncing clocks, so I'd like to try that first.  That's what's driving me to switch my approach and embrace the 300kbps 11.8dBm Table 2 limit.

[WhiteHare]

I've made the code changes: I have Listen Mode activating now every 98.4ms for a comfortable Rx period of 6*64usec=384 uSec.  It works great. I'll downgrade to a smaller 10F supercap (the cheap $2 Illinois one) and see how that goes. 

Also, the remote now works with a pushbutton, so it's starting to feel more like an true remote control instead of a telemetry project.

[perky]

Cool, keep up the good work!
Mark.

[WhiteHare]

The currently working Listen-Mode arrangement has an Rx window of 192uSec every 100ms.  The radio in Rx mode will consume about 16ma during that window.

So, to be conservative, and to account for the mcu current, let's round up and say that the device consumes 20ma during a 200uSec window, every 100ms.

Let's figure out what that would average out to.

Time activated per hour = (200uSec)*10*60*60=7.2 seconds/hour

So, average current = 20ma*(7.2/3600)=40uah=0.04mah

Therefore, the amount of current consumed over a 24 hour period=24*0.04=0.96mah. 

Meh, not bad.