FM APRS

1DangerMouse
Posts: 20
Joined: Sun May 03, 2020 12:31 am

Re: FM APRS

Post by 1DangerMouse » Mon Aug 28, 2023 11:18 am

VK3KYY wrote:
Mon Aug 28, 2023 11:09 am
1DangerMouse wrote:
Mon Aug 28, 2023 11:07 am
Was ever wondering if possible in a future if we can turn this Firmware APRS Feature into a Fill In Digipeater?

This be a Good Way to make a Portable Digi 😊👍

Could This Be Possible?
This has been answered already several times.
Ok I wasn’t aware , I’ve tried looking and didn’t see much on this.

SA0BUX
Posts: 701
Joined: Tue Jul 05, 2022 8:50 am
Location: JO99ah, Stockholm, Sweden
Contact:

Re: FM APRS

Post by SA0BUX » Mon Aug 28, 2023 11:20 am

VK3KYY wrote:
Mon Aug 28, 2023 11:05 am
SA0BUX wrote:
Mon Aug 28, 2023 11:02 am
I tried some of the values: API92 , API910, APN001, APOSW0 didn't showed up in aprs.fi.

APK003 worked, APK004 didn't.

The digipeater is https://aprs.fi/info/SL3ZB-2
Very interesting.

Thanks for testing.

Can you try

APOGD77

I just tried that, and it worked OK

Code: Select all

2023-08-28 21:04:27 AEST: VK3KYY>APOG77,WIDE1-1,WIDE2-1,qAO,VK3MDH-10:!3758.97S/14502.14E-

Nevermind, it worked now with the other RT3S

https://aprs.fi/info/a/SA0BUX-15


Have to test more with the first radio (which has GPS), could be some rate limiting function in the path, when it works I usually hear the digipeater repeat the packet to SK3BG-10

User avatar
DU2XXR
Posts: 191
Joined: Thu Nov 28, 2019 5:25 am
Location: Philippines
Contact:

Re: FM APRS

Post by DU2XXR » Mon Aug 28, 2023 7:41 pm

Since this is still an experimental application, I would recommend something that starts with APZ, so that openGD77 would be compliant with APRS spec. Once the implementation is more stable, then the devs can start requesting a more definite identifier to be included in the distributed list.

Also, it might be best to limit it to 6 characters. Some devices or applications might run into issues if it exceeds the length.

I myself have been developing APRSPH / IORETH since early 2022, and I am still using the APZIOR identifier (not in a hurry to get listed, actually).

VK3KYY
Posts: 8143
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: FM APRS

Post by VK3KYY » Mon Aug 28, 2023 9:52 pm

DU2XXR wrote:
Mon Aug 28, 2023 7:41 pm

Also, it might be best to limit it to 6 characters. Some devices or applications might run into issues if it exceeds the length.
The CPS already only allows 6 characters and only allows upper case letter, and numbers.

Because of communication with satellites and other systems, the Destination is editable. People can enter whatever they want, but obviously if they enter something not starting with AP it won't get routed by the traditional APRS network

I don't see the APRS functionality changing much in the future, in a way that would need to have one destination now and another destination at later stages of software development. The firmware is already transmitting a standard APRS packet.

We may send Mic-e packets and status messages, in the future, but I presume that the destination address is not related to the specific APRS data that is being set.

User avatar
DU2XXR
Posts: 191
Joined: Thu Nov 28, 2019 5:25 am
Location: Philippines
Contact:

Re: FM APRS

Post by DU2XXR » Mon Aug 28, 2023 11:40 pm

Most applications let the user define the digipath, but not necessarily the "destination" (again, which is only the identifier for the device, application, or software that sends APRS packets over-the-air or to the APRS network). When working satellites, users would have to remove the terrestrial digipaths (e.g., WIDE1-1,WIDE2-1) and instead use ARISS, otherwise the on-board amsat digipeater will not digipeat the packet.

I guess one good feature to have is to be able to quickly revise or change digipaths (e.g., when switching between working terrestrial digipeaters and working satellites), either by selecting from pre-programmed (CPS?) digipaths, or editing it on the radio itself. As for the "destination", as an end-user I don't really need to change it unless experimenting with identifying my own device differently.

For APRS messaging (not beaconing), the actual addressee is called the TOCALL, which is different from the APRS destination.
VK3KYY wrote:
Mon Aug 28, 2023 9:52 pm
DU2XXR wrote:
Mon Aug 28, 2023 7:41 pm

Also, it might be best to limit it to 6 characters. Some devices or applications might run into issues if it exceeds the length.
The CPS already only allows 6 characters and only allows upper case letter, and numbers.

Because of communication with satellites and other systems, the Destination is editable. People can enter whatever they want, but obviously if they enter something not starting with AP it won't get routed by the traditional APRS network

I don't see the APRS functionality changing much in the future, in a way that would need to have one destination now and another destination at later stages of software development. The firmware is already transmitting a standard APRS packet.

We may send Mic-e packets and status messages, in the future, but I presume that the destination address is not related to the specific APRS data that is being set.

VK3KYY
Posts: 8143
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: FM APRS

Post by VK3KYY » Mon Aug 28, 2023 11:43 pm

DU2XXR wrote:
Mon Aug 28, 2023 11:40 pm
Most applications let the user define the digipath, but not necessarily the "destination" (again, which is only the identifier for the device, application, or software that sends APRS packets over-the-air or to the APRS network). When working satellites, users would have to remove the terrestrial digipaths (e.g., WIDE1-1,WIDE2-1) and instead use ARISS, otherwise the on-board amsat digipeater will not digipeat the packet.

I guess one good feature to have is to be able to quickly revise or change digipaths (e.g., when switching between working terrestrial digipeaters and working satellites), either by selecting from pre-programmed (CPS?) digipaths, or editing it on the radio itself. As for the "destination", as an end-user I don't really need to change it unless experimenting with identifying my own device differently.

For APRS messaging (not beaconing), the actual addressee is called the TOCALL, which is different from the APRS destination.
VK3KYY wrote:
Mon Aug 28, 2023 9:52 pm
DU2XXR wrote:
Mon Aug 28, 2023 7:41 pm

Also, it might be best to limit it to 6 characters. Some devices or applications might run into issues if it exceeds the length.
The CPS already only allows 6 characters and only allows upper case letter, and numbers.

Because of communication with satellites and other systems, the Destination is editable. People can enter whatever they want, but obviously if they enter something not starting with AP it won't get routed by the traditional APRS network

I don't see the APRS functionality changing much in the future, in a way that would need to have one destination now and another destination at later stages of software development. The firmware is already transmitting a standard APRS packet.

We may send Mic-e packets and status messages, in the future, but I presume that the destination address is not related to the specific APRS data that is being set.
OK.

My mistake

I see that the satellite is digi / via [0]

I'm not sure whether to hard code the Destination . Perhaps I should hard code it, as it would free up 6 bytes in each APRS Config data item

1DangerMouse
Posts: 20
Joined: Sun May 03, 2020 12:31 am

Re: FM APRS

Post by 1DangerMouse » Tue Aug 29, 2023 2:38 am

1DangerMouse wrote:
Mon Aug 28, 2023 11:18 am
VK3KYY wrote:
Mon Aug 28, 2023 11:09 am
1DangerMouse wrote:
Mon Aug 28, 2023 11:07 am
Was ever wondering if possible in a future if we can turn this Firmware APRS Feature into a Fill In Digipeater?

This be a Good Way to make a Portable Digi 😊👍

Could This Be Possible?
This has been answered already several times.
Ok I wasn’t aware , I’ve tried looking and didn’t see much on this.
So Basically From What I’ve Learned we can’t try this on the RT3S for a Fill In Digipeater Then?

If so do we use WIDE etc?

VK3KYY
Posts: 8143
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: FM APRS

Post by VK3KYY » Tue Aug 29, 2023 6:45 am

I'm changing the firmware to use APOGD77 and will register with that github repo

User avatar
DU2XXR
Posts: 191
Joined: Thu Nov 28, 2019 5:25 am
Location: Philippines
Contact:

Re: FM APRS

Post by DU2XXR » Tue Aug 29, 2023 7:03 am

Given the 6-digit max convention, perhaps APOG77 might be better. Or APGD77?

Then yes, it will be good as it frees up additional bytes for other config items. I think it's more important to let the user define the digipath (or maybe choose between several options).
VK3KYY wrote:
Tue Aug 29, 2023 6:45 am
I'm changing the firmware to use APOGD77 and will register with that github repo

VK3KYY
Posts: 8143
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: FM APRS

Post by VK3KYY » Tue Aug 29, 2023 7:07 am

DU2XXR wrote:
Tue Aug 29, 2023 7:03 am
Given the 6-digit max convention, perhaps APOG77 might be better. Or APGD77?

Then yes, it will be good as it frees up additional bytes for other config items. I think it's more important to let the user define the digipath (or maybe choose between several options).
VK3KYY wrote:
Tue Aug 29, 2023 6:45 am
I'm changing the firmware to use APOGD77 and will register with that github repo
Edit.

My mistake. I'm using

APOG77

Dropping the D

Because the APO is for Open Source

We use .g77 for the codeplug, so dropping the D has precedence

Post Reply