Heltec CubeCell - part 1

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
image

Disable AT command:
image

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

Thanks.

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

Thank you for your good ideas!

After the Spring Festival holiday, we will gradually improve the document details

1 Like

Here is a sketch, mix of examples using CubeCell board.
Send data and sleep 20 Sec.
I accept suggestions.

#include "LoRaWan_APP.h"
#include "Arduino.h"


#define timetosleep 1000
#define timetowake 20000
static TimerEvent_t sleep;
static TimerEvent_t wakeup;
uint8_t lowpower=1;

/*
 * set LoraWan_RGB to Active,the RGB active in loraWan
 * RGB red means sending;
 * RGB purple means joined done;
 * RGB blue means RxWindow1;
 * RGB yellow means RxWindow2;
 * RGB green means received done;
 */

/*LoraWan Class*/
DeviceClass_t  CLASS=LORAWAN_CLASS;
/*OTAA or ABP*/
bool OVER_THE_AIR_ACTIVATION = LORAWAN_NETMODE;
/*ADR enable*/
bool LORAWAN_ADR_ON = LORAWAN_ADR;
/* set LORAWAN_Net_Reserve ON, the node could save the network info to flash, when node reset not need to join again */
bool KeepNet = LORAWAN_Net_Reserve;
/*LoraWan REGION*/
LoRaMacRegion_t REGION = ACTIVE_REGION;

/* Indicates if the node is sending confirmed or unconfirmed messages */
bool IsTxConfirmed = false;
/*!
* Number of trials to transmit the frame, if the LoRaMAC layer did not
* receive an acknowledgment. The MAC performs a datarate adaptation,
* according to the LoRaWAN Specification V1.0.2, chapter 18.4, according
* to the following table:
*
* Transmission nb | Data Rate
* ----------------|-----------
* 1 (first)       | DR
* 2               | DR
* 3               | max(DR-1,0)
* 4               | max(DR-1,0)
* 5               | max(DR-2,0)
* 6               | max(DR-2,0)
* 7               | max(DR-3,0)
* 8               | max(DR-3,0)
*
* Note, that if NbTrials is set to 1 or 2, the MAC will not decrease
* the datarate, in case the LoRaMAC layer did not receive an acknowledgment
*/
uint8_t ConfirmedNbTrials = 1;

/* Application port */
uint8_t AppPort = 2;

/*the application data transmission duty cycle.  value in [ms].*/
uint32_t APP_TX_DUTYCYCLE = 15000;

/* Prepares the payload of the frame */
static void PrepareTxFrame( uint8_t port )
{
    AppDataSize = 4;//AppDataSize max value is 64
    AppData[0] = 0x00;
    AppData[1] = 0x02;
    AppData[2] = 0x01;
    AppData[3] = 0x03;
}


void setup() {
    BoardInitMcu();
    Serial.begin(115200);
    #if(AT_SUPPORT)
    Enable_AT();
    #endif
    DeviceState = DEVICE_STATE_INIT;
    LoRaWAN.Ifskipjoin();
    Serial.println( "[stup] INIT");
    #if(AT_SUPPORT)
      getDevParam();
    #endif
    Serial.println ("");
    Serial.println("[pram] ***********************************");
    printDevParam();
    Serial.println("[pram] ***********************************");
    Serial.println ("");
    Serial.printf("[stup] LoRaWan Class%X  start! \r\n",CLASS+10);   
    LoRaWAN.Init(CLASS,REGION);
    Serial.println( "[stup] JOIN");
    LoRaWAN.Join();
    delay(1000);   

    TimerInit( &sleep, OnSleep );
    TimerInit( &wakeup, OnWakeup );
    OnSleep();
}

void loop()
{
  if(lowpower)
  {
  //note that LowPower_Handler() run six times the mcu into lowpower mode;
  LowPower_Handler();
  }					
}

void OnSleep()
{
  Serial.printf("[lowp] lowpower mode  %d ms\r\n",timetowake);
  Serial.println("---------------------------zzzzzzzz----------------------------");
  lowpower=1;
  //timetosleep ms later wake up;
  TimerSetValue( &wakeup, timetowake );
  TimerStart( &wakeup );
}
void OnWakeup()
{
  Serial.printf("[wkup] wake up, %d ms later into lowpower mode.\r\n",timetosleep);
  uint32_t currentTime=TimerGetCurrentTime()/1000;
  Serial.printf("[time] upTime: %d sec. \r\n",currentTime);   
  lowpower=0;
  //timetosleep ms later into lowpower mode;
  Serial.print( "[ttn ] ");//sending
  PrepareTxFrame( AppPort );
  LoRaWAN.Send();
  delay(1000); 
      
    /*
      Serial.println( "CYCLE");
      // Schedule next packet transmission
      TxDutyCycleTime = APP_TX_DUTYCYCLE + randr( 0, APP_TX_DUTYCYCLE_RND );
      LoRaWAN.Cycle(TxDutyCycleTime);
    */  
    
  Serial.println("[ttn ] SEND");
  LoRaWAN.Sleep();
  
  TimerSetValue( &sleep, timetosleep );
  TimerStart( &sleep );
}

I’m not sure for what reason you are posting this code here, examples are already included with the ASR650x Arduino Core.

At first look your code looks just like the standard LoRaWAN example.

Your ‘I accept suggestions’ does not sound very inviting and makes little sense.

If you have any specific questions then you can ask them, but don’t just post code without any clear reason.

Hi bluejedi.
This example is a mix of LowPower_WakeUpByTimer and the LoRaWan, sending data to TTN.

There are to a counter of millis betwen sleeps, using TimerGetCurrentTime().

I post here because I used with TTN, and could help somebody.

I’m not a good programmer, the sketch works, but probably you could propose some changes.

Regards.

Anybody trying to use a Cubecell with AU915 and TTN - have a look here for a solution to frequency issues

Many thanks to Bruce who found the solution

regards
Paul

1 Like

FYI: Topic title was updated.

Hi,
May I kindly ask regarding CubeCell module (meaning CubeCell chip, not developers board) - what is input voltage tolerance, Is it ok to powered it by 3,6V - LS14500STD 3,6V 2450mAh?? Or should I use regulator to convert it to 3.3V?
Ciao
Lukas

According to Heltec’s specifications max power supply voltage (VDD) is 3.5V.

See Tech Specs tab on the HTCC-AM01 product page.

An alternative is put a low forward voltage Schottky diode (e.g. 1N5817) in series with the (plus of) the battery. This will cause a voltage drop of around 0.3V to 0.5V and also provides reverse polarity protection.

Hi,
may I kindly ask a few questions. I tested your sketch but it really was not working based on my expectations. Using ABP I was able to send data. Using OTAA I always get response “unable to join” - I saw requests coming but no success.

Is it also possible to share sketch with download handling? Like ability to receive the response and parse data and apply it - like change wakeup time, or handle GPIO (low/high), or any other operation?

I would really appreciate any kind of support.
Maybe I am doing something totally wrong, but not sure
Ciao
Lukas

The standard LoRaWAN example already automatically enters deep sleep between upload cycles and automatically wakes up by timer.

I did a small test with the standard LoRaWAN.ino example.

When powered by LiPo battery via the battery connector the CubeCell board uses only 8.5 uA during deep sleep! :smiley: :+1:

When externally powered directly on the 3.3V pin, either by LiFePO4 (3.2V nominal) or by two Alkaline batteries (2 x 1.5V = 3.0V nominal) the CubeCell board uses only 3 to 3.5 uA in deep sleep.

2 Likes

Powering the CubeCell HTCC-AB01 board with batteries

Important: It is easy to connect batteries incorrectly and reverse their polarity (50% probability) which can permanently damage the board. I’m not sure if there is reverse polarity protection when using the battery connector (often not) but there definitely is not when directly powering the Vin or 3.3V pins. Also take care that AA, AAA, 18650 model batteries can accidentally be inserted in reverse when using a battery holder.

Powering with a Li-ion or LiPo battery:

Li-ion and LiPo batteries must be connected via the battery connector.
The battery will be automatically charged when a (powered) USB cable is connected or when a solar panel is connected.

Important: To prevent damaging the board, first check the polarity of the battery cable before connecting the battery to the board. It is not uncommon that polarity (plus and minus) of separately bought cables is reversed to that of the board - which can permanently damage it.
Some of these batteries have built-in protection but I’m not aware if that will also protect the board from damage if the battery is connected in reverse.

Powering with a LiFePO4 battery:

Connect the plus directly to the 3.3V pin and do not use the battery connector.
The battery connector only supports Li-ion and LiPo batteries. LiFePO4 battery have a lower output voltage and have different charging requirements. When using a LiFePO4 battery, it cannot be charged via the USB port.

Important: The board does not provide over-discharge protection for the battery. When using a battery holder it is possible to insert the battery reversed which can damage the board. Adding a reverse polarity protection with a MOSFET will protect against this.

Powering with regular Alkine batteries:

Note that directly powering the 3.3V pin with two regular Alkaline batteries is less suitable because the batteries provide only 3.0V nominal output which steadily decreases to below 2.0V during discharge, so it will not be possible to use their full capacity (maybe only half of it).

In case use of Alkaline batteries is preferred (e.g. because they are cheap and readily available) it will be better to use three Alkaline cells in series. In this case the plus must be connected via a Schottky diode in series to the Vin pin. Use a Schottky diode with low forward voltage (e.g. 1N5817).

Important: The Schottky series diode is required to protect the batteries. The diode prevents the batteries from being powered with Vin or Vusb (5V). This protection is important but is not provided on the board. The diode also provides reverse polarity protection.


Connecting a solar panel

The board can be connected to a 5V or 6V solar panel. The plus of solar panel must be connected via a Schottky diode in series to the VS pin. Use a Schottky diode with low forward voltage (e.g. 1N5817). The solar board will be used for charging the Li-ion or LiPo battery.

Important: The Schottky series diode is required to protect the solar panel. The diode prevents the solar panel from being powered with Vin or USB (5V). This protection is important but is not provided on the board.

1 Like