@gerrit-seigers Hoi Gerrit, probeer het eens zonder SSL (In postman -> File -> Settings -> SSL certificate verification)
Posts made by Stefan de Lange
-
RE: Connectie naar Azure
-
RE: Pycom FiPy compatible with band 8!
Hebben ze ondertussen de low power problemen al opgelost met de FiPy?
-
RE: Beeceptor URL wordt niet geaccepteerd
@houwer-de-geus said in Beeceptor URL wordt niet geaccepteerd:
https://testnbiot.free.beeceptor.com
Ik heb je endpoint net even getest via Postman, ik krijg een OK reply terug dus hij lijkt gewoon te werken:
{ "msg": "Success", "code": 1000 }
Misschien een issue met het startpakket dashboard?
-
RE: Postman request send uplink
@pieterhoenderken Geen idee. Heb dit nog nooit gezien. Misschien weet @ericbarten het
-
RE: Postman request send uplink
Maar ik heb niet het idee dat het bericht ook bij mijn device aankomt, aangezien ik een confirmatiebericht terugstuur en het device maar blijft zenden ipv in slaapmodus te gaan.
Dit begrijp ik niet. Wat bedoel je met het device âblijft maar zendenâ?
Dus de status âacceptedâ is volgens mij dat de CPD server de request accepteerd, maar niet de bevestiging dat het bericht daadwerkelijk via een downlink bij mijn device is aangekomen.
Als het goed is betekent âacceptedâ dat het downlink bericht ook is verstuurd naar je device. Voor mij kwam na het âacceptedâ bericht het downlink message altijd aan op het device.
Hoe kan ik dit controleren?
Als je accepted ontvangt in je node-red moet je het bericht ook ontvangen op je device, een andere controle is er niet dat ik zo weetâŠ
Het device stuurt een telemetry packet met de volgende samenstelling:
0x09 (telemetry packet identifier) 0x39 (number of parameters) 0x00 (parameter number) 0x04 (parameter length) 0x100e0000 (data) 0x01 (parameter number) 0x04 (parameter length) etcâŠ
Het antwoord van mijn Node Red server aan het device moet dan zijn 0x09 (telemetry packet confirmation) 0x0000000000 (byte stuffing) 0xF246 (CRC)Dit zegt mij niks. Zo ver ik weet antwoord node-red niet aan het device, alleen het t-mobile CDP communiceert met het device. Hier hoef je verder niks voor te doen op node-redâŠ
-
RE: Postman request send uplink
@pieterhoenderken said in Postman request send uplink:
@stefan-de-lange Hoe zend ik een downlink bericht vanaf Node-Red?
Verbind een âinjectâ node met een âhttp requestâ node en kopiĂ«er de instellingen van de downlink postman API call
-
RE: T-Mobile USA nu ook gelanceerd
@techniek said in T-Mobile USA nu ook gelanceerd:
Omdat er kleine regionale verschillen zouden kunnen zijn⊠al was het maar dat frequentie band in US een andere isâŠ
Wat voor regionale verschillen moet ik aan denken behalve frequentiebanden?
-
RE: How much battery lifetime can we expect with a Sara-N200 module on our IoT network?
@techniek Mooi experiment Henk.
Ik heb nog een aantal opmerkingen / vragen:
- Heb je bij iedere meting via het +NUESTATS commandado gekeken welk ECL niveau gebruikt werd? In mijn metingen zie ik soms ECL niveau 1 ondanks goede signaalcondities. Figuur 1 lijkt een ander ECL niveau te gebruiken, ik zie daar meerdere pieken welke ik op andere metingen niet zie.
- Klopt het dat een device dat UDP gebruikt langer blijft luisteren dan een device dat CoAP gebruikt? Het verbaast mij dat ik tussen +CSCON: 1 en CSCON: 0 een verschillend stroomfiguur zie voor beide metingen.
In je tekst schrijf je dit:
With the early release enabled the radio module will be forced to go into sleep (PSM) mode and not stay several seconds first in idle mode (where it listens for downlink messages).
-
Volgens mij bedoel je hier connected mode. De interval tussen +CSCON: 1 en +CSCON: 0 wordt verkleint met het gebruik van assisted release, zie figuur 2. De idle mode is de interval tussen CSCON:0 en NPSMR: 1 en wordt dus bepaald door de T3324 idle timer, zie ik ook deze foto van rohde en schwarz:
-
Aanpassen CPSMS parameters. Is het al mogelijk om de PSM timers aan te passen op het device? T3324 (idle) en T3412 (TAU) zijn configureerbaar via AT+CPSMS maar het netwerk lijkt dit nog niet te ondersteunen.
-
Het gebruik van de connected mode lijkt een wel/niet verhaal. Ăf mijn device blijft 20 seconden luisteren naar downlink berichten, of hij doet dit niet. Kan ik deze tijd niet variabel maken? Een device hoeft in heel veel gevallen niet zo lang te luisteren, enkele seconden volstaat.
-
Heb je ook gekeken wat er gebeurt als we PSM niet activeren? Het device blijft dan periodiek pagen. De interval van de pages (ongeveer 10 seconden) heb ik tot nu toe nog niet kunnen verklaren, ik denk dat het iets te maken heeft met eDRX aangezien het device dan in idle modus blijft.
-
Wat is precies het nut van de pages? Kunnen we op deze momenten downlink berichten ontvangen, zo ja, lukt dit dan zowel met UDP als met CoAP?
-
CoAP lijkt meer energie te verbruiken dan UDP. Waarom zouden we dan alsnog CoAP gebruiken? Wat krijgen we terug voor dit (bijna dubbele!) stroomverbruik?
-
Hogere ECL en een hoger zendvermogen is niet meegenomen in de metingen. Het is daarom niet met zekerheid te zeggen dat de data in iedere situatie geldig is. Zeker in situaties met slechtere signaal condities waar ECL: 2 optreedt zal de batterij minder lang meegaan dan in de tabel staat.
-
Ook een grotere pakketgrootte heeft invloed op het stroomverbruik. Er kunnen namelijk 512 bytes verstuurd worden in een enkel uplink bericht. Misschien interessant om hier ook nog naar te kijken.
Also on the network side we will see improvements with 3GPP release 14, which include:
a new NB2 modem category with double data rates,a new power class of 14 dBm to support coin-cell battery operation e.g. for wearables,
extentions on the early release, with AS release assistance indication,
And general capacity increases on the number of devices supported on the networkâŠ
- Het proces van het uitrollen van features verward mij nog een beetje. Als ik naar de roadmap kijk dan zie ik geen van de features die je nu noemt. Wanneer is het T-Mobile NB-IoT netwerk release 14 âreadyâ? 3GPP release 14 is namelijk al frozen in juni 2017: http://www.3gpp.org/release-14
Al met al is het stroomverbruik nog steeds een ingewikkeld verhaal met veel factoren die meespelen.
-
RE: Starterspakket nieuwe stijl
@alfons-geurts Mooi dat het werkt.
Ik raad je toch sterk aan om de firmware te upgraden, de firmware versie waar dubbele quotes niet verplicht zijn is behoorlijk verouderd
-
RE: Frequentie LTE-NB
@felixdonkers Volgens T-Mobile zelf is het guard band operation: https://docs.iot.t-mobile.nl/docs/general-settings
-
RE: (UI) Register endpoint (Device) CoAp onverwachte response
@pieterhoenderken Waar zie je deze response? Bij welke actie?
-
RE: Postman request send uplink
@pieterhoenderken Top! Het is overigens ook mogelijk om vanaf Node-RED downlink berichten te sturen naar een device
-
RE: Postman request send uplink
@pieterhoenderken Hoi Pieter, als het goed is kun je hiervoor de register application API call gebruiken (in postman). Die stuurt namelijk vanaf het CDP een leeg datapakket naar je north application, voor jou dus node-RED. Als Node-RED correct geconfigureerd is zal deze een 200 (OK) response sturen naar het CDP. Een correcte connectie tussen de north application en het CDP is hiermee bevestigd.
-
Downlink message to a group devices
Hoi iedereen,
Ik vroeg mij af of het ook mogelijk is om downlink berichten te sturen naar een groep devices ipv een enkel device. Nu werkt het goed op basis van device ID, met een handjevol devices is dat nog te doen. Het wordt echter al gauw te veel bij meerdere devices. Is dit mogelijk? Zo niet, kan deze feature geĂŻmplementeerd worden?