Long Range communication to a Cell Phone or Tablet GUI Display.

Marathonman

Well-known member
I am looking for some advice on long range communication to a cell or tablet using Teensy4.0 or 4.1. I was wondering if a XBee or Pro with other adapters would do the trick or do I need it to connect to a router. This is all local and I would rather not have it connected to the net rather local sub net.
I am kinda lost right now and sure could use some advice. I have no budget in mind as all i want is to communicate sensor date and BMS Date to a GUI on either a tablet or a cell phone. This is a solar tracker tower and I would love to get long range communication to 500 or 600 feet to the main house. Their is also an AirBnB right there that will also be running a solar system and I would like it connected also.

ANY advice is welcomed and is just the feasibility right now.
 
Lora is Synonymous with long range. If you only want to send data it should be fine.
I use these which communicate with the Teensy using the Serial interface.
There are other Lora/Uart modules in their range.
Search EByte on Amazon, sometimes you can find good prices in the range $6-$7 per module.
Of course you will also need aerials as well, circa $2 each.
There are a number of Libraries available and I have ones for the E32, E22 and the E220.
 
WOW Bricomp I honestly never knew Lora went that far and thought it was just another bluetooth type. 5.5 Klm is quite far as is the ZBee and Zbee pro at like 4000 ft.
The Lora dongle is by far the cheapest that I have seen. I simply love the fact that it is 85c capable as it will be in the Texas sun but under the panels.
Yes I was expecting to have other equipment to buy so not worried there. all in all it seems like a good solution to my problem.

Thank you so much.
 
What I will be doing is using the long rang communication so I can either use a android cell app to monitor and also a wall based touch sensor unit for monitoring the voltage, current, battery status, solar tower position ect...
Any suggestions will be HIGHLY appreciated. I have already designed the duel motor control unit with a Teensy 4.1 and can use the extra pins for sensor readings.
Regards,
Marathonman
 
The possible problem I can foresee is that LoRa is very low level transmission data and I will have multiple sensors sending data to a GUI and App on Android. Can anyone give me any information on this aspect.

Regards,
Marathonman
 
Not sure what product if any has been selected. Also what is meant by 'low level transmission data'?

Looking at this as an example: adafruit.com/radio-featherwing

It notes it uses SPI to connect, and indeed the low level radio does just bits - but it has a packetized interface for high level interface where the bits and error checking are handled below that.

The longer the distance the slower the data transfer rate - though didn't see that discussed in the above link.

That should clear up some details and point to that or other as a usable device where the bare LORA boards need some number of connections.
 
I an looking at about 500 to 1,000 feet but would like to get the highest transmission possible even though it is only sensor data there will be like 6 to 8 sensors. I was also looking at there 2.4ghz transmission module which is also good for quite a good range. All in all I an still undecided at this point. any suggestion are most welcome. all the censors will be tied into a The Teensy 4.1 and the LoRa sent to the receiver LoRa which is tied to a touch screen and a Android App. The touch screen will be at the main house which is rather far a way. I am guessing I need two Teensy 4,1's one for transmit and the other for receive.

Thank you for the reply so much!
 
Set the receiving station to Home Address (Whatever number you choose).
Set each remote station to their own address (REM01, REM02 etc)
Set all the channels to the same HOME and Remotes.
When sending from a remote, send to Home Address.
I don't know, but I guess LORA handless CLASHES.
When home receives data it will have the address of the sending station.
If you are worried about clashes you could have Home Send a message to each Remote in turn asking them to send data. Then home waits for the data to be sent, with a suitable timeout.

Send data in Binary form rather than ASCII form. Ideally have your data in a Struct, and just send the struct each time.
 
Last edited:
EBYTE Comms Types.jpg
Use the last type.
All modules have the same Channel.
Module A has address set to FFFF - Send to - Receive from ALL modules.

Each module should be set up with their own address:
A - FFFF
B - 0001
C - 0002
D - 0003

Within the structure from each module ( B C or D ) have something that states the address of the module.

If A wants to talk to B, A changes it's address to the same address as B, and sends the data.
When A has it's address set this way it can only communicate with modules with the SAME address (and Channel).
After having sent data to B, A puts it's address back to FFFF.

When a module has it's address set to FFFF it can receive and transmit to all channels.

Teensy Snooze Recovery Time inc Teensy 4.JPG
Be aware that you CANNOT use the Snooze library DeepSleep with Teensy 4.0 and 4.1 modules.
The EBYTE modules send a wake-up signal and 2-3ms later send the data to the MCU.
Unfortunately using the Snooze library DeepSleep with T4.0 and T4.1 they take MORE than 5ms to wake up the Teensy, so the Teensy has missed the data from the EBYTE module.

EBYTE Wakeup.jpg
 
Thank you very much for this valuable information. The units will be the transceiver connected to the Teensy mounted to the duel H bridge tracker board at the solar array. It will have multiple sensors connected to the Teensy like voltage and current status from the solar array and the battery plus I might add BMS status as well. So I am looking at two current and two voltage sensors plus solar panel direction location and the BMS status.

The receiver will be mounted permanent to the wall with a 10 inch touch screen showing all status that is updated every few minutes. I would also like an Android app display capable which i can make the app myself . All i need is the ability to connect to it and will only be status only with no means to control.
The Teensy will be attached to the H bridge board with all non used pins facing up for connection to sensors which will be a custom break out sensor board.. Now i need to figure out how i will send the information in packets, separate or what have you.

EDIT:
"Send data in Binary form rather than ASCII form. Ideally have your data in a Struct, and just send the struct each time."

I like the sound of that BriComp and will research as it does seem to solve my concerns. Can the sensor info be stored in a buffer then sent in Packetized group or groups to update the receiver end every so many minutes????

"Looking at this as an example: adafruit.com/radio-featherwing "

I like this Defragster and looks like it will fit the bill nicely.

Thank you both for fine information.
Regards,
Marathonman
 
Last edited:
"STATUS = Module_info((uint8_t *)pCFG, sizeof(CFGstruct));
if(STATUS == RET_SUCCESS)"

BriComp;
Is this what you were referring to when you said "Ideally have your data in a Struct, and just send the struct each time."

Regards,
Marathonman
 
No, something like this:-
Code:
#pragma pack(push,1)	// using this makes compiler use 2 bytes per uint16 rather than packing to 4.

typedef struct data_t {
	uint16_t volt1;     // actual voltage = volt1/10.0 giving range of 0.0 to 6500.1 volts.
				// if you want 2 dp then divide by 100. range reduced accordingly.
	uint16_t volt2;		// sendinmg uint16_t rather than float saves 2 bytes for each parameter.
	uint16_t current1;
	uint16_t current2;
// other data for return
};

data_t transmitData;

#pragma pack(pop)
I suggest that your version of above is put in a .h file, possibly vars.h and is imported into the slave and master ino. That way the data format will always be in sync.
 
Last edited:
Can this dats be put into a area in a buffer then sent as one struct or package. Like have all the sensors write their data to this buffer then send the whole packet to the receiver.????

"I suggest that your version of above is put in a .h file, possibly vars.h and is imported into the slave and master ino. That way the data format will always be in sync."

Makes a whole lot of sense, thanks!

Regards,
Marathonman
 
Last edited:
Can this dats be put into a area in a buffer then sent as one struct or package. Like have all the sensors write their data to this buffer then send the whole packet to the receiver.????

"I suggest that your version of above is put in a .h file, possibly vars.h and is imported into the slave and master ino. That way the data format will always be in sync."

Makes a whole lot of sense, thanks!

Regards,
Marathonman

Have a look at this as an idea as a possible solution.
First vars.h
Code:
#pragma once

#pragma pack(push,1)	// using this makes compiler use 2 bytes per uint16 rather than packing to 4.

typedef struct sensorType {
	uint16_t voltage;		// actual voltage = volt1/10.0 giving range of 0.0 to 6500.1 volts.
							// if you want 2 dp then divide by 100. range reduced accordingly.
	uint16_t current;		// sendinmg uint16_t rather than float saves 2 bytes for each parameter.
};

typedef struct azimuthType{
	uint32_t somethingElse;
}

typedef struct data_t {
	sensorType sensor1;
	sensorType sensor2;
	sensorType sensor3;
	azimuthType azimuth;
};

#pragma pack(pop)
...then SendData.ino
Code:
/*

  This example shows how to connect to an EBYTE transceiver
  using a Teensy 3.2

  This code for for the sender


  connections
  Module      Teensy
  M0          2
  M1          3
  Rx          1 (MCU Tx line)
  Tx          0 (MCU Rx line)
  Aux         4
  Vcc         3V3
  Gnd         Gnd

*/

#include <EBYTE_E220.h>
#include "vars.h"

// connect to any of the Teensy Serial ports
#define ESerial Serial1

#define PIN_M0 2
#define PIN_M1 3
#define PIN_AX 4

// i recommend putting this code in a .h file and including it
// from both the receiver and sender modules

// these are just dummy variables, replace with your own

int				Chan;
data_t			transmitData;
elapsedMicros	timeToSendData;

// create the transceiver object, passing in the serial and pins
EBYTE Transceiver(&ESerial, PIN_M0, PIN_M1, PIN_AX);

void setup() {

	Serial.begin(9600);

	while (!Serial) {}

	// start the transceiver serial port
	ESerial.begin(9600);

	Serial.println("Starting Sender");

	// this init will set the pinModes for you
	Transceiver.init();


	// all these calls are optional but shown to give examples of what you can do

	// Serial.println(Transceiver.GetAirDataRate());
	// Serial.println(Transceiver.GetChannel());

	Transceiver.SetAddressH(0xFF);
	Transceiver.SetAddressL(0xFF);
	Chan = 15;
	Transceiver.SetChannel(Chan);
	// save the parameters to the unit,
	Transceiver.SaveParameters(PERMANENT);

	// you can print all parameters and is good for debugging
	// if your units will not communicate, print the parameters
	// for both sender and receiver and make sure air rates, channel
	// and address is the same
	// Transceiver.PrintParameters();

}

void GatherData() {
	transmitData.sensor1.voltage = analogRead(A0);
	transmitData.sensor1.current = analogRead(A1);
	transmitData.sensor2.voltage = analogRead(A2);
	transmitData.sensor2.current = analogRead(A3);
	transmitData.sensor3.voltage = analogRead(A4);
	transmitData.sensor3.current = analogRead(A5);
	transmitData.azimuth.somethingElse = 0x324223;
}

void ClearoutData() {
	transmitData.sensor1.voltage = 0;
	transmitData.sensor1.current = 0;
	transmitData.sensor2.voltage = 0;
	transmitData.sensor2.current = 0;
	transmitData.sensor3.voltage = 0;
	transmitData.sensor3.current = 0;
	transmitData.azimuth.somethingElse = 0;
}

void loop() {

	if (timeToSendData >= 5 * 60000) {
		GatherData();
		if (Transceiver.SendStruct(&transmitData, sizeof(transmitData))) {
			ClearoutData();   //indicates data sent, ready for new data
			timeToSendData=0;
		}
		else {
			Serial.println("Error sending data");
		}
	}
	delay(1000);
}
NOTE That I have not tested this code in use, just based upon my experience.
 
WOW BriComp thank you for the time and effort. This should get me pointed in the right direction for sure. I have a friend helping me with is who is more coding efficient then i am. I am more of a hardware guy and do most if not all pcb stuff.

Again I thank you so very much and will post results when testing LoRa.

Regards,
Marathonman
 
You can get the E220 library here.
It is a modification of the excellent library written by Kris Kasprzak, modified for the E220.
So far no one other than myself has used this library. Welcome to the guinea pig club.
 
Excellent and comprehensive writeup. OMG thank you so very kindly. This definitely set me in the right direction and then some. just wish the 1076 was around to take advantage of the duel core Architecture.

So the internal buffer is cleared every time the data is sent to the receiver, verified, then the buffer is cleared to avoid programming and read corruption. Well that makes sense to me. And by the way we all are guinea pigs at one time or another putting ourselves out there. Also I will have to have a set of these correct? as it takes two of the same to talk to each other. Another thing is I have to use UART and not SPI.

Thank you so much,
Regards,
Marathonman
 
Yes, it takes two of the same unit, with one on each end. The communication uses proprietary protocols and signaling and data protections.

The post #6 link to AdaFruit device gave that and other informative details on using these devices. There may be better summaries - but it has some good highlights.
 
Another thing is I have to use UART and not SPI.
There are SPI versions of the radio but I have not used any of them. There are drivers out there for the SPI devices, you would have to search for them.

The advantage of the UART based devices is that it makes them relatively easy to debug and also they are more plentiful on Amazon and cheaper.

Yes you will need a pair of devices, one to send the data, the other to receive it. Having said that they are Transceivers so data can go both ways.
 
Another question I have would it be better to use the E32-900T30D wireless or the E32-900T20D LoRa module both UART and both seem to fit the bill. Again any advice would be welcome.
 
I use both, the xxx30 is a high power (1W unit / 30 db) device. It has crazy good range and mine works even with poor line of sight. It will consume some 800 ma when transmitting, the xxx20 is a 100 mW unit and while has good range, it's not as powerful as the 30. The units power down when not transmitting and power up when transmitting. I find them very reliable and UART so pretty easy to use with a Teensy. Transmitting a struct is easy and lets you send any combination of int, floats, bytes

I have a library for them and a YouTube vid showing usage.

https://github.com/KrisKasprzak/EBYTE

https://www.youtube.com/watch?v=hMjArKGucFA
 
Oh wow that is good to hear. I definitely thank BriComp for pointing me in the right direction and certainly you for the vote of confidence. This is good to know that these products work as advertised. I like the xxx30 and really do not care at the 800 ma of current as it will only be transmitting like every five minutes tapping the solar bats that are like 50 ah. I actually like the over kill as most everything i do is overkill hahaha!. the fact i don't have to worry I am to far away is most comforting plus i can ramp up the data speed if i need it as the house is only 1,000 feet from the solar array.

I have downloaded all the associated files and am going over them now. I will watch your vid and look at your code. I must ask you is this code different from the one supplied by BriComp and or EBYTE Master files???.

Regards,
Marathonman
 
There seems to be some confusion.

The E32, E22 and E220 are all Ebyte modules.

The E32 is the original. Then came the E22 which was said to be improved over the E32. This (the E22) was said to have intermediary hopping capabilities. That is remote transmits, this is picked up by an intermediary and re-transmitted to the final station or another intermediary. Judging by the number of libraries that exist for this module, this feature is not fully understood or used. Then came the E220 as a lower cost version, over the E22, without the hopping feature.

Any one of the modules will suit your requirements, although the E32 seems to be harder to find for sale now or is hideously expensive.

Here in the UK I find that the easiest way to purchase these modules is via Amazon.

The other decision you have to make is as to which frequency you wish to transmit or receive on. 434MHz, 868MHz or 900MHz. The latter two frequencies now seem to be combined into one spread spectrum module. So the decision is 434MHz or 868/900 MHz modules.

If I were making this decision I would search amazon for EBYTE LORA UART followed by the frequency. In my case I search for EBYTE LORA UART 868. That throws up the E220-900T22D at £5.15 or the E22-900T30D at £11.33.

Changing the search to EBYTE LORA UART 434 only throws up the E22-400T30D at £10.43. I cannot find any Ebyte 868/900 MHz E32's.

If you choose to use the E32 then Kris's library is the way to go. If you choose either the E22 or E220 then I have libraries based on Kris's which handle those modules with their enhanced features. I also have a modified version of Kris's library for the E32 which makes changing the UART speed much easier.

I would suggest that the E32 "may" be on end of life. That is just a guess on my part judging by the number of E32 parts that seem to be available.
 
Back
Top