PrintParameters vs baud rate

klismont commented 4 years ago

Hi Kris,

First of all, I greatly appreciate your work here! I love it.

First maybe some background on my project. I'd like to set up a simple sender-receiver communication using two Ebyte E32-915T30D modules. The sender is connected to an Arduino and the receiver to a Raspberry Pi 2B. I have been able to get a communication established in the past (read: last week), but the data transfer rate was too slow. So I ended up finding your library with the goal to configure the modules for a higher data transfer rate.

With another Arduino and some basic coding using your library, I made a little "programmer" and I was able to reconfigure the modules to baud rate 115200 bps and 19.2bps. The rest I kept the same.

In my sender code, I have inserted the following lines to check the sender module parameters:

`EBYTE Transceiver(&Serial); // Create the transceiver object, passing in the serial and pins

void setup() {
Serial.begin(9600); // Connect terminal serial (shared for LORA serial on Arduino Nano)

Transceiver.init(); // This init will set the pinModes for you Transceiver.PrintParameters();`

The serial output I get is as follows: `⸮⸮⸮⸮⸮⸮---------------------------------------- Model no.: 44 Version : C Features : 1E

Mode (HEX/DEC/BIN): C0/192/11000000 AddH (HEX/DEC/BIN): 0/0/0 AddL (HEX/DEC/BIN): 0/0/0 Sped (HEX/DEC/BIN): 3D/61/111101 Chan (HEX/DEC/BIN): F/15/1111 Optn (HEX/DEC/BIN): 44/68/1000100 Addr (HEX/DEC/BIN): 0/0/0

SpeedParityBit (HEX/DEC/BIN) : 0/0/0 SpeedUARTDataRate (HEX/DEC/BIN) : 7/7/111 SpeedAirDataRate (HEX/DEC/BIN) : 5/5/101 OptionTrans (HEX/DEC/BIN) : 0/0/0 OptionPullup (HEX/DEC/BIN) : 1/1/1 OptionWakeup (HEX/DEC/BIN) : 0/0/0 OptionFEC (HEX/DEC/BIN) : 1/1/1 OptionPower (HEX/DEC/BIN) : 0/0/0

`

This output data looks fine I believe.

Now, what I do not understand:

If I use 115200 as serial baud rate, I get back nothing but zeros as parameter values. I don't understand why. Only 9600 baud gives back correct values.
Having both sender and receiver modules reconfigured and showing exactly the same parameters (as in snippet above), I do not get communication established anymore. Sender and receiver M0 & M1 are connected to ground when trying to communicate. I realize this is not something you can investigate as so many things could be preventing communication, but just wanted to mention it.

Thanks in advance for any help, Kevin

KrisKasprzak commented 4 years ago

There could be a few issues here. I've never tested the lib with an RPI so i'm happy it works. 1) I recently made a change to the library where I was attempting to allow all serial settings through the library--bad idea have a look at your EBYTE.cpp file around line 79 you may see a _s->setTimeout(..... comment that line out. I found it was actually corrupting the modules settings and took manually resetting them. It's possible if you had a lib version with this on, it may have messed up your module settings--hence data will not transfer if you need to manually reset your module, this will get you close. see data sheet for exact bit values yourModuleObjectName.SetAddressH(0); yourModuleObjectName.SetAddressL(0); yourModuleObjectName.SetSpeed(0b00011000); yourModuleObjectName.SetChannel(0); // default may be 15 yourModuleObjectName.SetOptions(0b01000100); yourModuleObjectName.SaveParameters(PERMANENT);

2) I assume your 115200 is the rate you are sending data the module (Serial1.begin(115200) and NOT the UART or air data rate. The air data rate for the module is 19.2kbaud that high baud sounds iffy. I've had issues with baud rates being that high. Try sneaking up on that value. If 9600 works, try the next val and so on. 3) is your data transfer ever been reliable? Reason i asks is that if you are sending a struct different compilers optimize the struct differently--I had tons of issues in sending structs and had to use EasyTransfer libs--which sends structs differently avoiding the packing issues. There are other ways to force compilers to not screw with struct packing 4) i'm not sure how fast pin modes recover on a RPI but in EBYTE.h around line 77 you will see a #define for PIN_RECOVER, it's probably set to 20ms you may have to increse that--but this is a long shot 5) also I added many more methods for xxx.GetChannel() so you can present the current channel to the user if you want to allow some interactive change. If your lib does not have that method, maybe get the latest lib. 6) i'm sure it's just not included but you do have a Serial1.begin(9600)? or what ever serial EBYTE is connected to. Thanks, Kris Kasprzakkris.kasprzak@yahoo.com

On Monday, May 11, 2020, 03:37:42 PM CDT, klismont <notifications@github.com> wrote:

Hi Kris,

First of all, I greatly appreciate your work here! I love it.

First maybe some background on my project. I'd like to set up a simple sender-receiver communication using two Ebyte E32-915T30D modules. The sender is connected to an Arduino and the receiver to a Raspberry Pi 2B. I have been able to get a communication established in the past (read: last week), but the data transfer rate was too slow. So I ended up finding your library with the goal to configure the modules for a higher data transfer rate.

With another Arduino and some basic coding using your library, I made a little "programmer" and I was able to reconfigure the modules to baud rate 115200 bps and 19.2bps. The rest I kept the same.

In my sender code, I have inserted the following lines to check the sender module parameters:

`EBYTE Transceiver(&Serial); // Create the transceiver object, passing in the serial and pins

void setup() { Serial.begin(9600); // Connect terminal serial (shared for LORA serial on Arduino Nano)

Transceiver.init(); // This init will set the pinModes for you Transceiver.PrintParameters();`

The serial output I get is as follows: `⸮⸮⸮⸮⸮⸮---------------------------------------- Model no.: 44 Version : C Features : 1E

Mode (HEX/DEC/BIN): C0/192/11000000 AddH (HEX/DEC/BIN): 0/0/0 AddL (HEX/DEC/BIN): 0/0/0 Sped (HEX/DEC/BIN): 3D/61/111101 Chan (HEX/DEC/BIN): F/15/1111 Optn (HEX/DEC/BIN): 44/68/1000100 Addr (HEX/DEC/BIN): 0/0/0

SpeedParityBit (HEX/DEC/BIN) : 0/0/0 SpeedUARTDataRate (HEX/DEC/BIN) : 7/7/111 SpeedAirDataRate (HEX/DEC/BIN) : 5/5/101 OptionTrans (HEX/DEC/BIN) : 0/0/0 OptionPullup (HEX/DEC/BIN) : 1/1/1 OptionWakeup (HEX/DEC/BIN) : 0/0/0 OptionFEC (HEX/DEC/BIN) : 1/1/1 OptionPower (HEX/DEC/BIN) : 0/0/0

`

This output data looks fine I believe.

Now, what I do not understand:

If I use 115200 as serial baud rate, I get back nothing but zeros as parameter values. I don't understand why. Only 9600 baud gives back correct values.
Having both sender and receiver modules reconfigured and showing exactly the same parameters (as in snippet above), I do not get communication established anymore. Sender and receiver M0 & M1 are connected to ground when trying to communicate. I realize this is not something you can investigate as so many things could be preventing communication, but just wanted to mention it.

Thanks in advance for any help, Kevin

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

klismont commented 4 years ago

Hi Kris,

I'd have to look into your reply in detail this evening or later this week, but I can give some more info:

* I'm using the actual RX/TX on the Arduino for the sender module. I realize it is not ideal, as I have to unplug these two wires when I want to program the Arduino as it's shared with the USB. So no, I don't use a SoftwareSerial kind of serial connection, so Serial1.begin ( baud ) does not exist in my code. I do however use AltSoftSerial for a GPS receiver connected to the same Arduino. 
* I'm using your most recent library I believe, with the line 79 commented out. 
* Communication has never been reliable. A lot of data loss, or unfinished lines. But I am aware I'm pushing out too much data for the given air data rate, so I'm not surprised in that regard. I have not been using any structs or libs like EasyTransfer thus far, I'm just spitting our Serial.print. Maybe I should look into that, but first I'd like to have some kind of communication working again :-)

I think the best way to move forward is to maybe restore to factory settings again, and see if I can still get the communication to work again. I'm not 100% sure my sender module is still okay as I realize I have been running it a higher voltage then the 5.2VDC max mentioned in the datasheet - feel so stupid about that :-(

Can you explain to me what is the difference (if any) between the baud rate in the Arduino program (f.i. Serial.begin(115200)) and the baud rate you can set the E32 module to? I'm confused about this.

Just as a side note: I'm a true hobbyist without a great amount of programming knowledge, but I tend to pick up quickly and try to learn :-)

Regards & thanks for the fast reply, Kevin

Van: "Kris Kasprzak" notifications@github.com Aan: "KrisKasprzak/EBYTE" EBYTE@noreply.github.com Cc: "klismont" stvv@telenet.be, "Author" author@noreply.github.com Verzonden: Maandag 11 mei 2020 23:44:58 Onderwerp: Re: [KrisKasprzak/EBYTE] PrintParameters vs baud rate (#19)

There could be a few issues here. I've never tested the lib with an RPI so i'm happy it works. 1) I recently made a change to the library where I was attempting to allow all serial settings through the library--bad idea have a look at your EBYTE.cpp file around line 79 you may see a _s->setTimeout(..... comment that line out. I found it was actually corrupting the modules settings and took manually resetting them. It's possible if you had a lib version with this on, it may have messed up your module settings--hence data will not transfer if you need to manually reset your module, this will get you close. see data sheet for exact bit values yourModuleObjectName.SetAddressH(0); yourModuleObjectName.SetAddressL(0); yourModuleObjectName.SetSpeed(0b00011000); yourModuleObjectName.SetChannel(0); // default may be 15 yourModuleObjectName.SetOptions(0b01000100); yourModuleObjectName.SaveParameters(PERMANENT);

2) I assume your 115200 is the rate you are sending data the module (Serial1.begin(115200) and NOT the UART or air data rate. The air data rate for the module is 19.2kbaud that high baud sounds iffy. I've had issues with baud rates being that high. Try sneaking up on that value. If 9600 works, try the next val and so on. 3) is your data transfer ever been reliable? Reason i asks is that if you are sending a struct different compilers optimize the struct differently--I had tons of issues in sending structs and had to use EasyTransfer libs--which sends structs differently avoiding the packing issues. There are other ways to force compilers to not screw with struct packing 4) i'm not sure how fast pin modes recover on a RPI but in EBYTE.h around line 77 you will see a #define for PIN_RECOVER, it's probably set to 20ms you may have to increse that--but this is a long shot 5) also I added many more methods for xxx.GetChannel() so you can present the current channel to the user if you want to allow some interactive change. If your lib does not have that method, maybe get the latest lib. 6) i'm sure it's just not included but you do have a Serial1.begin(9600)? or what ever serial EBYTE is connected to. Thanks, Kris Kasprzakkris.kasprzak@yahoo.com

On Monday, May 11, 2020, 03:37:42 PM CDT, klismont notifications@github.com wrote: