I have halowlink2 devices with directional antennas on two towers. With 4 watts erp i can get enough signal to exceed the 15.9 km timing limit..is there a way to extend the range in the config?
Improving your EIRP is usually the best way to improve range - obviously cautioning the legal limit for your jurisdiction.
Opting for a lower configured bandwidth will slightly improve your receiver sensitivity and give you a little bit more in your link budget.
If you are hitting timing limits it could be the ack_timeout_adjust biting. Looks like the default on the HaLowLink 2 is 60us. At ~20km you’d be looking at ~133us worth of air time (round trip of 40km) so may be worth nudging that value up and seeing if that fixes things for you.
morse_cli set ack_timeout_adjust 180
What is the maximum i can put in the config?
Will this work on the older chips too?
The morse_cli utility will accept UINT32_MAX into that value.
Im confused. What is UINT32_MAX ?
Sorry, UINT32_MAX is 4294967295
Ok in your opinion. Whats a realistic maximum value/distance i can get at 1 mhz wide 4 watts erp
as a sidenode. setting the ack timeout limit is pointless. it works on ap side. but the station does reset the ack timout value to 60 on each assoc. of course you can reset it after but i’m sure that the assoc will not succeed if its reset to default values all the time
“Realistic” maximum range is hard to answer - as it varies wildly for different environment. Even with a 4W ERP I wouldn’t expect every deployment to hit 15.9km.
However, the standard effectively defines the limit for 802.11ah as 15.9km through the 52us slot time. Adjusting the ack timeout for long range will be required, but if you’re dealing with multiple stations you will also need to consider a slot time adjustment. Point to point deployment will degrade efficiency to unslotted aloha.
The standard does describe a mechanism for adjusting the slot time via setting the coverage class field of the operating triplet, but to my knowledge we do not support this - I’ll check with the team.
EDIT:
(Clarified a badly worded note around the ack timeout).
The slot time can’t be adjusted for 802.11ah. It is fixed in the standard as 52us.
if you are talking about my note. this was more or less a hint about a bug in the chipset firmware. it does not keep the settings configured and resets all to default on channel change. this of course is a problem if you want to configure ack timing on station side. regarding slot time i can tell you that its not against any standard to change the slottime to a different value. this has a also a huge performance benefit. consider you have a 500 meter link but the maximum time is defined to 15km. so a packet loss will be detected way later than expected. so timing adjustments to more or less accurate values is a very common thing. i also can tell you that all major wifi drivers who do support ack timing adjustments will also adjust slot and cts timeout values according to the coverage class setting
Oh no, I had made a badly worded comment that read as if the ack_timeout is not a helpful thing to adjust at all. As part of the edit to my own post I corrected that.
Regarding slot time, Section 23.3.15 (S1G / Slot Time) of the 802.11 2024 standard states
Because of the above we have not implemented any feature to adjust slot time. This isn’t necessarily an issue in a point to point deployment though.
I do hear you regarding the bug in chipset firmware. And have raised a ticket internally 
shall be != must be. so its not a mandatory value. which means its allowed to adjust a value. by its nature it will also not violate any protocoll standard if you adjust it to a lower or higher value. i mean you will find the same slot time for 802.11a (9 us) and 802.11g (11 us) (dont judge me if one of these values was wrong). but with such values no long range link can be established of course. thats why the coverage class setting was introduced.
since such devices have definitly a application for longer p2p links its not a bad idea to think about introducing these properties and we all know that its a codechange which can be done in minutes on firmware side and for the morse driver its also very simple (coverage class * 3 = ack/slot timing) etc. but i could live with a morse_cli set/get variant which is persistent for these values.
I’m going to have to correct that interpretation of “shall” on your part.
As defined in the standard:
The 52us setting is specific to the S1G PHY specification. Other PHYs have the capability to adjust the slot time via the coverage class.
Otherwise, I acknowledge the request for the feature and will raise it with the team - though I suspect we would want to explore an amendment to the standard before implementing anything.
thank you for consideration. i hope the best