- This topic has 3 replies, 2 voices, and was last updated 7 months ago by
.
-
Posts
-
-
Hi,
maybe could provide some ideas and advice here.
The project consists of two E32-868T20D modules, let’s say A and B
One (A) is configured as a transmitter the other one (B) as a receiver
Sending datagrams from A to B looks reliable and fine as long as the are setup in Normal or Wakeup mode for both circuits regarldess the air-rate (from 300 to 19200b).
Moving the receiver (B) in PowerSave mode, fixing the sender in wakeup mode with same WOR value for both, the reception on B works stable for an air rate up to 2400bauds. Setting a higher air rate involves unreliability where, sometim,e the receiver doesn’t seem to get correctly the air datagram or get it but not sending it to the MCU.
I check this on a scope, looking at the AUX and TX signals (Lora side chip). It confirms the AUX signal, sometime, is not activate and so data on the UART not sent.
I check the same behavior when the role of the transmitter and receiver are inverted (A becomes the receiver in Powersave mode)
Both modules have the same revision firmware 45 0C 14
Fixed transmission for both, FEC ON, POWER 21
The UART speed (8N1) is checked to be 2x or 4x the air-rate
the two modules are very closed to each other (0.5 meter).Is it something normal ” !! yes there are constraints when working in PowerSave mode and it is documented…!”
May I miss something here in my datasheet module interpretation for the Wakeup/PowerSave mode coupletThanks for your support
Jean-Michel -
Hello,
to complete my request
I could find a turnaround about the issue. As a reminder, when the E32 receiver is configured in Powersave mode (so sender in Wakeup mode, same WOR figures) I couldn’t get more than 2400bps air rate with a repetitive success (let’s say 1 over 6 is missed).testing with a higher WOR figure on the sender than the one setup on the receiver, seems to resolve the issue (ie 1000ms on sender, 750ms on the receiver), it works fine up to 19.2kbps.
Lowering the period time for the detection of the preamble may make sense but looks exotic as documentation mentioned an iso WOR figure on both sender and receiver
Thanks if you have any comments
Jean-Michel
-
Hi,
A critical configuration parameter is WOR Cycle. For the sender, it is essential because it adds a long preamble to the message (long as wake time). The receiver uses wake time as a pull interval time check.
So, if the receiver checks every 2000ms (polling time) if there is a message, the sender adds a 2000ms preamble. The receiver intercepts the message preamble, waits for the actual message to read It, and returns to power-saving mode.So, if you want to maximize the power savings, you must put the maximum WOR Cycle on the receiver. If you want more efficiency, you must do the inverse and add a long preamble to the sender.
Even if the EByte advises to use the same WOR cycle.
Bye Renzo -
-
- You must be logged in to reply to this topic.
