FM APRS

[1DangerMouse]

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]

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

[DU2XXR]

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]

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.

[DU2XXR]

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.

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]

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.

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]

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]

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

[DU2XXR]

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).

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

[VK3KYY]

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).

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