Thanks for your CubeCell information on GitHub.
“Best obtained” in what configuration?:
IIRC I read somewhere that the 3.5 μA in sleep mode is when externally powered via 3.3V pin (e.g. powered directly from LiFePO4 battery).
@andreas58 please use the github version.
that version will always contain all bug fixes.
the library manager version is outdated.
@bluejedi. Hi thanks for your comments . The test was carried out with a working Script and a BME680 sensor powered via Vext, sending every 15 minutes,with no AT support or USB connected. This showed 20 μA current was when the node was in its sleep cycle and with a much higher level when powering sensor RX or TX. The Power was only supplied by 3.7v Lipo-ion battery connect though the battery connector. If you use USB it will be Higher and if charging etc… I would note that when powered from a 3.3v supply then you can get around 4μA, Please dont connect directly a battery to the 3.3 v rail as may cause damage.
I have a battery life calculatator on my web site in downloads to workout battery life based on the consumprion by, sensor,RX, Dwell Time ,TX , SF, Duty cycle etc. It is here https://securethings.uk/sdm_downloads/lorawan-energy-calculator.
I have heard that some people have got arround 10μA, But I do not know what their settings were let me know if you get it that low.
Simon
Directly connecting a 3.2V LiFePo4 battery should be possible voltage-wise.
Is there any other reason than voltage (or reverse polarity) that may cause damage?
I’m trying to understand the missing pieces of the ‘Power management system’ part in the HTCC-AB01 diagram to find out how to properly connect power to the board (and how not) in order not to damage it. There are Vusb, Vin, Vs(olar), VDD and Vext and their relation and what can and cannot be connected at the same time does not become clear from the circuit diagram (because parts are missing).
E.g. is it safe to connect USB and Vin at the same time?, is it safe to connect USB and a solar panel at the same time? Are these protected by the ‘power management and charging system’ or not? This does not all become clear from the diagram and documentation.
In the HTCC-AB01 circuit diagram some essential parts of the ‘Power management system’ are only represented by ‘functional blocks’ (black boxes) which hides their actual implementation. 
The diagram shows that:
While trying to figure out how things are connected I noticed that:
I measured 3 μA current during sleep using the following test setup:
Heltec CubeCell HTCC-AB01 board.
Only power (and antenna) connected to the board.
Powered from 2 alkaline AA batteries (3.1V) directly to the 3.3V/VDD pin.
I used the Basics/LowPower_WakeUpByTimer example sketch to put the board in and out of sleep and increased the timetosleep and timetowake values to 60000 (60 seconds) so I had some time to do the measurements (μCurrent Gold requires manual range switching).
Just to be sure I additionally disabled Vext (at the start of both OnSleep() and OnWakeup()).
I even had AT Support still enabled in the IDE (had forgotten to turn it off). Maybe the Radio.Sleep() call in the sketch also disables the AT stuff during sleep but that’s just a guess.
Hi thanks for that info good to know you got down that low .will try when have time.Simin
This is the new documents page: https://heltec-automation-docs.readthedocs.io/
It’s still in construction… We are open to hear from you.
Hi @bluejedi, YES, the AT commands is disabled during deep sleep. CubeCell can be wake up via Serial port… But actually it’s wake up through GPIO interrupt. That’s why the first awaken data cannot be recognized by the system.
Thanks (I had already found it).
Some questions:
I noticed that disabling AT support in the IDE tools menu (which requires ASR650x Arduino Core v0.4.0) does not make the compiled code (binary) size any smaller.
Why?
[Update] Because this only has effect for LoRaWAN applications and apparently I had only tested this for non-LoRaWAN applications.
For what situations/reasons would disabling LoRaWAN AT support be an advantage?
How is LoRaWAN AT support implemented:
You can disable it by uncomment it completely in the cor lib of heltec see:
https://github.com/HelTecAutomation/ASR650x-Arduino/search?utf8=✓&q=AT_Command.h&type=
See update at the bottom. The rest of this post has become irrelevant.
Thanks for the tip.
Your suggestion is rather cryptic. With “cor lib” do you mean “both the LoRaWAN library and the kernel of the Arduino Core”? And I assume you meant comment out instead of uncomment.
So if I understand correctly, to completely disable AT support code the #include "AT_Command.h" statements have to be commented out from the following Arduino Core files:
libraries/LoRa/src/LoRa_APP.h
libraries/LoRa/src/LoRaWan_APP.h
cores/asr650x/kernel/protocols/lorawan/lora/mac/LoRaMac.c
Is this documented somewhere?
Does this have any (unwanted) side effects?
One shall not have to mess with the source code of the Arduino Core (LoRaWAN library included) to (truly) disable a feature like AT support, because error prone and a maintenance nightmare.
Common options should be enabled/disabled solely via configuration settings and not require any Arduino Core kernel and/or library source code changes.
Enabling or disabling AT support is a choice to be made at compile time, not runtime. The compiled binary should therefore not contain any AT support code when AT support is disabled.
However, disabling AT support via the normal way (disable via its configuration setting in the Arduino IDE tools menu) does not make its binary code size any smaller which appears to be a bug in the ASR650x Arduino Core.
[Update]
AT command support is for LoRaWAN only. Enabling AT support has no effect for non-LoRaWAN applications (and no effect on binary size).
For LoRaWAN applications, enabling AT command support increases binary code size about 5 kB (which is 4% of total flash memory).
@bluejedi I mean you have to edit the library from Heltec. And I think anywhere you find it includes. If when the compile work I don’t know.
But why want you disable it? Spare code memory?
If have disabled it and when RX and TX can work for debug to something in the serial console.
I uses the capsulate version from Cubecell.
@hunter8801
Yes the memory could be bigger. But I think I can handle it at the for my project.
Do you mean that your suggestion may not work and you have not tested this?
If so, that would imply that you have no clue of the impact of what you suggest. There can be dependencies and just removing these includes could have severe side effects (unless you are sure they don’t, either because you know the code or have seen this documented).
Has anyone had problems with Heltec shipping on Aliexpress? I ordered a few weeks ago and I’ve seen multiple tracking numbers but each carrier has stated they are waiting for the parcel. Heltec wont say if they’ve shipped, just to wait a few weeks for a status update.
I got it quickly delivered in 12 days (ordered Dec 23rd) via AliExpress Standard Shipping (which has tracking supported).
@bluejedi no I only disabled it. But I never tested it to uncomment. Try and error that’s the game. But you didn’t answer my questions why would you like to disable it.
This forum is not a game. If you have something useful to contribute then that is welcome, if not then don’t respond.
See further above:
Sorry for the late feedback.
Yes, AT command will not influence the low power features.
We just hope via AT command to provide a convenient way to use LoRaWAN protocol or config some parameters. Among the users we had reached, have a high percentage can’t implement the LoRaWAN protocol through code, so we hope to use a simple way, such as “T + Join = 1”, "AT + SendHex = AABBCC ", then uses can send serial data to the gateway by LoRaWAN protocol. In other word, AT command is an option, users decides whether to use.