Is telemetry digipeated?

[Matt]

I am not sure if my issue is with my devices sending telemetry, or with the digipeater in QTH. Telemetry shows up in the log but does not show in aprs.fi.

Example from QTH log below.

22:27:24.957 DEBUG APRSManagerImpl.transmit():145 - Posting packet for repeat
22:27:24.993 DEBUG KissTcpConnection.socket():93 - Data successfully written
22:28:06.444 DEBUG APRSManagerImpl.onAprsPacketReceived():167 - MESSAGE > from: KKKKKK-4 to: KKKKKK-4 msg: PARM.B Volt,B In,B Out,AC V,AC C
22:28:06.448 DEBUG APRSManagerImpl.onAprsPacketReceived():167 - MESSAGE > from: KKKKKK-4 to: KKKKKK-4 msg: UNIT.mV,mA,mA,mV,mA
22:28:06.906 DEBUG APRSManagerImpl.onAprsPacketReceived():167 - MESSAGE > from: KKKKKK-4 to: KKKKKK-4 msg: EQNS.0,5.1,3000,0,10,0,0,10,0,0,28,3000,0,10,0
22:28:06.956 DEBUG APRSManagerImpl.onAprsPacketReceived():167 - TELEMETRY > KKKKKK-4 @ 0°0'0" N, 0°0'0" E 0
22:28:06.957 DEBUG APRSManagerImpl.onAprsPacketReceived():171 - Telemetry: 233.0,78.0,0.0,62.0,82.0,0.0
22:28:19.907 DEBUG APRSManagerImpl.onAprsPacketReceived():167 - POSITION > KKKKKK-3 @ 46°56'35" N, 97°1'38" W Lora Tracker Batt=V
22:28:19.953 DEBUG APRSManagerImpl.transmit():145 - Posting packet for repeat
22:28:19.955 DEBUG KissTcpConnection.socket():93 - Data successfully written
22:29:06.445 DEBUG APRSManagerImpl.onAprsPacketReceived():167 - MESSAGE > from: KKKKKK-4 to: KKKKKK-4 msg: PARM.B Volt,B In,B Out,AC V,AC C
22:29:06.451 DEBUG APRSManagerImpl.onAprsPacketReceived():167 - MESSAGE > from: KKKKKK-4 to: KKKKKK-4 msg: UNIT.mV,mA,mA,mV,mA
22:29:06.944 DEBUG APRSManagerImpl.onAprsPacketReceived():167 - MESSAGE > from: KKKKKK-4 to: KKKKKK-4 msg: EQNS.0,5.1,3000,0,10,0,0,10,0,0,28,3000,0,10,0
22:29:06.951 DEBUG APRSManagerImpl.onAprsPacketReceived():167 - TELEMETRY > KKKKKK-4 @ 0°0'0" N, 0°0'0" E 0
22:29:06.992 DEBUG APRSManagerImpl.onAprsPacketReceived():171 - Telemetry: 233.0,75.0,0.0,62.0,80.0,0.0

‌

[Weston Bustraan]

I’m a little confused, but it may be the terminology.

Digipeating would mean that a packet received on RF would be re-transmitted on RF. If you want packets to be received on RF and then transmitted to APRS-IS, that would be an IGate. So, if you only have “Enable Digipeater” checked, and not “Enable IGate”, no packets would be sent to aprs.fi

What are your settings on the Digipeater tab in your Preferences?

[Matt]

Sorry for the confusion. I am digipeating from one KISS device, over RF via another KISS device (Direwolf connected to radio with transmit and receive capability), and the RF is captured by a nearby iGate and sent to APRS-IS. The packets are ending up on aprs.fi, but not the telemetry data.

That’s a good point, though. The iGate is another point where telemetry may be dropped. I can try later using QTH as an iGate and see if behavior changes.

‌

[Weston Bustraan]

Do you know what the via path looks like for the telemetry packets? i.e. do the packets have a WIDE1-1 in the path?

There are also other aliases that, if they appear in the path, can prevent the packets from being IGated, such as, “TCPIP”, “TCPXX“, “RFONLY”, or “NOGATE”.

If you send me your QTH.app database, I can also help take a look at that as well. The database is located at ~\Library\Application Support\com.w8wjb.QTH\qth.sqlite3 If you don’t want to attach it here, feel free to email it to me.

[Matt]

I emailed my database…then I checked the path. Path was WIDE1-1, but I just changed it to WIDE1-1,WIDE2-1.

ETA: well, that’s neat to see!

‌

[Weston Bustraan]

In the database, it appears that the telemetry packets are being sent without any VIA path.

Looking at the source code for the TTGO-T-Beam-LoRa-APRS, I see this:

 void sendTelemetryFrame() {
  #ifdef T_BEAM_V1_0
    uint8_t b_volt = (axp.getBattVoltage() - 3000) / 5.1;
    uint8_t b_in_c = (axp.getBattChargeCurrent()) / 10;
    uint8_t b_out_c = (axp.getBattDischargeCurrent()) / 10;
    uint8_t ac_volt = (axp.getVbusVoltage() - 3000) / 28;
    uint8_t ac_c = (axp.getVbusCurrent()) / 10;

    String telemetryParamsNames = String(":") + Tcall + ":PARM.B Volt,B In,B Out,AC V,AC C";
    String telemetryUnitNames = String(":") + Tcall + ":UNIT.mV,mA,mA,mV,mA";
    String telemetryEquations = String(":") + Tcall + ":EQNS.0,5.1,3000,0,10,0,0,10,0,0,28,3000,0,10,0";
    String telemetryData = String("T#MIC") + String(b_volt) + ","+ String(b_in_c) + ","+ String(b_out_c) + ","+ String(ac_volt) + ","+ String(ac_c) + ",00000000";
    String telemetryBase = "";
    telemetryBase += Tcall + ">APLO01" + ":";
    sendToTNC(telemetryBase + telemetryParamsNames);
    sendToTNC(telemetryBase + telemetryUnitNames);
    sendToTNC(telemetryBase + telemetryEquations);
    sendToTNC(telemetryBase + telemetryData);
  #endif
}

On line 14 above, it is omitting any digipeaters following the TOCALL of APLO01.

Contrast this to the code that constructs the location packet:

if (relay_path){
    outString += ">APLO01," + relay_path + ":!";
  }else{
    outString += ">APLO01:!";
  }

This would be the reason why the location packets are being digipeated but the telemetry packets are not.

[Matt]

Brilliant!

I’ve changed that line to

telemetryBase += Tcall + ">APLO01," + relay_path + ":";

and can confirm that the packets are digipeated. Getting errors from aprs.fi now, but I have confirmed where the issue is.

Thanks! This can be closed now.

[Weston Bustraan]

Actually, I think I might leave this open until we figure out why aprs.fi is marking the packets as invalid. It could still be something that QTH is doing wrong.

[Weston Bustraan]

I checked into why aprs.fi considers some of the packets invalid.

Here’s a telemetry packet:

2021-09-12 20:26:22 EDT: KB1GIM-4>APQTH1,KB1GIM-2*,WIDE2-1,qAO,N0RNB-5:T#MIC222,0,0,70,11,00000000 [Invalid telemetry packet]

It appears that aprs.fi’s parser does not appear to support the “MIC” after the ‘#'. I checked the APRS spec and it does allow for the “MIC”. Given that it appears in the spec, I think the problem is with aprs.fi’s parser. Of course, you could change the code that generates the packet to include a numeric sequence number instead.

‌

Here is a message packet:

KB1GIM-4>APQTH1,KB1GIM-2*,WIDE2-1,qAO,N0RNB-5::KB1GIM-4:UNIT.mV,mA,mA,mV,mA

In this case, the addressee field needs to be padded out to exactly 9 characters, so it should be:

:KB1GIM-4 :UNIT.mV,mA,mA,mV,mA

‌

There is one thing that I have to check into, though. I noticed that the destination field is coming in from device as APLO01 and seems to be being digipeated as APQTH1. That is probably a bug.

As long as the packet isn’t a Mic-E packet, the worst that can happen right now is that the sending device will be misidentified as QTH.app instead of the device that APLO01. That said, the APLO?? TOCALL hasn’t made it out to the TOCALL database yet, so it wouldn’t be identified correctly by most software yet, anyway.

[Matt]

FWIW, here is exactly how I “fixed” the path: https://github.com/mattbk/TTGO-T-Beam-LoRa-APRS/pull/2/commits/594da346edab58fcb541bae3749e63fa51fdf718

The APLOxx TOCALL is pretty new: https://github.com/SQ9MDD/TTGO-T-Beam-LoRa-APRS/issues/52#issuecomment-913039784

Good notes on MIC and the 9-character padding. I’ll see what I can figure out as part of the telemetry PR I’m working on.

(and as always during testing, I should chop my path down to WIDE1-1)

‌

[Weston Bustraan]

The bug with the destination field should be fixed in v0.5.10 now

[Matt]

It looks like “MIC” was in the original spec (p. 68), but I don’t see it mentioned in these links (from the 1.2 proposals):

Original Mic-E Telemetry Format is depricated. Overtaken by MFR TYPE codes. A new Telemetry format has been developed See spec .

Or are you looking at another document? I read the Base 91 document more closely and see this now:

Please read APRS101.PDF chapter 13 ("Telemetry Data") first. This specification only adds a new format used to transmit telemetry values. Otherwise the old specification is still valid.

I did get the telemetry working with your suggestions of padding the message callsign and removing “MIC” here: https://github.com/mattbk/TTGO-T-Beam-LoRa-APRS/commit/e572a68103770728e3edbfc2f99fd184dc5cc6d6.

I will test the new version of QTH, hopefully tomorrow.

‌

[Matt]

Destination field in v0.5.10 looks good from my end. You can see where I changed versions below.

2021-09-13 17:22:03 CDT: KB1GIM-4>APQTH1,KB1GIM-2*,qAO,N0RNB-5::KB1GIM-4 :PARM.B Volt,B In,B Out,AC V,AC C
2021-09-13 17:22:04 CDT: KB1GIM-4>APQTH1,KB1GIM-2*,qAO,N0RNB-5::KB1GIM-4 :UNIT.mV,mA,mA,mV,mA
2021-09-13 17:22:05 CDT: KB1GIM-4>APQTH1,KB1GIM-2*,qAO,N0RNB-5::KB1GIM-4 :EQNS.0,5.1,3000,0,10,0,0,10,0,0,28,3000,0,10,0
2021-09-13 17:22:06 CDT: KB1GIM-4>APQTH1,KB1GIM-2*,qAO,N0RNB-5:T#221,0,0,71,8,00000000
2021-09-14 09:55:26 CDT: KB1GIM-4>APLO01,KB1GIM-2*,qAO,N0RNB-5::KB1GIM-4 :PARM.B Volt,B In,B Out,AC V,AC C
2021-09-14 09:55:27 CDT: KB1GIM-4>APLO01,KB1GIM-2*,qAO,N0RNB-5::KB1GIM-4 :UNIT.mV,mA,mA,mV,mA
2021-09-14 09:55:28 CDT: KB1GIM-4>APLO01,KB1GIM-2*,qAO,N0RNB-5::KB1GIM-4 :EQNS.0,5.1,3000,0,10,0,0,10,0,0,28,3000,0,10,0

‌