Just another question:
I’m following the LMIC-Node to work with an Adafruit Feather M0 with RFM95 'LoRa Radio as you suggested me. Thank you for this.
Since this End Device is not present in the “import End Devices List”, I have to manually Register it (in the TTN console).
I have choosen:
The recomended Frequency Plan (Europe 863-870 - SF9 for RX2)
MAC V1.0.4 (as recomended in the introductory video on TTN)
Now I need to select a Regional Parameters Version, however looking at https://lora-alliance.org/wp-content/uploads/2019/11/rp_2-1.0.0_final_release.pdf it is not clear to me which value I should choose in the List for Regional Parameters Vesion.
According to the documentation, v1.0.3rA is aligned with LoRaWan 1.0.3, but it is not clear to me which Specification Revision is aligned with LoRaWan 1.0.4.
(Or shall I better use LoRaWAN V1.0.3 and then Regional Paramenters v1.0.3rA ?)
Thanks again for any help. Cheers
thank your help, I managed to have Feather M0 Node running, it performs some measurement and I see that the measured data (payload = 4 * uint8_t) is correcly uploaded to the Console.
Now my question is how to access the payload outside the console. I see that I can export as JSON … Since I have no experience with JSON: is there any place where I can find some documentation on this topic (JSON Export)?
Look on you console - application - select your application - integration - Now look at the bottom right and you will see documentation — select that, it will navigate you to the relevant information
I’m using the LMIC-Node Library with a Feather M0 Board. I read a Temperature Value from a Sensor.
On the local serial output I can see that the code is running as I’m expecting once every 60 seconds.
However TTN Console only shows me the first measurement.
On the serial output I get:
TEMPERATURE TT 1424
000016260749: Input data collected
COUNTER value: 5
000016260749: Uplink not scheduled because TxRx pending
When planning how often you will be transmitting the GPS location you should plan for the worst case situation when the node is at the limit of the working distance from the Gateway.
In these cases the node can go to transmitting at SF12. Since these are the longest packets (in air time terms); to keep within the fair use policy, the node should restrict itself to sending the location around once per hour.
OK, thank you. I still need some help in the strategy used for testing.
Now I see that using SF9 and a payload of 4 bytes the airtime calculator gives me an avarage of 7.6 messages per hour.
To be fair, I decided for an WAITFOR_SERIAL_SECONDS=600 in platformio.ini. This should mean 6 messages per hour. However in this case no payload arrived to the console.
With WAITFOR_SERIAL_SECONDS=450, however some payloads arrived(?)
Unfortunately I was not able to perform a long and continuous testing session.
What would you reccomend me?
WAITFOR_SERIAL_SECONDS=600 and wait for a longer time?
Was just a coincidence that data transmission worked at a higher frequency (450) and did not worked with 600?
You’ll need to perform meaningful testing, hopefully including some sort of debug serial output from your end device in order to understand what it is trying to do.
You perhaps need to re-read the documentation - this setting is how long the device should wait at startup for the USB serial port to connect to the computer. It has nothing to do with how often the device sends an uplink.
Hi,
I’m sorry, I gave you a wrong information in my last email. Today I was able to perform some more tests.
I’m using the Adafruit Feather M0 with RFM95 Radio and the LMIC-Node library to perform some temperature measurements.
The payload is 4 bytes. I’m using SF9 and according to the airtime calculator I should not send more than 7.6 messages per hour.
So I decided to put a delay of 600s (10 min → 6 messages per hour < 7.6 messages per hour).
Whatever I do, I’m only able to successfully transmit the first payload. After the first succesfull trasmission, I always get the message “Uplink not scheduled because TxRx pending”.
Have I forgot to “restart” TxRx in some way?
Shall I wait for a longer time before starting to complain? As you can see, the node did not success to send the data three times. The TTN Console, accoringly, only showed me the arrival of the first payload.
Something about the way you’ve architected your program has prevented LMIC from running its scheduled events for the RX windows that need to follow that transmit. Because you didn’t let LMIC finish the job you already asked it to do (and in the timely manner it needed to), it’s blocked and not accepting new transmissions.
You can’t simply put a delay() is task oriented code like this, or at least you can’t until you’ve determined that there are no more pending tasks.
If you look a bit, you’ll see examples of how send scheduling is usually done with LMIC, also in many practical cases there’s the need to enter a low power sleep mode in between.
As this has moved well away from getting a Pi gateway running I’ve split the topic. I’ve also formatted the lengthy serial output using the </> tool on the toolbar. Please make use of them when posting.
As explained above, there is a clear place in the code for the send job that will be called at the interval you set and should compile the payload and then leave the code to do its work, if put anything outside of that function you need to really know why you are doing so.
