CubeCell LoRa+reading PWM from sensor

aaz1n19 · July 21, 2020, 2:39pm

@descartes see my reply about printing the readings (sensor’s data), the same applies to pulse duration, it cuts off just after joining

descartes · July 21, 2020, 2:59pm

To use the supplied LoRaWAN library, Heltec require a registration code that is tied to the ESP32 chip id:

github.com

HelTecAutomation/ESP32_LoRaWAN/blob/7110cc9391d21110656e2639126eaf9ab9d897c3/examples/OTAA/OTAA.ino#L31


* https://heltec.org

* support@heltec.cn

*

*this project also release in GitHub:

*https://github.com/HelTecAutomation/ESP32_LoRaWAN

*/



#include <ESP32_LoRaWAN.h>

#include "Arduino.h"



/*license for Heltec ESP32 LoRaWan, quary your ChipID relevant license: http://resource.heltec.cn/search */

uint32_t  license[4] = {0xD5397DF0, 0x8573F814, 0x7A38C73D, 0x48E68607};



/* OTAA para*/

uint8_t DevEui[] = { 0x22, 0x32, 0x33, 0x00, 0x00, 0x88, 0x88, 0x02 };

uint8_t AppEui[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };

uint8_t AppKey[] = { 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x66, 0x01 };



/* ABP para*/

uint8_t NwkSKey[] = { 0x15, 0xb1, 0xd0, 0xef, 0xa4, 0x63, 0xdf, 0xbe, 0x3d, 0x11, 0x18, 0x1e, 0x1e, 0xc7, 0xda,0x85 };

uint8_t AppSKey[] = { 0xd7, 0x2c, 0x78, 0x75, 0x8c, 0xdc, 0xca, 0xbf, 0x55, 0xee, 0x4a, 0x77, 0x8d, 0x16, 0xef,0x67 };

which is obtained from here: https://resource.heltec.cn/search/

I failed to find where the code was referenced in the C source code, the modules worked OK that the client supplied so I wasn’t incentivised to read the assembly.

cslorabox · July 21, 2020, 3:03pm

The question concerns a PSoC based board, not an ESP32

https://heltec.org/project/htcc-ab01/

descartes · July 21, 2020, 3:11pm

Ah, a new chipset for the Arduino IDE - my bad.

weradis · July 21, 2020, 3:18pm

Try and see if the LoRaWAN.sleep() (replace with a delay(5000) is causing the issue, i.e. prevent the board from going to sleep, maybe the PWM settings are lost in the sleep function,

aaz1n19 · July 21, 2020, 3:33pm

@weradis It fails joining, (joining fail, try after 30s) and keeps doing this. I also looked at the execution order. Once it executes the join function it goes to sleep, then gets triggered and prints joined! after that it enters the loop of (send -> cycle -> sleep -> send …etc)

weradis · July 21, 2020, 3:53pm

Ok but does the data output remain stable or does it still turn to zero.?

aaz1n19 · July 21, 2020, 4:01pm

I kept printing data inside the loop() function as the prepareTxFrame() is not executed any more after the join fails. The data looks normal inside the loop() even though joining fails every 30s trial…

what do you think? is it something to do with the join() being successful and then PWM gets disable/used?

cslorabox · July 21, 2020, 4:04pm

even though joining fails every 30s trial…

Why do you keep re-joining? Joining is supposed to be extremely rare, really you should be saving session details across restarts of the firmware (LoRaWAN is not a protocol that is easy to use correctly).

If the device is not joined, there’s no point in preparing a TX frame since you can’t useful send application traffic without a joined session or ABP credentials instead.

weradis · July 21, 2020, 4:05pm

Yes We know that, we are trying to find where things get messed up … unless you know the solution

aaz1n19 · July 21, 2020, 4:07pm

@cslorabox I am not doing this on purpose, we are just trying to figure out where the PWM gets disabled and hence used delay() instead of sleep().

I am using the exact same code in the link below, except adding the PWM input bit:

github.com

HelTecAutomation/ASR650x-Arduino/blob/master/libraries/LoRa/examples/LoRaWAN/LoRaWan/LoRaWan.ino

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

/*
 * 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;
 */

/* OTAA para*/
uint8_t devEui[] = { 0x22, 0x32, 0x33, 0x00, 0x00, 0x88, 0x88, 0x02 };
uint8_t appEui[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
uint8_t appKey[] = { 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, 0x66, 0x01 };

/* ABP para*/
uint8_t nwkSKey[] = { 0x15, 0xb1, 0xd0, 0xef, 0xa4, 0x63, 0xdf, 0xbe, 0x3d, 0x11, 0x18, 0x1e, 0x1e, 0xc7, 0xda,0x85 };
uint8_t appSKey[] = { 0xd7, 0x2c, 0x78, 0x75, 0x8c, 0xdc, 0xca, 0xbf, 0x55, 0xee, 0x4a, 0x77, 0x8d, 0x16, 0xef,0x67 };

This file has been truncated. show original

weradis · July 21, 2020, 4:10pm

No the sleepmode() is messing things up, the join is failing because the Radio.IrqProcess( ) is not handled anymore. I think the PWM settings are lost, you could try to reinitialise after sleeping …

aaz1n19 · July 21, 2020, 5:38pm

@weradis I do re-initialise PWM in the prepareTxFrame() as other examples provided by the Library do. They initialise the sensor and read its data then append it to the appData buffer. Many examples use the same pattern, but none is using PWM.

weradis · July 21, 2020, 5:43pm

Let me do some more research, board itself looks very promising, small and cheap where did you procure and how long took it to deliver?

aaz1n19 · July 21, 2020, 5:53pm

I got it from Amazon for next day delivery as I wanted to get this done asap. Yes, it is a very promising board.

I was working on esp32 heltec board for the same application but its power consumptiion was high ( few mA). This board is drawing (20uA!) in sleep mode + can plug solar panel and battery without needing drivers, cheaper etc. Very powerful.

I apologise for bombarding you with many questions and thank you for your patience I really appreciate your help.

weradis · July 23, 2020, 7:43am

i ordered one in a local shop, but after ordering I noticed they are on holiday and returning next week - btw i sent send you a pm with some more ideas

bluejedi · July 23, 2020, 10:44am

New? CubeCell and ASR650x are discussed on the forum for 9+ months already.
For more information see: Heltec CubeCell - part 2

CubeCell (in topic title) indeed is not ESP32 based.

Not really (see above link). Heltec’s CubeCell product range uses the ASR Microelectronics ASR6501 and ASR6502 SiP’s (Cypress ARM Cortex M0 + SX1262) but the ASR’s have no Arduino support.

It is Heltec who has added the Arduino support for their CubeCell products. Development with the Arduino framework is supported for both the Arduino IDE as well as PlatformIO.

LoRaWAN support is based on Semtech’s LoRaMac-node (as this already provided SX1262 support).

bluejedi · July 23, 2020, 10:55am

When asking for help with a board you should at least provide information about your hardware.
While the topic title mentions CubeCell there is no mentioning what CubeCell board/harware you are using.

CubeCell is a product family consisting of different hardware products, not one single product.
See Heltec CubeCell - part 2

descartes · July 23, 2020, 11:02am

Yeah, like I have all the time in the world to keep tabs on ALL of the vendors offerings, cut us some slack.

And this is a new chipset for the IDE - Heltec added it so it appears in the IDE, which surely makes it a new chipset for the IDE - again, feel free to slice & dice my words.

bluejedi · July 23, 2020, 3:25pm

To save you time, the Heltec CubeCell start topic (link provided above) will provide you with a quick overview.