NO!
First that pinout diagram is full of errors and second LoRa_IRQ on that diagram is DIO0 NOT DI01.
Then this wiring is correct?
[wrong wiring deleted]
Do NOT use above incorrect pinout diagram.
For TTGO LoRa32 V2 do not use LilyGo’s pinout diagram from their GitHub location. It is full of errors and has not been updated for months.
Please read the start topic Big ESP32 + SX127x topic part 2 first (and the rest of the thread 
).
All information about wiring is detailed in the start topic. You can also find my updated LoRa32 V2 pinout diagram (TTGO LoRa32 V2.0 Pinout v3.0.pdf) there.
On my updated ‘LoRa32 V2.0’ pinout diagram you can see pins DIO1 and 33 (GPIO33). Those are the ones that should be connected.
Note: For any TTGO LoRa32 V2.1 be careful with LilyGo’s pinout diagram for TTGO LoRa32 V2.1. It is from an older version and totally incompatible with LoRa32 V2.1 release “V1.6”. I am unaware if it is compatible with release “V1.5”.
OK, I got it and deleted the wrong wirings above. To be clear, here is the correct wiring, it works.
1 Like
Did you event get .STL files or other files
possible to use for printing on a
Forgefinder 3D printer ?
Please share 
Would like to make some changes to box
and print/share
BR
T
I did the following wiring but I don’t think it’s right. Because the “Lora busy” error persists.
[wrong wiring remove]
Again: read the <board.h> file and double check your wiring. On TTGO T-BEAM for paxcounter GPIO32 is used for DIO1, not GPIO33 (see .h file). You need only 1 wire.
OK, thank you. This is the correct wiring and it works like a charm. I added an OLED display to see what happens.
I just got a new TTGOT-Beam T22_V05 20180608
This board has connection between IO33 and Lora1
if I change one line in ttgobeam.h like this
//#define DIO1 GPIO_NUM_32 // Lora1 <-> HPD13A IO1 // !! NEEDS EXTERNAL WIRING !!
#define DIO1 GPIO_NUM_33 // Lora1 <-> HPD13A IO1 // T22_V05 20180608
will that work, or do I need to make changes in other parts of the code too?
Yes, it should work this way, but on previous version of T-BEAM i had issues when DIO1 was controlled via GPIO33, that’s why i changed it to GPIO32 what solved the issues.
Just try it and please let us know your result here.
OK, I realized that I have the same board. I changed the line in ttgobeam.h from #define DIO1 GPIO_NUM_32 to #define DIO1 GPIO_NUM_33 and it works without special wiring!
Once more we see, that chinese manufacturers tend to change versions of their hardware suddenly and without transparency. The result is that different versions are on the market at the same time.
Another question about the boards:
I now have 3 boards with paxcounter running: ttgov2, ttgov21 and ttgobeam. They all work in the same TTN application. I enabled Cayenne integration and Cayenne LPP payload format and added all 3 in Cayenne. But none of them is seen in Cayenne dashboard, it seems that data didn’t reach Cayenne.
What could be wrong?
This is an interesting topic. While first customers are basically taking a risk with the first versions, it also adds to the confusion.
But on the other hand, I quite enjoy the fast pace progress.
I tend to favor the latter, but also I must admit I am not a dev.
did you activate cayenne integration for the TTN application with the paxcounter devices?
Yes I did. Maybe it’s an issue with the Cayenne website. I’m just chatting with them. Monday, they will bring an update.
They say, the payload of TTGO T-Beam is throwing an error.
Payload of TTGO LoRa32 V2.1 seems to be ok.
Payload of TTGO LoRa32 V2 can not be decoded, same as of T-Beam.
Supplement: I got an e-mail from Cayenne regarding TTGO V2 and TTGO T-Beam as follows:
“[…] it seems there is some error in the format of the payload we are receiving. Here is some documentation for the format. https://mydevices.com/cayenne/docs/lora/#lora-cayenne-low-power-payload […]”
The payload converter code is the same for all boards.
But only T-Beam send gps data, maybe this causes the error.
You’re welcome to make a pull request to solve this. It’s open source. Please contribute, not only consume, if it is possible for you.
I would like to do so. But I’m not able to do because I’m not familiar with this.
Edit: No need to search for the error anymore! It was my fault, I’ve forgotten to set #define PAYLOAD_ENCODER to 3 in paxcounter.conf for two devices (shame on me!). Now all three devices are in Cayenne.
But with this configuration t-beam does several (sometimes a lot of) reboots before joining and transmitting data. It seems like the BLTH and WIFI modules are down and couldn’t initialized.
The cause of the reboot should be sent to the Serial Terminal by the ESP32.
I dont know if its your issue, but the ESP32 is prone to brown out resets when the WiFi turns on, a good deal of care needs to be taken with the power supply design.