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?
@felixdonkers Volgens T-Mobile zelf is het guard band operation: https://docs.iot.t-mobile.nl/docs/general-settings
@niels-veul Hoi Niels. Verkeer tussen jouw applicatie en het T-Mobile netwerk is altijd in JSON formaat via HTTP(S). Verkeer tussen jouw modem en het T-Mobile netwerk kan UDP of CoAP zijn. Je zou het dus zo kunnen zien:
Modem <- [UDP] -> T-Mobile CDP <- [HTTP] -> Jouw applicatie
Dit betekent dus dat je nooit ‘direct’ over het open internet met een modem praat, zoals je LTE-M demo. Er zit altijd een proxy tussen, het CDP. Om te praten met het T-Mobile netwerk zul je dus een applicatie moeten opzetten die om kan gaan met HTTP.
@techniek Mooi experiment Henk.
Ik heb nog een aantal opmerkingen / vragen:
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…
Al met al is het stroomverbruik nog steeds een ingewikkeld verhaal met veel factoren die meespelen.
@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.
@afzal_m hi Afzal, maybe a good idea to provide commands for different modems? Because commands are always modem specific 
@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 
@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
@gerrit-seigers Hoi Gerrit, probeer het eens zonder SSL (In postman -> File -> Settings -> SSL certificate verification)
@supersjimmie Netjes! Eigenlijk zouden we een document moeten hebben om dit soort info voor iedere module op te slaan
@Martijn-Kooijman said in Arduino MKR NB1500: lukt niet om te verbinden.:
And I agree that psm might give better overall results if you send often but when you send once in a while (like I do) I think turning it off is more power efficient?
That depends on many things. Turning R4 off means you have to attach to the network every time you turn it on, that can consume a lot of energy.
@Martijn-Kooijman If you want to use network PSM you can’t turn it off.
@Stefan-de-Lange I dont think its only the board thats not optimised, but also the current arduino implementation. for example you could run the samd21 at lower speed.
If you want to measure sleep current the MCU should be in deep sleep, so no clock running at all (except maybe RTC to wake it up)
@Crowdsourcer It’s an arduino development board, it’s not build for low power. So don’t expect too much from it. In practise I get about 7uA deep sleep current with u-blox R4
@Crowdsourcer I use realterm, it works well with binary data:
@Crowdsourcer What tool do you use to send those ‘0’ characters? A standard serial terminal like putty will take input from your keyboard and will transmit ‘0’ as 0x30
@Crowdsourcer I don’t think it is a SARA bug. If there was a bug with this command I would have seen it after all the testing I did…
@Crowdsourcer said in Arduino MKR NB1500: lukt niet om te verbinden.:
@Stefan-de-Lange @Martijn-Kooijman
Sorry for spamming you again, but the script is not reliable. I could not repeat reliable results and only one message was sent last night (I am sending every 15 min.). Certain hex values or a combination of them still seem to be interpreted as control characters. I will try to find those “forbidden” numbers. Sending control characters such as CR or ETX are not causing issues and are just treated as binary. I may need to resort to Base syntax, but I don’t like sending the double amount of data.
This sounds very confusing. I suggest you try manually first with the passthrough sketch before continuing to write the program. I have used both syntaxes extensively in various applications and have never had any problems
@Crowdsourcer said in Arduino MKR NB1500: lukt niet om te verbinden.:
@Stefan-de-Lange Yes, I am first sending the command as text, then after receiving the @ I switch to binary to send the raw data.
//So I first open a UDP channel:
Udp.beginPacket(“172.27.131.100”,15683);
//Then I send the USOST command using ascii printing
sendcommand=“AT+USOST=0,“172.27.131.100”,15683,”+String(payload_size);
SerialSARA.println(sendcommand);
//Subsequently I receive a “@” from the SARA module, then write binary data
Udp.write((uint8_t*)&payload, payload_size);//
Udp.endPacket();
I can’t judge your code. I can only see you do not read ‘@’ (or it’s hidden in some other function) but start writing immediately. I suggest you implement this synchronously and read back the ‘@’ before writing data.
Only when I use SerialSARA.println(payloadtest); (this time with payloadtest as a char array I get the right values. However if one of these chars contain a control character the communication stops which is understandable for a print statement). Using a SerialSARA.write(…) in a loop byte for byte did not solve this (nothing ever received).
Can you try the binary syntax? It is stated in the AT command manual you can’t send control characters using base syntax:
