Forum Replies Created
-
Posts
-
Hi echo,
You can use the programmer software of the EByte, you can download from here also.
So you must set the device in config mode and connect to it.
Bye RenzoHi,
In fixed transmission you must use as destination address the address set in the config of the device that just receive the message.
In wor the tx and rx is setted as usual respectly to the rx tx of the counter part.
Bye RenzoHi William,
I think you must check the power supply and the memory usage, you must debug all the variables used and the size.
Bye RenzoHi,
I can’t check the configuration and the wiring without the library that translates the byte in instruction, but It’s very improbable that the problem is the module.But the configuration packet is 6 bytes so
C0 00 00 62 00 12
The sending packet for the address and channel you use seems incorrect.Try using the library to simplify all the processes and reduce the errors; if it works, try replicating the byte array packet.
Bye Renzo
Hi,
the code is correct, the only thing you must do is close the
ResponseStructContainer c;
like so
c.close();Check the power supply. The 1W module needs a lot of power to work, so now use an external power supply and add a 100uF electrolytic capacitor (or more) and a 0.1uF ceramic capacitor to it.
Then use a getConfiguration sketch and send me the result.
Bye RenzoHi,
If you correctly set the M0 and M1, the configuration for fixed transmission with relative addresses for the sender and receiver is okay. If you send the correct packet to address the message to the other device, it must work.
If It does not work, you do something wrong in one of these steps:
– connection schema
– configuration of receiver and sender
– code of the transmitter
– code of the receiver
Bye RenzoAnd you use this library???
Bye RMHi ERicci,
To start a fixed-point communication, you need to configure the device properly.Please post your configuration sketch and the sender/receiver one.
First of all, I advise you to try a simple get configuration and post an image of the connection to the board.
Bye RenzoHi,
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 RenzoHi Willian,
the code is quite complex, and I need time to check It in depth, but what is the scope of the Ticker library?
Bye RenzoHi Baftu,
I think you set the pointer for the structure, not the structure of single elements.
You must create a fixed structure with fixed-size elements.
Bye RenzoHi Elkez,
I normally describe a device module thinking of a real scenario (I don’t write to have a visit), and I select the e70 because it has RSSI and a very good Sleep mode management to manage the battery. You probably never raise a distance if a device is declared for 1.5km but has high sensitivity.
All to say, this can be considered a good solution.
There are alternatives, but the efficiency can’t be the same.But in your case (low number of messages per second), I think it can be a good solution for a LoRa device like the e220.
Bye Renzo
Hi phnahes,
I think you can’t decode because the EByte uses a proprietary cryptography system to obfuscate the message.
Even if some people decode it for e32 (it doesn’t have a key to change the algorithm), here is the thread where you can find some information.
EByte LoRa Communication encode/decode, crypt/decrypt
I don’t know if @Sahar-2 go ahead with Its idea, but I think you can ask.
Bye Renzo
