Is the standard tracker software on the Sodaq One capable of receiving upstream messages? I mean not just an Ack on the downstream message, but generic data. If so, are there any config restrictions that should be taken into account? For instance do you need to send the upstream data on certain channel, spreading factor, datarate, port, etc?
A node has two receive windows after transmitting its payload: RX1 and RX2. RX1 uses the same channel and spreading factor as the node has used. RX2 uses 869.525 MHz. According to the LoRaWAN specifications, this should be SF12 and maximum 27 dBm output power. However, TTN and KPN use SF9.
I’ve managed to send some data to the mote via TTN, which does not ask for any parameters on the web interface.
On Semtech, you need to specify channel, port, and SF/BW combination, and I haven’t been able to find a working combination there yet.
The specification of the reconfig OTA message is as follows (from github)
Fix Interval default -> uint16 (2)
Fix Interval alternate -> uint16 (2)
From (EPOCH) -> long (4)
To (EPOCH) -> long (4)
GPS fix timeout in seconds -> uint16 (2)
Does anyone know what the byte order is for these parameters?
The parameters on Semtech are uplink parameters: node to gateway. You want to send a downlink message: gateway to node. The RX1 and RX2 parameters are determined by the gateway.
i have problems to build the uplink parameters for TTN webinterface.
Fix Interval default -> uint16 (2) Fix Interval alternate -> uint16 (2) From (EPOCH) -> long (4) To (EPOCH) -> long (4) GPS fix timeout in seconds -> uint16 (2)
I did it like this:
Fix Interval default=30min=>001E Fix Interval alternate=10min=>000A From=7:00=>00070000 To=18:00=>00120000 fix timeout=120sec=>0078 HEX:=001E 000A 0007 0000 0012 0000 0078
The hex is send over the TTN network and the ONE does commit it with an OK but does stop sending frames.
If I reboot the ONE new parameters are not saved.
What am I doing wrong?
Would you please give an example how to build the hex?
Thank you very much
@mateng, I have tried it once, successfully from the TTN-webpage.
This was my test message: it puts the default interval at 1 minute and the GPS timeout at 64 seconds
01 00 00 00 00 00 00 00 00 00 00 00 40 00
01 00 | 00 00 | 00 00 00 00 | 00 00 00 00 | 40 00
So if I compare to your message, it looks like you have the byte order reversed, so you have a huge interval and a huge GPS timeout
Thank you very much!