Hello, I apologize if I’m not following guidelines for posts. If there’s a format then please let me know.
PROBLEM:
I’ve been spinning my wheels on an issue I’m seeing when using LoRaMAC node stack v4.4.7. I have custom HW w/ sx1262 radio included. I have a multi tech gateway that is configured as packet forwarder. I’m monitoring the traffic on the gateway. I’m seeing that if I transmit at a fixed interval that pkts aren’t received at expected rate and it’s inconsistent. For example say I transmit 10 pkts over a period of time. In one set of tests I may see only 2 pkts and in another test I may see 4 (just an example). The remaining pkts aren’t received by gateway. I have not been able to get much information from log files to try and pinpoint issue is it CRC, MIC,???
I have been using this same custom HW for > 3 years now. I originally was using basicmac version of LMiC stack. This worked well but I recently moved to LoRaMAC node since basicmac was not recommended for new designs anymore. When I flash the basicmac stack code to this same HW the pkts are received by gateway at expected rate. She cause of this I’m confident there is not a HW issue. Again I’ve used this HW for years now. The part that’s frustrating in new stack (LoRaMAC node is that I’m getting “TXDONE” interrupt at expected rate. I can also see on spectrum analyzer that transmissions are occurring. I also have a portable SX1262 evaluation board that increments at expected rate when pkts are transmitting.
The issue is not due to transmitting on channels outside gateway receive antenna configuration. For test I’m transmitting on FSB1 channels [0,7] enabled. The gateway is configured for this band also.
One more note… I have a network separate from TTN that I use. I’ve always joined using ABP approach. This has not been an issue in the past. The LoRaWAN spec used is 1.0.3.
Also, regarding proximity to gateway I’m approximately 3 m from it at all times. I’ve actually taken off the receive antenna from gateway and can still see pkts received. My devices are transmitting at +18 dBm.
Any help or suggestions are greatly appreciated. I have a headache from trying to figure this one out for the past week.
Are you using the TTS stack for this private network? Because if you’re using neither public TTN nor a private TTS instance, it’s not really an on-topic question for this forum.
Given you’re playing with private networks, it’s possible you have a mismatch in pre-amble settings. In some sources, the preamble should be different between public and private LoRaWAN networks, others give that difference as between LoRaWAN and other schemes. A mismatch will result in only a minority of packets getting through.
You don’t want to remove the gateway’s antenna, because if things did work, then the gateway would be likely to transmit, without a suitable load for its power amplifier to work into. Transmitters really don’t “like” that. Moving the gateway or node some distance apart would be good, you can also use a 50 ohm resistor on the node in place of an antenna (or buy a connectorized one to use on the gateway - even a high value attenuator makes a tolerable dummy load for something like this.
Thanks for the reply. Typically -80 dBm RSSI. I don’t know on SNR. I’ve typically seen > 0. I’m using a chip antenna on transmitter.
I ended up testing on another gateway and the same behavior was observed… Its’ quite odd. I unfortunately do not have tools at the moment that I can use to pinpoint the issue. Is there an issue w/ keys, sync word, preamble, MIC. I have been checking all of these but have not found the smoking gun yet.
Are you using the TTS stack for this private network? Because if you’re using neither public TTN nor a private TTS instance, it’s not really an on-topic question for this forum.
No it is not. Typically when I’ve had difficulty I’ve used this forum to find answers. Is there another forum that is more appropriate? I view this issue as network independent.
A mismatch will result in only a minority of packets getting through.
I’m not sure I follow. For this particular case you’d expect some pkts to be dropped? I’ve not heard of this. Do you mean if gateway is setup for 12 symbols and transmitter is sending 8? Or no?
An RSSI of -80 dBm should be OK, a bit on the low side for a node close to a gateway.
If my position tracker transmits at about 5m from my TTIG I get around -40 dBm RSSI (and +10 dB SNR).
Does your hardware have an antenna Tx/Rx switch? Perhaps this switch is not actuated by the software stack. This could be a missing or incorrect configuration in software and would explain why it works with one stack and not with the other.
Preamble sync word should probably stay at 8, but there are different sync words for different types of networks, and those need to match or the traffic won’t get through, except for the occasional packet that leaks through despite the mismatch.
The format of sync words for the SX1262 is a bit different than for the SX1276 and gateway chips, but it’s well documented which in one context goes with which in the other.
Thx for response. The TX/RX is handled automatically by SX1262 DIO pin. The spectrum analyzer measurements show that the correct path is selected (I see the RF energy at the expected rate).
If you aren’t using any of the TTI/TTN serves, this would normally make it off topic for a TTI funded forum that is specifically for TTN / TTI users. However I’ve been persuaded that you may have a generic issue that could benefit everyone.
It is, however, still not clear what network & application server you are using. So, like the many many other debugging threads on here, can you tell us exactly:
Gateway model number and is this running a LoRaWAN stack for you?
Device MCU & what format / vendor / model the SX1262 is.
As I think about this more -80 for RSSI is just not right for a node 3m from a gateway.
Something’s wrong there, quite probably with the antenna path or chip setup, really suggesting that either there’s a TX/RX switch not correctly being driven, or the antenna simply isn’t connected to the chip, or possibly that you’re trying to use a 470 MHz RF circuit on 868 or 915 (eg, it’s about what I ran into when I accidentally bought the wrong STM32WL55 Nucleo) What’s the actual form of the SX126x? Surely it’s not a custom chip on your own board, so what exactly is it? And where can we see the documentation for this module?
It’s also very unclear how you can be switching between LMiC and LoRaMAC-node on the same hardware, because LMiC doesn’t really support the sx1262 - unless you’re using some obscure branch which does, in which case you should explicitly identify and link that.
If you did have a software stack that worked well, and one that didn’t on the same hardware the thing to do might be to modify each to dump the contents of all SPI interactions with the radio, and then take the dumps into a text editor and painstakingly go through them vs. the data sheet and see what’s being done differently. There’s also an app note from semtech that’s a crib sheet of recommended settings with the actual register values - though oddly while that’s useful for the obscure optimization settings, some of the basic ones may not be right for LoRaWAN, eg, wrong downlink bandwith setting for some regions.
Thanks. I was able to dump all SPI transactions in the stack that was working and compared to the latest LoRaMAC node code. I found that the register address used for setting things like Sync Word in radio was being forced to 0 in code. A mask then cast then right shift was applied to parameter instead of mask then shift then cast. The upper byte of all the register addresses was forced to zero because of this. Changing this fixed my issue. I’m not longer seeing pkts inconsistently. I believe the root issue was due to sync word not getting setup properly. The default sync word according to SX1262 datasheet is 0x1424 (private). My network is setup to use public. I don’t fully understand why there were times when pkts were received ok on gateway. The error I mentioned would have prevented every register write being written to the expected address.
In which codebase did you find this error? Did it occur on the intended platform, or on porting it to something else, eg, code meant for ARM being run on something with a 16-bit int?
As explained earlier, the occasional packet will trigger the preamble detector despite mismatching sync words. It’s just a crude filter to damp down the volume of extraneous stuff, both keeping it off the backhaul and keeping the pool of demodulator engines in the chip available for signals more likely to be relevant.
Overall you’re leaving more unsaid about what you’re trying to do than you’re saying. Presumably that is intentional, but it makes for an odd read.
The error is not in the LoRaMAC Node provided code. It was added when adding the equivalent SPI function calls for my microcontroller. The microcontroller I’m using is not included in LoRaMAC node provided code. I added support for it for my use. The cast was added to remove a compiler warning. This unfortunately completely obliterated the upper byte of the register address.