CubeCell: Difference between revisions

From RevSpace
Jump to navigation Jump to search
No edit summary
 
(17 intermediate revisions by the same user not shown)
Line 14: Line 14:


What I'd like to investigate:
What I'd like to investigate:
* Does it have an RTC?
* Does it have an RTC? YES, it appears so
* Can we run the arduino-lmic library on this? This should be possible because arduino-lmic is also targeted to a sx12x2 core.
* --Can we run the arduino-lmic library on this? NO, probably not in the short term--
* Can we compile the code with platformio? YES
* --Can we compile the code with platformio? YES--
  https://github.com/HelTecAutomation/ASR650x-Arduino/issues/11
  https://github.com/platformio/platformio-core/issues/3078
* Use this board for my [[LoraBatBox]]
* Use this board for my [[LoraBatBox]]
* [https://www.youtube.com/watch?v=lobNwqHLrag Video review by Andreas Spiess]
* [https://www.youtube.com/watch?v=lobNwqHLrag Video review by Andreas Spiess]
Line 24: Line 22:
== Hardware ==
== Hardware ==
Features:
Features:
* based on an ASR605x (ARM cortex M0+ core) + SX1262(?) radio chip
* based on an ASR605x (ARM cortex M0+ core) + SX1262 radio chip
* low power, only microamps sleep current
* low power, only microamps sleep current
* battery connection
* battery connection
* solar cell connection
* solar cell connection
* [https://resource.heltec.cn/download/CubeCell/HTCC-AB01/HTCC-AB01_PinoutDiagram.pdf pinout]
* [https://resource.heltec.cn/download/CubeCell/HTCC-AB01/HTCC-AB01_PinoutDiagram.pdf pinout]
According to https://heltec.org/project/htcc-ab01/ 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.


== Software ==
== Software ==
Example code:
* [https://github.com/HelTecAutomation/platform-asrmicro650x/tree/develop/examples/arduino-lorawan LoraWan example code]
* A basic platformio demo project is available at https://github.com/bertrik/cubecelldemo


What I'd like to do for a LoraBatBox:
=== Example code ===
* register with OTAA (and remember the session keys)
* A basic working LoRaWAN platformio demo project is available at https://github.com/bertrik/cubecelldemo
* wake up when there is movement sensed by the PIR
* [https://github.com/HelTecAutomation/platform-asrmicro650x/blob/develop/examples/LoRa/LoRaWAN/LoRaWAN/src/LoRaWan.ino LoraWan example code] from Heltec (not recommended)
* keep track of times when movement was detected (in wall-clock time)
 
* send activity (say) once per hour to TTN
The CubeCell hardware works with (an export of) the [https://github.com/LacunaSpace/basicmac basicmac] device stack from Lacuna Space, just needs a pinmap definition,
(see also https://www.thethingsnetwork.org/forum/t/heltec-cubecell-part-2/37225/72):
<pre>
const lmic_pinmap lmic_pins = {
    .nss = RADIO_NSS,
    .tx = LMIC_CONTROLLED_BY_DIO2,
    .rx = LMIC_UNUSED_PIN,
    .rst = RADIO_RESET,
    .dio = {LMIC_UNUSED_PIN, RADIO_DIO_1, LMIC_UNUSED_PIN},
    .busy = RADIO_BUSY,
    .tcxo = LMIC_CONTROLLED_BY_DIO3,
};
</pre>
 
=== Troubleshooting ===
==== 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);
into
  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.
 
[http://community.heltec.cn/t/cubecell-micros-function/985 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.
 
==== TX_START / TX_DONE timing ====
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?

Latest revision as of 19:55, 27 March 2022

Project CubeCell
Cubecell.png
Low-power LoRaWAN Board
Status In progress
Contact bertrik
Last Update 2022-03-27

Intro

This page is about the CubeCell board from heltec.org, 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

Hardware

Features:

  • 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 https://heltec.org/project/htcc-ab01/ 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.

Software

Example code

The CubeCell hardware works with (an export of) the basicmac device stack from Lacuna Space, just needs a pinmap definition, (see also https://www.thethingsnetwork.org/forum/t/heltec-cubecell-part-2/37225/72):

const lmic_pinmap lmic_pins = {
    .nss = RADIO_NSS,
    .tx = LMIC_CONTROLLED_BY_DIO2,
    .rx = LMIC_UNUSED_PIN,
    .rst = RADIO_RESET,
    .dio = {LMIC_UNUSED_PIN, RADIO_DIO_1, LMIC_UNUSED_PIN},
    .busy = RADIO_BUSY,
    .tcxo = LMIC_CONTROLLED_BY_DIO3,
};

Troubleshooting

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);

into

 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.

TX_START / TX_DONE timing

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?