TTGO T-Beam topic

YO6OSC · August 11, 2018, 7:14am

hello,
t-beam was working fine untill 2 days ago…i have no data ever since.
i tried to reflash butt still no luck
i get this on the serial monitor…it seems like it is on endless restart loop

Rebooting…
ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (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:812
load:0x40078000,len:0
load:0x40078000,len:11572
entry 0x40078a5c
assertion “entry < ENTRY_COUNT” failed: file “/Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/nvs_flash/src/nvs_page.hpp”, line 188, function: uint32_t nvs::Page::getEntryAddress(size_t) const
abort() was called at PC 0x400d93e3 on core 0

Backtrace: 0x40091428:0x3ffce520 0x40091603:0x3ffce540 0x400d93e3:0x3ffce560 0x400dd72b:0x3ffce590 0x400ddd0f:0x3ffce5b0 0x400dea71:0x3ffce600 0x400dcf0e:0x3ffce660 0x400dca2a:0x3ffce6b0 0x400dcac3:0x3ffce6d0 0x400dcb0e:0x3ffce6f0 0x400d5170:0x3ffce710 0x401150bf:0x3ffce730 0x400da2ca:0x3ffce760

Rebooting…
ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (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:812
load:0x40078000,len:0
load:0x40078000,len:11572
entry 0x40078a5c
assertion “entry < ENTRY_COUNT” failed: file “/Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/nvs_flash/src/nvs_page.hpp”, line 188, function: uint32_t nvs::Page::getEntryAddress(size_t) const
abort() was called at PC 0x400d93e3 on core 0

Backtrace: 0x40091428:0x3ffce520 0x40091603:0x3ffce540 0x400d93e3:0x3ffce560 0x400dd72b:0x3ffce590 0x400ddd0f:0x3ffce5b0 0x400dea71:0x3ffce600 0x400dcf0e:0x3ffce660 0x400dca2a:0x3ffce6b0 0x400dcac3:0x3ffce6d0 0x400dcb0e:0x3ffce6f0 0x400d5170:0x3ffce710 0x401150bf:0x3ffce730 0x400da2ca:0x3ffce760

Linar · August 14, 2018, 4:55pm

One of LilyGO’s AliExpress stores is doing a promo sale of the T-Beam boards right now -

p2-ae-discount-eu

wienkegiezeman · August 27, 2018, 9:43am

Did anybody already find a suitable industrial casing for this device?

bluejedi · August 30, 2018, 10:02pm

I have suggested LilyGo to provide T-Beam with IPEX/UFL connector.
That will make them easier to fit in different types of enclosures and enables more flexible antenna placement.

meshla · August 31, 2018, 11:29am

I just got my Ttgo T-beam, i tried in deep sleep mode, using 44mA, and i think it using power gps module, because it is not power down, and i look in data sheet of Neo-6M-0-001 it is not possible to turn off with out physically connection, i will try later to use on board transistor and one pin of board to turn on off.

BoRRoZ · September 3, 2018, 5:22pm

5 posts were merged into an existing topic: TOOLS for TINKERERS

covraworks · September 5, 2018, 12:08pm

I had a problema with two modules bought on aliexpress… One of them was a 433 instead a 868. Asking about that to the seller , he told me that if you tear off the label, you can see a dot on the chip if it is the 433 versión: t_beam_close

covraworks · September 5, 2018, 1:15pm

I have another issue and I dont know if the problem comes from node or Gateway does.

Gateway: LoRaGo Dock v1.1 single channel from SandboxElectronics with its own firmware LoRaGoDOCK-Gateway with this parameters:
#define _SPREADING SF10
#define _CAD 1
#define _STRICT_1CH 1
Node: TTGO T-Beam 868eu T22-v05 20180608, firmware: TTNMapper-T-Beam from DeuxVis (who helped me a lot).
I had to modify the firmware changing these lines:

LMIC_setDrTxpow(DR_SF10, 14)
and
LMIC_setupChannel(0....8, 868100000, DR_RANGE_MAP(DR_SF10, DR_SF10), BAND_CENTI); // g-band

in order to link with the single cannel Gateway.

Both are up for 14 hours aprox. The gateway uplinks about 1/3 of the data packets sended by T-beamc (it sends 1 each 2 minuts) , but at the TTN console i see a strange behaviour with the traffic data… I can see now in “My device>Overview”
Status: 12 minutes ago /Frames up: 712
In “Gateways>Mygateway”
Status connected
Last Seen 1 minute ago
Received Messages 95
Transmitted Messages 0
But no application data…

Update: Meanwhile I am writing this post, suddenly appears 3 data on my device:

‎15‎:‎03‎:‎487181
payload:B845047FC3C6001307altitude:48.64hdop:0.07latitude:27.9992longitude:-375.1041


‎15‎:‎00‎:‎067121
payload:B845047FC3C6000008altitude:0hdop:0.08latitude:27.9992longitude:-375.1041


‎14‎:‎57‎:‎377081
payload:B845077FC3C2000007altitude:0hdop:0.07latitude:47.66longitude:-401.3185

(wrong gps data…)

Any idea why so few packages appear in the log?

Any idea why gps data is wrong?
function Decoder(b, port) {

var lat = (b[0] | b[1]<<8 | b[2]<<16 | (b[2] & 0x80 ? 0xFF<<24 : 0)) / 10000;
var lon = (b[3] | b[4]<<8 | b[5]<<16 | (b[5] & 0x80 ? 0xFF<<24 : 0)) / 10000;
var alt = (b[6] | b[7]<<8 | (b[7] & 0x80 ? 0xFF<<16 : 0)) / 100;
var hdop = b[8] / 100;

return {
  
    latitude: lat,
    longitude: lon,
    altitude: alt,
    hdop: hdop
  
};

}

PS: I have just read the wire question between GPIO32 and LoRa1… but I get data… then???

covraworks · September 5, 2018, 3:08pm

This function is wrong, I updated and it now works

Still, dissapear and few data packets…

log_gateway

note that webserver is gmt

DeuxVis · September 6, 2018, 8:17am

Hey covra, I’m glad you made some progress.

Can you please rephrase in a single sentence what is the problem you are asking help with ? I don’t understand it clearly.

covraworks · September 6, 2018, 8:55pm

Sorry about that… Actually, I was writing the post while things were happening…

My problem is that very few data packets arrive (sometimes two in an hour) to the server even though the ttgo transmits every 60 seconds and, really, I do not know if it’s from the SF, or the Single channel gateway, or for a bad configuration of the ttgo in the lorawan protocol …

Also, despite having read tons of documentation, nothing appears in the TTMapper (I think it is because TTN does not show the SCGs on the map and therefore can not draw the lines from the gw to the node)

Now I’m testing the integration with Cayenne, to see if, at least, I can show the GPS data there, but I still do not clearly know if I have to modify the code in my firmware to be compatible with Cayenne lpp or TTN does it in its integration … Many questions …

thank you anyway

kersing · September 6, 2018, 9:28pm

TTN knows nothing about your data (format) so they are unable to change your data to lpp format. You need to change your firmware.

Has your node been programmed to only transmit on the channel your single channel ‘gateway’ uses? If not that will explain missing packets. Do you use OTAA? That will set the node to use 8 channels.

For you ‘gateway’, don’t set it to strict 1 channel, RX2 transmissions use another frequency, setting strict mode disables switching to that frequency.

covraworks · September 7, 2018, 10:02am

TTN knows nothing about your data (format) so they are unable to change your data to lpp format. You need to change your firmware.

I was some confused about that, but now I am writing a header file for my gps application based on TTN_arduino>src>CayenneLPPclass

Has your node been programmed to only transmit on the channel your single channel ‘gateway’ uses? If not that will explain missing packets. Do you use OTAA? That will set the node to use 8 channels

First, I use ABP in order to avoid uplink messages (works in that way?) and about node firmware, yes:

… Node: TTGO T-Beam 868eu T22-v05 20180608, firmware: TTNMapper-T-Beam 2 from DeuxVis (who helped me a lot).
I had to modify the firmware changing these lines:
LMIC_setDrTxpow(DR_SF10, 14)
and
LMIC_setupChannel(0....8, 868100000, DR_RANGE_MAP(DR_SF10, DR_SF10), BAND_CENTI); // g-band
in order to link with the single cannel Gateway…

For you ‘gateway’, don’t set it to strict 1 channel, RX2 transmissions use another frequency, setting strict mode disables switching to that frequency

But, I dont need RX2 transmissions… it is a tracker application, the node dont need hear nothing, only needs to send gps data… Am I wrong?

kersing · September 7, 2018, 10:21am

Your ‘gateway’ is providing services to anyone close to it, not only you. So why not stay in-line with the LoRaWAN specification as much as possible given the hardware limitations? Having a 1 channel ‘gateway’ is better than no gateway only if it follows specs (within technical limitations).

covraworks · September 7, 2018, 10:32am

You are fully right but, by now, i am only thinking in debug mode and as far I know, single channel gateways work better in a single SF and again, as far I know, TTN uses SF9 for its RX2 window (my gw only works in SF10) …Maybe should I set node and gw in SF9 instead SF10?

Am I right? Thanks!

kersing · September 7, 2018, 10:57am

You ‘gateway’ listens at a single spreading factor, sending can be at any SF as requested by the back-end as far as I know.

covraworks · September 7, 2018, 11:28am

This is from my gw firmware:

//     Single channel gateways if they behave strict should only use one frequency
        // channel and one spreading factor. However, the TTN backend replies on RX2
        // timeslot for spreading factors SF9-SF12.
        // Also, the server will respond with SF12 in the RX2 timeslot.
        // If the 1ch gateway is working in and for nodes that ONLY transmit and receive on the set
        // and agreed frequency and spreading factor. make sure to set STRICT to 1.
        // In this case, the frequency and spreading factor for downlink messages is adapted by this
        // gateway
        // NOTE: If your node has only one frequency enabled and one SF, you must set this to 1
        //		in order to receive downlink messages
        #define _STRICT_1CH	1

I think in this (my) case, the gateway ignores the adaptative data rate message from server and continues forwading node packets with the SF and BW pre-set.

I suppose, anyway, as you told, that the gateway is loosing packets for that reason…

PS:Despite that, this morning is working better than other days and i am loosing only 1/10

kersing · September 7, 2018, 12:52pm

ADR is a totally different mechanism. That mechanism provides information to a node to allow/force it to optimize its communication settings. For nodes with only a single channel ‘gateway’ in radio coverage that mechanism could destroy the communication path (it could instruct the node to switch to a different SF which the ‘gateway’ does not support). So you should not enable ADR on your node.

What STRICT_1CH does is force the ‘gateway’ to ignore the SF and frequency settings of any downlink packet. That only works if all nodes within coverage that do use downlinks are also modified for this purpose. You can modify your nodes, others within coverage can’t as they do not know they need to. Because it makes the non compliant ‘gateway’ less compliant it is not a good idea and it is not required so my advice is to change the setting.

covraworks · September 7, 2018, 1:39pm

The gateway acts as an ADR messages firewall so they doesnt arrive to node, I mean, the gateway re-write those messages (i.e. if server sends new DR1, DR3…etc, the gw always sends to node DR2 (SF10/125Khz))

At the time, in Spain, there is only a few of active gateways. In 15 km around there is no more gws, so I suppose nobody is working with lorawan , in addition TTN says that doesnt show single channel gateways because they are not full compilance

covraworks · September 7, 2018, 2:06pm

This is the log from 1 TX:

EV_TXCOMPLETE (includes waiting for RX windows)
152117219: Scheduled job 0x3ffc4720, cb 0x400d1a54 at 153992219
152117571: engineUpdate, opmode=0x900
153992219: Running job 0x3ffc4720, cb 0x400d1a54, deadline 153992219
Valid gps Fix.
0
1
2
3
4
154054693: engineUpdate, opmode=0x908
154054697: Uplink data pending
154054700: Considering band 0, which is available at 1299
154054865: Considering band 3, which is available at 0
154055168: No channel found in band 3
154055380: Considering band 0, which is available at 1299
154055700: No channel found in band 0
154055912: Considering band 1, which is available at 153260034
154056259: Considering band 2, which is available at 1299
154056579: No channel found in band 2
154056791: Considering band 1, which is available at 153260034
154057138: Airtime available at 153260034 (channel duty limit)
154057485: Ready for uplink
154057659: Updating info for TX at 154054697, airtime will be 12864. Setting available time for band 1 to 155341097
154058297: TXMODE, freq=868100000, len=24, SF=9, BW=125, CR=4/5, IH=0
Packet queued
154071172: irq: dio: 0x0 flags: 0x8
154071180: Scheduled job 0x3ffc8c58, cb 0x400d2a30 ASAP
154071185: Running job 0x3ffc8c58, cb 0x400d2a30, deadline 0
154071326: Scheduled job 0x3ffc8c58, cb 0x400d2738 at 154133929
154133929: Running job 0x3ffc8c58, cb 0x400d2738, deadline 154133929
154134056: RXMODE_SINGLE, freq=868100000, SF=9, BW=125, CR=4/5, IH=0
154135356: irq: dio: 0x1 flags: 0x80
154135364: Scheduled job 0x3ffc8c58, cb 0x400d3f58 ASAP
154135369: Running job 0x3ffc8c58, cb 0x400d3f58, deadline 0
154135515: Scheduled job 0x3ffc8c58, cb 0x400d2788 at 154196429
154196429: Running job 0x3ffc8c58, cb 0x400d2788, deadline 154196429
154196556: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
154197856: irq: dio: 0x1 flags: 0x80
154197864: Scheduled job 0x3ffc8c58, cb 0x400d3f88 ASAP
154197869: Running job 0x3ffc8c58, cb 0x400d3f88, deadline 0
EV_TXCOMPLETE (includes waiting for RX windows)