Feature Request: Support for APRS Item Mode to Handle Multiple Trackers

[awatchar]

Hello,

I've been exploring the LoRa APRS Tracker project and find it incredibly useful for ham radio activities. However, I noticed that it lacks support for APRS item mode. This feature would be highly beneficial for operators who manage multiple trackers, as it allows better organization and individual tracking of each device.

Implementing APRS item mode could enhance the utility of the tracker by enabling distinct identification and management of multiple trackers under a single operator's call sign.

This would greatly improve operational efficiency and monitoring capabilities in various scenarios, including disaster management and educational activities.Could this feature be considered for a future update? Thank you for considering this enhancement.

Best regards,

E25FGL

[richonguzman]

Hi,

If I remember correctly the only difference between objects and items is that the second type does not move.

so you want to create a possibility to have a "non" moving tracker? that it gets its gps positions and stay fixed there?

[S57PNX]

I don't see how APRS item mode would help in this case. The original poster is probably looking for SSID? SSID (the -1 to -16 at the end of the call sign) is allowing using multiple trackers under same operator callsigns. I can see that E25FGL is currently operating only one tracker (an Icom D-star handheld) and it is without the SSID. I advise E25FGL to study the concept of APRS SSID and apply it to all his trackers, including the Icom unit, since an SSID is mandatory in APRS.

On the note of APRS objects/items, https://github.com/LiamMehle is working to add support for APRS objects. The idea behind his implementation is to drop an expiring marker (object) on the current location when a GPI pin is shorted. This can be used in an EMCOM situation when trackers are used to track the movement of SAR units and markers indicate the location of found victims. A special button will be soldered to the tracker for this purpose.

[awatchar]

I don't see how APRS item mode would help in this case. The original poster is probably looking for SSID? SSID (the -1 to -16 at the end of the call sign) is allowing using multiple trackers under same operator callsigns. I can see that E25FGL is currently operating only one tracker (an Icom D-star handheld) and it is without the SSID. I advise E25FGL to study the concept of APRS SSID and apply it to all his trackers, including the Icom unit, since an SSID is mandatory in APRS.

On the note of APRS objects/items, https://github.com/LiamMehle is working to add support for APRS objects. The idea behind his implementation is to drop an expiring marker (object) on the current location when a GPI pin is shorted. This can be used in an EMCOM situation when trackers are used to track the movement of SAR units and markers indicate the location of found victims. A special button will be soldered to the tracker for this purpose.

Thank you for your quick response and for pointing out the use of SSIDs in APRS tracking.

I understand the typical application of SSIDs and their role in managing multiple trackers under a single call sign. However, I'd like to elaborate on why the APRS item mode would specifically benefit our situation in northern Thailand, particularly given our unique regulatory and environmental challenges.

In northern Thailand, we frequently face significant environmental crises, such as wildfires, which contribute to severe PM2.5 pollution. During these emergencies, our ham radio clubs play a crucial role in coordinating communication and incident management. Thai regulations uniquely allow non-licensed individuals to operate ham radio equipment under the supervision of licensed club stations. This flexibility is crucial during widespread emergencies where rapid deployment of communication tools like APRS trackers is necessary across a broad team of responders, many of whom may not be licensed ham operators.

One significant limitation with the SSID approach is that it supports only up to 16 devices per call sign. In large-scale emergency situations, such as the wildfires we face, this cap is quickly exceeded as we mobilize a substantial number of volunteers and equipment. The APRS item mode would greatly enhance our capability in such scenarios. It allows for more flexible, dynamic positioning and tracking of resources and personnel across different locations without needing to pre-configure SSIDs for each unit. This mode supports spontaneous on-field adjustments more seamlessly than the traditional SSID method, which requires predefined settings that might not be as adaptable in fast-evolving situations.

For instance, during a wildfire, quick and effective deployment of APRS trackers to various key points and units (both human and non-human resources) can provide real-time data crucial for managing not only the firefighting efforts but also for monitoring air quality and evacuating communities. Being able to assign and reassign trackers dynamically as "items" in the field without worrying about individual SSIDs can streamline operations and enhance response times.

Additionally, the ongoing development of APRS objects to mark significant locations dynamically, as you mentioned, aligns with our needs. This feature could be further expanded to support emergency situations where quick identification of critical spots (like safe zones or heavily affected areas) is necessary. A system that allows us to drop location markers in real-time can significantly aid in coordinating a large-scale emergency response.

Given these points, I believe that integrating APRS item mode would not only benefit our specific operational context but could also enhance the APRS tracker's versatility and utility in various other emergency management scenarios globally.

Thank you for considering this enhancement. It could truly make a significant difference in how effectively we manage environmental and emergency situations here.

Best regards,

E25FGL

[S57PNX]

APRS Items are non-moving permanent points of interest (like repeater sites, hospitals etc.), while objects are moving points of interest similar to position beacons. If anything, you want to be looking at objects, not items. However, I don't think that objects are the correct solution for your problem (I am just an user nad not affiliated with this project). Objects are not replacement for correct calls with ssid if you operate on ham radio infrstructure using licensed frequencies, depending on the law in your country.

In your case, I would apply for additional callsigns from your licensing authority, and use each of them with 16 SSID. This will give you n*16 trackers. The trackers can be preconfigured with calls and stored for emergency situations.

Using objects just to avoid the callsign rules is... not a good choice. If you want to insert an item on the map, you can inject it from a laptop via APRS-IS or via a KISS-connected lora radio (even a tracker in kiss mode).

I do agree that objects are the correct tool to mark positions (e.g. a collapsed house) while the tracker should remain a beacon and will follow the movement of the SAR team. Special care must be applied not to overload the APRS-IS infrastructure and filling the map up with 1000s of such objects.

In S5, we have organized state and regional volonteer HAM EMCOM team, each team has a special callsign that identifies the region it is covering. In the near future, we plan to build a suitcase with 16 trackers, preconfigured for such events, with a laptop and a KISS-connected digipeater so that it can operate without internet connection, ready to deploy at a moment's notice.

[richonguzman]

Hi,

both cases are awesome to be part of!

so first with E25FGL: fires could be created as objects that are alive as they are being updated , maybe the way to create them is over a Central station with an app to keep them alive as Xastir or others

@S57PNX this case with lots of trackers/handys is ment to be lora trackers or AFSK also?

[S57PNX]

E25FGL perhaps you should consider the software that you use in the control center. https://www.pinpointaprs.com allows you to work offline (with preloaded maps) or online and assign Nicknames to each APRS object. Then it doesn't matter what is the callsign of the tracker - your command center can assign nicknames for easier control and monitoring. There are other software packages used for SAR situations that can handle this situation maybe even better, but I never used them.

@richonguzman lora only, probably the IPEX t-beams with SX1268, and a few digis, one for the base and one with a battery/solar combo as fill-in if we need to install it somewhere to extend coverage. BTW In my experience AFSK doesn't work well on SX12xx radios, it's quite deaf. We are still in the planning phase, we expect to have it built by end of this year. The mark drop feature that @LiamMehle is preparing is an important part of it, it would be great if you can consider his work for merge at some point.

[richonguzman]

@richonguzman lora only, probably the IPEX t-beams with SX1268, and a few digis, one for the base and one with a battery/solar combo as fill-in if we need to install it somewhere to extend coverage. BTW In my experience AFSK doesn't work well on SX12xx radios, it's quite deaf. We are still in the planning phase, we expect to have it built by end of this year. The mark drop feature that @LiamMehle is preparing is an important part of it, it would be great if you can consider his work for merge at some point.

will write him!

[LiamMehle]

Hey, @richonguzman. I have implemented the mark drop feature enough to test. It's at least missing some way to configure the name of the object to be dropped to avoid name collisions and ID the marked objects, and configuration for which GPIO (or other source) triggers the mark. Currently both are hardcoded. Feedback would be appreciated.

[richonguzman]

Hey, @richonguzman. I have implemented the mark drop feature enough to test. It's at least missing some way to configure the name of the object to be dropped to avoid name collisions and ID the marked objects, and configuration for which GPIO (or other source) triggers the mark. Currently both are hardcoded. Feedback would be appreciated.

@LiamMehle do you have Telegram? write me at my user to talk about this! this is an idea I was working also !