LoRa Trackers don't accept a CR value of 4:8?

[arizonajon1]

Hi Ricardo -

I've been running into this a lot recently in attempting to dial in low rates to match the digi/igate.
While I can set the digi/igate to accept CR4:8, it appears that tracker firmware doesn't allow that.

What am I doing wrong?

Cheers and 73 - Jon N7UV

[richonguzman]

this sure had been limited on the webUI rules , it sure can be modded to accept those values.

with vscode you can mod it fast

[arizonajon1]

I've been looking through the VScode, I find in the LoRa_APRS_Tracker "lora_utils.cpp" references to setting SF, CR, BW. When I mouse over them it suggests that


that it should take the full range of values, but as before I can't find the bit of code that is rejecting allowed values of SF and CR. I checked "configuration.cpp" but didn't find anything there that appears to limit, that looks like it's just setting up the form and fill-in boxes for configuration.
Can you point me to the place I need to look to open up the SF and CR ranges in the tracker?

[richonguzman]

this is configured on the WebUI-Configuration Page

what values are you trying to use?

[arizonajon1]

Since I've proven to myself that range and mobile performance is excellent, it's time to move to higher data rates.
SF of 7 and 8, CR of 4:5 and 4:6 are good places to start. I still want to drop the bandwidth to allow the signal to fit in a typical cavity filter, but changes in SF and CR right now are the most interesting.
I tried looking through the tracker code to see where the values entered for SF and CR were checked and rejected, but I haven't found that.
Ideally, the allowed values for the digi/igate and the tracker would be symmetric.

[richonguzman]

now I see... some values are limited on the index.html file of the repository

[arizonajon1]

Also, I have a persistent error

Invalid 'c:\Users\jta\Downloads\LoRa_APRS_Tracker-main\LoRa_APRS_Tracker-main\variants\ttgo-t-beam-v1_2\platformio.ini' (project configuration file): 'No section: 'common''

[richonguzman]

watch out what you deleted!

to enter WIFIAP again (info which is on the wiki, press 3 times the user/middle button)

[arizonajon1]

Thanks for the pointers! The on-device menu is a great addition. Took a little navigating and learning what a short press really was, but I figured it out %^)

I got rid of the old fork, downloaded a new one since I didn't know where I'd accidentally deleted something.

Modified the script.js to allow all legal values of SF and CR. Modified smartbeacon_utils.cpp to increase the beacon frequency (remember, I'm the only person on the channel).

Running now at SF8 CR4:6, 2.60 kbps, my channel occupancy time has dropped to less than half, a quick trip showed that the -2.5 dB hit on link budget didn't impact local range. As I only have ready access to the digi/igate at the house and the tracker in the truck, I didn't modify my 3 other fill-in digis on the frequency so their coverage assistance isn't available at this time.

Why reduce channel occupancy in trade for range? We all know that on an aloha channel we can only get about 18% occupancy before things start to degrade. With regular igates and the outstanding link margin for a LoRa system, but with the realities of having to use digipeaters that have no other connectivity (at least out here in the southwest), decreasing channel usage is in my opinion better than going for the extra range. And the hit on power consumption is minimized due to the reduced transmit on time. Another factor that is harder to estimate is the effect on mobile fade on the link. A significant mobile fade can be well in excess of 20 dB, and a shorter transmit time helps to reduce the number of fade cycles that might occur during any one transmission. (Of course, compression helps too, thanks for implementing that!)

As well, I now have some bi-directional 433 amplifiers that promise 11 dB transmit gain. I've tested one on the bench, since the LilyGO only puts out +17 dBm, the bidirectional amp puts out +28 dBm, which will more than make up for the range reduction due to the improvement in reduced channel capacity. Also, with more +30 dBm LoRa radios becoming available, there's really no reason to run at lower baud rates than are necessary for a minimum system. I already have two of the qrp-labs solar units, and am eagerly awaiting %^) the port of your firmware to that device!

I'm going to experiment further with LoRa parameters to see where the tradeoff really is.

Last question: In script.js I did not see a LoRa BW setting (signalBandwidth). In order to move down to 62.5 kHz, I will need to modify both the tracker and the digi/igate firmware.

[arizonajon1]

on the script.js line 185 and down are some rules avoid some errors... test it

Hey Ricardo - happy winter!

I finally got back to your comment about the restriction on available LoRa SF and CR modes. When I Iook at script.js in the vicinity of line 185 I see the following
<div class="form-floating col-6 col-md-3 px-1 mb-2"> <input type="number" class="form-control form-control-sm" name="lora.${index}.spreadingFactor" id="lora.${index}.spreadingFactor" value="${lora.spreadingFactor}" min="6" max="12"> <label for="lora.${index}.spreadingFactor">Spreading Factor</label> </div>
which suggests to me that all LoRa spreading factors (except 5) are supported. But, as I've said before, I run SF7 here on my network and the setup screen rejects that as an invalid value, only allowing an SF 8 or greater.

Also, the same is true for CR, the chip allows values of 4:5 to 4:8, and script.js lines 192 through 202 suggest those are all allowed, but I cannot set a CR of 4:5, the html setup page rejects it.
<div class="form-floating col-6 col-md-3 px-1 mb-2"> <input type="number" class="form-control form-control-sm" name="lora.${index}.codingRate4" id="lora.${index}.codingRate4" value="${lora.codingRate4}" min="5" max="8"> <label for="lora.${index}.codingRate4">Coding Rate</label> </div>
The way I've dealt with this so far is to just hack the code to get my 4560 bps SF7 CR4:6 at BW125 to work. But now as more people are considering joining my network here in Phoenix, they can't just set the right values, they need to learn VSC and make sure not to break things.

Can you revisit the index.html and script.js to allow the user to easily set up whatever SF/CR the chip set can support?

Salud - Jon N7UV

[arizonajon1]

Ahh, it appears that the digi/igate firmware is updated! I was looking at my version dated 20MAR25. The newest version released on 20JUN25 has no more restrictions on SF and CR. Can you do the same for the tracker side?
Thanks so much Ricardo!