TX Packet Decoding on cubecell

Before I go off and try and reinvent the wheel or do my usual thing of making things more complicated as they are.

The setup I have is an M02 running Node Red on the Lan Side, On the LoRa side I have 3 AMG88XX Sensors on a cubecell with a filter to fire off triggers based on what now is a 18 X 8 matrix. Tis part of the project works perfectly with the each sensor after its been read put in to low power mode and when all sensors are read Vext is turned off to conserve power during the sleep cycles.

The next part of the project is to be able to adjust the settings on the cubecell via the Node Red interface, Currently i can set the trigger levels, and a few other settings but would like to be able to change the
devEui, appEui, appKey and possibly the userChannelsMask

These values are all in HEX, now unless i am mistaken the M02 sends its data in Base64. On the Cubecell side the payload is decoded in to a string.

Is there a way to make downLinkDataHandle return the actual hex rather than decoding it? I have not been able to find where its located in the libraries to take a look.
Or would I be better off just sticking with the base64 string then splitting it in to a byte array?

Has anyone set up a similar system?

Hello @vangalvin,

I am also using downlink data, it returns exactly what you send it. So it seems you send base64 data to it. Can you provide your handle function, so maybe we can insert some debug code there to see what’s really sent?

Hi @eiten I am still working on the downlink side. I found that unless i send a Base64 to the mqtt/tx topic it does not seem to get to the device. Change the data payload to base64 and it gets there every time.

On the receive side (lora device) the base64 is automaticaly decoded and made available by the downLinkDataHandle(McpsIndication_t *mcpsIndication)

allthought its in string format not hex but then that is not a huge issue to deal with.

I am however going to have to rethink the way I was thinking of setting the data as that would make the packet 62 bytes and anyting under DR3 shouold only be 51 bytes.So maybe i skip the userChannelsMask and leave that so it can be set seperatly.

I will upload the code as soon as I have it cleaned up a little so you can take a look and feel free to be critical and pick it apart :slight_smile:

OK, let’s see then. I use this on thethingsnetwork, and send the data as fields by mqtt and only encode it at thethingsnetwork… maybe a way for you?

As per usualy I have to be diferent than everyone else. lol…

This project needs to be self contained and will not have access to the net. Things would have made life so much easier and is how i bult the original system.

Hi, I sending {“confirmed”:false,“payload_raw”:“Af7///8=”,“port”:1} to app/devices/device/up - this data will appear as decoded binary data and is extracted as below

   if (mcpsIndication->BufferSize == 5 && mcpsIndication->Buffer[0] == 1) {
		int32_t offset =  (uint32_t) mcpsIndication->Buffer[1];
		offset |= (uint32_t) mcpsIndication->Buffer[2] << 8;
		offset |= (uint32_t) mcpsIndication->Buffer[3] << 16;
		offset |= (uint32_t) mcpsIndication->Buffer[4] << 24;

		Serial.printf("epOffset=%d offset=%d\n",epOffset,offset);
		epOffset += offset;


No base64 of whatever required at the recipient, just sending the proper format thats all

Thanks @weradus.
I ended up using memcpy() on the buffer and it seems to be working.
initially the data did not appear to be what was being sent then I discovered this was being caused by the way I had set up Node Red to send the base64.