Ebyte E22 UART LoRa Modules

Ebyte E22 UART LoRa Modules

Just starting to play with these LoRa modules – the E22-900T22DC (0.16 watt) and E22-900T30DC (1 watt) from Ebyte. Both have simple UART interfaces. These seem interesting, but the datasheets are fairly brief and leave a lot to the imagination.

So here I am going to list some random observations and measurements, which may help you with these or similar modules. These are 900MHz versions, but much of this probably applies to all the E22 series. These pages are not going to be pretty. Your mileage may vary!

Baud Rate Hint

This is mentioned in the datasheet (using odd language), but isn’t clear until you try things yourself.

The baud rate in CONFIG state is fixed at 9.6kbps and 8N1. The baud rate you can set in register 03H only applies in Normal and WOR modes. Everytime you come back to CONFIG mode, the rate will be 9.6kbps again.

Fixed Transmission

I misinterpreted the datasheet initially. In Fixed Transmission mode, the first three bytes sent must be the address low and address high bytes, and the Channel (RF frequency value in Register 0x05). At first Fixed Transmission wouldn’t work because I had assumed the third byte should be the NetID, not the Channel (duh).

In both Transparent and Fixed transmission modes, the NetID of the sending and receiving modules must match.

CONFIG vs. AUX

There is some undocumented behaviour when the module is in CONFIG mode. The datasheet mentions AUX needing to stay high for 1 or 2mS following an action, before you know the E22 is ready for more commands or has responded to a mode change etc.

However, after successfully writing to the config registers, the E22 replies on TX with the new register values – but this reply sometimes doesn’t start until about 125mS after the register write finishes, and during this time AUX remains high and the E22 is unresponsive to any commands! AUX goes low again during the reply TX – the next time it goes high for 1+mS, you are good to go again. Summary: beware the 125mS of high AUX and unresponsive E22 when writing to configuration registers.

If you request readback of registers, or write an incorrect register value (and get FF FF FF back) when in CONFIG mode – the E22 reply will start within 2-3mS and with expected AUX behaviour.

Power Use

For LoRa, power use is super important. But only basics are in the datasheets, and nothing on actual power use during WOR mode etc. My current measurements were made with 5V supply – albeit a pretty weak supply that sagged under the heaviest loads (so you might see higher current draw at max power, when you try this).

Current in CONFIG Mode

Power use in Config mode is pretty disappointing! 10.4mA for the T30DC and 4.9mA for the T22DC. Almost as much as when in RX. So do your config, then change mode ASAP.

WOR Current – RX

When in WOR RX (“Wake on Radio”), the module sleeps for the WOR period except for a brief RX. The length of this RX depends on the air data rate – slower rates mean longer RX periods. So if set to “4000mS WOR”, module will spend 3967mS asleep, and 33mS receiving (for 2.4kbps air data rate), checking for signal. At 0.3kbps air data rate, the RX time is much longer – 280mS, significantly increasing WOR power requriements.

I measured both the RX and sleep currents for the T22DC and T30DC modules. You can see the E22 WOR can make continuously available RX feasible on batteries.

WOR Cycle (mS)Sleep mSRX mST22DC Sleep (mA)T22DC RX (mA)Average WOR mA
500467330.0048.60.571
1000967330.0048.60.288
15001467330.0048.60.193
20001967330.0048.60.146
25002467330.0048.60.117
30002967330.0048.60.099
35003467330.0048.60.085
40003967330.0048.60.075
T22DC WOR Current Draw @ 2.4kbps air data rate
WOR Cycle (mS)Sleep mSRX mST30DC Sleep (mA)T30DC RX (mA)Average WOR mA
500467330.00414.00.928
1000967330.00414.00.466
15001467330.00414.00.312
20001967330.00414.00.235
25002467330.00414.00.189
30002967330.00414.00.158
35003467330.00414.00.136
40003967330.00414.00.119
T30DC WOR Current Draw @ 2.4kbps air data rate
WOR Current – TX

The modules seem to remain in a high-power mode when on standby for WOR transmission – 9.4mA and 15.1mA for the T22DC and T30DC respectively. Then full TX power when data is actually transmitted, of course. So send your data and then find another mode ASAP.

TX Current

The datasheet specifies maximum current draw only, but not current draw at lower TX power settings. Here are some quick and dirty measurements at 5V supply:

T22DC – 1 ohm current shunt.

dBmmA
22170(140mA in datasheet)
17147
13116
1094

T30DC – 0.1 ohm current shunt. Note my power supply voltage sagged at the maximum current draw. I didn’t spend time setting up a proper supply, so max current draw at 5V probably higher than what I report here, if you use a lower-impedance supply.

dBmmA
30476(650mA in datasheet)
27408
24344
21304
RX Current

This is the same as the 33mS of RX seen in WOR-RX mode, but in NORMAL mode the RX current is continuous. So 8.6mA for the T22DC and 14.0mA for the T30DC

WOR with modules at different WOR cycles?

What if you could have your RX set to one WOR cycle time, and your TX to a different WOR cycle time? This is expressly forbidden in the datasheet, but turns out you can do this, with some restrictions. This might be useful if you have some nodes you want to have on lower latency, and others where you want to have lower current draw.

In some cases you can have your RX module set to a shorter WOR cycle than the TX. This way the RX module “sees” the TX WOR signal and waits for the data to come – it just needs to wait long enough. The RX module will give up if the data takes too long to arrive compared to its WOR cycle setting.

So you can have the WOR cycle of your RX module set to a shorter cycle than the TX module, but not too much shorter. Whether this will always work…I have not tested enough. I tested the following:

RX WORTX WOR
500mS2000mSReceived OK, couldn’t manage to cause a failure
500mS4000mSNothing received
1000mS4000mSNothing received
1500mS4000mSSometimes received, unreliable
2000mS4000mSReceived OK, couldn’t manage to cause a failure
Visits: 505

Leave a Reply

Your email address will not be published.