I'm building a Lora network, with two SX1278 modules and Arduino Uno. Lora is based on three classes. A , B and C, The question is : for implementing Class B, Does it need to change Lora module registers?! or differences between classes are just between the time they communicate to each other? and If you have a source code, it really makes life easier.
or implementing Class B, Does it need to change Lora module registers?
Well, yes. It needs to do a RX window from time to time.
or differences between classes are just between the time they communicate to each other?
Generally yes. Almost all implementation of power-saving methods in wireless communication may be reduced to difference in "just the time between they communicate" - this is an oversimplification. But generally, yes, classes manipulate the times when downlink are possible from gateway to beacon.
Class A can send message anytime and it receives messages only right after sending. Class B is class A with periodic synchronized receiving windows. And Class C can receive messages anytime - keeps RX always open.
From lora-allience.org/about-lorawan:
Class A – Lowest power, bi-directional end-devices:
The default class which must be supported by all LoRaWAN end-devices, class A communication is always initiated by the end-device and is fully asynchronous. Each uplink transmission can be sent at any time and is followed by two short downlink windows, giving the opportunity for bi-directional communication, or network control commands if needed. This is an ALOHA type of protocol. The end-device is able to enter low-power sleep mode for as long as defined by its own application: there is no network requirement for periodic wake-ups. This makes class A the lowest power operating mode, while still allowing uplink communication at any time. Because downlink communication must always follow an uplink transmission with a schedule defined by the end-device application, downlink communication must be buffered at the network server until the next uplink event.
Class B – Bi-directional end-devices with deterministic downlink latency:
In addition to the class A initiated receive windows, class B devices are synchronised to the network using periodic beacons, and open downlink ‘ping slots’ at scheduled times. This provides the network the ability to send downlink communications with a deterministic latency, but at the expense of some additional power consumption in the end-device. The latency is programmable up to 128 seconds to suit different applications, and the additional power consumption is low enough to still be valid for battery powered applications.
Class C – Lowest latency, bi-directional end-devices:
In addition to the class A structure of uplink followed by two downlink windows, class C further reduces latency on the downlink by keeping the receiver of the end-device open at all times that the device is not transmitting (half duplex). Based on this, the network server can initiate a downlink transmission at any time on the assumption that the end-device receiver is open, so no latency. The compromise is the power drain of the receiver (up to ~50mW) and so class C is suitable for applications where continuous power is available. For battery powered devices, temporary mode switching between classes A & C is possible, and is useful for intermittent tasks such as firmware over-the-air updates.