Posts made by melvinItude

Een hele goede vraag. Ons apparaat gaat nu ook maar 1,5 maand mee voornamelijk door de lange ready en idle tijd.
T-Mobile heeft de T3412 timer op 310 uur staan en de T3324 op 30 seconde.
Bij onze meting blijft de BG96 ~60mA gebruiken voor 35 seconden waarna hij in idle mode gaat voor rond de 31 seconde en op dat moment ~20mA verbruikt. In PSM verbruikt ons complete board rond de 40µA.
Zie afbeelding. 1mV == 1mA.

Uiteindelijk zou eDRX veel kunnen helpen maar mijn vraag is ook waarom de ready en idle tijd zo lang is.

@andre-rodenburg
Met deze commando’s heb ik gewerkt op de BG96:

Open socket: AT+QIOPEN=1,0,"UDP SERVICE","127.0.0.1",0,5683,0
send message: AT+QISEND=0,<payload size>,"172.27.131.100",15683
A > will follow from bg96. Type payload
Check for incoming message: AT+QIRD=0
Close socket: AT+QICLOSE=0

Een volledige communicatie tussen MCU en BG96:

AT+QIOPEN=1,0,"UDP SERVICE","127.0.0.1",0,5683,0

OK

+QIOPEN: 0,0
AT+QISEND=0,4,"172.27.131.100",15683

> test
SEND OK
AT+QISEND=0,0

+QISEND: 4,4,0

OK
AT+QIRD=0

+QIRD: 0

OK
AT+QICLOSE=0

OK

Hoop dat je er wat aan hebt!

Hoi Andre,

Lastig probleem om op te lossen als je niet kan nagaan waar de fout zit.
Zelf heb ik wel UDP uplinks werkend maar dat is dan met de BG96.
Wat mij wel is opgevallen is dat ik soms ook geen UDP binnen kreeg na registratie.
Ik heb toen het device verwijderd uit de API en alles opnieuw uitgevoerd:

• registeren device
• opnieuw registreren applicatie
• registeren subscription (dit blijkt niet nodig te zijn voor UDP)

Daarna heb ik de BG96 opnieuw laten connecten met het netwerk en na enige tijd ging het dan werken.

Hierbij dan toch nog een ongeteste poort naar otheruse :

size_t MDM9206Module::receiveUDP(int socket, uint8_t* buffer, size_t len, uint32_t timeout) {
	timestamp_t start = getTimestamp();
	bool found = false;
	int size;
	serial.printf("AT+QIRD=%d\r\n", socket);
	serial.find(1000,{"+QIRD: "});
	serial.readLine((char*)buffer, len, 1000);// the response
	size = atoi((char*)buffer);

	if (size == 0) {
		while (getTimestamp() - start < timeout) {
			// +QIURC: "recv",
			if (serial.find(1000, {"+QIURC: \"recv\","}) == 0) {
				char buf[10]{};
				serial.readLine(buf, sizeof(buf), timeout - (getTimestamp() - start));
				int sock = atoi(buf);
	//			Serial.print("Message receive indicator found on socket ");
	//			Serial.println(sock, 10);
				if (sock == socket) {
					found = true;
					break;
				}
			}
		}
		if (found) {
			serial.printf("AT+QIRD=%d\r\n", socket);
			serial.find(1000,{"+QIRD: "});
			serial.readLine((char*)buffer, len, 1000);// the response
			size = atoi((char*)buffer);
		}
	}
	if (size != 0) {
		// Ignore ip address and port for now
		serial.readBytes(buffer, size, 1000);
		return size;
	}
	return 0;
}

Hoi Allemaal,

Wij hebben het voor elkaar om met de Quectel BG96 Neul messages te sturen naar het Nokia impact platform.
Er is wat vraag naar om hierover mijn ervaring te delen dus bij deze

De library die wij gebruikt hebben:
https://github.com/otheruse/NeulMessenger

Wij hebben deze library gepoort naar Mbed en gebruiken geen Arduino oid.
De enige twee klassen die wij gebruiken zijn:

• CoapPacket.h .cpp
• NeulMessenger.h .cpp

De MDM9206Module klasse hebben wij verwerkt in onze eigen klasse.

Er was 1 probleem dat wij ondervonden hebben in de MDM9206Module.
De methode receiveUDP houdt geen rekening met achtereenvolgende downlink berichten. De methode receiveUDP is zo geprogrammeerd dat deze wacht op een +QIURC: “recv” bericht. Dit bericht wordt echter alleen verstuurd als de BG96 buffer op dat moment leeg is!
Het oceanconnect/impact platform stuurt een ACK bericht terug en direct daar achteraan een bericht bevattende een token oid. Wij hebben ondervonden dat hij de ACK netjes verwerkt en daarna vervolgens wacht op nogmaals een +QIURC: “recv” wat nooit naar voren komt omdat de buffer op het moment dat het bericht binnen kwam al data bevatte (de ACK).

Zie hiervoor ook de Quectel documentatie (pagina 19):
https://www.quectel.com/UploadImage/Downlad/Quectel_BG96_TCP(IP)_AT_Commands_Manual_V1.0.pdf
“Please note that if the buffer is not empty, and the module receives data again, it will not report a new
URC until all the received data has been retrieved via AT+QIRD from buffer.”

Hierbij onze implementatie van receiveUDP (deze zou je moeten verbouwen voor Arduino):

size_t BG96::receiveUDP(const int socket, uint8_t* buffer, const size_t len, const uint32_t timeout) {
uint32_t start = us_ticker_read();
	bool found = false;
	// Ignore ip address and port for now
	size_t size = 0;
	char crLf;

	//No +QIURC will be sended when the buffer already contained data.
	//So check if we have already some data ready to be read
	LOG("Reading UDP buffer\n");
	sendCommand("AT+QIRD=%d", socket);
	receive(DEFAULT_TIMEOUT, "+QIRD: %d%c", &size, &crLf);
	if (size == 0) {
		LOG("Buffer is empty. Waiting for incoming UDP messages\n");
		while (us_ticker_read() - start < (timeout * 1000)) {
			// +QIURC: "recv",<socket>
			int sock;
			char crLf;
			LOG("Checking for incoming UDP message\n");
			if (receive(DEFAULT_TIMEOUT, "+QIURC: \"recv\",%d%c%c", &sock, &crLf, &crLf)) {
				LOG("Got a incoming UDP message\n");
				if (sock == socket) {
					LOG("UDP message is from the same socket\n");
					found = true;
					break;
				}
			}
		}
		if (found) {
			LOG("Reading UDP buffer\n");
			sendCommand("AT+QIRD=%d", socket);
			receive(DEFAULT_TIMEOUT, "+QIRD: %d%c", &size, &crLf);
		}
	}
	if (size != 0) {
		LOG("Got message size: %d\n", size);
		size_t bytesToRead = (size <= len ? size : len);
		LOG("Bytes to read: %d\n", bytesToRead);
		//drop ip information and other stuff till we find the new line character
		while (crLf != '\n') {
			read(DEFAULT_TIMEOUT, &crLf, 1);
		}
		read(DEFAULT_TIMEOUT, (char*)buffer, bytesToRead);
		for (size_t i = 0; i < bytesToRead; i++) {
			LOG("%02x ", buffer[i]);
		}
		LOG("\n");
		return bytesToRead;
	}
	return 0;
}

Success

Oke bedankt! Als het in de NB-IoT specs staan dan zou het wel 512 bytes blijven.

Hoi allen,

Ik ben aan het testen wat de maximale pakketgrootte kan zijn voor een NB-IoT uplink bericht.
Nu staat in de SARA N2 AT en Quectel BC95 documentatie dat de maximale grootte 512 bytes mag zijn.
Ik heb dit getest en bij 512 bytes komt het bericht nog netjes en compleet aan bij de server (via Oceanconnect).

Tijdens het installfest hoorde ik echter 250 bytes. Wat ondersteunen (of gaan ondersteunen) jullie maximaal aan pakket grootte? Kan ik 512 bytes blijven aanhouden als een maximum of gaat dit verlaagd worden?

512 bytes zou erg mooi zijn

Mvg,
Melvin