E32-TTL-100 - How to use the RF module?

Hi, I know, there are several articles on how to get this type of RF module work, and some of them seems to be really helpful, but after a week of searching and trying all the codes I found, I can say, that I wasn't able to use the modules with Arduino. The only thing I know, that they're working, but only with their USB to TTL converters. So if you have any experience, please share it with me, Thanks!

What code did you try on the Arduino. How did you wire the module to the Arduino. What Arduino are you connecting it to.

And post a link to the datasheet for the wireless module.

...R

Here you can download the datasheet: http://www.cdebyte.com/en/downpdf.aspx?id=130

I connected: Module---Arduino UNO VCC---5V GND---GND TX---10 RX---11 M0---GND M1---GND

And used the softwareSerial example code: https://www.arduino.cc/en/Tutorial/SoftwareSerialExample With setting the softwareSerial baud rate to 9600.

I assume you have two of those wireless devices and two UNOs.

Post the programs YOU have uploaded to both Arduinos.

...R

Sorry, I was at school, so didn't have enough time to write down all rhe important infos. So, the first thing I tried out to do the thing with two Nanos, but it didn't work. Then I changed one of them to an UNO, unfortunately, I wasn't able to send and receive messages. The code I was using on both modules:

/*
  Software serial multple serial test

 Receives from the hardware serial, sends to software serial.
 Receives from software serial, sends to hardware serial.

 The circuit:
 * RX is digital pin 10 (connect to TX of other device)
 * TX is digital pin 11 (connect to RX of other device)

 Note:
 Not all pins on the Mega and Mega 2560 support change interrupts,
 so only the following can be used for RX:
 10, 11, 12, 13, 50, 51, 52, 53, 62, 63, 64, 65, 66, 67, 68, 69

 Not all pins on the Leonardo and Micro support change interrupts,
 so only the following can be used for RX:
 8, 9, 10, 11, 14 (MISO), 15 (SCK), 16 (MOSI).

 created back in the mists of time
 modified 25 May 2012
 by Tom Igoe
 based on Mikal Hart's example

 This example code is in the public domain.

 */
#include 

SoftwareSerial mySerial(10, 11); // RX, TX

void setup() {
  // Open serial communications and wait for port to open:
  Serial.begin(9600);
  while (!Serial) {
    ; // wait for serial port to connect. Needed for native USB port only
  }


  Serial.println("Goodnight moon!");

  // set the data rate for the SoftwareSerial port
  mySerial.begin(9600);
  mySerial.println("Hello, world?");
}

void loop() { // run over and over
  if (mySerial.available()) {
    Serial.write(mySerial.read());
  }
  if (Serial.available()) {
    mySerial.write(Serial.read());
  }
}

For testing something like that I would write two separate programs. I would get one of them to send "" once per second and I would use the 3rd example from Serial Input Basics on the other Arduino.

I can't think of any reason why it would make any difference using Nanos or Unos.

I have had another look at the datasheet. That seems to be a 3.3v device so you are likely to damage it by connecting it directly to a 5v Arduino.

...R

Thanks! I'll try to do the thing according to your suggestions, and will notice you if it will work, or not. But I'm still confused about voltage levels, because I found an older datasheet, that says it's 5V tolerant (works well up to 5.5Volts). So I don't know what to do. E32-TTL-100 Connections

afkiss: because I found an older datasheet, that says it's 5V tolerant (works well up to 5.5Volts).

I does not actually say that. And I don't think the advice in that link is any different to the advice in the other link.

...R

The datasheet shows the module can be powered up to 5.2V but the data pins are only rated up to 3.6V

In an early reply you said your using 9600 baud and the datasheet says this is the default baud rate for the module but the example code you posted shows software serial is using 4800 baud.

Once you have the voltage & baud problems sorted if it still does not work then try swapping the RX/TX pins over as Serial naming conventions are a but lax and the pins might not match the direction. |500x299

Clipboard-1.png|964x577

Thanks for both of you! Robin2, your code solved all my problem. By using a 4.7k resistor between Arduino TX and E32's RX, the whole thing works like a charm.

If you want a library specific to this company transceivers, i've posted a library, You can send / receive bytes or data structures, as well as program the unit in terms of changing air data rates, channels, and other module parameters.

https://github.com/KrisKasprzak/EBYTE

Hope this helps.

KrisKasprzak: If you want a library specific to this company transceivers, i've posted a library, You can send / receive bytes or data structures, as well as program the unit in terms of changing air data rates, channels, and other module parameters.

https://github.com/KrisKasprzak/EBYTE

Hope this helps.

Hello Kris,

I'm trying to get a simple transmitter receiver between two transceivers, E32-TTL-100 and E32-TTL-1W. I'm trying to run the sender and receiver.ino files but the following error message appears. I'm sure that I'm doing something wrong with the file directories. Can you give me a few instructions on how to use the library.

sketch\EBYTE.cpp:47:19: fatal error: EBYTE.h: No such file or directory

compilation terminated.

exit status 1
Error compiling for board Arduino/Genuino Uno.

Thanks in advance, Georgios

Did you try the standard method for importing Zip file libraries;

Sketch\Include Library\Add ZIP Library...

I seem to be getting extremely low bandwidth (with uart at 115200 and rf at 19200) when trying to receive a stream of gnss data, distance not being the problem. Do I miss something basic like having to change default channels?

epigramx: I seem to be getting extremely low bandwidth (with uart at 115200 and rf at 19200) when trying to receive a stream of gnss data, distance not being the problem. Do I miss something basic like having to change default channels?

What is missing is a complete description of the hardware you are using and the code for the programs you are using.

...R

Robin2: What is missing is a complete description of the hardware you are using and the code for the programs you are using.

...R

Nevermind, my main problem was a misunderstanding of what those modules can do. The first practical problem I noticed is that it's relatively nonsensical to use a different UART rate compared to air rate unless you can guarantee you won't go above the air rate since the module appears to be implied by the manual-datasheet that has only 512bytes of cache (so it's a dropped-data galore that way [if you try to stream something like a big file] when it's already easy to drop data if you meet the air rate anyway).

Secondly, generally the modules are VERY low bandwidth by design so one should be careful to not try to send anything too populous and above the air rate. Something crucial is that they also have an error correction mode on by default (FEC) which is an EXTREME bandwidth hog so one should only enable it if they are absolutely sure they can get away with the lost bandwidth.

epigramx: Something crucial is that they also have an error correction mode on by default (FEC) which is an EXTREME bandwidth hog so one should only enable it if they are absolutely sure they can get away with the lost bandwidth.

The use of FEC is implicit in the use of LoRa, you cannot turn it off all together. Ebyte have an option for turning it on and off, I suspect that might actually just be changing the rate from 4:5 to 4:8.

You can (with the native LoRa device) set the rate from 4:5 to 4:8.

The standard FEC rate, 4:5 adds 25% to the number of bits sent, hardly an 'EXTREME bandwidth hog'.

epigramx: Secondly, generally the modules are VERY low bandwidth by design so one should be careful to not try to send anything too populous

In LoRa technology bandwidth is used to refer to the RF bandwidth of the LoRa signal, which can be set between 7.8Khz and 500Khz. Bandwiths of 62.5Khz and lower give longer range but really require the modules to use temperature compensated oscillators, so mostly not used due to cost considerations.

A (high) bandwidth of 125Khz is most used in IOT applications.

The UHF LoRa devices were not designed to stream large amounts of data, rather to provide extreme long range links for low data rates in a very battery efficient manner.

srnet: The use of FEC is implicit in the use of LoRa, you cannot turn it off all together. Ebyte have an option for turning it on and off, I suspect that might actually just be changing the rate from 4:5 to 4:8.

You can (with the native LoRa device) set the rate from 4:5 to 4:8.

The standard FEC rate, 4:5 adds 25% to the number of bits sent, hardly an 'EXTREME bandwidth hog'.

I do not know if they practically violate the standard on their config tool. I talked of their config tool specifically ("RF_Setting") which only shows "FEC ON", "FEC OFF" and when it's enabled it's extremely higher bandwidth compared to being off when bandwidth matters (e.g. when you need to squeeze your data - comfortably - in 9600 and when it's on, only 19200 may do it) [the word "extremely" is subjective anyway, so let's not delve too much into that, in the example I gave it can be considered an important overhead in any case].

[PS. Their manual/datasheet also only includes phrases like "After turn off FEC"]