I have a few of the first TTGO Lora boards shown above and the LED is on pin 2. This is the first board not the 32 v1 or 32 v2.
The important thing seems to be that both sender and receiver have the same orientation.
I performed the 8.7km range with horizontal orientation.
However it seems also that it is better theoritically to have a vertical orientation with the “hot” side pointing up to avoid “grounding effect with the earth”.
Both boards are using the same ESP32 Expressif chip.
Datasheet is saying this:
Each digital output pin is associated with its configurable drive-strength. Column “Drive
Strength” in Table IO_MUX lists the default values. The drive strength of the digital output
pins can be configured into one of the following four options:
• 0: ~5 mA
• 1: ~10 mA
• 2: ~20 mA
• 3: ~40 mA
The default value is 2.
The drive strength of the internal pull-up (wpu) and pull-down (wpd) is ~75 µA
OK, so for 100 mA peak, I need something else… Do you know an efficient module that would allow me to toggle energy coming directly from the 3V3 pin and can power that?
no don’t change the module.
Just add a simple mosfet on the IO pin as on this schema:
ths “switch” is done by your IO pin is commands the gate of the mosfet which itself acts exactly as a manual switch
Please note that:
The maximum output current (sink/source) of the ESP32 is 12mA.
Well you are surely right…
I must say that this datasheet with the “drive strength” is somehow misleading
Thank you for the link
Correct, that information is not very clear.
From above link: “We’ll need to make the drive strength / DC current distinction more clear in the datasheet anyway.”
Please correct your post to prevent that others damage their board due to incorrect information.
Caveat: I am not an electronic engineer!
Usually a simple circuit using a bipolar NpN transistor such as 2N3904 (with a suitable resistor) on your output pin driving a low voltage (voltage to turn fully on to low resistance) P-Channel logic level mosfet to power your sensor load. I will test a FDN338P mosfet for this application as soon as they come in the post. You could drive all of your sensors on a power bus using this combination.
How about the range on your tests?
Has anyone got good range (I’m talking hundreds of meters… possibly km!) from a TTGO V2.0 yet? or alternatively, anyone used any of the following and got good range:
- LoRa32u4 II 868MHZ Lora Module Development Board IOT LiPo Atmega328 SX1276 HPD13 - like here: https://goo.gl/g15B56
- Adafruit Featherwing - https://goo.gl/wLy5qB
Just looking for a cheap way to get a node to map TTN coverage (using TTN mapper, so don’t need GPS or anything) - and don’t really have the appetite for DHL-ing several different components from different continents (in South Africa it is hard to wait for the post office)
i didn’t test the TTGOv2 outdoor yet, but from within my home it connects to a gateway on a tower in about 2km distance.
first of all, thank you for this very informative thread on the Heltec and TT2Go boards.
I have two Heltec boards and a TT2Gov1 board, and got them all running with the Arduino IDE (sending and receiving LoRa packets directly and with the Radiohead library).
But, since I do not really like this environment, I tried to get it to work with the ESP-IDF environment. While I know how to integrate the Heltec-Arduino core as a component with the build environment of ESP-IDF (i.e., as a component), I cannot get it to work. My first and unsolved problem is that Serial.println() does not work, but prints only gibberish (program reduced to println statements in both setup() and loop()). If I use the created binary and put it on a normal DOIT board it prints everything fine, but if I use the same binary on a Heltec board, it prints only unreadable characters.
So, what am I missing? I could continue using the Arduino IDE, but I would be very happy to understand what I am doing wrong in the ESP-IDF environment.
Thanks for that. So I think that is answered
- TTGO V2 does have reasonable range.
Is that with standard antenna or something better?
Thanks guys. It seems the ttn-abp code is working now; no errors occur and it gets into the loop(). Now the serial monitor shows the following:
5038011: EV_TXCOMPLETE (includes waiting for RX windows)
9311073: EV_TXCOMPLETE (includes waiting for RX windows)
13584761: EV_TXCOMPLETE (includes waiting for RX windows)
No data arriving in my TTN application (yes, device properly registered ).
NB: de otaa code geeft EV_JOINING en hier lijken de berichten ook niet aan te komen. Radio instellingen lijken juist te zijn (868).
are you recieving the packets on your gateway?
Did you check, that there is no payload converter in you app?
You may double check if the settings in the software do properly match the ones configured in the TTN Console (and in proper byte order).
You could also try to reset the framecounter of the device in the TTN Console.
Should there be a payload converter?
What would be the proper byte order: lsb or msb?