Feature request: behaviour similar to old StationMode=5, but triggered by APRS-IS connect

[S57PNX]

Hello,

I have been using the old StationMode=5 to switch beween being an igate and a digi, depending on whether my site had WIFI or not.

I am uncertain of the "new" behaviour since StationMode is deprecated. Does the new code still contain a similar logic to switch between igate and digi roles, depending on wifi connectivity? I have APRS_IS active and DigiMode=2.

Secondly, the old logic triggered on wifi connect. However, one of my mountain sites has a very stable local wifi AP, but the uplink from the valley is unreliable. Even with StationMode=5, the gate never lost wifi connect and never switched to digi mode, even when the uplink was down and aprs.net unreachable. The gate thus just dissapeared since the traffic was blackholed. Can the new logic trigger on having a connection to APRS-IS, rather than just having a wifi connect? This will ensure the gate never becomes a blackhole and if the packet can't reach APRS-IS for any reason (mostly internet failure, but it could even be a misconfig), it will be at least digipeated to the other gates in the region.

[richonguzman]

good point mentioned here...

so, stationMode does not go anymore, the process now is to control independently the APRS-IS connection and the digimode use.

The old "stationMode:5" process will return eventually for this special cases when you need to change from one to the other.

And the validation of APRS-IS is also right, this before even Wifi-validation

[S57PNX]

Thanks Ricardo. So what is the new logic when both APRS-IS and digi are enabled? The received package is both relayed to APRS-IS and rebroadcasted over RF?

I will stay this site on the old version to keep StationMode=5 for this special case for now, looking forward to return of 5 in the future.

[SQ2CPA]

Hello. Please confirm: in simpler words: you want to enable Digi mode when APRSIS connection (IGate) is enabled but there is no internet connection?

[sp2atj]

But gentelmens it makes no sense to stick to Internet connection and repporting it only to APRSIS while we are able to work completely us RF network indepenently. We are Hams lets build RF based APRS nettwork not only throw frames to internet only. Relaying on wifi connection to chose state is also mistake because you dont know if frame was send to APRSIS of not there is no confirmation form servers if frame was ack. So building it only based on IGates limits functionality of that cheap technology. Make step forward start building RF nettwork.

[S57PNX]

Correct. If APRS-IS is enabled, but unable to connect to APRS-IS server, then switch to Digi mode. Run this check every 5 minutes to detect if internet goes away or if it comes back.

You can put this behaviour in the Digi menu as (Digi if no APRS-IS connection).

[sp2atj]

APRSIS connection should be addition to RF nettwork not clue of working APRS!

[S57PNX]

SP2ATJ, we are not taking away any functionality. You are still able to disable APRS-IS and use the gate as pure RF digi, or as APRS-IS only without any digipeating, or a APRS-IS with digipeating.

This feature request gives you more freedom and more possiblity to design the system. I have some gates on high mountains and I don't want to pollute RF by always digipeating everything in the radius of 300km, but I want these gates to forward to APRS-IS. Digi on these sites is only a temporary/emergency function if APRS-IS is not reachable, but shouldn't be running all time.

I agree that relaying on WIFI connection status is wrong. The mode change should rely on whether a TCP/IP connection to the aprs-is server was established or not.

[SQ2CPA]

Ok, so I understood correctly. This will be added in next updates so you will be able to migrate to the newest version.

Btw, as SP2ATJ said - why you guys don't want to use LoRa APRS like classic APRS on 2m? I mean good speed like 1200 bps, focusing on RF, not internet because for now to be true you are playing with APRSIS and we are playing with APRS. Using only IGates and trackers is weird, you can use aprsdroid without any that stuff and this will also work and it's as simple as possible without any devices, costless

[S57PNX]

We are using a mix of igates and digipeaters in my region. The gates are mostly on sites with DMR repeaters which have existing internet connectivity (either local or via wifi links) to function in the Brandmeister network. So having both communication paths (RF and APRS-IS) is better than having just one.

I disagree that only gates and trackers is not better than aprsdroid - at least there is some RF involved in the communication between trackers and gates, and things like terrain coverage and placement of gates/digis, S5 is a mountainous terrain with plenty of shaded spots. aprsdroid on the other hand only serves to test the mobile network infrastructure and should not be used with APRS-IS at all in my option.

[sp2atj]

In my opinion would be better to work more with DIGIS and just few Igates in walleys where its easier to get internet connection. Working on RF makes you posibility that you are able to make contact on radio with mobile station not only report its possition to internet. For that just use APRSDroid. Maby better would be to focus on digireapeating options like viscous delay and not repeat frames allready heard from network instead making focus on IGate functionality. In this way you are inverting idea of APRS from its original design and purpose.

[S57PNX]

APRS-IS works in both directions, so it is not just reporting position to the internet. Bi-directional gate gives you two-way communication, so I see a good network as a mix of gates and digis, and I run a few digi-only sites too. Also, even in a pure tracker-gate setup that you disagree with, does that not include a RF path between tracker and gate? It is not fair to compare it as not better than aprsdroid, which is an internet-only thing. I think we all agree that aprsdroid should not be polluting the APRS infrastructure.

I do see a RF channel overload in the future, as more users join and since there is no good CSMA/CD solution for LoRa, the throughput of the RF channel might drop significantly at some point due to congestion. But this is a discussion for different place.

Anyway, we are straying away from the purpose of this ticket, which is to bring back the hybrid mode functionality that was available before. I am thankful for SQ2CPA agreeing to bring it back.

[sp2atj]

More users reqires using faster standard. 300bps is good for idea with Igates but it is really bad idea in case RF network. Us i understand with LORA

coverage you are trying to repleace no GSM areas. APSR-IS is not working completely both ways it has some big disadvantages in transmiting packets from IS to RF.

[Mane76]

More users reqires using faster standard. 300bps is good for idea with Igates but it is really bad idea in case RF network. Us i understand with LORA

coverage you are trying to repleace no GSM areas. APSR-IS is not working completely both ways it has some big disadvantages in transmiting packets from IS to RF.

I would disagree with both statements, but fully support to bring back the "old mode 5" as Ricardo and I developed. LoRa IS completely different to AFSK used on 2m APRS. And we should use this unique possibilities rather than copy 2m APRS.

For those who are interested a bit in the background: https://github.com/richonguzman/LoRa_APRS_iGate/issues/48#issuecomment-1998223748

[sp2atj]

Mane76 you are making your statement based on 300bps speed we are using completely different aproach. Usign 1200bps with gives us frame arround 600ms with full posiblility of the using band. With is faster than 2m APRS frame Then we are more indepened from APRSIS and have more capacity in LORA nettwork. Main advantage of lora is resistance for noice and price for modules. Screenshot i pasted in previous message was view of pure RF network with me made here in SP. APRSIS is addition not clue of APRS. What you propose its just puting frames with positions on map. We are proposing completely RF APRS including messaging and all possibilities of the APRS on VHF.

[Mane76]

What you propose its just puting frames with positions on map. We are proposing completely RF APRS including messaging and all possibilities of the APRS on VHF.

This is not correct, just take a look on the features in iGate and Tracker FW

Usign 1200bps with gives us frame arround 600ms with full posiblility of the using band. With is faster than 2m APRS frame Then we are more indepened from APRSIS and have more capacity in LORA nettwork.

Thanks for sharing and feel free to do - I just try to close the loop for the audience to have the possibility to see your statements in context of your changed set of parameters.

[sp2atj]

Yes we are not denying that we changed parameters thats clue of it. I understand that you are trying to use messaging but frame AIR time is limiting you and then you need to do things with we are not even thinking off like limiting comments to every 10th etc. Just difrent parameters gave us more flexibility. There are still some limitations like not really good digirepeating decision making for now both sofwares Ricardo and DL9SAU are having just simple digirepeating logic and in case extended network like ours we have lot of repeated frames but still even with this dissadvatage its not blocking our nettwork to be able to hear weak 10mW mobile stations. Thats incredible how that small power can make 30-40km range. Please take look on that what we did not telling that we are 100% right but with limitations of 300bps there is not much to gain and then understand why you are limiting digirepeating. Just trying to show maby diffrent way and go further not stop development and possbilty because decision done on begining is limiting us.

[S57PNX]

Beside all the benefits of 1200 bps, you forgot to mention one minus - by increasing the speed from 300 bps to 1200 bps you lost approx. 10dB of Lora sensitivity. This is a design tradeoff, but to many of us the attractivity of LoRA is much higer SNR limit comparing to traditional modulations. But why stop at 1200 bps? By switching to SF7, the time on air of a frame will drop to 60ms and your bitrate will increase to 5k bps, and it is only going to cost you another 8dB in SNR. Now 5k bps is much better throughput than 1200 bps. You can take it even to 230 kbps, that's very fast. But speed comes at a price.

I don't want to start a design discussion, the above was just to point that there is no free lunch and selecting modulation parameters is always a tradeoff of what you gain and what you lose. You have chosen different parameters and you have your own reasons why you chose that. But for the benefit of the audience, there is no right choice, just different tradeoffs.

This is clearly outside of the scope of this ticket and the discussion should continue elsewhere. Ricardo and the team are providing us the tools and we are grateful we can use them in the different ways.

[sp2atj]

Accualy we are using SF 9 and yes this is disadvantage also thats why we changed qrg to 434.855 to avoid ISM band noice and yes its another problem its hard to find global qrg for all countries within 70cm band. You are right this is allways tradeoff but in this case i think is worth of it because on the end we are not having noticable range limitation compare to 300bps and also 1.2k is beter for mobiles us frame sending is shorter so then distortions coused by moving is much less. And you are right its not really place for this discussion but its good to take it.

[SQ2CPA]

Unfortunely I found another problem with 300bps - it could costs me about 5 times more energy because TX is longer compared to 1200bps. If I'm using very low power device (that could stay on 3200mAh battery for 10 days with RX and TX) it makes very big difference when transmitting many frames if the TX takes 5x more time. The same problem goes for the tracker - it seems like nothing, but if you really try to save energy at every possible moment, it matters. For example I have Digipeater that consumes about 12mAh (at 3.3V) per hour (RX always and TX 30 times for calculations).

and to finish what SP2ATJ wrote - we use our local network to show how it works, you can see it and analyze it without any problems.

and to answer your question that I missed "So what is the new logic when both APRS-IS and digi are enabled? The received package is both relayed to APRS-IS and rebroadcasted over RF?" - Yes, that's exactly how it works.

[S57PNX]

I am still hoping for you or SP2ATJ to explain what made you chose 1200bps. Why not switch to 5k bps? The frame will be only 61ms instead of 600ms, and you will spend at least 5 times less energy than 1200bps (and 25 times less than 300 bps). RF sensitivity with 5k bps will be still better than analog APRS and the speed will be drastically higher than 1200 bps.

Thanks for answering my new logic question!

[sp2atj]

So I had to dig in some groups and chats because I was not part of team with started building lora network here in SP. There was more people involved in this with was developing software on the lead of Ryszard SQ9MDD. They started developing software for TTGO and their goal was to make not only one way comuincation (Igate) but both ways exacly like its on 2m with all its advantages. They did some tests and 1200bps was balance beetwen nettwork capacity and range of comunication. This also come with chaning QRG to 434.855 with is not so noisy like used 433.775 with is localizated in ISM part of band so many devices like smart meters etc are working on this band. So taking this two decisions they found good working balance us they gained network capacity on changing speed from 300bps to 1200bps and also lost in sensitivity was partialy compensated by less QRM on new frequency.

For now there is one important thing to make in the software its viscus delay and buffer preventing that multiple digis are repeating the same frame many times but this is on close plans of Damian SQ2CPA. So hope that problem will be solved soon. Hope that explanation is clear. If not feel free to ask i will try to find out answer.

[1tilen]

Hey guys, I was just thinking of a situation similar to the one discussed in this “issue”.

Has there been any development to this? I also think that possibility to have an Igate which switches to the digipeating mode would be great addition to the software. We wouldn’t like to have digipeating on all the time as many of our GW locations can bear eachother, quite a lot of unneeded traffic would occupy the frequency if everything was digipeated. Still we would love to have digipeating option available in case any of the sites loses internet connection.

I have another feature request which is connected to the discussion but I can open a separate topic if needed. would there maybe be a possibility to have connection also to private APRS IS server next to the public one? We are thinking of deploying a server inside our internal HAMnet. In this case we are not directly relying to the internet but rather to the hamnet which is as our igates controlled by us. We wouldnlike to learn/experiment about/with multiple projects together.

Thank you for all of the devolpment on this software, LoRa APRS project wouldn’t be on such a high level if it weren’t for you guys.

73 de S54B

[iw2ejh]

I have another feature request which is connected to the discussion but I can open a separate topic if needed. would there maybe be a possibility to have connection also to private APRS IS server next to the public one? We are thinking of deploying a server inside our internal HAMnet. In this case we are not directly relying to the internet but rather to the hamnet which is as our igates controlled by us. We wouldnlike to learn/experiment about/with multiple projects together.

You can set any ip address in the config.son you can then install your own instance of APRS-IS server and connect your clients to that private server.

[S57PNX]

He is asking to send data to two APRS-IS servers at the same time. One public aprs2.net and one private.

[iw2ejh]

He is asking to send data to two APRS-IS servers at the same time. One public aprs2.net and one private.

the private server installation will then relay the info to the public server, like it happens with tier2 servers to main server.

[S57PNX]

This is doable, but then the private server is the single point of failure - it if fails, the traffic will not reach the public servers and all the sites will drop off the map. To counter that, the private server would need to have a redundant infrastructure etc., making it more complicated than a simple test and analysis server.

In comparison, if the gateway itself sends the udp packet to two destinations, the private server can be small and unreliable while the public servers are already massively redundant and reliable.

[S57PNX]

Thank you for adding Mode=5 equivalent to the latest code. Quick test shows that it works as expected in my use case, and it detects both loss of wifi and return of wifi within seconds, not in 15 minutes as I was expecting.

One problem though: I started with firmware and config from 1.0.2 (April 16th), built the latest code and uploaded the resulting firmware.bin via OTA. After this, I am running build date 23.5.2025 but the webgui shows the message: "Failed to load configuration" and all the fields are blank.

However, the gate seems to have read the config correctly and is working correclty. I am attaching the backup json from April 16th that new webgui doesn't like.

iGateConfigurationBackup (2).json

[richonguzman]

build

this is because from 2024-04-13 (web installer version) to the github latest version (2024-05-23) the filesystem and firmware changed

[S57PNX]

So there is no direct upgrade path? We need to upload a new filesystem and reenter the config by hand?

[richonguzman]

So there is no direct upgrade path? We need to upload a new filesystem and reenter the config by hand?

sorry, but for this change it will be needed as with the old partitions size definition we were getting to 99.7% of usage of the internal memory and we needed the mod to continue adding more stuff

[S57PNX]

Understood, thank you. Maybe you want to put a little notice when you release the new release?

[richonguzman]

Understood, thank you. Maybe you want to put a little notice when you release the new release?

sure !