Missing data using AT+RECV command in RAW format

[Luca Bertoldo]

I’m using an XDOT module within a LoRaWAN Network.

After receiving a packet of 3 bytes from the network (as reported by the following lines of trace console):

[TRACE] Info: Status: 0 ACK: 0 Retries: 0 TxDR: 4 RxPort: 1 RxSize: 3 RSSI: -43 SNR: 70 Energy: 0 Margin: 0 Gateways: 0
[INFO] Packet RSSI: -43 dB SNR: 70 cB
[DEBUG] mDotEvent - RxDone
[DEBUG] RadioEvent – RxDone

If I get the data in Hexadecimal format (at+rxo=0) I can see the received data correctly.

If I get the data in Raw/Unprocessed format (at+rxo=1) I lost the data with zero value and the following bytes.

For example, if I downlink 3 byte in this sequence: 0x1A, 0x00, 0x2B
1. AT+RECV (Hexadecimal format) – I receive correctly 1A002B
2. AT+RXO=1 (set the raw mode)
3. AT+RECV (Raw format) – I receive only 1 byte with value 1A (second and third bytes are missing)

[Luca Bertoldo]

See the following additional example.
I sent the following byte sequence: 0x41, 0x00, 0x42

Following what I can see using AT command on console:

at+rxo=0

OK
at+recv
410042

OK
at+rxo=1

OK
at+recv
A

OK

[Jason Reiss]

We will take a look into this for next release.

In the meantime AT+SD provides a serial passthrough that can be used.

When in serial mode issue +++ with 1 second guard times to escape.

[Luca Bertoldo]

Ok, thanks.
In any case, at this time I can’t use the serial passthrough because I can’t identify where a frame starts and where it ends.
To work in this way I should introduce a frame structure at application level… that I would like to avoid in order to minimize the packets dimension.

Is there any other way to identify the limits of a frame in serial mode?

Other things: if I work with AT+RECV command, how can I detect a new frame RX event?
I mean… AT+RECV still reports the last frame received by the node but I’m not able to identify if it is already read or if it is a new one. Is there any way to identify new frame RX event?

[Jason Reiss]

AT+DLC will report the last received counter

AT Firmware source is available here for modifications
https://os.mbed.com/teams/MultiTech/code/Dot-AT-Firmware/

Or a custom firmware could be created using the library
https://os.mbed.com/teams/MultiTech/code/libxDot-mbed5/

[Luca Bertoldo]

I installed the last release fw:
MultiTech xDot
Firmware : 3.1.0-mbed161
Library : 3.1.0-mbed161
MTS-Lora : 3.1.0

The problem still be present. Did you take a look to this topic?

[Jason Reiss]

Strings containing NULL or other special characters may have issues being printed to the terminal. This is why the HEX output is available.

AT+SD will provide the raw data correctly.

[Luca Bertoldo]

I used a terminal like realterm so I can receive binary data… and I receive the packet only before the first 0 value.

As I wrote above, I can’t use the SD mode to get the rx packets.

Thanks,
Luca

[Author]

Posts