hessu / aprs-specs Goto Github PK

First, thanks for publishing these excellent documents. I've implemented the specification for BLE and TCP TNC discovery in an iOS Winlink client. It is magical!

A couple of thoughts:

1. The KISS TNC discovery spec described here are broader than APRS. Perhaps rename this repo to reflect the general purpose nature?
2. Maybe the DNS-SD mechanism could be expanded to other type of service discovery. Two popular come to mind:

• VARA modems. Client exposes a command port, usually 8300 and a data port 8301. Since there are two distinct clients for HF and FM, and they can run simultaneously on different ports, perhaps could be published under _vara-hf._tcp and _vara-fm._tcp respectively.

• rigctl/rigctld. Usually exposed on 4532 port. Maybe _rigctl._tcp

Thoughts?

Per the apr base91 comment telemetry spec (also at he.fi), section 3.9 says:

3.9 If binary values are transmitted, they MUST appear last in the
extension, after all 5 "analog" channels. They are put into a single
Base91 encoded integer, where the LSB (least significant bit) corresponds
to B1 of the traditional Telemetry specification, the 8th bit corresponds
to B8. Bits 9 to 13 are reserved to future use and will not currently be
treated as additional binary values.

Then, later, in the examples it is given:

Binary values:    '!"' decodes to decimal 1, binary values 10000000,
                          B1 is 1, B2 to B8 are 0.

I could be misunderstanding, but it was my understanding that in binary, the LSB was the right-most bit. Wouldn't this mean that in the given example B1 would be 0? I guess I am confused as to whether the binary representation goes from B8-B1 like 87654321 or from B1-B8 like 12345678. If B1 were the LSB I would think it would be 87654321 but in the example, it seems to go 12345678. Could I get some clarity here? Also, I am assuming, but would appreciate some clarity as well, as to where the 9-13 reserved bits would then go.

Thanks!

Not sure if this is the correct forum for this kind of question, please feel free to close this issue if its not.

I'm working on configuring a Microchip BM70 bluetooth module in the correct way to be discovered by the aprs.fi iOS app (and any other applications implementing the BLE spec defined in this repo).

As far as I can tell, I have the correct service and characteristic UUIDs:

I noticed that the tnc3 firmware sets a few other pieces of info. I'm wondering if maybe this "magic" string is needed by aprs.fi https://github.com/mobilinkd/tnc3-firmware/blob/master/TNC/bm78.cpp#L308. I also notice that the UUIDs set in this firmware are different from those defined in the spec. 🤔

Any guidance would be greatly appreciated!

In implementing the spec in an ESP32 using Nimble, I uncovered a couple of assumptions not yet documented. These impact both the iPhone APRS.FI app and the mobilinkd Config app from connecting and sending frames to the TNC.

1. Service UUID needs to be present in the Gap advertisement. Interestingly, very few BLE devices do this, presumably to keep gap packets short, Nimble itself limits the length to 31 which is challenging. (Only affects APRS.FI from memory)
2. Preferred MTU on the TNC I believe needs to be set to 527.
3. Flags on the KTS TX characteristic needs to be WRITE WITHOUT RESPONSE. Using plain WRITE does not work with either app.

Might be useful to document this. 1 &3 are critical, 2 I’m not sure anymore, it was a long journey to get to this point!

Could you please add on know TNC and Firmwares

the TTGO T-Beam or LoRa32v2.1 boards with my firmware as this runs also now with aprs.fi with AX.25 protocol over BLE and APRS.fi iOS app

www.github.com/richonguzman/LoRa_APRS_Tracker

Consider a pull request to add a PTT interface BLE characteristic.
Some modem waveforms do not lend themselves to a derived PTT (tx keyline) as easily as FSK.
Key delay to data valid could still be specified in the KISS parameters to give the PA time to power up/antenna match/TDMA slot, etc. .

Hi,

I got a TNC working which received AX25 packets from aprs.fi app over BLE.

when TNC receives APRS packet, it decodes and changes into an AX25 packet , and this is encapsulated in KISS

so I don't know how to keep on going to enable the good reception of the aprs.fi phone