LoRaWAN enables class C end nodes, definitely possible to configure the device over the air and send commands to it that cloce a valve or switch a relay. Even as a class A device, there are two RX windows in which control params can be sent down. Great vid though.
Great video, thank you! I very much agree with you because I went through the every step you mentioned making my WCDMA GPS tracking device years ago. Now I'm about to design my new LTE-M GPS tracking device. I wonder if I can use your certified LL-LTE-M-VZN-S to simplify the new design. Is there a datasheet or developer kit available?
Hello, one question, why do you think is not possible to send geo location using SigFox in your example? Using geohash a complete address would be 12 characters, but as you would know, geohash prefix are the same for similar locations and also Sigfox give you an approximated area using his antennas (so you can avoid the first characters from your geohash). Also Sigfox allows 140 messages per day (1 message per 10 minutes more or less) with 12 bytes so in the worst scenario you can send a full geohash (but the smartest way is to send only the suffix that has changed from previous position). For example, imagine that you are somewhere in the Brooklyn Botanic Park, your geohash would be "dr5rken0uwu6". You can check in the next url: geohash.org/dr5rken0uwu6 Then you move to somewhere between 7th avenue and 9th street... your new geohash would be "dr5rke0jpp7z". Check again here: geohash.org/dr5rke0jpp7z The common prefix is dr5rke so to send a location update you can just send as the next event the geohash 0jpp7z (just 6 characters): dr5rken0uwu6 - dr5rke0jpp7z ----------------------- jpp7z This is just a quick example of course, a fully API should be more elaborated but in my humble opinion is feasible to do it. Tell me your concerns please, probably I missed something!!
There is a lot of WRONG information about the SIGFOX solution !!! You should review your sources since you are not being fair. There is not problem for SIGFOX to support a message every 15 minutes, since the standard stipulates 140 messages per day, or one every 10 minutes (ETSI). Plus your connectivity costs estimates are much higher than the reality. For metering, with 1 message per day, your connectivity costs are 10 to 30 times higher than the reality..... so your comparison is skewed. Besides, the USA will be covered entirely within a pretty short time.... and you do not mention deep indoor reception, which is an additional benefit of the LPWAN technology, and also the fact that it is not jammeable, unlike LTE, NBIot and LORA (Spread spectrum). In short, either you are not well informed or you are fully biased !!!!
Agree with you Guyginestet, a cost study from a company that has his own LPWAN technology could not be very impartial. but i think the real good question is not the costs between the different LPWAN techs but witch one is right tech for your use case needs.
Slides: www.slideshare.net/BrianRay10/lpwan-sost-webinar
this video was really informative for me ..
LoRaWAN enables class C end nodes, definitely possible to configure the device over the air and send commands to it that cloce a valve or switch a relay. Even as a class A device, there are two RX windows in which control params can be sent down. Great vid though.
Impressive - thanks for sharing your valuable experience. This is worth watching several times.
Thanks Dick.
Great video, thank you! I very much agree with you because I went through the every step you mentioned making my WCDMA GPS tracking device years ago. Now I'm about to design my new LTE-M GPS tracking device. I wonder if I can use your certified LL-LTE-M-VZN-S to simplify the new design. Is there a datasheet or developer kit available?
Absolutely. Please get in touch with webinar @ link-labs . com
Thank you for this. Super helpful!!
Very informative.. thanks very much!!!
great video, good overall picture, thanks!
Hello, one question, why do you think is not possible to send geo location using SigFox in your example?
Using geohash a complete address would be 12 characters, but as you would know, geohash prefix are the same for similar locations and also Sigfox give you an approximated area using his antennas (so you can avoid the first characters from your geohash).
Also Sigfox allows 140 messages per day (1 message per 10 minutes more or less) with 12 bytes so in the worst scenario you can send a full geohash (but the smartest way is to send only the suffix that has changed from previous position).
For example, imagine that you are somewhere in the Brooklyn Botanic Park, your geohash would be "dr5rken0uwu6".
You can check in the next url:
geohash.org/dr5rken0uwu6
Then you move to somewhere between 7th avenue and 9th street... your new geohash would be "dr5rke0jpp7z".
Check again here:
geohash.org/dr5rke0jpp7z
The common prefix is dr5rke so to send a location update you can just send as the next event the geohash 0jpp7z (just 6 characters):
dr5rken0uwu6
- dr5rke0jpp7z
-----------------------
jpp7z
This is just a quick example of course, a fully API should be more elaborated but in my humble opinion is feasible to do it.
Tell me your concerns please, probably I missed something!!
Very useful stuff !
Adrien Course
There is a lot of WRONG information about the SIGFOX solution !!! You should review your sources since you are not being fair. There is not problem for SIGFOX to support a message every 15 minutes, since the standard stipulates 140 messages per day, or one every 10 minutes (ETSI).
Plus your connectivity costs estimates are much higher than the reality. For metering, with 1 message per day, your connectivity costs are 10 to 30 times higher than the reality..... so your comparison is skewed.
Besides, the USA will be covered entirely within a pretty short time.... and you do not mention deep indoor reception, which is an additional benefit of the LPWAN technology, and also the fact that it is not jammeable, unlike LTE, NBIot and LORA (Spread spectrum).
In short, either you are not well informed or you are fully biased !!!!
Agree with you Guyginestet, a cost study from a company that has his own LPWAN technology could not be very impartial. but i think the real good question is not the costs between the different LPWAN techs but witch one is right tech for your use case needs.
Please refer to this white paper to have more impartial costs :
s-media-cache-ak0.pinimg.com/originals/12/cf/c4/12cfc41a14fae49a4b07c26750d2fad9.jpg
@@danisamgibs Very interesting. Is there an updated version of this?
Wiegand Mission