No, that should work, let’s have a look the LoRaWAN protocol document:
Refer to my picture, the LoRaWAN protocol set the AU915 upstream channel frequency:
Total 64 channels, 915.2MHz begin, incrementing linearly by 200KHz, and 927.8MHz end.
Then look back to our code:
in the channelsMaskTemp[0], 0x00FF means use the first 0~7 channels, they are 915.2MHz, 915.4MHz, 915.6MHz … 916.6MHz. When you set the value to 0xFF00, it means the upload channels changed to 8~15, they are 916.8MHz, 917.0MHz … 918.2MHz.
Now, I think you need to confirm your gateway’s listening channels and listening frequency. Make sure they match the 8~15 channels.
I just received this board, looks very promising, but I have a few doubts:
How mature is the LoRaWAN stack?
Can I run the mcci-catena arduino-lmic stack on it? I doubt it can because that seems to be written (at the moment) for sx1272. Also this board seems to have rather limited RAM (only 16 kB).
Can I build it with platformio instead of Arduino IDE? I think the Arduino IDE is awful, you need to select a lot of options manually in the menu, there is an endless list of devices that you need to scroll through. And if you switch to another Arduino project, you have to re-select all of the settings. With platformio, this is all much easier, you can specify the libraries tool chain in a text file and easily switch between targets. It is even possible to build the Arduino software on the command line, automatically upon git push on a service like travis-ci.
Why would you post such a question here after you asked the very same thing on the issues page of that repo yesterday and got a negative answer from the maintainer?
Please don’t duplicate issues all over the web, especially with no acknowledgement that they’ve been asked by you before - and already answered.
Also this board seems to have rather limited RAM (only 16 kB).
That is hardly an issue. It is, for example 8 times the memory present on an Arduino Uno. The 2K on an Uno is marginal. But most of the chips people are using are in the 10-20K range, those 16K are plenty.
As explained on github, the issue is the need to adapt to the different LoRa chip having (all though not mentioned there) actually a rather different interface to software.
Oops, seems I hit a nerve there, sorry, just expressing some doubts after just having received this board and investigating its possibilities.
Good to realise that 16 kB isn’t that small compared to other targets.
Arduino-lmic stack support isn’t a question with closure or a fixed answer yet, that I should shut up about (IMO). At least for me it’s clear that it currently does not work, but it might work in the future with some help.
I think that you try to say something different than what you have written.
Do you mean to say “LMIC library does not support all current LoRaWAN features”?
Questions:
If I understand correctly from the Heltec forum the LoRaWAN library used for the CubeCell is based on LoRaMac-node which also supports Semtech SX126x LoRa chips (integrated on ASR6501 used on the CubeCell). Is that correct?
Has this been implemented as a true Arduino library (that can be easily updated) or is it tightly integrated into Heltec’s ASR650x Arduino core?
If library, is the implementation truly open source?
I have looked at the current CubeCell and ASR6501 documentation, information on GitHub (links provided in this thread) and Andreas Spiess’ CubeCell HTCC-AB01 video.
Below is a summary of my analysis:
[Updated]
ASR6501 is a SIP manufactured by ASR Microelectonics.
It combines a Cypress PSoC 4000 ARM Cortex-M0+ 32 bits 48MHz MCU with 16kB SRAM and 128kB flash together with a Semtech SX1262 LoRa tranceiver in a single package. SIP stands for System In Package which is similar to a SoC.
Heltec CubeCell is a product range based on the ASR650x series SoC.
Heltec CubeCell HTCC-AM01 is a module based on the ASR6501 SoC.
The module can be used both as a separate LoRaWAN module with UART interface, and as a standalone module where custom Arduino sketches can be uploaded to.
Heltec CubeCell HTCC-AB01 is a development board based on the HTCC-AM01 module.
Programming the Cubecell module/board is done via UART Rx/Tx using Heltec tools. The board has an integrated USB to Serial adapter which can be used for automatic uploading of firmware and for serial monitoring.
Heltec provides the ASR6501x Arduino Core for development with the Arduino framework. This currently is supported for the Arduino IDE only. Support for PlatformIO is under development and is expected to be available relatively soon.
According to the HTCC-AB01 circuit diagram GPIO6 and GPIO7 (used to control Vext and battery voltage measurement) also double as SWD and SWC (serial wire interface) which are commonly used on ARM for programming and debugging. Documentation for the serial wire interface is currently missing.
LoRaWAN support appears to be based on LoRaMac-node v4.4.1.
LoRaWAN support is integrated as part of the kernel. It is not implemented as a library that can be easily updated or replaced.
Support is included for some sensors, but like LoRaWAN this appears to be integrated in the kernel instead of as standard Arduino libraries that can be easily updated or replaced. I have yet to verify this.
When the module is used with an external micrcontroller, serial AT commands are used to communicate with the module.
AT commands are also supported when using the module standalone (which will probably be the most common) with custom sketches which is a nice feature. The AT commands can then be used to e.g. set LoRaWAN keys, select between OTAA and ABP, enable ADR, restart (reset) the module and more. These settings do not require changes in program code and are stored in flash. AT support is optional and can be enabled and disabled. When disabled, keys and settings will have to be provided in the sketch.
When AT support is not enabled (e.g. to save power during sleep) the LoRaWAN keys will have to be provided in code. Not in the sketch but in a file that is part of the Arduino Core source code which is poor design that should be fixed.
Some users have already found a solution for this (I will add a link to it later).
Observation: For the HTCC-AB01 board GPIO7 is used for button USR1, while recommended hardware designs for the HTCC-AM01 module use GPIO0 for button USR1.
Why this inconsistency?
The tools directory contains files for installing the tool chain. Files get.exe and get.py.
These are for downloading the ARM toolchain and CubeCell related tools.
What I do not like:
Both ARM tool chain and CubeCell tools are downloadedfrom an insecure unknown IP address. Not using a verifiable known DNS URL and using insecure http transport (not https/TLS).
ARM tool chain is not downloaded directly from ARM’s download site (and is not the most recent version).
Hi @bluejedi, your feed back makes us become better and better. We will try to fix all the things you don’t like
About the LMIC and LoRaWAN-Node, here is my understanding:
The libraries and examples of CubeCell, that’s open-source, in this path. But we do want to open the bootloader source code of CubeCell currently. With respect, fully open-source really goes hard in China.
I noticed that the asr650x kernel lorawan readme.md is not up to date. It is from LoRaMac-node version v4.3.2 while SX126x radio support was only added in LoRaMac-Node v4.4.1.
This gives the impression that the ASR650x-Arduino repository is inconsistent and/or incomplete.
As far as your product goes overall, the apparent lack of SWD signals would make many professional users immediately reject it as an option, as this is the industry standard for working with ARM Cortex-M parts.
