LTE to LMR

[snicholson72]

There seems to be conflicting information regarding the ability of a Harris Radio to switch back from LTE to LMR without any kind of user intervention. Can anyone explain, with detail, how a Harris Radio goes back to LMR once it has been on LTE? Does this require the user to push a setting, feature, anything? Or, is it truly automatic? For conventional and trunking options

 

[rjschilder]

You need r20 firmware. It will automatically switch to BeOn if the control channel is below a certain threshold. It also checks in the background while on BeOn to see if the CC is above a certain threshold to switch back. I’ve only tried on trunking, not sure how that could work automatically for conventional since there is nothing to monitor for Rssi

 

[wsp44]

You need r20 firmware. It will automatically switch to BeOn if the control channel is below a certain threshold. It also checks in the background while on BeOn to see if the CC is above a certain threshold to switch back. I’ve only tried on trunking, not sure how that could work automatically for conventional since there is nothing to monitor for Rssi

rsjchilder is spot on, L3H said they are continuing to try and improve the transition from LMR to BeOn and BeOn back to LMR, They want it to be seamless where the end user wouldn't notice and I think they will continue to develop this with new FW, and I second the conventional statement, I believe you would have to program a button/switch or zone to swap between a conventional LMR system to BeOn/MCPTT.

 

[nikronzo]

as XL firmware continues to develop so will hopefully the beon/xlconnect radio functionality. As it stood on previous iterations, it was something like -117 or worse for 30 seconds minimum before the XL would roam to a beon system and then it had to turn in wifi/lte and then connect to vida and download the profile which was another 15-20 seconds. You can now leave LTE and Wifi turned on at power up but the count down timer is still there and its still slow as balls to connect to the server most of the time.

There is no conv beon roaming support right now, so you'd have to manually toggle the beon system from a zone/system menu or a present function button that has been programmed. It would also require the core to support trunking and have a full VIDA stood up.

 

[xntexan]

I'll echo the previous 2 comments about constantly evolving FW. I've got RPM2/XLP R22A with CCM R7A and there is a user defined RSSI roaming threshold in the Smart Roaming section. Someone I know is getting RPM2/XLP R23 with CCM R8 today for testing and this whole revision change is focused on P25T to LTE and back roaming.

BTW, R22 has P25T two tone paging and ability to disable emergency on a per system level.

 

[rjschilder]

is there a way to automatically failover to a p25 conventional or analog conventional channel if the control channel Rssi is below a threshold? I’ve never actually looked, just curious if anyone knows. I know there would be no automatic way to go back to trunking if this is possible.

 

[gatekeep]

I'll echo the previous 2 comments about constantly evolving FW. I've got RPM2/XLP R22A with CCM R7A and there is a user defined RSSI roaming threshold in the Smart Roaming section. Someone I know is getting RPM2/XLP R23 with CCM R8 today for testing and this whole revision change is focused on P25T to LTE and back roaming.

BTW, R22 has P25T two tone paging and ability to disable emergency on a per system level.

I don't mean to be argumentative...but I find these version numbers suspect as hell. That would mean in the ~5 to 6 months since L3Harris officially released XLP R20A and CCM R5A (which was in April of 2025), they created essentially 2 to 3 *entire major* revisions of each firmware.

 

[NavyBOFH]

I don't mean to be argumentative...but I find these version numbers suspect as hell. That would mean in the ~5 to 6 months since L3Harris officially released XLP R20A and CCM R5A (which was in April of 2025), they created essentially 2 to 3 *entire major* revisions of each firmware.

Not to mention If public availability is R20 and R05 CCM and this claim is true - it’s showing L3Harris has no strategy for firmware releases and break/fix except “throw everything at the wall and whichever sticks becomes general release” because it proves R20 is “old” but also “new”. That means they’ve essentially chained their development team to a table and said “don’t move till this is fixed” which is… a choice.

 

[xntexan]

 

[xntexan]

I don't mean to be argumentative...but I find these version numbers suspect as hell. That would mean in the ~5 to 6 months since L3Harris officially released XLP R20A and CCM R5A (which was in April of 2025), they created essentially 2 to 3 *entire major* revisions of each firmware.

There are plenty of things I use that I doubt you've seen. RPM R15A03 ? Special release SW for converting M/P5300 900MHz OS to 900MHz P25.

 

[gatekeep]

View attachment 190849View attachment 190850

Impressive. Harris *actually* buckling down and committing to fixing something. They really did ball and chain the developers to their desks to fix ****.

 

[gatekeep]

Not to mention If public availability is R20 and R05 CCM and this claim is true - it’s showing L3Harris has no strategy for firmware releases and break/fix except “throw everything at the wall and whichever sticks becomes general release” because it proves R20 is “old” but also “new”. That means they’ve essentially chained their development team to a table and said “don’t move till this is fixed” which is… a choice.

To your point now though, given this chain of events, it would indicate that L3Harris really does have no strategy for firmware release timetables.

 

[nikronzo]

View attachment 190849View attachment 190850

R20 is still the latest PUBLIC available XLP and RPM2 along with R05CCM, so while your "versions" are all well and great, they are not what L3 is recommending for general code on subscribers.
Even when we get a special code release for bugs or features requested in beta and not field consumption its never been 3+ versions ahead of release.

 

[Echo4Thirty]

R20 is still the latest PUBLIC available XLP and RPM2 along with R05CCM, so while your "versions" are all well and great, they are not what L3 is recommending for general code on subscribers.
Even when we get a special code release for bugs or features requested in beta and not field consumption its never been 3+ versions ahead of release.

Correct. 21 and 22 is an internal release for BeOn customers and is not supposed to be in the wild. 22 *MIGHT* be released to the public, but based on what I am seeing with it, i wouldnt put money on it.

 

[commtech124]

Now if Harris can fix the XL-Bridge feature on the radios....they do not have any useful features they promised would be released with it. The only useful thing that it brings at the moment is the ability to not have to use Pathway+ with the XL radios. The DFSI connection will not pass emergencies or UID from a radio on another system.