Ok I wasn’t aware , I’ve tried looking and didn’t see much on this.VK3KYY wrote: ↑Mon Aug 28, 2023 11:09 amThis has been answered already several times.1DangerMouse wrote: ↑Mon Aug 28, 2023 11:07 amWas 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?
FM APRS
-
- Posts: 20
- Joined: Sun May 03, 2020 12:31 am
Re: FM APRS
Re: FM APRS
VK3KYY wrote: ↑Mon Aug 28, 2023 11:05 amVery interesting.SA0BUX wrote: ↑Mon Aug 28, 2023 11:02 amI 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
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
Re: FM APRS
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).
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).
Re: FM APRS
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.
Re: FM APRS
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.
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 pmThe 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.
Re: FM APRS
OK.DU2XXR wrote: ↑Mon Aug 28, 2023 11:40 pmMost 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 pmThe 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.
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
-
- Posts: 20
- Joined: Sun May 03, 2020 12:31 am
Re: FM APRS
So Basically From What I’ve Learned we can’t try this on the RT3S for a Fill In Digipeater Then?1DangerMouse wrote: ↑Mon Aug 28, 2023 11:18 amOk I wasn’t aware , I’ve tried looking and didn’t see much on this.VK3KYY wrote: ↑Mon Aug 28, 2023 11:09 amThis has been answered already several times.1DangerMouse wrote: ↑Mon Aug 28, 2023 11:07 amWas 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?
If so do we use WIDE etc?
Re: FM APRS
I'm changing the firmware to use APOGD77 and will register with that github repo
Re: FM APRS
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).
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).
Re: FM APRS
Edit.DU2XXR wrote: ↑Tue Aug 29, 2023 7:03 amGiven 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).
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