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.
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.
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.
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.
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
Serial port /dev/cu.usbmodem54240346091
Chip is ESP32-D0WDQ6-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
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.
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.