Hello! I am trying to use ttgo t-beam v1.1 but the only way I could find was using paxcounter project. I would like to write my code as I wish and be able to deep sleep the device, put a button interrupt, connect to TTN and send the data in the format I choose. The paxcounter project let me connect to TTN, but I can’t do what I want because I am not so good at modifying that code (which is very ample). Is there any alternative for this simplist app I’m trying to create? Thanks.
T-Beam versions 1.x have a special power management chip.
For T-Beam specific things I suggest to visit the TTGO T-Beam topic instead.
Paxcounter is rather complex if you only want to write some basic code yourself.
For connecting to TTN you might want to start with the basic examples from the MCCI LMIC library as described in the topic start.
Note that you will have to use the proper pin mappings for your T-Beam version and that you have to enable/configure the power management chip (see T-Beam topic).
First try to get these basics working, from there you can extend the code with support for GPS and other things.
Keep in mind you only connect to TTN once and need to store the ‘connection’ information. You can not join every time you want to send data because you will run out of join opportunities.
I appreciate very much your answers! Thanks for the fast replays! Before trying the Paxcounter (the only way I succeded to connect to TTN) I tried LMIC library but with no succes. Now after you suggested me, I started on git an issue because I can’t succed in running the ttn-otaa.ino example from LMIC. Have a look here please! Thanks.
In this topic you have not provided any information whatsoever so I’m not sure what you expect from filing an issue for MCCI LMIC on Github.
Your issue will very probably not be caused by a shortcoming in MCCI LMIC.
If you want to get any useful input on this forum you will at least have to provide sufficient detailed information about your problem, what exactly is not working, what you have tried, what sketch you are using, what settings and pin mappings you have used, what error messages do you get, etc.
You can use the search option to find any relevant information for your issue on the forum.
Also don’t paste links without any further description (e.g. Github).
Users on the forum don’t like having to go elsewhere to read your information.
Try the steps already described on the forum.
If something is not working it is usually ones own fault (e.g. incorrect settings used, typo’s, not carefully following steps provided) and not because a bug in examples, libraries etc.
And if you do not setup the power management chip on a T-Beam v1.x correctly then it will not connect to TTN.
I just started my first baby steps with LoRaWan after buying two Heltec WiFi LoRa 32 V2. Living in an urban city the nearest GateWay is out of range and most likely is the standard antenna not helpful. Closer to this gateway I think I was able to connect or at least get a reaction from this gateway. My first working (?) sketch was made with the OTAA.ino sketch from https://robotzero.one/heltec-lora32-lorawan-node/ and solely changing my Heltec/TTN credentials. Found some references in this forum like here likely I should migrate to MCCI LMIC but this was the easiest first attempt;).
Some questions (likely missed reading them in the forum):
- what kind of range can I expect with this Heltec, will a different antenna be an improvement?
- can I continue with this sketch or is diving in MCCI LMIC a better option?
How far ‘out of range’?
If a different (better) antenna will make any difference depends on different factors, like distance, antenna placement, obstacles etc.
You may possibly need to setup your own indoor or outdoor gateway.
Improvements are possible but depend on different factors, one being the antenna’s included with your Heltec boards. You have not given any details about your antennas. The type of antenna’s included will depend on region and probably on time of production, time and location of purchase and availability.
Also have a look at:
If you want to do and learn anything more than just running someone else’s sketch then reading documentation and learning the essentials will be useful.
This topic (start at the top) and other topics on the forum contain useful information to help getting you started.
1 Like
@bluejedi thanks for your response.
- I live 1,3 km from this gateway, a field trip into the cold gave a positive reading at 400 meters (positive as in joining - joined - sending). This was done with the standard antenna sold with the product. I am not able to check the quality of this antenna and to determine this is a fair result with on the other side an indoor gateway.
- Personally I prefer a good working sketch as starting point to make your own variations but also agree with a more or less RTFM approach (thanks for the antenna topic); think the answer is yes on my question “is MCCI LMIC a better option?”
Maybe, maybe not. The LoRaWAN source used by Heltec is from the original Semtech code base, the people that invented LoRa.
The MCCI LMIC is the continuation of code that has passed through many hands over the years and has proved it’s worth for smaller MCU’s but still has it’s foibles.
Depending on what you are trying to achieve depends on where you go next. If you want to experiment with devices at the LoRaWAN level, then dig in to both code bases. If you want to deploy devices with some useful sensors on, which requires a fair bit of firmware development & testing and get stuck in to the data presentation & analysis, then I’d stick with what’s working. You can of course do both if you have a lot of time on your hand or a really big brain, preferably both.
1 Like
That is a fair result. For a gateway with the antenna indoors distances differ from <100m to a few kilometers but mostly 100-600 meters in my experience. (A lot depends on the materials used in the building)
1 Like
Friends:
I am using a TTGO v1 with a DTH11 sensor to send temperature and humidity, I use the MCCI_LoRaWAN_LMIC library
with version 1.5.1, using the example ttn-abp-feather-us915-dht22.
I use the V3 of TTN for the new changes for 2021.
I have 2 gateways (one channel) and both the sending node and the receiving node (903.9 MHz) channel 0 are configured on the same frequency.
However, I get these errors and the data is not uploaded to the platform.
Could someone help me, maybe something needs to be changed in the library or in the TTGO programming? 
I’m sorry for you but we do not support single channel packet forwarders on the forum.
See: Single Channel Packet Forwarders (SCPF) are obsolete and not supported
1 Like
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.