New hardware from Heltec, Cubecell

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. :face_with_raised_eyebrow:

The diagram shows that:

  • Vin is directly connected (via fuse) to USB power. The board should therefore be powered either via USB or via Vin but NEVER both.

While trying to figure out how things are connected I noticed that:

  • Vin is connected via Schottky diode (D4) to pin VS (Vsolar).
    VS is the input pin for connecting a solar panel and serves as input for the battery charger chip.
    When both a solar panel and Vin or USB are connected, current may flow from Vin to the solar panel (which the panel normally ‘will not like’).
    To protect the solar panel from possible reverse current, it should be connected to pin VS with an external (Schottky) diode in series. That diode is not provided in the ‘Charging management system’ and is not integrated on the board.

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:

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.

1 Like

Thanks (I had already found it).

Some questions:

  1. Does this mean that enabling LoRaWAN AT support will not have any negative impact on power consumption in deep sleep (assuming nothing is connected to the serial port so it will not be awoken by GPIO interrupt, only by timer interrupt) when compared to when AT support is disabled in the IDE?

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.

  1. Why?
    [Update] Because this only has effect for LoRaWAN applications and apparently I had only tested this for non-LoRaWAN applications.

  2. For what situations/reasons would disabling LoRaWAN AT support be an advantage?

How is LoRaWAN AT support implemented:

  1. Is it integrated into the LoRaWAN (library) code and uploaded to the ASR650x with each sketch (as part of the binary code that is uploaded)?
  2. Or is AT support code permanently present on the ASR650x (maybe as part of the bootloader code) and is it not uploaded with every LoRaWAN sketch but only enabled or disabled?

You can disable it by uncomment it completely in the cor lib of heltec see:✓&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:

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

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

1 Like

I don’t think AT command enable/disable has no result for binary size.

Enable AT command

Disable AT command:

For the opinions in the Arduino’s tools menu, we can think of it as some optional compilation implemented through macro definitions (I don’t know if my English expressed accurately). The not selected code will not be compiled.

1 Like

The AT command is integrated into the LoRaWAN library. In other words, only LoRaWAN relevant examples can have AT command support.

If users need AT command to do a LoRa P2P communication, use this example:

And set AT+LORAWAN=0

1 Like


It seems that I had only checked code sizes for AT command support enabled and disabled for non-LoRaWAN examples. For non-LoRaWAN code, enabling/disabling AT command support has no effect on binary size.

But indeed, for LoRaWAN applications enabling and disabling AT command support does have impact on binary size. When enabled, binary code size increases with 5 kB.

I’m aware it is still under construction but the following information would be welcome (and is probably wanted by many):

  • General description with concepts and how the ASR-6501x-Arduino core works/how it is implemented.

  • The HTCC-AM01 module can be supplied with and without Arduino support installed. What development framework/toolchain is needed to develop for CubeCell (HTCC-AM01/ASR650x) when not using Arduino?

  • What of the Arduino standard framework is supported and what not and are there any differences (e.g. related to ASR650x/PSoC 4000 architecture)?

  • Are there any compatibility issues to expect when using external/3rd party Arduino libraries?

  • Where exactly are the settings (e.g. LoRaWAN keys) stored that can be changed via AT commands?

  • Are these settings maintained when new sketches are uploaded or are they destroyed when a new sketch is uploaded?

  • API documentation (with details) for at least ASR650x-Arduino specific:

    • Types / classes.
    • Global definitions, constants, variables.
    • Functions.
    • Classes and their methods.
    • Timers.
    • Events.
    • Standard event handlers (if available).
  • Details about (deep) sleep and how it is implemented. Is state (memory, program state, GPIO pin levels) preserved during sleep? What is (not) supported during sleep? Is there some kind of RTC memory where custom state can be stored to survive sleep cycles?

  • LoRaWAN

    • General description on how LoRaWAN support is implemented.
    • API documentation similar like above but specific for LoRaWAN.
    • How to properly set LoRaWAN keys and other LoRaWAN related settings in application code (without having to hack files in the ASR650x-Arduino core) when not using AT command support (when AT command support is disabled)?
    • It seems that LoRaWAN is not just a library but has also some integration in the kernel. Please explain.
    • Is it possible to disable the integrated LoRaMAC-node library and use any other LoRaWAN library (version) instead (for those who have a need for it)?
  • Security.

    • After every reset, LoRaWAN settings are output to the serial port which also includes all LoRaWAN keys. This may be nice during development but is very bad security practice. This is similar to writing down your pin code on your banking or credit card. How can this be disabled?
    • Similarly it should be possible to disable the functionality of requesting the current value of LoRaWAN keys (either requested via AT commands or from an API if there is an API that supports it). How can this be disabled?
  • Debugging support. An SWD interface (GPIO6, GPIO7) is available which is standard for ARM debugging. Is debugging supported for Arduino development? If not, what debugging is supported?

  • Is it possible to call any lower-level ASR650x / PSoC 4000 SDK functions from within an Arduino sketch?

  • Details about the bootloader. Is bootloader code available? Can the bootloader be updated or replaced (e.g. in case of issues)?

1 Like