From RevSpace
Jump to navigation Jump to search
Project CubeCell
Low-power LoRaWAN Board
Status In progress
Contact bertrik
Last Update 2022-03-27


This page is about the CubeCell board from, aka HTCC-AB01

the github page for the Arduino code

What I'd like to investigate:

  • Does it have an RTC? YES, it appears so
  • --Can we run the arduino-lmic library on this? NO, probably not in the short term--
  • --Can we compile the code with platformio? YES--
  • Use this board for my LoraBatBox
  • Video review by Andreas Spiess



  • based on an ASR605x (ARM cortex M0+ core) + SX1262 radio chip
  • low power, only microamps sleep current
  • battery connection
  • solar cell connection
  • pinout

According to this board has only 16 kB RAM, so things might get a bit tight. A basic LoRaWAN "hello world" example with the basicmac stack uses approximately 2336 bytes.


Example code

The CubeCell hardware works with (an export of) the basicmac device stack from Lacuna Space, just needs a pinmap definition, (see also

const lmic_pinmap lmic_pins = {
    .nss = RADIO_NSS,
    .rx = LMIC_UNUSED_PIN,
    .rst = RADIO_RESET,
    .busy = RADIO_BUSY,


Failure to initialize hardware

The SPI clock in the basic mac stack is configured by default to 10 MHz. Reducing this to 1 MHz makes it start much more reliably. This can be configured in hal.cpp , change:

 static const SPISettings settings(10E6, MSBFIRST, SPI_MODE0);


 static const SPISettings settings(1E6, MSBFIRST, SPI_MODE0);

Timing issues

The stack complains about event being out of order. These can be 'fixed' by configuring DCFG_rxrampup to some high number, e.g. 10000

Still, I'm seeing trouble to have joins succeed in the first try. When it does succeed, it's usually already up to SF11.

Constant OSTICKS_PER_SEC amounts to 62500, or 16 us per tick.

This post suggests the micros() function is off by a couple percent. Basically, the arduino micros() function appears to be broken for this platform.

Slow joins

Joining seems to fail until the node reaches SF=11. At that setting, the node can receives the gateway loud and clear (RSSI -36 dBm, SNR +9 dB or so) and the join accept is processed.


The plan is to use the interval between these two events for duty cycle bookkeeping. It appears the timing between these events is typically 30 ms higher than what is shown in the TTN console. Perhaps there is an effect of serial port debugging, slowing things down a bit?