Open hemna opened 2 years ago
This is how the packet is being sent
https://github.com/craigerl/aprsd/blob/master/aprsd/clients/kiss.py#L89-L93
The message code actually manages the msgid
field itself. If you set oneshot=False
, it will fill in the msgid
from a counter managed by the APRSInterface
class.
Is there a requirement in your application to manage the msgid
field directly?
Two ideas come to mind:
APRSInterface
to support an external counter class that can be shared by other code that needs to track the message ID externally.msgid
parameter to send_message
so that you can specify the msgid
(onus will be on the caller to ensure it is unique).so aprsd uses aprslib for client connections to aprsis servers as well. i have to manage message numbers and ack counts and replies manually with it. i have abstracted out a client object that uses aprslib or tcpkiss or serialkiss underneath it. so i pack the message mumber as part of the message itself according to the aprs spec. aprslib can exctract that and creates an aprs "packet" dict with all the particulars.
So yes i need to be able to send a message packet that includes the msg number.
What's handling the retransmissions in the case of a dropped packet? Does aioax25
need to manage retransmissions with a caller-supplied msgid
, or is it sufficient to send the message "one-shot" and rely on aprslib
to handle retransmissions if a message gets lost?
in the case of aprsd it will detect that it hasnt gotten an ack and will retransmit the message itself via another one shot message
Right, so we just really need a dumb UI frame transmit with no real smarts behind the scenes, since the APRS message itself is already constructed and aprslib
itself is managing retransmissions.
https://github.com/sjlongland/aioax25/blob/master/aioax25/aprs/aprs.py#L163-L170 is basically what send_message
does when oneshot=True
.
You might be able to do what you're after with something like this:
self.aprsint.transmit(APRSFrame(
destination=msg.tocall,
source=self.mycall,
payload=(':%-9s:%s' % (
msg.tocall,
payload
)).encode('US-ASCII'),
repeaters=["WIDE1-1", "WIDE2-1"]
))
Ok thanks for the help. I have a modified version of that that seems to get received on the other side. Now I'm running into replies getting dropped because they are all Third-party packets.
08/03/2022 09:16:01 AM TXPKT-3-help INFO messaging.py:584
Sending Message _______________(TX:1)
Raw : WB4BOR-12>APZ100::WB4BOR-11:help{3
To : WB4BOR-11
Message : help
Msg # : 3
Sending Message _______________ Complete
08/03/2022 09:16:01 AM TXPKT-3-help DEBUG GET client tcpkiss client.py:226
08/03/2022 09:16:01 AM TXPKT-3-help DEBUG Send 'WB4BOR-12>APZ100::WB4BOR-11:help{3 kiss.py:109
' TO KISS
08/03/2022 09:16:01 AM TXPKT-3-help INFO Sending WB4BOR-12>WB4BOR-11,WIDE1-1,WIDE2-1: PID=0xf0 aprs.py:330
Payload=b':WB4BOR-11:help{3'
08/03/2022 09:16:01 AM TXPKT-3-help DEBUG Adding to queue: WB4BOR-12>WB4BOR-11,WIDE1-1,WIDE2-1: PID=0xf0 interface.py:62
Payload=b':WB4BOR-11:help{3'
08/03/2022 09:16:01 AM TXPKT-3-help DEBUG Scheduling next transmission ASAP interface.py:113
08/03/2022 09:16:05 AM RX_MSG DEBUG Transmitting WB4BOR-12>WB4BOR-11,WIDE1-1,WIDE2-1: PID=0xf0 interface.py:141
Payload=b':WB4BOR-11:help{3'
08/03/2022 09:16:05 AM RX_MSG DEBUG XMIT AX.25 WB4BOR-12>WB4BOR-11,WIDE1-1,WIDE2-1: PID=0xf0 kiss.py:619
Payload=b':WB4BOR-11:help{3'
08/03/2022 09:16:05 AM RX_MSG DEBUG XMIT FRAME '00ae8468849ea476ae8468849ea4f8ae92888a624062ae92888a64406303f03a57423 kiss.py:226
4424f522d31313a68656c707b33'
08/03/2022 09:16:05 AM RX_MSG DEBUG Clear-to-send expiry at 358.08661028348564 interface.py:89
08/03/2022 09:16:05 AM RX_MSG DEBUG XMIT RAW 'c000ae8468849ea476ae8468849ea4f8ae92888a624062ae92888a64406303f03a57423 kiss.py:319
4424f522d31313a68656c707b33c0'
08/03/2022 09:16:08 AM RX_MSG DEBUG RECV RAW 'c000ae8468849ea476ae8468849ea4f8966886a24040e8ae92888a6240e0ae92888a644 kiss.py:211
06303f03a574234424f522d31313a68656c707b33c0'
And the RX
08/03/2022 09:16:24 AM RX_MSG DEBUG Handling incoming frame APPOMX*>APDW16*,K4CQ-4*,WIDE1*,WIDE2-1: PID=0xf0 router.py:95
Payload=b'}WB4BOR-11>APZ100,TCPIP,APPOMX*::WB4BOR-12:plugins: avwxweather email
location location-slack openweathermap{15'
08/03/2022 09:16:24 AM RX_MSG DEBUG Dispatching frame to 0 receivers router.py:133
08/03/2022 09:16:24 AM RX_MSG DEBUG Failed to decode as APRS frame.py:46
╭────────────────────── Traceback (most recent call last) ──────────────────────╮
│ │
│ /Users/i530566/devel/mine/hamradio/aioax25/aioax25/aprs/frame.py:38 in decode │
│ │
│ 35 │ │ try: │
│ 36 │ │ │ # Inspect the first byte. │
│ 37 │ │ │ type_code = APRSDataType(uiframe.payload[0]) │
│ ❱ 38 │ │ │ handler_class = cls.DATA_TYPE_HANDLERS[type_code] │
│ 39 │ │ │ │
│ 40 │ │ │ # Decode the payload as text │
│ 41 │ │ │ payload = uiframe.payload.decode('US-ASCII') │
╰───────────────────────────────────────────────────────────────────────────────╯
KeyError: <APRSDataType.THIRD_PARTY: 125>
08/03/2022 09:16:24 AM RX_MSG DEBUG Processing incoming message APPOMX*>APDW16*,K4CQ-4*,WIDE1*,WIDE2-1: PID=0xf0 aprs.py:291
Payload=b'}WB4BOR-11>APZ100,TCPIP,APPOMX*::WB4BOR-12:plugins: avwxweather email
location location-slack openweathermap{15' (type AX25UnnumberedInformationFrame)
08/03/2022 09:16:24 AM RX_MSG DEBUG Handling incoming frame APPOMX*>APDW16*,K4CQ-4*,WIDE1*,WIDE2-1: PID=0xf0 router.py:95
Payload=b'}WB4BOR-11>APZ100,TCPIP,APPOMX*::WB4BOR-12:plugins: avwxweather email
location location-slack openweathermap{15'
08/03/2022 09:16:24 AM RX_MSG DEBUG Dispatching frame to 0 receivers
The latest test code here:
https://github.com/craigerl/aprsd/blob/small_refactor/aprsd/clients/kiss.py#L107-L131
Yeah, third party packets is a whole area of APRS I'm unfamiliar with.
I am seeing a problem with sending a message that includes a message number. It looks like the message number is being stripped off the packet, resulting in incorrect acks coming back.
Here is an example from aprsd.
The direwolf log
The recieving APRSD instance view of the packet
As you can see the original message was sent to tcpkiss with a message number of 4, so I can get acks for message 4 back from the destination.
The destination didn't get a message number as part of the packet as it was stripped out, so it sent an ack with message number of 0.