Arduino MKR NB1500: lukt niet om te verbinden.
-
@Martijn-Kooijman Yes this number arrives at https://portal.iot.t-mobile.nl/projects/1544/devices a few seconds after I send it. I tried sending sending other values but it remains the same.
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). -
sorry I think I was not clear. What Imeant to ask is if you get the correct number at your application server. Maybe you can set the application server to winhook.info to test?
-
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:
-
I send my values as Hex values so only 0-9A-F characters are sent
-
@Martijn-Kooijman At T-Mobile I see 41542b… the first two bytes are a temperature and these bytes are received at “Allthingstalk”. 4154 hex unsigned is 16724 decimal and Allthingstalk converts this to a temperature using the following equation: T=coded/65535*100-40 and it show -14.48, so these steps are fine. The problem is that I have never sent 4154.
-
@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(); -
@Martijn-Kooijman I did a new tests where I use SerialSARA.println(“<<”); “<” is ascii code for 3c hex unsigned, so “<<” = 15420 decimal. This is nicely received at TMobile as “3c3c”.
(I get a nice confirmation of SARA with +USOST: … OK
But I do not want to send “<<” (because it can contain control characters with other codes) instead I want to send binary 15420 or as text “3c3c”. The old firmware wants it binary but so far I do not manage. I hope it is clear now. -
@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.
-
@Stefan-de-Lange I do wait for “@” and code is correct, otherwise I would not be able to send “<<” as explained in my previous post.
The holy grail is how to send binary in such a way that SARA treats it as binary (the old firmware in the SARA in the current Arduino requires one to do so). -
@Crowdsourcer Okay great
-
This is the code to send the USOST command which waits for the “@”:
cmd(“AT+USOST=0,“172.27.131.100”,15683,”+String(payload_size);String cmd(String cmd) {
l("cmd: " + cmd);
SerialSARA.println(cmd);
int timeout = TIMEOUT;
while (!SerialSARA.available() & timeout > 0) {
timeout–;
delay(1);
}
if (timeout == 0 || timeout < 0) {
l(“Timed out”);
return “”;
}
String result = “”;
do {
result += char(SerialSARA.read());
delay(5);
} while(SerialSARA.available());
l("rsp: " + result);
return result;
} -
@Stefan-de-Lange: Base syntax works fine, but it needs double the amount of bytes than the binary extended syntax. This is not ethical to use for narrow band IOT solutions. It is strange that I wait for the @ but it still does not do the binary syntax. Do I need to send an additional @ before sending the binary data? The manual states that I just need to send <length> bytes of data.
-
@Stefan-de-Lange
I can confirm that it is working now. I managed to send the CR code 16 times as binary code and it arrives as 0D0D0D… HEX code.
//Solution for sharing
//sending binary data in binary extended syntax for SARA module
//measure (here a t and h float are converted into scaled unsigned 16 bit temperature and humidity values)…
uint16_t temperature_coded=round((t+40)/ 100 * 65535); //scale: -40C=0, 60C=65535
uint16_t humidity_coded = round(h / 101 * 65535); //scale: 0%=0,101%=65535
char payload[payload_size]; //define array of char
//write coded measurements into the char array
payload[0] = (byte) ((temperature_coded & 0xFF00) >> 8 );
payload[1] = (byte) ((temperature_coded & 0X00FF) );
payload[2] = (byte) ((humidity_coded & 0xFF00) >> 8 );
payload[3] = (byte) ((humidity_coded & 0X00FF) );
//payload[…etc… sendcommand=“AT+USOST=0,“172.27.131.100”,15683,”+String(payload_size);
cmd(sendcommand); //cmd: see previous post
cmd(payload); -
@Stefan-de-Lange @Martijn-Kooijman
Thanks for the help, appreciated! -
@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. -
@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
-
@Stefan-de-Lange
Yes, I started now with fixed byte values. When I change the value of any of the 16 bytes to a value zero it does not send anything anymore. As soon as I change the zero byte to 1 it sends again. Seems like a SARA modem bug? -
@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…
-
@Stefan-de-Lange
I just checked with the passthrough sketch. I first send:
AT+USOST=0,“172.27.131.100”,15683,16
Then after the @ I send 0000000000000000 (16 zero’s). I get the ascii code for zero (this is 30 hex) 16 times at T-Mobile. So this is not binary!
At least with my code I could send binary as long as I did not send a zero. -
@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