TTGO T-Beam topic

There is no doubt lmic works. The trick is to find the proper version of lmic for the T-Beam.

There are a pair of local dudes using ttnmapper with T-Beams on 915 MHz here in Canada. They gave me their copy of lmic, or so they thought… It produced a compile time WARNING saying board (T-Beam) not supported. Its only a warning. The IDE compiles the program source. Running the code, it loops in an error state: board not supported.

The local dudes have lost code control. They understand they are using one version of lmic, the version they gave me. In fact their build is using a t-beam compatible version picked somewhere on their system during the build process. They are not using what they think they are using, the code they gave me. No code control.

Now the t-beam is an elegant board featuring an esp32 with WiFi, Bluetooth, a GPS, a sx1276 Lora transceiver, and li-polymer battery socket complete with associated charging circuitry. I like. I like it a lot.

I think this version is working good with my ttgo-tbeam v7 and oled display.
I search a log time for a working solution to use it with ttn mapper without paxcounter.

I want a small software for arduino ide without the interference of wifi and bluetooth.

I think the biggest problem i had is to understand that i should use ABP activation and
disable the “frame counter checks” in TTN Backend (Device section).

Alternativeley you can tweak the software to reset the counter. I think the software is generaly broken in this part because i found no software where the tracker work on the second day after flashing the keys.

But have a look at the TX intervall because of the fair frequency use policy.

I use the version of LMIC that “ships with” PlatformIO with my T-Beam. You should just need to change lmic_config.h. However, there is really no code control there either, since you are assuming whoever is in charge of the LMIC version doesn’t break it.

I added AXP192 experimental code to the paxcounter software, you find it in the development branch:

Could you please test on your device? Thanks.

1 Like

@Linar can you post the complete schematic here? Would be quite useful for software development. Thanks.

https://github.com/Xinyuan-LilyGO/TTGO-T-Beam/blob/master/schematic/T_BeamV1.0.pdf

2 Likes

Hello,

I’m a newbie so I apologize for the fool question. What board should I choose in the board list of Arduino IDE when I program the ttgo t-beam?

Thank you

I use the “T-Beam” board.

First you have to update the board list and add: https://dl.espressif.com/dl/package_esp32_index.json

Thank you very much. Another doubt is: “should I modify anything in the " Lora-TTNMapper-T-Beam.ino” file in order to make ttgo t-beam work as TTN Mapper node? (I have already put in config.h file the Nwks and App keys and andress of my device.

Depends on your T-Beam “band”.
My code was tested with 868 Mhz T-Beams since this is what is possible in my country.
For 915Mhz have a look at what someone submitted : https://github.com/DeuxVis/Lora-TTNMapper-T-Beam/pull/11/commits/23bd9b04bb335daf32a2c8aafc485cd54d278381#diff-11634892e8a26e85cab0ec7c5fda9c8bR165

First of all thank you for the answer. I’m from Italy so the band is the 868 Mhz. The problem I observe is that when I open the serial monitor in order to see if device is working or not, “dirty” byte are printed such as that in the figure. serial_monitor

The baud rate in the serial monitor (9600) does not match the baud rate in the sketch you linked to (115200).

Is there a particular reason why the baud rate in the sketch was to 115200?

No particular reason, it’s just the most common value for me.

Nope, but the monitor needs to use the same one as in the sketch.

Lots of ??? is a classic symtom of baud rate miss-match.

After matching, the serial monitor prints: “No gps Fix” and removing the comment in the else function of https://github.com/DeuxVis/Lora-TTNMapper-T-Beam/blob/master/gps.cpp file the message in the serial monitor becomes:
No gps Fix.
location valid: 0
location age: -1
hdop valid: 1
hdop age: 549
hdop: 9999
altitude valid: 0
altitude age: -1

Finally, making the variable “bool gps::checkGpsFix()” always true the massage printed on the serial monitor is the following:

ets Jun 8 2016 00:22:57

rst:0x5 (DEEPSLEEP_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:928
ho 0 tail 12 room 4
load:0x40078000,len:8740
load:0x40080400,len:5788
entry 0x4008069c
TTN Mapper
Valid gps Fix.
Lat: 0.000000
Lng: 0.000000
Packet queued
EV_TXCOMPLETE (includes waiting for RX windows)

not sure what the question is? which version of board do you have?

Then maybe the GPS does not have a fix ?

Is the GPS outdoors with a good view of the sky ?

For “jzed”, the version I have is the T22_V07 20180711.
For “LoRa Tracker” the GPS was indoor.

Yup the GPS won’t get a fix inside.

What I usually do to debug is use a battery to power up the board outside - under sky - and wait until it get a fix then move it inside. If your walls are not too thick the GPS could continue working.

Otherwise, use a laptop and work outside :slight_smile: