Hello,
I’m thinking of using a TTGO T-Beam to track the position of my car.
I would therefore like to ask, what is the best way to do this at the moment?
So far, I have found these two projects:
Which one do you think is better? Or should I use something else?
GSM or an SD Card.
Route tracking requires far too many uplinks to stay within the Fair Use Policy and rather presumes you are in range of a gateway, which doesn’t really have anything like the coverage of the mobile networks.
But then you may have a use case that hasn’t been done to death on the forum already - what did you have in mind?
Thank you for answer.
I mean car security. I want the tracker to send the location once in a while so I can check that the car is in the right place.
If the car is lost, I can find it.
I know there are limits to the fact that LoRaWAN network coverage is not 100%.
I’m getting acquainted with this technology and this is a use case that sounds very good to me and I would like to try it.
This is not a professional application where I need maximum reliability.
Not sure I understand that - you could just have a movement detector to alert you that the car has moved. And unless you live in some high crime area, it’s not going to happen very often.
I’d highly recommend starting with a simple sensor as there’s a fair number of moving parts to this sort of project.
The TTNMapper code is a bit TTNMapper specific. The other code would be a good starting point, bearing in mind that it will be coded for v2 and we are on v3 now,
I’d start with a board that LMIC-node supports in the TTGO with GPS range and build things up from there. It’s well documented, supported on here and is v3 friendly.
@roelwolf made a fork of LMIC-node with support for GPS that is tested on the TTGO T-Beam v1.0 board and should probably also work on T-Beam v1.1 (latter is an assumption).
You can find more information about it here: LMIC-node | One example to rule them all - #20 by roelwolf
Note that the GPS extensions are not documented. You will have to check the source code.
Looking for a data sheet for the TTGO T-Beam V1.0, I have searched but Google cant help me, or did I ask the question incorrectly to Google?
Try this: GitHub - Xinyuan-LilyGO/LilyGo-LoRa-Series: LilyGo LoRa Series examples
Here you find circuit drawings and datasheets of the components.
Thanks I did find Xinyuan repository, looking for interrupt pin, Vbat, onboard led … long time since I read circuit diagrams 
After some time of absence I picked up on platformio / paxcounter again and bought a Liligo module on Ali.
For some reason I am unable to flash this unit on my mac. “A fatal error occurred: Failed to write to target RAM (result was 01070000)”
On windows it works.
This unit is a T22_V1.1 and from what little info I can find on the web it is not compatible with M1 mac or Big Sur. I tried it on both an Intel and an M1 mac but both fail. Can’t seem to find anything on that in this topic apart from @bluejed ranting on V1.1 with 1276/1262 chips. So here’s my addition to that. Stay away from V1.1 if you own a mac.
It will be interesting to know what the actual cause is here.
It is less likely that this would only occur with TTGO T-Beam v1. 1 and not with v1. 0 or any of the other (ESP32) boards.
My other boards flash without problems.
Heltec, Tbeam and a Lilygo.
It looks to be a driver issue.
I’ve just installed the CH34XSER driver from this page but no success yet.
See also discussion here.
Wait I just noticed something.
The other Lily that flashes ok is marked T22_V1.1 20191212
And the new one I got last week is T22_V1.1 20210222
Don’t know what the difference is but if the new one didn’t flash on Windows I would think it is defective.
Not very clear.
So you have two different T-Beam V1.1, one dated 2019-12-12 and the other 2021-02-22?
You have tested both on Windows 10 on Intel?
And on two different Mac’s, one Intel and the other Apple M1 based?
For the 2019 T-Beam uploading/flashing from within PlatformIO works on all three OS/CPU combinations?
For the 2021 T-Beam uploading/flashing works on Windows 10/Intel and OSX/Intel but fails on OSX/M1?
(All Windows here, no Mac (OSX))
Aha, two different hardware versions, but both with the same version number v1.1.
If no hardware differences then there would not be a reason to change the date.
If a reason for changing the date then the version should have been changed also.
Bad practice but from LilyGO I’m not surprised about this.
So apparently something has changed but what?
(As usual LilyGO will probably leave that up to the customer to find out).
In the linked discussion the problem was solved.
What is different in your situation from that of the discussion where it was solved?
Are PlatformIO versions identical on all three of your OS/CPU combinations?
Is the ESP32 Arduino Core (‘platform Espressif ESP32’) version (and esp tool) identical on all three?
Possibly differences in Python versions and/or how they are installed? Although this appears less likely because for the 2019 T-Beam it seems to work.
Please don’t post images of text/code/logs. See How do I format my forum post? [HowTo]
What is firmware_ttgotbeam_v3.2.1, is that Paxcounter?
Have you already tested the very basics by uploading one of the standard basic (e.g. blink) Arduino examples to check if that works?
yes and yes
Yes. Both latest os 12.3.1
yes
Works on Windows 10 Intel but fails on both Macs. Old and new mac, Intel vs M1.
What is firmware_ttgotbeam_v3.2.1, is that Paxcounter?
Yes, latest. Compiles and uploads without problems to my other boards - Heltec V1 & V2, TTGO and the other Lily.
Yes I tried that and it also failed. Even the simplest empty sketch crashes with the same fatal error.
Sketch uses 197340 bytes (15%) of program storage space. Maximum is 1310720 bytes.
Global variables use 13084 bytes (3%) of dynamic memory, leaving 314596 bytes for local variables. Maximum is 327680 bytes.
/Users/paulb/Library/Arduino15/packages/esp32/tools/esptool_py/3.0.0/esptool --chip esp32 --port /dev/cu.usbmodem54240346091 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0xe000 /Users/paulb/Library/Arduino15/packages/esp32/hardware/esp32/1.0.6/tools/partitions/boot_app0.bin 0x1000 /Users/paulb/Library/Arduino15/packages/esp32/hardware/esp32/1.0.6/tools/sdk/bin/bootloader_dio_80m.bin 0x10000 /var/folders/j9/0nlsqd4510q298pj_6k7jj1m0000gn/T/arduino_build_165707/sketch_apr29a.ino.bin 0x8000 /var/folders/j9/0nlsqd4510q298pj_6k7jj1m0000gn/T/arduino_build_165707/sketch_apr29a.ino.partitions.bin
esptool.py v3.0-dev
Serial port /dev/cu.usbmodem54240346091
Connecting......
Chip is ESP32-D0WDQ6-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 58:bf:25:04:17:bc
Uploading stub...
A fatal error occurred: Failed to write to target RAM (result was 01070000)
Indeed the other thread reported the problem as solved so I guess I should retrace my steps. I’m suspecting that the driver install was somehow not ok. I’m unsure if there is a hardware difference or that I am somehow wasting everyones time here.
To come back to your remark about my older post about SX1262 based T-Beam:
On SX1262 based T-Beam images on the internet the sticker on the LoRa module clearly shows SX1262 on the bottom, your’s does not so is most probably SX1272.
BTW, IIRC I haven’t seen any posts on the forum where someone mentions they actually have a SX1262 based T-Beam.
I’ve connected a T-Beam T22_V1.1 20210222 to the TTN and learnt the following things:
The USB-serial chip isn’t properly supported on the Mac (neither Intel or Apple Silicon both running Monterey 12.4). I didn’t explore third-party drivers, but just copied the files to a Raspberry Pi, and ran esptool there instead.
a. The Meshtastic firmware appeared to work, though having only one device it was hard to be sure. It doesn’t use The Things Network, so this firmware is only really useful to test the toolchain and basic hardware.
b. I couldn’t get LMIC-node or LMIC-node-gps-tracker to work: the hardware initialization failed, though it wasn’t clear why. I didn’t spend long on them though, and it’s quite possible I was making a stupid mistake.
c. The TTGO T-Beam Tracker worked after fixing the duplicate hal_init issue described above. It connects to The Things Network and successfully logs its location.
I hope this is helpful to anyone trying to get a simple example working.
I know this is a ridiculously old topic but I’m interested in using the external Wi-Fi/Bluetooth port and was wondering if anybody has tried this yet. You mentioned moving a resistor. Is there a place where I can see which one to move and where?
Thanks for any help!
I would suggest to search for the schematic diagram of your version of the T-Beam. Check if the diagram contains any details about this. Next (try to) follow the PCB traces/connections of the onboard antenna, of the U.Fl antenna connector and of the antenna pin from the ESP32 chip. Somewhere they should come close and only one of them will be connected, probably via a 0 Ohm SMD resistor. Looking at my original picture above, I would expect the resistor to probably be on the left side of the U.Fl connector. The (blackish) resistor you see there might have to be soldered in vertical instead of horizontal position, but it could also be possible that the resistor needs to be removed and soldered on the solder islands just below where the resistor is now. But these are just assumptions. You will have to carefully check and verify yourself. In addition the job will require some decent SMD soldering skills.
Good luck.
Thanks so much for the reply! I have been looking closely at the traces and what you’ve said seems to be the case. I will give it a try and see what happens. I’ve bricked more expensive items than this that’s for sure! 
Thank you! I will try it out today. I appreciate the detailed pictures!