Re: Protocol Issue? Cannot get any response to my APRS Beacons
Hi Brian,
For clarification, the Rx audio out of the rig goes to all of the
ports, regardless of what mode you're using.? It's the Tx side that
is specific to wherever the PTT is coming from.? But, from your
description, it sounds like you've got things wired up correctly.? I
presume you have menu #23 (packet rate) set correctly.
No more ideas here, other than Andrew's suggestion to verify your
transmit volume level.? I'm driving my 847 from a USB sound card
(Raspberry Pi with Direwolf), and it's cranked all the way up.
Greg? KO6TH
kodiak wrote:
toggle quoted message
Show quoted text
Andrew:? Thanks for
your response.? ? Yes, I am using the dedicated 'packet' 6 pin DIN
for all connections. On the "TNC" side of the packet cable I have
pinned PTT to DB9 Pin 3, TX Data to Pin 1, RX Data (1200baud) to
Pin5, and wrapped the signal and chassis grounds together on Pin
6; I don't hook up the squelch wire, the TNC can be set for
software-controlled squelch control which is easier.? ? ?I utilize
a DB-9 breakout connector (see below)? for the testing which makes
troubleshooting much simpler:
I was unaware that the audio is suppressed on the other jacks if
the packet connector is used.? However it does make sense, the
external speaker jack also cannot be used if the headphone jack in
the front is in use.? There is a workaround for tapping receive
audio from the Ring/Sleeve of the "data" jack (Tip is PTT).? When
I work satellites I tap audio from the data jack to feed a
recording device, it's crude but it works. That said, the tap is a
modulated audio signal and more than likely 9600 baud, useless for
feeding into the TNC.?
Again, Thanks for your response ....Brian/AA5H
|
Re: Protocol Issue? Cannot get any response to my APRS Beacons
Greg:? Thanks for your response.? ? Yes, I am using the dedicated 'packet' 6 pin DIN for all connections. On the "TNC" side of the packet cable I have pinned PTT to DB9 Pin 3, TX Data to Pin 1, RX Data (1200baud) to Pin5, and wrapped the signal and chassis grounds together on Pin 6; I don't hook up the squelch wire, the TNC can be set for software-controlled squelch control which is easier.? ? ?I utilize a DB-9 breakout connector (see below)? for the testing which makes troubleshooting much simpler:  I was unaware that the audio is suppressed on the other jacks if the packet connector is used.? However it does make sense, the external speaker jack also cannot be used if the headphone jack in the front is in use.? There is a workaround for tapping receive audio from the Ring/Sleeve of the "data" jack (Tip is PTT).? When I work satellites I tap audio from the data jack to feed a recording device, it's crude but it works. That said, the tap is a modulated audio signal and more than likely 9600 baud, useless for feeding into the TNC.? Again, Thanks for your response ....Brian/AA5H
|
Re: Protocol Issue? Cannot get any response to my APRS Beacons
Adding to Andrew's note... Where is the audio coming into the 847,
compared to where the source of PTT is?
The 847 uses the port where PTT is asserted to decide which port to
listen to for transmit audio; audio level from other ports is reduced by
something like 20db - barely audible. Receive audio goes to all of
them, so the ability to receive but not transmit reliably fits with a
mismatch.
There are two ports on the back, plus the mike / speaker combination,
and the CAT port. 1200 / 9600 baud FM packet can only come in via the
6-pin DIN connector, and that connector's PTT line must be used for
keying. You can't, for example, key the radio with CAT, the PTT jack,
or the Data In/Out port, if the audio is coming in from the DIN
connector. Makes it very difficult to use a single TNC for both packet
and HF digital modes.
Greg KO6TH
Andrew P. wrote:
toggle quoted message
Show quoted text
3. You say when the KPC-3 is sending packets, none of them are understood by other stations. So, are you sending at the correct signal level to avoid compression and distortion by the radio, or are you overmodulating? Just because you somehow got the correct signal levels with the SignaLink is no guarantee you are _also_ going to get the correct levels with a totally different audio source (the KPC-3).
|
Re: Protocol Issue? Cannot get any response to my APRS Beacons
Let's look at your issues, step by step. 1. You say that when you use a SignaLink (and presumably some modem software like DireWolf), everything works perfectly. So that says, when you are using the SignaLink audio path, your levels are close enough to correct so you are not overmodulating and distorting your signal. 2. Note that the RESTART after the KISS ON is a TNC2 quirk; the RESET after an INTFACE KISS might not be necessary for a KPC3 (I don't own one, so I can't confirm the correct usage; I was told to implement this by another KPC-3 owner). 3. You say when the KPC-3 is sending packets, none of them are understood by other stations. So, are you sending at the correct signal level to avoid compression and distortion by the radio, or are you overmodulating? Just because you somehow got the correct signal levels with the SignaLink is no guarantee you are _also_ going to get the correct levels with a totally different audio source (the KPC-3). 4. Are you sure you are actually _transmitting_ when using the KPC-3? Yaesu radios have a non-standard behavior with the 6-pin data jack cable, so the cable coming from the KPC-3 may not be connected to the radio correctly. Listen with another radio to your transmissions when using the SignaLink, then do so when using the KPC-3. Do the packets sound the same (no extra distortion, no radically different volume levels, etc.)? If your KPC-3 packets sound distorted, there is no guarantee that other stations will be able to decode them. And if they can't decode them, they won't respond to or digipeat them. 5. Your point about sending a packet directly to a specific station doesn't make sense. Do you mean you are sending an APRS text message packet addressed to that one station? Are you doing this with the same KPC-3 setup? Have you tried doing the exact same transmission addressed to other stations? It could be that one station is using DireWolf or some other software modem that is more tolerant of poor-quality modulation. Most hardware modems are very intolerant of poor-quality signals, and most digipeaters use hardware modems and custom firmware to be only a digipeater. The _only_ TNC to radio connections that are guaranteed to have the correct signal level out-of-the-box are the Kenwood D710/D72/D74 radios, where the TNC is built into the radio and can't have its analog signal levels screwed up by the user. For any separate radio and external TNC (software or hardware), you need to get the levels matched correctly, which will require some trial-and-error and measurement of your transmitted signal. Hope this helps. Andrew, KA2DDO author of YAAC ________________________________________ From: [email protected] < [email protected]> on behalf of kodiak <kodiakat777@...> Sent: Friday, May 21, 2021 5:56 PM To: [email protected]Subject: [yaac-users] Protocol Issue? Cannot get any response to my APRS Beacons HI; I've been trying to resolve a problem for two weeks. I have spent dozens of hours on the phone With Kantronics thinking it was a hardware problem; recent test results are proving otherwise. Circuit Setup: FT-847 connected from the radio packet port to a Kantronics KPC-3 Plus. The KPC plugs into the PC using a USB Cable. In my current configuration, I am manually setting (via Putty) the TNC into KISS mode, performing a reset, then configuring a TNC port in YAAC. I've tried allowing YAAC to push the INTFACE KISS commands, but the Kantronics usually falls back out of KISS mode after the reset command. Heres what DOES work: - YAAC works using a Singalink as a dumb modem; same radio, same PC, same cable. - I have a high-gain antenna and plenty of power; and when I broadcast through the Signalink I get immediate responses from dozens of local APRS stations. - Receive packets are good. I can log into the TNC and watch the packets arrive, the KISS headers are in hex/binary as expected, the payload is readable. The KISS packets that arrive at YAAC, are properly decoded, and stations are plotted on the map. - If I choose a single station in YAAC and send a test message I receive an immediate ACK response. - YAAC is decoding and attempting to respond to other digipeaters. Heres what SORTA works: I have to manually set the TNC into KISS mode. I've tried allowing YAAC to push the INTFACE KISS commands, but the Kantronics usually falls back out of KISS mode after the reset command. Manually setting the TNC into KISS mode is a bit annoying, but it's not that big a problem; otherwise, it's just an additional step. Here is what DOESNT work: - None of the digipeater responses appear to be heard, same for all my status reports and beacons. I send beacons, status reports, respond to the others stations....all ignored.... If I send a direct message to a station, I get an immediate ACK, but any type of broadcast results in crickets. Without the ability to interact with other nodes and digipeaters the entire system is useless. My hypothesis; - The Radio, TNC, PC, and cabling are correct. I can send direct packets to other stations and receive acks to the same messages. - There is something amiss in the protocol stack for broadcast-type packets; perhaps a flag in the packet header is not set, or incorrectly see, I just don't know Any help would be appreciated! Thanks Brian, AA5H
|
Protocol Issue? Cannot get any response to my APRS Beacons
HI;? ? I've been trying?to resolve a problem for two weeks. I?have spent dozens of hours on the phone? With Kantronics thinking it was a hardware problem; recent test results?are proving otherwise.?
Circuit Setup:? FT-847 connected from the radio packet port to a Kantronics KPC-3 Plus. The KPC plugs into the?PC using a USB Cable.? ??
In my current configuration, I am manually setting? (via Putty) the TNC into KISS mode, performing a reset, then configuring a TNC port in YAAC.? ?I've tried allowing YAAC to push the INTFACE?KISS commands, but the Kantronics usually?falls back out of KISS mode after the reset command.
Heres what DOES work:?
-? YAAC works using a Singalink as a dumb modem; same radio, same PC, same cable.??
- I have a high-gain antenna and plenty of power; and when I broadcast through the Signalink I get immediate responses from dozens of local APRS stations.
- Receive packets are good.? I can log into the TNC and watch the packets arrive, the KISS headers are in hex/binary as expected, the payload is readable.? The KISS packets that arrive at YAAC, are?properly decoded, and stations are plotted on the map.
- If I? choose a single station in YAAC?and send a test message I receive an immediate ACK response.?
- YAAC is decoding and?attempting to respond to other digipeaters.? ?
Heres what SORTA works:?
I have to manually?set the TNC into KISS mode.? ?I've tried allowing YAAC to push the INTFACE?KISS commands, but the Kantronics usually?falls back out of KISS mode after the reset command.? ? Manually setting the TNC into KISS mode is a bit annoying, but it's not that big a problem; otherwise, it's just an additional step.
Here is what DOESNT?work:
- None of the digipeater responses appear to be heard, same for all my status reports and beacons. I send beacons, status reports, respond to the others stations....all ignored....? ? ?If I send a direct message to a station, I get an immediate ACK, but any type of broadcast results in crickets.? Without the ability to interact with other nodes and digipeaters the entire system is useless.?
My hypothesis;
- The Radio, TNC, PC, and cabling?are correct.? I can send direct packets to other stations and receive acks to the same messages.?
- There is something amiss in the protocol stack for? broadcast-type packets; perhaps a flag in the packet header is not set, or incorrectly see, I just don't know
Any help would be appreciated!
Thanks
Brian, AA5H
|
Re: Accessing TNC commands
Do you actually need an emulator for the full functionality of TNC2 command mode while in YAAC? The setup commands should already be done for your local hardware (TXDELAY, etc.), so you shouldn't need to mess with them. Since you would be using YAAC to perform beaconing, you don't need the beacon setting commands. Because APRS is always listening to everyone, the equivalent of the MONITOR and MHEARD commands are already in the YAAC Station/Object List. The connected-mode AX.25 session window handles the equivalent of the TNC2 CONNECT command. So what specific TNC2 command-mode commands do you need access to? Andrew, KA2DDO author of YAAC ________________________________________ From: [email protected] < [email protected]> on behalf of Joshua KJ7LVZ <joshuajayg@...> Sent: Friday, May 21, 2021 9:34 AM To: [email protected]Subject: [yaac-users] Accessing TNC commands Though I use numerous Raspberry Pis for different projects (including ham radio), I would like to interface my computer with a KISS TNC and be able to connect to a BBS through a terminal program. My struggle is that my laptop is a Macbook Pro. The ham radio community doesn't have much for OSX applications. BPQ32 has a TNC2 emulator that puts a terminal front end on a KISS TNC so you can send commands though a terminal and interact with it like it's a TNC2. The problem is, BPQ32 isn't compatible with OSX. YAAC has the PBBS, chat, and Winlink options in the messages menu so it is capable of talking with a BBS node though my KISS TNC. Is there a way to expose or create an emulator like BPQ32 did here?<> My TM-D710G has an exposed TNC and I can easily connect to it with my laptop but my other mobile radio is a TM-V71A and I use a homemade Mobilinkd TNC for packet with it.
|
Though I use numerous Raspberry Pis for different projects (including ham radio), I would like to interface my computer with a KISS TNC and be able to connect to a BBS through a terminal program.? My struggle is that my laptop is a Macbook Pro.? The ham radio community doesn't have much for OSX applications.? BPQ32 has a TNC2 emulator that puts a terminal front end on a KISS TNC so you can send commands though a terminal and interact with it like it's a TNC2.? The problem is, BPQ32 isn't compatible with OSX.??
YAAC has the PBBS, chat, and Winlink options in the messages menu so it is capable of talking with a BBS node though my KISS TNC.? Is there a way to expose or create an emulator like BPQ32 did ? My TM-D710G has an exposed TNC and I can easily connect to it with my laptop but my other mobile radio is a TM-V71A and I use a homemade Mobilinkd TNC for packet with it.
|
Re: APRS-IS filter + error message
That is a message I added recently to report when you are using an APRS-IS filter that depends upon your station telling the APRS-IS backbone where you are located, but you aren't actually sending a position to the APRS-IS. Since you are configured to not send a beacon through the APRS-IS port, the APRS-IS will not know where the center is of the 200-kilometer circle you are specifying. Lots of people have complained that they weren't getting the extra APRS-IS traffic back when they specified a radius filter without identifying where the center of the circle was. To get rid of the message, either transmit your position beacon through the APRS-IS port, or switch to a different filter that specifies the circle center explicitly instead of implying the position reported (but not actually being reported) by your station. For example, r/38/-95/200 where this implies the circle center is as 38 degrees North latitude, 95 degrees West longitude. Andrew, KA2DDO author of YAAC ________________________________________ From: [email protected] < [email protected]> on behalf of Paul Bramscher <pfbram@...> Sent: Friday, May 14, 2021 5:21 PM To: [email protected]Subject: [yaac-users] APRS-IS filter + error message Greetings, Been running YAAC for several years, Debian Linux, Kenwood D710. I have three profiles: one for terrestrial APRS, one as a digipeater, and one for satellite (ISS) work. I'm getting a strange message that I don't recall seeing before on my terrestrial profile. If I click to edit the APRS-IS port and then close it, with or without making any changes, I get a window message: Error saving changes "You are using an m/NNN filter expression but are not configured to transmit a beacon through this port, so you will not receive any packets." My setting for APRS-IS filter: m/200 I've probably had that setting for several years, and I thought mainly it meant that I would not be seeing APRS internet traffic unless it was 200 km or closer. I didn't think it had any effect on transmitting. Also, the error message states that I won't be receiving any packets. I don't recall seeing this pop-up before. Has something changed? Thanks! 73, KD0KZE / Paul
|
APRS-IS filter + error message
Greetings,
Been running YAAC for several years, Debian Linux, Kenwood D710. I have
three profiles: one for terrestrial APRS, one as a digipeater, and one
for satellite (ISS) work.
I'm getting a strange message that I don't recall seeing before on my
terrestrial profile. If I click to edit the APRS-IS port and then close
it, with or without making any changes, I get a window message:
Error saving changes
"You are using an m/NNN filter expression but are not configured to
transmit a beacon through this port,
so you will not receive any packets."
My setting for APRS-IS filter: m/200
I've probably had that setting for several years, and I thought mainly
it meant that I would not be seeing APRS internet traffic unless it was
200 km or closer. I didn't think it had any effect on transmitting.
Also, the error message states that I won't be receiving any packets.
I don't recall seeing this pop-up before. Has something changed?
Thanks!
73, KD0KZE / Paul
|
Re: Satellite filters? Useful or not necessary?
Weeellllll.... None, if I'm painfully honest.? I've only had it up a few hours off and on over the last few days.? I'm still trying to learn as much as I can about "Best practices" settings before I leave it on autopilot.
I've done some more reading over the last day and stumbled on this conversation:
That info is about 4 years old, but it's hard finding anything current.
The delay mentioned there seems like it would serve a similar function as a terrestrial filter, without the effect of completely killing the packet.? Further down in the conversation, another user mentions that Direwolf has a SATGATE function to specifically implement this delay before gating.? The port that I'm going to use for sGate listening is a Direwolf port, so for grins I tried turning that setting on.? As far as I can tell, that delay is strictly implemented in its own gating functions, it seems like it passes heard packets to YAAC immediately.? It also makes mention on the loading text that "SATGATE is a pretty useless function and will probably be removed in future versions."?? Deep in the Direwolf user guide, it has language that "Of course some other IGate probably send the original promptly so this could just be an exercise in futility."? ... still.. best practices, and all that..
It seems like a good idea, but I can't tell if this plan has been abandoned, as the most recent info I can find is from 2017-2018 range, but maybe a checkbox option on the "Ports" tab for "Satellite Gate - 10s delay for gating directly received packets on this port"
I don't know anything about programming, I have no idea how onerous that would be to program, and I can imagine there are a lot of other things higher on the "to-do" list.? Maybe a filter would be easier --- maybe it's not worth bothering at all.? Anyway.. for your consideration.
Thanks for writing and maintaining this software!? Learning it, learning linux, and really getting a deeper understanding of APRS has been hugely interesting these past few months.
JH
|
Re: Satellite filters? Useful or not necessary?
That is an interesting concept. In theory, your assumption is correct; if you are running a sat-gate and a sat user is transmitting within direct receive range of you, it is possible that you could I-gate the packet before the ISS digipeater could send it back. But they would have to be within direct contact (non-digipeated) of your sat-gate for this to happen. YAAC doesn't presently support viscous digipeating, so it wouldn't skip ahead of the ARISS or ISS or RS0ISS digipeat callsign to digipeat your packets itself (assuming the sender was using bad practice by specifying a second ground digipeat alias after the ISS alias). So how many satellite users can you hear directly (ground-wave) at your I-gate? I'm curious whether it's worth implementing such a receive I-gate filter. Andrew, KA2DDO author of YAAC ________________________________________ From: [email protected] < [email protected]> on behalf of johnhaley3@... <johnhaley3@...> Sent: Thursday, May 13, 2021 10:43 PM To: [email protected]Subject: [yaac-users] Satellite filters? Useful or not necessary? I've been running an iGate for about 8-10 years now, but have just recently moved to YAAC running on Raspberry Pi with a TNC-Pi. I love this software, so easy to use. Anyway, I sort of inherited an ancient 2m rig that has something burned out on the transmit side, but that receives very well, and I thought I'd add a second port and do some sGate operations as well. I added a USB sound card and got it working with Direwolf, and both ports are getting along nicely. I have zero experience with ISS/Amsat ops, so my question is this: I know that on 144.390, terrestrial APRS, that most packets are transmitted with the end goal of being gated to the IS backbone, by whatever route the propagation chooses. But anyone trying to work a satellite or the ISS on 145.825 is assumed to be specifically trying to get a packet digipeated by the ISS. If my station happens to directly hear a packet on 145.825 and gate it, it won't ever register as having traversed the ISS hop, right? I would think a station would rather have a packet ignored by ground stations in the hope of hitting the ISS, vs. always getting intercepted by a ground station and gated, causing rejection of the packet with the ISS in the path. Is there a way to reject or ignore (or otherwise NOT gate) a packet with ARISS in the path, while dutifully gating packets in which the ARISS has been replaced with a *'d alias? My goal is to be as useful as possible to stations trying to work the ISS while NOT being detrimental. Is my logic sound? Is such filtering possible? More to the point, is it beneficial or necessary? John KG5BQX, West Texas
|
Satellite filters? Useful or not necessary?
I've been running an iGate for about 8-10 years now, but have just recently moved to YAAC running on Raspberry Pi with a TNC-Pi.? I love this software, so easy to use.
Anyway, I sort of inherited an ancient 2m rig that has something burned out on the transmit side, but that receives very well, and I thought I'd add a second port and do some sGate operations as well.
I added a USB sound card and got it working with Direwolf, and both ports are getting along nicely.
I have zero experience with ISS/Amsat ops, so my question is this:? I know that on 144.390, terrestrial APRS, that most packets are transmitted with the end goal of being gated to the IS backbone, by whatever route the propagation chooses.? But anyone trying to work a satellite or the ISS on 145.825 is assumed to be specifically trying to get a packet digipeated by the ISS.? If my station happens to directly hear a packet on 145.825 and gate it, it won't ever register as having traversed the ISS hop, right?? I would think a station would rather have a packet ignored by ground stations in the hope of hitting the ISS, vs. always getting intercepted by a ground station and gated, causing rejection of the packet with the ISS in the path.
Is there a way to reject or ignore (or otherwise NOT gate) a packet with ARISS in the path, while dutifully gating packets in which the ARISS has been replaced with a *'d alias?? My goal is to be as useful as possible to stations trying to work the ISS while NOT being detrimental.? Is my logic sound?? Is such filtering possible?? More to the point, is it beneficial or necessary?
John
KG5BQX, West Texas
|
Ah, you're talking about supplemental IS-to-RF forwarding. This is a special case, used only in limited circumstances, to forward Internet APRS packets that don't meet the normal transmit-capable I-gate constraints of being either: 1. an APRS Text message addressed to an RF station that was reported to the Internet by this I-gate. 2. a Position beacon (any format) from the station that just sent a case#1 packet. However, you must be _very_ conservative in what additional traffic you allow to be forwarded this way, as the Internet has far more bandwidth than the 1200-baud RF channel, and a slight typo here can make the RF channel unusable within the direct transmission range of your station (and possibly further, depending on whether or not the nearby digipeaters get reconfigured to blacklist your flood). Furthermore, such traffic should be of interest to all the local RF users (otherwise, why are you cluttering the channel with it?); there generally is never a reason to force arbitrary packets from hundreds of miles away onto the local RF channel, as they would not be locally relevant. First, you have to add a filter to your APRS-IS port configuration so the additional traffic will be forwarded from the APRS-IS to your I-gate. Second, you have to add _another_ filter on the Transmit tab of the expert-mode Configuration dialog that specifies exactly which packets are to be forwarded on to RF. Really, if the YSF stations want to be known on APRS, they should have a local station transmit APRS Objects to report the YSF station location, frequency, and capabilities. Andrew, KA2DDO author of YAAC ________________________________________ From: [email protected] < [email protected]> on behalf of Kun N7DMR <sa4591@...> Sent: Tuesday, May 11, 2021 3:19 PM To: [email protected]Subject: [yaac-users] APRS Analog - YSF Is there a way for my Analog iGate to Digipeat beacons sent by YSF stations? Meaning when my YAAC iGate see there is packet sent from YSF station into APRS-IS, rebroadcast it as Analog.
|
Is there a way for my Analog iGate to Digipeat beacons sent by YSF stations? Meaning when my YAAC iGate see there is packet sent from YSF station into APRS-IS, rebroadcast it as Analog.
|
Ah, that make sense. I have make sure RF beacon and APRS-IS beacon happens at different time. I just want to probe RF path to a distance iGate.?
|
Well, your own station should be able to see any echo-backs from local digipeaters in the traffic you receive from RF, assuming you are using a non-empty digipeat path (if you don't authorize digipeating in your packets, no compliant digipeater will do so). In fact, on RF you will see _all_ digipeats from local digipeaters, not just the first one, unlike on the Internet backbone, which deliberately filters out duplicate copies of any received transmission. Of course, if you are half-way between two digipeaters that can't hear each other, their simultaneous retransmissions of your packets may collide with each other at your station so you end up getting nothing but RFI. Note also there is no guarantee there is any working I-gate within digipeated RF range of your station, hence there is no guarantee that your RF packets will ever make it to the APRS-IS backbone. I know a user who runs the only I-gate in his state (the next nearest ones are over the state line). If you use two beacon records, you can change the timing on the two beacon records so they are less likely to land on each other (ex.: RF beacon at 47 seconds decaying to 29 minutes, Internet beacon at 7 minutes decaying to 30 minutes). The only problem is that if you force beaconing (by tapping the spacebar on the map window), the beacons are all sent simultaneously, so they will have to drift apart again (hence why I suggested such significantly different and non-multiples-of-each-other beacon rates). Andrew, KA2DDO author of YAAC ________________________________________ From: [email protected] < [email protected]> on behalf of Kun N7DMR Sent: Friday, May 7, 2021 9:30 PMSubject: Re: [yaac-users] YAAC beacon settings Ah, that make sense. When I have both beacon on, only the Internet beacon shows up which made me believe the over-the-air beacon was not sent. However, I do want my RF beacon to show up, so that I could check out local RF condition based on which digipeater picked it up. Is there a way I could let the Internet beacon and RF beacon to go out at a different time?
|
Ah, that make sense. When I have both beacon on, only the Internet beacon shows up which made me believe the over-the-air beacon was not sent. However, I do want my RF beacon to show up, so that I could check out local RF condition based on which digipeater picked it up. Is there a way I could let the Internet beacon and RF beacon to go out at a different time?
|
This is a rather odd request. _Why_ don't you want your beacon going to the Internet? It's not considered good practice for an I-gate station. Your beacon can go to both ports simultaneously. You just won't ever see your RF-transmitted beacon coming back on APRS-IS because the direct-to-Internet packet will get there first (and some other I-gate may bring it to the Internet anyway if you disable it). And the receivers of any packets you forward to the Internet (which will be tagged with your callsign as the I-gate that forwarded it to the Internet backbone) will not know where they were received because they won't know your station position. And, yes, setting a port to "transmit disabled" means _nothing_ will be transmitted out that port; that was intentional, so that not-yet-licensed users could still legally use YAAC in a receive-only mode (like short-wave listeners). However, if you really want to do this, you need to create a second beacon record, and assign one beacon record to the RF port and the other one to the APRS-IS port, then disable (not delete) the beacon associated with the APRS-IS port. Disabled beacons are never transmitted, but every APRS transmitting port has to have _some_ beacon associated with it. Hope this helps. Andrew, KA2DDO author of YAAC ________________________________________ From: [email protected] < [email protected]> on behalf of Kun N7DMR Sent: Friday, May 7, 2021 7:24 PM Subject: [yaac-users] YAAC beacon settings I have some trouble setting YAAC beacon. I am running an APRS iGate. I want my beacon to go out to TNC port. However, it always goes to TCP/IP port. If I set TCP/IP port to none transmit, YAAC will stop forwarding packets from RF to APRS-IS. How do I configure my YAAC to beacon only via TNC?
|
I have some trouble setting YAAC beacon. I am running an APRS iGate. I want my beacon to go out to TNC port.
However, it always goes to TCP/IP port. If I set TCP/IP port to none transmit, YAAC will stop forwarding packets from RF to APRS-IS.
How do I configure my YAAC to beacon only via TNC?
|
Re: Headless REST API for sending/receiving messages?
Hi Andrew,
First, thank you for the speedy response and for providing YAAC to the amateur radio community.
Yes, I plan to create a plugin for YAAC that provides a REST server.?
The Sample plugin (along with the other source code) is exceptionally useful. I was able to get a quick prototype working this morning before work and can now listen to the various events. Now. It¡¯s just a matter of noodling around with how to cleanly integrate a RESTful server into the plugin. I have some ideas on how to move forward. The only thing I have decided on is that I want to make use of Swagger/Open API to define the API specification and generate the server-side and client-side stubs.
I¡¯ll keep you posted. Is there a separate developer list?
Keep up the good work! ?
73,
Gaston KT1RUN The Tech Prepper
toggle quoted message
Show quoted text
Greetings.That's an interesting idea. I presume you mean for YAAC to be a REST server in this context, not a REST client. YAAC has no REST functionality at the present time.However, your concept is entirely doable, except that my mini-webserver currently only supports the HTTP GET method; other methods are rejected with the BAD_METHOD HTTP error (405). But I could fix that in the next build. Note that the mini-webserver also doesn't provide the full functionality of a webapp container like Tomcat, so any extras you want to add (such as HTML form upload parsing) you would have to add yourself (or find appropriate 3rd-party libraries that can do it without a webapp container).Regarding APIs to get into the internal data and data flows of YAAC, you basically have access to every public class and method in YAAC itself, plus all the 3rd party libraries bundled with YAAC (such as JSSC, OpenMap, Apache Commons Math, and Apache Commons Compress); that's why I bundle the Javadocs of YAAC in the plugin SDK zip file. Note that, because YAAC still works with Java 8, it does _not_ enforce or use any of the module features introduced in Java 9.If you download the source distribution of YAAC, you can see not only the source code of core YAAC, but also the source code of every plugin I've released as well (not just the sample plugin), so you can see how they interface with core YAAC. For example, the RepeaterFinder plugin registers itself as a TrackerListener on the StationTracker object in YAAC, so it can be informed each time a new station or object is received (in case said station or object looks like a repeater station). The ADSBdecoder and AISDecoder plugins also access the StationTracker to create new pseudo-APRS objects representing the aircraft and ships they decode so these vessels can be plotted on the YAAC map like any other APRS station. Similarly, if you look at the APRSISPseudoServer, you can see how it registers another dynamic HTTP page with the mini-webserver (instantiated on a different port) so it can produce a status page like a real APRS-IS backbone server would produce. And the TelemetryAlarm plugin can create APRS text messages (the MessageMessage class) for submission to the Transmitter class when an out-of-range telemetry value is detected.So your item#3 is trivial; just register new web pages with the appropriate URLs that do the same thing as the MessagesPage and StationsPage but in the appropriate REST output data format. Item#2 requires adding support for non-GET methods on the mini-webserver, which I will put in the next build; your registered webpage for that would have to parse either REST URLs or HTML forms to get the data to insert into a MessageMessage object (APRS text message) and submit them to the Transmitter, then produce an appropriate HTML response page to report the results of the submission.Andrew, KA2DDOauthor of YAAC________________________________________From:?[email protected]?<[email protected]> on behalf of The Tech PrepperSent: Friday, May 7, 2021 9:11 AMSubject: [yaac-users] Headless REST API for sending/receiving messages?Happy Friday,I am new to the group, but have been enjoying YAAC for a few months. As a Java software engineer I love that this project has a plugin architecture.I don't want to re-invent the wheel, but I am looking to run APRS fully headless via a REST-based API. I've seen mentions of the headless mode (nogui option) and the small web server, but it does not look like there's an API that exposes a subset of features?Here's my use case:1. Create a plugin that provides a REST endpoint for sending location beacons and station messages.2. In terms of API POST requests, my MVP is to add abstractions for sending messages to the following SSIDs: SMEGTE, EMAIL-2 and APRS2SOTA (and possibly station-to-station).3. In terms of API GET requests, my MVP is to list heard stations and incoming messages.4. This will all run on a Raspberry Pi and function as a man portable field station. I love operating from the backcountry.5. Today, I am connecting to the hotspot on my iPhone via VNC and launching YAAC. The new goal is to start direwolf and YAAC along with my API plugin on startup. For the user interface, I will be designing a small Progressive Web Application (PWA) with Node.js that will run on the Pi. Then, I can simply run the PWA from any device that has a web browser and is connected to the hotspot.My question is this: Does a REST API exist that offers endpoints for sending simple messages and/or listing heard stations? If not, this something I am starting on today.73,Gaston KT1RUNThe Tech Prepper
|
SeaBass
The Tech Prepper