LoRa-APRS Monitoring possible

[df6dbf]

I do my first steps with LoRa-APRS. Got 2 Boards (one Tracker and one as IGate configured) running and want to monitor the traffic with SDRANGEL an a PlutoSDR.

But i got stuck by confiruring the ChirpChat Plugin.
The following Parameters are recommended:

Derzeit haben sich in DL anscheindend folgende Parameter für LoRa-APRS durchgesetzt:

Frequenzen:

TX-Frequenz: 433.775 MHz (von Tracker zu iGate)
RX-Frequenz: 433.900 MHz (von iGate zu Tracker - bei RxGates nicht aktiv)

Übertragungsparameter:

Spreading factor: SF12
Bandwidth: 125 kHz
Coding rate: 4/5

I have SF and Bandwith found, but where to adjust the Coding Rate?

73s Holger, DF6DBF

[f4exb]

Hello,

please check this: https://github.com/f4exb/sdrangel/tree/master/plugins/channelrx/demodchirpchat#a8-number-of-fec-parity-bits

This is the number of parity bits so here 4/5 means there is 1 parity bit (5 = 4+1) and the value is 1.

Take also note that SF=12 may imply DE=2 as per LoRa standard you will have to try btw DE=0 and DE=2 (0 and 2 are the only valid values for LoRa).

Brgds.

[srcejon]

Didn't know about LoRa-APRS. It should probably be fairly easy to hook up the ChirpChat demodulator to the APRS feature - which should allow LoRa-APRS decoding and to function as an IGate.

[f4exb]

I was thinking about this... 😄 I don't know about the payload format but it is probably accessible.

[srcejon]

Perhaps df6dbf can send some example packets / .sdriq file?

All the Chirpchat demod would need to do, would be to send a MainCore::MsgPacket to the "packets" pipe.

[df6dbf]

I can give a few Infos abt LoRa-APRS.
The Project was invented in Austria, the Frequency is 433.775 MHz. Hardware are in most cases cheap LoRa-Boards, sometimes with GPS. I purchased two of this Boards:

https://www.ebay.de/itm/TTGO-T-Beam-ESP32-LoRa-APRS-433MHz-OLED-T22V1-1-ERP32-GPS-WiFi-Wettersonden/254903723732?hash=item3b597226d4:g:vP4AAOSw5Stf7IaU

I have a little bit of expirience with ESP8266 and ESP32 Boards and Micropython but i am far away from being a programmer. :)
So i got most of my Informations from here: https://www.lora-aprs.at

So i configured one of my boards as iGate and one as Tracker using the Stuff found on Github:

https://github.com/lora-aprs/LoRa_APRS_iGate
https://github.com/oe3cjb/TTGO-T-Beam-LoRa-APRS

Both works surprisely well, hearing Stationns with simular Hardware over a Distance over 4,5km with a Diamond X30 Antenna and my Packets are also heard by others. (You may look at aprs.fi and search for DF6DBF-10 and DF6DBF-11)

The Payload is in Mic-E compressed Format, well known if you are in old fashioned APRS on 2m.

73s Holger, DF6DBF

[df6dbf]

Got here a Screenshot of the Signal from my Tracker.

[srcejon]

Ah, the APRS feature doesn't currently support Mic-E compression. But shouldn't be too difficult to add.

Would you be able to create an .sdriq file of a packet transmission so I can replay it? (Add channel File Sink - Press the file button to give a name such as lora.sdriq and then press the record button next to the save button)? Then we can try to do some proper decoding in SDRangel.

[df6dbf]

I had just recorded a few Beacons from my Tracker. Have you an valid email adress for me?

[srcejon]

Great. Can you zip them up and attach them to this issue? (Should just be able to drop and drag them).

Unless they're bigger than 25MB, in which case we'll need to do it differently (but that's more than my email will accept anyway)

[df6dbf]

lora_aprs_df6dbf-11_beacon.2021-03-25T13_54_41_607.zip

[srcejon]

Thanks - I can demodulate that.

[srcejon]

Well, I can sort of demodulate it. The first part of the packet is OK - but it looks like it is being demodulated incorrectly after the position is received (It doesn't look like Mic-E encoding to me, but corrupted data). If I replay it several times, it gets slightly different data each time and the CRC is always wrong. (The CRC is also wrong in the image you posted)

However, there is enough of a packet there to workout the basic format, so I've submitted a patch that forwards the packet on to the APRS feature anyway:

This doesn't currently check the CRC, but probably should. If you can work out how to capture fully valid packets, and they have a valid CRC, then we can enable checking.

[df6dbf]

I checked my Setup: It seems there is a Problem with a PlutoSDR as Frontend. A simple SDRStick with SoapySDR works fine and the CRC-Check is now also ok. Adding a new Sample now with "all green" here.
df6dbf-11_lora_beacon.2021-03-26T15_55_17_701.zip

Im my Area a some OMs playing with LoRa-APRS if you need more Samples let me know.

73s Holger

[f4exb]

Just as a sidenote RTL-SDR is supported by a native plugin that will have better performance and more control on the RTL-SDR:
https://github.com/f4exb/sdrangel/blob/master/plugins/samplesource/rtlsdr/readme.md

[srcejon]

Thanks - that looks better. Just submitted a patch to better support the LoRa CRC.

It should work now - although it doesn't look like the telemetry is transmitted in the APRS telemetry format, just as a comment - so you wont be able to see it plotted as a graph. Perhaps something to feedback to whoever develops the tracker.

[df6dbf]

It should work now - although it doesn't look like the telemetry is transmitted in the APRS telemetry format, just as a comment - so you wont be able to see it plotted as a graph. Perhaps something to feedback to whoever develops the tracker.

Telemetry will be added in the near future:

lora-aprs/LoRa_APRS_Tracker#7

73s Holger

[f4exb]

Implemented in v6.7.0