Arduino MKR NB1500: lukt niet om te verbinden.
-
@Stefan-de-Lange I dont have the upgrade yet but willupgrade as soon as I do!, in the meantime I read somewhere that It could work if you enable a sim pin. And that works!
-
@Stefan-de-Lange
Yes, there seem to be test solder pads that belong to the SARA chip, but nowhere mentioned what they are (there are 6 of them). I prefer to wait for a serial pass through update such as tested by: https://forum.arduino.cc/index.php?topic=628808.15 Problem seems that it is difficult to get the update file from Ublox (they only provide the USB flash update). -
@Crowdsourcer I would not recommend taking the route mentioned in this arduino forum post. Upgrading FW is a critical process and you may permanently brick the modem by doing it manually. Better to let the ublox application handle it for you.
@Stefan-de-Lange
Yes, there seem to be test solder pads that belong to the SARA chip, but nowhere mentioned what they are (there are 6 of them).I found the following in the design documentation:
Looks like it’s relatively easy to solder two wires (+ gnd) to the pads to get access to the USB interface.
-
@Stefan-de-Lange @Crowdsourcer I did this yesterday (Tp1 & tp2 for d- en d+ and also solder bridge at tp3 for v_usb_det) and connected it. a new device was detected but Iand the flasher program connected made a backup of nvm but could not flash the sara. The 6 pins mentioned by @Crowdsourcer is a debug header :
https://forum.arduino.cc/index.php?topic=442133.0 -
@Martijn-Kooijman Could not flash? What do you mean exactly?
-
@Stefan-de-Lange I received the firmware update file from ublox and tried to flash it to the sara r410 on the mkrnb1500 with extra usb cable soldered to the tp1 - tp3 pins. but it didnt succeed (because you suggested that to @Crowdsourcer
-
@Martijn-Kooijman It has always worked fine for me. I can help you but I need more info, the picture is unreadable. Can you copy paste the entire log/output of the program?
-
@Stefan-de-Lange sadly I only have this screenshot during update at the end it stated putting the sara in download mode then it counted link<0><1>…<15> then it beeped and said failed. I tried it several times but couldnt get it to finish correctly.
-
@Stefan-de-Lange text on photo:
Using USB portProcessing SARA-R410M-02B-01-L0_0_00_00_05_08.dof
please turn on the device and dont disconnect power supply
waiting for device
Device found!
Mobile version report: PASS
Ext Mobile Mobile SW Rev. L0.0.00.00.05.06-> Backup of legacy NV object
a
-
@Crowdsourcer I see that the socket id of the created socket is 2. In the consecutive commands you should use that Id. All other steps seem fine.
-
@Stefan-de-Lange I tried to update again on another computer and I see that during the update procedure a new device appears (qhsusb_bulk) but my machine does not have the drivers for it do you have any suggestions?
-
@Martijn-Kooijman @Stefan-de-Lange
Arduino sent me a message that they have close my “firmware update” ticket. Their recommendation is to use the serial passthrough method as outlined in: https://forum.arduino.cc/index.php?topic=628808.15 -
@Crowdsourcer Shows Arduino didn’t properly read the datasheet of the u-blox when they made this board. USB console access should come out of the box
-
@Stefan-de-Lange You were a great help with the commands for communicating with T-Mobile. I meanwhile have a program that seemed to work. However, I recently discovered that the message I send after the “@” is not always arriving. Today I discovered why: if the bytes contain certain print control characters it modifies the data and only a few bytes arrive at T-Mobile (or nothing). My script uses this function to send serial data to the SARA module (and works fine for AT+ commands, but not for binary data:
/**- Send AT command to u-blox module
*/
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;
}As you can see it uses a “print” statement, but I think it should be a “write” statement. So I changed cmd(payload) that is started after receiving the “@” the script into:
for (i=0;i<payload_size;i++){
if (SerialSARA.available()){
SerialSARA.write(payload[i]);
}
}
But still nothing arrives at T-Mobile with certain bytes (that translate to “ETX”, “SOH”, “CR” “LF”… Help very much appreciated! - Send AT command to u-blox module
-
Additional info: code that also does not send the data:
for (i=0;i<payload_size;i++){
while (!SerialSARA.available()){}
SerialSARA.write(payload[i]);
}
//Also not working:
Udp.beginPacket(“172.27.131.100”,15683);
Udp.write((const char*)&payload, payload_size);
Udp.endPacket(); -
Update: I can send data but at the IOT portal always the same number arrives:
41542b55534f53543d2d312c22302e30
I use Udp.write((uint8_t*)&payload, payload_size) after receiving the “@”. -
and thats what you receive at theend point also? Im asking because ive seen that the number in portaldoesnt always show the latest message.
Also did you try to do it manually with serailpassthrough? -
@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();