CubeCell Dev-Board HTCC-AB01 from Heltec - Downlink

I am a newbie and try to get downlink Data from TTN to my CubeCell Dev-Board HTCC-AB01 from Heltec. UpIoad works well and I see the uploaded data in TTN. I try to do it by using “Downlink” with dummy data in TTN and run on Cubecell https://github.com/HelTecAutomation/ASR650x-Arduino/tree/master/libraries/LoRa/examples/LoRaWAN/LoRaWan_downlinkdatahandle
I see the download Data in TTN Data console but on Serial monitor of the device I cannot see the received data printed out. Any idea. Thanks, Ruedi

1
2

#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 };
uint32_t devAddr =  ( uint32_t )0x007e6ae1;

/*LoraWan channelsmask, default channels 0-7*/ 
uint16_t userChannelsMask[6]={ 0x00FF,0x0000,0x0000,0x0000,0x0000,0x0000 };

/*LoraWan region, select in arduino IDE tools*/
LoRaMacRegion_t loraWanRegion = ACTIVE_REGION;

/*LoraWan Class, Class A and Class C are supported*/
DeviceClass_t  loraWanClass = LORAWAN_CLASS;

/*the application data transmission duty cycle.  value in [ms].*/
uint32_t appTxDutyCycle = 15000;

/*OTAA or ABP*/
bool overTheAirActivation = LORAWAN_NETMODE;

/*ADR enable*/
bool loraWanAdr = LORAWAN_ADR;

/* set LORAWAN_Net_Reserve ON, the node could save the network info to flash, when node reset not need to join again */
bool keepNet = LORAWAN_NET_RESERVE;

/* Indicates if the node is sending confirmed or unconfirmed messages */
bool isTxConfirmed = LORAWAN_UPLINKMODE;

/* Application port */
uint8_t appPort = 2;
/*!
* Number of trials to transmit the frame, if the LoRaMAC layer did not
* receive an acknowledgment. The MAC performs a datarate adaptation,
* according to the LoRaWAN Specification V1.0.2, chapter 18.4, according
* to the following table:
*
* Transmission nb | Data Rate
* ----------------|-----------
* 1 (first)       | DR
* 2               | DR
* 3               | max(DR-1,0)
* 4               | max(DR-1,0)
* 5               | max(DR-2,0)
* 6               | max(DR-2,0)
* 7               | max(DR-3,0)
* 8               | max(DR-3,0)
*
* Note, that if NbTrials is set to 1 or 2, the MAC will not decrease
* the datarate, in case the LoRaMAC layer did not receive an acknowledgment
*/
uint8_t confirmedNbTrials = 4;

/* Prepares the payload of the frame */
static void prepareTxFrame( uint8_t port )
{
	/*appData size is LORAWAN_APP_DATA_MAX_SIZE which is defined in "commissioning.h".
	*appDataSize max value is LORAWAN_APP_DATA_MAX_SIZE.
	*if enabled AT, don't modify LORAWAN_APP_DATA_MAX_SIZE, it may cause system hanging or failure.
	*if disabled AT, LORAWAN_APP_DATA_MAX_SIZE can be modified, the max value is reference to lorawan region and SF.
	*for example, if use REGION_CN470, 
	*the max value for different DR can be found in MaxPayloadOfDatarateCN470 refer to DataratesCN470 and BandwidthsCN470 in "RegionCN470.h".
	*/
    appDataSize = 4;
    appData[0] = 0x00;
    appData[1] = 0x01;
    appData[2] = 0x02;
    appData[3] = 0x03;
}

//downlink data handle function example
void downLinkDataHandle(McpsIndication_t *mcpsIndication)
{
  Serial.printf("+REV DATA:%s,RXSIZE %d,PORT %d\r\n",mcpsIndication->RxSlot?"RXWIN2":"RXWIN1",mcpsIndication->BufferSize,mcpsIndication->Port);
  Serial.print("+REV DATA:");
  for(uint8_t i=0;i<mcpsIndication->BufferSize;i++)
  {
    Serial.printf("%02X",mcpsIndication->Buffer[i]);
  }
  Serial.println();
  uint32_t color=mcpsIndication->Buffer[0]<<16|mcpsIndication->Buffer[1]<<8|mcpsIndication->Buffer[2];
#if(LoraWan_RGB==1)
  turnOnRGB(color,5000);
  turnOffRGB();
#endif
}

void setup() {
	boardInitMcu();
	Serial.begin(115200);
#if(AT_SUPPORT)
	enableAt();
#endif
	deviceState = DEVICE_STATE_INIT;
	LoRaWAN.ifskipjoin();
}

void loop()
{
	switch( deviceState )
	{
		case DEVICE_STATE_INIT:
		{
#if(LORAWAN_DEVEUI_AUTO)
			LoRaWAN.generateDeveuiByChipID();
#endif
#if(AT_SUPPORT)
			getDevParam();
#endif
			printDevParam();
			LoRaWAN.init(loraWanClass,loraWanRegion);
			deviceState = DEVICE_STATE_JOIN;
			break;
		}
		case DEVICE_STATE_JOIN:
		{
			LoRaWAN.join();
			break;
		}
		case DEVICE_STATE_SEND:
		{
			prepareTxFrame( appPort );
			LoRaWAN.send();
			deviceState = DEVICE_STATE_CYCLE;
			break;
		}
		case DEVICE_STATE_CYCLE:
		{
			// Schedule next packet transmission
			txDutyCycleTime = appTxDutyCycle + randr( 0, APP_TX_DUTYCYCLE_RND );
			LoRaWAN.cycle(txDutyCycleTime);
			deviceState = DEVICE_STATE_SLEEP;
			break;
		}
		case DEVICE_STATE_SLEEP:
		{
			LoRaWAN.sleep();
			break;
		}
		default:
		{
			deviceState = DEVICE_STATE_INIT;
			break;
		}
	}
}

Does the device send an uplink - with TTN you will ONLY see the downlink just after the uplink - assuming all works well between the gateway and TTN.

Yes, Uplink is working

But Downlink is not working. I only get “confirmed ulink sending …” in Serial Monitor

Is Downlink not possible with HTCC-AB01?

It should be - perhaps posting this issue on the Heltec forum would be good - it will be a couple more days for me to dig out my CubeCell to try it for you.

Thanks for the hint, I have already postet it there, but don’t have a answer yet received.

Aside: I very much dislike people posting the same thing in multiple places, even more so when not providing links to the duplicated posts. Just a waste of people’s time, I feel, unless the poster can guarantee to keep the multiple places synced, 24/7. Which, of course, never happens.

1 Like

Isuue is also posted at http://community.heltec.cn/t/cubecell-dev-board-htcc-ab01-from-heltec-downlink/2591

Sorry for that I was not aware of this. Thanks for the hint.
I am a newbi in LORA and thought that receive a download from TTN using a provider delivered example code must be a simple basic funcion, but nowehre I get a hint what the problem could be. So I thought it is a good idea to post it at TTN and Heltec.

Who do you consider to be the provider? Surely not TTN because TTN would never create sample code with confirmed uplinks. Please switch to unconfirmed uplinks as soon as possible.
When it comes to downlinks, there is no guarantee a downlink will be delivered to the node. There are multiple reasons it can fail. Please switch off the confirmed uplinks and try again. Try a couple of downlinks.
However keep in mind, for development you can use a bit more but regular nodes are limited to 10 downlinks (including acknowledgments for acknowledged uplinks) each day as per TTN fair access policy.

In this case, Heltec - the issue is with their example code and if I get a free moment, I’ll pull my CubeCell out the pile and take it for a spin to see if we are missing something obvious.

Ruedi has been trying for 7 days with only me “helping” so he’s still well karma plus at present.

That is your interpretation of provider, I am still wondering who @Ruedi_68 refers to in his message.

I refer to the sample code I have posted in my Topic as a link to the Gitub repository of Heltec and which I have pasted in addition in my topic as cleartext. So the sample code is from Heltec.

See Topic:
I try to do it by using “Downlink” with dummy data in TTN and run on Cubecell https://github.com/HelTecAutomation/ASR650x-Arduino/tree/master/libraries/LoRa/examples/LoRaWAN/LoRaWan_downlinkdatahandle

My settings:
ttn

Yesterdays test from Heltec shows that in general downlink from TTN with Heltec example script should work:

Sorry I haven’t got to trying mine yet but there are some useful ideas to check from Heltec, things I should of thought of earlier.

Do you have access to the gateway logs on the gateway itself?

What we are looking for is the downlink being received by the gateway from TTN and assuming it is arriving, is it in time for the RX2 window. If the network connection is too slow, the device will have stopped listening by the time it arrives to be transmitted.

Thanks for the reply. Unfortunately I donn’t have access to the gateway. But I also use another LORA Device with TTN ( https://github.com/RobPo/PaperiNode ) and whith this one download is working on same location.
2020-10-01 18_32_22-The Things Network Console

18:30:29.945 -> TX on freq 868500000 Hz at DR 5
18:30:30.045 -> Event : Tx Done
18:30:31.025 -> RX on freq 868500000 Hz at DR 5
18:30:31.058 -> Event : Rx Timeout
18:30:32.070 -> RX on freq 869525000 Hz at DR 0
18:30:32.271 -> Event : Rx Timeout
18:30:45.095 -> unconfirmed uplink sending …
18:30:45.095 -> TX on freq 868100000 Hz at DR 5
18:30:45.161 -> Event : Tx Done
18:30:46.171 -> RX on freq 868100000 Hz at DR 5
18:30:46.204 -> Event : Rx Timeout
18:30:47.186 -> RX on freq 869525000 Hz at DR 0
18:30:47.386 -> Event : Rx Timeout
18:31:00.936 -> unconfirmed uplink sending …
18:31:00.936 -> TX on freq 867700000 Hz at DR 5
18:31:01.030 -> Event : Tx Done
18:31:01.996 -> RX on freq 867700000 Hz at DR 5
18:31:02.030 -> Event : Rx Timeout
18:31:03.040 -> RX on freq 869525000 Hz at DR 0
18:31:03.242 -> Event : Rx Timeout
18:31:16.392 -> unconfirmed uplink sending …
18:31:16.392 -> TX on freq 867300000 Hz at DR 5
18:31:16.459 -> Event : Tx Done
18:31:17.435 -> RX on freq 867300000 Hz at DR 5
18:31:17.468 -> Event : Rx Timeout
18:31:18.515 -> RX on freq 869525000 Hz at DR 0
18:31:18.681 -> Event : Rx Timeout
18:31:31.918 -> unconfirmed uplink sending …
18:31:31.918 -> TX on freq 867100000 Hz at DR 5
18:31:31.984 -> Event : Tx Done
18:31:32.959 -> RX on freq 867100000 Hz at DR 5
18:31:32.993 -> Event : Rx Timeout
18:31:34.001 -> RX on freq 869525000 Hz at DR 0
18:31:34.201 -> Event : Rx Timeout
18:31:47.204 -> unconfirmed uplink sending …
18:31:47.238 -> TX on freq 868300000 Hz at DR 5
18:31:47.306 -> Event : Tx Done
18:31:48.282 -> RX on freq 868300000 Hz at DR 5
18:31:48.317 -> Event : Rx Timeout
18:31:49.336 -> RX on freq 869525000 Hz at DR 0
18:31:49.540 -> Event : Rx Timeout
18:32:03.164 -> unconfirmed uplink sending …
18:32:03.164 -> TX on freq 867700000 Hz at DR 5
18:32:03.233 -> Event : Tx Done
18:32:04.213 -> RX on freq 867700000 Hz at DR 5
18:32:04.247 -> Event : Rx Timeout
18:32:05.261 -> RX on freq 869525000 Hz at DR 0
18:32:05.462 -> Event : Rx Timeout
18:32:18.572 -> unconfirmed uplink sending …
18:32:18.572 -> TX on freq 867300000 Hz at DR 5
18:32:18.640 -> Event : Tx Done
18:32:19.654 -> RX on freq 867300000 Hz at DR 5
18:32:19.654 -> Event : Rx Timeout
18:32:20.692 -> RX on freq 869525000 Hz at DR 0
18:32:20.894 -> Event : Rx Timeout
18:32:33.829 -> unconfirmed uplink sending …
18:32:33.829 -> TX on freq 867100000 Hz at DR 5
18:32:33.897 -> Event : Tx Done
18:32:34.877 -> RX on freq 867100000 Hz at DR 5
18:32:34.910 -> Event : Rx Timeout
18:32:35.927 -> RX on freq 869525000 Hz at DR 0
18:32:36.130 -> Event : Rx Timeout
18:32:48.972 -> unconfirmed uplink sending …
18:32:48.972 -> TX on freq 868300000 Hz at DR 5
18:32:49.042 -> Event : Tx Done
18:32:50.030 -> RX on freq 868300000 Hz at DR 5
18:32:50.064 -> Event : Rx Timeout
18:32:51.074 -> RX on freq 869525000 Hz at DR 0
18:32:51.277 -> Event : Rx Timeout
18:33:04.004 -> unconfirmed uplink sending …
18:33:04.004 -> TX on freq 867900000 Hz at DR 5
18:33:04.071 -> Event : Tx Done
18:33:05.047 -> RX on freq 867900000 Hz at DR 5
18:33:05.080 -> Event : Rx Timeout
18:33:06.088 -> RX on freq 869525000 Hz at DR 0
18:33:06.323 -> Event : Rx Timeout

That’s not okay; TTN uses SF9 for RX2 in EU868, and for ABP devices you’ll need to configure that manually.

That said, as the device is using DR5/SF7 for the uplink, it’s very unlikely TTN would use RX2 for the downlink, so unrelated to your problems.

Is this log for the working device, or for the troublesome one?

Thanks for your reply, this log is from the troublesome one.