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! 
1 Like
Thank you! I will try it out today. I appreciate the detailed pictures!
- family of LilyGO T-Beam products has been expanded with T-Beam Supreme device that uses ESP32-S3 SoC, Semtech SX1262 radio, Ublox M10S GNSS and 1.3 inch OLED display ;
- LilyGO is also ceasing the V1.1 version of T-Beam in favor of the V1.2 variant. Discontinued AXP192 PMU has been replaced by the new AXP2101 one.
1 Like
Hello, I would like advice on a project with TTGo T BEAM with TTN with anemometers and wind direction.
Ask away - remember details matter and volunteers dont know what you are thinking or what you may have tried so clear questions and details will help the volunteers respond where they can 
Trying to register a T-Beam v1 in my new application, and it’s not available in the list of devices. All I see is what’s in the images. I’ve searched for every string I can think of, can’t find it in the list.
How does one register a T-Beam and get the required Keys and IDs?
I don’t have any of this information:
What is the software on the t-beam? Does it supply any information? Or do you need to program it yourself?
It had Meshtastic on there a couple years ago but I haven’t used it since. My goal is just to load up this ttn tracker to see what kind of coverage I can get in this location, but I need TTN to generate keys for me.
Then use the frequency plan for your location, LoRaWAN version 1.0.2, regional parameters 1.0.2B, JoinEUI al zeros and have TTN generate the DevEUI and AppKey for you.
Take care, the default SEND_INTERVAL is 20 seconds.
Thanks, that got the sketch installed and running. Unfortunately no traffic ever arrived in my application, so either I had something set up wrong, or there are no gateways near enough. In the end, the frustration is higher than the “fun weekend project” designation allows for, and I’ll move on to something else.
This is a serious question as it would be really useful to understand this - what gave you the impression that LoRaWAN & TTN mapping was just something that could be thrown together?
As a supplementary question, did you look on the TTN Mapper site to see if there were any gateways in your vicinity?
Ignoring the basic IDE and dependencies setups, both kizniche and DeuxVis show 3-4 total steps to start seeing data in TTN. What’s not clear from these projects is that most of the linked TTN-specific documentation is split between v2 and v3, making much of it not applicable to what I’m seeing on my screen. Querying how other people have accomplished the same goals often shows screenshots of pages and settings that can’t be found because they no longer exist. The step “add the Keys/EUIs for your Application’s Device from The Things Network” took the most time by far.
There’s a gateway 2.6mi east of my location, and one 3.5mi south. These are probably reachable, and I’m assuming it was a setup error on my end, but there’s no way to confirm without buying my own gateway. This is too high of an investment for someone who has no real-world need, just wanted to tinker for a weekend.
Thanks for this - it confirms the ongoing view that the interwebs are polluted with well meaning but somewhat naive tutorials and that the whole LoRa is Long Range is a common gotcha - it is but with caveats - line of sight and in urban areas, generally the gateway has to be above pretty much everything.
If you do decide that collecting sensor data is a thing at a later date, come back and ask about your use case so we can give you pointers
Meshtastic also planted the seed in my head the LoRa is super simple, and for that specific application it really is. Once you break out of that container, though, things get a bit more complex. I agree that my expectations weren’t accurate, and that I allowed my frustration to set in faster than I should have.
I get an itch to dive into TTN every year or so, I’m sure I’ll be back.
It is a different use case but will still suffer from the same problem of describing the reality of range, but point to point if there are more nodes around does solve some of this. But like gateways, you need some nodes near to hand which can be pretty random - you may have a hotspot of users exchanging messages on a regular basis or you may be the only one for 10’s of kms. Meshtastic is really all about a huge number of users in an emergency when the mobile network is down whipping out their devices & using it for message exchange & relay. But like CPR, it’s a thing that the usefulness of the facility only becomes apparent at the point of requirement.
Update: I got a TTN indoor gateway, and the rumors are true; it’s essentially impossible for a new user to join a new device to TTN without one. The ability to see the traffic (and errors) in the gateway logs is crucial.
The T-Beam is now successfully sending location data. No idea what I’m going to do with it, but it was a fun Saturday project.
Thanks for the help and understanding back in October.
1 Like
Impossible is a bit strong, but it is hard. In our community we added most gateways to an organization and allow community members access to the gateway console. That way they have the same facilities without having to buy a gateway. Of course they still need to be within radio coverage of one of the gateways.
1 Like
now if you look at the uplinks you will see all the gateway data
if your packet are received by other gateways you will see their data as well
depends o what you want to see build your own front end