DRF1268 module - communication problem

[kylix34]

Hello!

I have a Dorji DRF1268 module but somehow, Arduino doesn't "discover" it. I keep getting these 2 error codes: -20 and -707

[jgromes]

Could you please post the Serial monitor output with debug and verbose enabled?

Also, what is your Arduino IDE and RadioLib version?

[kylix34]

I downloades the RadioLib library yesterday, so it must be the latest version. I'm using Arduino IDE 1.8.10.I'll post the serial output after work 👍🏻

Inviato da Yahoo Mail su Android

Il lun, 25 nov, 2019 alle 9:22, Jan Gromešnotifications@github.com ha scritto:
Could you please post the Serial monitor output with debug and verbose enabled?

Also, what is your Arduino IDE and RadioLib version?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[kylix34]

Here you are: `Initializing ... Wait for BUSY ... CMD 80
DATW 0 A2

Wait for BUSY ... CMD 96
DATW 1 A2

Wait for BUSY ... CMD 8F
DATW 0 A2 0 A2

Wait for BUSY ... CMD 8A
DATW 1 A2

Wait for BUSY ... CMD 93
DATW 20 A2

Wait for BUSY ... CMD 88
DATW 3 A2 16 A2 A A2 0 A2 0 A2 0 A2 0 A2

Wait for BUSY ... CMD 2
DATW 3 A2 FF A2

Wait for BUSY ... CMD 8
DATW 0 A2 0 A2 0 A2 0 A2 0 A2 0 A2 0 A2 0 A2

Wait for BUSY ... CMD 89
DATW 7F A2

Wait for BUSY ... CMD 11
DATR 0 AA 0 FF

failed, code -20`

After I close the serial monitor and retry again, I get this:

`Initializing ... Wait for BUSY ...

CMD 80
DATW 0 AA

failed, code -707`

[jgromes]

This is the exact same issue I've seen on one of my modules. What happens is that for whatever reason, after issuing GetPacketType command (0x11), SX1268 responds with 0xAA 0xFF. The last byte - 0xFF - is pure nonsense, it should be either 0x00 (if FSK modem is active) or 0x01 (if LoRa modem is active).

Wait for BUSY ...
CMD 11
DATR 0 AA 0 FF

This is what the correct exchange looks like:

Wait for BUSY ...
CMD 11
DATR 0 A2 0 1

I opened a new thread at Semtech support forum (which seems to be the fastest way to get any information): https://lora-developers.semtech.com/knowledge-base/forum/viewthread/170/

@kylix34 the good news for you is that your module seems to be working mostly OK. All the SPI exchanges are correct, except for the first GetPacketType. I think it should work fine if you ignore the error code returned from SX126x::begin(). In the meantime, there's one thing I'd like to try out - could you please open src/modules/SX126x/SX126x.cpp and comment out lines 1380 - 1388? Those run a calibration sequence on the module, which is the command that's executed prior to the failed exchange. I'd like to see if this has an effect, thanks.

[kylix34]

I loaded the TX and RX examples provided by Droji, the manufacturer and the serial monitor doesn't throw any error. Unfortunately, I don't have another module for checking whether the TX/RX really work ... Also, obviously, they're not using RadioLib.

If you could try their examples from here with your module: http://dorji.com/docs/app/Arduino_code_for_sx1268_tcxo_module_DRF1268T_EN.rar

They seem to use an extra pin: SW const int BusyPin = 3; const int Dio2Pin = 4; const int Dio1Pin = 5; const int NssPin = 7; const int SwPin = 8;

A guy from their tech support sent me this: "You need to set the pin of SW to logic high when the module works in receive or transmit mode. "

[kylix34]

This is the exact same issue I've seen on one of my modules. What happens is that for whatever reason, after issuing GetPacketType command (0x11), SX1268 responds with 0xAA 0xFF. The last byte - 0xFF - is pure nonsense, it should be either 0x00 (if FSK modem is active) or 0x01 (if LoRa modem is active).

Wait for BUSY ...
CMD 11
DATR 0 AA 0 FF

This is what the correct exchange looks like:

Wait for BUSY ...
CMD 11
DATR 0 A2 0 1

I opened a new thread at Semtech support forum (which seems to be the fastest way to get any information): https://lora-developers.semtech.com/knowledge-base/forum/viewthread/170/

@kylix34 the good news for you is that your module seems to be working mostly OK. All the SPI exchanges are correct, except for the first GetPacketType. I think it should work fine if you ignore the error code returned from SX126x::begin(). In the meantime, there's one thing I'd like to try out - could you please open src/modules/SX126x/SX126x.cpp and comment out lines 1380 - 1388? Those run a calibration sequence on the module, which is the command that's executed prior to the failed exchange. I'd like to see if this has an effect, thanks.

Here you are:

Initializing ... Wait for BUSY ... CMD 80
DATW 0 A2

Wait for BUSY ... CMD 96
DATW 1 A2

Wait for BUSY ... CMD 8F
DATW 0 A2 0 A2

Wait for BUSY ... CMD 8A
DATW 1 A2

Wait for BUSY ... CMD 93
DATW 20 A2

Wait for BUSY ... CMD 88
DATW 3 A2 16 A2 A A2 0 A2 0 A2 0 A2 0 A2

Wait for BUSY ... CMD 2
DATW 3 A2 FF A2

Wait for BUSY ... CMD 8
DATW 0 A2 0 A2 0 A2 0 A2 0 A2 0 A2 0 A2 0 A2

Wait for BUSY ... CMD 11
DATR 0 A2 0 1

Symbol length: 4.10 ms Wait for BUSY ... CMD 8B
DATW 9 A2 4 A2 3 A2 0 A2

Wait for BUSY ... CMD 11
DATR 0 A2 0 1

Symbol length: 4.10 ms Wait for BUSY ... CMD 8B
DATW 9 A2 4 A2 3 A2 0 A2

Wait for BUSY ... CMD 11
DATR 0 A2 0 1

Symbol length: 4.10 ms Wait for BUSY ... CMD 8B
DATW 9 A2 4 A2 3 A2 0 A2

Wait for BUSY ... CMD 11
DATR 0 A2 0 1

Wait for BUSY ... CMD D 7 40
DATW 14 A2 24 A2

Wait for BUSY ... CMD D 8 E7
DATW 18 A2

Wait for BUSY ... CMD 11
DATR 0 A2 0 1

Wait for BUSY ... CMD 1D 7 36
DATR 0 A2 0 D

Wait for BUSY ... CMD D 7 36
DATW 9 A2

Wait for BUSY ... CMD 8C
DATW 0 A2 8 A2 0 A2 FF A2 1 A2 0 A2

Wait for BUSY ... CMD 9D
DATW 0 A2

Wait for BUSY ... CMD 98
DATW 6B A2 6F A2

Wait for BUSY ... CMD 86
DATW 1B AA 20 CB 0 0 0 EF

Wait for BUSY ... CMD 1D 8 E7
DATR 0 A2 0 18

Wait for BUSY ... CMD 95
DATW 2 A2 2 A2 0 A2 1 A2

Wait for BUSY ... CMD 8E
DATW 16 A2 4 A2

Wait for BUSY ... CMD D 8 E7
DATW 18 A2

Wait for BUSY ... CMD 1D 8 D8
DATR 0 A2 0 48

Wait for BUSY ... CMD D 8 D8
DATW 5E A2

success! [SX1262] Starting to listen ... Wait for BUSY ... CMD 8
DATW 2 A2 2 A2 0 A2 2 A2 0 A2 0 A2 0 A2 0 A2

Wait for BUSY ... CMD 8F
DATW 0 A2 0 A2

Wait for BUSY ... CMD 2
DATW 3 A2 FF A2

Wait for BUSY ... CMD 82
DATW FF A2 FF A2 FF A2

success!

[jgromes]

I've seen those examples previously - they don't employ any sort of status checking, so it's no surprise they don't return any error codes ;)

The SW pin is usually used to control external antenna switch, which has been mentioned a few times here, e.g. #12 and #49, however, that's only a part of the DRF1268T module, not the actual SX1268 chip.

[jgromes]

OK, that looks like the root cause is indeed the calibration sequence - not sure why this happens, or why it only happens so randomly. I will contact Semtech about this and keep this issue open for now.

[kylix34]

Thanks a lot Jan!!!!! Should it work, for the moment, without the calibration sequence?

[jgromes]

It should, it doesn't seem to be a required step.

[kylix34]

I've just tried again the GroundStation example that uses the Fossa-Comms library and I still see -707 error:

Sending ping frame ... Wait for BUSY ... CMD 80
DATW 0 AA

failed, code -707 Wait for BUSY ... CMD 8
DATW 2 A2 2 A2 0 A2 2 A2 0 A2 0 A2 0 A2 0 A2

Wait for BUSY ... CMD 8F
DATW 0 A2 0 A2

Wait for BUSY ... CMD 2
DATW 3 A2 FF A2

Wait for BUSY ... CMD 82
DATW FF A2 FF A2 FF A2

This is the code used: `void sendPing() { Serial.print(F("Sending ping frame ... "));

// data to transmit uint8_t functionId = CMD_PING;

// build frame uint8_t len = FCP_Get_Frame_Length(callsign); uint8_t* frame = new uint8_t[len]; FCP_Encode(frame, callsign, functionId);

// send data int state = radio.transmit(frame, len); delete[] frame;

// check transmission success if (state == ERR_NONE) { Serial.println(F("sent successfully!")); } else { Serial.print(F("failed, code ")); Serial.println(state); } }`

[jgromes]

This time it seems to fail at SetStandby - I haven't seen that yet, sorry.

[kylix34]

One of the engineers from Droji sent me this email:

In the file: RadioLib-master\RadioLib-master\src\modules\SX126x.cpp:

1. The TCXO is enabled only after initialization so the TCXO should be enabled first. You can add the codes below into line 34 in the code file.

state =  setTCXO(3.3);
 if(state != ERR_NONE) {
return(state);

}

2). The RX/TX switching is realized by controlling the CTNL pin of the RF switch PE4259 through the pin DIO2. In code the function of this pin is disabled so you can enable it by changing the code (line 142) from: state = setDio2AsRfSwitch(false); to

state = setDio2AsRfSwitch(true);

Now the module should transmit at interval. "

[jgromes]

1. Both setTCXO and setDio2AsRfSwitch and their usage is documented in the issue I linked to previously (#49) as well as in the (quite extensive) API documentation.

2. These commands are not a part of the SX126x::begin() method by design - RadioLib was written to control any SX126x chip, not just the SX1268-based modules made by Dorji. That's why these commands are not handled by the library begin method - the TCXO and the RF switch are external components and not a part of the SX1268 chip itself.

3. I don't think either of those will have any effect. Your module failed to initialize - it returned unexpected response to one of the SPI commands, before any operations with TCXO or the RF switch could have had a chance to take place.

[kylix34]

Well...I give up 😁

Inviato da Yahoo Mail su Android

Il mar, 26 nov, 2019 alle 16:50, Jan Gromešnotifications@github.com ha scritto:

• Both setTCXO and setDio2AsRfSwitch of these commands and their usage is documented in the issue I linked to previously (#49).

• These commands are not a part of the SX126x::begin() method by design - RadioLib was written to control any SX126x chip, not just the SX1268-based modules made by Dorji. That's why these commands are not handled by the library begin method - the TCXO and the RF switch are external components and not a part of the SX1268 chip itself.

• I don't think either of those will have any effect. Your module failed to initialize - it returned unexpected response to one of the SPI commands, before any operations with TCXO or the RF switch could have had a chance to take place.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[jgromes]

Why? It still might work, if you ignore the occasional error code. I suggest you get a different LoRa module and/or different shield (since the one you have right now won't be ble to use external interrupts, and so it won't work with the default ground station example).

[kylix34]

I already connected it through dupont cables to the correct corresponding pins on arduino.

Inviato da Yahoo Mail su Android

Il mar, 26 nov, 2019 alle 17:12, Jan Gromešnotifications@github.com ha scritto:
Why? It still might work, if you ignore the occasional error code. I suggest you get a different LoRa module and/or different shield (since the one you have right now won't be ble to use external interrupts, and so it won't work with the default ground station example).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[kylix34]

Jan, I've just made, out of curiosity, the changes suggested by Dorji and I don't have -707 error on SetStandby. The serial monitor doesn't throw any other error. Let's see if it really works. Waiting for FOSSASAT in orbit.

PS: I also re-enabled the callibration sequence and ... the errors are gone.

[jgromes]

Could you please share exactly what changes you made? Thanks.

[kylix34]

I just followed the instructions posted before:

In the file: RadioLib-master\RadioLib-master\src\modules\SX126x.cpp:

The TCXO is enabled only after initialization so the TCXO should be enabled first. You can add the codes below into line 34 in the code file. state = setTCXO(3.3); if(state != ERR_NONE) { return(state); }

2). The RX/TX switching is realized by controlling the CTNL pin of the RF switch PE4259 through the pin DIO2. In code the function of this pin is disabled so you can enable it by changing the code (line 71) from: state = setDio2AsRfSwitch(false); to

state = setDio2AsRfSwitch(true);

Now, I'm not saying I'm sure it works ... it's just I don't have errors as before (I'm not a programmer)

[jgromes]

I'm glad it's working, could you please try out a few things? First, reset and reupload the sketch a couple of times and check if it still works. Then, unplug everything and leave it that way for a few minutes. Plug it back again, open serial monitor and check if it still works.

EDIT: also, could you try if it still works if only one of the changes is made? It will help me a lot to track this down.

[kylix34]

I did another thing: loaded the stupid Blink LED sketch and the LED was flashing. Then, I put back the GroundStation sketch...and it still works without errors (at least in serial monitor). I don't really know whether the module really sends anything :)

[kylix34]

Changed state = setDio2AsRfSwitch(true); back to state = setDio2AsRfSwitch(false); and it doesn't throw any error.

That doesn't mean though that the module really sends something.....

[jgromes]

I was able to replicate this on one of my modules. Calling setTCXO seems to resolve the issue:

1. Upload code without TCXO after line 34
2. Check serial monitor - status byte 0xAA is returned
3. Upload code with TCXO after line 34
4. Check serial monitor - no errors
5. Cycle power - still no errors
6. Upload code without TCXO after line 34
7. Check serial monitor - still no errors
8. Cycle power - status byte 0xAA is returned again

This seems to suggest that TCXO is required to run the configuration commands. When you upload code without TCXO control, but don't cycle power, the module will retain the previous configuration, hence the errors do not appear.

[kylix34]

Made other tests and I found that this block of code is the one that makes the difference: state = setTCXO(3.3); if(state != ERR_NONE) { return(state); }

Unfortunately, I have no other LoRa module to check if it really sends something...

[jgromes]

I'm fairly confident it will transmit - there's no reason it shouldn't, since the only problem it had seems now resolved and mine works.

EDIT: I will add TCXO voltage as a parameter to the begin method. When set to 0, it will skip TCXO configuration, since there seems to be no way to disable TCXO control after it was enabled.

[kylix34]

Thanks a lot!!!!

[jgromes]

Could you please do one last test? I want to know if it still works with 1.6V reference voltage. Mine seems to be, but I'd like you to verify.

[kylix34]

What exactly should I do? Do I need to update the RadioLib library? On Tuesday, November 26, 2019, 8:58:15 PM GMT+1, Jan Gromeš notifications@github.com wrote:

Could you please do one last test? I want to know if it still works with 1.6V reference voltage. Mine seems to be, but I'd like you to verify.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[jgromes]

No, just instead of setTCXO(3.3) call setTCXO(1.6) in SX126x.cpp.

[kylix34]

If not getting any error means it works, I confirm that with 1.6 reference voltage , it still works. On Tuesday, November 26, 2019, 9:03:30 PM GMT+1, Jan Gromeš notifications@github.com wrote:

No, just instead of setTCXO(3.3) call setTCXO(1.6) in SX126x.cpp.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[jgromes]

Should be fixed in 49f6a7c, new release most likely tomorrow.

@kylix34 Thank you very much for the testing, it helped me a great deal.

[kylix34]

Thank you, for your time!