Thanks to all involved in getting this next phase of TTN out of the lab. Really impessive to notice what has been done and I think it might be good we say: 'thanks all of you guys'. It looks amazing. Well done.
Announcing staging environment of TTN Back-end 1.0
↧
↧
Measuring coverage gateway
Experimenting in Zwolle, but I can't help but feel that coverage is way lower than it should be. Any pointers? A map of coverage can be seen here.
- Gateway: I'm using a Lorank 8, mounted on the 4th floor near the front of our building, which is covered in glass.
- Node: Sodaq Autonomo + RN2483 (LoraBee)
Is this kind of coverage in line with expectation considering these two devices or could there be something wrong with my setup?
↧
Node with ESP8266 and RFM95W
Verified - fixed /4 changed to /16 in LMIC_disableChannel() for CFG_us915 and now it works, only sends on my single channel gateway frequency of 913.7:
...
Disabling channel: 53
Disabling channel: 54
Disabling channel: 55
Disabling channel: 56
Disabling channel: 58
Disabling channel: 59
Disabling channel: 60
Disabling channel: 61
Disabling channel: 62
Disabling channel: 63
Disabling channel: 64
Disabling channel: 65
Disabling channel: 66
Disabling channel: 67
Disabling channel: 68
Disabling channel: 69
Disabling channel: 70
Disabling channel: 71
Disabling channel: 72
Init done
Time: 0
Send, txCnhl: 0
Opmode check: ok
Event EV_TXCOMPLETE, time: 10
Time: 30
Send, txCnhl: 57
Opmode check: ok
Event EV_TXCOMPLETE, time: 40
Time: 60
Send, txCnhl: 57
Opmode check: ok
Event EV_TXCOMPLETE, time: 70
Time: 90
Send, txCnhl: 57
Opmode check: ok
Event EV_TXCOMPLETE, time: 101
Time: 120
Send, txCnhl: 57
Opmode check: ok
Thanks!
↧
[OFFICIAL] TheThingsNetwork.org & Community Pages
Hi all,
The new design of the community pages has been launched. Please take a look at your community page, or go to http://thethingsnetwork.org/c/amsterdam.
A new feature of the community page, is a generator that creates a unique logo for each community. The logo is an svg file and can be downloaded and used for any purpose.
Feedback
We would like to receive feedback on the new design. We're happy with any positive feedback and/or recommendations. Please provide the feedback on this forum topic: http://forum.thethingsnetwork.org/t/new-design-community-page/1662 (or send me a personal message: laurens@thethingsnetwork.org).
↧
Denver, Colorado
@dwalkes
Hi,
I have ordered a gateway and nodes during the Kickstarter campaign with an expected mid-year delivery.
Interested in the LoRa/LoRaWAN technology for IoT applications.
I am located in the greater Denver area and very interested in furthering conversations with others getting involved in this technology.
David
3/6380653
↧
↧
New design community page
First impression: well done guys. Modern, fresh look and more attractive for a non contributor. Thanks a lot for this again exciting move forward.
↧
Leiden, The Netherlands
Don't know if this topic is still active. I went to the iot techday in Utrecht last week and i got really excited about iot.
I do not see any network coverage in Sassenheim (where i live) so maybe i can start there ? 
↧
Capacity of iC880a-based gateway
I think the gateway could take the load without much trouble, the problem is that one message every 10 seconds most likely violates TTN's fair usage policy, and perhaps also duty cycle limitation per node.
↧
Sticker The Things Network
↧
↧
Announcing staging environment of TTN Back-end 1.0
You do need access to an account server. You can use TTN's account server on https://account.thethingsnetwork.org. We're still doing quite some development on this, but as soon as the API is stable, we'll define a specification for this account server so that you can implement your own.
This could be caused by a number of things. For example if you have a single-channel gateway closeby (#140), if you're not in Europe (#119 and #120) or some other unknown issue. Talk to me on Slack tomorrow (CEST) and I can try to help you.
That's not possible yet, but it's on our todo list.
Only use confirmed uplink if you really need it. It eats downlink capacity.
That's not possible yet, but it's on our todo list.
↧
Capacity of iC880a-based gateway
That's why I want to add a filter (eg my gateway) to catch my packets before they reach The Things Network.
The dutycycle-limit is not hit at an interval of 10s. The limit kicks in at an interval of 6 seconds, i tested
↧
MultiTech TTN package
You should be able to use this in a Multitech Conduit:$ mts-io-sysfs show lora/eui
↧
ESP8266/RFM95W node - How long should a send take?
I've been looking at a battery powered node using an ESP8266 and RFM95W, based on this thread. I've done ESP8266 IoT sensors before using WiFi and been able to get a few months out of them on a couple of AA batteries so hoped that using LoRa instead of WiFi could extend that a lot.
However it turns out that the time for the node doing a send and getting the TX_COMPLETE event back takes ages, 6 - 10 seconds, so even when using deepSleep for the rest of the time that 10 seconds of up time would drain the batteries quite quickly.
I wondered if it was something i had wrong but doing some searches i see from the logs other people have posted that theirs are slow too, eg here and here and here.
That seems odd., it shouldn't take so long should it? Poking around in the LMIC code and the SX1276 datasheet it sounded like after a send DIO0 going high would indicate the send is complete so I've tried using that to trigger when to put the ESP8266 in deepSleep, and that seems to work, DIO0 goes high about 130 milliseconds after the send and putting the ESP8266 to sleep then the gateway still seems to get the transmission ok.
So great. I have WiFi disabled on the ESP so its using about 14mA when awake, and thats only for 130ms or so, and then deepSleep current is about 17uA the rest of the time, so even with the node publishing as often as once a minute a couple of AA alkalines should last over a year.
I wonder is this a bug in the LMIC code that its not doing the EV_TXCOMPLETE sooner, or perhaps is the SX1276 carrying on finishing the send after i put the ESP to sleep after 130ms? Any ideas?
(I've put this code i have for this ESP8266/RFM95W node here)
And here's a pic of the node asleep:
↧
↧
ESP8266/RFM95W node - How long should a send take?
That doesn't feel right. But it does depend on the packet size. Like sending a 50 byte packet on SF12 takes 2.8 seconds on SF12. I guess that implies the node starts to listen for a response after 3.8 and 4.8 seconds, but I might have that timing wrong. The TX_COMPLETE would only be triggered after both the first and second Class A receive windows have ended.
↧
Measuring coverage gateway
@arondeparon, the coverage map shows red, orange, yellow and green: not bad? Or did you expect readings at locations not shown on that map?
↧
TTN Gateway
Hi Flavio,
I saw that you purchased the Gateway and mDot from Digi-key.
My problem is that Digi-key can't export this itens to Brazil.
It has some export restrictions, so I need to find another distributor.
Did you have this problem?
↧
Measuring coverage gateway
It seems that the signal is okay, but the range is way lower than I would expect. (Max. +- 500 meters).
↧
↧
New design community page
Check website tab header text!
All communities are now called "The Things Network Amsterdam". I would change that to The Things Network.
Cheers.
↧
Universal LoRa(WAN) gateway limitations, because physics?
Interesting, this is rather straightforward. Assuming a Packet Error Rate of 10% is the upper-bound for proper operation, for a single base station, we have:
Lora using 125kHz (but actually 200kHz channel spacing) and optimal (i.e. impractical) adaptive data rate: 100 messages/minute
Sigfox using 200kHz: 1,500 messages/minute
That is an application layer uplink capacity of 0.0008 bit/s/Hz for Lora and 0.012bit/s/Hz for Sigfox. That is, 15 times more uplink capacity/spectrum efficiency for Sigfox compared to Lora. It would therefore require upward of 3MHz of spectrum for Lora to accommodate as many uplink messages/minute as Sigfox.
The proposed "solution" of increasing the gateway density defeats the purpose of LPWAN, and will make the usage of Lora CSS obsolete as a physical layer. More than ever it is time to use flexible base station design, like SDR approaches used in Sigfox, Weightless or Cellular IoT. Using a hardware receiver like what is typically done for LoraWAN requires a lot of faith...
There might be a reason after all why Sigfox, Weightless-P, NB-IOT or NB-LTE have all elected to use (Ultra) Narrow Band in 200kHz to cater for the expected IoT traffic.
As for synchronization and TDMA/FDMA, this is indeed a way to scale, as used by Weightless-P or NB-IOT. It is inaccurate to claim EU has to go with duty cycle limitations. It is indeed the case when you use Lora CSS, but it is not when you use more spectrum-efficient narrowband modulations.
↧
Measuring coverage gateway
Something is definitely not normal there, we use basically the same radio hardware (not lorank8 but the plain ic880a board that is inside of it) and we have at least 2km range in urban setting. We even measured over 6km between node and an indoors gateway once (coincidentally also 4th floor behind a window).
Try another node, maybe there's a defect on that one. Then try outdoors, just to make sure there's nothing particularly isolating in your building...
↧
More Pages to Explore .....
