thanks.
<rant-mode>
Some examples of inconsistencies in LilyGO/TTGO documentation.
In this case for TTGO LoRa32 V1.3 (aka LoRa V1.3, aka T3 V1.3).
Part of the circuit diagram:
Notice that the LoRa32 V1.3 circuit diagram is actually placed in the T-Beam repository which is a totally different product. The information is not where one expects and will try to look for it.
LilyGo also have a website which unfortunately hardly provides (better detailed) information about their (LoRa) products and is again made difficult to find.
What the above says:
SX1276 Reset is connected to ESP32 GPIO14 (diagram)
SX1276 Reset is connected to ESP32 GPIO23 (textbox)
Only one of these is correct. Now you figure out which one…
The information in the textbox shows “IO23 = IRQ/RESET” but IRQ and Reset are not the same and do not use the same pin!
What is often incorrectly called IRQ on these boards is actually the DIO0 pin from the LoRa chip which on TTGO LoRaWAN boards is connected to the ESP32’s GPIO26 pin and not GPIO23.
According to the circuit diagram:
Display D1 is I2C SDA = ESP32 GPIO21
Display D0 is I2C SCL = ESP32 GPIO22
However, in practice this appears not to be true,and instead:
SDA = GPIO4
SCL = GPIO15
The same repository contains a product link for the TTGO LoRa32 V1.3 that points to the LilyGo shop on AliExpress (in Portugese!).
The page contains a pinout diagram for the TTGO LoRa32 V1.3 (aka T3) that contains the same incorrect?? I2C pins information:
A month ago I copied the same pinout diagram and then it showed:
As said before, in posts from others SDA in pratice appears to be GPIO4 and SCL appears to be GPIO15. Which is as shown on the pinout diagram from a month ago, while the pinout currently shown on their shop’s product page shows SDA = GPIO21 and SCL = GPIO22.
I don’t have the board so I am unable to verify it.
The different pinout diagrams do not show a document version or document date.
What to believe here? Who / what is correct and when?
Without actually having the boards to verify it is impossible to know which information is correct.
Will we soon see a batch of new boards with same version number where the IC2 pins have suddenly changed?
Deficient documentation and contradicting information like above make it hard to keep information in this topic up to date and reliable (and this hasn’t improved much over time).
It also does not give much confidence in these products. If essential information and documentation keep having/getting errors and inconsistencies then why would one expect the products themselves and their design to be any better?
</rant-mode>
Do you have to set anything in software to set the AXP chip to allow the On button to work?
I’m aware it has to be held down for a few seconds, so it’s not that. Nor is it a flat battery.
It might be useful to provide a little more information. 
What device is this about?
Do you mean AXP192 on a TTGO T-Beam?
Which version?
(The T-Beam topic might even be a better place to post it.)
What code have you used to initialize the AXP?
Yeah, not fully awake, will try there.
If you mean the user button connected to GPIO38:
You will need to setup the 3.3V line on the AXP first to make the button work.
See my post in the T-Beam topic.
No, I meant the PWR button, now I’ve looked at it again. Still not awake so I’ll leave it alone and ask on the other topic later on after the coffee has cut in.
I have a TTGO LoRa32 V1.0, I want to use it with DTH11 to measure temperature and humidity, but I have problems because I can’t find an example with the programming code to make it work, because I don’t know which version works for the working frequency ( 902-915 MHz) and what version of the ILMIC library should be used for the node to work in ABP mode for TTN V3 ???
Most information is already available at the start of this topic. Just read it. The library advised to use is also the library most suitable for V3.
It also describes which examples to start with, (but those do not include use of a temperature sensor).
Use of ABP with V3 is possible but not preferred. Use of OTAA is preferred.
Check/search the forum and ‘V2 to V3 upgrade’ category for important information about how to migrate devices to V3.
Hi there,
Im new to this forum. I think I got a simple question.
Can you implement OTAA/ABP comms with a TTGO/Heltec (etc), the LMIC Library and the device EUI, app key etc from another server/host apart from TTN? Or does it just works with the TTN network?
Thanks in advance <3
You should be able to use the TTGO on a private (non TTN) network, but perhaps thats a question for the support forum of the private network you had in mind,.
The problem is that there are different versions of the lmic library. I have tried some and they give me errors, in addition to making several changes in working frequencies (in the sub libraries), among other things, that is why it is my question to know if someone already has a system with this temperature sensor ( very common) to be able to replicate more easily and to avoid errors. Thanks
Heltec devices are now available in the LoRaWAN Device Repository
Heltec has added their LoRa devices to the LoRaWAN Device Repository.
This means that these devices can now be selected from the device list when adding a new device in the V3 Console.
2 Likes
The latest version of Arduino Core ESP32 now has additional boards added. Finally also additions for TTGO LoRa32 V2.x.x boards:
- ttgo-lora32-v2
- ttgo-lora32-v21new
For Heltec boards the Wireless Stick and Wireless Stick Lite were added already earlier:
- heltec_wireless_stick
- heltec_wireless_stick_lite
As usual, don’t blindly trust board definitions in the Arduino cores:
I noticed an error in the ttgo-lora32-v21new BSP:
#define LORA_RST 12 // GPIO14 - SX1276 RST
But uh, oh, LoRa reset for this board is connected to GPIO23…
(Well, at least according to LilyGO’s pinout diagram for this board.)
And similar error in the ttgo-lora32-v2 BSP:
#define LORA_RST 12 // GPIO14 - SX1276 RST
The same ‘12 commented as 14’. However, in reality LoRa reset on the
v2.0 board board is NOT connected to any GPIO but to EN/RST of the ESP32…
I wonder what people are creating these board definitions.
How hard can it be to check consistency between code, comments and reality and correct any errors before this stuff gets released globally to thousands of users?
The topic-start has been updated with the LMIC-node example and a link to the pinout-diagrams repository which contains pinout diagrams for most of the boards described in this topic. In addition some notes were added for The Things Stack V3.
2 Likes
Hey guys, great thread here!
sadly im trying to connect my TTGO Lora32 v1.0 to TTN, without success so far. I hoped i would get the new example from the LMIC-node to work but this is without success so far. A single channel gateway i am running here is receiving something that doesnt look completely wrong. I know the TTGO Lora32 isnt listed in the supported devices. Since the lmic pins are the same as on the Heltec Lora32 V1 i gave it a try. I suppose some configuration is still wrong since packets are received by the gateway but not correctly forwarded to the network?!
I use ABP from LMIC-node example since i am using a single channel gateway in my flat. With OTAA i got no succcess either. There should be some Gateways not too far away, but for testing purposes i decided to go with ABP and an own 1-Ch-Gateway.
This is the received packet as shown in the gateway console:
Maybe someone of you can see waht im doing wrong. thanks a lot in advance
{
"name": "gs.up.receive",
"time": "2021-10-16T09:34:08.455140041Z",
"identifiers": [
{
"gateway_ids": {
"gateway_id": "b8f009ffffcca210"
}
},
{
"gateway_ids": {
"gateway_id": "b8f009ffffcca210",
"eui": "B8F009FFFFCCA210"
}
}
],
"data": {
"@type": "type.googleapis.com/ttn.lorawan.v3.UplinkMessage",
"raw_payload": "QOFECyaAAwAKVIab8UMu",
"payload": {
"m_hdr": {
"m_type": "UNCONFIRMED_UP"
},
"mic": "m/FDLg==",
"mac_payload": {
"f_hdr": {
"dev_addr": "260B44E1",
"f_ctrl": {
"adr": true
},
"f_cnt": 3
},
"f_port": 10,
"frm_payload": "VIY="
}
},
"settings": {
"data_rate": {
"lora": {
"bandwidth": 125000,
"spreading_factor": 7
}
},
"coding_rate": "4/5",
"frequency": "868099975",
"timestamp": 161729712
},
"rx_metadata": [
{
"gateway_ids": {
"gateway_id": "b8f009ffffcca210",
"eui": "B8F009FFFFCCA210"
},
"timestamp": 161729712,
"rssi": -113,
"channel_rssi": -113,
"snr": 2,
"uplink_token": "Ch4KHAoQYjhmMDA5ZmZmZmNjYTIxMBIIuPAJ///MohAQsJmPTRoMCJC5qosGEMKK/dgBIICf3r7aBA=="
}
],
"received_at": "2021-10-16T09:34:08.455034178Z",
"correlation_ids": [
"gs:conn:01FJ472WX5SW5A0DHHMFAXWKYC",
"gs:uplink:01FJ477527VN20ZQ7PJ0C9AWQC"
]
},
"correlation_ids": [
"gs:conn:01FJ472WX5SW5A0DHHMFAXWKYC",
"gs:uplink:01FJ477527VN20ZQ7PJ0C9AWQC"
],
"origin": "ip-10-100-12-248.eu-west-1.compute.internal",
"context": {
"tenant-id": "CgN0dG4="
},
"visibility": {
"rights": [
"RIGHT_GATEWAY_TRAFFIC_READ",
"RIGHT_GATEWAY_TRAFFIC_READ"
]
},
"unique_id": "01FJ4775275M22MKG96D7MXAYY"
}We do not support Single or Dual Packet Forwarders. Please disconnect it from TTN and get a LoRaWAN gateway NOT a LoRa ‘Gateway’ - one that fully supports 8 channels, across the full spread of SF’s or more. These are disruptive to other users on the network (use Forum search) and cause issues of the type you may be experiencing yourself. Come back when in range of a LoRaWAN gateway or get one for your own use and add to the communities coverage then many here will be able to assist you.
It may be that if the other gateways are really in coverage range then simply scrapping your SCPF will allow them to correctly start servicing your node…
Thanks a lot for the fast reply. SCPF is shut off now.
There should be a few gateways not too far away, but im not sure if the TTGO Lora32 V1.0 has enough range. Ill try to let it run for a while. Should i then try to go with OTAA since this is the preferred way then? Just went with ABP since i’ve read OTAA isnt possible with the SCPF i was using
Thank for this very useful comparison.
Has anybody worked out which peripheral is connected to which bus for the TTGO LoRa V2.1.6? In these pin-out diagrams it would appear that the SD card is connected using its native iterface (CMD, SD0, etc.) but in another pinout for the same board, pinout-diagrams/TTGO LoRa32 V2.1.6 Pinout.pdf at main · lnlp/pinout-diagrams · GitHub, the SD card appears to be connected to a SPI bus. From the choice of pins, it looks like it maybe H-SPI. Which is the definitive diagram?
The SX12xx appears to be connected to V-SPI. Is this the case does anybody know?
I am working on a project that will connect to the board via SPI with fairly tight latency requirements; so I do not want to share the SPI bus with the LoRa activity. Sharing the bus with the SD card (if it actually uses a SPI would be OK as I have control when this would be active.
Any advice would be greatly appreciated.