Long range sx1268 wireless module DRF1268DS with Arduino UNO for home automation

Hello,

I am also interested in testing the 868 MHz version.

Thanks.

dorji_com:
The SW pin is connected to the /CTRL(or VDD) pin of RF switch PE4259. In normal operation, it should be connected to VCC but in sleep mode, it should be connnected to GND in order to reduce the static current. Therefore you can use a I/O pin to control it.

Are you absolutly sure about that ?

The data sheet for the DRF1268F seems very clear;

DIO2 controls the /CTRL pin of RF switch PE4259.

and

The SW pin is connected to the VDD pin of RF switch PE4259.

Seems to me that you need to use both SW and DIO2 for controlling the DRF1268F, DIO2 when switching between RX and TX and SW when you want to put the device to sleep.

I am aware thet you would normally use the SetDIO2AsRfSwitchCtrl option to control DIO2 automatically.

srnet:
Are you absolutly sure about that ?

The data sheet for the DRF1268F seems very clear;

DIO2 controls the /CTRL pin of RF switch PE4259.

and

The SW pin is connected to the VDD pin of RF switch PE4259.

Seems to me that you need to use both SW and DIO2 for controlling the DRF1268F, DIO2 when switching between RX and TX and SW when you want to put the device to sleep.

I am aware thet you would normally use the SetDIO2AsRfSwitchCtrl option to control DIO2 automatically.

Thanks for the update. The DIO2 pin is used to switch RX and TX of sx1262 when the SW is connected to VCC. If you want to minimize the sleep current (<1uA) of DRF1268T, the PE4259 should be shut up totally by setting SW and DIO2 pins to GND.

kayel:
Hello,

I am also interested in testing the 868 MHz version.

Thanks.

Thank you. We will send you the tracking number by PM very soon.

In the original post I notice that the DRF1262DS is connected directly to a Arduino UNO.
The UNO digital pins are 5v. But in the DRF1262DS data sheet it states that:

Rx 3.3v
Tx 3.3v
Mo grd or 3.3v

Wonder which I should believe ?

Oldtron:
In the original post I notice that the DRF1262DS is connected directly to a Arduino UNO.
The UNO digital pins are 5v. But in the DRF1262DS data sheet it states that:

Rx 3.3v
Tx 3.3v
Mo grd or 3.3v

Wonder which I should believe ?

Thanks for your update. The logic level of DRF1262DS is 3.3V so it will be better to connect it to 3.3V I/O pins. Anyway we add serial resistor on the I/O pins of the modules to restrict the current so these pins can be connected to 5V pins of UNO.

Thank you very much for the clarification.
I will continue with the testing.

Hi,

I received my modules today. Thanks.

MO and AU are inverted. Which one is right? I suppose it doesn't matter if I use the DAD07?

kayel:
Hi,

I received my modules today. Thanks.

MO and AU are inverted. Which one is right? I suppose it doesn't matter if I use the DAD07?

Hello Kevin, It should be the mistake of the layout engineer. The silkscreen of MO and AU on the module should be swapped. We will correct it in next version. The pin sequence and pin names in the datasheet and on the testing board DAD07 are correct. Therefore you can solder it directly on the DAD07 without problem. It's really sorry for the inconvenience.

Hello testers,

I had more or less given up with my modules. I thought I'd destroyed them while soldering. I decided to give them another go after a PM from another tester who wasn't getting anywhere with his modules either.

I dumped the example programs. The compiler complained at the second line of the first two programs so I didn't feel like trusting the rest. It was just a mis-spelling of an included library, but it makes me wonder if anyone at Dorji tests their examples before publishing them.

I don't have Windows, so the the usb-ttl converter and the configuration tool are useless to me.

With the modules 20cm apart the receiver doesn't miss a beat, as long as I hold the receiver's antenna between thumb and forefinger. If I let go, I get more errors than data.

I use a push-button pulled up to 3.3V and connected to GND in order to be able to reset the module independantly of the Arduino Pro Mini 3.3V, 8MHz.

I haven't tried sending AT commands, so the modules are configured as sold.

The modules are powered from 5V phone chargers connected to VDD. MO and EN are connected to GND using the jumpers on the modules.

The Arduinos are powered from each computer's USB port.

That's enough for now.

:sunglasses:

Hi kayel !

With the modules 20cm apart the receiver doesn't miss a beat, as long as I hold the receiver's antenna between thumb and forefinger. If I let go, I get more errors than data.

Maybe 20cm is to short for

High sensitivity: -143dBm @ power mode 0/1
                   -132dBm @ power mode 2
 Max. Output power: 22dBm

too strong signal on receiver side ?

Hi Al1fch,

I thought my modules were probably too close to each other too, but at 1 metre apart I didn't even get errors, not even a blink from the receiver's LED, although that might have something to do with my crappy breadboards!
:slight_smile:

These modules seem to be able to heal themselves!

Here are my results using the lora_main example:

I hope I haven't woken anyone up!

:sunglasses:

PS:

Look! No hands!

I didn't have to hold the aerial!

:slight_smile:

Finally success !

I had about given up on getting these to work. But after seeing that Kayel got his working I decided to give them another try. I connected each module to a Arduino UNO then connected one UNO to my desktop computer and one to my laptop. Then I loaded each UNO with the LORA_Main example sketch. I then opened up the serial monitor and typed in some data and pressed send. The module's Tx led came on and the other module's Rx led came on. But no data was displayed in the receiving serial monitor. No joy here. Then I decided to reset both modules to their factory settings using the LORA Modem Configuration Tool.
I fired everything back up and typed data into the desktop's serial monitor and pressed send. And after a slight delay data appeared on the laptop serial monitor about ten feet away. Next I moved my laptop about sixty feet away and tried sending again. Everything I sent came through with no errors. I can sent and receive from either module with no problems.
It appears that these modules are working as advertised. Next I will try some longer distances and check out some of their other features.

Just did a test at approximately 300' and had no problems. I believe these may replace my NRF24's that
seem to be really glitchy.

Dorji recently kindly supplied me several of their UART friendly SX1268 based 433 MHz modules & these have been tested to very good effect here in NZ. Several quick points -

  • Dorji's new configuration tool is very involved & perhaps needs simplification -advanced tweaks often need NOT be shown for basic setups.

  • The RSSI reporting feature is marvellous & offers all sorts of IoT prospects !

  • Due to crystal matching tolerances, temperature & aging drift the initial SX127x based modules were usually limited to 62.5 kHz BW. An apparently superior Rakon crystal (~1ppm) is now used, implying tighter BW could be beneficially employed. Such more closely matched Rx & Tx freqs suggest range improvements of perhaps 50 -100% could arise with narrower BW. (Refer the attached table -organised in conjunction with SRNET back in 2015.)

Hi,
Is this operation still active?
I'm looking for trying some LoRa communication.
I'm searching a really low consumption emitter while sleeping and a high sensitivity receiver.

ROUGEXIII:
Hi,
Is this operation still active?
I'm looking for trying some LoRa communication.
I'm searching a really low consumption emitter while sleeping and a high sensitivity receiver.

There is an example of a low current transmitter used as a remote control for a LoRa receiver here;

The 'transmitter' uses a bare bones ATMega328P and uses around 2uA when asleep. Press one of the buttons and the transmitter wakes up and sends the packet to control the remote.

At the moment it runs on SX127X only, but SX126x support will be added soon.

UART front ended modules have their place, but the standard SPI based modules are very much more flexible.