Andre,
interessante meting. Alles lijkt nog niet helemaal verklaarbaar, toch?
wij zijn ook geinteresseerd in power-reductie, zeker als het gaat om het gemiddeld opgenomen vermogen gemiddeld over een korte periode (< 100 ms) en zullen hier ook wat meetstappen moeten maken.
Om even appels met appels te blijven vergelijken:
Hoeveel samples per seconde neemt jouw meetapparatuur? (Was dit een STM32 ADC?)
Wat is de bandbreedte van jouw meetapparatuur?
Groet,
Leon.
En om het helemaal simpel te houden (zonder node-red) kun je eerst verifieren of alles tot je endpoint host goed gaat. Ik deed dat als volgt:
echo “HTTP/1.0 200 OK” | nc -l localhost 8080
vanuit een Linux server. | = pipe symbool , -l is “minus el” voor “listen”.
Ik realiseer me nu dat ik geen AT+CFUN=0 en CFUN=1 meer heb gebruikt, wellicht lost dat het aan mijn kant op. Zodra ik de code 4 (Unknown) weer krijg zal ik dat eens proberen.
Soms registreert mijn module zich niet langer op het netwerk. Alleen het verwijderen/opnieuw toevoegen in device manager lijkt dan nog te helpen. Dit is uiteraard geen werkbare oplossing voor betrouwbare toepassing. Hier een log:
[2018-05-10 23:40:42:101_S:] AT+QCFG=“NWSCANSEQ”,030201
[2018-05-10 23:40:42:106_R:] AT+QCFG=“NWSCANSEQ”,030201
[2018-05-10 23:40:42:110_R:] OK
[2018-05-10 23:40:45:710_S:] AT+QCFG=“NBSIBSCRAMBLE”,0
[2018-05-10 23:40:45:714_R:] AT+QCFG=“NBSIBSCRAMBLE”,0
[2018-05-10 23:40:45:719_R:] OK
[2018-05-10 23:40:48:958_S:] AT+QCFG=“IOTOPMODE”,1
[2018-05-10 23:40:48:962_R:] AT+QCFG=“IOTOPMODE”,1
[2018-05-10 23:40:48:966_R:] OK
[2018-05-10 23:40:52:726_S:] AT+QCFG=“BAND”,0,80,80
[2018-05-10 23:40:52:730_R:] AT+QCFG=“BAND”,0,80,80
[2018-05-10 23:40:52:735_R:] OK
[2018-05-10 23:40:56:478_S:] AT+CGATT=1
[2018-05-10 23:40:56:482_R:] AT+CGATT=1
[2018-05-10 23:40:56:487_R:] OK
[2018-05-10 23:41:00:422_S:] AT+CSQ
[2018-05-10 23:41:00:427_R:] AT+CSQ
[2018-05-10 23:41:00:427_R:] +CSQ: 23,99
[2018-05-10 23:41:00:427_R:] OK
[2018-05-10 23:41:04:206_S:] AT+CEREG?
[2018-05-10 23:41:04:211_R:] AT+CEREG?
[2018-05-10 23:41:04:211_R:] +CEREG: 0,4 <===== hier gaat het fout
[2018-05-10 23:41:04:211_R:] OK
[2018-05-10 23:41:08:510_S:] AT+QICSGP=1,1,“cdp.iot.t-mobile.nl”
[2018-05-10 23:41:08:514_R:] AT+QICSGP=1,1,“cdp.iot.t-mobile.nl”
[2018-05-10 23:41:08:522_R:] OK
[2018-05-10 23:41:12:391_S:] AT+QIACT=1
[2018-05-10 23:41:12:395_R:] AT+QIACT=1
[2018-05-10 23:41:13:181_R:] ERROR <== heeft dit tot gevolg
Het verwijderen van de resources en het device, en het opnieuw toevoegen van device en resource subscription in jullie device manager lijkt dit probleem op te lossen. Dan wordt de module wel goed geregistreerd.
[2018-05-10 23:46:35:262_R:] AT+CEREG?
[2018-05-10 23:46:35:266_R:] +CEREG: 4,5,“400”,“A0”,“C77E67”,9,“00000000”,“01100000”
Het 2e getal wat terugkomt uit AT+CEREG? betekent volgens mijn module (BG96) manual:
0 Not registered. MT is not currently searching an operator to register to.
1 Registered, home network
2 Not registered, but MT is currently trying to attach or searching an operator to register to.
Registration denied
4 Unknown
5 Registered, roaming
Ik kan dus van mijn kant niet zien waarom de module niet langer registreert op jullie netwerk.
Zien jullie in jullie logs hier iets van?
Voor diegenen die in deze thread terecht komen, de BG96 werkt nu met UDP.
Ik heb UDP ook werkend vanaf een BG96.
Het was nodig om een resource te registreren.
Ik zie echter twee problemen:
Als 3e nog twee vragen:
Wat is de juiste API om via HTTP een UDP packet naar mijn equipment te sturen?
Wat is de MTU size?
De BG96 heeft een andere chipset, wordt deze reeds ondersteunt in de huidige (spoedig oude) APN?
Lijkt alles te ondersteunen, behalve CDN. Is CDN een vereiste om een IP verbinding op te zetten?