I bought an iC880A-SPI board and wired it up to an Orange Pi Zero a few years back, but never managed to put together a device properly and it got abandoned.
Well, I revived this box recently and reinstalled the gateway with basicstation. I also put together a device prototype with parts laying around (ESP32C3 and an Adafruilt RFM95W). I managed to get Zephyr’s class_a sample program working, it is able to join TTN and exchange messages. Yay!
Now, to the issue: I cannot get the default data rate of 0 changed. I am enabling adaptive data rate with lorawan_enable_adr(), which returns no indication of success. Calling lorawan_set_datarate() fails with -EINVAL no matter the datarate requested or the time I call this function – before or after joining, around confirmed or unconvirmed transmissions. The gateway and device are very close, I get RSSI -17dBm on one and -40-ish dBm on the other. I should be able to use the highest possible data rates with no issue?
I should also note that neither the gateway nor the device scale down their TX power. They’re basically shouting in each others’ ears. I can’t find any API in Zephyr’s lorawan subsystem driver to adjust that. I haven’t even looked at basicstation’s config.
Far too loud and close……search /read forum wrt correct degree of separation/absorption in between. Remember this is a Lo ng Ra nge technology and devices will be hearing a distorted version of signals and commands. This comes up almost weekly as a potential problem. Oh, and avoid confirmed messages……again read forum for why, and FUP.
Indeed, and I am aware. I’m just playing and prototyping. I would expect the network stacks to be aware as well and scale down TX power and adjust SF and coding rate accordingly. This is the whole point of the post.
Firstly, If the LNS hears well enough and commands an SF scale under ADR the Device may not hear correctly in order to act on the command! The stack will be oblivious if obscured by corrupt signals. Secondly, ADR adjusts SF 1st and fore most…… only once SF down to SF7 will next steps be to start dealing down Tx pwr……
Physics doesn’t care what you are doing, if you are overloading either or both ends of the link there could be a whole range of values being reported.
This is probably the most common issue for getting started - if you search the forum you’ll find lots of repetitions of “5-10m and a solid preferable brick wall between them”.
OK, well, both devices hear each other loud and clear (way too loud as mentioned), there are no bit errors, SNR on both sides is between 8 and 10. Given those, what prevents the system from switching to a lower spreading factor and scaling down TX power is my question. Is it the config of the gateway? Settings on the device? Some additional negotiation that needs to happen?
I could share additional details on the setup if this will help, but it’s pretty vanilla right now. I’ve followed the guide for setting up a RPi+iC880A gateway verbatim, device is running this sample with a couple of modifications: one in every 20 messages is confirmed; I’m trying to enable ADR; trying to set higher data rates which fails.
I could try adding an attenuator on the antennas (or at least on the device), but I’d rather not play with a soldering iron on the RF paths.
Actually, the range of values reported is pretty narrow and consistent. Introducing some loss in the RF path does not help either – it’s always SF12BW125.
RSSI is still a bit high but a more acceptable figure - we’ll skip over the actual construction of your refrigerator.
ADR often takes 30 or so uplinks for a re-calculation. But will almost always be dialled back on join if needs a big adjustment - like straight to SF7
Is the device console showing any MAC commands being queued for downlink?
If you have had “quite a few messages transferred” in the few minutes since you moved the device, please ensure you are transmitting to FUP - particularly with a confirmed uplink every 20.
Forum search is more TTN/TTI/TTS specific - Fair Use Policy - if you read the Learn section (linked at the top of the page) you’ll know many of the in’s & out’s to get over these getting started humps.
Most pressingly for Zephyr (and many other offerings), the sample sets the uplink rate to 10 seconds which at SF12 is not just a breach of the FUP but is actually illegal in most jurisdictions?
As Zephyr provides a wrapper to LoRaMAC-node, most of the options needed are exposed - do you know Zephyr to dig in to it?
Fair Use Policy is hardly a LoRaWAN only thing. It applies to numerous technologies and services.
It might well be. I think you need to grab an uplink data packet at gateway level (TTN console provides it in the json you get when you click on an uplink) and using the keys found in the device information decode it using LoRaWAN 1.0.x packet decoder
Then get yourself a copy of the lorawan specification for the Lora alliance website and check the bits that have been set in the header. Given the behavior it seems likely ADR is disabled on the node.
Or have you disabled ADR at TTN device level?? (Device-General Settings-Network layer-Advanced MAC settings.)
I am aware of the Fair Use Policy, just couldn’t parse the abbreviation as such. I’m also aware of the regulatory requirements here (EU) and that’s part of the reason I want this fixed! Also went through the “Learn” section and have a fair idea of how the PHY and MAC stack up as well as the overall architecture of LoraWAN and TTN.
I don’t know Zephyr that well, but compared to loramac-node it’s a no-brainer.
I don’t have time to go through the whole formal spec but I will consult it when tracing packets. This is a hobby project for me after all.
An unfortunate incident broke off the wire antenna soldered to my module, so I went ahead and soldered an SMA connector, followed by a 30 dB attenuator and a wire strip. Full disclosure, this is what I have now:
I’d say layering Zephyr on top of LMn is actually pressing two mammothly complicated systems together for no reasonable benefit unless you like the pain of writing device drivers for Zephyr - but I’ve run out of chickens & other VooDoo aids so I’m not bitter, just jaded.
There are API calls to turn ADR on & off as well as explicitly set the DR (as you noted, with ADR off).
Well, Zephyr is for grownups with long white beards. I don’t have one yet
That said, not a great fan of Arduino either. I like having a decent preemptive system with synchronization mechanisms, async tooling, proper power management support and other bells and whistles one may or may not need. Device drivers … someone else wrote most of them already, thankfully and they do mostly work if you can get the DTS right.
Maybe there is a way to stitch RadioLib with FreeRTOS or Zephyr…
Anyway, my problem is solved for now. Not sure if it was the attenuator or adjusting the ADR margin to a lower value. I will give it some rest now (FUP!) and will try a TTNMapper session or two during the weekend.
Cough splutter - I think not - and it’s not unusual for them to have missing functionality.
You assume Arduino? But most of those things are available in Arduino-ESP32 - like FreeRTOS base - and there is a deep sleep example for ESP32. But overall I only use ESP32 if I need BLE or WiFi with LoRa/LoRaWAN - otherwise there are much better alternatives.
Should be, there’s the settings for IDF and a freestanding mode but I doubt it would slip in to Zephyr’s way of working anytime soon.
