Arduino MKR NB1500: lukt niet om te verbinden.



  • @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



  • @Stefan-de-Lange

    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



  • @Stefan-de-Lange Good point, I use the Arduino IDE.



  • @Crowdsourcer I use realterm, it works well with binary data:

    ca8145ff-6a1c-4737-9b96-f5b3b61116d8-image.png



  • @Stefan-de-Lange Thanks, RealTerm works great and I could easily send sixteen 0x00 and it was received as 0x00 at TMobile. So it means that something is wrong with my Arduino code implementation. Really strange that my script fails on 0x00.



  • Whats the reason you dont want to send the data as Hexstring?



  • @Martijn-Kooijman double the amount of data! Suppose there is a limit of 500 bytes (hypothetical, but I don’t know exactly how much T-mobile allows), I would then only be able to send 250 bytes.
    I can binary using terminal emulator so it should be possible programming it correctly…



  • I think it is 1600 bytes but that is per message you can always send more messages. I dont know if Tmobile supports non hex string format. Maybe first get it to work with hex and if that works try binary?



  • @Martijn-Kooijman @Stefan-de-Lange
    Solved! After receiving @ I use following command:
    SerialSARA.write((uint8_t*)&payload, payload_size);
    (It was first a Char array and this worked not ok for value 0 but strange enough worked for other numbers).
    Next issue I will focus on is the sleep mode power consumption, getting it below 1.2mA.



  • @Crowdsourcer I use the portable version of the arduino ide so I can have multiple installations with different settings and/or library/board versions. This may help you not having to reinstall after changing boards.txt (you can just make a copy of the folder before making changes)



  • @Martijn-Kooijman
    I commented out the port initialisation in
    …\AppData\Local\Arduino15\packages\arduino\hardware\samd\1.8.6\cores\arduino\wiring.c
    looks like this now: //pinMode( ul, INPUT ) ;
    I now measure a sleep current of 0.95 mA, still way too high for IoT. I did reset the board, but no change. I did read about MKRFOX1200 achieving 50 microA, so should be possible for this one also…
    I measured it at the LiPo wires. My sensors consume very little power, so they are not to blame, or is the SAMD pin assignment changing the currents within the SAMD internally?


Log in to reply