[EG]

@skovarik

I just realized a more important item missing from the API – GET /api/v2/apps/:id returns a list of app configs, but does not list the name for each one, so there is no way to programmatically get the config id fro the name and then install it on the device. Can you please add this as an enhancement request.

[EG]

Do you plan to add an API to upload custom app config files to deviceHQ? I see that I can apply them, but I need to upload them manually. This would close the gap on our automation.

Thanks,
Elizabeth

[EG]

That’s great. Can you please post here when it has been updated? Thanks!

[EG]

Hmmm. I just tried to create a directory on /var/oem both with and without sudo and it said it’s a read-only filesystem. I could change /var/oem, but then I worry about it reverting in a firmware upgrade.

/dev/mtdblock6 on /var/config type jffs2 (rw,relatime)
/dev/mtdblock7 on /var/oem type jffs2 (ro,relatime)

[EG]

Thanks.

[EG]

I entered a ticket and was informed that Multitech was aware and was working on the problem.

[EG]

Yes that’s great news!

[EG]

Thanks for the explanation. The MTCAP2 are the POE ones?

Maybe something could be added to the interface to explain this?

Thanks!

[EG]

I take it back. I have to install a bunch of other packages with opkg first.

[EG]

I can’t vouch for all your versions. I just installed python3 on a MTCDT-246A running 5.2.5 with the following commands:

opkg update
opkg install python3
python3 -m ensurepip
pip3 install mypackage

[EG]

I’ll have to try this when I am next in the same location with this node and gateway, but would you expect the network server to perform full ADR processing based on SNR/RSSI at this point? In other words, if it’s at highest power (0) and DR (5), would you expect it to ask the node to lower its power if the SNR/RSSI are good enough?

[EG]

OK, thanks for your help.

[EG]

Thanks. I’ll give that a try.

[EG]

Jason – sorry for one more question. How do I send a message and specify the port? I don’t see anything here that allows that: http://www.multitech.net/developer/software/lora/lora-network-server/mqtt-messages. I only specify the application payload as in “down JSON fields”.

I would have to do it through the AEP API as documented here?
http://www.multitech.net/developer/software/aep/conduit-aep-api/collection-endpoints-conduit/lora-packets/
I’m not sure how to format it.

Thanks!

• This reply was modified 5 years, 2 months ago by EG.

[EG]

I have a question regarding the mac command to change the channel mask. Do you know if that is supposed to (according to spec) set the channel mask to the new mask or if it masks it – I’ve seen some code in the stack where it &’s it, which would just turn off disabled channels but not turn on enabled ones, but the stack can be hard to follow in places. I’m trying to determine if I need to first send a command to open up all channels, then send the channel mask.

At join time, all channels are active. so it doesn’t matter with the one the gateway sends.

[EG]

The stack does not expose the channel/subband that was used for the join request. I would use it if I could. The second round of hopping is a waste of time, power, & bandwidth. I may have to modify it to pull it out.

Yes, it’s tricky. That’s why I have my end-devices go back to join after they detect no communication for a while, so they’ll hop until they find it. It sounds like aside from optimizing out the second round of hopping there’s really no better way.

Oh, so you’re saying to send a normal downlink but with the payload formatted to contain a MAC command (port=0, formatted as a link ADR req). Ah, thanks, I didn’t think of that!

[EG]

Hmm. OK. I’ve seen that code in the stack, but I didn’t think it was being hit here. I’ll investigate further.

Regarding “The application can send ADR commands on port 0 to end-devices to change channel mask” – Can you please explain this? Do you mean an application running on the gateway using mqtt?

My issue is this – assume I boot up my end-devices and the gateway. How do they negotiate a shared subband when they don’t know which subband to use, and then be able to change subbands at will.

My plan was to bring up my end devices without constraining the channels. They hop on all channels until they find the gateway and join, then hop again sending an init message until they find the gateway again, at which point the gateway will send the channel mask down in the receive window and the channels will be constrained to the single subband. If I want to switch subbands, I remotely change the subband and channel mask of the gateway, save, and restart the network server, and my end devices will go back to join after realizing they cannot reach the gateway for a while, repeating the process until they are on the new subband.

I’m sure this has come up before, do you have a recommendation for best practice for this?

Thanks!

[EG]

I did some testing with the tip of the dev branch today and it looks as if the mcu remains on throughout rx and tx rather than going to sleep and waking up via txdone/rxdone interrupts. Is that true? If so, do you have any plans to change this? This can consume a lot of power, especially during the long dr0 toa.

[EG]

Thanks, that’s perfect!

[EG]

Just to be clear – it will also sleep between send and rxw1?

[EG]

It looks to me like explicit header mode is used and thus only the downlink header crc bit is relevant.

[EG]

Just to make sure I understand – the crc setting changed as of network server version 1.0.26, which changes the packet format. I’ll certainly double check my code and versions, but I would think that I would get more than sporadic errors if there were a header format mismatch, no?

I’ll double check the network server version on the 3.3.13 gateway. It’s in my lab and I won’t be there until Monday. I’l also play around with the crc setting.

Would flashing the mlinux-factory-image update the network server? If I’m reading this (http://www.multitech.net/mlinux/images/mtcdt/3.3.13/analysis/ipklist.txt) correctly, the package I flashed would install lora-network-server – 1.0.41-r1.0? So it does seem the two network servers in question have different crc settings.

I haven’t swapped cards because the problem started happening on a sw update. I can try that, though.

How would I check the frequency accuracy?

[EG]

I was about to reply that I hadn’t updated the network server, but I went to check and I have version 1.0.13 running on my mlinux 3.2.0 gateway. I don’t remember upgrading it, but I guess I must have.

The gateway and node are 1-2 meters apart. This is with DR4.

On the 3.3.13 gateway, the reason I flashed it originally was that I messed up the network config and bricked it (it wouldn’t complete boot), so I flashed 3.3.13 using uboot. I can’t tell you what version the network server was before that. I saw I was having the mic/address problem (which actually hung my node sw because I had a bug when handling the bad acks, so I’m sure I’ve never gotten them before on either gateway), so then I tried to downgrade (which didn’t work), then went back to 3.3.13.

[EG]

Thanks for your response.

No, It does not. I get these errors on the order of once every 10 minutes when sending 1 msg/sec, BTW.

[Author]

Posts