Heltec CubeCell support

[bertrik]

Would it be possible to support this particular board with the mcci arduino-lmic stack? https://heltec.org/project/htcc-ab01/

It consist of a ARM Cortex M0+ microcontroller plus a Semtech SX LoRa radio chip, combined with low-power circuitry to allow battery charging from a solar cell. https://github.com/HelTecAutomation/ASR650x-Arduino

The Arduino code comes with a LoRa example, but I am much more confident in the mcci-catena arduino-lmic stack. The lower layer of the heltec board appears to be a SPI+GPIO based interface. https://github.com/HelTecAutomation/ASR650x-Arduino/blob/master/cores/asr650x/board/src/asr_board.c

As far as I can tell it looks possible, I might try to hack up some code this weekend, simply starting with reading an ID register, perhaps get a good idea of the pin connections, etc.

[terrillmoore]

Certainly an attractive price. 128k of flash and 16k of SRAM is enough to do most things. Too bad no built-in USB support -- external USB chips have their drawbacks.

Here's the big deal. The docs say it has an SX1262. That's not insurmountable, but the SX1262 is completely different (from a software point of view) than the 1272/1276 currently supported by LMIC.

Radio.c only has a few entry points, so abstracting it into "radio.c" and "radio_sx127x.c", and "radio_sx1262.c" is not really that hard; the harder part is writing the content. I've recently documented the "APIs" so that it's clear what the parameters are for each radio(OP) call. But it might be more than a weekend of work, I'm afraid.

[cstratton]

This might be a cheap way to play with an SX126x...

In terms of connectivity, it's no one's fault but the manufacturer's for not putting it upfront in their promotional materials, but detail pages shows there's actually a CP2102 USB-UART on the underside of the board. If or how well that is supported in a bootloader is certainly a valid question for arduino-ish usage, it's entirely possible to place the right hardware but not end up with a working solution. As on pretty much any ARM Cortex trail-blazing efforts would probably want to use SWD for programming and debugging.

[terrillmoore]

This might be a cheap way to play with an SX126x...

Definitely -- was thinking the same thing.

BTW I saw the CP2102 -- near to my heart as I worked on the original version of that device -- I just tend to prefer in-the-SOC USB because it's more flexible.

[Heltec-Aaron-Lee]

Hi there

I didn't look into the LMIC library very deeply, but I have a confuse: Why not use LoRaWAN protocol directly? LoRaWAN 1.0.2 and 1.0.3 provided many new features than LMIC.

CubeCell has fully LoRaWAN Class A and Class C protocol support.

[lnlp]

The CubeCell products are based on the (ASR Microelectronics) ASR650x series SoC. The ASR6501 combines an ARM Cortex-M0+ together with SX1262 on a single SoC. Based on a response from Heltec on their forum it appears that they use (a port of?) LoRaMac-node in their Arduino core and there appears to have been some confusion between the terms 'LoRaWAN' and 'LoRaMac-node'.

With "Why not use LoRaWAN protocol directly?" I suspect that @Heltec-Aaron-Lee actually means "Why not use the LoRaMac-node functionality already implemented in our ASR650x Arduino Core?".

[terrillmoore]

@lnlp thanks! @Heltec-Aaron-Lee, this is a cross-platform open-source project. The reason to use the Heltec platform for hardware would be to test our software with the ASR650x and 1262.

We already support a range of platforms from AVR to RISC-V. It's good not to have a monoculture. The LMIC passes class A testing already for LoRaWAN 1.02 and 1.03, so it's functionally equivalent. Anyway, others are welcome to do what they like! Who knows, maybe there are people who like the LMIC (or have apps based on LMIC) that would like to use your hardware!

Best regards, --Terry

[Heltec-Aaron-Lee]

@lnlp Thanks for your accurate expression, that's what I want to say! My poor English allow me read some technical documents, but I must write with Grammarly and Google Translate 😄.

In the beginning, when I began to make a library for our ESP32 + LoRa products, I had tried with the LMIC Arduino library, this library is friendly to read, fix and config, but I found a problem: LMIC use system tick to be the timeline, this timmer can't run while the system in deep sleep. In my opinion, the biggest advantage of LoRa is low power and long-range, deep sleep is an important feature for many LoRa applications.

About Semtech's LoRaWAN-Node project, I think it provides a very clever approach: use an RTC linked list to handle system events. this RTC timer does not generate a tick timer to check the timer linked list regularly, but directly timings based on the linked list header! Compared with the tick timer method, this RTC method works more efficiently. When the timer event increased in the linked list, the time spent on refreshing the timer will not increase, because there is no need to traverse the entire list.

So, it allows users to set hardware in a deep sleep mode to save energy, and wake up via RTC timmer, GPIO, UART, etc.

But the disadvantage is the LoRaWAN-Node is the example code is not very friendly to read and difficult to implement.

[Heltec-Aaron-Lee]

@terrillmoore You did a great job and provide perfect documents!!! Awesome! 👍👍 👍

[terrillmoore]

@Heltec-Aaron-Lee 哪里·，太客气了！

Clock and sleep: this part of the LMIC is really quite hard to understand at first; the LMIC's big remaining difficulty is that it doesn't have explicit finite-state machines for lmic.c, just chains of deferred function calls. It works, but it's hard to understand and change. But we finally figured out that the timing loop in the LMIC doesn't need anything special other than accurate real-time clock values representing the passage of time.

We solved that problem in MCCI's BSP and in our "catena-arduino-platform" -- we get very good battery life. You just have to advance the value of millis() after you wake up, so that the Arduino's idea of time is in line with the passage of time. In my opinion, the root cause is the primitive implementation of timekeeping in the Arduino framework, at least in the ARM variants.

However, I now understand the code better, and we can do the same thing in the LMIC w/o updating the BSP, by simply storing a "sleep compensation" -- your sleep routine just would tell the LMIC "time has changed by this much"; the LMIC would adjust the offset it adds to micros() and millis(), and things will work fine.

I'll be happy to consider a formal API to do this, as not everybody wants to maintain a BSP! (MCCI has to, because we build systems...)