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

So after doing a little research into ttl and ttl compatible devices i have come to this conclusions.

Since we all know the Teensy 4 and 4.1 are 3.3 volts and basically anything higher then 3.6 on any one pin will kill it. "BUT" if you are trying to interface the Teensy to a ttl compatible device that is powered by 5 volts that means the input is considered high above 2 volts. If this is a one way signal from the Teensy to the ttl compatible device like i am doing to a ttl compatible H bridge driver then the Teensy will work without a level translator or level shifter. Remember this is from the teensy to the ttl compatible device not from the ttl compatible device to the Teensy.
So why do I know this, because I have a Teensy 4.0 attached to 8 Nexperia 74VHCT595 8 bit shift registers (ttl compatible) powered by 5 volts that are logic high above 2 volts and work just perfect.

So the conclusion of this post is Yes i can hook up a Teensy 4 or 4.1 to any TTl compatible device if it is one way from the Teensy to the ttl device without a level translator or level shifter.

So the conclusion of this post is Yes i can hook up a Teensy 4 or 4.1 to any TTl compatible device if it is one way from the Teensy to the ttl device without a level translator or level shifter.

SO according to this web site i am right a 3.3 volt Teensy output can interface with a 5 volt ttl device input but not from a 5 volt output to the Teensy 4/4.1 input without level shifting.
https://hackaday.com/2016/12/05/taking-it-to-another-level-making-3-3v-and-5v-logic-communicate-with-level-shifters/#:~:text=If%20you%20are%20lucky%20the,without%20any%20extra%20hardware%20required.

Regards,
Marathonman
 
If anyone is interested the E220-900T30D is only 7 bucks on Ebytes Alibaba page. I think that is a very good price.
https://www.alibaba.com/product-detail/Ebyte-868MHZ-LoRa-Module-Original-LLCC68_1600190488624.html?spm=a2747.manage.0.0.1a7f71d2vC7RxZ#

E220-900T22D is on sale at 4 bucks https://www.alibaba.com/product-detail/Ebyte-Lower-Power-Consumption-LLCC68-LoRa_1600190604082.html?spm=a2747.manage.0.0.3f9c71d2mFNl2Z

Another thing is after reviewing Both data sheets on the 900T30D and the 900T22D both chips are powered with 5 volts but the ttl level I/O is at 3.3 volts so NO level shifter is necessary. Which means direct communication with the Teensy 4 and 4.1 I/O.

Regards,
Marathonman
 
Last edited:
Here is a quote from an Ebyte engineer just this morning.
"There is no need to use a 3.3 to 5 volt level translator. The AUS, RX, M0M1&2 of the module can be connected to the MCU."

SO you see a little research and asking goes a long way.
Regards,
Marathonman
 
All the program does is error and will not compile. It says can't find EBYTE E220.h even though it is right there in the folder.
 
As long as it doesn't push 5V to the Teensy and recognizes 3.3V as high.

For the build error - not sure of the software in use - posting the verbose build output might indicate the trouble.
 
There is something wrong with Bricomps E220.h file so I replaced it with one i found through the library manager I replaced it with LoRa_E220.h and it has no problem finding it now. I just wanted to find out if the ino would even compile.
Thank you for the replay Defrag.
 
I compiled the Receive.ino in the EBYTE_E220 examples without any problem. The library was found just fine.
Be aware that the library you have chosen to use was the one that I started with (the E32 version).

I found that in my usage that it would work fine, then for some unknown reason it would stop working (communication would stop or be problematic).
It has some very peculiar/complex C++ usage, which may, or may not, be the problem area.

That is when I found the Kris Kasprzak E32 library. I had no problem with this library, it worked fine on the E32.
I modified this library for the E220 and E22 which required different configuration methods.

Good luck with the Lora_E220 library.
 
Last edited:
Thanks now i am completely confused as the library specifically says LoRa E220.h not E32. After hours of attempting to compile with your library I deleted it and used Renzo Mischianti's library and I have no problem with it seeing the file.
 
I read the damn thing and yes i understand that that file is screwy but so is your file because my system will not recognize it period!. I have tried for over a week to get your file to work and it always says file does not exist even though I added it through the library manager and it is clearly present in the library folder as is EBYTE E220.h.
 
I read the damn thing and yes i understand that that file is screwy but so is your file because my system will not recognize it period!. I have tried for over a week to get your file to work and it always says file does not exist even though I added it through the library manager and it is clearly present in the library folder as is EBYTE E220.h.

@BriComp's message says "EBYTE_E220.h" (with an underscore). Yours says "EBYTE E220.h" (with a space). Could that be the problem?
 
I have tried everything short of renaming the file which I guess I will try. At this point in time I will try anything. I add it directly from the library manager so how can it be wrong???

Edit;
Code:
ResolveLibrary(EBYTE_220.h)C:\Users\Donald\Documents\Arduino\libraries\EBYTE_E220-main\Examples\Teensy\Send\Send.ino:21:23: fatal error: EBYTE_220.h: No such file or directory

This is after reinstalling the file just like all the times over the last week.
 
Last edited:
Seems the file on git hub was updated two days ago.
Code:
Alternatives for EBYTE_E220.h: [EBYTE_E220-main@5.0] Resolve Library(EBYTE_E220.h)-> candidates: [EBYTE_E220-main@5.0]

After deleting files in the Appdata library file it found the file after reinstalation so after a week of frustration it finally seen the file whew!
 
Seems the file on git hub was updated two days ago.
Just changed some erroneous comments in the library, such as from this
Code:
// parity bit options (must be the same for transmitter and reveiver)
to this
Code:
// parity bit options (can be different for transmitter and reveiver)
Seems like i have miss-spelled reciever :- reviever as well. There will be a change to correct that but there is no way that it will affect the performance of the library.
I thought you were using the LoRa_E220.h library!
You might find that less troublesome for yourself!
 
I thought you were using the LoRa_E220.h library!
You might find that less troublesome for yourself!

You said the other was squirly so I went with your modified Kris Kasprzak. It finally showed up, now i just need to finish the rest.
 
Back
Top