Posts made by Martijn Kooijman

Thanks I think I tried these already but could not get it to work. what terminal program did you use? And maybe other things that are of importance?

@Crowdsourcer what instructions did you use, for me serialpassthrough did not work

@Stefan-de-Lange if you want to measure sleep current of the mkrnb1500 I would turn of all other peripherals. And I agree that psm might give better overall results if you send often but when you send once in a while (like I do) I think turning it off is more power efficient? The clock speed was just an example (arduino code is meant to be interchangeable between mcus so might not be optimal)

@Crowdsourcer do you turn off the sara module before sleep?

@Crowdsourcer the sleep current on the mkrfox1200 boards Ive used vary from 80 to +/- 180 uA but it very much depends on what pins you use. ( mkrfox1200 uses the -DVERY_LOW_POWER option in boards.txt)
@Stefan-de-Lange I dont think its only the board thats not optimised, but also the current arduino implementation. for example you could run the samd21 at lower speed.

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

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?

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

I send my values as Hex values so only 0-9A-F characters are sent

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?

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?

@Crowdsourcer said in More messages than expected on application server.:

VERY_LOW_POWER

Strange did you add the option in the same way as you can see for the mkrfox1200? Can you post (part of) the code where you fill the msg variable? also could you give a complete example of a msg that you send and what you receive? for example with webhook.info?

Would like to know your results! Do you use the mkrnb library or do you send the at commands yourself?

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

If you dont want to change wiringe.c you can also add -DVERY_LOW_POWER in boards.txt (thats what I did)

I was working, It send a message +/-55mA then went to deep sleep for 3 minutes and repeat

@Eric-Barten I still get the extra messages delivered even after deleting all but one subscriptions. Any thoughts on how to tackle this? Could it have something to do with downlinks not arriving? for example how lomg should I wait after sending before receiving?

@Crowdsourcer I measured the deep sleep current on the mkrnb1500 without changes to wiring.c I got around 400 uA, with changes 194uA, later it dropped to 35uA but I am not 100% the 35uA is correct

@Crowdsourcer I did not have the opportunity to measure the sleep current myself but was wondering if you tried to comment out the following lines in wiring.c in the arduino core samd folder?

#ifndef VERY_LOW_POWER
  // Setup all pins (digital and analog) in INPUT mode (default is nothing)
  for (uint32_t ul = 0 ; ul < NUM_DIGITAL_PINS ; ul++ )
  {
    pinMode( ul, INPUT ) ;
  }
#endif

Maybe this is related to my problem I dont receive downlinks since a couple of days on my device at all since a couple of days ago

@Eric-Barten Thanks, that worked!

@Eric-Barten @Stefan-de-Lange Yes, It would be nice to know how how to manage the subscriptions, see https://forum.iot.t-mobile.nl/topic/556/delete-subscriptions-via-api
The file supplied on the website for posstman di-oes not include the correct json syntax to use it.

Also I am not sure the extra events are lifecycle events. I get to types of messages:
1:

{"reports":[{"serialNumber":"IMEI:352753096136229","timestamp":1589356837854,"subscriptionId":"80ec5c8b-209a-47d8-8e8c-ef0dba0343b1","resourcePath":"uplinkMsg/0/data","value":"5a204fb8e506ffc304f73000"}],"registrations":[],"deregistrations":[],"updates":[],"expirations":[],"responses":[]}

and
2:

{"reports":[],"registrations":[{"deviceType":"device","serialNumber":"IMEI:352753096136229","timestamp":1589358107277,"make":"Generic","model":"Sensor","groupName":"TMNL.STARTERKIT.CON_0000001542","imsi":"N/A","protocol":"N/A","tags":"N/A","subscriptionId":"bf3aedf1-26bc-4e28-b739-7debac04b68e","deviceProps":{"device/0/imsi":"IMSI:901405700007913","device/0/model":"Sensor","uplinkMsg/0/data":"000000000000000000006040","device/0/manufacturer":"Generic","connectivity/0/port":"2390","connectivity/0/mncmcc":"","location/0/longitude":"","device/0/endPointClientName":"IMEI:352753096136229","connectivity/0/cellid":"","connectivity/0/ip":"10.128.0.90","location/0/radius":"","connectivity/0/rat":"","location/0/latitude":"","connectivity/0/apn":""}}],"deregistrations":[],"updates":[],"expirations":[],"responses":[]}

The second type is always the same, the first type sometimesgives a very large payload:

{"reports":[{"serialNumber":"IMEI:352753096136229","timestamp":1589355068395,"subscriptionId":"80ec5c8b-209a-47d8-8e8c-ef0dba0343b1","resourcePath":"uplinkMsg/0/data","value":"428ae3f0080234000ecc30a80d006f0d0001eeeaf00a18150af996fd3f410e00002b0e28100e87bb01001d2a8f18080a0204000029ac0418150a0100fd3f410e2001210a2c100e100ec007dfbc0f18080a0504000021510718110a0100fd3f410a2001210a02100e510e0018080a02000000293a0418170a0495fd3f41100000210a64100e104a00002ae02ec20c18080a05040000219d0818120a0100fd3f410b2001210a0c100e4d0e6f0118120a0100fd3f410b2001210a0c100e4b0e590018080a0200000029250b180a0a11fc0020231d00000018080a11fc450029bdff18080a0100300121f60d"}],"registrations":[],"deregistrations":[],"updates":[],"expirations":[],"responses":[]}

sadly starting 0:00 this morning I started receiving the long messages again (I changed nothing) so still not working as expected for me.