[wkhatch@unimar.com]

Ugh, all that was needed was restarting the browser. Close this out lol

[wkhatch@unimar.com]

I don’t know. How am I to determine that without being able to login, which I need the user account for, no? Just got three more of these in today, and they’re all doing the same thing, too…

[wkhatch@unimar.com]

Thanks for the reply, Ajay; I just saw this today. So, you’re scp the .tar.gz file to /var/tmp, and not the SD card? I was trying to do it from the sd card, yes. I’m willing to abandon that strategy, as it seems running apps off the card is just too unreliable; they die within a few days, and all sorts of other weirdness that it’s just not sustainable or reliable. Thanks again for the tips.

[wkhatch@unimar.com]

anybody using this at all? opinions? anything? lol

[wkhatch@unimar.com]

Sorry, posted this in error to the wrong forum. Moving it to devicehq.

[wkhatch@unimar.com]

Thanks Jeff; didn’t see this until today. I had messed up the sudoers file, because the version of vi was alien to me, so I used nano instead, and… clearly didn’t end so well. I ended up restoring it, but good to know about u-boot. Thanks again.

[wkhatch@unimar.com]

Just following up for completeness sake, as I’m sure other people will hit this as well, so hopefully this helps somebody.

We’d determined that an upper safe limit as to over all data message size would be around 40 bytes, but, that this is also dependent on the link speed. We’ve since dramatically lowered that to 11 bytes, which seems to be the lowest, most consistent size where we don’t experience problems. We’re just using standard bit packing to get the message size down. During our testing, we did observe several successful transmissions where we were using protobuffers to package up the message, and the message size was significantly higher than 11 bytes, but this was inconsistent; sometimes it would work perfectly, other times it would silently fail, or worse, take down some of the application stack. I am assuming there is some programatic means of controlling the transmission data rate, on the sending device, or maybe this is a lora network setting on the gateway, but I do not know, and have not been able to find, anything documented along these lines. Bear in mind I’m not an RF engineer and have limited knowledge as to the internals of how lora or any other protocol works, so I’m just assuming that we can somehow do these things, otherwise, why would the spec provide for so much more than we can practically use? Anyway, as of now, we’re limiting to 11 bytes total on the payload, until some time in the future we figure out a better solution that accommodates additional data.

[wkhatch@unimar.com]

It turns out our problem was due to message size exceeding the lora spec limits. The sensor device seems to invalidate the existing session, after it is not able to successfully send a message, and subsequently was rejoining on each iteration. We’ve refactored the sensor code to send raw binary data, and my assumption is that I’ll still get a base64 encoded string off the mqtt topic at lora/+/up, and from there, I can do what I need to convert. Thanks for all the help, Jason

[wkhatch@unimar.com]

I haven’t done anything with respect to firmware updates since getting this gateway.

The device I’m testing against is new to use, and developed using an arduino mkr wan 1310 https://store.arduino.cc/usa/mkr-wan-1310, which is using a murata lora radio, I believe. Previous versions of this sensor were able to connect successfully to a rakk raspberry pi, but what I’m using is a different build of the original. I do not believe this build has been tested against the rakk unit.

I’m going to try using three other sensors, which are identical to this one, to rule out some issue with the sensor itself, or some configuration key mismatch, etc.

I have another MTC, which is dealing with a different set of sensors (netvox mostly), which are in a staging environment, so I can’t really take that one down for this test, unfortunately.

Thanks again.

[wkhatch@unimar.com]

I’ve tried all sub bands, and still not getting anything on up. Is there something additional I should be doing when changing the sub channel, to make sure we have a clean reset?

[wkhatch@unimar.com]

Conduit is model MTCDT-L4N1-246A, firmware 5.2.1. Lora card model: MTAC-LORA-H-915 with hardware MTAC-LORA-1.5 I don’t see anything specific to mPower anywhere?

From the Packets page, Recent Rx Packets:
SNR: 7.2, and RSSI: -54, which was a JnReq

The developer has no idea what sub band; I’ve requested info on the module/shield used to try and track that down

I cannot get session keys from the device; not possible for me to access it, and not sure there’s any sort of api on the device that would return it to me if I did have access.

The flow on every lora transaction loop is:

join_request
packet_recv
packet_recv
joined
packet_sent
packet_sent
packet_sent

I don’t know if it’s getting the join response from the gateway or not.

For now, I’m debugging this by adjusting the sub band setting, and then deleting any existing session keys, then waiting for the next batch of messages from the sensor; not sure what else I can do

Thanks for the hand on this; much appreciated.

[wkhatch@unimar.com]

Jason, I’m not sure how to confirm the session keys match? Can you summarize that process, if possible? It appears we get a join request each time the device sends data. We were on sub band 2, and previous engineer suggested changing it to 7, while awaiting confirmation from the device developer as to which one we should be using. Changing to 7 hasn’t resulted in any change; still not getting lora/+/up

[wkhatch@unimar.com]

Thanks, Jason. The deveui and app eui line up, and I can see the join requests and sessions in the web ui. There’s one other gateway, but I don’t see any messages matching the device in question. I am getting all the other messages under lora/#, just not any up messages. I’m seeing this in /var/log/lora-pkt-fwd-1.log, however. Not sure if that’s at all related to the the mqtt publish on the up topic or not.

JSON up: {“rxpk”:[{“tmst”:1017483540,”chan”:3,”rfch”:0,”freq”:904.500000,”stat”:-1,”modu”:”LORA”,”datr”:”SF8BW125″,”codr”:”OFF”,”lsnr”:-13.8,”rssi”:-97,”size”:242,”data”:”3ENhcdwIW3/LJS/LPFDTy
5SVbn5m2ahByPy5hcVV818/3c+gLwUFmedr4U5disLFYi2JBmK9lyjtASXw06oYZ4BT3Tyro5GPddZtkMN/dwKFgi9CbrPN8pm8riCJvi8yWSErwLgtYJH+q/79A/uBclp0FVi1vUUtf4xCRfwwBlRBgom9K9Yvu9+NNRa9YPNIqwVPu5/bxoPD7VwtJQEui
egcUXNF4OyQYeVfWGLUp9AnL1Oytnn942SoGKdjyb72YjRmhJ8nrj8inlT1Dq/SJV+wh/7oSyeG6B2bG2BItJegfZPMkyVgse6Aia5rcr1SkG0=”}]}
INFO: [up] PUSH_ACK received in 0 ms

Any other debugging steps I should consider? Thanks again for the reply.

[wkhatch@unimar.com]

I worked around this by making sure the user my app runs as is also associated with the disk group, so it picks up the right permissions. And yeah, fat32 fs ignore linux permissions aside from whatever they’re initially assigned, so chmod, etc will have no effect; I haven’t found any way of changing them yet.

[wkhatch@unimar.com]

ext3/4 were no go’s, but FAT32 works, assuming you’re only accessing as root; everybody else outside of root:disk will have no access, which implies you have to run the apps as root; also not really great, but I’ll take it at this point. There’s probably something to be done to change it’s default permissions, umask, etc to at least allow read and execute for world, so I could assign directory level permissions as appropriate, but not going to dig into that right now.

[wkhatch@unimar.com]

Awesome, thanks Jeff.

[wkhatch@unimar.com]

So, the card was formatted using sdformatter, as HPFS/NTFS so that’s likely part of the problem. I’ll try it on a different machine using a different utility. I think the device should include formatting utilities so you can manage all this directly on the device. Thanks for the clarity on supported fs types; appreciate it.

[wkhatch@unimar.com]

Yes, I’m doing all this with either sudo or root. Do we have to use this AppManager application? I really don’t want or need another piece of middleware to deploy an app if I don’t have to. I know how to hook into monit, I just can’t carve out the space for my apps, and then getting the code or binaries on the device is a challenge, mostly due to this space issue. scp will fail if the file is too big, and I’m not able to scp to the card storage, etc.

[wkhatch@unimar.com]

No change in behavior after following the steps at the above link. Any access attempts to /media/card return “No such file or directory”

fdisk -l:

Disk /dev/mmcblk0: 127.8 GB, 127865454592 bytes
255 heads, 63 sectors/track, 15545 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

        Device Boot      Start         End      Blocks  Id System
/dev/mmcblk0p1               3       15546   124852224   7 HPFS/NTFS

• This reply was modified 4 years, 3 months ago by wkhatch@unimar.com.

[wkhatch@unimar.com]

For what it’s worth, this article https://www.multitech.net/developer/software/corecdp/applications/improving-sd-card-performance/ indicates that there’s an entry in /etc/fstab specifying the sd card, at /media/card, but there is no entry like that in my fstab. Instead, the closest I’ve got is:

tmpfs /run tmpfs mode=0755,noexec,nodev,nosuid,strictatime 0 0

[wkhatch@unimar.com]

No, I didn’t.

[wkhatch@unimar.com]

I reset the Lora network config to defaults, and that resolved the Save and Apply issue. From there, I was able to reconfigure and aside from the other issues I mentioned (Backup and Restore didn’t work), and the ssh config for no password, things are fine.

[wkhatch@unimar.com]

Disabling password auth in /etc/ssh/sshd_config seems to completely disable ssh. I can enable public key, and that works fine, but as soon as password auth is disabled in the config, ssh stops working, and all connection attempts are refused.

[wkhatch@unimar.com]

The link included by the OP is 404. Is there any documentation about means of resetting? I haven’t found anything beyond the quick info in the product Hardware Guide pdf.

[Author]

Posts