Hi,
On RAK3172 module, I send the AT command: AT+SEND=1:12345678
On the IOT server I receive :
“lorawan.frmpayload”: “ed:be:3a:39”,
Next request is :
“lorawan.frmpayload”: “1e:72:86:fe”,
So on…
With a SX1276, I’m able to send 11 bytes and retreived exactly the same bytes again and again invariably .
DR=3 in both case.
Your firmeware limits the send command at 8 bytes. I can’t try 11 bytes.
What is wrong in my settings?
Thank you
Regards
A LoRaWAN frmpayload is still in encrypted form.
To see the actual data input to the node LoRaWAN stack, you need to look at the application payload produced after validation and decryption.
Hi Chris,
I don’t understand what you say.
If there is an encryption the RAK3172 make it. I don’t see any parameter like that.
It looks more like a wrong baud rate somewhere or a wrong frame length setting.
I run two systems in parallel and only the RAK3172 do that.
Thank you
LoRaWAN is by definition encrypted so you must look at the application payload not the frame payload
It sounds like you’re probably mixing up LoRaWAN components with raw LoRa expectations.
I believe you can operate the RAK3172 in a raw LoRa (p2p) mode, but your data platforms usage of LoRaWAN terminology then gets odd.
Chris,
I use AWS LoraWan.
The weird thing I have just noted, TTN find the payload but not AWS.
So AWS is not a Lorawan plateform?
Chris,
There is no application payload, only frame payload and when the SX1276 send data, I see data in the frame payload on AWS.
Then you’re not implementing LoRaWAN with your sx1276 setup, and you appear to be pulling intermediate debug data out of the AWS LoRaWAN setup rather than using the final output it would produce if fed with proper LoRaWAN packets as input.
You need to make a choice between actually using LoRaWAN (correctly, with the right keys or an OTAA session, a proper stack, etc) or else not using LoRaWAN and working out all of the details of whatever scheme you chose by yourself.
The mode you are using the RAK3172 in is a LoRaWAN mode. If you want to use the P2P mode instead to send non-LoRaWAN traffic, you need to look at the documentation and use the commands that apply to that mode instead, or else create your own firmware that runs on the MCU in the module and operates the radio however you like.
Hi Chris,
Sorry, but something is illogical…
I don’t want to use P2P.
OTAA is in the LoraWan mode only? No?
This is my settings for the SX1276 in AWS. It says the settings are OTAA:
OK you say the RAK module is in LoraWan mode. So, the main problem still same: AWS don’t see the data and TTN decodes both systems in same time.
So AWS is not good for LoraWan?
Thank you
It sounds like you need to spend some time studying LoRaWAN.
For one thing, a LoRaWAN node must only be registered with a single network at a given time.
If the node is registered with TTN, AWS shouldn’t have any registration records to even try to pay attention to it, and the reverse is also true.
And to repeat the initial point, for a LoRaWAN node, you must look at the application payload NOT the frame payload - your TTN example is showing an application payload, while for AWS you are erroneously looking at the frame payload which is only intermediate debug information, not a result.
If you don’t like how LoRaWAN works, then you’ll have to do something fully custom.
The RAK module lets you transmit either LoRaWAN traffic in the way LoRaWAN works, or more raw P2P traffic. You’ll have to chose between those options, and expect only the results that follow from such choice.
No , you didn’t understand.
When I make tests It’s on TTN after it’s on AWS not both networks in same time.
When I test on a TTN or on AWS I test both devices in same time .
TTN decodes both and AWS decode just one. Two behaves for one set of settings.
Just that is illogical!
Thank you
I will use something else.
Probably because you are looking in the wrong place, perhaps because you have not correctly entered the encryption keys which would allow it to decode the frame payload and produce the application packet you gave to the send command.
Hi @JeanDubuc ,
I haven’t tried the AWS LoRaWAN Network Server and I have no idea yet how its front-end console looks. If it works in TTN, then it should work in AWS as well if it is LoRaWAN compliant.
What @cstratton is saying is that you are still looking in the RAW frame payload (FRMPayload). This is still encrypted by the AppSkey and must be decoded by the network server side. This is not the application payload you are looking for yet. And even if you send the same application payload, the frame payload (FRMPayload) will have different values even if the actual payload is the same (in your case AT+SEND=1:12345678).
Here’s the section of LoRaWAN specification explaining that.
In my mind, you might be looking in the wrong data output from AWS? Or probably it is gated and the application payload can be seen somewhere else in the AWS console?
