Cubecell ADC behavior as Vdd changes?

I believe the best low power performance on the AB01 dev board comes when Vdd is directly powered, with the data sheet saying Vdd should be from 3.0 to 3.3 volts. I have been doing that using a battery which starts slightly above 3.3v. This works very well and I’ve been able to see 3.5uA sleeps using a meter, and then executed two field trials of several months length. My time of service on a single battery is really only limited by the message duty cycle I choose. Ultimately though the battery drops significantly below 3.0v and things stop working (see below).

The plan had been to use the ADC to monitor battery voltage, after removing BR01, and using Vext to keep from bleeding electrons through a voltage divider. That circuit works fine and is able to take meaningful readings using the ADC on a bench setup. Unfortunately, it looks like Vref changes as Vdd drops? That’s just a guess. It behaves like the Vref change is directly in proportion to the Vdd change, and thus the ADC reports nearly the same value no matter what my battery voltage is. I’ve recently used a pair of adjustable power supplies to check this and can actually watch my readings go up as I dial Vdd down if I keep the ADC pin voltage steady. I’ll probably try to take some data a bit later to see if it’s linear, and try another AB01 board. It’s a difficult test setup because right now I have to use LoRa messaging to watch the board behavior when powered through Vdd. Note that if the behavior is not linear then we’re good and it’s just a matter of mapping the behavior. If Vref and Vdd are directly tied then it pretty much makes the ADC useless for this purpose.

I am using the “CubeCell Development Framework” version 0.0.5 updated a few days ago through the Arduino IDE. Would it be possible for someone else to confirm the ADC behavior? At this point I believe I have to abandon the direct Vdd power or get an external ADC (or maybe there’s a software patch?) I will be experimenting this week with an I2C ADC, but it would be sort of sad to not use the one supplied on the chip. Is there any chance the ASR6502 is different, or there’s a code change not in the 0.0.5 version?

In the previous ADC function, the Vref is VDD, this will cause a problem, if the voltage higher than VDD, all value will be considered as 3.3V, and when the VDD voltage drops, the kind of problems you encounter will occur.

In a later version (which specific version I can’t recall), we use the internal 1.2V as Vref, this will avoid the problems described above. But note that in this case, the maximum input voltage allowed by the ADC pin is 2.4V, so you need to add a voltage divider circuit to the input pin of the ADC.

This topic showed how is a voltage divider circuit work:

Please update the development framework to the newest version, I think the ADC will work well at your side.

Thanks! My Arduino IDE had cached the Heltec board manager package index. Even updating the IDE didn’t fix it. I had to switch from docs.heltec.cn to resource.heltec.cn to get it to reload and show me the new versions. Very annoying, but not Heltec’s problem.

Using the 1.0.0 version works better for the ADC, and indeed I’m able to run the radio and chip from 3.4v all the way down to 2.4v with nicely linear reporting through the ADC. I have no idea of whether CubeCell would be reliable down that far, and my sensors won’t run below 2.5v anyway, so I stopped checking at that point. RSSI from a couple of receivers didn’t show much difference as I adjusted Vdd, but these tests are all near-field and probably invalid for radio checks. I didn’t check any receive functions as I adjusted Vdd, but presume they’re at least similar to the transmit side.

Now that I’m more confident on my hardware, does anyone have a recommendation for an inexpensive LoRaWAN gateway for very light message traffic? My test area is somewhat isolated and if I’m going to play with TTN I’ll have to set up my own access. As it is, I’ll have to relay messages to even get near a place where I can link in a gateway.