yes plan to tag my own packets. I am just interested if repeating a foreign packet is detrimental or helpful to increasing range of other nodes or if it just blocks up the network.
You should never relay messages that are not part of your own network/protocol. If you don’t own the network repeating messages is basically a replay attack which might harm other networks. It will always increase the usage of the frequency which by itself is bad.
1 Like
In some circumstances it might not cause an issue, even on TTN, but not all packets can be assumed to be TTN. You have no way of knowing what the impact on the ‘other’ network would be by inserting extra packets into that networks operations.
So does it not just make sense to assume that repeating any packet that does not belong to your network is a (very) bad idea ?
2 Likes
Wow, thank you for the link on Fair Access policy. I had no idea of the restrictions. After reading all that i feel like some kind of reckless CB radio guy , with no idea. As a licenced radio ham, I should have considered there may have been restrictions. My Approach was of the Packet radio days, And so my approach also considered none encrypted and beacon that broadcast my GPS location in plain txt. Now that i have read the restrictions i can see even my usage needs to be reduced and to repeat foreign packets is wasting my allowable usage. My lora reciever picks up very few foreign packets. So i feel some logic regarding fair use should take into account that the user may be in an area of few or no other devices. So there is a lot of capacity. It would make some sense to have an adaptive usage based on spare capacity in the area. Also adaptive transmitter strength depending on density of other devices. Just a thought… But again thank you for pointing me to the policy, as i don’t want to be that annoying person spoiling it for everyone else.
One thing is duty cycle limitation (1%), this is by law and there is no easy way to tell whether you are in an area with “few or no other devices”, and also for much time the situation will remain the same.
A different thing is the Fair Access Policy, which is regulating the use of a shared and free, yet owned and paid by someone, resource like the network server, for which the logic you feel may not be so logic (other providers limit free accounts in different and stricter ways). If you pay for a TTI account, FAP will not be an issue. However, there is a specific thread about this.
your welcome (and please stick to the topic start)
But as @UdLoRa points out, you are using getting free use of all the back end TTN network. Even though your perhaps in a quiet area, your using the same amount of that resouce and support as a user in a busy area.
tried again and it compiled??? strange but working now
Try changing every instance of TinyGPSPlus to gps
Instead of TinyGPSPlus(…) change it to gps(…) and give that a try
There are several T-Beam Arduino sketches on github that claim to work with TTN. Some clearly never did and never will. For example, never initializing the SPI interface, wrong ESP32 pin mappings for the LoRa SX1276 pins, ‘radio not supported’ error messages, … Often the understanding of which ESP32 pin is connected to the BLUE LED is not correct. This is sad.
This problem is lack of code control. The sketches cannot be used to program a T-Beam as claimed in the various github T-Beam repositories. The main culprit is the lmic library. The issue is which lmic library, from what github, with whatever github revision purported to function. The Arduino maker community often fails to comprehend a .ino sketch that references a library needs that library code to be able to reproduce the working sketch. Since the libraries are not included with the sketch, we are left to search for candidate lmic libraries. There are many, each with a history of revisions in github repositories.
So as far as I can see, the T-Beam hardware is perfectly capable of connecting to the TTN gateways if the .ino sketch code ever were to match up with the correct lmic library. Until that happens, the T-Beam will never connect to TTN. It is called code control. None exists for the T-Beam.
Now, starting from scratch, I have been able to blink the LED, read the push button, create a Bluetooth NMEA sentence GPS, and exchanged data between a pair of T-Beams over the LoRa radio. The next step is to port the IBM lmic library code to the ESP32. Yes, this exactly what the many lmic repositories on github claim to have done, but do any of them work with an identifiable .ino sketch? We need code control. We need to be able to recreate a working system from a given code base.
So far, the T-Beam has been a waste of time for me, but has provided a fantastic journey learning about ESP32, LoRa, and LoRaWAN. Unfortunately, it has not worked out for TTN.
You are right about the whole code control thing. However the TTGO works with the ESP32-PAXCounter codebase which works with TTN, and the ttnmapper integration. I have programmed the TTGO with it using Visual Studio Code.with the PlatformIO module. The (compatible) LMIC library is provided.
It works very well.
1 Like
I agree with the code control problem. MarkD has 3 TTGO T-Beams that connect to TTN, work with TTN Mapper and continue to work well. He has shared his code with us.
I’ve edited the same code to work with the TTGO V1 without OLED and TTGO V2 with OLED.
Hi, do you find any box for device?
I look it, too. Thanks
You are right that finding the appropriate library version can be difficult.
This is why someone who creates a sketch on github should provide detailed instructions (README file) about which version to use, along with links.
@covraworks:
I have a ttgo t-beam device and i wanted to send the gps position to the gateway using TTN and arduino IDE.
At first, I wanted to send a simple message ‘helloworld’ to TTN but no data was received there. Even the module status was never seen.
Was the problem with the LMIC library?
could you please pass me your code and tell me if there is something to change in the configuration of the library LMIC.
Seems to be a new version out (ordering one as my old one has failed anyway) T22_V10 20190612
Product Upgrade Content
1. Pin GPIO34 pin is replaced with GPIO35
2. Replace the charging IC (TP5400) with the power management AXP192
3.GPS TX, RX pin replacement
4. Power on and remove, replace with button to open
5. Reduced sleep current
6.GPS battery replacement
Some more info > https://github.com/Xinyuan-LilyGO/TTGO-T-Beam
1 Like
Do someone knows how to connect a tipping bucket rain gauge sensor to TTGO-T-Beam borad? Paxcounter in github did not support that and there is only some advice with normal ESP32 board with this rain gauge sensor but not suits for TTGO-T-Beam? Did someone can give some new idea? Many thanks.
Sorry, I have double checked my DEVEUI APPEUI APPKEY in config.h. Also the program can uploaded well. But still the status in TTN shows never seen. Could you please help me to check the problem somewhere? Thank you very much.
You not giving us a single bit of information to assist in diagnosis, other than saying its not being seen.
Are you running your own gateway? have you got other nodes working? what is your T-beam node log showing during the connect process?
Also there is a vast amount of info on this forum now to check and diagnose your nodes connection log too, search and you will find 